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-June/005197.html | 80 + zarb-ml/mageia-dev/2011-June/005198.html | 93 + zarb-ml/mageia-dev/2011-June/005199.html | 104 + zarb-ml/mageia-dev/2011-June/005200.html | 115 + zarb-ml/mageia-dev/2011-June/005201.html | 136 + zarb-ml/mageia-dev/2011-June/005202.html | 127 + zarb-ml/mageia-dev/2011-June/005203.html | 128 + zarb-ml/mageia-dev/2011-June/005204.html | 100 + zarb-ml/mageia-dev/2011-June/005205.html | 99 + zarb-ml/mageia-dev/2011-June/005206.html | 110 + zarb-ml/mageia-dev/2011-June/005207.html | 119 + zarb-ml/mageia-dev/2011-June/005208.html | 151 + zarb-ml/mageia-dev/2011-June/005209.html | 163 + zarb-ml/mageia-dev/2011-June/005210.html | 89 + zarb-ml/mageia-dev/2011-June/005211.html | 82 + zarb-ml/mageia-dev/2011-June/005212.html | 90 + zarb-ml/mageia-dev/2011-June/005213.html | 106 + zarb-ml/mageia-dev/2011-June/005214.html | 99 + zarb-ml/mageia-dev/2011-June/005215.html | 107 + zarb-ml/mageia-dev/2011-June/005216.html | 101 + zarb-ml/mageia-dev/2011-June/005217.html | 105 + zarb-ml/mageia-dev/2011-June/005218.html | 100 + zarb-ml/mageia-dev/2011-June/005219.html | 94 + zarb-ml/mageia-dev/2011-June/005220.html | 125 + zarb-ml/mageia-dev/2011-June/005221.html | 115 + zarb-ml/mageia-dev/2011-June/005222.html | 132 + zarb-ml/mageia-dev/2011-June/005223.html | 134 + zarb-ml/mageia-dev/2011-June/005224.html | 123 + zarb-ml/mageia-dev/2011-June/005225.html | 161 + zarb-ml/mageia-dev/2011-June/005226.html | 170 + zarb-ml/mageia-dev/2011-June/005227.html | 107 + zarb-ml/mageia-dev/2011-June/005228.html | 97 + zarb-ml/mageia-dev/2011-June/005229.html | 115 + zarb-ml/mageia-dev/2011-June/005230.html | 121 + zarb-ml/mageia-dev/2011-June/005231.html | 109 + zarb-ml/mageia-dev/2011-June/005232.html | 114 + zarb-ml/mageia-dev/2011-June/005233.html | 104 + zarb-ml/mageia-dev/2011-June/005234.html | 113 + zarb-ml/mageia-dev/2011-June/005235.html | 78 + zarb-ml/mageia-dev/2011-June/005236.html | 102 + zarb-ml/mageia-dev/2011-June/005237.html | 77 + zarb-ml/mageia-dev/2011-June/005238.html | 151 + zarb-ml/mageia-dev/2011-June/005239.html | 159 + zarb-ml/mageia-dev/2011-June/005240.html | 168 + zarb-ml/mageia-dev/2011-June/005241.html | 144 + zarb-ml/mageia-dev/2011-June/005242.html | 193 + zarb-ml/mageia-dev/2011-June/005243.html | 254 ++ zarb-ml/mageia-dev/2011-June/005244.html | 179 + zarb-ml/mageia-dev/2011-June/005245.html | 136 + zarb-ml/mageia-dev/2011-June/005246.html | 188 + zarb-ml/mageia-dev/2011-June/005247.html | 210 + zarb-ml/mageia-dev/2011-June/005248.html | 224 + zarb-ml/mageia-dev/2011-June/005249.html | 219 + zarb-ml/mageia-dev/2011-June/005250.html | 218 + zarb-ml/mageia-dev/2011-June/005251.html | 168 + zarb-ml/mageia-dev/2011-June/005252.html | 187 + zarb-ml/mageia-dev/2011-June/005253.html | 178 + zarb-ml/mageia-dev/2011-June/005254.html | 155 + zarb-ml/mageia-dev/2011-June/005255.html | 224 + zarb-ml/mageia-dev/2011-June/005256.html | 157 + zarb-ml/mageia-dev/2011-June/005257.html | 197 + zarb-ml/mageia-dev/2011-June/005258.html | 147 + zarb-ml/mageia-dev/2011-June/005259.html | 167 + zarb-ml/mageia-dev/2011-June/005260.html | 189 + zarb-ml/mageia-dev/2011-June/005261.html | 217 + zarb-ml/mageia-dev/2011-June/005262.html | 165 + zarb-ml/mageia-dev/2011-June/005263.html | 209 + zarb-ml/mageia-dev/2011-June/005264.html | 201 + zarb-ml/mageia-dev/2011-June/005265.html | 175 + zarb-ml/mageia-dev/2011-June/005266.html | 210 + zarb-ml/mageia-dev/2011-June/005267.html | 80 + zarb-ml/mageia-dev/2011-June/005268.html | 93 + zarb-ml/mageia-dev/2011-June/005269.html | 159 + zarb-ml/mageia-dev/2011-June/005270.html | 93 + zarb-ml/mageia-dev/2011-June/005271.html | 197 + zarb-ml/mageia-dev/2011-June/005272.html | 176 + zarb-ml/mageia-dev/2011-June/005273.html | 216 + zarb-ml/mageia-dev/2011-June/005274.html | 93 + zarb-ml/mageia-dev/2011-June/005275.html | 105 + zarb-ml/mageia-dev/2011-June/005276.html | 164 + zarb-ml/mageia-dev/2011-June/005277.html | 170 + zarb-ml/mageia-dev/2011-June/005278.html | 172 + zarb-ml/mageia-dev/2011-June/005279.html | 211 + zarb-ml/mageia-dev/2011-June/005280.html | 222 + zarb-ml/mageia-dev/2011-June/005281.html | 223 + zarb-ml/mageia-dev/2011-June/005282.html | 121 + zarb-ml/mageia-dev/2011-June/005283.html | 127 + zarb-ml/mageia-dev/2011-June/005284.html | 186 + zarb-ml/mageia-dev/2011-June/005285.html | 200 + zarb-ml/mageia-dev/2011-June/005286.html | 187 + zarb-ml/mageia-dev/2011-June/005287.html | 183 + zarb-ml/mageia-dev/2011-June/005288.html | 187 + zarb-ml/mageia-dev/2011-June/005289.html | 250 ++ zarb-ml/mageia-dev/2011-June/005290.html | 256 ++ zarb-ml/mageia-dev/2011-June/005291.html | 268 ++ zarb-ml/mageia-dev/2011-June/005292.html | 201 + zarb-ml/mageia-dev/2011-June/005293.html | 86 + zarb-ml/mageia-dev/2011-June/005294.html | 97 + zarb-ml/mageia-dev/2011-June/005295.html | 217 + zarb-ml/mageia-dev/2011-June/005296.html | 196 + zarb-ml/mageia-dev/2011-June/005297.html | 186 + zarb-ml/mageia-dev/2011-June/005298.html | 208 + zarb-ml/mageia-dev/2011-June/005299.html | 216 + zarb-ml/mageia-dev/2011-June/005300.html | 224 + zarb-ml/mageia-dev/2011-June/005301.html | 242 ++ zarb-ml/mageia-dev/2011-June/005302.html | 203 + zarb-ml/mageia-dev/2011-June/005303.html | 258 ++ zarb-ml/mageia-dev/2011-June/005304.html | 265 ++ zarb-ml/mageia-dev/2011-June/005305.html | 208 + zarb-ml/mageia-dev/2011-June/005306.html | 248 ++ zarb-ml/mageia-dev/2011-June/005307.html | 205 + zarb-ml/mageia-dev/2011-June/005308.html | 217 + zarb-ml/mageia-dev/2011-June/005309.html | 216 + zarb-ml/mageia-dev/2011-June/005310.html | 92 + zarb-ml/mageia-dev/2011-June/005311.html | 212 + zarb-ml/mageia-dev/2011-June/005312.html | 226 + zarb-ml/mageia-dev/2011-June/005313.html | 258 ++ zarb-ml/mageia-dev/2011-June/005314.html | 270 ++ zarb-ml/mageia-dev/2011-June/005315.html | 210 + zarb-ml/mageia-dev/2011-June/005316.html | 238 ++ zarb-ml/mageia-dev/2011-June/005317.html | 204 + zarb-ml/mageia-dev/2011-June/005318.html | 198 + zarb-ml/mageia-dev/2011-June/005319.html | 219 + zarb-ml/mageia-dev/2011-June/005320.html | 209 + zarb-ml/mageia-dev/2011-June/005321.html | 212 + zarb-ml/mageia-dev/2011-June/005322.html | 216 + zarb-ml/mageia-dev/2011-June/005323.html | 205 + zarb-ml/mageia-dev/2011-June/005324.html | 207 + zarb-ml/mageia-dev/2011-June/005325.html | 183 + zarb-ml/mageia-dev/2011-June/005326.html | 150 + zarb-ml/mageia-dev/2011-June/005327.html | 165 + zarb-ml/mageia-dev/2011-June/005328.html | 210 + zarb-ml/mageia-dev/2011-June/005329.html | 234 ++ zarb-ml/mageia-dev/2011-June/005330.html | 222 + zarb-ml/mageia-dev/2011-June/005331.html | 137 + zarb-ml/mageia-dev/2011-June/005332.html | 160 + zarb-ml/mageia-dev/2011-June/005333.html | 129 + zarb-ml/mageia-dev/2011-June/005334.html | 136 + zarb-ml/mageia-dev/2011-June/005335.html | 142 + zarb-ml/mageia-dev/2011-June/005336.html | 164 + zarb-ml/mageia-dev/2011-June/005337.html | 183 + zarb-ml/mageia-dev/2011-June/005338.html | 158 + zarb-ml/mageia-dev/2011-June/005339.html | 182 + zarb-ml/mageia-dev/2011-June/005340.html | 187 + zarb-ml/mageia-dev/2011-June/005341.html | 120 + zarb-ml/mageia-dev/2011-June/005342.html | 126 + zarb-ml/mageia-dev/2011-June/005343.html | 142 + zarb-ml/mageia-dev/2011-June/005344.html | 223 + zarb-ml/mageia-dev/2011-June/005345.html | 132 + zarb-ml/mageia-dev/2011-June/005346.html | 301 ++ zarb-ml/mageia-dev/2011-June/005347.html | 144 + zarb-ml/mageia-dev/2011-June/005348.html | 236 ++ zarb-ml/mageia-dev/2011-June/005349.html | 145 + zarb-ml/mageia-dev/2011-June/005350.html | 165 + zarb-ml/mageia-dev/2011-June/005351.html | 123 + zarb-ml/mageia-dev/2011-June/005352.html | 129 + zarb-ml/mageia-dev/2011-June/005353.html | 134 + zarb-ml/mageia-dev/2011-June/005354.html | 167 + zarb-ml/mageia-dev/2011-June/005355.html | 186 + zarb-ml/mageia-dev/2011-June/005356.html | 146 + zarb-ml/mageia-dev/2011-June/005357.html | 182 + zarb-ml/mageia-dev/2011-June/005358.html | 184 + zarb-ml/mageia-dev/2011-June/005359.html | 155 + zarb-ml/mageia-dev/2011-June/005360.html | 145 + zarb-ml/mageia-dev/2011-June/005361.html | 172 + zarb-ml/mageia-dev/2011-June/005362.html | 171 + zarb-ml/mageia-dev/2011-June/005363.html | 150 + zarb-ml/mageia-dev/2011-June/005364.html | 314 ++ zarb-ml/mageia-dev/2011-June/005365.html | 192 + zarb-ml/mageia-dev/2011-June/005366.html | 169 + zarb-ml/mageia-dev/2011-June/005367.html | 166 + zarb-ml/mageia-dev/2011-June/005368.html | 149 + zarb-ml/mageia-dev/2011-June/005369.html | 186 + zarb-ml/mageia-dev/2011-June/005370.html | 167 + zarb-ml/mageia-dev/2011-June/005371.html | 156 + zarb-ml/mageia-dev/2011-June/005372.html | 195 + zarb-ml/mageia-dev/2011-June/005373.html | 157 + zarb-ml/mageia-dev/2011-June/005374.html | 163 + zarb-ml/mageia-dev/2011-June/005375.html | 177 + zarb-ml/mageia-dev/2011-June/005376.html | 169 + zarb-ml/mageia-dev/2011-June/005377.html | 217 + zarb-ml/mageia-dev/2011-June/005378.html | 204 + zarb-ml/mageia-dev/2011-June/005379.html | 192 + zarb-ml/mageia-dev/2011-June/005380.html | 193 + zarb-ml/mageia-dev/2011-June/005381.html | 177 + zarb-ml/mageia-dev/2011-June/005382.html | 143 + zarb-ml/mageia-dev/2011-June/005383.html | 188 + zarb-ml/mageia-dev/2011-June/005384.html | 154 + zarb-ml/mageia-dev/2011-June/005385.html | 166 + zarb-ml/mageia-dev/2011-June/005386.html | 153 + zarb-ml/mageia-dev/2011-June/005387.html | 179 + zarb-ml/mageia-dev/2011-June/005388.html | 182 + zarb-ml/mageia-dev/2011-June/005389.html | 161 + zarb-ml/mageia-dev/2011-June/005390.html | 159 + zarb-ml/mageia-dev/2011-June/005391.html | 164 + zarb-ml/mageia-dev/2011-June/005392.html | 179 + zarb-ml/mageia-dev/2011-June/005393.html | 201 + zarb-ml/mageia-dev/2011-June/005394.html | 147 + zarb-ml/mageia-dev/2011-June/005395.html | 154 + zarb-ml/mageia-dev/2011-June/005396.html | 191 + zarb-ml/mageia-dev/2011-June/005397.html | 200 + zarb-ml/mageia-dev/2011-June/005398.html | 148 + zarb-ml/mageia-dev/2011-June/005399.html | 177 + zarb-ml/mageia-dev/2011-June/005400.html | 161 + zarb-ml/mageia-dev/2011-June/005401.html | 165 + zarb-ml/mageia-dev/2011-June/005402.html | 186 + zarb-ml/mageia-dev/2011-June/005403.html | 165 + zarb-ml/mageia-dev/2011-June/005404.html | 161 + zarb-ml/mageia-dev/2011-June/005405.html | 188 + zarb-ml/mageia-dev/2011-June/005406.html | 129 + zarb-ml/mageia-dev/2011-June/005407.html | 190 + zarb-ml/mageia-dev/2011-June/005408.html | 173 + zarb-ml/mageia-dev/2011-June/005409.html | 197 + zarb-ml/mageia-dev/2011-June/005410.html | 212 + zarb-ml/mageia-dev/2011-June/005411.html | 145 + zarb-ml/mageia-dev/2011-June/005412.html | 175 + zarb-ml/mageia-dev/2011-June/005413.html | 189 + zarb-ml/mageia-dev/2011-June/005414.html | 178 + zarb-ml/mageia-dev/2011-June/005415.html | 195 + zarb-ml/mageia-dev/2011-June/005416.html | 180 + zarb-ml/mageia-dev/2011-June/005417.html | 206 + zarb-ml/mageia-dev/2011-June/005418.html | 186 + zarb-ml/mageia-dev/2011-June/005419.html | 218 + zarb-ml/mageia-dev/2011-June/005420.html | 194 + zarb-ml/mageia-dev/2011-June/005421.html | 161 + zarb-ml/mageia-dev/2011-June/005422.html | 165 + zarb-ml/mageia-dev/2011-June/005423.html | 132 + zarb-ml/mageia-dev/2011-June/005424.html | 77 + zarb-ml/mageia-dev/2011-June/005425.html | 155 + zarb-ml/mageia-dev/2011-June/005426.html | 155 + zarb-ml/mageia-dev/2011-June/005427.html | 157 + zarb-ml/mageia-dev/2011-June/005428.html | 225 + zarb-ml/mageia-dev/2011-June/005429.html | 162 + zarb-ml/mageia-dev/2011-June/005430.html | 273 ++ zarb-ml/mageia-dev/2011-June/005431.html | 184 + zarb-ml/mageia-dev/2011-June/005432.html | 187 + zarb-ml/mageia-dev/2011-June/005433.html | 245 ++ zarb-ml/mageia-dev/2011-June/005434.html | 237 ++ zarb-ml/mageia-dev/2011-June/005435.html | 260 ++ zarb-ml/mageia-dev/2011-June/005436.html | 208 + zarb-ml/mageia-dev/2011-June/005437.html | 255 ++ zarb-ml/mageia-dev/2011-June/005438.html | 171 + zarb-ml/mageia-dev/2011-June/005439.html | 133 + zarb-ml/mageia-dev/2011-June/005440.html | 134 + zarb-ml/mageia-dev/2011-June/005441.html | 129 + zarb-ml/mageia-dev/2011-June/005442.html | 318 ++ zarb-ml/mageia-dev/2011-June/005443.html | 198 + zarb-ml/mageia-dev/2011-June/005444.html | 200 + zarb-ml/mageia-dev/2011-June/005445.html | 134 + zarb-ml/mageia-dev/2011-June/005446.html | 169 + zarb-ml/mageia-dev/2011-June/005447.html | 207 + zarb-ml/mageia-dev/2011-June/005448.html | 209 + zarb-ml/mageia-dev/2011-June/005449.html | 183 + zarb-ml/mageia-dev/2011-June/005450.html | 177 + zarb-ml/mageia-dev/2011-June/005451.html | 287 ++ zarb-ml/mageia-dev/2011-June/005452.html | 279 ++ zarb-ml/mageia-dev/2011-June/005453.html | 237 ++ zarb-ml/mageia-dev/2011-June/005454.html | 200 + zarb-ml/mageia-dev/2011-June/005455.html | 265 ++ zarb-ml/mageia-dev/2011-June/005456.html | 198 + zarb-ml/mageia-dev/2011-June/005457.html | 178 + zarb-ml/mageia-dev/2011-June/005458.html | 192 + zarb-ml/mageia-dev/2011-June/005459.html | 249 ++ zarb-ml/mageia-dev/2011-June/005460.html | 273 ++ zarb-ml/mageia-dev/2011-June/005461.html | 210 + zarb-ml/mageia-dev/2011-June/005462.html | 265 ++ zarb-ml/mageia-dev/2011-June/005463.html | 194 + zarb-ml/mageia-dev/2011-June/005464.html | 176 + zarb-ml/mageia-dev/2011-June/005465.html | 181 + zarb-ml/mageia-dev/2011-June/005466.html | 273 ++ zarb-ml/mageia-dev/2011-June/005467.html | 154 + zarb-ml/mageia-dev/2011-June/005468.html | 132 + zarb-ml/mageia-dev/2011-June/005469.html | 175 + zarb-ml/mageia-dev/2011-June/005470.html | 153 + zarb-ml/mageia-dev/2011-June/005471.html | 259 ++ zarb-ml/mageia-dev/2011-June/005472.html | 280 ++ zarb-ml/mageia-dev/2011-June/005473.html | 291 ++ zarb-ml/mageia-dev/2011-June/005474.html | 285 ++ zarb-ml/mageia-dev/2011-June/005475.html | 349 ++ zarb-ml/mageia-dev/2011-June/005476.html | 267 ++ zarb-ml/mageia-dev/2011-June/005477.html | 179 + zarb-ml/mageia-dev/2011-June/005478.html | 294 ++ zarb-ml/mageia-dev/2011-June/005479.html | 134 + zarb-ml/mageia-dev/2011-June/005480.html | 134 + zarb-ml/mageia-dev/2011-June/005481.html | 300 ++ zarb-ml/mageia-dev/2011-June/005482.html | 153 + zarb-ml/mageia-dev/2011-June/005483.html | 241 ++ zarb-ml/mageia-dev/2011-June/005484.html | 217 + zarb-ml/mageia-dev/2011-June/005485.html | 259 ++ zarb-ml/mageia-dev/2011-June/005486.html | 162 + zarb-ml/mageia-dev/2011-June/005487.html | 179 + zarb-ml/mageia-dev/2011-June/005488.html | 188 + zarb-ml/mageia-dev/2011-June/005489.html | 305 ++ zarb-ml/mageia-dev/2011-June/005490.html | 243 ++ zarb-ml/mageia-dev/2011-June/005491.html | 206 + zarb-ml/mageia-dev/2011-June/005492.html | 130 + zarb-ml/mageia-dev/2011-June/005493.html | 182 + zarb-ml/mageia-dev/2011-June/005494.html | 251 ++ zarb-ml/mageia-dev/2011-June/005495.html | 174 + zarb-ml/mageia-dev/2011-June/005496.html | 186 + zarb-ml/mageia-dev/2011-June/005497.html | 156 + zarb-ml/mageia-dev/2011-June/005498.html | 302 ++ zarb-ml/mageia-dev/2011-June/005499.html | 188 + zarb-ml/mageia-dev/2011-June/005500.html | 224 + zarb-ml/mageia-dev/2011-June/005501.html | 245 ++ zarb-ml/mageia-dev/2011-June/005502.html | 237 ++ zarb-ml/mageia-dev/2011-June/005503.html | 192 + zarb-ml/mageia-dev/2011-June/005504.html | 242 ++ zarb-ml/mageia-dev/2011-June/005505.html | 247 ++ zarb-ml/mageia-dev/2011-June/005506.html | 267 ++ zarb-ml/mageia-dev/2011-June/005507.html | 201 + zarb-ml/mageia-dev/2011-June/005508.html | 206 + zarb-ml/mageia-dev/2011-June/005509.html | 157 + zarb-ml/mageia-dev/2011-June/005510.html | 100 + zarb-ml/mageia-dev/2011-June/005511.html | 153 + zarb-ml/mageia-dev/2011-June/005512.html | 222 + zarb-ml/mageia-dev/2011-June/005513.html | 266 ++ zarb-ml/mageia-dev/2011-June/005514.html | 173 + zarb-ml/mageia-dev/2011-June/005515.html | 230 + zarb-ml/mageia-dev/2011-June/005516.html | 143 + zarb-ml/mageia-dev/2011-June/005517.html | 234 ++ zarb-ml/mageia-dev/2011-June/005518.html | 193 + zarb-ml/mageia-dev/2011-June/005519.html | 219 + zarb-ml/mageia-dev/2011-June/005520.html | 166 + zarb-ml/mageia-dev/2011-June/005521.html | 226 + zarb-ml/mageia-dev/2011-June/005522.html | 106 + zarb-ml/mageia-dev/2011-June/005523.html | 113 + zarb-ml/mageia-dev/2011-June/005524.html | 233 ++ zarb-ml/mageia-dev/2011-June/005525.html | 207 + zarb-ml/mageia-dev/2011-June/005526.html | 157 + zarb-ml/mageia-dev/2011-June/005527.html | 235 ++ zarb-ml/mageia-dev/2011-June/005528.html | 177 + zarb-ml/mageia-dev/2011-June/005529.html | 237 ++ zarb-ml/mageia-dev/2011-June/005530.html | 234 ++ zarb-ml/mageia-dev/2011-June/005531.html | 157 + zarb-ml/mageia-dev/2011-June/005532.html | 183 + zarb-ml/mageia-dev/2011-June/005533.html | 111 + zarb-ml/mageia-dev/2011-June/005534.html | 134 + zarb-ml/mageia-dev/2011-June/005535.html | 166 + zarb-ml/mageia-dev/2011-June/005536.html | 232 + zarb-ml/mageia-dev/2011-June/005537.html | 236 ++ zarb-ml/mageia-dev/2011-June/005538.html | 157 + zarb-ml/mageia-dev/2011-June/005539.html | 272 ++ zarb-ml/mageia-dev/2011-June/005540.html | 272 ++ zarb-ml/mageia-dev/2011-June/005541.html | 276 ++ zarb-ml/mageia-dev/2011-June/005542.html | 301 ++ zarb-ml/mageia-dev/2011-June/005543.html | 227 + zarb-ml/mageia-dev/2011-June/005544.html | 158 + zarb-ml/mageia-dev/2011-June/005545.html | 176 + zarb-ml/mageia-dev/2011-June/005546.html | 220 + zarb-ml/mageia-dev/2011-June/005547.html | 239 ++ zarb-ml/mageia-dev/2011-June/005548.html | 244 ++ zarb-ml/mageia-dev/2011-June/005549.html | 255 ++ zarb-ml/mageia-dev/2011-June/005550.html | 229 + zarb-ml/mageia-dev/2011-June/005551.html | 232 + zarb-ml/mageia-dev/2011-June/005552.html | 245 ++ zarb-ml/mageia-dev/2011-June/005553.html | 252 ++ zarb-ml/mageia-dev/2011-June/005554.html | 239 ++ zarb-ml/mageia-dev/2011-June/005555.html | 241 ++ zarb-ml/mageia-dev/2011-June/005556.html | 237 ++ zarb-ml/mageia-dev/2011-June/005557.html | 179 + zarb-ml/mageia-dev/2011-June/005558.html | 246 ++ zarb-ml/mageia-dev/2011-June/005559.html | 232 + zarb-ml/mageia-dev/2011-June/005560.html | 176 + zarb-ml/mageia-dev/2011-June/005561.html | 238 ++ zarb-ml/mageia-dev/2011-June/005562.html | 181 + zarb-ml/mageia-dev/2011-June/005563.html | 160 + zarb-ml/mageia-dev/2011-June/005564.html | 250 ++ zarb-ml/mageia-dev/2011-June/005565.html | 286 ++ zarb-ml/mageia-dev/2011-June/005566.html | 185 + zarb-ml/mageia-dev/2011-June/005567.html | 173 + zarb-ml/mageia-dev/2011-June/005568.html | 188 + zarb-ml/mageia-dev/2011-June/005569.html | 236 ++ zarb-ml/mageia-dev/2011-June/005570.html | 186 + zarb-ml/mageia-dev/2011-June/005571.html | 168 + zarb-ml/mageia-dev/2011-June/005572.html | 388 ++ zarb-ml/mageia-dev/2011-June/005573.html | 179 + zarb-ml/mageia-dev/2011-June/005574.html | 124 + zarb-ml/mageia-dev/2011-June/005575.html | 220 + zarb-ml/mageia-dev/2011-June/005576.html | 180 + zarb-ml/mageia-dev/2011-June/005577.html | 170 + zarb-ml/mageia-dev/2011-June/005578.html | 174 + zarb-ml/mageia-dev/2011-June/005579.html | 166 + zarb-ml/mageia-dev/2011-June/005580.html | 183 + zarb-ml/mageia-dev/2011-June/005581.html | 209 + zarb-ml/mageia-dev/2011-June/005582.html | 218 + zarb-ml/mageia-dev/2011-June/005583.html | 125 + zarb-ml/mageia-dev/2011-June/005584.html | 255 ++ zarb-ml/mageia-dev/2011-June/005585.html | 183 + zarb-ml/mageia-dev/2011-June/005586.html | 264 ++ zarb-ml/mageia-dev/2011-June/005587.html | 189 + zarb-ml/mageia-dev/2011-June/005588.html | 256 ++ zarb-ml/mageia-dev/2011-June/005589.html | 193 + zarb-ml/mageia-dev/2011-June/005590.html | 203 + zarb-ml/mageia-dev/2011-June/005591.html | 269 ++ zarb-ml/mageia-dev/2011-June/005592.html | 218 + zarb-ml/mageia-dev/2011-June/005593.html | 239 ++ zarb-ml/mageia-dev/2011-June/005594.html | 239 ++ zarb-ml/mageia-dev/2011-June/005595.html | 246 ++ zarb-ml/mageia-dev/2011-June/005596.html | 250 ++ zarb-ml/mageia-dev/2011-June/005597.html | 248 ++ zarb-ml/mageia-dev/2011-June/005598.html | 271 ++ zarb-ml/mageia-dev/2011-June/005599.html | 254 ++ zarb-ml/mageia-dev/2011-June/005600.html | 253 ++ zarb-ml/mageia-dev/2011-June/005601.html | 272 ++ zarb-ml/mageia-dev/2011-June/005602.html | 248 ++ zarb-ml/mageia-dev/2011-June/005603.html | 273 ++ zarb-ml/mageia-dev/2011-June/005604.html | 255 ++ zarb-ml/mageia-dev/2011-June/005605.html | 224 + zarb-ml/mageia-dev/2011-June/005606.html | 229 + zarb-ml/mageia-dev/2011-June/005607.html | 239 ++ zarb-ml/mageia-dev/2011-June/005608.html | 217 + zarb-ml/mageia-dev/2011-June/005609.html | 200 + zarb-ml/mageia-dev/2011-June/005610.html | 206 + zarb-ml/mageia-dev/2011-June/005611.html | 262 ++ zarb-ml/mageia-dev/2011-June/005612.html | 206 + zarb-ml/mageia-dev/2011-June/005613.html | 220 + zarb-ml/mageia-dev/2011-June/005614.html | 217 + zarb-ml/mageia-dev/2011-June/005615.html | 221 + zarb-ml/mageia-dev/2011-June/005616.html | 190 + zarb-ml/mageia-dev/2011-June/005617.html | 202 + zarb-ml/mageia-dev/2011-June/005618.html | 217 + zarb-ml/mageia-dev/2011-June/005619.html | 202 + zarb-ml/mageia-dev/2011-June/005620.html | 225 + zarb-ml/mageia-dev/2011-June/005621.html | 172 + zarb-ml/mageia-dev/2011-June/005622.html | 241 ++ zarb-ml/mageia-dev/2011-June/005623.html | 303 ++ zarb-ml/mageia-dev/2011-June/005624.html | 208 + zarb-ml/mageia-dev/2011-June/005625.html | 212 + zarb-ml/mageia-dev/2011-June/005626.html | 219 + zarb-ml/mageia-dev/2011-June/005627.html | 266 ++ zarb-ml/mageia-dev/2011-June/005628.html | 163 + zarb-ml/mageia-dev/2011-June/005629.html | 182 + zarb-ml/mageia-dev/2011-June/005630.html | 197 + zarb-ml/mageia-dev/2011-June/005631.html | 155 + zarb-ml/mageia-dev/2011-June/005632.html | 156 + zarb-ml/mageia-dev/2011-June/005633.html | 128 + zarb-ml/mageia-dev/2011-June/005634.html | 246 ++ zarb-ml/mageia-dev/2011-June/005635.html | 253 ++ zarb-ml/mageia-dev/2011-June/005636.html | 191 + zarb-ml/mageia-dev/2011-June/005637.html | 275 ++ zarb-ml/mageia-dev/2011-June/005638.html | 274 ++ zarb-ml/mageia-dev/2011-June/005639.html | 256 ++ zarb-ml/mageia-dev/2011-June/005640.html | 199 + zarb-ml/mageia-dev/2011-June/005641.html | 257 ++ zarb-ml/mageia-dev/2011-June/005642.html | 191 + zarb-ml/mageia-dev/2011-June/005643.html | 192 + zarb-ml/mageia-dev/2011-June/005644.html | 189 + zarb-ml/mageia-dev/2011-June/005645.html | 207 + zarb-ml/mageia-dev/2011-June/005646.html | 152 + zarb-ml/mageia-dev/2011-June/005647.html | 175 + zarb-ml/mageia-dev/2011-June/005648.html | 170 + zarb-ml/mageia-dev/2011-June/005649.html | 163 + zarb-ml/mageia-dev/2011-June/005650.html | 253 ++ zarb-ml/mageia-dev/2011-June/005651.html | 145 + zarb-ml/mageia-dev/2011-June/005652.html | 175 + zarb-ml/mageia-dev/2011-June/005653.html | 183 + zarb-ml/mageia-dev/2011-June/005654.html | 203 + zarb-ml/mageia-dev/2011-June/005655.html | 152 + zarb-ml/mageia-dev/2011-June/005656.html | 122 + zarb-ml/mageia-dev/2011-June/005657.html | 202 + zarb-ml/mageia-dev/2011-June/005658.html | 172 + zarb-ml/mageia-dev/2011-June/005659.html | 217 + zarb-ml/mageia-dev/2011-June/005660.html | 215 + zarb-ml/mageia-dev/2011-June/005661.html | 161 + zarb-ml/mageia-dev/2011-June/005662.html | 195 + zarb-ml/mageia-dev/2011-June/005663.html | 147 + zarb-ml/mageia-dev/2011-June/005664.html | 179 + zarb-ml/mageia-dev/2011-June/005665.html | 91 + zarb-ml/mageia-dev/2011-June/005666.html | 135 + zarb-ml/mageia-dev/2011-June/005667.html | 166 + zarb-ml/mageia-dev/2011-June/005668.html | 83 + zarb-ml/mageia-dev/2011-June/005669.html | 194 + zarb-ml/mageia-dev/2011-June/005670.html | 159 + zarb-ml/mageia-dev/2011-June/005671.html | 77 + zarb-ml/mageia-dev/2011-June/005672.html | 160 + zarb-ml/mageia-dev/2011-June/005673.html | 237 ++ zarb-ml/mageia-dev/2011-June/005674.html | 233 ++ zarb-ml/mageia-dev/2011-June/005675.html | 236 ++ zarb-ml/mageia-dev/2011-June/005676.html | 243 ++ zarb-ml/mageia-dev/2011-June/005677.html | 83 + zarb-ml/mageia-dev/2011-June/005678.html | 177 + zarb-ml/mageia-dev/2011-June/005679.html | 85 + zarb-ml/mageia-dev/2011-June/005680.html | 143 + zarb-ml/mageia-dev/2011-June/005681.html | 141 + zarb-ml/mageia-dev/2011-June/005682.html | 218 + zarb-ml/mageia-dev/2011-June/005683.html | 91 + zarb-ml/mageia-dev/2011-June/005684.html | 197 + zarb-ml/mageia-dev/2011-June/005685.html | 207 + zarb-ml/mageia-dev/2011-June/005686.html | 214 + zarb-ml/mageia-dev/2011-June/005687.html | 240 ++ zarb-ml/mageia-dev/2011-June/005688.html | 106 + zarb-ml/mageia-dev/2011-June/005689.html | 231 + zarb-ml/mageia-dev/2011-June/005690.html | 113 + zarb-ml/mageia-dev/2011-June/005691.html | 220 + zarb-ml/mageia-dev/2011-June/005692.html | 118 + zarb-ml/mageia-dev/2011-June/005693.html | 196 + zarb-ml/mageia-dev/2011-June/005694.html | 130 + zarb-ml/mageia-dev/2011-June/005695.html | 82 + zarb-ml/mageia-dev/2011-June/005696.html | 88 + zarb-ml/mageia-dev/2011-June/005697.html | 93 + zarb-ml/mageia-dev/2011-June/005698.html | 84 + zarb-ml/mageia-dev/2011-June/005699.html | 199 + zarb-ml/mageia-dev/2011-June/005700.html | 94 + zarb-ml/mageia-dev/2011-June/005701.html | 92 + zarb-ml/mageia-dev/2011-June/005702.html | 103 + zarb-ml/mageia-dev/2011-June/005703.html | 153 + zarb-ml/mageia-dev/2011-June/005704.html | 108 + zarb-ml/mageia-dev/2011-June/005705.html | 211 + zarb-ml/mageia-dev/2011-June/005706.html | 213 + zarb-ml/mageia-dev/2011-June/005707.html | 62 + zarb-ml/mageia-dev/2011-June/005708.html | 190 + zarb-ml/mageia-dev/2011-June/005709.html | 69 + zarb-ml/mageia-dev/2011-June/005710.html | 194 + zarb-ml/mageia-dev/2011-June/005711.html | 201 + zarb-ml/mageia-dev/2011-June/005712.html | 154 + zarb-ml/mageia-dev/2011-June/005713.html | 201 + zarb-ml/mageia-dev/2011-June/005714.html | 201 + zarb-ml/mageia-dev/2011-June/005715.html | 196 + zarb-ml/mageia-dev/2011-June/005716.html | 200 + zarb-ml/mageia-dev/2011-June/005717.html | 195 + zarb-ml/mageia-dev/2011-June/005718.html | 218 + zarb-ml/mageia-dev/2011-June/005719.html | 238 ++ zarb-ml/mageia-dev/2011-June/005720.html | 218 + zarb-ml/mageia-dev/2011-June/005721.html | 220 + zarb-ml/mageia-dev/2011-June/005722.html | 71 + zarb-ml/mageia-dev/2011-June/005723.html | 249 ++ zarb-ml/mageia-dev/2011-June/005724.html | 224 + zarb-ml/mageia-dev/2011-June/005725.html | 190 + zarb-ml/mageia-dev/2011-June/005726.html | 195 + zarb-ml/mageia-dev/2011-June/005727.html | 186 + zarb-ml/mageia-dev/2011-June/005728.html | 186 + zarb-ml/mageia-dev/2011-June/005729.html | 209 + zarb-ml/mageia-dev/2011-June/005730.html | 94 + zarb-ml/mageia-dev/2011-June/005731.html | 180 + zarb-ml/mageia-dev/2011-June/005732.html | 186 + zarb-ml/mageia-dev/2011-June/005733.html | 219 + zarb-ml/mageia-dev/2011-June/005734.html | 236 ++ zarb-ml/mageia-dev/2011-June/005735.html | 144 + zarb-ml/mageia-dev/2011-June/005736.html | 73 + zarb-ml/mageia-dev/2011-June/005737.html | 153 + zarb-ml/mageia-dev/2011-June/005738.html | 223 + zarb-ml/mageia-dev/2011-June/005739.html | 228 + zarb-ml/mageia-dev/2011-June/005740.html | 79 + zarb-ml/mageia-dev/2011-June/005741.html | 231 + zarb-ml/mageia-dev/2011-June/005742.html | 211 + zarb-ml/mageia-dev/2011-June/005743.html | 68 + zarb-ml/mageia-dev/2011-June/005744.html | 71 + zarb-ml/mageia-dev/2011-June/005745.html | 204 + zarb-ml/mageia-dev/2011-June/005746.html | 72 + zarb-ml/mageia-dev/2011-June/005747.html | 81 + zarb-ml/mageia-dev/2011-June/005748.html | 87 + zarb-ml/mageia-dev/2011-June/005749.html | 96 + zarb-ml/mageia-dev/2011-June/005750.html | 102 + zarb-ml/mageia-dev/2011-June/005751.html | 76 + zarb-ml/mageia-dev/2011-June/005752.html | 90 + zarb-ml/mageia-dev/2011-June/005753.html | 130 + zarb-ml/mageia-dev/2011-June/005754.html | 176 + zarb-ml/mageia-dev/2011-June/005755.html | 89 + zarb-ml/mageia-dev/2011-June/005756.html | 80 + zarb-ml/mageia-dev/2011-June/005757.html | 183 + zarb-ml/mageia-dev/2011-June/005758.html | 72 + zarb-ml/mageia-dev/2011-June/005759.html | 76 + zarb-ml/mageia-dev/2011-June/005760.html | 176 + zarb-ml/mageia-dev/2011-June/005761.html | 81 + zarb-ml/mageia-dev/2011-June/005762.html | 178 + zarb-ml/mageia-dev/2011-June/005763.html | 188 + zarb-ml/mageia-dev/2011-June/005764.html | 167 + zarb-ml/mageia-dev/2011-June/005765.html | 188 + zarb-ml/mageia-dev/2011-June/005766.html | 97 + zarb-ml/mageia-dev/2011-June/005767.html | 92 + zarb-ml/mageia-dev/2011-June/005768.html | 140 + zarb-ml/mageia-dev/2011-June/005769.html | 70 + zarb-ml/mageia-dev/2011-June/005770.html | 68 + zarb-ml/mageia-dev/2011-June/005771.html | 169 + zarb-ml/mageia-dev/2011-June/005772.html | 68 + zarb-ml/mageia-dev/2011-June/005773.html | 165 + zarb-ml/mageia-dev/2011-June/005774.html | 160 + zarb-ml/mageia-dev/2011-June/005775.html | 79 + zarb-ml/mageia-dev/2011-June/005776.html | 167 + zarb-ml/mageia-dev/2011-June/005777.html | 76 + zarb-ml/mageia-dev/2011-June/005778.html | 176 + zarb-ml/mageia-dev/2011-June/005779.html | 138 + zarb-ml/mageia-dev/2011-June/005780.html | 182 + zarb-ml/mageia-dev/2011-June/005781.html | 207 + zarb-ml/mageia-dev/2011-June/005782.html | 196 + zarb-ml/mageia-dev/2011-June/005783.html | 69 + zarb-ml/mageia-dev/2011-June/005784.html | 75 + zarb-ml/mageia-dev/2011-June/005785.html | 115 + zarb-ml/mageia-dev/2011-June/005786.html | 75 + zarb-ml/mageia-dev/2011-June/005787.html | 80 + zarb-ml/mageia-dev/2011-June/005788.html | 189 + zarb-ml/mageia-dev/2011-June/005789.html | 82 + zarb-ml/mageia-dev/2011-June/005790.html | 162 + zarb-ml/mageia-dev/2011-June/005791.html | 175 + zarb-ml/mageia-dev/2011-June/005792.html | 187 + zarb-ml/mageia-dev/2011-June/005793.html | 161 + zarb-ml/mageia-dev/2011-June/005794.html | 113 + zarb-ml/mageia-dev/2011-June/005795.html | 159 + zarb-ml/mageia-dev/2011-June/005796.html | 103 + zarb-ml/mageia-dev/2011-June/005797.html | 152 + zarb-ml/mageia-dev/2011-June/005798.html | 150 + zarb-ml/mageia-dev/2011-June/005799.html | 189 + zarb-ml/mageia-dev/2011-June/005800.html | 165 + zarb-ml/mageia-dev/2011-June/005801.html | 132 + zarb-ml/mageia-dev/2011-June/005802.html | 113 + zarb-ml/mageia-dev/2011-June/005803.html | 152 + zarb-ml/mageia-dev/2011-June/005804.html | 145 + zarb-ml/mageia-dev/2011-June/005805.html | 142 + zarb-ml/mageia-dev/2011-June/005806.html | 133 + zarb-ml/mageia-dev/2011-June/005807.html | 126 + zarb-ml/mageia-dev/2011-June/005808.html | 112 + zarb-ml/mageia-dev/2011-June/005809.html | 159 + zarb-ml/mageia-dev/2011-June/005810.html | 84 + zarb-ml/mageia-dev/2011-June/005811.html | 88 + zarb-ml/mageia-dev/2011-June/005812.html | 105 + zarb-ml/mageia-dev/2011-June/005813.html | 117 + zarb-ml/mageia-dev/2011-June/005814.html | 110 + zarb-ml/mageia-dev/2011-June/005815.html | 103 + zarb-ml/mageia-dev/2011-June/005816.html | 100 + zarb-ml/mageia-dev/2011-June/005817.html | 106 + zarb-ml/mageia-dev/2011-June/005818.html | 115 + zarb-ml/mageia-dev/2011-June/005819.html | 182 + zarb-ml/mageia-dev/2011-June/005820.html | 216 + zarb-ml/mageia-dev/2011-June/005821.html | 110 + zarb-ml/mageia-dev/2011-June/005822.html | 121 + zarb-ml/mageia-dev/2011-June/005823.html | 119 + zarb-ml/mageia-dev/2011-June/005824.html | 221 + zarb-ml/mageia-dev/2011-June/005825.html | 107 + zarb-ml/mageia-dev/2011-June/005826.html | 64 + zarb-ml/mageia-dev/2011-June/005827.html | 83 + zarb-ml/mageia-dev/2011-June/005828.html | 196 + zarb-ml/mageia-dev/2011-June/005829.html | 112 + zarb-ml/mageia-dev/2011-June/005830.html | 100 + zarb-ml/mageia-dev/2011-June/005831.html | 87 + zarb-ml/mageia-dev/2011-June/005832.html | 283 ++ zarb-ml/mageia-dev/2011-June/005833.html | 132 + zarb-ml/mageia-dev/2011-June/005834.html | 88 + zarb-ml/mageia-dev/2011-June/005835.html | 102 + zarb-ml/mageia-dev/2011-June/005836.html | 127 + zarb-ml/mageia-dev/2011-June/005837.html | 86 + zarb-ml/mageia-dev/2011-June/005838.html | 91 + zarb-ml/mageia-dev/2011-June/005839.html | 93 + zarb-ml/mageia-dev/2011-June/005840.html | 290 ++ zarb-ml/mageia-dev/2011-June/005841.html | 91 + zarb-ml/mageia-dev/2011-June/005842.html | 76 + zarb-ml/mageia-dev/2011-June/005843.html | 66 + zarb-ml/mageia-dev/2011-June/005844.html | 149 + zarb-ml/mageia-dev/2011-June/005845.html | 104 + zarb-ml/mageia-dev/2011-June/005846.html | 98 + zarb-ml/mageia-dev/2011-June/005847.html | 244 ++ zarb-ml/mageia-dev/2011-June/005848.html | 102 + zarb-ml/mageia-dev/2011-June/005849.html | 108 + zarb-ml/mageia-dev/2011-June/005850.html | 112 + zarb-ml/mageia-dev/2011-June/005851.html | 110 + zarb-ml/mageia-dev/2011-June/005852.html | 98 + zarb-ml/mageia-dev/2011-June/005853.html | 102 + zarb-ml/mageia-dev/2011-June/005854.html | 106 + zarb-ml/mageia-dev/2011-June/005855.html | 102 + zarb-ml/mageia-dev/2011-June/005856.html | 111 + zarb-ml/mageia-dev/2011-June/005857.html | 104 + zarb-ml/mageia-dev/2011-June/005858.html | 118 + zarb-ml/mageia-dev/2011-June/005859.html | 111 + zarb-ml/mageia-dev/2011-June/005860.html | 116 + zarb-ml/mageia-dev/2011-June/005861.html | 137 + zarb-ml/mageia-dev/2011-June/005862.html | 126 + zarb-ml/mageia-dev/2011-June/005863.html | 118 + zarb-ml/mageia-dev/2011-June/005864.html | 323 ++ zarb-ml/mageia-dev/2011-June/005865.html | 99 + zarb-ml/mageia-dev/2011-June/005866.html | 102 + zarb-ml/mageia-dev/2011-June/005867.html | 99 + zarb-ml/mageia-dev/2011-June/005868.html | 101 + zarb-ml/mageia-dev/2011-June/005869.html | 98 + zarb-ml/mageia-dev/2011-June/005870.html | 97 + zarb-ml/mageia-dev/2011-June/005871.html | 100 + zarb-ml/mageia-dev/2011-June/005872.html | 101 + zarb-ml/mageia-dev/2011-June/005873.html | 117 + zarb-ml/mageia-dev/2011-June/005874.html | 137 + zarb-ml/mageia-dev/2011-June/005875.html | 90 + zarb-ml/mageia-dev/2011-June/005876.html | 99 + zarb-ml/mageia-dev/2011-June/005877.html | 113 + zarb-ml/mageia-dev/2011-June/005878.html | 102 + zarb-ml/mageia-dev/2011-June/005879.html | 137 + zarb-ml/mageia-dev/2011-June/005880.html | 93 + zarb-ml/mageia-dev/2011-June/005881.html | 113 + zarb-ml/mageia-dev/2011-June/005882.html | 67 + zarb-ml/mageia-dev/2011-June/005883.html | 92 + zarb-ml/mageia-dev/2011-June/005884.html | 92 + zarb-ml/mageia-dev/2011-June/005885.html | 103 + zarb-ml/mageia-dev/2011-June/005886.html | 97 + zarb-ml/mageia-dev/2011-June/005887.html | 96 + zarb-ml/mageia-dev/2011-June/005888.html | 100 + zarb-ml/mageia-dev/2011-June/005889.html | 98 + zarb-ml/mageia-dev/2011-June/005890.html | 109 + zarb-ml/mageia-dev/2011-June/005891.html | 125 + zarb-ml/mageia-dev/2011-June/005892.html | 63 + zarb-ml/mageia-dev/2011-June/005893.html | 96 + zarb-ml/mageia-dev/2011-June/005894.html | 115 + zarb-ml/mageia-dev/2011-June/005895.html | 113 + zarb-ml/mageia-dev/2011-June/005896.html | 113 + zarb-ml/mageia-dev/2011-June/005897.html | 114 + zarb-ml/mageia-dev/2011-June/005898.html | 103 + zarb-ml/mageia-dev/2011-June/005899.html | 117 + zarb-ml/mageia-dev/2011-June/005900.html | 134 + zarb-ml/mageia-dev/2011-June/005901.html | 70 + zarb-ml/mageia-dev/2011-June/005902.html | 103 + zarb-ml/mageia-dev/2011-June/005903.html | 101 + zarb-ml/mageia-dev/2011-June/005904.html | 105 + zarb-ml/mageia-dev/2011-June/005905.html | 172 + zarb-ml/mageia-dev/2011-June/005906.html | 130 + zarb-ml/mageia-dev/2011-June/005907.html | 116 + zarb-ml/mageia-dev/2011-June/005908.html | 136 + zarb-ml/mageia-dev/2011-June/005909.html | 113 + zarb-ml/mageia-dev/2011-June/005910.html | 102 + zarb-ml/mageia-dev/2011-June/005911.html | 99 + zarb-ml/mageia-dev/2011-June/005912.html | 123 + zarb-ml/mageia-dev/2011-June/005913.html | 99 + zarb-ml/mageia-dev/2011-June/005914.html | 104 + zarb-ml/mageia-dev/2011-June/005915.html | 127 + zarb-ml/mageia-dev/2011-June/005916.html | 102 + zarb-ml/mageia-dev/2011-June/005917.html | 92 + zarb-ml/mageia-dev/2011-June/005918.html | 101 + zarb-ml/mageia-dev/2011-June/005919.html | 82 + zarb-ml/mageia-dev/2011-June/005920.html | 143 + zarb-ml/mageia-dev/2011-June/005921.html | 123 + zarb-ml/mageia-dev/2011-June/005922.html | 105 + zarb-ml/mageia-dev/2011-June/005923.html | 105 + zarb-ml/mageia-dev/2011-June/005924.html | 155 + zarb-ml/mageia-dev/2011-June/005925.html | 114 + zarb-ml/mageia-dev/2011-June/005926.html | 116 + zarb-ml/mageia-dev/2011-June/005927.html | 118 + zarb-ml/mageia-dev/2011-June/005928.html | 70 + zarb-ml/mageia-dev/2011-June/005929.html | 104 + zarb-ml/mageia-dev/2011-June/005930.html | 118 + zarb-ml/mageia-dev/2011-June/005931.html | 117 + zarb-ml/mageia-dev/2011-June/005932.html | 95 + zarb-ml/mageia-dev/2011-June/005933.html | 105 + zarb-ml/mageia-dev/2011-June/005934.html | 131 + zarb-ml/mageia-dev/2011-June/005935.html | 148 + zarb-ml/mageia-dev/2011-June/005936.html | 102 + zarb-ml/mageia-dev/2011-June/005937.html | 121 + zarb-ml/mageia-dev/2011-June/005938.html | 97 + zarb-ml/mageia-dev/2011-June/005939.html | 92 + zarb-ml/mageia-dev/2011-June/005940.html | 101 + zarb-ml/mageia-dev/2011-June/005941.html | 120 + zarb-ml/mageia-dev/2011-June/005942.html | 151 + zarb-ml/mageia-dev/2011-June/005943.html | 126 + zarb-ml/mageia-dev/2011-June/005944.html | 117 + zarb-ml/mageia-dev/2011-June/005945.html | 95 + zarb-ml/mageia-dev/2011-June/005946.html | 144 + zarb-ml/mageia-dev/2011-June/005947.html | 113 + zarb-ml/mageia-dev/2011-June/005948.html | 124 + zarb-ml/mageia-dev/2011-June/005949.html | 95 + zarb-ml/mageia-dev/2011-June/005950.html | 393 ++ zarb-ml/mageia-dev/2011-June/005951.html | 106 + zarb-ml/mageia-dev/2011-June/005952.html | 94 + zarb-ml/mageia-dev/2011-June/005953.html | 88 + zarb-ml/mageia-dev/2011-June/005954.html | 96 + zarb-ml/mageia-dev/2011-June/005955.html | 83 + zarb-ml/mageia-dev/2011-June/005956.html | 80 + zarb-ml/mageia-dev/2011-June/005957.html | 83 + zarb-ml/mageia-dev/2011-June/005958.html | 97 + zarb-ml/mageia-dev/2011-June/005959.html | 94 + zarb-ml/mageia-dev/2011-June/005960.html | 80 + zarb-ml/mageia-dev/2011-June/005961.html | 107 + zarb-ml/mageia-dev/2011-June/005962.html | 125 + zarb-ml/mageia-dev/2011-June/005963.html | 107 + zarb-ml/mageia-dev/2011-June/005964.html | 115 + zarb-ml/mageia-dev/2011-June/005965.html | 95 + zarb-ml/mageia-dev/2011-June/005966.html | 99 + zarb-ml/mageia-dev/2011-June/005967.html | 99 + zarb-ml/mageia-dev/2011-June/005968.html | 87 + zarb-ml/mageia-dev/2011-June/005969.html | 101 + zarb-ml/mageia-dev/2011-June/005970.html | 109 + zarb-ml/mageia-dev/2011-June/005971.html | 134 + zarb-ml/mageia-dev/2011-June/005972.html | 107 + zarb-ml/mageia-dev/2011-June/005973.html | 66 + zarb-ml/mageia-dev/2011-June/005974.html | 77 + zarb-ml/mageia-dev/2011-June/005975.html | 157 + zarb-ml/mageia-dev/2011-June/005976.html | 126 + zarb-ml/mageia-dev/2011-June/005977.html | 190 + zarb-ml/mageia-dev/2011-June/005978.html | 195 + zarb-ml/mageia-dev/2011-June/005979.html | 94 + zarb-ml/mageia-dev/2011-June/005980.html | 89 + zarb-ml/mageia-dev/2011-June/005981.html | 108 + zarb-ml/mageia-dev/2011-June/005982.html | 161 + zarb-ml/mageia-dev/2011-June/005983.html | 119 + zarb-ml/mageia-dev/2011-June/005984.html | 168 + zarb-ml/mageia-dev/2011-June/005985.html | 157 + zarb-ml/mageia-dev/2011-June/005986.html | 183 + zarb-ml/mageia-dev/2011-June/005987.html | 178 + zarb-ml/mageia-dev/2011-June/005988.html | 90 + zarb-ml/mageia-dev/2011-June/005989.html | 129 + zarb-ml/mageia-dev/2011-June/005990.html | 146 + zarb-ml/mageia-dev/2011-June/005991.html | 172 + zarb-ml/mageia-dev/2011-June/005992.html | 196 + zarb-ml/mageia-dev/2011-June/005993.html | 102 + zarb-ml/mageia-dev/2011-June/005994.html | 124 + zarb-ml/mageia-dev/2011-June/005995.html | 115 + zarb-ml/mageia-dev/2011-June/005996.html | 177 + zarb-ml/mageia-dev/2011-June/005997.html | 102 + zarb-ml/mageia-dev/2011-June/005998.html | 165 + zarb-ml/mageia-dev/2011-June/005999.html | 132 + zarb-ml/mageia-dev/2011-June/006000.html | 186 + zarb-ml/mageia-dev/2011-June/006001.html | 111 + zarb-ml/mageia-dev/2011-June/006002.html | 162 + zarb-ml/mageia-dev/2011-June/006003.html | 179 + zarb-ml/mageia-dev/2011-June/006004.html | 120 + zarb-ml/mageia-dev/2011-June/006005.html | 122 + zarb-ml/mageia-dev/2011-June/006006.html | 105 + zarb-ml/mageia-dev/2011-June/006007.html | 103 + zarb-ml/mageia-dev/2011-June/006008.html | 115 + zarb-ml/mageia-dev/2011-June/006009.html | 135 + zarb-ml/mageia-dev/2011-June/006010.html | 168 + zarb-ml/mageia-dev/2011-June/006011.html | 77 + zarb-ml/mageia-dev/2011-June/006012.html | 117 + zarb-ml/mageia-dev/2011-June/006013.html | 205 + zarb-ml/mageia-dev/2011-June/006014.html | 199 + zarb-ml/mageia-dev/2011-June/006015.html | 231 + zarb-ml/mageia-dev/2011-June/006016.html | 116 + zarb-ml/mageia-dev/2011-June/006017.html | 76 + zarb-ml/mageia-dev/2011-June/006018.html | 122 + zarb-ml/mageia-dev/2011-June/006019.html | 122 + zarb-ml/mageia-dev/2011-June/006020.html | 139 + zarb-ml/mageia-dev/2011-June/006021.html | 101 + zarb-ml/mageia-dev/2011-June/006022.html | 169 + zarb-ml/mageia-dev/2011-June/006023.html | 127 + zarb-ml/mageia-dev/2011-June/006024.html | 114 + zarb-ml/mageia-dev/2011-June/006025.html | 133 + zarb-ml/mageia-dev/2011-June/006026.html | 79 + zarb-ml/mageia-dev/2011-June/006027.html | 147 + zarb-ml/mageia-dev/2011-June/006028.html | 78 + zarb-ml/mageia-dev/2011-June/006029.html | 88 + zarb-ml/mageia-dev/2011-June/006030.html | 126 + zarb-ml/mageia-dev/2011-June/006031.html | 143 + zarb-ml/mageia-dev/2011-June/006032.html | 91 + zarb-ml/mageia-dev/2011-June/006033.html | 72 + zarb-ml/mageia-dev/2011-June/006034.html | 108 + zarb-ml/mageia-dev/2011-June/006035.html | 76 + zarb-ml/mageia-dev/2011-June/006036.html | 223 + zarb-ml/mageia-dev/2011-June/006037.html | 117 + zarb-ml/mageia-dev/2011-June/006038.html | 122 + zarb-ml/mageia-dev/2011-June/006039.html | 134 + zarb-ml/mageia-dev/2011-June/006040.html | 90 + zarb-ml/mageia-dev/2011-June/006041.html | 139 + zarb-ml/mageia-dev/2011-June/006042.html | 158 + zarb-ml/mageia-dev/2011-June/006043.html | 99 + zarb-ml/mageia-dev/2011-June/006044.html | 103 + zarb-ml/mageia-dev/2011-June/006045.html | 96 + zarb-ml/mageia-dev/2011-June/006046.html | 104 + zarb-ml/mageia-dev/2011-June/006047.html | 117 + zarb-ml/mageia-dev/2011-June/006048.html | 121 + zarb-ml/mageia-dev/2011-June/006049.html | 97 + zarb-ml/mageia-dev/2011-June/006050.html | 97 + zarb-ml/mageia-dev/2011-June/006051.html | 97 + zarb-ml/mageia-dev/2011-June/006052.html | 97 + zarb-ml/mageia-dev/2011-June/006053.html | 103 + zarb-ml/mageia-dev/2011-June/006054.html | 64 + zarb-ml/mageia-dev/2011-June/006055.html | 99 + zarb-ml/mageia-dev/2011-June/006056.html | 103 + zarb-ml/mageia-dev/2011-June/006057.html | 110 + zarb-ml/mageia-dev/2011-June/006058.html | 100 + zarb-ml/mageia-dev/2011-June/006059.html | 112 + zarb-ml/mageia-dev/2011-June/006060.html | 118 + zarb-ml/mageia-dev/2011-June/006061.html | 134 + zarb-ml/mageia-dev/2011-June/006062.html | 101 + zarb-ml/mageia-dev/2011-June/006063.html | 92 + zarb-ml/mageia-dev/2011-June/006064.html | 111 + zarb-ml/mageia-dev/2011-June/006065.html | 109 + zarb-ml/mageia-dev/2011-June/006066.html | 116 + zarb-ml/mageia-dev/2011-June/006067.html | 108 + zarb-ml/mageia-dev/2011-June/006068.html | 129 + zarb-ml/mageia-dev/2011-June/006069.html | 107 + zarb-ml/mageia-dev/2011-June/006070.html | 104 + zarb-ml/mageia-dev/2011-June/006071.html | 94 + zarb-ml/mageia-dev/2011-June/006072.html | 86 + zarb-ml/mageia-dev/2011-June/006073.html | 97 + zarb-ml/mageia-dev/2011-June/006074.html | 136 + zarb-ml/mageia-dev/2011-June/006075.html | 135 + zarb-ml/mageia-dev/2011-June/006076.html | 173 + zarb-ml/mageia-dev/2011-June/006077.html | 96 + zarb-ml/mageia-dev/2011-June/006078.html | 91 + zarb-ml/mageia-dev/2011-June/006079.html | 96 + zarb-ml/mageia-dev/2011-June/006080.html | 102 + zarb-ml/mageia-dev/2011-June/006081.html | 111 + zarb-ml/mageia-dev/2011-June/006082.html | 88 + zarb-ml/mageia-dev/2011-June/006083.html | 124 + zarb-ml/mageia-dev/2011-June/006084.html | 120 + zarb-ml/mageia-dev/2011-June/006085.html | 108 + zarb-ml/mageia-dev/2011-June/006086.html | 122 + zarb-ml/mageia-dev/2011-June/006087.html | 124 + zarb-ml/mageia-dev/2011-June/006088.html | 94 + zarb-ml/mageia-dev/2011-June/006089.html | 97 + zarb-ml/mageia-dev/2011-June/006090.html | 109 + zarb-ml/mageia-dev/2011-June/006091.html | 90 + zarb-ml/mageia-dev/2011-June/006092.html | 106 + zarb-ml/mageia-dev/2011-June/006093.html | 119 + zarb-ml/mageia-dev/2011-June/006094.html | 130 + zarb-ml/mageia-dev/2011-June/006095.html | 132 + zarb-ml/mageia-dev/2011-June/006096.html | 97 + zarb-ml/mageia-dev/2011-June/006097.html | 114 + zarb-ml/mageia-dev/2011-June/006098.html | 99 + zarb-ml/mageia-dev/2011-June/006099.html | 85 + zarb-ml/mageia-dev/2011-June/006100.html | 147 + zarb-ml/mageia-dev/2011-June/006101.html | 108 + zarb-ml/mageia-dev/2011-June/006102.html | 129 + zarb-ml/mageia-dev/2011-June/006103.html | 97 + zarb-ml/mageia-dev/2011-June/006104.html | 86 + zarb-ml/mageia-dev/2011-June/006105.html | 92 + zarb-ml/mageia-dev/2011-June/006106.html | 96 + zarb-ml/mageia-dev/2011-June/006107.html | 115 + zarb-ml/mageia-dev/2011-June/006108.html | 120 + zarb-ml/mageia-dev/2011-June/006109.html | 87 + zarb-ml/mageia-dev/2011-June/006110.html | 121 + zarb-ml/mageia-dev/2011-June/006111.html | 91 + zarb-ml/mageia-dev/2011-June/006112.html | 107 + zarb-ml/mageia-dev/2011-June/006113.html | 104 + zarb-ml/mageia-dev/2011-June/006114.html | 81 + zarb-ml/mageia-dev/2011-June/006115.html | 87 + zarb-ml/mageia-dev/2011-June/006116.html | 92 + zarb-ml/mageia-dev/2011-June/006117.html | 99 + zarb-ml/mageia-dev/2011-June/006118.html | 122 + zarb-ml/mageia-dev/2011-June/006119.html | 140 + zarb-ml/mageia-dev/2011-June/006120.html | 155 + zarb-ml/mageia-dev/2011-June/006121.html | 109 + zarb-ml/mageia-dev/2011-June/006122.html | 83 + zarb-ml/mageia-dev/2011-June/006123.html | 85 + zarb-ml/mageia-dev/2011-June/006124.html | 90 + zarb-ml/mageia-dev/2011-June/006125.html | 98 + zarb-ml/mageia-dev/2011-June/006126.html | 89 + zarb-ml/mageia-dev/2011-June/006127.html | 102 + zarb-ml/mageia-dev/2011-June/006128.html | 95 + zarb-ml/mageia-dev/2011-June/006129.html | 112 + zarb-ml/mageia-dev/2011-June/006130.html | 98 + zarb-ml/mageia-dev/2011-June/006131.html | 131 + zarb-ml/mageia-dev/2011-June/006132.html | 104 + zarb-ml/mageia-dev/2011-June/006133.html | 99 + zarb-ml/mageia-dev/2011-June/006134.html | 108 + zarb-ml/mageia-dev/2011-June/006135.html | 87 + zarb-ml/mageia-dev/2011-June/006136.html | 77 + zarb-ml/mageia-dev/2011-June/006137.html | 103 + zarb-ml/mageia-dev/2011-June/006138.html | 78 + zarb-ml/mageia-dev/2011-June/006139.html | 80 + zarb-ml/mageia-dev/2011-June/006140.html | 110 + zarb-ml/mageia-dev/2011-June/006141.html | 116 + zarb-ml/mageia-dev/2011-June/006142.html | 109 + zarb-ml/mageia-dev/2011-June/006143.html | 79 + zarb-ml/mageia-dev/2011-June/006144.html | 79 + zarb-ml/mageia-dev/2011-June/006145.html | 201 + zarb-ml/mageia-dev/2011-June/006146.html | 80 + zarb-ml/mageia-dev/2011-June/006147.html | 87 + zarb-ml/mageia-dev/2011-June/006148.html | 73 + zarb-ml/mageia-dev/2011-June/006149.html | 80 + zarb-ml/mageia-dev/2011-June/006150.html | 81 + zarb-ml/mageia-dev/2011-June/006151.html | 150 + zarb-ml/mageia-dev/2011-June/006152.html | 101 + zarb-ml/mageia-dev/2011-June/006153.html | 97 + zarb-ml/mageia-dev/2011-June/006154.html | 102 + zarb-ml/mageia-dev/2011-June/006155.html | 74 + zarb-ml/mageia-dev/2011-June/006156.html | 117 + zarb-ml/mageia-dev/2011-June/006157.html | 90 + zarb-ml/mageia-dev/2011-June/006158.html | 95 + zarb-ml/mageia-dev/2011-June/006159.html | 95 + zarb-ml/mageia-dev/2011-June/006160.html | 71 + zarb-ml/mageia-dev/2011-June/006161.html | 75 + zarb-ml/mageia-dev/2011-June/006162.html | 81 + zarb-ml/mageia-dev/2011-June/006163.html | 205 + zarb-ml/mageia-dev/2011-June/006164.html | 77 + zarb-ml/mageia-dev/2011-June/006165.html | 77 + zarb-ml/mageia-dev/2011-June/006166.html | 82 + zarb-ml/mageia-dev/2011-June/006167.html | 100 + zarb-ml/mageia-dev/2011-June/006168.html | 95 + zarb-ml/mageia-dev/2011-June/006169.html | 105 + zarb-ml/mageia-dev/2011-June/006170.html | 62 + zarb-ml/mageia-dev/2011-June/006171.html | 85 + zarb-ml/mageia-dev/2011-June/006172.html | 86 + zarb-ml/mageia-dev/2011-June/006173.html | 80 + zarb-ml/mageia-dev/2011-June/006174.html | 121 + zarb-ml/mageia-dev/2011-June/author.html | 4932 ++++++++++++++++++++++ zarb-ml/mageia-dev/2011-June/date.html | 4932 ++++++++++++++++++++++ zarb-ml/mageia-dev/2011-June/index.html | 1 + zarb-ml/mageia-dev/2011-June/subject.html | 4932 ++++++++++++++++++++++ zarb-ml/mageia-dev/2011-June/thread.html | 6519 +++++++++++++++++++++++++++++ 983 files changed, 173404 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-June/005197.html create mode 100644 zarb-ml/mageia-dev/2011-June/005198.html create mode 100644 zarb-ml/mageia-dev/2011-June/005199.html create mode 100644 zarb-ml/mageia-dev/2011-June/005200.html create mode 100644 zarb-ml/mageia-dev/2011-June/005201.html create mode 100644 zarb-ml/mageia-dev/2011-June/005202.html create mode 100644 zarb-ml/mageia-dev/2011-June/005203.html create mode 100644 zarb-ml/mageia-dev/2011-June/005204.html create mode 100644 zarb-ml/mageia-dev/2011-June/005205.html create mode 100644 zarb-ml/mageia-dev/2011-June/005206.html create mode 100644 zarb-ml/mageia-dev/2011-June/005207.html create mode 100644 zarb-ml/mageia-dev/2011-June/005208.html create mode 100644 zarb-ml/mageia-dev/2011-June/005209.html create mode 100644 zarb-ml/mageia-dev/2011-June/005210.html create mode 100644 zarb-ml/mageia-dev/2011-June/005211.html create mode 100644 zarb-ml/mageia-dev/2011-June/005212.html create mode 100644 zarb-ml/mageia-dev/2011-June/005213.html create mode 100644 zarb-ml/mageia-dev/2011-June/005214.html create mode 100644 zarb-ml/mageia-dev/2011-June/005215.html create mode 100644 zarb-ml/mageia-dev/2011-June/005216.html create mode 100644 zarb-ml/mageia-dev/2011-June/005217.html create mode 100644 zarb-ml/mageia-dev/2011-June/005218.html create mode 100644 zarb-ml/mageia-dev/2011-June/005219.html create mode 100644 zarb-ml/mageia-dev/2011-June/005220.html create mode 100644 zarb-ml/mageia-dev/2011-June/005221.html create mode 100644 zarb-ml/mageia-dev/2011-June/005222.html create mode 100644 zarb-ml/mageia-dev/2011-June/005223.html create mode 100644 zarb-ml/mageia-dev/2011-June/005224.html create mode 100644 zarb-ml/mageia-dev/2011-June/005225.html create mode 100644 zarb-ml/mageia-dev/2011-June/005226.html create mode 100644 zarb-ml/mageia-dev/2011-June/005227.html create mode 100644 zarb-ml/mageia-dev/2011-June/005228.html create mode 100644 zarb-ml/mageia-dev/2011-June/005229.html create mode 100644 zarb-ml/mageia-dev/2011-June/005230.html create mode 100644 zarb-ml/mageia-dev/2011-June/005231.html create mode 100644 zarb-ml/mageia-dev/2011-June/005232.html create mode 100644 zarb-ml/mageia-dev/2011-June/005233.html create mode 100644 zarb-ml/mageia-dev/2011-June/005234.html create mode 100644 zarb-ml/mageia-dev/2011-June/005235.html create mode 100644 zarb-ml/mageia-dev/2011-June/005236.html create mode 100644 zarb-ml/mageia-dev/2011-June/005237.html create mode 100644 zarb-ml/mageia-dev/2011-June/005238.html create mode 100644 zarb-ml/mageia-dev/2011-June/005239.html create mode 100644 zarb-ml/mageia-dev/2011-June/005240.html create mode 100644 zarb-ml/mageia-dev/2011-June/005241.html create mode 100644 zarb-ml/mageia-dev/2011-June/005242.html create mode 100644 zarb-ml/mageia-dev/2011-June/005243.html create mode 100644 zarb-ml/mageia-dev/2011-June/005244.html create mode 100644 zarb-ml/mageia-dev/2011-June/005245.html create mode 100644 zarb-ml/mageia-dev/2011-June/005246.html create mode 100644 zarb-ml/mageia-dev/2011-June/005247.html create mode 100644 zarb-ml/mageia-dev/2011-June/005248.html create mode 100644 zarb-ml/mageia-dev/2011-June/005249.html create mode 100644 zarb-ml/mageia-dev/2011-June/005250.html create mode 100644 zarb-ml/mageia-dev/2011-June/005251.html create mode 100644 zarb-ml/mageia-dev/2011-June/005252.html create mode 100644 zarb-ml/mageia-dev/2011-June/005253.html create mode 100644 zarb-ml/mageia-dev/2011-June/005254.html create mode 100644 zarb-ml/mageia-dev/2011-June/005255.html create mode 100644 zarb-ml/mageia-dev/2011-June/005256.html create mode 100644 zarb-ml/mageia-dev/2011-June/005257.html create mode 100644 zarb-ml/mageia-dev/2011-June/005258.html create mode 100644 zarb-ml/mageia-dev/2011-June/005259.html create mode 100644 zarb-ml/mageia-dev/2011-June/005260.html create mode 100644 zarb-ml/mageia-dev/2011-June/005261.html create mode 100644 zarb-ml/mageia-dev/2011-June/005262.html create mode 100644 zarb-ml/mageia-dev/2011-June/005263.html create mode 100644 zarb-ml/mageia-dev/2011-June/005264.html create mode 100644 zarb-ml/mageia-dev/2011-June/005265.html create mode 100644 zarb-ml/mageia-dev/2011-June/005266.html create mode 100644 zarb-ml/mageia-dev/2011-June/005267.html create mode 100644 zarb-ml/mageia-dev/2011-June/005268.html create mode 100644 zarb-ml/mageia-dev/2011-June/005269.html create mode 100644 zarb-ml/mageia-dev/2011-June/005270.html create mode 100644 zarb-ml/mageia-dev/2011-June/005271.html create mode 100644 zarb-ml/mageia-dev/2011-June/005272.html create mode 100644 zarb-ml/mageia-dev/2011-June/005273.html create mode 100644 zarb-ml/mageia-dev/2011-June/005274.html create mode 100644 zarb-ml/mageia-dev/2011-June/005275.html create mode 100644 zarb-ml/mageia-dev/2011-June/005276.html create mode 100644 zarb-ml/mageia-dev/2011-June/005277.html create mode 100644 zarb-ml/mageia-dev/2011-June/005278.html create mode 100644 zarb-ml/mageia-dev/2011-June/005279.html create mode 100644 zarb-ml/mageia-dev/2011-June/005280.html create mode 100644 zarb-ml/mageia-dev/2011-June/005281.html create mode 100644 zarb-ml/mageia-dev/2011-June/005282.html create mode 100644 zarb-ml/mageia-dev/2011-June/005283.html create mode 100644 zarb-ml/mageia-dev/2011-June/005284.html create mode 100644 zarb-ml/mageia-dev/2011-June/005285.html create mode 100644 zarb-ml/mageia-dev/2011-June/005286.html create mode 100644 zarb-ml/mageia-dev/2011-June/005287.html create mode 100644 zarb-ml/mageia-dev/2011-June/005288.html create mode 100644 zarb-ml/mageia-dev/2011-June/005289.html create mode 100644 zarb-ml/mageia-dev/2011-June/005290.html create mode 100644 zarb-ml/mageia-dev/2011-June/005291.html create mode 100644 zarb-ml/mageia-dev/2011-June/005292.html create mode 100644 zarb-ml/mageia-dev/2011-June/005293.html create mode 100644 zarb-ml/mageia-dev/2011-June/005294.html create mode 100644 zarb-ml/mageia-dev/2011-June/005295.html create mode 100644 zarb-ml/mageia-dev/2011-June/005296.html create mode 100644 zarb-ml/mageia-dev/2011-June/005297.html create mode 100644 zarb-ml/mageia-dev/2011-June/005298.html create mode 100644 zarb-ml/mageia-dev/2011-June/005299.html create mode 100644 zarb-ml/mageia-dev/2011-June/005300.html create mode 100644 zarb-ml/mageia-dev/2011-June/005301.html create mode 100644 zarb-ml/mageia-dev/2011-June/005302.html create mode 100644 zarb-ml/mageia-dev/2011-June/005303.html create mode 100644 zarb-ml/mageia-dev/2011-June/005304.html create mode 100644 zarb-ml/mageia-dev/2011-June/005305.html create mode 100644 zarb-ml/mageia-dev/2011-June/005306.html create mode 100644 zarb-ml/mageia-dev/2011-June/005307.html create mode 100644 zarb-ml/mageia-dev/2011-June/005308.html create mode 100644 zarb-ml/mageia-dev/2011-June/005309.html create mode 100644 zarb-ml/mageia-dev/2011-June/005310.html create mode 100644 zarb-ml/mageia-dev/2011-June/005311.html create mode 100644 zarb-ml/mageia-dev/2011-June/005312.html create mode 100644 zarb-ml/mageia-dev/2011-June/005313.html create mode 100644 zarb-ml/mageia-dev/2011-June/005314.html create mode 100644 zarb-ml/mageia-dev/2011-June/005315.html create mode 100644 zarb-ml/mageia-dev/2011-June/005316.html create mode 100644 zarb-ml/mageia-dev/2011-June/005317.html create mode 100644 zarb-ml/mageia-dev/2011-June/005318.html create mode 100644 zarb-ml/mageia-dev/2011-June/005319.html create mode 100644 zarb-ml/mageia-dev/2011-June/005320.html create mode 100644 zarb-ml/mageia-dev/2011-June/005321.html create mode 100644 zarb-ml/mageia-dev/2011-June/005322.html create mode 100644 zarb-ml/mageia-dev/2011-June/005323.html create mode 100644 zarb-ml/mageia-dev/2011-June/005324.html create mode 100644 zarb-ml/mageia-dev/2011-June/005325.html create mode 100644 zarb-ml/mageia-dev/2011-June/005326.html create mode 100644 zarb-ml/mageia-dev/2011-June/005327.html create mode 100644 zarb-ml/mageia-dev/2011-June/005328.html create mode 100644 zarb-ml/mageia-dev/2011-June/005329.html create mode 100644 zarb-ml/mageia-dev/2011-June/005330.html create mode 100644 zarb-ml/mageia-dev/2011-June/005331.html create mode 100644 zarb-ml/mageia-dev/2011-June/005332.html create mode 100644 zarb-ml/mageia-dev/2011-June/005333.html create mode 100644 zarb-ml/mageia-dev/2011-June/005334.html create mode 100644 zarb-ml/mageia-dev/2011-June/005335.html create mode 100644 zarb-ml/mageia-dev/2011-June/005336.html create mode 100644 zarb-ml/mageia-dev/2011-June/005337.html create mode 100644 zarb-ml/mageia-dev/2011-June/005338.html create mode 100644 zarb-ml/mageia-dev/2011-June/005339.html create mode 100644 zarb-ml/mageia-dev/2011-June/005340.html create mode 100644 zarb-ml/mageia-dev/2011-June/005341.html create mode 100644 zarb-ml/mageia-dev/2011-June/005342.html create mode 100644 zarb-ml/mageia-dev/2011-June/005343.html create mode 100644 zarb-ml/mageia-dev/2011-June/005344.html create mode 100644 zarb-ml/mageia-dev/2011-June/005345.html create mode 100644 zarb-ml/mageia-dev/2011-June/005346.html create mode 100644 zarb-ml/mageia-dev/2011-June/005347.html create mode 100644 zarb-ml/mageia-dev/2011-June/005348.html create mode 100644 zarb-ml/mageia-dev/2011-June/005349.html create mode 100644 zarb-ml/mageia-dev/2011-June/005350.html create mode 100644 zarb-ml/mageia-dev/2011-June/005351.html create mode 100644 zarb-ml/mageia-dev/2011-June/005352.html create mode 100644 zarb-ml/mageia-dev/2011-June/005353.html create mode 100644 zarb-ml/mageia-dev/2011-June/005354.html create mode 100644 zarb-ml/mageia-dev/2011-June/005355.html create mode 100644 zarb-ml/mageia-dev/2011-June/005356.html create mode 100644 zarb-ml/mageia-dev/2011-June/005357.html create mode 100644 zarb-ml/mageia-dev/2011-June/005358.html create mode 100644 zarb-ml/mageia-dev/2011-June/005359.html create mode 100644 zarb-ml/mageia-dev/2011-June/005360.html create mode 100644 zarb-ml/mageia-dev/2011-June/005361.html create mode 100644 zarb-ml/mageia-dev/2011-June/005362.html create mode 100644 zarb-ml/mageia-dev/2011-June/005363.html create mode 100644 zarb-ml/mageia-dev/2011-June/005364.html create mode 100644 zarb-ml/mageia-dev/2011-June/005365.html create mode 100644 zarb-ml/mageia-dev/2011-June/005366.html create mode 100644 zarb-ml/mageia-dev/2011-June/005367.html create mode 100644 zarb-ml/mageia-dev/2011-June/005368.html create mode 100644 zarb-ml/mageia-dev/2011-June/005369.html create mode 100644 zarb-ml/mageia-dev/2011-June/005370.html create mode 100644 zarb-ml/mageia-dev/2011-June/005371.html create mode 100644 zarb-ml/mageia-dev/2011-June/005372.html create mode 100644 zarb-ml/mageia-dev/2011-June/005373.html create mode 100644 zarb-ml/mageia-dev/2011-June/005374.html create mode 100644 zarb-ml/mageia-dev/2011-June/005375.html create mode 100644 zarb-ml/mageia-dev/2011-June/005376.html create mode 100644 zarb-ml/mageia-dev/2011-June/005377.html create mode 100644 zarb-ml/mageia-dev/2011-June/005378.html create mode 100644 zarb-ml/mageia-dev/2011-June/005379.html create mode 100644 zarb-ml/mageia-dev/2011-June/005380.html create mode 100644 zarb-ml/mageia-dev/2011-June/005381.html create mode 100644 zarb-ml/mageia-dev/2011-June/005382.html create mode 100644 zarb-ml/mageia-dev/2011-June/005383.html create mode 100644 zarb-ml/mageia-dev/2011-June/005384.html create mode 100644 zarb-ml/mageia-dev/2011-June/005385.html create mode 100644 zarb-ml/mageia-dev/2011-June/005386.html create mode 100644 zarb-ml/mageia-dev/2011-June/005387.html create mode 100644 zarb-ml/mageia-dev/2011-June/005388.html create mode 100644 zarb-ml/mageia-dev/2011-June/005389.html create mode 100644 zarb-ml/mageia-dev/2011-June/005390.html create mode 100644 zarb-ml/mageia-dev/2011-June/005391.html create mode 100644 zarb-ml/mageia-dev/2011-June/005392.html create mode 100644 zarb-ml/mageia-dev/2011-June/005393.html create mode 100644 zarb-ml/mageia-dev/2011-June/005394.html create mode 100644 zarb-ml/mageia-dev/2011-June/005395.html create mode 100644 zarb-ml/mageia-dev/2011-June/005396.html create mode 100644 zarb-ml/mageia-dev/2011-June/005397.html create mode 100644 zarb-ml/mageia-dev/2011-June/005398.html create mode 100644 zarb-ml/mageia-dev/2011-June/005399.html create mode 100644 zarb-ml/mageia-dev/2011-June/005400.html create mode 100644 zarb-ml/mageia-dev/2011-June/005401.html create mode 100644 zarb-ml/mageia-dev/2011-June/005402.html create mode 100644 zarb-ml/mageia-dev/2011-June/005403.html create mode 100644 zarb-ml/mageia-dev/2011-June/005404.html create mode 100644 zarb-ml/mageia-dev/2011-June/005405.html create mode 100644 zarb-ml/mageia-dev/2011-June/005406.html create mode 100644 zarb-ml/mageia-dev/2011-June/005407.html create mode 100644 zarb-ml/mageia-dev/2011-June/005408.html create mode 100644 zarb-ml/mageia-dev/2011-June/005409.html create mode 100644 zarb-ml/mageia-dev/2011-June/005410.html create mode 100644 zarb-ml/mageia-dev/2011-June/005411.html create mode 100644 zarb-ml/mageia-dev/2011-June/005412.html create mode 100644 zarb-ml/mageia-dev/2011-June/005413.html create mode 100644 zarb-ml/mageia-dev/2011-June/005414.html create mode 100644 zarb-ml/mageia-dev/2011-June/005415.html create mode 100644 zarb-ml/mageia-dev/2011-June/005416.html create mode 100644 zarb-ml/mageia-dev/2011-June/005417.html create mode 100644 zarb-ml/mageia-dev/2011-June/005418.html create mode 100644 zarb-ml/mageia-dev/2011-June/005419.html create mode 100644 zarb-ml/mageia-dev/2011-June/005420.html create mode 100644 zarb-ml/mageia-dev/2011-June/005421.html create mode 100644 zarb-ml/mageia-dev/2011-June/005422.html create mode 100644 zarb-ml/mageia-dev/2011-June/005423.html create mode 100644 zarb-ml/mageia-dev/2011-June/005424.html create mode 100644 zarb-ml/mageia-dev/2011-June/005425.html create mode 100644 zarb-ml/mageia-dev/2011-June/005426.html create mode 100644 zarb-ml/mageia-dev/2011-June/005427.html create mode 100644 zarb-ml/mageia-dev/2011-June/005428.html create mode 100644 zarb-ml/mageia-dev/2011-June/005429.html create mode 100644 zarb-ml/mageia-dev/2011-June/005430.html create mode 100644 zarb-ml/mageia-dev/2011-June/005431.html create mode 100644 zarb-ml/mageia-dev/2011-June/005432.html create mode 100644 zarb-ml/mageia-dev/2011-June/005433.html create mode 100644 zarb-ml/mageia-dev/2011-June/005434.html create mode 100644 zarb-ml/mageia-dev/2011-June/005435.html create mode 100644 zarb-ml/mageia-dev/2011-June/005436.html create mode 100644 zarb-ml/mageia-dev/2011-June/005437.html create mode 100644 zarb-ml/mageia-dev/2011-June/005438.html create mode 100644 zarb-ml/mageia-dev/2011-June/005439.html create mode 100644 zarb-ml/mageia-dev/2011-June/005440.html create mode 100644 zarb-ml/mageia-dev/2011-June/005441.html create mode 100644 zarb-ml/mageia-dev/2011-June/005442.html create mode 100644 zarb-ml/mageia-dev/2011-June/005443.html create mode 100644 zarb-ml/mageia-dev/2011-June/005444.html create mode 100644 zarb-ml/mageia-dev/2011-June/005445.html create mode 100644 zarb-ml/mageia-dev/2011-June/005446.html create mode 100644 zarb-ml/mageia-dev/2011-June/005447.html create mode 100644 zarb-ml/mageia-dev/2011-June/005448.html create mode 100644 zarb-ml/mageia-dev/2011-June/005449.html create mode 100644 zarb-ml/mageia-dev/2011-June/005450.html create mode 100644 zarb-ml/mageia-dev/2011-June/005451.html create mode 100644 zarb-ml/mageia-dev/2011-June/005452.html create mode 100644 zarb-ml/mageia-dev/2011-June/005453.html create mode 100644 zarb-ml/mageia-dev/2011-June/005454.html create mode 100644 zarb-ml/mageia-dev/2011-June/005455.html create mode 100644 zarb-ml/mageia-dev/2011-June/005456.html create mode 100644 zarb-ml/mageia-dev/2011-June/005457.html create mode 100644 zarb-ml/mageia-dev/2011-June/005458.html create mode 100644 zarb-ml/mageia-dev/2011-June/005459.html create mode 100644 zarb-ml/mageia-dev/2011-June/005460.html create mode 100644 zarb-ml/mageia-dev/2011-June/005461.html create mode 100644 zarb-ml/mageia-dev/2011-June/005462.html create mode 100644 zarb-ml/mageia-dev/2011-June/005463.html create mode 100644 zarb-ml/mageia-dev/2011-June/005464.html create mode 100644 zarb-ml/mageia-dev/2011-June/005465.html create mode 100644 zarb-ml/mageia-dev/2011-June/005466.html create mode 100644 zarb-ml/mageia-dev/2011-June/005467.html create mode 100644 zarb-ml/mageia-dev/2011-June/005468.html create mode 100644 zarb-ml/mageia-dev/2011-June/005469.html create mode 100644 zarb-ml/mageia-dev/2011-June/005470.html create mode 100644 zarb-ml/mageia-dev/2011-June/005471.html create mode 100644 zarb-ml/mageia-dev/2011-June/005472.html create mode 100644 zarb-ml/mageia-dev/2011-June/005473.html create mode 100644 zarb-ml/mageia-dev/2011-June/005474.html create mode 100644 zarb-ml/mageia-dev/2011-June/005475.html create mode 100644 zarb-ml/mageia-dev/2011-June/005476.html create mode 100644 zarb-ml/mageia-dev/2011-June/005477.html create mode 100644 zarb-ml/mageia-dev/2011-June/005478.html create mode 100644 zarb-ml/mageia-dev/2011-June/005479.html create mode 100644 zarb-ml/mageia-dev/2011-June/005480.html create mode 100644 zarb-ml/mageia-dev/2011-June/005481.html create mode 100644 zarb-ml/mageia-dev/2011-June/005482.html create mode 100644 zarb-ml/mageia-dev/2011-June/005483.html create mode 100644 zarb-ml/mageia-dev/2011-June/005484.html create mode 100644 zarb-ml/mageia-dev/2011-June/005485.html create mode 100644 zarb-ml/mageia-dev/2011-June/005486.html create mode 100644 zarb-ml/mageia-dev/2011-June/005487.html create mode 100644 zarb-ml/mageia-dev/2011-June/005488.html create mode 100644 zarb-ml/mageia-dev/2011-June/005489.html create mode 100644 zarb-ml/mageia-dev/2011-June/005490.html create mode 100644 zarb-ml/mageia-dev/2011-June/005491.html create mode 100644 zarb-ml/mageia-dev/2011-June/005492.html create mode 100644 zarb-ml/mageia-dev/2011-June/005493.html create mode 100644 zarb-ml/mageia-dev/2011-June/005494.html create mode 100644 zarb-ml/mageia-dev/2011-June/005495.html create mode 100644 zarb-ml/mageia-dev/2011-June/005496.html create mode 100644 zarb-ml/mageia-dev/2011-June/005497.html create mode 100644 zarb-ml/mageia-dev/2011-June/005498.html create mode 100644 zarb-ml/mageia-dev/2011-June/005499.html create mode 100644 zarb-ml/mageia-dev/2011-June/005500.html create mode 100644 zarb-ml/mageia-dev/2011-June/005501.html create mode 100644 zarb-ml/mageia-dev/2011-June/005502.html create mode 100644 zarb-ml/mageia-dev/2011-June/005503.html create mode 100644 zarb-ml/mageia-dev/2011-June/005504.html create mode 100644 zarb-ml/mageia-dev/2011-June/005505.html create mode 100644 zarb-ml/mageia-dev/2011-June/005506.html create mode 100644 zarb-ml/mageia-dev/2011-June/005507.html create mode 100644 zarb-ml/mageia-dev/2011-June/005508.html create mode 100644 zarb-ml/mageia-dev/2011-June/005509.html create mode 100644 zarb-ml/mageia-dev/2011-June/005510.html create mode 100644 zarb-ml/mageia-dev/2011-June/005511.html create mode 100644 zarb-ml/mageia-dev/2011-June/005512.html create mode 100644 zarb-ml/mageia-dev/2011-June/005513.html create mode 100644 zarb-ml/mageia-dev/2011-June/005514.html create mode 100644 zarb-ml/mageia-dev/2011-June/005515.html create mode 100644 zarb-ml/mageia-dev/2011-June/005516.html create mode 100644 zarb-ml/mageia-dev/2011-June/005517.html create mode 100644 zarb-ml/mageia-dev/2011-June/005518.html create mode 100644 zarb-ml/mageia-dev/2011-June/005519.html create mode 100644 zarb-ml/mageia-dev/2011-June/005520.html create mode 100644 zarb-ml/mageia-dev/2011-June/005521.html create mode 100644 zarb-ml/mageia-dev/2011-June/005522.html create mode 100644 zarb-ml/mageia-dev/2011-June/005523.html create mode 100644 zarb-ml/mageia-dev/2011-June/005524.html create mode 100644 zarb-ml/mageia-dev/2011-June/005525.html create mode 100644 zarb-ml/mageia-dev/2011-June/005526.html create mode 100644 zarb-ml/mageia-dev/2011-June/005527.html create mode 100644 zarb-ml/mageia-dev/2011-June/005528.html create mode 100644 zarb-ml/mageia-dev/2011-June/005529.html create mode 100644 zarb-ml/mageia-dev/2011-June/005530.html create mode 100644 zarb-ml/mageia-dev/2011-June/005531.html create mode 100644 zarb-ml/mageia-dev/2011-June/005532.html create mode 100644 zarb-ml/mageia-dev/2011-June/005533.html create mode 100644 zarb-ml/mageia-dev/2011-June/005534.html create mode 100644 zarb-ml/mageia-dev/2011-June/005535.html create mode 100644 zarb-ml/mageia-dev/2011-June/005536.html create mode 100644 zarb-ml/mageia-dev/2011-June/005537.html create mode 100644 zarb-ml/mageia-dev/2011-June/005538.html create mode 100644 zarb-ml/mageia-dev/2011-June/005539.html create mode 100644 zarb-ml/mageia-dev/2011-June/005540.html create mode 100644 zarb-ml/mageia-dev/2011-June/005541.html create mode 100644 zarb-ml/mageia-dev/2011-June/005542.html create mode 100644 zarb-ml/mageia-dev/2011-June/005543.html create mode 100644 zarb-ml/mageia-dev/2011-June/005544.html create mode 100644 zarb-ml/mageia-dev/2011-June/005545.html create mode 100644 zarb-ml/mageia-dev/2011-June/005546.html create mode 100644 zarb-ml/mageia-dev/2011-June/005547.html create mode 100644 zarb-ml/mageia-dev/2011-June/005548.html create mode 100644 zarb-ml/mageia-dev/2011-June/005549.html create mode 100644 zarb-ml/mageia-dev/2011-June/005550.html create mode 100644 zarb-ml/mageia-dev/2011-June/005551.html create mode 100644 zarb-ml/mageia-dev/2011-June/005552.html create mode 100644 zarb-ml/mageia-dev/2011-June/005553.html create mode 100644 zarb-ml/mageia-dev/2011-June/005554.html create mode 100644 zarb-ml/mageia-dev/2011-June/005555.html create mode 100644 zarb-ml/mageia-dev/2011-June/005556.html create mode 100644 zarb-ml/mageia-dev/2011-June/005557.html create mode 100644 zarb-ml/mageia-dev/2011-June/005558.html create mode 100644 zarb-ml/mageia-dev/2011-June/005559.html create mode 100644 zarb-ml/mageia-dev/2011-June/005560.html create mode 100644 zarb-ml/mageia-dev/2011-June/005561.html create mode 100644 zarb-ml/mageia-dev/2011-June/005562.html create mode 100644 zarb-ml/mageia-dev/2011-June/005563.html create mode 100644 zarb-ml/mageia-dev/2011-June/005564.html create mode 100644 zarb-ml/mageia-dev/2011-June/005565.html create mode 100644 zarb-ml/mageia-dev/2011-June/005566.html create mode 100644 zarb-ml/mageia-dev/2011-June/005567.html create mode 100644 zarb-ml/mageia-dev/2011-June/005568.html create mode 100644 zarb-ml/mageia-dev/2011-June/005569.html create mode 100644 zarb-ml/mageia-dev/2011-June/005570.html create mode 100644 zarb-ml/mageia-dev/2011-June/005571.html create mode 100644 zarb-ml/mageia-dev/2011-June/005572.html create mode 100644 zarb-ml/mageia-dev/2011-June/005573.html create mode 100644 zarb-ml/mageia-dev/2011-June/005574.html create mode 100644 zarb-ml/mageia-dev/2011-June/005575.html create mode 100644 zarb-ml/mageia-dev/2011-June/005576.html create mode 100644 zarb-ml/mageia-dev/2011-June/005577.html create mode 100644 zarb-ml/mageia-dev/2011-June/005578.html create mode 100644 zarb-ml/mageia-dev/2011-June/005579.html create mode 100644 zarb-ml/mageia-dev/2011-June/005580.html create mode 100644 zarb-ml/mageia-dev/2011-June/005581.html create mode 100644 zarb-ml/mageia-dev/2011-June/005582.html create mode 100644 zarb-ml/mageia-dev/2011-June/005583.html create mode 100644 zarb-ml/mageia-dev/2011-June/005584.html create mode 100644 zarb-ml/mageia-dev/2011-June/005585.html create mode 100644 zarb-ml/mageia-dev/2011-June/005586.html create mode 100644 zarb-ml/mageia-dev/2011-June/005587.html create mode 100644 zarb-ml/mageia-dev/2011-June/005588.html create mode 100644 zarb-ml/mageia-dev/2011-June/005589.html create mode 100644 zarb-ml/mageia-dev/2011-June/005590.html create mode 100644 zarb-ml/mageia-dev/2011-June/005591.html create mode 100644 zarb-ml/mageia-dev/2011-June/005592.html create mode 100644 zarb-ml/mageia-dev/2011-June/005593.html create mode 100644 zarb-ml/mageia-dev/2011-June/005594.html create mode 100644 zarb-ml/mageia-dev/2011-June/005595.html create mode 100644 zarb-ml/mageia-dev/2011-June/005596.html create mode 100644 zarb-ml/mageia-dev/2011-June/005597.html create mode 100644 zarb-ml/mageia-dev/2011-June/005598.html create mode 100644 zarb-ml/mageia-dev/2011-June/005599.html create mode 100644 zarb-ml/mageia-dev/2011-June/005600.html create mode 100644 zarb-ml/mageia-dev/2011-June/005601.html create mode 100644 zarb-ml/mageia-dev/2011-June/005602.html create mode 100644 zarb-ml/mageia-dev/2011-June/005603.html create mode 100644 zarb-ml/mageia-dev/2011-June/005604.html create mode 100644 zarb-ml/mageia-dev/2011-June/005605.html create mode 100644 zarb-ml/mageia-dev/2011-June/005606.html create mode 100644 zarb-ml/mageia-dev/2011-June/005607.html create mode 100644 zarb-ml/mageia-dev/2011-June/005608.html create mode 100644 zarb-ml/mageia-dev/2011-June/005609.html create mode 100644 zarb-ml/mageia-dev/2011-June/005610.html create mode 100644 zarb-ml/mageia-dev/2011-June/005611.html create mode 100644 zarb-ml/mageia-dev/2011-June/005612.html create mode 100644 zarb-ml/mageia-dev/2011-June/005613.html create mode 100644 zarb-ml/mageia-dev/2011-June/005614.html create mode 100644 zarb-ml/mageia-dev/2011-June/005615.html create mode 100644 zarb-ml/mageia-dev/2011-June/005616.html create mode 100644 zarb-ml/mageia-dev/2011-June/005617.html create mode 100644 zarb-ml/mageia-dev/2011-June/005618.html create mode 100644 zarb-ml/mageia-dev/2011-June/005619.html create mode 100644 zarb-ml/mageia-dev/2011-June/005620.html create mode 100644 zarb-ml/mageia-dev/2011-June/005621.html create mode 100644 zarb-ml/mageia-dev/2011-June/005622.html create mode 100644 zarb-ml/mageia-dev/2011-June/005623.html create mode 100644 zarb-ml/mageia-dev/2011-June/005624.html create mode 100644 zarb-ml/mageia-dev/2011-June/005625.html create mode 100644 zarb-ml/mageia-dev/2011-June/005626.html create mode 100644 zarb-ml/mageia-dev/2011-June/005627.html create mode 100644 zarb-ml/mageia-dev/2011-June/005628.html create mode 100644 zarb-ml/mageia-dev/2011-June/005629.html create mode 100644 zarb-ml/mageia-dev/2011-June/005630.html create mode 100644 zarb-ml/mageia-dev/2011-June/005631.html create mode 100644 zarb-ml/mageia-dev/2011-June/005632.html create mode 100644 zarb-ml/mageia-dev/2011-June/005633.html create mode 100644 zarb-ml/mageia-dev/2011-June/005634.html create mode 100644 zarb-ml/mageia-dev/2011-June/005635.html create mode 100644 zarb-ml/mageia-dev/2011-June/005636.html create mode 100644 zarb-ml/mageia-dev/2011-June/005637.html create mode 100644 zarb-ml/mageia-dev/2011-June/005638.html create mode 100644 zarb-ml/mageia-dev/2011-June/005639.html create mode 100644 zarb-ml/mageia-dev/2011-June/005640.html create mode 100644 zarb-ml/mageia-dev/2011-June/005641.html create mode 100644 zarb-ml/mageia-dev/2011-June/005642.html create mode 100644 zarb-ml/mageia-dev/2011-June/005643.html create mode 100644 zarb-ml/mageia-dev/2011-June/005644.html create mode 100644 zarb-ml/mageia-dev/2011-June/005645.html create mode 100644 zarb-ml/mageia-dev/2011-June/005646.html create mode 100644 zarb-ml/mageia-dev/2011-June/005647.html create mode 100644 zarb-ml/mageia-dev/2011-June/005648.html create mode 100644 zarb-ml/mageia-dev/2011-June/005649.html create mode 100644 zarb-ml/mageia-dev/2011-June/005650.html create mode 100644 zarb-ml/mageia-dev/2011-June/005651.html create mode 100644 zarb-ml/mageia-dev/2011-June/005652.html create mode 100644 zarb-ml/mageia-dev/2011-June/005653.html create mode 100644 zarb-ml/mageia-dev/2011-June/005654.html create mode 100644 zarb-ml/mageia-dev/2011-June/005655.html create mode 100644 zarb-ml/mageia-dev/2011-June/005656.html create mode 100644 zarb-ml/mageia-dev/2011-June/005657.html create mode 100644 zarb-ml/mageia-dev/2011-June/005658.html create mode 100644 zarb-ml/mageia-dev/2011-June/005659.html create mode 100644 zarb-ml/mageia-dev/2011-June/005660.html create mode 100644 zarb-ml/mageia-dev/2011-June/005661.html create mode 100644 zarb-ml/mageia-dev/2011-June/005662.html create mode 100644 zarb-ml/mageia-dev/2011-June/005663.html create mode 100644 zarb-ml/mageia-dev/2011-June/005664.html create mode 100644 zarb-ml/mageia-dev/2011-June/005665.html create mode 100644 zarb-ml/mageia-dev/2011-June/005666.html create mode 100644 zarb-ml/mageia-dev/2011-June/005667.html create mode 100644 zarb-ml/mageia-dev/2011-June/005668.html create mode 100644 zarb-ml/mageia-dev/2011-June/005669.html create mode 100644 zarb-ml/mageia-dev/2011-June/005670.html create mode 100644 zarb-ml/mageia-dev/2011-June/005671.html create mode 100644 zarb-ml/mageia-dev/2011-June/005672.html create mode 100644 zarb-ml/mageia-dev/2011-June/005673.html create mode 100644 zarb-ml/mageia-dev/2011-June/005674.html create mode 100644 zarb-ml/mageia-dev/2011-June/005675.html create mode 100644 zarb-ml/mageia-dev/2011-June/005676.html create mode 100644 zarb-ml/mageia-dev/2011-June/005677.html create mode 100644 zarb-ml/mageia-dev/2011-June/005678.html create mode 100644 zarb-ml/mageia-dev/2011-June/005679.html create mode 100644 zarb-ml/mageia-dev/2011-June/005680.html create mode 100644 zarb-ml/mageia-dev/2011-June/005681.html create mode 100644 zarb-ml/mageia-dev/2011-June/005682.html create mode 100644 zarb-ml/mageia-dev/2011-June/005683.html create mode 100644 zarb-ml/mageia-dev/2011-June/005684.html create mode 100644 zarb-ml/mageia-dev/2011-June/005685.html create mode 100644 zarb-ml/mageia-dev/2011-June/005686.html create mode 100644 zarb-ml/mageia-dev/2011-June/005687.html create mode 100644 zarb-ml/mageia-dev/2011-June/005688.html create mode 100644 zarb-ml/mageia-dev/2011-June/005689.html create mode 100644 zarb-ml/mageia-dev/2011-June/005690.html create mode 100644 zarb-ml/mageia-dev/2011-June/005691.html create mode 100644 zarb-ml/mageia-dev/2011-June/005692.html create mode 100644 zarb-ml/mageia-dev/2011-June/005693.html create mode 100644 zarb-ml/mageia-dev/2011-June/005694.html create mode 100644 zarb-ml/mageia-dev/2011-June/005695.html create mode 100644 zarb-ml/mageia-dev/2011-June/005696.html create mode 100644 zarb-ml/mageia-dev/2011-June/005697.html create mode 100644 zarb-ml/mageia-dev/2011-June/005698.html create mode 100644 zarb-ml/mageia-dev/2011-June/005699.html create mode 100644 zarb-ml/mageia-dev/2011-June/005700.html create mode 100644 zarb-ml/mageia-dev/2011-June/005701.html create mode 100644 zarb-ml/mageia-dev/2011-June/005702.html create mode 100644 zarb-ml/mageia-dev/2011-June/005703.html create mode 100644 zarb-ml/mageia-dev/2011-June/005704.html create mode 100644 zarb-ml/mageia-dev/2011-June/005705.html create mode 100644 zarb-ml/mageia-dev/2011-June/005706.html create mode 100644 zarb-ml/mageia-dev/2011-June/005707.html create mode 100644 zarb-ml/mageia-dev/2011-June/005708.html create mode 100644 zarb-ml/mageia-dev/2011-June/005709.html create mode 100644 zarb-ml/mageia-dev/2011-June/005710.html create mode 100644 zarb-ml/mageia-dev/2011-June/005711.html create mode 100644 zarb-ml/mageia-dev/2011-June/005712.html create mode 100644 zarb-ml/mageia-dev/2011-June/005713.html create mode 100644 zarb-ml/mageia-dev/2011-June/005714.html create mode 100644 zarb-ml/mageia-dev/2011-June/005715.html create mode 100644 zarb-ml/mageia-dev/2011-June/005716.html create mode 100644 zarb-ml/mageia-dev/2011-June/005717.html create mode 100644 zarb-ml/mageia-dev/2011-June/005718.html create mode 100644 zarb-ml/mageia-dev/2011-June/005719.html create mode 100644 zarb-ml/mageia-dev/2011-June/005720.html create mode 100644 zarb-ml/mageia-dev/2011-June/005721.html create mode 100644 zarb-ml/mageia-dev/2011-June/005722.html create mode 100644 zarb-ml/mageia-dev/2011-June/005723.html create mode 100644 zarb-ml/mageia-dev/2011-June/005724.html create mode 100644 zarb-ml/mageia-dev/2011-June/005725.html create mode 100644 zarb-ml/mageia-dev/2011-June/005726.html create mode 100644 zarb-ml/mageia-dev/2011-June/005727.html create mode 100644 zarb-ml/mageia-dev/2011-June/005728.html create mode 100644 zarb-ml/mageia-dev/2011-June/005729.html create mode 100644 zarb-ml/mageia-dev/2011-June/005730.html create mode 100644 zarb-ml/mageia-dev/2011-June/005731.html create mode 100644 zarb-ml/mageia-dev/2011-June/005732.html create mode 100644 zarb-ml/mageia-dev/2011-June/005733.html create mode 100644 zarb-ml/mageia-dev/2011-June/005734.html create mode 100644 zarb-ml/mageia-dev/2011-June/005735.html create mode 100644 zarb-ml/mageia-dev/2011-June/005736.html create mode 100644 zarb-ml/mageia-dev/2011-June/005737.html create mode 100644 zarb-ml/mageia-dev/2011-June/005738.html create mode 100644 zarb-ml/mageia-dev/2011-June/005739.html create mode 100644 zarb-ml/mageia-dev/2011-June/005740.html create mode 100644 zarb-ml/mageia-dev/2011-June/005741.html create mode 100644 zarb-ml/mageia-dev/2011-June/005742.html create mode 100644 zarb-ml/mageia-dev/2011-June/005743.html create mode 100644 zarb-ml/mageia-dev/2011-June/005744.html create mode 100644 zarb-ml/mageia-dev/2011-June/005745.html create mode 100644 zarb-ml/mageia-dev/2011-June/005746.html create mode 100644 zarb-ml/mageia-dev/2011-June/005747.html create mode 100644 zarb-ml/mageia-dev/2011-June/005748.html create mode 100644 zarb-ml/mageia-dev/2011-June/005749.html create mode 100644 zarb-ml/mageia-dev/2011-June/005750.html create mode 100644 zarb-ml/mageia-dev/2011-June/005751.html create mode 100644 zarb-ml/mageia-dev/2011-June/005752.html create mode 100644 zarb-ml/mageia-dev/2011-June/005753.html create mode 100644 zarb-ml/mageia-dev/2011-June/005754.html create mode 100644 zarb-ml/mageia-dev/2011-June/005755.html create mode 100644 zarb-ml/mageia-dev/2011-June/005756.html create mode 100644 zarb-ml/mageia-dev/2011-June/005757.html create mode 100644 zarb-ml/mageia-dev/2011-June/005758.html create mode 100644 zarb-ml/mageia-dev/2011-June/005759.html create mode 100644 zarb-ml/mageia-dev/2011-June/005760.html create mode 100644 zarb-ml/mageia-dev/2011-June/005761.html create mode 100644 zarb-ml/mageia-dev/2011-June/005762.html create mode 100644 zarb-ml/mageia-dev/2011-June/005763.html create mode 100644 zarb-ml/mageia-dev/2011-June/005764.html create mode 100644 zarb-ml/mageia-dev/2011-June/005765.html create mode 100644 zarb-ml/mageia-dev/2011-June/005766.html create mode 100644 zarb-ml/mageia-dev/2011-June/005767.html create mode 100644 zarb-ml/mageia-dev/2011-June/005768.html create mode 100644 zarb-ml/mageia-dev/2011-June/005769.html create mode 100644 zarb-ml/mageia-dev/2011-June/005770.html create mode 100644 zarb-ml/mageia-dev/2011-June/005771.html create mode 100644 zarb-ml/mageia-dev/2011-June/005772.html create mode 100644 zarb-ml/mageia-dev/2011-June/005773.html create mode 100644 zarb-ml/mageia-dev/2011-June/005774.html create mode 100644 zarb-ml/mageia-dev/2011-June/005775.html create mode 100644 zarb-ml/mageia-dev/2011-June/005776.html create mode 100644 zarb-ml/mageia-dev/2011-June/005777.html create mode 100644 zarb-ml/mageia-dev/2011-June/005778.html create mode 100644 zarb-ml/mageia-dev/2011-June/005779.html create mode 100644 zarb-ml/mageia-dev/2011-June/005780.html create mode 100644 zarb-ml/mageia-dev/2011-June/005781.html create mode 100644 zarb-ml/mageia-dev/2011-June/005782.html create mode 100644 zarb-ml/mageia-dev/2011-June/005783.html create mode 100644 zarb-ml/mageia-dev/2011-June/005784.html create mode 100644 zarb-ml/mageia-dev/2011-June/005785.html create mode 100644 zarb-ml/mageia-dev/2011-June/005786.html create mode 100644 zarb-ml/mageia-dev/2011-June/005787.html create mode 100644 zarb-ml/mageia-dev/2011-June/005788.html create mode 100644 zarb-ml/mageia-dev/2011-June/005789.html create mode 100644 zarb-ml/mageia-dev/2011-June/005790.html create mode 100644 zarb-ml/mageia-dev/2011-June/005791.html create mode 100644 zarb-ml/mageia-dev/2011-June/005792.html create mode 100644 zarb-ml/mageia-dev/2011-June/005793.html create mode 100644 zarb-ml/mageia-dev/2011-June/005794.html create mode 100644 zarb-ml/mageia-dev/2011-June/005795.html create mode 100644 zarb-ml/mageia-dev/2011-June/005796.html create mode 100644 zarb-ml/mageia-dev/2011-June/005797.html create mode 100644 zarb-ml/mageia-dev/2011-June/005798.html create mode 100644 zarb-ml/mageia-dev/2011-June/005799.html create mode 100644 zarb-ml/mageia-dev/2011-June/005800.html create mode 100644 zarb-ml/mageia-dev/2011-June/005801.html create mode 100644 zarb-ml/mageia-dev/2011-June/005802.html create mode 100644 zarb-ml/mageia-dev/2011-June/005803.html create mode 100644 zarb-ml/mageia-dev/2011-June/005804.html create mode 100644 zarb-ml/mageia-dev/2011-June/005805.html create mode 100644 zarb-ml/mageia-dev/2011-June/005806.html create mode 100644 zarb-ml/mageia-dev/2011-June/005807.html create mode 100644 zarb-ml/mageia-dev/2011-June/005808.html create mode 100644 zarb-ml/mageia-dev/2011-June/005809.html create mode 100644 zarb-ml/mageia-dev/2011-June/005810.html create mode 100644 zarb-ml/mageia-dev/2011-June/005811.html create mode 100644 zarb-ml/mageia-dev/2011-June/005812.html create mode 100644 zarb-ml/mageia-dev/2011-June/005813.html create mode 100644 zarb-ml/mageia-dev/2011-June/005814.html create mode 100644 zarb-ml/mageia-dev/2011-June/005815.html create mode 100644 zarb-ml/mageia-dev/2011-June/005816.html create mode 100644 zarb-ml/mageia-dev/2011-June/005817.html create mode 100644 zarb-ml/mageia-dev/2011-June/005818.html create mode 100644 zarb-ml/mageia-dev/2011-June/005819.html create mode 100644 zarb-ml/mageia-dev/2011-June/005820.html create mode 100644 zarb-ml/mageia-dev/2011-June/005821.html create mode 100644 zarb-ml/mageia-dev/2011-June/005822.html create mode 100644 zarb-ml/mageia-dev/2011-June/005823.html create mode 100644 zarb-ml/mageia-dev/2011-June/005824.html create mode 100644 zarb-ml/mageia-dev/2011-June/005825.html create mode 100644 zarb-ml/mageia-dev/2011-June/005826.html create mode 100644 zarb-ml/mageia-dev/2011-June/005827.html create mode 100644 zarb-ml/mageia-dev/2011-June/005828.html create mode 100644 zarb-ml/mageia-dev/2011-June/005829.html create mode 100644 zarb-ml/mageia-dev/2011-June/005830.html create mode 100644 zarb-ml/mageia-dev/2011-June/005831.html create mode 100644 zarb-ml/mageia-dev/2011-June/005832.html create mode 100644 zarb-ml/mageia-dev/2011-June/005833.html create mode 100644 zarb-ml/mageia-dev/2011-June/005834.html create mode 100644 zarb-ml/mageia-dev/2011-June/005835.html create mode 100644 zarb-ml/mageia-dev/2011-June/005836.html create mode 100644 zarb-ml/mageia-dev/2011-June/005837.html create mode 100644 zarb-ml/mageia-dev/2011-June/005838.html create mode 100644 zarb-ml/mageia-dev/2011-June/005839.html create mode 100644 zarb-ml/mageia-dev/2011-June/005840.html create mode 100644 zarb-ml/mageia-dev/2011-June/005841.html create mode 100644 zarb-ml/mageia-dev/2011-June/005842.html create mode 100644 zarb-ml/mageia-dev/2011-June/005843.html create mode 100644 zarb-ml/mageia-dev/2011-June/005844.html create mode 100644 zarb-ml/mageia-dev/2011-June/005845.html create mode 100644 zarb-ml/mageia-dev/2011-June/005846.html create mode 100644 zarb-ml/mageia-dev/2011-June/005847.html create mode 100644 zarb-ml/mageia-dev/2011-June/005848.html create mode 100644 zarb-ml/mageia-dev/2011-June/005849.html create mode 100644 zarb-ml/mageia-dev/2011-June/005850.html create mode 100644 zarb-ml/mageia-dev/2011-June/005851.html create mode 100644 zarb-ml/mageia-dev/2011-June/005852.html create mode 100644 zarb-ml/mageia-dev/2011-June/005853.html create mode 100644 zarb-ml/mageia-dev/2011-June/005854.html create mode 100644 zarb-ml/mageia-dev/2011-June/005855.html create mode 100644 zarb-ml/mageia-dev/2011-June/005856.html create mode 100644 zarb-ml/mageia-dev/2011-June/005857.html create mode 100644 zarb-ml/mageia-dev/2011-June/005858.html create mode 100644 zarb-ml/mageia-dev/2011-June/005859.html create mode 100644 zarb-ml/mageia-dev/2011-June/005860.html create mode 100644 zarb-ml/mageia-dev/2011-June/005861.html create mode 100644 zarb-ml/mageia-dev/2011-June/005862.html create mode 100644 zarb-ml/mageia-dev/2011-June/005863.html create mode 100644 zarb-ml/mageia-dev/2011-June/005864.html create mode 100644 zarb-ml/mageia-dev/2011-June/005865.html create mode 100644 zarb-ml/mageia-dev/2011-June/005866.html create mode 100644 zarb-ml/mageia-dev/2011-June/005867.html create mode 100644 zarb-ml/mageia-dev/2011-June/005868.html create mode 100644 zarb-ml/mageia-dev/2011-June/005869.html create mode 100644 zarb-ml/mageia-dev/2011-June/005870.html create mode 100644 zarb-ml/mageia-dev/2011-June/005871.html create mode 100644 zarb-ml/mageia-dev/2011-June/005872.html create mode 100644 zarb-ml/mageia-dev/2011-June/005873.html create mode 100644 zarb-ml/mageia-dev/2011-June/005874.html create mode 100644 zarb-ml/mageia-dev/2011-June/005875.html create mode 100644 zarb-ml/mageia-dev/2011-June/005876.html create mode 100644 zarb-ml/mageia-dev/2011-June/005877.html create mode 100644 zarb-ml/mageia-dev/2011-June/005878.html create mode 100644 zarb-ml/mageia-dev/2011-June/005879.html create mode 100644 zarb-ml/mageia-dev/2011-June/005880.html create mode 100644 zarb-ml/mageia-dev/2011-June/005881.html create mode 100644 zarb-ml/mageia-dev/2011-June/005882.html create mode 100644 zarb-ml/mageia-dev/2011-June/005883.html create mode 100644 zarb-ml/mageia-dev/2011-June/005884.html create mode 100644 zarb-ml/mageia-dev/2011-June/005885.html create mode 100644 zarb-ml/mageia-dev/2011-June/005886.html create mode 100644 zarb-ml/mageia-dev/2011-June/005887.html create mode 100644 zarb-ml/mageia-dev/2011-June/005888.html create mode 100644 zarb-ml/mageia-dev/2011-June/005889.html create mode 100644 zarb-ml/mageia-dev/2011-June/005890.html create mode 100644 zarb-ml/mageia-dev/2011-June/005891.html create mode 100644 zarb-ml/mageia-dev/2011-June/005892.html create mode 100644 zarb-ml/mageia-dev/2011-June/005893.html create mode 100644 zarb-ml/mageia-dev/2011-June/005894.html create mode 100644 zarb-ml/mageia-dev/2011-June/005895.html create mode 100644 zarb-ml/mageia-dev/2011-June/005896.html create mode 100644 zarb-ml/mageia-dev/2011-June/005897.html create mode 100644 zarb-ml/mageia-dev/2011-June/005898.html create mode 100644 zarb-ml/mageia-dev/2011-June/005899.html create mode 100644 zarb-ml/mageia-dev/2011-June/005900.html create mode 100644 zarb-ml/mageia-dev/2011-June/005901.html create mode 100644 zarb-ml/mageia-dev/2011-June/005902.html create mode 100644 zarb-ml/mageia-dev/2011-June/005903.html create mode 100644 zarb-ml/mageia-dev/2011-June/005904.html create mode 100644 zarb-ml/mageia-dev/2011-June/005905.html create mode 100644 zarb-ml/mageia-dev/2011-June/005906.html create mode 100644 zarb-ml/mageia-dev/2011-June/005907.html create mode 100644 zarb-ml/mageia-dev/2011-June/005908.html create mode 100644 zarb-ml/mageia-dev/2011-June/005909.html create mode 100644 zarb-ml/mageia-dev/2011-June/005910.html create mode 100644 zarb-ml/mageia-dev/2011-June/005911.html create mode 100644 zarb-ml/mageia-dev/2011-June/005912.html create mode 100644 zarb-ml/mageia-dev/2011-June/005913.html create mode 100644 zarb-ml/mageia-dev/2011-June/005914.html create mode 100644 zarb-ml/mageia-dev/2011-June/005915.html create mode 100644 zarb-ml/mageia-dev/2011-June/005916.html create mode 100644 zarb-ml/mageia-dev/2011-June/005917.html create mode 100644 zarb-ml/mageia-dev/2011-June/005918.html create mode 100644 zarb-ml/mageia-dev/2011-June/005919.html create mode 100644 zarb-ml/mageia-dev/2011-June/005920.html create mode 100644 zarb-ml/mageia-dev/2011-June/005921.html create mode 100644 zarb-ml/mageia-dev/2011-June/005922.html create mode 100644 zarb-ml/mageia-dev/2011-June/005923.html create mode 100644 zarb-ml/mageia-dev/2011-June/005924.html create mode 100644 zarb-ml/mageia-dev/2011-June/005925.html create mode 100644 zarb-ml/mageia-dev/2011-June/005926.html create mode 100644 zarb-ml/mageia-dev/2011-June/005927.html create mode 100644 zarb-ml/mageia-dev/2011-June/005928.html create mode 100644 zarb-ml/mageia-dev/2011-June/005929.html create mode 100644 zarb-ml/mageia-dev/2011-June/005930.html create mode 100644 zarb-ml/mageia-dev/2011-June/005931.html create mode 100644 zarb-ml/mageia-dev/2011-June/005932.html create mode 100644 zarb-ml/mageia-dev/2011-June/005933.html create mode 100644 zarb-ml/mageia-dev/2011-June/005934.html create mode 100644 zarb-ml/mageia-dev/2011-June/005935.html create mode 100644 zarb-ml/mageia-dev/2011-June/005936.html create mode 100644 zarb-ml/mageia-dev/2011-June/005937.html create mode 100644 zarb-ml/mageia-dev/2011-June/005938.html create mode 100644 zarb-ml/mageia-dev/2011-June/005939.html create mode 100644 zarb-ml/mageia-dev/2011-June/005940.html create mode 100644 zarb-ml/mageia-dev/2011-June/005941.html create mode 100644 zarb-ml/mageia-dev/2011-June/005942.html create mode 100644 zarb-ml/mageia-dev/2011-June/005943.html create mode 100644 zarb-ml/mageia-dev/2011-June/005944.html create mode 100644 zarb-ml/mageia-dev/2011-June/005945.html create mode 100644 zarb-ml/mageia-dev/2011-June/005946.html create mode 100644 zarb-ml/mageia-dev/2011-June/005947.html create mode 100644 zarb-ml/mageia-dev/2011-June/005948.html create mode 100644 zarb-ml/mageia-dev/2011-June/005949.html create mode 100644 zarb-ml/mageia-dev/2011-June/005950.html create mode 100644 zarb-ml/mageia-dev/2011-June/005951.html create mode 100644 zarb-ml/mageia-dev/2011-June/005952.html create mode 100644 zarb-ml/mageia-dev/2011-June/005953.html create mode 100644 zarb-ml/mageia-dev/2011-June/005954.html create mode 100644 zarb-ml/mageia-dev/2011-June/005955.html create mode 100644 zarb-ml/mageia-dev/2011-June/005956.html create mode 100644 zarb-ml/mageia-dev/2011-June/005957.html create mode 100644 zarb-ml/mageia-dev/2011-June/005958.html create mode 100644 zarb-ml/mageia-dev/2011-June/005959.html create mode 100644 zarb-ml/mageia-dev/2011-June/005960.html create mode 100644 zarb-ml/mageia-dev/2011-June/005961.html create mode 100644 zarb-ml/mageia-dev/2011-June/005962.html create mode 100644 zarb-ml/mageia-dev/2011-June/005963.html create mode 100644 zarb-ml/mageia-dev/2011-June/005964.html create mode 100644 zarb-ml/mageia-dev/2011-June/005965.html create mode 100644 zarb-ml/mageia-dev/2011-June/005966.html create mode 100644 zarb-ml/mageia-dev/2011-June/005967.html create mode 100644 zarb-ml/mageia-dev/2011-June/005968.html create mode 100644 zarb-ml/mageia-dev/2011-June/005969.html create mode 100644 zarb-ml/mageia-dev/2011-June/005970.html create mode 100644 zarb-ml/mageia-dev/2011-June/005971.html create mode 100644 zarb-ml/mageia-dev/2011-June/005972.html create mode 100644 zarb-ml/mageia-dev/2011-June/005973.html create mode 100644 zarb-ml/mageia-dev/2011-June/005974.html create mode 100644 zarb-ml/mageia-dev/2011-June/005975.html create mode 100644 zarb-ml/mageia-dev/2011-June/005976.html create mode 100644 zarb-ml/mageia-dev/2011-June/005977.html create mode 100644 zarb-ml/mageia-dev/2011-June/005978.html create mode 100644 zarb-ml/mageia-dev/2011-June/005979.html create mode 100644 zarb-ml/mageia-dev/2011-June/005980.html create mode 100644 zarb-ml/mageia-dev/2011-June/005981.html create mode 100644 zarb-ml/mageia-dev/2011-June/005982.html create mode 100644 zarb-ml/mageia-dev/2011-June/005983.html create mode 100644 zarb-ml/mageia-dev/2011-June/005984.html create mode 100644 zarb-ml/mageia-dev/2011-June/005985.html create mode 100644 zarb-ml/mageia-dev/2011-June/005986.html create mode 100644 zarb-ml/mageia-dev/2011-June/005987.html create mode 100644 zarb-ml/mageia-dev/2011-June/005988.html create mode 100644 zarb-ml/mageia-dev/2011-June/005989.html create mode 100644 zarb-ml/mageia-dev/2011-June/005990.html create mode 100644 zarb-ml/mageia-dev/2011-June/005991.html create mode 100644 zarb-ml/mageia-dev/2011-June/005992.html create mode 100644 zarb-ml/mageia-dev/2011-June/005993.html create mode 100644 zarb-ml/mageia-dev/2011-June/005994.html create mode 100644 zarb-ml/mageia-dev/2011-June/005995.html create mode 100644 zarb-ml/mageia-dev/2011-June/005996.html create mode 100644 zarb-ml/mageia-dev/2011-June/005997.html create mode 100644 zarb-ml/mageia-dev/2011-June/005998.html create mode 100644 zarb-ml/mageia-dev/2011-June/005999.html create mode 100644 zarb-ml/mageia-dev/2011-June/006000.html create mode 100644 zarb-ml/mageia-dev/2011-June/006001.html create mode 100644 zarb-ml/mageia-dev/2011-June/006002.html create mode 100644 zarb-ml/mageia-dev/2011-June/006003.html create mode 100644 zarb-ml/mageia-dev/2011-June/006004.html create mode 100644 zarb-ml/mageia-dev/2011-June/006005.html create mode 100644 zarb-ml/mageia-dev/2011-June/006006.html create mode 100644 zarb-ml/mageia-dev/2011-June/006007.html create mode 100644 zarb-ml/mageia-dev/2011-June/006008.html create mode 100644 zarb-ml/mageia-dev/2011-June/006009.html create mode 100644 zarb-ml/mageia-dev/2011-June/006010.html create mode 100644 zarb-ml/mageia-dev/2011-June/006011.html create mode 100644 zarb-ml/mageia-dev/2011-June/006012.html create mode 100644 zarb-ml/mageia-dev/2011-June/006013.html create mode 100644 zarb-ml/mageia-dev/2011-June/006014.html create mode 100644 zarb-ml/mageia-dev/2011-June/006015.html create mode 100644 zarb-ml/mageia-dev/2011-June/006016.html create mode 100644 zarb-ml/mageia-dev/2011-June/006017.html create mode 100644 zarb-ml/mageia-dev/2011-June/006018.html create mode 100644 zarb-ml/mageia-dev/2011-June/006019.html create mode 100644 zarb-ml/mageia-dev/2011-June/006020.html create mode 100644 zarb-ml/mageia-dev/2011-June/006021.html create mode 100644 zarb-ml/mageia-dev/2011-June/006022.html create mode 100644 zarb-ml/mageia-dev/2011-June/006023.html create mode 100644 zarb-ml/mageia-dev/2011-June/006024.html create mode 100644 zarb-ml/mageia-dev/2011-June/006025.html create mode 100644 zarb-ml/mageia-dev/2011-June/006026.html create mode 100644 zarb-ml/mageia-dev/2011-June/006027.html create mode 100644 zarb-ml/mageia-dev/2011-June/006028.html create mode 100644 zarb-ml/mageia-dev/2011-June/006029.html create mode 100644 zarb-ml/mageia-dev/2011-June/006030.html create mode 100644 zarb-ml/mageia-dev/2011-June/006031.html create mode 100644 zarb-ml/mageia-dev/2011-June/006032.html create mode 100644 zarb-ml/mageia-dev/2011-June/006033.html create mode 100644 zarb-ml/mageia-dev/2011-June/006034.html create mode 100644 zarb-ml/mageia-dev/2011-June/006035.html create mode 100644 zarb-ml/mageia-dev/2011-June/006036.html create mode 100644 zarb-ml/mageia-dev/2011-June/006037.html create mode 100644 zarb-ml/mageia-dev/2011-June/006038.html create mode 100644 zarb-ml/mageia-dev/2011-June/006039.html create mode 100644 zarb-ml/mageia-dev/2011-June/006040.html create mode 100644 zarb-ml/mageia-dev/2011-June/006041.html create mode 100644 zarb-ml/mageia-dev/2011-June/006042.html create mode 100644 zarb-ml/mageia-dev/2011-June/006043.html create mode 100644 zarb-ml/mageia-dev/2011-June/006044.html create mode 100644 zarb-ml/mageia-dev/2011-June/006045.html create mode 100644 zarb-ml/mageia-dev/2011-June/006046.html create mode 100644 zarb-ml/mageia-dev/2011-June/006047.html create mode 100644 zarb-ml/mageia-dev/2011-June/006048.html create mode 100644 zarb-ml/mageia-dev/2011-June/006049.html create mode 100644 zarb-ml/mageia-dev/2011-June/006050.html create mode 100644 zarb-ml/mageia-dev/2011-June/006051.html create mode 100644 zarb-ml/mageia-dev/2011-June/006052.html create mode 100644 zarb-ml/mageia-dev/2011-June/006053.html create mode 100644 zarb-ml/mageia-dev/2011-June/006054.html create mode 100644 zarb-ml/mageia-dev/2011-June/006055.html create mode 100644 zarb-ml/mageia-dev/2011-June/006056.html create mode 100644 zarb-ml/mageia-dev/2011-June/006057.html create mode 100644 zarb-ml/mageia-dev/2011-June/006058.html create mode 100644 zarb-ml/mageia-dev/2011-June/006059.html create mode 100644 zarb-ml/mageia-dev/2011-June/006060.html create mode 100644 zarb-ml/mageia-dev/2011-June/006061.html create mode 100644 zarb-ml/mageia-dev/2011-June/006062.html create mode 100644 zarb-ml/mageia-dev/2011-June/006063.html create mode 100644 zarb-ml/mageia-dev/2011-June/006064.html create mode 100644 zarb-ml/mageia-dev/2011-June/006065.html create mode 100644 zarb-ml/mageia-dev/2011-June/006066.html create mode 100644 zarb-ml/mageia-dev/2011-June/006067.html create mode 100644 zarb-ml/mageia-dev/2011-June/006068.html create mode 100644 zarb-ml/mageia-dev/2011-June/006069.html create mode 100644 zarb-ml/mageia-dev/2011-June/006070.html create mode 100644 zarb-ml/mageia-dev/2011-June/006071.html create mode 100644 zarb-ml/mageia-dev/2011-June/006072.html create mode 100644 zarb-ml/mageia-dev/2011-June/006073.html create mode 100644 zarb-ml/mageia-dev/2011-June/006074.html create mode 100644 zarb-ml/mageia-dev/2011-June/006075.html create mode 100644 zarb-ml/mageia-dev/2011-June/006076.html create mode 100644 zarb-ml/mageia-dev/2011-June/006077.html create mode 100644 zarb-ml/mageia-dev/2011-June/006078.html create mode 100644 zarb-ml/mageia-dev/2011-June/006079.html create mode 100644 zarb-ml/mageia-dev/2011-June/006080.html create mode 100644 zarb-ml/mageia-dev/2011-June/006081.html create mode 100644 zarb-ml/mageia-dev/2011-June/006082.html create mode 100644 zarb-ml/mageia-dev/2011-June/006083.html create mode 100644 zarb-ml/mageia-dev/2011-June/006084.html create mode 100644 zarb-ml/mageia-dev/2011-June/006085.html create mode 100644 zarb-ml/mageia-dev/2011-June/006086.html create mode 100644 zarb-ml/mageia-dev/2011-June/006087.html create mode 100644 zarb-ml/mageia-dev/2011-June/006088.html create mode 100644 zarb-ml/mageia-dev/2011-June/006089.html create mode 100644 zarb-ml/mageia-dev/2011-June/006090.html create mode 100644 zarb-ml/mageia-dev/2011-June/006091.html create mode 100644 zarb-ml/mageia-dev/2011-June/006092.html create mode 100644 zarb-ml/mageia-dev/2011-June/006093.html create mode 100644 zarb-ml/mageia-dev/2011-June/006094.html create mode 100644 zarb-ml/mageia-dev/2011-June/006095.html create mode 100644 zarb-ml/mageia-dev/2011-June/006096.html create mode 100644 zarb-ml/mageia-dev/2011-June/006097.html create mode 100644 zarb-ml/mageia-dev/2011-June/006098.html create mode 100644 zarb-ml/mageia-dev/2011-June/006099.html create mode 100644 zarb-ml/mageia-dev/2011-June/006100.html create mode 100644 zarb-ml/mageia-dev/2011-June/006101.html create mode 100644 zarb-ml/mageia-dev/2011-June/006102.html create mode 100644 zarb-ml/mageia-dev/2011-June/006103.html create mode 100644 zarb-ml/mageia-dev/2011-June/006104.html create mode 100644 zarb-ml/mageia-dev/2011-June/006105.html create mode 100644 zarb-ml/mageia-dev/2011-June/006106.html create mode 100644 zarb-ml/mageia-dev/2011-June/006107.html create mode 100644 zarb-ml/mageia-dev/2011-June/006108.html create mode 100644 zarb-ml/mageia-dev/2011-June/006109.html create mode 100644 zarb-ml/mageia-dev/2011-June/006110.html create mode 100644 zarb-ml/mageia-dev/2011-June/006111.html create mode 100644 zarb-ml/mageia-dev/2011-June/006112.html create mode 100644 zarb-ml/mageia-dev/2011-June/006113.html create mode 100644 zarb-ml/mageia-dev/2011-June/006114.html create mode 100644 zarb-ml/mageia-dev/2011-June/006115.html create mode 100644 zarb-ml/mageia-dev/2011-June/006116.html create mode 100644 zarb-ml/mageia-dev/2011-June/006117.html create mode 100644 zarb-ml/mageia-dev/2011-June/006118.html create mode 100644 zarb-ml/mageia-dev/2011-June/006119.html create mode 100644 zarb-ml/mageia-dev/2011-June/006120.html create mode 100644 zarb-ml/mageia-dev/2011-June/006121.html create mode 100644 zarb-ml/mageia-dev/2011-June/006122.html create mode 100644 zarb-ml/mageia-dev/2011-June/006123.html create mode 100644 zarb-ml/mageia-dev/2011-June/006124.html create mode 100644 zarb-ml/mageia-dev/2011-June/006125.html create mode 100644 zarb-ml/mageia-dev/2011-June/006126.html create mode 100644 zarb-ml/mageia-dev/2011-June/006127.html create mode 100644 zarb-ml/mageia-dev/2011-June/006128.html create mode 100644 zarb-ml/mageia-dev/2011-June/006129.html create mode 100644 zarb-ml/mageia-dev/2011-June/006130.html create mode 100644 zarb-ml/mageia-dev/2011-June/006131.html create mode 100644 zarb-ml/mageia-dev/2011-June/006132.html create mode 100644 zarb-ml/mageia-dev/2011-June/006133.html create mode 100644 zarb-ml/mageia-dev/2011-June/006134.html create mode 100644 zarb-ml/mageia-dev/2011-June/006135.html create mode 100644 zarb-ml/mageia-dev/2011-June/006136.html create mode 100644 zarb-ml/mageia-dev/2011-June/006137.html create mode 100644 zarb-ml/mageia-dev/2011-June/006138.html create mode 100644 zarb-ml/mageia-dev/2011-June/006139.html create mode 100644 zarb-ml/mageia-dev/2011-June/006140.html create mode 100644 zarb-ml/mageia-dev/2011-June/006141.html create mode 100644 zarb-ml/mageia-dev/2011-June/006142.html create mode 100644 zarb-ml/mageia-dev/2011-June/006143.html create mode 100644 zarb-ml/mageia-dev/2011-June/006144.html create mode 100644 zarb-ml/mageia-dev/2011-June/006145.html create mode 100644 zarb-ml/mageia-dev/2011-June/006146.html create mode 100644 zarb-ml/mageia-dev/2011-June/006147.html create mode 100644 zarb-ml/mageia-dev/2011-June/006148.html create mode 100644 zarb-ml/mageia-dev/2011-June/006149.html create mode 100644 zarb-ml/mageia-dev/2011-June/006150.html create mode 100644 zarb-ml/mageia-dev/2011-June/006151.html create mode 100644 zarb-ml/mageia-dev/2011-June/006152.html create mode 100644 zarb-ml/mageia-dev/2011-June/006153.html create mode 100644 zarb-ml/mageia-dev/2011-June/006154.html create mode 100644 zarb-ml/mageia-dev/2011-June/006155.html create mode 100644 zarb-ml/mageia-dev/2011-June/006156.html create mode 100644 zarb-ml/mageia-dev/2011-June/006157.html create mode 100644 zarb-ml/mageia-dev/2011-June/006158.html create mode 100644 zarb-ml/mageia-dev/2011-June/006159.html create mode 100644 zarb-ml/mageia-dev/2011-June/006160.html create mode 100644 zarb-ml/mageia-dev/2011-June/006161.html create mode 100644 zarb-ml/mageia-dev/2011-June/006162.html create mode 100644 zarb-ml/mageia-dev/2011-June/006163.html create mode 100644 zarb-ml/mageia-dev/2011-June/006164.html create mode 100644 zarb-ml/mageia-dev/2011-June/006165.html create mode 100644 zarb-ml/mageia-dev/2011-June/006166.html create mode 100644 zarb-ml/mageia-dev/2011-June/006167.html create mode 100644 zarb-ml/mageia-dev/2011-June/006168.html create mode 100644 zarb-ml/mageia-dev/2011-June/006169.html create mode 100644 zarb-ml/mageia-dev/2011-June/006170.html create mode 100644 zarb-ml/mageia-dev/2011-June/006171.html create mode 100644 zarb-ml/mageia-dev/2011-June/006172.html create mode 100644 zarb-ml/mageia-dev/2011-June/006173.html create mode 100644 zarb-ml/mageia-dev/2011-June/006174.html create mode 100644 zarb-ml/mageia-dev/2011-June/author.html create mode 100644 zarb-ml/mageia-dev/2011-June/date.html create mode 120000 zarb-ml/mageia-dev/2011-June/index.html create mode 100644 zarb-ml/mageia-dev/2011-June/subject.html create mode 100644 zarb-ml/mageia-dev/2011-June/thread.html (limited to 'zarb-ml/mageia-dev/2011-June') diff --git a/zarb-ml/mageia-dev/2011-June/005197.html b/zarb-ml/mageia-dev/2011-June/005197.html new file mode 100644 index 000000000..12a457b78 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005197.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] Discrepancy between /etc/version and /etc/release - which one for MIRRORLIST + + + + + + + + + +

[Mageia-dev] Discrepancy between /etc/version and /etc/release - which one for MIRRORLIST

+ James Kerr + jim at jkerr82508.free-online.co.uk +
+ Wed Jun 8 14:10:50 CEST 2011 +

+
+ +
On 08/06/11 08:42, Oliver Burger wrote:
+> Hi,
+>
+> after some discussion in the German forums, I saw, that there are
+> discrepancies between /etc/version and /etc/release, both coming from
+> the mageia-release-common-1-2.mga1 package.
+>
+> While /etc/release calls my system
+> ----------
+> Mageia release 1 (Official) for i586
+> ----------
+>
+> it is called
+> ----------
+> 1 2 cauldron
+> ----------
+>
+> by /etc/version.
+>
+> Which one of those defines the branch used by MIRRORLIST
+
+I thought that /etc/product.id was used.
+
+Jim
+
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005198.html b/zarb-ml/mageia-dev/2011-June/005198.html new file mode 100644 index 000000000..6b76e57bb --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005198.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] automatic chroot install using urpmi + + + + + + + + + +

[Mageia-dev] automatic chroot install using urpmi

+ Vasiliy G Tolstov + v.tolstov at selfip.ru +
+ Wed Jun 8 14:14:06 CEST 2011 +

+
+ +
Hello. I'm glad to announce, that mageia linux is in testing mode on our
+cloud vps hosting (clodo.ru).
+After build image i have one question - is that possible to do fully
+automatic install with this script:
+
+#!/bin/bash
+
+export LC_ALL=C
+
+ROOT=$1
+ARCH=$2
+VERSION=$3
+
+mount -o bind /dev ${ROOT}/dev/
+mount -o bind /sys ${ROOT}/sys/
+mount -t proc none ${ROOT}/proc/
+
+if [ "x${ARCH}" != "xx86_64" ] ; then
+  ARCH="i586"
+fi
+
+urpmi.addmedia --urpmi-root ${ROOT} --distrib
+http://ftp.cc.uoc.gr/mirrors/linux/mageia/distrib/${VERSION}/${ARCH}
+urpmi -v --replacefiles --ignoresize --urpmi-root ${ROOT} basesystem
+urpmi -v --replacefiles --ignoresize --urpmi-root ${ROOT} openssh-server
+ntpd
+
+
+One problem is: urpmi try to get answers for installing default init
+system, default boot loader and some other questions.... How can i avoid
+it to do full unattended install?
+
+-- 
+Vasiliy G Tolstov <v.tolstov at selfip.ru>
+Selfip.Ru
+
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005199.html b/zarb-ml/mageia-dev/2011-June/005199.html new file mode 100644 index 000000000..27536fb86 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005199.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] automatic chroot install using urpmi + + + + + + + + + +

[Mageia-dev] automatic chroot install using urpmi

+ Thomas Backlund + tmb at mageia.org +
+ Wed Jun 8 14:23:04 CEST 2011 +

+
+ +
Vasiliy G Tolstov skrev 8.6.2011 15:14:
+> Hello. I'm glad to announce, that mageia linux is in testing mode on our
+> cloud vps hosting (clodo.ru).
+> After build image i have one question - is that possible to do fully
+> automatic install with this script:
+>
+> #!/bin/bash
+>
+> export LC_ALL=C
+>
+> ROOT=$1
+> ARCH=$2
+> VERSION=$3
+>
+> mount -o bind /dev ${ROOT}/dev/
+> mount -o bind /sys ${ROOT}/sys/
+> mount -t proc none ${ROOT}/proc/
+>
+> if [ "x${ARCH}" != "xx86_64" ] ; then
+>    ARCH="i586"
+> fi
+>
+> urpmi.addmedia --urpmi-root ${ROOT} --distrib
+> http://ftp.cc.uoc.gr/mirrors/linux/mageia/distrib/${VERSION}/${ARCH}
+> urpmi -v --replacefiles --ignoresize --urpmi-root ${ROOT} basesystem
+> urpmi -v --replacefiles --ignoresize --urpmi-root ${ROOT} openssh-server
+> ntpd
+
+No need to make it 2 steps, you can push all in one go...
+
+
+>
+> One problem is: urpmi try to get answers for installing default init
+> system, default boot loader and some other questions.... How can i avoid
+> it to do full unattended install?
+>
+
+Either use --auto, or be specific (add all packages you get a question 
+about):
+urpmi -v --replacefiles --ignoresize --urpmi-root ${ROOT} basesystem 
+openssh-server ntpd grub sysvinit
+
+And if you dont need the kernel, you can use basesystem-minimal and dont 
+need to specify grub
+
+--
+Thomas
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005200.html b/zarb-ml/mageia-dev/2011-June/005200.html new file mode 100644 index 000000000..e2fd02b02 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005200.html @@ -0,0 +1,115 @@ + + + + [Mageia-dev] automatic chroot install using urpmi + + + + + + + + + +

[Mageia-dev] automatic chroot install using urpmi

+ Vasiliy G Tolstov + v.tolstov at selfip.ru +
+ Wed Jun 8 14:26:35 CEST 2011 +

+
+ +
On Wed, 2011-06-08 at 15:23 +0300, Thomas Backlund wrote:
+> Vasiliy G Tolstov skrev 8.6.2011 15:14:
+> > Hello. I'm glad to announce, that mageia linux is in testing mode on our
+> > cloud vps hosting (clodo.ru).
+> > After build image i have one question - is that possible to do fully
+> > automatic install with this script:
+> >
+> > #!/bin/bash
+> >
+> > export LC_ALL=C
+> >
+> > ROOT=$1
+> > ARCH=$2
+> > VERSION=$3
+> >
+> > mount -o bind /dev ${ROOT}/dev/
+> > mount -o bind /sys ${ROOT}/sys/
+> > mount -t proc none ${ROOT}/proc/
+> >
+> > if [ "x${ARCH}" != "xx86_64" ] ; then
+> >    ARCH="i586"
+> > fi
+> >
+> > urpmi.addmedia --urpmi-root ${ROOT} --distrib
+> > http://ftp.cc.uoc.gr/mirrors/linux/mageia/distrib/${VERSION}/${ARCH}
+> > urpmi -v --replacefiles --ignoresize --urpmi-root ${ROOT} basesystem
+> > urpmi -v --replacefiles --ignoresize --urpmi-root ${ROOT} openssh-server
+> > ntpd
+> 
+> No need to make it 2 steps, you can push all in one go...
+> 
+> 
+> >
+> > One problem is: urpmi try to get answers for installing default init
+> > system, default boot loader and some other questions.... How can i avoid
+> > it to do full unattended install?
+> >
+> 
+> Either use --auto, or be specific (add all packages you get a question 
+> about):
+> urpmi -v --replacefiles --ignoresize --urpmi-root ${ROOT} basesystem 
+> openssh-server ntpd grub sysvinit
+> 
+> And if you dont need the kernel, you can use basesystem-minimal and dont 
+> need to specify grub
+> 
+> --
+> Thomas
+
+Thank's for answer. Very well. If i use basesystem-minimal and append
+grub systemd ntpd openssh-server and kernel, does that system can
+boot-up ?
+
+-- 
+Vasiliy G Tolstov <v.tolstov at selfip.ru>
+Selfip.Ru
+
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005201.html b/zarb-ml/mageia-dev/2011-June/005201.html new file mode 100644 index 000000000..cb84f8f54 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005201.html @@ -0,0 +1,136 @@ + + + + [Mageia-dev] Re Skype Version + + + + + + + + + +

[Mageia-dev] Re Skype Version

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Wed Jun 8 14:34:26 CEST 2011 +

+
+ +
Hi,
+
+[Friendly request: Please try not to post HTML messages to this list and
+also please try to quote properly. As your mail client broke the
+threading, and no parts of the original message were quoted, it is very
+hard to tell to which message you were replying!!]
+
+'Twas brillig, and brianbailey10 at aol.com at 07/06/11 19:17 did gyre and
+gimble:
+> Hi, I don't have a problem or issue using Skype, this was a reply to
+> someone who was asking what version Skype would work. 
+
+Hmm, sorry, the message did not look like a reply. I don't see the
+original message there, and there is no "Re: " prefix on the subject...
+perhaps this is just your mail client being weird as mentioned above.
+
+
+> As I said if a
+> later version is used which happens to be a beta problems may occur when
+> trying to configure the sound and audio devices
+
+What problems do you refer to?
+
+> - bearing in mind Skype
+> is a closed source code and I doubt if it's possible to change things
+> within Skype!
+
+I'm relatively friendly with some Skype devs and have helped them in the
+past with PulseAudio support, so this is not beyond the realms of
+possibility.
+
+> I have used Skype for over 5
+> years on a daily basis running both under Windows (various versions) and
+> Mandriva Linux, and the version I stated works well on my system using
+> various USB devices which can be configured via Kmix, the newer beta
+>  version appears to have issues in selecting audio devices, I would
+> suggest that you download both versions (old and the new beta) and try
+> them out. 
+
+This is perhaps a misinterpretation of how things should work these
+days. Individual applications should generally not "select the audio
+devices" themselves but leave it up to a central GUI to do that. When
+run with PulseAudio you can use Skype and select which devices you want
+to use via the System Settings -> Multimedia device by selecting the
+appropriate devices for the "Communications" category. Either that or
+you can wait until Skype is running and then use Kmix to move Skypes
+streams to the appropriate devices by right clicking on the skype
+streams in the Playback or Recording tabs and selecting from the Move...
+submenu.
+
+Central GUI to configure all applications. No need to hunt around in
+individual applications for strange and hidden configuration options!
+Progress!
+
+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-June/005202.html b/zarb-ml/mageia-dev/2011-June/005202.html new file mode 100644 index 000000000..d94bc0383 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005202.html @@ -0,0 +1,127 @@ + + + + [Mageia-dev] automatic chroot install using urpmi + + + + + + + + + +

[Mageia-dev] automatic chroot install using urpmi

+ Vasiliy G Tolstov + v.tolstov at selfip.ru +
+ Wed Jun 8 15:19:32 CEST 2011 +

+
+ +
On Wed, 2011-06-08 at 16:26 +0400, Vasiliy G Tolstov wrote:
+> On Wed, 2011-06-08 at 15:23 +0300, Thomas Backlund wrote:
+> > Vasiliy G Tolstov skrev 8.6.2011 15:14:
+> > > Hello. I'm glad to announce, that mageia linux is in testing mode on our
+> > > cloud vps hosting (clodo.ru).
+> > > After build image i have one question - is that possible to do fully
+> > > automatic install with this script:
+> > >
+> > > #!/bin/bash
+> > >
+> > > export LC_ALL=C
+> > >
+> > > ROOT=$1
+> > > ARCH=$2
+> > > VERSION=$3
+> > >
+> > > mount -o bind /dev ${ROOT}/dev/
+> > > mount -o bind /sys ${ROOT}/sys/
+> > > mount -t proc none ${ROOT}/proc/
+> > >
+> > > if [ "x${ARCH}" != "xx86_64" ] ; then
+> > >    ARCH="i586"
+> > > fi
+> > >
+> > > urpmi.addmedia --urpmi-root ${ROOT} --distrib
+> > > http://ftp.cc.uoc.gr/mirrors/linux/mageia/distrib/${VERSION}/${ARCH}
+> > > urpmi -v --replacefiles --ignoresize --urpmi-root ${ROOT} basesystem
+> > > urpmi -v --replacefiles --ignoresize --urpmi-root ${ROOT} openssh-server
+> > > ntpd
+> > 
+> > No need to make it 2 steps, you can push all in one go...
+> > 
+> > 
+> > >
+> > > One problem is: urpmi try to get answers for installing default init
+> > > system, default boot loader and some other questions.... How can i avoid
+> > > it to do full unattended install?
+> > >
+> > 
+> > Either use --auto, or be specific (add all packages you get a question 
+> > about):
+> > urpmi -v --replacefiles --ignoresize --urpmi-root ${ROOT} basesystem 
+> > openssh-server ntpd grub sysvinit
+> > 
+> > And if you dont need the kernel, you can use basesystem-minimal and dont 
+> > need to specify grub
+> > 
+> > --
+> > Thomas
+> 
+> Thank's for answer. Very well. If i use basesystem-minimal and append
+> grub systemd ntpd openssh-server and kernel, does that system can
+> boot-up ?
+> 
+
+
+Hmm. I change cmd line to:
+urpmi -v --replacefiles --ignoresize --urpmi-root ${ROOT}
+basesystem-minimal openssh-server ntpd grub vim man rsyslog systemd
+systemd-sysvinit
+
+But basesystem-minimal depends of polkit-gnome, pinentry-gtk2 why? this
+is server... Or i need many stuff from X to run software under server?
+
+
+
+-- 
+Vasiliy G Tolstov <v.tolstov at selfip.ru>
+Selfip.Ru
+
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005203.html b/zarb-ml/mageia-dev/2011-June/005203.html new file mode 100644 index 000000000..419317528 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005203.html @@ -0,0 +1,128 @@ + + + + [Mageia-dev] automatic chroot install using urpmi + + + + + + + + + +

[Mageia-dev] automatic chroot install using urpmi

+ Michael Scherer + misc at zarb.org +
+ Wed Jun 8 16:12:06 CEST 2011 +

+
+ +
Le mercredi 08 juin 2011 à 17:19 +0400, Vasiliy G Tolstov a écrit :
+> On Wed, 2011-06-08 at 16:26 +0400, Vasiliy G Tolstov wrote:
+> > On Wed, 2011-06-08 at 15:23 +0300, Thomas Backlund wrote:
+> > > Vasiliy G Tolstov skrev 8.6.2011 15:14:
+> > > > Hello. I'm glad to announce, that mageia linux is in testing mode on our
+> > > > cloud vps hosting (clodo.ru).
+> > > > After build image i have one question - is that possible to do fully
+> > > > automatic install with this script:
+> > > >
+> > > > #!/bin/bash
+> > > >
+> > > > export LC_ALL=C
+> > > >
+> > > > ROOT=$1
+> > > > ARCH=$2
+> > > > VERSION=$3
+> > > >
+> > > > mount -o bind /dev ${ROOT}/dev/
+> > > > mount -o bind /sys ${ROOT}/sys/
+> > > > mount -t proc none ${ROOT}/proc/
+> > > >
+> > > > if [ "x${ARCH}" != "xx86_64" ] ; then
+> > > >    ARCH="i586"
+> > > > fi
+> > > >
+> > > > urpmi.addmedia --urpmi-root ${ROOT} --distrib
+> > > > http://ftp.cc.uoc.gr/mirrors/linux/mageia/distrib/${VERSION}/${ARCH}
+> > > > urpmi -v --replacefiles --ignoresize --urpmi-root ${ROOT} basesystem
+> > > > urpmi -v --replacefiles --ignoresize --urpmi-root ${ROOT} openssh-server
+> > > > ntpd
+> > > 
+> > > No need to make it 2 steps, you can push all in one go...
+> > > 
+> > > 
+> > > >
+> > > > One problem is: urpmi try to get answers for installing default init
+> > > > system, default boot loader and some other questions.... How can i avoid
+> > > > it to do full unattended install?
+> > > >
+> > > 
+> > > Either use --auto, or be specific (add all packages you get a question 
+> > > about):
+> > > urpmi -v --replacefiles --ignoresize --urpmi-root ${ROOT} basesystem 
+> > > openssh-server ntpd grub sysvinit
+> > > 
+> > > And if you dont need the kernel, you can use basesystem-minimal and dont 
+> > > need to specify grub
+> > > 
+> > > --
+> > > Thomas
+> > 
+> > Thank's for answer. Very well. If i use basesystem-minimal and append
+> > grub systemd ntpd openssh-server and kernel, does that system can
+> > boot-up ?
+> > 
+> 
+> 
+> Hmm. I change cmd line to:
+> urpmi -v --replacefiles --ignoresize --urpmi-root ${ROOT}
+> basesystem-minimal openssh-server ntpd grub vim man rsyslog systemd
+> systemd-sysvinit
+> 
+> But basesystem-minimal depends of polkit-gnome, pinentry-gtk2 why? this
+> is server... Or i need many stuff from X to run software under server?
+
+Try with --no-suggests
+
+
+-- 
+Michael Scherer
+
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005204.html b/zarb-ml/mageia-dev/2011-June/005204.html new file mode 100644 index 000000000..9c93d396e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005204.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] Tonight's meeting + + + + + + + + + +

[Mageia-dev] Tonight's meeting

+ Anne nicolas + ennael at mageia.org +
+ Wed Jun 8 16:31:40 CEST 2011 +

+
+ +
2011/6/8 Anne nicolas <ennael at mageia.org>
+
+> Hi there
+>
+> Now that release is out, let restart our weekly meetings on #mageia-dev at
+> 19h UTC.
+>
+> Here are the topics:
+>
+> - short review of Mageia 1 launch
+> - organize post-portem for packagers team
+> - start brainstorm on release cycle
+> - relaunch mentoring
+>
+
+adding
+- start and organize discussions about first technical specifications
+
+
+>
+> As usual feel free to comment or propose any other topic
+>
+> Cheers
+>
+> --
+> Anne
+> http://www.mageia.org
+>
+
+
+
+-- 
+Anne
+http://www.mageia.org
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110608/8d64b1c9/attachment-0001.html>
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005205.html b/zarb-ml/mageia-dev/2011-June/005205.html new file mode 100644 index 000000000..560da09e8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005205.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Michael Scherer + misc at zarb.org +
+ Wed Jun 8 18:44:29 CEST 2011 +

+
+ +
Le mercredi 08 juin 2011 à 10:40 +0200, Anne nicolas a écrit :
+> Hi there
+> 
+> We have some stuff to complete here:
+> http://mageia.org/wiki/doku.php?id=security
+> 
+> <http://mageia.org/wiki/doku.php?id=security>Can we spend the 2 or 3 coming
+> days to finalize it and start updates submits?
+
+Pascal is working on this.
+
+So here is a proposal :
+- anybody can submit a package to updates_testing. 
+- once submitted to testing, it should ask to QA to test, along with :
+  - a reason for the update ( likely bug number )
+  - potentially a priority ( ie, if this is just a translation update or
+a urgent 0 day exploit ) 
+  - a way to test the bug and see it is fixed
+  - text for the update 
+
+- qa validate the update ( with process to define )
+
+- someone move the package from updates_testing to testing 
+- the bug is closed
+- a announce is sent ( on various medias to be defined ), with the text
+of update 
+
+
+So the points are : 
+- no update can be uploaded without QA validation
+- QA manage the checks, and so will requires help ( hence the security
+team or any packager can help, provided they know how to do QA )
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005206.html b/zarb-ml/mageia-dev/2011-June/005206.html new file mode 100644 index 000000000..ff6723030 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005206.html @@ -0,0 +1,110 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Wed Jun 8 18:48:49 CEST 2011 +

+
+ +
On 8 June 2011 18:44, Michael Scherer <misc at zarb.org> wrote:
+> Le mercredi 08 juin 2011 à 10:40 +0200, Anne nicolas a écrit :
+>> Hi there
+>>
+>> We have some stuff to complete here:
+>> http://mageia.org/wiki/doku.php?id=security
+>>
+>> <http://mageia.org/wiki/doku.php?id=security>Can we spend the 2 or 3 coming
+>> days to finalize it and start updates submits?
+>
+> Pascal is working on this.
+>
+> So here is a proposal :
+> - anybody can submit a package to updates_testing.
+> - once submitted to testing, it should ask to QA to test, along with :
+>  - a reason for the update ( likely bug number )
+>  - potentially a priority ( ie, if this is just a translation update or
+> a urgent 0 day exploit )
+>  - a way to test the bug and see it is fixed
+>  - text for the update
+>
+> - qa validate the update ( with process to define )
+>
+> - someone move the package from updates_testing to testing
+
+Isn't it cleaner to rebuild when submitting to */updates? instead of moving.
+
+> - the bug is closed
+> - a announce is sent ( on various medias to be defined ), with the text
+> of update
+>
+>
+> So the points are :
+> - no update can be uploaded without QA validation
+> - QA manage the checks, and so will requires help ( hence the security
+> team or any packager can help, provided they know how to do QA )
+>
+> --
+> Michael Scherer
+>
+>
+
+
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005207.html b/zarb-ml/mageia-dev/2011-June/005207.html new file mode 100644 index 000000000..f78b2ce88 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005207.html @@ -0,0 +1,119 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Wed Jun 8 18:57:40 CEST 2011 +

+
+ +
On Wed, 8 Jun 2011, Michael Scherer wrote:
+
+> Le mercredi 08 juin 2011 à 10:40 +0200, Anne nicolas a écrit :
+>> Hi there
+>>
+>> We have some stuff to complete here:
+>> http://mageia.org/wiki/doku.php?id=security
+>>
+>> <http://mageia.org/wiki/doku.php?id=security>Can we spend the 2 or 3 coming
+>> days to finalize it and start updates submits?
+>
+> Pascal is working on this.
+>
+> So here is a proposal :
+> - anybody can submit a package to updates_testing.
+> - once submitted to testing, it should ask to QA to test, along with :
+>  - a reason for the update ( likely bug number )
+>  - potentially a priority ( ie, if this is just a translation update or
+> a urgent 0 day exploit )
+>  - a way to test the bug and see it is fixed
+>  - text for the update
+
+> - qa validate the update ( with process to define )
+
+> - someone move the package from updates_testing to testing
+
+Someone from security (stable updates) team I guess?
+
+> - the bug is closed
+> - a announce is sent ( on various medias to be defined ), with the text
+> of update
+
+So who decides to reject an update and at what point? According to your 
+proposal, either QA people decide this or they waste time on updates that 
+later get rejected.
+
+> So the points are :
+> - no update can be uploaded without QA validation
+
+What does 'QA validation' mean exactly, can only certain people do it...?
+
+> - QA manage the checks, and so will requires help ( hence the security
+> team or any packager can help, provided they know how to do QA )
+
+So a packager wants to fix a bug in package that is not very visible, 
+sends it to QA, then has to test it anyway? I'm not sure what you're 
+saying here.
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005208.html b/zarb-ml/mageia-dev/2011-June/005208.html new file mode 100644 index 000000000..aa06867b3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005208.html @@ -0,0 +1,151 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Wed Jun 8 19:39:55 CEST 2011 +

+
+ +
On 8 June 2011 18:57, Christiaan Welvaart <cjw at daneel.dyndns.org> wrote:
+> On Wed, 8 Jun 2011, Michael Scherer wrote:
+>
+>> Le mercredi 08 juin 2011 à 10:40 +0200, Anne nicolas a écrit :
+>>>
+>>> Hi there
+>>>
+>>> We have some stuff to complete here:
+>>> http://mageia.org/wiki/doku.php?id=security
+>>>
+>>> <http://mageia.org/wiki/doku.php?id=security>Can we spend the 2 or 3
+>>> coming
+>>> days to finalize it and start updates submits?
+>>
+>> Pascal is working on this.
+>>
+>> So here is a proposal :
+>> - anybody can submit a package to updates_testing.
+>> - once submitted to testing, it should ask to QA to test, along with :
+>>  - a reason for the update ( likely bug number )
+>>  - potentially a priority ( ie, if this is just a translation update or
+>> a urgent 0 day exploit )
+>>  - a way to test the bug and see it is fixed
+>>  - text for the update
+>
+>> - qa validate the update ( with process to define )
+>
+>> - someone move the package from updates_testing to testing
+>
+> Someone from security (stable updates) team I guess?
+>
+>> - the bug is closed
+>> - a announce is sent ( on various medias to be defined ), with the text
+>> of update
+>
+> So who decides to reject an update and at what point? According to your
+> proposal, either QA people decide this or they waste time on updates that
+> later get rejected.
+>
+
+IMHO, rejection reasons:
+- The sec team doesn't think the update fixes a serious security
+vulnerability; so it's not updates but backports
+- The QA team couldn't validate, i.e. using the test case in the bug
+report, their test results didn't show that the bug is fixed
+
+>> So the points are :
+>> - no update can be uploaded without QA validation
+>
+> What does 'QA validation' mean exactly, can only certain people do it...?
+>
+
+IIUC, QA validation is that they use the test case given in the
+report; an example of a test case:
+- install package foo-1mga1 from */release
+- do foo bar, notice the app crashes
+- install the fixed package foo-1.1mga1 from */updates_testing
+- test again, the bug should be fixed
+
+if any of these steps fail, then it's not gonna get pushed as an
+update. And it should be the QA team doing the validation, i.e.
+experienced devs/packagers in the that team.
+
+>> - QA manage the checks, and so will requires help ( hence the security
+>> team or any packager can help, provided they know how to do QA )
+>
+> So a packager wants to fix a bug in package that is not very visible, sends
+> it to QA, then has to test it anyway? I'm not sure what you're saying here.
+>
+
+Not the packager committing the fix, (if he doesn't think it's fixed
+he won't ask for an update to begin with). But the QA team, this team
+could/should have packagers in it.
+
+>
+>    Christiaan
+>
+
+
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005209.html b/zarb-ml/mageia-dev/2011-June/005209.html new file mode 100644 index 000000000..dfe5b8cf2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005209.html @@ -0,0 +1,163 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Wed Jun 8 19:41:13 CEST 2011 +

+
+ +
On 8 June 2011 19:39, Ahmad Samir <ahmadsamir3891 at gmail.com> wrote:
+> On 8 June 2011 18:57, Christiaan Welvaart <cjw at daneel.dyndns.org> wrote:
+>> On Wed, 8 Jun 2011, Michael Scherer wrote:
+>>
+>>> Le mercredi 08 juin 2011 à 10:40 +0200, Anne nicolas a écrit :
+>>>>
+>>>> Hi there
+>>>>
+>>>> We have some stuff to complete here:
+>>>> http://mageia.org/wiki/doku.php?id=security
+>>>>
+>>>> <http://mageia.org/wiki/doku.php?id=security>Can we spend the 2 or 3
+>>>> coming
+>>>> days to finalize it and start updates submits?
+>>>
+>>> Pascal is working on this.
+>>>
+>>> So here is a proposal :
+>>> - anybody can submit a package to updates_testing.
+>>> - once submitted to testing, it should ask to QA to test, along with :
+>>>  - a reason for the update ( likely bug number )
+>>>  - potentially a priority ( ie, if this is just a translation update or
+>>> a urgent 0 day exploit )
+>>>  - a way to test the bug and see it is fixed
+>>>  - text for the update
+>>
+>>> - qa validate the update ( with process to define )
+>>
+>>> - someone move the package from updates_testing to testing
+>>
+>> Someone from security (stable updates) team I guess?
+>>
+>>> - the bug is closed
+>>> - a announce is sent ( on various medias to be defined ), with the text
+>>> of update
+>>
+>> So who decides to reject an update and at what point? According to your
+>> proposal, either QA people decide this or they waste time on updates that
+>> later get rejected.
+>>
+>
+> IMHO, rejection reasons:
+> - The sec team doesn't think the update fixes a serious security
+> vulnerability; so it's not updates but backports
+> - The QA team couldn't validate, i.e. using the test case in the bug
+> report, their test results didn't show that the bug is fixed
+>
+
+Adding to this:
+- the bug is fixed, but it caused regressions somewhere else in the
+package itself, or in packages depending on it.
+
+>>> So the points are :
+>>> - no update can be uploaded without QA validation
+>>
+>> What does 'QA validation' mean exactly, can only certain people do it...?
+>>
+>
+> IIUC, QA validation is that they use the test case given in the
+> report; an example of a test case:
+> - install package foo-1mga1 from */release
+> - do foo bar, notice the app crashes
+> - install the fixed package foo-1.1mga1 from */updates_testing
+> - test again, the bug should be fixed
+>
+> if any of these steps fail, then it's not gonna get pushed as an
+> update. And it should be the QA team doing the validation, i.e.
+> experienced devs/packagers in the that team.
+>
+>>> - QA manage the checks, and so will requires help ( hence the security
+>>> team or any packager can help, provided they know how to do QA )
+>>
+>> So a packager wants to fix a bug in package that is not very visible, sends
+>> it to QA, then has to test it anyway? I'm not sure what you're saying here.
+>>
+>
+> Not the packager committing the fix, (if he doesn't think it's fixed
+> he won't ask for an update to begin with). But the QA team, this team
+> could/should have packagers in it.
+>
+>>
+>>    Christiaan
+>>
+>
+>
+>
+> --
+> Ahmad Samir
+>
+
+
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005210.html b/zarb-ml/mageia-dev/2011-June/005210.html new file mode 100644 index 000000000..b0af599d8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005210.html @@ -0,0 +1,89 @@ + + + + [Mageia-dev] Discrepancy between /etc/version and /etc/release - which one for MIRRORLIST + + + + + + + + + +

[Mageia-dev] Discrepancy between /etc/version and /etc/release - which one for MIRRORLIST

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Wed Jun 8 19:45:56 CEST 2011 +

+
+ +
On 8 June 2011 14:10, James Kerr <jim at jkerr82508.free-online.co.uk> wrote:
+> On 08/06/11 08:42, Oliver Burger wrote:
+>>
+>> Hi,
+>>
+>> after some discussion in the German forums, I saw, that there are
+>> discrepancies between /etc/version and /etc/release, both coming from
+>> the mageia-release-common-1-2.mga1 package.
+>>
+>> While /etc/release calls my system
+>> ----------
+>> Mageia release 1 (Official) for i586
+>> ----------
+>>
+>> it is called
+>> ----------
+>> 1 2 cauldron
+>> ----------
+>>
+>> by /etc/version.
+>>
+>> Which one of those defines the branch used by MIRRORLIST
+>
+> I thought that /etc/product.id was used.
+>
+> Jim
+>
+>
+
+AFAIK, yes, /etc/product.id is what urpmi uses to parse the MIRRORLIST
+parameters.
+
+-- 
+Ahmad Samir
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005211.html b/zarb-ml/mageia-dev/2011-June/005211.html new file mode 100644 index 000000000..36ebed6e7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005211.html @@ -0,0 +1,82 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Samuel Verschelde + stormi at laposte.net +
+ Wed Jun 8 21:45:26 CEST 2011 +

+
+ +
Le mercredi 8 juin 2011 19:39:55, Ahmad Samir a écrit :
+> IMHO, rejection reasons:
+> - The sec team doesn't think the update fixes a serious security
+> vulnerability; so it's not updates but backports
+
+What about bugfix updates ? I guess fixing a bug is a valid reason for an 
+update, like it was in Mandriva's updates.
+
+Regards
+
+Samuel
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110608/e67eb0ca/attachment-0001.html>
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005212.html b/zarb-ml/mageia-dev/2011-June/005212.html new file mode 100644 index 000000000..f807549a3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005212.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Wed Jun 8 22:23:29 CEST 2011 +

+
+ +
On 8 June 2011 21:45, Samuel Verschelde <stormi at laposte.net> wrote:
+> Le mercredi 8 juin 2011 19:39:55, Ahmad Samir a écrit :
+>
+>> IMHO, rejection reasons:
+>
+>> - The sec team doesn't think the update fixes a serious security
+>
+>> vulnerability; so it's not updates but backports
+>
+> What about bugfix updates ? I guess fixing a bug is a valid reason for an
+> update, like it was in Mandriva's updates.
+>
+> Regards
+>
+> Samuel
+
+Right, I probably phrased that one wrongly; I meant:
+fixes a serious bug, e.g. crashing, segfaulting
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005213.html b/zarb-ml/mageia-dev/2011-June/005213.html new file mode 100644 index 000000000..172382c62 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005213.html @@ -0,0 +1,106 @@ + + + + [Mageia-dev] mageia sound task + + + + + + + + + +

[Mageia-dev] mageia sound task

+ Sascha Schneider + ungleichklang at gmail.com +
+ Wed Jun 8 22:28:30 CEST 2011 +

+
+ +
after 6 month of pausing this topic I would like to reactivate it.
+
+Now that release 1 is out it might be woth for further toughts and a
+lot of fun work :)
+
+http://www.mageia.org/wiki/doku.php?id=soundstudio
+
+I didn't rest thinking on this idea:
+my latest idea is to mame a bash-script with dialog to configure
+proaudio on mageia.
+
+Join if you like and share your ideas :)
+
+Greetings from belgium, sascha
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005214.html b/zarb-ml/mageia-dev/2011-June/005214.html new file mode 100644 index 000000000..5d236b8c2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005214.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] mageia sound task + + + + + + + + + +

[Mageia-dev] mageia sound task

+ José Jorge + jjorge at free.fr +
+ Wed Jun 8 22:51:02 CEST 2011 +

+
+ +
Le mercredi 8 juin 2011 22:28:30, Sascha Schneider a écrit :
+> my latest idea is to mame a bash-script with dialog to configure
+> proaudio on mageia.
+
+What do you mean by 'configure proaudio'?
+
+I think the only needed thing is "pasuspender jackd" to use proaudio tools.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005215.html b/zarb-ml/mageia-dev/2011-June/005215.html new file mode 100644 index 000000000..dea7c9e14 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005215.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] mageia sound task + + + + + + + + + +

[Mageia-dev] mageia sound task

+ Sascha Schneider + ungleichklang at gmail.com +
+ Wed Jun 8 22:58:24 CEST 2011 +

+
+ +
Hi Jose,
+
+I meant ...... configure mageia to use this distro for "professional"
+audio stuff, like ardour, qtractor, qmidiarp ........
+
+
+2011/6/8 José Jorge <jjorge at free.fr>:
+> Le mercredi 8 juin 2011 22:28:30, Sascha Schneider a écrit :
+>> my latest idea is to mame a bash-script with dialog to configure
+>> proaudio on mageia.
+>
+> What do you mean by 'configure proaudio'?
+>
+> I think the only needed thing is "pasuspender jackd" to use proaudio tools.
+>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005216.html b/zarb-ml/mageia-dev/2011-June/005216.html new file mode 100644 index 000000000..6a0d204fc --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005216.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Michael Scherer + misc at zarb.org +
+ Wed Jun 8 23:31:00 CEST 2011 +

+
+ +
Le mercredi 08 juin 2011 à 19:48 +0300, Ahmad Samir a écrit :
+> On 8 June 2011 18:44, Michael Scherer <misc at zarb.org> wrote:
+> > Le mercredi 08 juin 2011 à 10:40 +0200, Anne nicolas a écrit :
+> >> Hi there
+> >>
+> >> We have some stuff to complete here:
+> >> http://mageia.org/wiki/doku.php?id=security
+> >>
+> >> <http://mageia.org/wiki/doku.php?id=security>Can we spend the 2 or 3 coming
+> >> days to finalize it and start updates submits?
+> >
+> > Pascal is working on this.
+> >
+> > So here is a proposal :
+> > - anybody can submit a package to updates_testing.
+> > - once submitted to testing, it should ask to QA to test, along with :
+> >  - a reason for the update ( likely bug number )
+> >  - potentially a priority ( ie, if this is just a translation update or
+> > a urgent 0 day exploit )
+> >  - a way to test the bug and see it is fixed
+> >  - text for the update
+> >
+> > - qa validate the update ( with process to define )
+> >
+> > - someone move the package from updates_testing to testing
+> 
+> Isn't it cleaner to rebuild when submitting to */updates? instead of moving.
+
+Well, that depend on the way package is built. In fact, it should not
+matter much, as we should not do a change that could break a existing
+software in update, and so this should be the same in updates_testing
+( ie, they should be the same wrto ABI )
+
+But that's also why I ask here :)
+
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005217.html b/zarb-ml/mageia-dev/2011-June/005217.html new file mode 100644 index 000000000..1252a5a2c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005217.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Stew Benedict + stewbintn at gmail.com +
+ Wed Jun 8 23:38:00 CEST 2011 +

+
+ +
On 06/08/2011 05:31 PM, Michael Scherer wrote:
+> Le mercredi 08 juin 2011 à 19:48 +0300, Ahmad Samir a écrit :
+>> On 8 June 2011 18:44, Michael Scherer<misc at zarb.org>  wrote:
+>>> Le mercredi 08 juin 2011 à 10:40 +0200, Anne nicolas a écrit :
+>>>> Hi there
+>>>>
+>>>> We have some stuff to complete here:
+>>>> http://mageia.org/wiki/doku.php?id=security
+>>>>
+>>>> <http://mageia.org/wiki/doku.php?id=security>Can we spend the 2 or 3 coming
+>>>> days to finalize it and start updates submits?
+>>> Pascal is working on this.
+>>>
+>>> So here is a proposal :
+>>> - anybody can submit a package to updates_testing.
+>>> - once submitted to testing, it should ask to QA to test, along with :
+>>>   - a reason for the update ( likely bug number )
+>>>   - potentially a priority ( ie, if this is just a translation update or
+>>> a urgent 0 day exploit )
+>>>   - a way to test the bug and see it is fixed
+>>>   - text for the update
+>>>
+>>> - qa validate the update ( with process to define )
+>>>
+>>> - someone move the package from updates_testing to testing
+>> Isn't it cleaner to rebuild when submitting to */updates? instead of moving.
+> Well, that depend on the way package is built. In fact, it should not
+> matter much, as we should not do a change that could break a existing
+> software in update, and so this should be the same in updates_testing
+> ( ie, they should be the same wrto ABI )
+>
+> But that's also why I ask here :)
+>
+>
+If you're going to rebuild *after* QA, you've just invalidated your QA. 
+(yeah, I know it *should* be the same, but stuff happens)
+
+
+-- 
+Stew Benedict
+New Tazewell, TN
+
+
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005218.html b/zarb-ml/mageia-dev/2011-June/005218.html new file mode 100644 index 000000000..37f5118d8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005218.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] mageia sound task + + + + + + + + + +

[Mageia-dev] mageia sound task

+ José Jorge + jjorge at free.fr +
+ Wed Jun 8 23:38:21 CEST 2011 +

+
+ +
Le mercredi 8 juin 2011 22:58:24, Sascha Schneider a écrit :
+> I meant ...... configure mageia to use this distro for "professional"
+> audio stuff, like ardour, qtractor, qmidiarp ........
+
+Yes, this is what I have understood. And pasuspender is the only thing I do to 
+use them. So I wonder what more should the script do?
+
+ML : Please, answer at the end of the message.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005219.html b/zarb-ml/mageia-dev/2011-June/005219.html new file mode 100644 index 000000000..45cbde71e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005219.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Anssi Hannula + anssi.hannula at iki.fi +
+ Wed Jun 8 23:40:52 CEST 2011 +

+
+ +
On 08.06.2011 23:23, Ahmad Samir wrote:
+> On 8 June 2011 21:45, Samuel Verschelde <stormi at laposte.net> wrote:
+>> Le mercredi 8 juin 2011 19:39:55, Ahmad Samir a écrit :
+>>
+>>> IMHO, rejection reasons:
+>>
+>>> - The sec team doesn't think the update fixes a serious security
+>>
+>>> vulnerability; so it's not updates but backports
+>>
+>> What about bugfix updates ? I guess fixing a bug is a valid reason for an
+>> update, like it was in Mandriva's updates.
+>>
+>> Regards
+>>
+>> Samuel
+> 
+> Right, I probably phrased that one wrongly; I meant:
+> fixes a serious bug, e.g. crashing, segfaulting
+
+I don't think we should exclude non-serious bugs :)
+
+(or version updates in some cases, like firefox/opera/flash or updating
+an rc/beta version to a stable one, and maybe some online games that are
+useless unless on latest version)
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005220.html b/zarb-ml/mageia-dev/2011-June/005220.html new file mode 100644 index 000000000..808c7bd7b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005220.html @@ -0,0 +1,125 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Wed Jun 8 23:48:01 CEST 2011 +

+
+ +
On 8 June 2011 23:38, Stew Benedict <stewbintn at gmail.com> wrote:
+> On 06/08/2011 05:31 PM, Michael Scherer wrote:
+>>
+>> Le mercredi 08 juin 2011 à 19:48 +0300, Ahmad Samir a écrit :
+>>>
+>>> On 8 June 2011 18:44, Michael Scherer<misc at zarb.org>  wrote:
+>>>>
+>>>> Le mercredi 08 juin 2011 à 10:40 +0200, Anne nicolas a écrit :
+>>>>>
+>>>>> Hi there
+>>>>>
+>>>>> We have some stuff to complete here:
+>>>>> http://mageia.org/wiki/doku.php?id=security
+>>>>>
+>>>>> <http://mageia.org/wiki/doku.php?id=security>Can we spend the 2 or 3
+>>>>> coming
+>>>>> days to finalize it and start updates submits?
+>>>>
+>>>> Pascal is working on this.
+>>>>
+>>>> So here is a proposal :
+>>>> - anybody can submit a package to updates_testing.
+>>>> - once submitted to testing, it should ask to QA to test, along with :
+>>>>  - a reason for the update ( likely bug number )
+>>>>  - potentially a priority ( ie, if this is just a translation update or
+>>>> a urgent 0 day exploit )
+>>>>  - a way to test the bug and see it is fixed
+>>>>  - text for the update
+>>>>
+>>>> - qa validate the update ( with process to define )
+>>>>
+>>>> - someone move the package from updates_testing to testing
+>>>
+>>> Isn't it cleaner to rebuild when submitting to */updates? instead of
+>>> moving.
+>>
+>> Well, that depend on the way package is built. In fact, it should not
+>> matter much, as we should not do a change that could break a existing
+>> software in update, and so this should be the same in updates_testing
+>> ( ie, they should be the same wrto ABI )
+>>
+>> But that's also why I ask here :)
+>>
+>>
+> If you're going to rebuild *after* QA, you've just invalidated your QA.
+> (yeah, I know it *should* be the same, but stuff happens)
+>
+
+You're right (even if that's never happened for 3-4 years in mdv,
+since sec team rebuilt the packages when pushing to */updates IIRC).
+
+>
+> --
+> Stew Benedict
+> New Tazewell, TN
+>
+>
+>
+
+
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005221.html b/zarb-ml/mageia-dev/2011-June/005221.html new file mode 100644 index 000000000..70ece5826 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005221.html @@ -0,0 +1,115 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Wed Jun 8 23:53:51 CEST 2011 +

+
+ +
On 8 June 2011 23:40, Anssi Hannula <anssi.hannula at iki.fi> wrote:
+> On 08.06.2011 23:23, Ahmad Samir wrote:
+>> On 8 June 2011 21:45, Samuel Verschelde <stormi at laposte.net> wrote:
+>>> Le mercredi 8 juin 2011 19:39:55, Ahmad Samir a écrit :
+>>>
+>>>> IMHO, rejection reasons:
+>>>
+>>>> - The sec team doesn't think the update fixes a serious security
+>>>
+>>>> vulnerability; so it's not updates but backports
+>>>
+>>> What about bugfix updates ? I guess fixing a bug is a valid reason for an
+>>> update, like it was in Mandriva's updates.
+>>>
+>>> Regards
+>>>
+>>> Samuel
+>>
+>> Right, I probably phrased that one wrongly; I meant:
+>> fixes a serious bug, e.g. crashing, segfaulting
+>
+> I don't think we should exclude non-serious bugs :)
+>
+
+Depends, overworking the sec team doesn't look like a good aspect...
+(that's why I liked contrib in mdv, I could push an update any time,
+without having to go though the bug report -> QA -> Sec team loop).
+
+> (or version updates in some cases, like firefox/opera/flash or updating
+> an rc/beta version to a stable one, and maybe some online games that are
+> useless unless on latest version)
+>
+
+I agree, (except for the games part, nowadays if it's less than 4GB
+it's not really a "game").
+
+
+Maybe the sec team should only work on sec fixes, and there should be
+a sub-group of the sec team that handle the not
+CVE|crash|segfaulting|buffer-overflow updates.
+
+> --
+> Anssi Hannula
+>
+
+
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005222.html b/zarb-ml/mageia-dev/2011-June/005222.html new file mode 100644 index 000000000..f44e8cb44 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005222.html @@ -0,0 +1,132 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Michael Scherer + misc at zarb.org +
+ Thu Jun 9 00:09:29 CEST 2011 +

+
+ +
Le mercredi 08 juin 2011 à 20:39 +0300, Ahmad Samir a écrit :
+> On 8 June 2011 18:57, Christiaan Welvaart <cjw at daneel.dyndns.org> wrote:
+
+> > So who decides to reject an update and at what point? According to your
+> > proposal, either QA people decide this or they waste time on updates that
+> > later get rejected.
+> >
+> 
+> IMHO, rejection reasons:
+> - The sec team doesn't think the update fixes a serious security
+> vulnerability; so it's not updates but backports
+
+I would say that there is no version upgrade, unless exception. 
+
+
+> - The QA team couldn't validate, i.e. using the test case in the bug
+> report, their test results didn't show that the bug is fixed
+
+Yup.
+
+Or someone detected a regression.
+( like 'I installed foo-1.0-1 but it opened a dimensional vortex to
+hell', as it happened on the QA testing facility of Phobos in Doom )
+
+> >> - QA manage the checks, and so will requires help ( hence the security
+> >> team or any packager can help, provided they know how to do QA )
+> >
+> > So a packager wants to fix a bug in package that is not very visible, sends
+> > it to QA, then has to test it anyway? I'm not sure what you're saying here.
+> >
+> 
+> Not the packager committing the fix, (if he doesn't think it's fixed
+> he won't ask for an update to begin with). 
+
+Yup :)
+
+> But the QA team, this team
+> could/should have packagers in it.
+
+Or someone could help by doing QA and saying "so far, I see no
+regression", or just saying "I see regression" before some more
+experienced QA member do the test. 
+
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005223.html b/zarb-ml/mageia-dev/2011-June/005223.html new file mode 100644 index 000000000..6a00439ec --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005223.html @@ -0,0 +1,134 @@ + + + + [Mageia-dev] Providing 32-bit flash-player-plugin in x86_64 nonfree? + + + + + + + + + +

[Mageia-dev] Providing 32-bit flash-player-plugin in x86_64 nonfree?

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Thu Jun 9 00:17:07 CEST 2011 +

+
+ +
On 5 June 2011 02:23, Ahmad Samir <ahmadsamir3891 at gmail.com> wrote:
+> On 5 June 2011 01:31, Anssi Hannula <anssi.hannula at iki.fi> 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.
+>
+> A suggests on nspluginwrapper I think; (actually I've never seen
+> nspluginwrapper work... might be my box/setup though).
+>
+> Usually I install the 32bit flash plugin and either use a 32bit
+> browser or 64bit konqueror (which uses the KDE4 wrapper) to watch
+> flash content.
+>
+
+Scratch the part about konqueror, it was using an
+forgotten-by-accident 64bit flash .so on my HD...
+
+>>
+>> Do you think this should be done, or would it add too much confusion?
+>>
+>> --
+>> Anssi Hannula
+>>
+>
+>
+>
+> --
+> Ahmad Samir
+>
+
+
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005224.html b/zarb-ml/mageia-dev/2011-June/005224.html new file mode 100644 index 000000000..d1ab96c5a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005224.html @@ -0,0 +1,123 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Michael Scherer + misc at zarb.org +
+ Thu Jun 9 01:08:08 CEST 2011 +

+
+ +
Le mercredi 08 juin 2011 à 18:57 +0200, Christiaan Welvaart a écrit :
+> On Wed, 8 Jun 2011, Michael Scherer wrote:
+> 
+> > Le mercredi 08 juin 2011 à 10:40 +0200, Anne nicolas a écrit :
+> >> Hi there
+> >>
+> >> We have some stuff to complete here:
+> >> http://mageia.org/wiki/doku.php?id=security
+> >>
+> >> <http://mageia.org/wiki/doku.php?id=security>Can we spend the 2 or 3 coming
+> >> days to finalize it and start updates submits?
+> >
+> > Pascal is working on this.
+> >
+> > So here is a proposal :
+> > - anybody can submit a package to updates_testing.
+> > - once submitted to testing, it should ask to QA to test, along with :
+> >  - a reason for the update ( likely bug number )
+> >  - potentially a priority ( ie, if this is just a translation update or
+> > a urgent 0 day exploit )
+> >  - a way to test the bug and see it is fixed
+> >  - text for the update
+> 
+> > - qa validate the update ( with process to define )
+> 
+> > - someone move the package from updates_testing to testing
+> 
+> Someone from security (stable updates) team I guess?
+
+Someone who type the command would be a admin ( until someone decide to
+write a script for that, and to plug it to the current restricted shell
+framework ).
+
+Who decide exactly what should og or not is open. IE, that the part of
+the process to define.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005225.html b/zarb-ml/mageia-dev/2011-June/005225.html new file mode 100644 index 000000000..06497ac9a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005225.html @@ -0,0 +1,161 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Michael Scherer + misc at zarb.org +
+ Thu Jun 9 01:25:16 CEST 2011 +

+
+ +
Le jeudi 09 juin 2011 à 00:53 +0300, Ahmad Samir a écrit :
+> On 8 June 2011 23:40, Anssi Hannula <anssi.hannula at iki.fi> wrote:
+> > On 08.06.2011 23:23, Ahmad Samir wrote:
+> >> On 8 June 2011 21:45, Samuel Verschelde <stormi at laposte.net> wrote:
+> >>> Le mercredi 8 juin 2011 19:39:55, Ahmad Samir a écrit :
+> >>>
+> >>>> IMHO, rejection reasons:
+> >>>
+> >>>> - The sec team doesn't think the update fixes a serious security
+> >>>
+> >>>> vulnerability; so it's not updates but backports
+> >>>
+> >>> What about bugfix updates ? I guess fixing a bug is a valid reason for an
+> >>> update, like it was in Mandriva's updates.
+> >>>
+> >>> Regards
+> >>>
+> >>> Samuel
+> >>
+> >> Right, I probably phrased that one wrongly; I meant:
+> >> fixes a serious bug, e.g. crashing, segfaulting
+> >
+> > I don't think we should exclude non-serious bugs :)
+> >
+> 
+> Depends, overworking the sec team doesn't look like a good aspect...
+> (that's why I liked contrib in mdv, I could push an update any time,
+> without having to go though the bug report -> QA -> Sec team loop).
+
+Well, I didn't asked to secteam to do anything except managing the
+security aspect : 
+- finding CVE
+- finding patch ( with the help of maintainer )
+- finding test and fixes
+
+But the building and updating should be done by maintainer, as this
+would scale better. Let the security team focus on the security aspect,
+and be there as a help for maintainers and viceversa. We shouldn't
+overload the secteam, while maintainers are here for that :)
+ 
+One of the problem at Mandriva was that security and stable updates were
+quite disconnected from maintainers, and so it didn't scale well. 
+
+It didn't scale because people didn't know security procedure ( it was
+not part of the expected curriculum of a packager, and often was done
+without them implied ), it didn't scale because security was only for a
+restricted set of salaree taking care of everything on separate
+systems. 
+
+I think we should focus on having :
+- a system using already know procedure ( ie regular build system )
+- make sure that taking care of update is something done regulary as
+part as packager duty ( after all, that's the whole part of being
+maintainer )
+
+> > (or version updates in some cases, like firefox/opera/flash or updating
+> > an rc/beta version to a stable one, and maybe some online games that are
+> > useless unless on latest version)
+> >
+> 
+> I agree, (except for the games part, nowadays if it's less than 4GB
+> it's not really a "game").
+
+I guess we can start with a list of exception :
+
+- stuff that should be updated to latest version, because the security
+support for older releases ( firefox, chrome ) is too hard
+-> we update to latest version if there is no regression and a strong
+reason to upgrade ( severe bugfixes, security issue, breakages ). 
+Exception of this category should be very expectional
+
+- stuff where there is strict bugfixes only release
+( postgresql ), or update to a stable version ( which should be a bugfix
+only release when compared to beta/rc :) )
+-> we upgrade to stable ( for rc/beta )
+-> we do version update if it is bug fixes and if the packager is ok
+with it ( and if the rules of the bugfix branches are clearly documented
+) 
+
+- everything else 
+-> only minimal patches
+
+The question of game is still open, ie, should it go in 1st category, or
+should we have different rules to see what should be there or not ?
+
+I guess this would only be for networked game ?
+
+> Maybe the sec team should only work on sec fixes, and there should be
+> a sub-group of the sec team that handle the not
+> CVE|crash|segfaulting|buffer-overflow updates.
+
+segfault, crash are the duty of packager, as well as wrong requires or
+anything.
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005226.html b/zarb-ml/mageia-dev/2011-June/005226.html new file mode 100644 index 000000000..22cef1ed6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005226.html @@ -0,0 +1,170 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Thu Jun 9 01:40:15 CEST 2011 +

+
+ +
On 9 June 2011 01:25, Michael Scherer <misc at zarb.org> wrote:
+> Le jeudi 09 juin 2011 à 00:53 +0300, Ahmad Samir a écrit :
+>> On 8 June 2011 23:40, Anssi Hannula <anssi.hannula at iki.fi> wrote:
+>> > On 08.06.2011 23:23, Ahmad Samir wrote:
+>> >> On 8 June 2011 21:45, Samuel Verschelde <stormi at laposte.net> wrote:
+>> >>> Le mercredi 8 juin 2011 19:39:55, Ahmad Samir a écrit :
+>> >>>
+>> >>>> IMHO, rejection reasons:
+>> >>>
+>> >>>> - The sec team doesn't think the update fixes a serious security
+>> >>>
+>> >>>> vulnerability; so it's not updates but backports
+>> >>>
+>> >>> What about bugfix updates ? I guess fixing a bug is a valid reason for an
+>> >>> update, like it was in Mandriva's updates.
+>> >>>
+>> >>> Regards
+>> >>>
+>> >>> Samuel
+>> >>
+>> >> Right, I probably phrased that one wrongly; I meant:
+>> >> fixes a serious bug, e.g. crashing, segfaulting
+>> >
+>> > I don't think we should exclude non-serious bugs :)
+>> >
+>>
+>> Depends, overworking the sec team doesn't look like a good aspect...
+>> (that's why I liked contrib in mdv, I could push an update any time,
+>> without having to go though the bug report -> QA -> Sec team loop).
+>
+> Well, I didn't asked to secteam to do anything except managing the
+> security aspect :
+> - finding CVE
+> - finding patch ( with the help of maintainer )
+> - finding test and fixes
+>
+> But the building and updating should be done by maintainer, as this
+> would scale better. Let the security team focus on the security aspect,
+> and be there as a help for maintainers and viceversa. We shouldn't
+> overload the secteam, while maintainers are here for that :)
+>
+> One of the problem at Mandriva was that security and stable updates were
+> quite disconnected from maintainers, and so it didn't scale well.
+>
+> It didn't scale because people didn't know security procedure ( it was
+> not part of the expected curriculum of a packager, and often was done
+> without them implied ), it didn't scale because security was only for a
+> restricted set of salaree taking care of everything on separate
+> systems.
+>
+> I think we should focus on having :
+> - a system using already know procedure ( ie regular build system )
+> - make sure that taking care of update is something done regulary as
+> part as packager duty ( after all, that's the whole part of being
+> maintainer )
+>
+>> > (or version updates in some cases, like firefox/opera/flash or updating
+>> > an rc/beta version to a stable one, and maybe some online games that are
+>> > useless unless on latest version)
+>> >
+>>
+>> I agree, (except for the games part, nowadays if it's less than 4GB
+>> it's not really a "game").
+>
+> I guess we can start with a list of exception :
+>
+> - stuff that should be updated to latest version, because the security
+> support for older releases ( firefox, chrome ) is too hard
+> -> we update to latest version if there is no regression and a strong
+> reason to upgrade ( severe bugfixes, security issue, breakages ).
+> Exception of this category should be very expectional
+>
+> - stuff where there is strict bugfixes only release
+> ( postgresql ), or update to a stable version ( which should be a bugfix
+> only release when compared to beta/rc :) )
+> -> we upgrade to stable ( for rc/beta )
+> -> we do version update if it is bug fixes and if the packager is ok
+> with it ( and if the rules of the bugfix branches are clearly documented
+> )
+>
+> - everything else
+> -> only minimal patches
+>
+> The question of game is still open, ie, should it go in 1st category, or
+> should we have different rules to see what should be there or not ?
+>
+> I guess this would only be for networked game ?
+>
+>> Maybe the sec team should only work on sec fixes, and there should be
+>> a sub-group of the sec team that handle the not
+>> CVE|crash|segfaulting|buffer-overflow updates.
+>
+> segfault, crash are the duty of packager, as well as wrong requires or
+> anything.
+> --
+> Michael Scherer
+>
+>
+
+Yes, but I was talking about the actual submitting to */release, not
+fixing the package itself. IIUC the submission rights will be
+restricted to the Sec team.
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005227.html b/zarb-ml/mageia-dev/2011-June/005227.html new file mode 100644 index 000000000..c3e8d761f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005227.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] mageia sound task + + + + + + + + + +

[Mageia-dev] mageia sound task

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Thu Jun 9 01:46:24 CEST 2011 +

+
+ +
On Wed, 8 Jun 2011, Sascha Schneider wrote:
+
+> Now that release 1 is out it might be woth for further toughts and a
+> lot of fun work :)
+>
+> http://www.mageia.org/wiki/doku.php?id=soundstudio
+>
+> I didn't rest thinking on this idea:
+> my latest idea is to mame a bash-script with dialog to configure
+> proaudio on mageia.
+
+Much of what is done in the script can also be done in a package 
+(task-sound-studio?) and then it would be reversible because that's 
+policy for packages. Wouldn't that be better and easier to use?
+
+For example instead of adding lines to rc.local a new soundstudio 
+initscript can be installed.
+
+Adding a specific user to groups may not be possible in a package, 
+however.
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005228.html b/zarb-ml/mageia-dev/2011-June/005228.html new file mode 100644 index 000000000..5cf38e987 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005228.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Michael Scherer + misc at zarb.org +
+ Thu Jun 9 03:15:42 CEST 2011 +

+
+ +
Le jeudi 09 juin 2011 à 02:40 +0300, Ahmad Samir a écrit :
+
+> Yes, but I was talking about the actual submitting to */release, not
+> fixing the package itself. IIUC the submission rights will be
+> restricted to the Sec team.
+
+Sorry to be picky, but there is no submit to */release, it is frozen.
+And in my proposition, there is also no submit to */update, there is a
+move from */updates_testing.
+
+So for managing the submit to updates_testing and the whole process, I
+think it should be open to any packagers. It should be maintainers
+responsibility to do the update ( prepare, do a test build, check,
+submit ), even if secteam members could be proactive for that. But the
+process should not be restricted to them, or it will not scale ( and
+given we want to have bugfixes updates, it wouldn't make much sense to
+call the team like this ).
+
+Since ensuring that a update is a minimal change is (to me) a quality
+issue, I propose to add to the QA list of things to check before
+refusing a update :
+"it doesn't fullfill the requirement of minimal changes ( with
+exceptions" 
+
+But that requires QA people to have minimal packaging notions, which
+could be a problem :/ 
+
+Again, nothing prevent people from the secteam to also be part of the QA
+team. 
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005229.html b/zarb-ml/mageia-dev/2011-June/005229.html new file mode 100644 index 000000000..674acedd1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005229.html @@ -0,0 +1,115 @@ + + + + [Mageia-dev] mageia sound task + + + + + + + + + +

[Mageia-dev] mageia sound task

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Jun 9 03:17:40 CEST 2011 +

+
+ +
'Twas brillig, and José Jorge at 08/06/11 21:51 did gyre and gimble:
+> Le mercredi 8 juin 2011 22:28:30, Sascha Schneider a écrit :
+>> my latest idea is to mame a bash-script with dialog to configure
+>> proaudio on mageia.
+> 
+> What do you mean by 'configure proaudio'?
+> 
+> I think the only needed thing is "pasuspender jackd" to use proaudio tools.
+
+Please don't do this. Using pasuspender with jackd is not the right way
+to do things. We've supported a protocol in PA for *years* to allow
+graceful handover to jack. Jack just needs to have dbus support and the
+two apps will communicate.
+
+There is even going to be a module in PA call jack-dbus-detect to allow
+PA to load a Jack module such that sound can still be output.
+
+Speak to me about the best setup (I don't know jack, but I do know PA.
+Don't hack around it, just ask :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-June/005230.html b/zarb-ml/mageia-dev/2011-June/005230.html new file mode 100644 index 000000000..c83b88575 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005230.html @@ -0,0 +1,121 @@ + + + + [Mageia-dev] kdegraphics4 commits [102171] + + + + + + + + + +

[Mageia-dev] kdegraphics4 commits [102171]

+ Balcaen John + mikala at mageia.org +
+ Thu Jun 9 03:19:14 CEST 2011 +

+
+ +
Le mercredi 8 juin 2011 21:48:25, vous avez écrit :
+> Revision: 102171
+> Author:   ze
+> Date:     2011-06-09 02:48:25 +0200 (Thu, 09 Jun 2011)
+> Log Message:
+> -----------
+> 
+> - add dependency needed by kgamma build
+> - add missing versioning in main package require
+> 
+> Modified Paths:
+> --------------
+>     cauldron/kdegraphics4/current/SPECS/kdegraphics4.spec
+> 
+> Modified: cauldron/kdegraphics4/current/SPECS/kdegraphics4.spec
+> ===================================================================
+> --- cauldron/kdegraphics4/current/SPECS/kdegraphics4.spec	2011-06-09 
+00:33:15 UTC (rev 102170)
+> +++ cauldron/kdegraphics4/current/SPECS/kdegraphics4.spec	2011-06-09 
+00:48:25 UTC (rev 102171)
+> @@ -42,9 +42,9 @@
+>  BuildRequires: djvulibre-devel
+>  BuildRequires: ebook-tools-devel
+>  BuildRequires: libxt-devel
+> +BuildRequires:	libxxf86vm-devel
+This buildrequires is already pulled during deps installed, why adding it 
+again ?
+
+> +Requires: %name-core = %epoch:%version
+
+> -Requires: %name-core
+Well maybe it would have been better to remove  this requires since this 
+package is just empty & only have suggests for packages which are already 
+requiring the %name-core package...
+
+-- 
+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-June/005231.html b/zarb-ml/mageia-dev/2011-June/005231.html new file mode 100644 index 000000000..be5085d3d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005231.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] mageia sound task + + + + + + + + + +

[Mageia-dev] mageia sound task

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Jun 9 03:21:19 CEST 2011 +

+
+ +
'Twas brillig, and Christiaan Welvaart at 09/06/11 00:46 did gyre and
+gimble:
+> For example instead of adding lines to rc.local a new soundstudio
+> initscript can be installed.
+
+As we'll be switching to systemd, an initscript is probably not the way
+to go. A systemd unit however would be good :D
+
+> Adding a specific user to groups may not be possible in a package, however.
+
+What do you need to add users to groups for these days? Can jack not use
+rtkit to get realtime privs? Or is there other group membership stuff
+that is desirable?
+
+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-June/005232.html b/zarb-ml/mageia-dev/2011-June/005232.html new file mode 100644 index 000000000..b32863f61 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005232.html @@ -0,0 +1,114 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Thu Jun 9 04:09:28 CEST 2011 +

+
+ +
On 9 June 2011 03:15, Michael Scherer <misc at zarb.org> wrote:
+> Le jeudi 09 juin 2011 à 02:40 +0300, Ahmad Samir a écrit :
+>
+>> Yes, but I was talking about the actual submitting to */release, not
+>> fixing the package itself. IIUC the submission rights will be
+>> restricted to the Sec team.
+>
+> Sorry to be picky, but there is no submit to */release, it is frozen.
+
+I meant */updates, it's a typo.
+
+[..]
+
+> And in my proposition, there is also no submit to */update, there is a
+> move from */updates_testing.
+>
+> So for managing the submit to updates_testing and the whole process, I
+> think it should be open to any packagers. It should be maintainers
+> responsibility to do the update ( prepare, do a test build, check,
+> submit ), even if secteam members could be proactive for that. But the
+> process should not be restricted to them, or it will not scale ( and
+> given we want to have bugfixes updates, it wouldn't make much sense to
+> call the team like this ).
+>
+
+A balance between leaving it open for all, and not restricting it too
+much so as not to make updating take more time, is needed, I think.
+
+> Since ensuring that a update is a minimal change is (to me) a quality
+> issue, I propose to add to the QA list of things to check before
+> refusing a update :
+> "it doesn't fullfill the requirement of minimal changes ( with
+> exceptions"
+>
+> But that requires QA people to have minimal packaging notions, which
+> could be a problem :/
+>
+> Again, nothing prevent people from the secteam to also be part of the QA
+> team.
+> --
+> Michael Scherer
+>
+>
+
+
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005233.html b/zarb-ml/mageia-dev/2011-June/005233.html new file mode 100644 index 000000000..75a224f5f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005233.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] [RPM] cauldron core/release libgdata-0.7.1-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release libgdata-0.7.1-1.mga2

+ Balcaen John + mikala at mageia.org +
+ Thu Jun 9 04:28:21 CEST 2011 +

+
+ +
Le mercredi 8 juin 2011 16:52:16, Mageia Team a écrit :
+> Name        : libgdata                     Relocations: (not relocatable)
+> Version     : 0.7.1                             Vendor: Mageia.Org
+[...]
+> dmorgan <dmorgan> 0.7.1-1.mga2:
+> + Revision: 102030
+> - New version 0.7.1
+There's a file conflict :
+Installation failed:
+        file /usr/lib64/girepository-1.0/GData-0.0.typelib from install of 
+lib64gdata10-0.7.1-1.mga2.x86_64 conflicts with file from package 
+lib64gdata7-0.6.6-1.mga1.x86_64                                                                                                                                                              
+
+Installation failed:    file /usr/lib64/girepository-1.0/GData-0.0.typelib 
+from install of lib64gdata10-0.7.1-1.mga2.x86_64 conflicts with file from 
+package lib64gdata7-0.6.6-1.mga1.x86_64              
+
+Maybe this file should not be in the versionned library package ?
+
+-- 
+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-June/005234.html b/zarb-ml/mageia-dev/2011-June/005234.html new file mode 100644 index 000000000..bba4378e4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005234.html @@ -0,0 +1,113 @@ + + + + [Mageia-dev] [RPM] cauldron core/release libcanberra-0.27-2.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release libcanberra-0.27-2.mga2

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Thu Jun 9 05:10:37 CEST 2011 +

+
+ +
On 8 June 2011 09:20, Mageia Team <buildsystem-daemon at mageia.org> wrote:
+> Name        : libcanberra                  Relocations: (not relocatable)
+> Version     : 0.27                              Vendor: Mageia.Org
+> Release     : 2.mga2                        Build Date: Wed Jun  8 09:16:17 2011
+> Install Date: (not installed)               Build Host: ecosse
+> Group       : Sound                         Source RPM: (none)
+> Size        : 504482                           License: LGPLv2+
+> Signature   : (none)
+> Packager    : Mageia Team <http://www.mageia.org>
+> URL         : http://0pointer.de/lennart/projects/libcanberra/
+> Summary     : XDG compliant sound event library
+> Description :
+> A small and lightweight implementation of the XDG Sound Theme Specification
+> (http://0pointer.de/public/sound-theme-spec.html).
+>
+> dmorgan <dmorgan> 0.27-2.mga2:
+> + Revision: 101746
+> - Enable gtk3 part
+
+The -devel sub-package now requires lib*canberra-gtk30, which means
+gtk+3.0-devel is pulled in any chroot that has BR canberra-gtk-devel,
+I am not sure it'll have any effect on the built packages, but it
+doesn't look right having both gtk+2.0 and gtk+3.0 -devel in the same
+chroot...
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005235.html b/zarb-ml/mageia-dev/2011-June/005235.html new file mode 100644 index 000000000..6ee6943bc --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005235.html @@ -0,0 +1,78 @@ + + + + [Mageia-dev] automatic chroot install using urpmi + + + + + + + + + +

[Mageia-dev] automatic chroot install using urpmi

+ Bruno Cornec + Bruno.Cornec at hp.com +
+ Thu Jun 9 05:47:20 CEST 2011 +

+
+ +
Vasiliy G Tolstov said on Wed, Jun 08, 2011 at 04:26:35PM +0400:
+
+> Thank's for answer. Very well. If i use basesystem-minimal and append
+> grub systemd ntpd openssh-server and kernel, does that system can
+> boot-up ?
+
+You may want to look at rpmbootstrap, which was working fine for
+mdv2010.2 and thus should easily work for mageia 1 as well. (part of
+project-builder.org), this tools creates operational chroot for RPM
+based distros, similar to debbootstrap and better than rinse or mock ,
+as being multi distro (fedora, rhel, opensuse, mdv, mageia, ...)
+
+I use it to create the chroots (VEs) needed by project-builder.org to
+build its packages, zhen not using VMs.
+
+HTH,
+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-June/005236.html b/zarb-ml/mageia-dev/2011-June/005236.html new file mode 100644 index 000000000..0b55db887 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005236.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Anssi Hannula + anssi.hannula at iki.fi +
+ Thu Jun 9 07:00:24 CEST 2011 +

+
+ +
On 09.06.2011 02:25, Michael Scherer wrote:
+> I guess we can start with a list of exception :
+> 
+> - stuff that should be updated to latest version, because the security
+> support for older releases ( firefox, chrome ) is too hard
+> -> we update to latest version if there is no regression and a strong
+> reason to upgrade ( severe bugfixes, security issue, breakages ). 
+> Exception of this category should be very expectional
+> 
+> - stuff where there is strict bugfixes only release
+> ( postgresql ), or update to a stable version ( which should be a bugfix
+> only release when compared to beta/rc :) )
+> -> we upgrade to stable ( for rc/beta )
+> -> we do version update if it is bug fixes and if the packager is ok
+> with it ( and if the rules of the bugfix branches are clearly documented
+> ) 
+> 
+> - everything else 
+> -> only minimal patches
+> 
+> The question of game is still open, ie, should it go in 1st category, or
+> should we have different rules to see what should be there or not ?
+> 
+> I guess this would only be for networked game ?
+
+Yes. Note that this applies to some other software that communicates
+with outside systems as well, e.g. subdownloader. Maybe also Vuze if the
+content delivery system requires a version update.
+
+Maybe the correct phrasing would be something like:
+- Packages where some functions no longer work due to remote server
+  changes, requiring a newer version of the package.
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005237.html b/zarb-ml/mageia-dev/2011-June/005237.html new file mode 100644 index 000000000..541338785 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005237.html @@ -0,0 +1,77 @@ + + + + [Mageia-dev] automatic chroot install using urpmi + + + + + + + + + +

[Mageia-dev] automatic chroot install using urpmi

+ Vasiliy G Tolstov + v.tolstov at selfip.ru +
+ Thu Jun 9 07:13:49 CEST 2011 +

+
+ +
On Thu, 2011-06-09 at 05:47 +0200, Bruno Cornec wrote:
+> Vasiliy G Tolstov said on Wed, Jun 08, 2011 at 04:26:35PM +0400:
+> 
+> > Thank's for answer. Very well. If i use basesystem-minimal and append
+> > grub systemd ntpd openssh-server and kernel, does that system can
+> > boot-up ?
+> 
+> You may want to look at rpmbootstrap, which was working fine for
+> mdv2010.2 and thus should easily work for mageia 1 as well. (part of
+> project-builder.org), this tools creates operational chroot for RPM
+> based distros, similar to debbootstrap and better than rinse or mock ,
+> as being multi distro (fedora, rhel, opensuse, mdv, mageia, ...)
+> 
+> I use it to create the chroots (VEs) needed by project-builder.org to
+> build its packages, zhen not using VMs.
+> 
+> HTH,
+> Bruno.
+
+Thank you, Bruno. I'm try look ad it.
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005238.html b/zarb-ml/mageia-dev/2011-June/005238.html new file mode 100644 index 000000000..3b7c05c59 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005238.html @@ -0,0 +1,151 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ JA Magallón + jamagallon at ono.com +
+ Thu Jun 9 10:45:03 CEST 2011 +

+
+ +
Hi all...
+
+I have a problem with this first big change in Cauldron...
+I have a couple test boxes in which I have updated everything, and I can't
+get Gnome 3 to work properly. I suppose it is still work in progress, but as
+other people sent messages telling this or that application doesn't work...
+
+I can't even get an application to launch. I log in, get gnome-shell running,
+but:
+- no applet is shown in the bar. and they are there, i can press moue button
+  on right menu, hover it over there and the volume bubble pops, but I see no
+  icon on the bar.
+- if I select "System settings" o launch firefox, immediately I get a fullscreen
+  error about "something went wrong, plz logout and in again"
+
+I suppose probably I miss some depdency not correctly handled, but I can not
+guess what.
+
+Any ideas ?
+
+TIA
+
+
+-- 
+J.A. Magallon <jamagallon()ono!com>     \                 Winter is coming...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005239.html b/zarb-ml/mageia-dev/2011-June/005239.html new file mode 100644 index 000000000..1dbc8e4e9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005239.html @@ -0,0 +1,159 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Dexter Morgan + dmorganec at gmail.com +
+ Thu Jun 9 10:54:54 CEST 2011 +

+
+ +
2011/6/9 JA Magallón <jamagallon at ono.com>:
+> Hi all...
+>
+> I have a problem with this first big change in Cauldron...
+> I have a couple test boxes in which I have updated everything, and I can't
+> get Gnome 3 to work properly. I suppose it is still work in progress, but as
+> other people sent messages telling this or that application doesn't work...
+>
+> I can't even get an application to launch. I log in, get gnome-shell running,
+> but:
+> - no applet is shown in the bar. and they are there, i can press moue button
+>  on right menu, hover it over there and the volume bubble pops, but I see no
+>  icon on the bar.
+> - if I select "System settings" o launch firefox, immediately I get a fullscreen
+>  error about "something went wrong, plz logout and in again"
+>
+> I suppose probably I miss some depdency not correctly handled, but I can not
+> guess what.
+>
+> Any ideas ?
+>
+
+Hi,
+
+sorry  i forgot to tell that it was in WIP :/
+
+so first accept my apologize.
+
+Then, yes there is still missing pieces, i try to get them today.
+
+can you give the exact error messages please ?
+have you tried to install gnome-shell and in kdm/gdm to choose Gnome3 ?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005240.html b/zarb-ml/mageia-dev/2011-June/005240.html new file mode 100644 index 000000000..76059ca86 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005240.html @@ -0,0 +1,168 @@ + + + + [Mageia-dev] Change for clutter-gtk package + + + + + + + + + +

[Mageia-dev] Change for clutter-gtk package

+ Dexter Morgan + dmorganec at gmail.com +
+ Thu Jun 9 10:56:34 CEST 2011 +

+
+ +
Hi dear packagers,
+
+
+clutter-gtk will be a gtk3 app today.
+
+To keep the compatibility with gtk2 apps we will still have the gtk2
+clutter-gtk it will be clutter-gtk010.
+So don't forget to use this one if you want to use it with a gtk2 app.
+
+
+thanks.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005241.html b/zarb-ml/mageia-dev/2011-June/005241.html new file mode 100644 index 000000000..e381e3c0e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005241.html @@ -0,0 +1,144 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Jun 9 11:05:16 CEST 2011 +

+
+ +
'Twas brillig, and Ahmad Samir at 08/06/11 22:48 did gyre and gimble:
+> On 8 June 2011 23:38, Stew Benedict <stewbintn at gmail.com> wrote:
+>> On 06/08/2011 05:31 PM, Michael Scherer wrote:
+>>>
+>>> Le mercredi 08 juin 2011 à 19:48 +0300, Ahmad Samir a écrit :
+>>>>
+>>>> On 8 June 2011 18:44, Michael Scherer<misc at zarb.org>  wrote:
+>>>>>
+>>>>> Le mercredi 08 juin 2011 à 10:40 +0200, Anne nicolas a écrit :
+>>>>>>
+>>>>>> Hi there
+>>>>>>
+>>>>>> We have some stuff to complete here:
+>>>>>> http://mageia.org/wiki/doku.php?id=security
+>>>>>>
+>>>>>> <http://mageia.org/wiki/doku.php?id=security>Can we spend the 2 or 3
+>>>>>> coming
+>>>>>> days to finalize it and start updates submits?
+>>>>>
+>>>>> Pascal is working on this.
+>>>>>
+>>>>> So here is a proposal :
+>>>>> - anybody can submit a package to updates_testing.
+>>>>> - once submitted to testing, it should ask to QA to test, along with :
+>>>>>  - a reason for the update ( likely bug number )
+>>>>>  - potentially a priority ( ie, if this is just a translation update or
+>>>>> a urgent 0 day exploit )
+>>>>>  - a way to test the bug and see it is fixed
+>>>>>  - text for the update
+>>>>>
+>>>>> - qa validate the update ( with process to define )
+>>>>>
+>>>>> - someone move the package from updates_testing to testing
+>>>>
+>>>> Isn't it cleaner to rebuild when submitting to */updates? instead of
+>>>> moving.
+>>>
+>>> Well, that depend on the way package is built. In fact, it should not
+>>> matter much, as we should not do a change that could break a existing
+>>> software in update, and so this should be the same in updates_testing
+>>> ( ie, they should be the same wrto ABI )
+>>>
+>>> But that's also why I ask here :)
+>>>
+>>>
+>> If you're going to rebuild *after* QA, you've just invalidated your QA.
+>> (yeah, I know it *should* be the same, but stuff happens)
+>>
+> 
+> You're right (even if that's never happened for 3-4 years in mdv,
+> since sec team rebuilt the packages when pushing to */updates IIRC).
+
+
+Personally, and this might just be me, I always submit my packages to
+*testing with a subrel of 0.1, 0.2 0.3 etc etc. Users then test my
+various iterations. When I'm happy and when it's ready to pass to QA, I
+set the subrel to 1. This way the final version that should hit updates
+is nice and neat.
+
+In an ideal world, QA would validate it for me then change the subrel
+for me. That process would require a rebuild.
+
+I'm not sure what others feel about this? It's not impossible to just do
+this as a matter of course as part of the process we go through and
+increment subrel to a round number before handing over to QA... although
+maybe I'm just a bit too anal about neat version numbers :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-June/005242.html b/zarb-ml/mageia-dev/2011-June/005242.html new file mode 100644 index 000000000..fec68c2c0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005242.html @@ -0,0 +1,193 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process) + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process)

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Jun 9 11:14:21 CEST 2011 +

+
+ +
Hi,
+
+As I upgrade my various machines (I only really have about 5, so not
+that many) I'm running into a few packages that are missing (this is
+inevitable).
+
+Nothing major just little things like trac and supybot etc.
+
+What is the best way to add these packages to the v1 tree?
+
+Using backports seems a little odd as this is "unsupported" and we don't
+really want to encourage using it as a means to get the missing packages.
+
+release is obviously frozen so no go there.
+
+The only real option is updates, but that should obviously have some QA
+on it.
+
+Perhaps we need to have some kind of exemption to get these missing
+packages added?
+
+Does anyone have any opinions 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-June/005243.html b/zarb-ml/mageia-dev/2011-June/005243.html new file mode 100644 index 000000000..f471a2c77 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005243.html @@ -0,0 +1,254 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ JA Magallón + jamagallon at ono.com +
+ Thu Jun 9 11:20:10 CEST 2011 +

+
+ +
On Thu, 9 Jun 2011 10:54:54 +0200, Dexter Morgan <dmorganec at gmail.com> wrote:
+
+> 2011/6/9 JA Magallón <jamagallon at ono.com>:
+> > Hi all...
+> >
+> > I have a problem with this first big change in Cauldron...
+> > I have a couple test boxes in which I have updated everything, and I can't
+> > get Gnome 3 to work properly. I suppose it is still work in progress, but as
+> > other people sent messages telling this or that application doesn't work...
+> >
+> > I can't even get an application to launch. I log in, get gnome-shell running,
+> > but:
+> > - no applet is shown in the bar. and they are there, i can press moue button
+> >  on right menu, hover it over there and the volume bubble pops, but I see no
+> >  icon on the bar.
+> > - if I select "System settings" o launch firefox, immediately I get a fullscreen
+> >  error about "something went wrong, plz logout and in again"
+> >
+> > I suppose probably I miss some depdency not correctly handled, but I can not
+> > guess what.
+> >
+> > Any ideas ?
+> >
+> 
+> Hi,
+> 
+> sorry  i forgot to tell that it was in WIP :/
+> 
+> so first accept my apologize.
+
+No need, Cauldron is Cauldron. The only strange thing is that I had
+heard on other threads that update to Gnome 3 was being discussed,
+but never realized it had finally agreed on.
+
+> 
+> Then, yes there is still missing pieces, i try to get them today.
+> 
+> can you give the exact error messages please ?
+
+Bah, no real useful message, a full gray screen with:
+
+Oh, no, something has gone wrong.
+A problem has occurred and the system can't recover
+Please log out and try again.
+[Log Out]
+
+BTW, perhaps it is useful: gdm has no background, so perhaps it is
+a problem connecting to dbus/gconf or the like.
+
+> have you tried to install gnome-shell and in kdm/gdm to choose Gnome3 ?
+
+Yes, it is installed and launches. But looks like there are things missing
+(icons, applets, do not know...).
+In last test it just gave me the error just after switching to a vt,
+uninstalling the old .7 kernel that was still around, and switched back
+to X.
+
+This is .xsession-errors:
+
+/etc/X11/gdm/Xsession: Beginning session setup...
+/etc/X11/gdm/Xsession: Setup done, will execute: /usr/bin/ssh-agent -- /usr/share/X11/xdm/Xsession GNOME3
+gnome-session[6411]: WARNING: Could not parse desktop file /home/magallon/.config/autostart/xfce4-tips-autostart.desktop: Key file does not have key 'Name'
+gnome-session[6411]: WARNING: could not read /home/magallon/.config/autostart/xfce4-tips-autostart.desktop
+gnome-session[6411]: WARNING: Could not parse desktop file /home/magallon/.config/autostart/xfconf-migration-4.6.desktop: Key file does not have key 'Name'
+gnome-session[6411]: WARNING: could not read /home/magallon/.config/autostart/xfconf-migration-4.6.desktop
+gnome-session[6411]: WARNING: Could not parse desktop file /home/magallon/.config/autostart/xfce4-firstrun.desktop: Key file does not have key 'Name'
+gnome-session[6411]: WARNING: could not read /home/magallon/.config/autostart/xfce4-firstrun.desktop
+gnome-session[6411]: WARNING: Could not parse desktop file /home/magallon/.config/autostart/user-dirs-update-gtk.desktop: Key file does not have key 'Name'
+gnome-session[6411]: WARNING: could not read /home/magallon/.config/autostart/user-dirs-update-gtk.desktop
+gnome-session[6411]: WARNING: Could not parse desktop file /home/magallon/.config/autostart/xfce4-settings-helper-autostart.desktop: Key file does not have key 'Name'
+gnome-session[6411]: WARNING: could not read /home/magallon/.config/autostart/xfce4-settings-helper-autostart.desktop
+GNOME_KEYRING_CONTROL=/tmp/keyring-7QUy3k
+GNOME_KEYRING_CONTROL=/tmp/keyring-7QUy3k
+GPG_AGENT_INFO=/tmp/keyring-7QUy3k/gpg:0:1
+GNOME_KEYRING_CONTROL=/tmp/keyring-7QUy3k
+GPG_AGENT_INFO=/tmp/keyring-7QUy3k/gpg:0:1
+SSH_AUTH_SOCK=/tmp/keyring-7QUy3k/ssh
+GNOME_KEYRING_CONTROL=/tmp/keyring-7QUy3k
+GPG_AGENT_INFO=/tmp/keyring-7QUy3k/gpg:0:1
+SSH_AUTH_SOCK=/tmp/keyring-7QUy3k/ssh
+Window manager warning: Workarounds for broken applications disabled. Some applications may not behave properly.
+Window manager warning: Failed to load theme "Adwaita": Failed to find a valid file for theme Adwaita
+
+    JS ERROR: !!!   Exception was: Error: Requiring NetworkManager, version none: Typelib file for namespace 'NetworkManager' (any version) not found
+    JS ERROR: !!!     lineNumber = '0'
+    JS ERROR: !!!     fileName = 'gjs_throw'
+    JS ERROR: !!!     stack = '("Requiring NetworkManager, version none: Typelib file for namespace 'NetworkManager' (any version) not found")@gjs_throw:0
+@/usr/share/gnome-shell/js/ui/status/network.js:8
+'
+    JS ERROR: !!!     message = 'Requiring NetworkManager, version none: Typelib file for namespace 'NetworkManager' (any version) not found'
+      JS LOG: NMApplet is not supported. It is possible that your NetworkManager version is too old
+      JS LOG: GNOME Shell started at Thu Jun 09 2011 11:17:05 GMT+0200 (CEST)
+
+(gnome-shell:6580): GdmUser-WARNING **: Unable to load CK history: no seat-id found
+    JS ERROR: !!!   Exception in callback for signal: activate
+    JS ERROR: !!!     message = 'app is null'
+    JS ERROR: !!!     lineNumber = '250'
+    JS ERROR: !!!     fileName = '/usr/share/gnome-shell/js/ui/statusMenu.js'
+    JS ERROR: !!!     stack = '([object Object],[object _private_Clutter_Event])@/usr/share/gnome-shell/js/ui/statusMenu.js:250
+([object Object],[object _private_Clutter_Event])@/usr/share/gjs-1.0/lang.js:110
+_emit("activate",[object _private_Clutter_Event])@/usr/share/gjs-1.0/signals.js:124
+([object _private_Clutter_Event])@/usr/share/gnome-shell/js/ui/popupMenu.js:95
+([object _private_Shell_GenericContainer],[object _private_Clutter_Event])@/usr/share/gnome-shell/js/ui/popupMenu.js:68
+([object _private_Shell_GenericContainer],[object _private_Clutter_Event])@/usr/share/gjs-1.0/lang.js:110
+'
+gnome-session[6411]: WARNING: Application 'gnome-shell.desktop' failed to register before timeout
+
+** (polkit-gnome-authentication-agent-1:6718): WARNING **: Unable to register authentication agent: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: An authentication agent already exists for the given subject
+Cannot register authentication agent: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: An authentication agent already exists for the given subject
+
+** (bluetooth-applet:6720): WARNING **: Could not open RFKILL control device, please verify your installation
+Failed to play sound: File or data not found
+** Message: applet now removed from the notification area
+** Message: applet now embedded in the notification area
+
+(gnome-settings-daemon:6548): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
+Window manager warning: Log level 16: gnome-shell: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
+
+gnome-shell-calendar-server[6586]: Lost (or failed to acquire) the name org.gnome.Shell.CalendarServer - exiting
+g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.
+g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.
+** Message: Got disconnected from the session message bus; retrying to reconnect every 10 seconds
+** Message: <info>  disconnected by the session bus.
+
+g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.
+
+-- 
+J.A. Magallon <jamagallon()ono!com>     \                 Winter is coming...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005244.html b/zarb-ml/mageia-dev/2011-June/005244.html new file mode 100644 index 000000000..2eedb75e4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005244.html @@ -0,0 +1,179 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Dexter Morgan + dmorganec at gmail.com +
+ Thu Jun 9 11:25:04 CEST 2011 +

+
+ +
2011/6/9 JA Magallón <jamagallon at ono.com>:
+> Hi all...
+>
+> I have a problem with this first big change in Cauldron...
+> I have a couple test boxes in which I have updated everything, and I can't
+> get Gnome 3 to work properly. I suppose it is still work in progress, but as
+> other people sent messages telling this or that application doesn't work...
+>
+> I can't even get an application to launch. I log in, get gnome-shell running,
+> but:
+> - no applet is shown in the bar. and they are there, i can press moue button
+>  on right menu, hover it over there and the volume bubble pops, but I see no
+>  icon on the bar.
+> - if I select "System settings" o launch firefox, immediately I get a fullscreen
+>  error about "something went wrong, plz logout and in again"
+>
+> I suppose probably I miss some depdency not correctly handled, but I can not
+> guess what.
+>
+> Any ideas ?
+>
+> TIA
+>
+>
+> --
+> J.A. Magallon <jamagallon()ono!com>     \                 Winter is coming...
+>
+
+what is your version of gnome-session ?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005245.html b/zarb-ml/mageia-dev/2011-June/005245.html new file mode 100644 index 000000000..f2c7b3226 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005245.html @@ -0,0 +1,136 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Thu Jun 9 11:25:41 CEST 2011 +

+
+ +
2011/6/9 JA Magallón <jamagallon at ono.com>:
+>
+> No need, Cauldron is Cauldron. The only strange thing is that I had
+> heard on other threads that update to Gnome 3 was being discussed,
+> but never realized it had finally agreed on.
+
+Same here, I'm a bit surprised.
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005246.html b/zarb-ml/mageia-dev/2011-June/005246.html new file mode 100644 index 000000000..44aa5eb14 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005246.html @@ -0,0 +1,188 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process) + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process)

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Thu Jun 9 11:27:25 CEST 2011 +

+
+ +
Op donderdag 09 juni 2011 11:14:21 schreef Colin Guthrie:
+> Hi,
+> 
+> As I upgrade my various machines (I only really have about 5, so not
+> that many) I'm running into a few packages that are missing (this is
+> inevitable).
+> 
+> Nothing major just little things like trac and supybot etc.
+> 
+> What is the best way to add these packages to the v1 tree?
+> 
+> Using backports seems a little odd as this is "unsupported" and we don't
+> really want to encourage using it as a means to get the missing packages.
+> 
+> release is obviously frozen so no go there.
+> 
+> The only real option is updates, but that should obviously have some QA
+> on it.
+> 
+> Perhaps we need to have some kind of exemption to get these missing
+> packages added?
+> 
+> Does anyone have any opinions on this?
+> 
+> Col
+
+tbh, i had been thinking about this too, but it would kind of defeat the 
+updates reasoning?
+
+otoh, perhaps a missing package is also a bugfix... maybe we could file bug 
+reports for missing packages and go through the updates route...
+
+personally, i would like updates for it, but it might be against updates 
+protocol and it will likely add extra strain on the QA team?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005247.html b/zarb-ml/mageia-dev/2011-June/005247.html new file mode 100644 index 000000000..3ddf7c7b5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005247.html @@ -0,0 +1,210 @@ + + + + [Mageia-dev] Go to gnome 3 + + + + + + + + + +

[Mageia-dev] Go to gnome 3

+ Dexter Morgan + dmorganec at gmail.com +
+ Thu Jun 9 11:30:30 CEST 2011 +

+
+ +
Hi,
+
+as a misunderstanding i started to update to gnome 3 as it seemed
+agreed to go this way ( at least i and some ppl understood as i read
+that some ppl planned to update to it too )
+
+
+What do we plan ?  i can revert to the previous rpms  or continue to update.
+
+
+sorry again.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005248.html b/zarb-ml/mageia-dev/2011-June/005248.html new file mode 100644 index 000000000..34f6b680a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005248.html @@ -0,0 +1,224 @@ + + + + [Mageia-dev] Go to gnome 3 + + + + + + + + + +

[Mageia-dev] Go to gnome 3

+ Stefano Negro + stblack at gmail.com +
+ Thu Jun 9 11:36:55 CEST 2011 +

+
+ +
2011/6/9 Dexter Morgan <dmorganec at gmail.com>
+
+> Hi,
+>
+> as a misunderstanding i started to update to gnome 3 as it seemed
+> agreed to go this way ( at least i and some ppl understood as i read
+> that some ppl planned to update to it too )
+>
+>
+> What do we plan ?  i can revert to the previous rpms  or continue to
+> update.
+>
+>
+> sorry again.
+>
+
+My opinon is positive.
+I have seen gnome 3 on fedora 15 and was really amazing.
+
+-- 
+my 2c
+Stblack
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110609/1f982fb1/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005249.html b/zarb-ml/mageia-dev/2011-June/005249.html new file mode 100644 index 000000000..4bf45cf37 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005249.html @@ -0,0 +1,219 @@ + + + + [Mageia-dev] Go to gnome 3 + + + + + + + + + +

[Mageia-dev] Go to gnome 3

+ JA Magallón + jamagallon at ono.com +
+ Thu Jun 9 11:37:13 CEST 2011 +

+
+ +
On Thu, 9 Jun 2011 11:30:30 +0200, Dexter Morgan <dmorganec at gmail.com> wrote:
+
+> Hi,
+> 
+> as a misunderstanding i started to update to gnome 3 as it seemed
+> agreed to go this way ( at least i and some ppl understood as i read
+> that some ppl planned to update to it too )
+> 
+> 
+> What do we plan ?  i can revert to the previous rpms  or continue to update.
+> 
+
+From the POV of a user/tester, go ahead. The sooner you start, the sooner
+we will get the dependency hell sorted and Gnome3 working.
+After I read that you can force the fallback (more or less traditional)
+mode, I'm happy with gnome 3 again :).
+An it even works fast on an oldie i945GM graphics.
+
+-- 
+J.A. Magallon <jamagallon()ono!com>     \                 Winter is coming...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005250.html b/zarb-ml/mageia-dev/2011-June/005250.html new file mode 100644 index 000000000..90f965fd6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005250.html @@ -0,0 +1,218 @@ + + + + [Mageia-dev] Go to gnome 3 + + + + + + + + + +

[Mageia-dev] Go to gnome 3

+ Thomas Backlund + tmb at mageia.org +
+ Thu Jun 9 11:37:36 CEST 2011 +

+
+ +
Dexter Morgan skrev 9.6.2011 12:30:
+> Hi,
+>
+> as a misunderstanding i started to update to gnome 3 as it seemed
+> agreed to go this way ( at least i and some ppl understood as i read
+> that some ppl planned to update to it too )
+>
+>
+> What do we plan ?  i can revert to the previous rpms  or continue to update.
+>
+
+Since this is Cauldron, and we will ship Gnome 3 in Mageia 2 I'd say 
+continue the updates.
+
+The earlier we get the bigger changes in, the better they will be tested 
+for final release.
+
+--
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005251.html b/zarb-ml/mageia-dev/2011-June/005251.html new file mode 100644 index 000000000..17011f8a2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005251.html @@ -0,0 +1,168 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process) + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process)

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Thu Jun 9 11:40:29 CEST 2011 +

+
+ +
On Thu, 9 Jun 2011, Maarten Vanraes wrote:
+
+> otoh, perhaps a missing package is also a bugfix... maybe we could file bug
+> reports for missing packages and go through the updates route...
+
+Filing bug reports is not a bad idea, even if the new package will go to 
+backports. Just explain a little why it is important (to fix this in a 
+stable release).
+
+We probably need a new "version" in bugzilla because mga1+backports is 
+basically a new distro. A bug in backports shouldn't be filed against "1" 
+IMHO.
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005252.html b/zarb-ml/mageia-dev/2011-June/005252.html new file mode 100644 index 000000000..d53a0c525 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005252.html @@ -0,0 +1,187 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ JA Magallón + jamagallon at ono.com +
+ Thu Jun 9 11:43:00 CEST 2011 +

+
+ +
On Thu, 9 Jun 2011 11:25:04 +0200, Dexter Morgan <dmorganec at gmail.com> wrote:
+
+> 2011/6/9 JA Magallón <jamagallon at ono.com>:
+> > Hi all...
+> >
+> > I have a problem with this first big change in Cauldron...
+> > I have a couple test boxes in which I have updated everything, and I can't
+> > get Gnome 3 to work properly. I suppose it is still work in progress, but as
+> > other people sent messages telling this or that application doesn't work...
+> >
+> > I can't even get an application to launch. I log in, get gnome-shell running,
+> > but:
+> > - no applet is shown in the bar. and they are there, i can press moue button
+> >  on right menu, hover it over there and the volume bubble pops, but I see no
+> >  icon on the bar.
+> > - if I select "System settings" o launch firefox, immediately I get a fullscreen
+> >  error about "something went wrong, plz logout and in again"
+> >
+> > I suppose probably I miss some depdency not correctly handled, but I can not
+> > guess what.
+> >
+> > Any ideas ?
+> >
+> > TIA
+> >
+> >
+> > --
+> > J.A. Magallon <jamagallon()ono!com>     \                 Winter is coming...
+> >
+> 
+> what is your version of gnome-session ?
+
+xps:~# rpm -qa gnome-ses*
+gnome-session-3.0.1-1.mga2
+gnome-session-bin-3.0.1-1.mga2
+
+-- 
+J.A. Magallon <jamagallon()ono!com>     \                 Winter is coming...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005253.html b/zarb-ml/mageia-dev/2011-June/005253.html new file mode 100644 index 000000000..d00639a07 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005253.html @@ -0,0 +1,178 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Olav Vitters + olav at vitters.nl +
+ Thu Jun 9 11:28:09 CEST 2011 +

+
+ +
On Thu, Jun 09, 2011 at 11:20:10AM +0200, JA Magallón wrote:
+> This is .xsession-errors:
+> Window manager warning: Failed to load theme "Adwaita": Failed to find a valid file for theme Adwaita
+
+needs gnome-themes-standard
+
+>     JS ERROR: !!!   Exception was: Error: Requiring NetworkManager, version none: Typelib file for namespace 'NetworkManager' (any version) not found
+
+needs networkmanager 0.9 + gobject-introspection file
+
+> (gnome-shell:6580): GdmUser-WARNING **: Unable to load CK history: no seat-id found
+
+guessing newer consolekit?
+
+> ** (polkit-gnome-authentication-agent-1:6718): WARNING **: Unable to register authentication agent: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: An authentication agent already exists for the given subject
+> Cannot register authentication agent: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: An authentication agent already exists for the given subject
+
+something about policykit, but no idea
+
+> ** (bluetooth-applet:6720): WARNING **: Could not open RFKILL control device, please verify your installation
+> Failed to play sound: File or data not found
+> ** Message: applet now removed from the notification area
+> ** Message: applet now embedded in the notification area
+
+weird, applets should not try and load in gnome-shell.
+
+
+guessing rest of the messages occur due to GNOME shell failing to start
+properly.
+
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005254.html b/zarb-ml/mageia-dev/2011-June/005254.html new file mode 100644 index 000000000..8d86d6431 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005254.html @@ -0,0 +1,155 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Jun 9 11:49:18 CEST 2011 +

+
+ +
'Twas brillig, and Wolfgang Bornath at 09/06/11 10:25 did gyre and gimble:
+> 2011/6/9 JA Magallón <jamagallon at ono.com>:
+>>
+>> No need, Cauldron is Cauldron. The only strange thing is that I had
+>> heard on other threads that update to Gnome 3 was being discussed,
+>> but never realized it had finally agreed on.
+> 
+> Same here, I'm a bit surprised.
+
+We're on the next cycle now. Quite frankly I'd be stunned (and hugely
+disappointed) if we *didn't* have Gnome 3!
+
+Providing a Gnome2 environment or not is likely the point that need
+discussion :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-June/005255.html b/zarb-ml/mageia-dev/2011-June/005255.html new file mode 100644 index 000000000..e82ee0262 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005255.html @@ -0,0 +1,224 @@ + + + + [Mageia-dev] Go to gnome 3 + + + + + + + + + +

[Mageia-dev] Go to gnome 3

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Jun 9 11:50:52 CEST 2011 +

+
+ +
'Twas brillig, and Dexter Morgan at 09/06/11 10:30 did gyre and gimble:
+> Hi,
+> 
+> as a misunderstanding i started to update to gnome 3 as it seemed
+> agreed to go this way ( at least i and some ppl understood as i read
+> that some ppl planned to update to it too )
+> 
+> 
+> What do we plan ?  i can revert to the previous rpms  or continue to update.
+
+As posted in the other thread (I read my mails out of order!), I'd plow on!
+
+I think the real decision is whether or not to provide a Gnome 2 env in
+Mageia 2 and that can be discussed in time.
+
+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-June/005256.html b/zarb-ml/mageia-dev/2011-June/005256.html new file mode 100644 index 000000000..3d71fe241 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005256.html @@ -0,0 +1,157 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Dexter Morgan + dmorganec at gmail.com +
+ Thu Jun 9 11:51:43 CEST 2011 +

+
+ +
On Thu, Jun 9, 2011 at 11:28 AM, Olav Vitters <olav at vitters.nl> wrote:
+> On Thu, Jun 09, 2011 at 11:20:10AM +0200, JA Magallón wrote:
+>> This is .xsession-errors:
+>> Window manager warning: Failed to load theme "Adwaita": Failed to find a valid file for theme Adwaita
+>
+> needs gnome-themes-standard
+
+thanks a lot for all your inputs,  so i think all will be better when
+i will finish updating  gnome.
+
+For policykit i will update too today then
+
+thanks again :)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005257.html b/zarb-ml/mageia-dev/2011-June/005257.html new file mode 100644 index 000000000..20ac0901b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005257.html @@ -0,0 +1,197 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Jun 9 11:54:27 CEST 2011 +

+
+ +
'Twas brillig, and Christiaan Welvaart at 09/06/11 10:40 did gyre and
+gimble:
+> On Thu, 9 Jun 2011, Maarten Vanraes wrote:
+> 
+>> otoh, perhaps a missing package is also a bugfix... maybe we could
+>> file bug
+>> reports for missing packages and go through the updates route...
+> 
+> Filing bug reports is not a bad idea, even if the new package will go to
+> backports. Just explain a little why it is important (to fix this in a
+> stable release).
+> 
+> We probably need a new "version" in bugzilla because mga1+backports is
+> basically a new distro. A bug in backports shouldn't be filed against
+> "1" IMHO.
+
+As I said in my original mail I really don't think backports is the
+right approach.
+
+I'd prefer to have a 3rd party repo than abuse backports to get the
+missing packages.
+
+I think updates would be the right place.
+
+Perhaps we can make the submission process check to see if there already
+exists a package and if not, allow packagers to submit directly to
+core/updates? That way the first version of the package will make it to
+updates but subsequent changes will have to go via QA?
+
+While the "oops I messed up the first version" problem could happen, it
+would at least keep the burden on the packager for the majority of cases
+which is how we want it (from my understanding of the previous messages
+on this thread).
+
+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-June/005258.html b/zarb-ml/mageia-dev/2011-June/005258.html new file mode 100644 index 000000000..3552409b0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005258.html @@ -0,0 +1,147 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Thu Jun 9 12:00:07 CEST 2011 +

+
+ +
2011/6/9 Colin Guthrie <mageia at colin.guthr.ie>:
+> 'Twas brillig, and Wolfgang Bornath at 09/06/11 10:25 did gyre and gimble:
+>> 2011/6/9 JA Magallón <jamagallon at ono.com>:
+>>>
+>>> No need, Cauldron is Cauldron. The only strange thing is that I had
+>>> heard on other threads that update to Gnome 3 was being discussed,
+>>> but never realized it had finally agreed on.
+>>
+>> Same here, I'm a bit surprised.
+>
+> We're on the next cycle now. Quite frankly I'd be stunned (and hugely
+> disappointed) if we *didn't* have Gnome 3!
+>
+> Providing a Gnome2 environment or not is likely the point that need
+> discussion :D
+
+Yes, I surely agree to that.
+And my surprise was caused by not yet fully operational synapsis in my
+biologic core data center.
+I mixed "Gnome2" with "Unity" :(
+
+(I should not read mails before breakfast, it's not even noon here!)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005259.html b/zarb-ml/mageia-dev/2011-June/005259.html new file mode 100644 index 000000000..cb383ead7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005259.html @@ -0,0 +1,167 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ JA Magallón + jamagallon at ono.com +
+ Thu Jun 9 12:02:20 CEST 2011 +

+
+ +
On Thu, 09 Jun 2011 10:49:18 +0100, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+
+> 'Twas brillig, and Wolfgang Bornath at 09/06/11 10:25 did gyre and gimble:
+> > 2011/6/9 JA Magallón <jamagallon at ono.com>:
+> >>
+> >> No need, Cauldron is Cauldron. The only strange thing is that I had
+> >> heard on other threads that update to Gnome 3 was being discussed,
+> >> but never realized it had finally agreed on.
+> > 
+> > Same here, I'm a bit surprised.
+> 
+> We're on the next cycle now. Quite frankly I'd be stunned (and hugely
+> disappointed) if we *didn't* have Gnome 3!
+> 
+> Providing a Gnome2 environment or not is likely the point that need
+> discussion :D
+> 
++1
+
+One question:
+
+xps:/etc/X11/wmsession.d# ll
+total 16
+-rw-r--r-- 1 root root 131 2011.06.08 11:00 02GNOME
+-rw-r--r-- 1 root root 116 2011.03.25 00:36 06Xfce
+-rw-r--r-- 1 root root 177 2011.06.08 11:31 11GNOME3
+-rw-r--r-- 1 root root 118 2011.02.07 22:12 29drak3d
+xps:/etc/X11/wmsession.d# rpm -qf *
+gnome-session-3.0.1-1.mga2
+xfce-utils-4.8.1-5.mga1
+gnome-shell-3.0.2-1.mga2
+drak3d-1.30-1.mga1
+
+What is the difference between bot gnomes ? IE, gnome-session and
+gnome-shell-session ?
+
+Now we don't have gnome 2 (gnome 3 uninstalled almost everything), so ?
+
+TIA
+
+-- 
+J.A. Magallon <jamagallon()ono!com>     \                 Winter is coming...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005260.html b/zarb-ml/mageia-dev/2011-June/005260.html new file mode 100644 index 000000000..b139236c1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005260.html @@ -0,0 +1,189 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Thu Jun 9 12:03:44 CEST 2011 +

+
+ +
2011/6/9 Colin Guthrie <mageia at colin.guthr.ie>:
+> 'Twas brillig, and Christiaan Welvaart at 09/06/11 10:40 did gyre and
+> gimble:
+>> On Thu, 9 Jun 2011, Maarten Vanraes wrote:
+>>
+>>> otoh, perhaps a missing package is also a bugfix... maybe we could
+>>> file bug
+>>> reports for missing packages and go through the updates route...
+>>
+>> Filing bug reports is not a bad idea, even if the new package will go to
+>> backports. Just explain a little why it is important (to fix this in a
+>> stable release).
+>>
+>> We probably need a new "version" in bugzilla because mga1+backports is
+>> basically a new distro. A bug in backports shouldn't be filed against
+>> "1" IMHO.
+
+There's already a lot of requests for missing packages in Bugzilla,
+the question about filing such bug reports was answered long ago.
+
+> As I said in my original mail I really don't think backports is the
+> right approach.
+>
+> I'd prefer to have a 3rd party repo than abuse backports to get the
+> missing packages.
+
+I thought we will try to avoid 3rd party repos?
+
+> I think updates would be the right place.
+>
+> Perhaps we can make the submission process check to see if there already
+> exists a package and if not, allow packagers to submit directly to
+> core/updates? That way the first version of the package will make it to
+> updates but subsequent changes will have to go via QA?
+>
+> While the "oops I messed up the first version" problem could happen, it
+> would at least keep the burden on the packager for the majority of cases
+> which is how we want it (from my understanding of the previous messages
+> on this thread).
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005261.html b/zarb-ml/mageia-dev/2011-June/005261.html new file mode 100644 index 000000000..b67c42430 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005261.html @@ -0,0 +1,217 @@ + + + + [Mageia-dev] [102224] + + + + + + + + + +

[Mageia-dev] [102224]

+ John Balcaen + mikala at mageia.org +
+ Thu Jun 9 12:06:19 CEST 2011 +

+
+ +
2011/6/8  <root at mageia.org>:
+> Revision 102224 Author ze Date 2011-06-09 04:57:19 +0200 (Thu, 09 Jun 2011)
+>
+> Log Message
+>
+> - move binary xf86gammacfg to proper package kgamma
+>
+[...]
+>  %files -n kgamma
+>  %defattr(-,root,root)
+> +%_kde_bindir/xf86gammacfg
+>  %_kde_datadir/kde4/services/kgamma*
+[...]
+> +
+>
+> #-----------------------------------------------------------------------------
+>
+>  %package -n kamera
+> @@ -155,7 +157,6 @@
+>  %files -n okular
+>  %defattr(-,root,root)
+>  %_kde_bindir/okular
+> -%_kde_bindir/xf86gammacfg
+[...]
+
+You need to add a conflict here because you don't know in which order
+kamera or kgamma can be installed.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005262.html b/zarb-ml/mageia-dev/2011-June/005262.html new file mode 100644 index 000000000..d8d3eb160 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005262.html @@ -0,0 +1,165 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Dexter Morgan + dmorganec at gmail.com +
+ Thu Jun 9 12:15:12 CEST 2011 +

+
+ +
2011/6/9 JA Magallón <jamagallon at ono.com>:
+> On Thu, 09 Jun 2011 10:49:18 +0100, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+>
+>> 'Twas brillig, and Wolfgang Bornath at 09/06/11 10:25 did gyre and gimble:
+>> > 2011/6/9 JA Magallón <jamagallon at ono.com>:
+>> >>
+>> >> No need, Cauldron is Cauldron. The only strange thing is that I had
+>> >> heard on other threads that update to Gnome 3 was being discussed,
+>> >> but never realized it had finally agreed on.
+>> >
+>> > Same here, I'm a bit surprised.
+>>
+>> We're on the next cycle now. Quite frankly I'd be stunned (and hugely
+>> disappointed) if we *didn't* have Gnome 3!
+>>
+>> Providing a Gnome2 environment or not is likely the point that need
+>> discussion :D
+>>
+> +1
+>
+> One question:
+>
+> xps:/etc/X11/wmsession.d# ll
+> total 16
+> -rw-r--r-- 1 root root 131 2011.06.08 11:00 02GNOME
+> -rw-r--r-- 1 root root 116 2011.03.25 00:36 06Xfce
+> -rw-r--r-- 1 root root 177 2011.06.08 11:31 11GNOME3
+> -rw-r--r-- 1 root root 118 2011.02.07 22:12 29drak3d
+> xps:/etc/X11/wmsession.d# rpm -qf *
+> gnome-session-3.0.1-1.mga2
+> xfce-utils-4.8.1-5.mga1
+> gnome-shell-3.0.2-1.mga2
+> drak3d-1.30-1.mga1
+>
+> What is the difference between bot gnomes ? IE, gnome-session and
+> gnome-shell-session ?
+>
+> Now we don't have gnome 2 (gnome 3 uninstalled almost everything), so ?
+
+can you do a rpm -qf for  02GNOME please ?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005263.html b/zarb-ml/mageia-dev/2011-June/005263.html new file mode 100644 index 000000000..8db57bfd4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005263.html @@ -0,0 +1,209 @@ + + + + [Mageia-dev] KDE Update plan + + + + + + + + + +

[Mageia-dev] KDE Update plan

+ Balcaen John + mikala at mageia.org +
+ Thu Jun 9 12:24:57 CEST 2011 +

+
+ +
Hello,
+
+I noticed that gnome is moving to the 3.x release,on kde we're going to stick 
+in the next days with KDE SC 4.6.x until probably RC1 of KDE 4.7 (so by the 
+end of the month)  :
+- upstream might reconsider the tarball creation (currently there's a lot of 
+splitted tarballs :D ) so it's a way to reduce the packaging work :D
+- it's a good way to have more tests for kde as i want to provide (will need 
+to talk about that with Qa team & Sec team) the KDE SC 4.6.x for mageia 1.
+- kdepim should be back in the KDE release 
+we currently providing kdepim 4.4.x 
+switching currently to the next kdepim 4.6 immediatly could provides some 
+files conflicts due to the l10n files ( kdepim 4.6 comes with his own l10n-
+files while they should be available again in kde-l10n for KDE SC  4.7)
+
+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-June/005264.html b/zarb-ml/mageia-dev/2011-June/005264.html new file mode 100644 index 000000000..554bf027b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005264.html @@ -0,0 +1,201 @@ + + + + [Mageia-dev] [RFC] Update of Gnome + + + + + + + + + +

[Mageia-dev] [RFC] Update of Gnome

+ Dexter Morgan + dmorganec at gmail.com +
+ Thu Jun 9 12:26:41 CEST 2011 +

+
+ +
Hello to all,
+
+as we say, better late than never :)  so i announce that cauldron is
+in WIP for the update to gnome3
+
+I hope to finish tomorrow for the complete gnome.
+
+For now you can have an half working gnome so don't report bugreports
+for the moment, i will mail back when ready.
+
+
+thanks for all.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005265.html b/zarb-ml/mageia-dev/2011-June/005265.html new file mode 100644 index 000000000..677c6ed66 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005265.html @@ -0,0 +1,175 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ JA Magallón + jamagallon at ono.com +
+ Thu Jun 9 12:30:40 CEST 2011 +

+
+ +
On Thu, 9 Jun 2011 11:51:43 +0200, Dexter Morgan <dmorganec at gmail.com> wrote:
+
+> On Thu, Jun 9, 2011 at 11:28 AM, Olav Vitters <olav at vitters.nl> wrote:
+> > On Thu, Jun 09, 2011 at 11:20:10AM +0200, JA Magallón wrote:
+> >> This is .xsession-errors:
+> >> Window manager warning: Failed to load theme "Adwaita": Failed to find a valid file for theme Adwaita
+> >
+> > needs gnome-themes-standard
+> 
+> thanks a lot for all your inputs,  so i think all will be better when
+> i will finish updating  gnome.
+> 
+> For policykit i will update too today then
+> 
+> thanks again :)
+
+I have been takin a look to versions of things, and perhaps you could update
+things in this order:
+
+- GLib: we have 2.28.6, there is 2.28.8
+- GObjectIntrospection: we have 0.10.7, latest is 0.10.8
+- consolekit: now 0.4.3, there is a 0.4.5
+- gtk is up to date
+- gtk engines -> 2.91
+
+  in this kind of very new release, perhaps a third decimal makes a difference...
+
+- gdm: get the new 3.0.4
+  could it be that old gdm is not setting things properly for new gnome sessions ?
+
+Complicated, lots of things to update for Gnome 3. It will be nice...
+
+-- 
+J.A. Magallon <jamagallon()ono!com>     \                 Winter is coming...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005266.html b/zarb-ml/mageia-dev/2011-June/005266.html new file mode 100644 index 000000000..21b34b557 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005266.html @@ -0,0 +1,210 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ JA Magallón + jamagallon at ono.com +
+ Thu Jun 9 12:35:14 CEST 2011 +

+
+ +
On Thu, 9 Jun 2011 12:15:12 +0200, Dexter Morgan <dmorganec at gmail.com> wrote:
+
+> 2011/6/9 JA Magallón <jamagallon at ono.com>:
+> > On Thu, 09 Jun 2011 10:49:18 +0100, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+> >
+> >> 'Twas brillig, and Wolfgang Bornath at 09/06/11 10:25 did gyre and gimble:
+> >> > 2011/6/9 JA Magallón <jamagallon at ono.com>:
+> >> >>
+> >> >> No need, Cauldron is Cauldron. The only strange thing is that I had
+> >> >> heard on other threads that update to Gnome 3 was being discussed,
+> >> >> but never realized it had finally agreed on.
+> >> >
+> >> > Same here, I'm a bit surprised.
+> >>
+> >> We're on the next cycle now. Quite frankly I'd be stunned (and hugely
+> >> disappointed) if we *didn't* have Gnome 3!
+> >>
+> >> Providing a Gnome2 environment or not is likely the point that need
+> >> discussion :D
+> >>
+> > +1
+> >
+> > One question:
+> >
+> > xps:/etc/X11/wmsession.d# ll
+> > total 16
+> > -rw-r--r-- 1 root root 131 2011.06.08 11:00 02GNOME
+> > -rw-r--r-- 1 root root 116 2011.03.25 00:36 06Xfce
+> > -rw-r--r-- 1 root root 177 2011.06.08 11:31 11GNOME3
+> > -rw-r--r-- 1 root root 118 2011.02.07 22:12 29drak3d
+> > xps:/etc/X11/wmsession.d# rpm -qf *
+> > gnome-session-3.0.1-1.mga2
+> > xfce-utils-4.8.1-5.mga1
+> > gnome-shell-3.0.2-1.mga2
+> > drak3d-1.30-1.mga1
+> >
+> > What is the difference between bot gnomes ? IE, gnome-session and
+> > gnome-shell-session ?
+> >
+> > Now we don't have gnome 2 (gnome 3 uninstalled almost everything), so ?
+> 
+> can you do a rpm -qf for  02GNOME please ?
+
+xps:/etc/X11/wmsession.d# ll
+total 16
+-rw-r--r-- 1 root root 131 2011.06.08 11:00 02GNOME
+-rw-r--r-- 1 root root 116 2011.03.25 00:36 06Xfce
+-rw-r--r-- 1 root root 177 2011.06.08 11:31 11GNOME3
+-rw-r--r-- 1 root root 118 2011.02.07 22:12 29drak3d
+xps:/etc/X11/wmsession.d# rpm -qf *
+gnome-session-3.0.1-1.mga2   <=====================
+xfce-utils-4.8.1-5.mga1
+gnome-shell-3.0.2-1.mga2
+drak3d-1.30-1.mga1
+
+But, if you look at it:
+
+xps:/etc/X11/wmsession.d# cat 11*
+NAME=GNOME 3
+ICON=gnome-logo-icon-transparent.png
+DESC=GNOME Environment
+EXEC=/usr/share/gnome-shell/gnome-shell-session
+SCRIPT:
+exec /usr/share/gnome-shell/gnome-shell-session
+xps:/etc/X11/wmsession.d# cat /usr/share/gnome-shell/gnome-shell-session
+#!/bin/bash
+#
+# Script to start a GNOME session in a GNOME 3 preview mode.
+#
+
+if test -n "$XDG_CONFIG_DIRS"; then
+    export XDG_CONFIG_DIRS=/usr/share/gnome-shell/xdg-override:$XDG_CONFIG_DIRS
+else
+    export XDG_CONFIG_DIRS=/usr/share/gnome-shell/xdg-override:/etc/xdg
+fi
+
+exec /usr/bin/startgnome $*
+
+It looks like the session file in gnome-shell-3.0.2 is just for testing,
+the good one seems to be that in gnome-session (INMHO...).
+Probably you need to kill 11GNOME, and in a future if we have it add a
+"GNOME2" or "GNOME Simple" or the like...
+
+-- 
+J.A. Magallon <jamagallon()ono!com>     \                 Winter is coming...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005267.html b/zarb-ml/mageia-dev/2011-June/005267.html new file mode 100644 index 000000000..2fc63b1d0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005267.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ nicolas vigier + boklm at mars-attacks.org +
+ Thu Jun 9 12:35:42 CEST 2011 +

+
+ +
On Thu, 09 Jun 2011, Michael Scherer wrote:
+
+> Le jeudi 09 juin 2011 à 02:40 +0300, Ahmad Samir a écrit :
+> 
+> > Yes, but I was talking about the actual submitting to */release, not
+> > fixing the package itself. IIUC the submission rights will be
+> > restricted to the Sec team.
+> 
+> Sorry to be picky, but there is no submit to */release, it is frozen.
+> And in my proposition, there is also no submit to */update, there is a
+> move from */updates_testing.
+
+In that case, if the package is not rebuilt and only moved from
+*/updates_testing, we need to disable the */updates_testing repository
+in iurt during builds of packages for */updates_testing repository, to
+make sure it is not linked to an other testing package.
+I think this was not the case on testing repository on mandriva.
+
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005268.html b/zarb-ml/mageia-dev/2011-June/005268.html new file mode 100644 index 000000000..31d22ee8d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005268.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Thomas Backlund + tmb at mageia.org +
+ Thu Jun 9 12:42:15 CEST 2011 +

+
+ +
nicolas vigier skrev 9.6.2011 13:35:
+> On Thu, 09 Jun 2011, Michael Scherer wrote:
+>
+>> Le jeudi 09 juin 2011 à 02:40 +0300, Ahmad Samir a écrit :
+>>
+>>> Yes, but I was talking about the actual submitting to */release, not
+>>> fixing the package itself. IIUC the submission rights will be
+>>> restricted to the Sec team.
+>>
+>> Sorry to be picky, but there is no submit to */release, it is frozen.
+>> And in my proposition, there is also no submit to */update, there is a
+>> move from */updates_testing.
+>
+> In that case, if the package is not rebuilt and only moved from
+> */updates_testing, we need to disable the */updates_testing repository
+> in iurt during builds of packages for */updates_testing repository, to
+> make sure it is not linked to an other testing package.
+> I think this was not the case on testing repository on mandriva.
+>
+
+That wont work.
+
+Think of programs that need to be rebuilt with an other updated 
+package.. and pushed to /updates all at once.
+
+such as a big kde update, ...
+
+
+--
+Thomas
+
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005269.html b/zarb-ml/mageia-dev/2011-June/005269.html new file mode 100644 index 000000000..08f7f1aab --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005269.html @@ -0,0 +1,159 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ JA Magallón + jamagallon at ono.com +
+ Thu Jun 9 12:52:35 CEST 2011 +

+
+ +
On Thu, 9 Jun 2011 12:15:12 +0200, Dexter Morgan <dmorganec at gmail.com> wrote:
+
+> 2011/6/9 JA Magallón <jamagallon at ono.com>:
+> > On Thu, 09 Jun 2011 10:49:18 +0100, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+> >
+> >> 'Twas brillig, and Wolfgang Bornath at 09/06/11 10:25 did gyre and gimble:
+> >> > 2011/6/9 JA Magallón <jamagallon at ono.com>:
+> >> >>
+> >> >> No need, Cauldron is Cauldron. The only strange thing is that I had
+> >> >> heard on other threads that update to Gnome 3 was being discussed,
+> >> >> but never realized it had finally agreed on.
+> >> >
+> >> > Same here, I'm a bit surprised.
+> >>
+> >> We're on the next cycle now. Quite frankly I'd be stunned (and hugely
+> >> disappointed) if we *didn't* have Gnome 3!
+> >>
+> >> Providing a Gnome2 environment or not is likely the point that need
+> >> discussion :D
+> >>
+
+One other question (that's what pedantic users are for, isn't it ;) ).
+Now we have:
+
+gnome-desktop-2.32.1-1.mga1
+gnome-desktop3-3.0.2-1.mga2
+
+The old one just contains a bunch of generic icons.
+You could post a new gnome-desktop-3.0.x and obsolete both...
+As Gnome moves to 3, no suffix is needed. If ever one is, it would be for
+gnome2 packages one future day, isn't it ?
+
+TIA
+
+-- 
+J.A. Magallon <jamagallon()ono!com>     \                 Winter is coming...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005270.html b/zarb-ml/mageia-dev/2011-June/005270.html new file mode 100644 index 000000000..f900cc590 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005270.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ nicolas vigier + boklm at mars-attacks.org +
+ Thu Jun 9 12:53:31 CEST 2011 +

+
+ +
On Thu, 09 Jun 2011, Thomas Backlund wrote:
+
+> nicolas vigier skrev 9.6.2011 13:35:
+>> On Thu, 09 Jun 2011, Michael Scherer wrote:
+>>
+>>> Le jeudi 09 juin 2011 à 02:40 +0300, Ahmad Samir a écrit :
+>>>
+>>>> Yes, but I was talking about the actual submitting to */release, not
+>>>> fixing the package itself. IIUC the submission rights will be
+>>>> restricted to the Sec team.
+>>>
+>>> Sorry to be picky, but there is no submit to */release, it is frozen.
+>>> And in my proposition, there is also no submit to */update, there is a
+>>> move from */updates_testing.
+>>
+>> In that case, if the package is not rebuilt and only moved from
+>> */updates_testing, we need to disable the */updates_testing repository
+>> in iurt during builds of packages for */updates_testing repository, to
+>> make sure it is not linked to an other testing package.
+>> I think this was not the case on testing repository on mandriva.
+>>
+>
+> That wont work.
+>
+> Think of programs that need to be rebuilt with an other updated package.. 
+> and pushed to /updates all at once.
+>
+> such as a big kde update, ...
+
+Yes. One long term solutions could be to create a temporary testing repository,
+for each update.
+
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005271.html b/zarb-ml/mageia-dev/2011-June/005271.html new file mode 100644 index 000000000..4f99f7df2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005271.html @@ -0,0 +1,197 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Jun 9 13:39:17 CEST 2011 +

+
+ +
'Twas brillig, and Wolfgang Bornath at 09/06/11 11:03 did gyre and gimble:
+> 2011/6/9 Colin Guthrie <mageia at colin.guthr.ie>:
+>> 'Twas brillig, and Christiaan Welvaart at 09/06/11 10:40 did gyre and
+>> gimble:
+>>> On Thu, 9 Jun 2011, Maarten Vanraes wrote:
+>>>
+>>>> otoh, perhaps a missing package is also a bugfix... maybe we could
+>>>> file bug
+>>>> reports for missing packages and go through the updates route...
+>>>
+>>> Filing bug reports is not a bad idea, even if the new package will go to
+>>> backports. Just explain a little why it is important (to fix this in a
+>>> stable release).
+>>>
+>>> We probably need a new "version" in bugzilla because mga1+backports is
+>>> basically a new distro. A bug in backports shouldn't be filed against
+>>> "1" IMHO.
+> 
+> There's already a lot of requests for missing packages in Bugzilla,
+> the question about filing such bug reports was answered long ago.
+> 
+>> As I said in my original mail I really don't think backports is the
+>> right approach.
+>>
+>> I'd prefer to have a 3rd party repo than abuse backports to get the
+>> missing packages.
+> 
+> I thought we will try to avoid 3rd party repos?
+
+Yes we did, but I still think it would be better than using backports as
+backports is very specifically "not-supported updates" and if users have
+to add that media to get the missing packages then IMO this is very
+dangerous. Hence my statement that it would *prefer* to use a 3rd party
+repo over using backports as it is safer for the user. It doesn't mean
+to say I like the idea in an absolute sense.
+
+My *preferred* (i.e. absolute, not relative) is to use updates, but
+without the QA burden and overhead.
+
+Hope that clarifies.
+
+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-June/005272.html b/zarb-ml/mageia-dev/2011-June/005272.html new file mode 100644 index 000000000..733344048 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005272.html @@ -0,0 +1,176 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ andre999 + andr55 at laposte.net +
+ Thu Jun 9 13:41:27 CEST 2011 +

+
+ +
JA Magallón a écrit :
+>
+> On Thu, 9 Jun 2011 11:51:43 +0200, Dexter Morgan<dmorganec at gmail.com>  wrote:
+>
+>> On Thu, Jun 9, 2011 at 11:28 AM, Olav Vitters<olav at vitters.nl>  wrote:
+>>> On Thu, Jun 09, 2011 at 11:20:10AM +0200, JA Magallón wrote:
+>>>> This is .xsession-errors:
+>>>> Window manager warning: Failed to load theme "Adwaita": Failed to find a valid file for theme Adwaita
+>>>
+>>> needs gnome-themes-standard
+>>
+>> thanks a lot for all your inputs,  so i think all will be better when
+>> i will finish updating  gnome.
+>>
+>> For policykit i will update too today then
+>>
+>> thanks again :)
+>
+> I have been takin a look to versions of things, and perhaps you could update
+> things in this order:
+>
+> - GLib: we have 2.28.6, there is 2.28.8
+> - GObjectIntrospection: we have 0.10.7, latest is 0.10.8
+> - consolekit: now 0.4.3, there is a 0.4.5
+> - gtk is up to date
+> - gtk engines ->  2.91
+>
+>    in this kind of very new release, perhaps a third decimal makes a difference...
+>
+> - gdm: get the new 3.0.4
+>    could it be that old gdm is not setting things properly for new gnome sessions ?
+>
+> Complicated, lots of things to update for Gnome 3. It will be nice...
+
+If I'm following it correctly, the rewrite of gdm in gnome is still a work in progress
+https://bugzilla.gnome.org/show_bug.cgi?id=587750
+(But maybe they just continued the rewrite without updating the bug report ?)
+Anyway, gdm has not been saving session settings for a while.
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005273.html b/zarb-ml/mageia-dev/2011-June/005273.html new file mode 100644 index 000000000..85440b47a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005273.html @@ -0,0 +1,216 @@ + + + + [Mageia-dev] Switching from Cooker to Cauldron? + + + + + + + + + +

[Mageia-dev] Switching from Cooker to Cauldron?

+ Olav Vitters + olav at vitters.nl +
+ Thu Jun 9 13:44:25 CEST 2011 +

+
+ +
Hello,
+
+Now that GNOME3 is being imported to Cauldron, I'd like to switch my
+Mandriva Cooker installation to Cauldron.
+
+However, Cooker has a different rpm for a while and I have that
+installed.
+
+I'm guessing if I attempt to switch to Cauldron, it likely cannot read
+the rpm5 database.
+
+I can only think of a few things:
+1. Create a new partition, install Mageia 1 on that, switch to Cauldron,
+install all the non-automatic installed packages, copy stuff from the
+Cauldron partition to the existing one
+-> Not too sure about the copying. I've modified various things over the
+years (e.g. special Postfix setup and so on)
+2. Just attempt to install Cauldron, forcefully reinstall the packages,
+and ignore the rpm difference
+-> I think this will fail though
+3. Somehow export/downgrade the 'rpm5' info to rpm4. Is this possible
+and how?
+4. Wait for Mageia to have rpm5. Is this planned?
+
+
+Any advice?
+
+
+Note: I don't mind some ugly workaround. e.g. I switched from i386->x86_64
+without reinstalling. My Cooker installation is from 2004 or so.
+-- 
+Regards,
+Olav
+
+PS: As I want to use Cauldron I used the -dev list. Hope that's ok.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005274.html b/zarb-ml/mageia-dev/2011-June/005274.html new file mode 100644 index 000000000..3cb86c395 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005274.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] automatic chroot install using urpmi + + + + + + + + + +

[Mageia-dev] automatic chroot install using urpmi

+ Vasiliy G Tolstov + v.tolstov at selfip.ru +
+ Thu Jun 9 14:08:32 CEST 2011 +

+
+ +
On Thu, 2011-06-09 at 05:47 +0200, Bruno Cornec wrote:
+> Vasiliy G Tolstov said on Wed, Jun 08, 2011 at 04:26:35PM +0400:
+> 
+> > Thank's for answer. Very well. If i use basesystem-minimal and append
+> > grub systemd ntpd openssh-server and kernel, does that system can
+> > boot-up ?
+> 
+> You may want to look at rpmbootstrap, which was working fine for
+> mdv2010.2 and thus should easily work for mageia 1 as well. (part of
+> project-builder.org), this tools creates operational chroot for RPM
+> based distros, similar to debbootstrap and better than rinse or mock ,
+> as being multi distro (fedora, rhel, opensuse, mdv, mageia, ...)
+> 
+> I use it to create the chroots (VEs) needed by project-builder.org to
+> build its packages, zhen not using VMs.
+> 
+> HTH,
+> Bruno.
+
+I'm port project-builder to my linux distro - Exherbo. Fedora build
+success, but centos 5.6 with cmd line like:
+
+rpmbootstrap  -v centos-5.6-x86_64 -a
+acl,anacron,attr,audit,bc,diffutils,file,ftp,grub,groff,ipsec-tools,iptables,iptables-ipv6,kbd,
+jwhois,kernel-xen,man,man-pages,mgetty,ntp,passwd,quota,screen,checkpolicy,libselinux-utils,
+policycoreutils,selinux-policy-targeted,sysfsutils,sysklogd,system-config-securitylevel-tui,
+time,unzip,vim-enhanced,which,wget,openssh-clients,openssh,openssh-server,libselinux-utils,
+libselinux-python,at,setools,setuptool,rootfiles,setarch,yum-priorities,yum-downloadonly,yum-utils,exim /root/t
+
+can't determine mirror... if i specify version 5, it tries to install
+5.5 that not in kernel.org mirror... can i specify url where rpm lives?
+
+
+-- 
+Vasiliy G Tolstov <v.tolstov at selfip.ru>
+Selfip.Ru
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005275.html b/zarb-ml/mageia-dev/2011-June/005275.html new file mode 100644 index 000000000..3d37a64ea --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005275.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] automatic chroot install using urpmi + + + + + + + + + +

[Mageia-dev] automatic chroot install using urpmi

+ Vasiliy G Tolstov + v.tolstov at selfip.ru +
+ Thu Jun 9 14:12:50 CEST 2011 +

+
+ +
On Thu, 2011-06-09 at 16:08 +0400, Vasiliy G Tolstov wrote:
+> On Thu, 2011-06-09 at 05:47 +0200, Bruno Cornec wrote:
+> > Vasiliy G Tolstov said on Wed, Jun 08, 2011 at 04:26:35PM +0400:
+> > 
+> > > Thank's for answer. Very well. If i use basesystem-minimal and append
+> > > grub systemd ntpd openssh-server and kernel, does that system can
+> > > boot-up ?
+> > 
+> > You may want to look at rpmbootstrap, which was working fine for
+> > mdv2010.2 and thus should easily work for mageia 1 as well. (part of
+> > project-builder.org), this tools creates operational chroot for RPM
+> > based distros, similar to debbootstrap and better than rinse or mock ,
+> > as being multi distro (fedora, rhel, opensuse, mdv, mageia, ...)
+> > 
+> > I use it to create the chroots (VEs) needed by project-builder.org to
+> > build its packages, zhen not using VMs.
+> > 
+> > HTH,
+> > Bruno.
+> 
+> I'm port project-builder to my linux distro - Exherbo. Fedora build
+> success, but centos 5.6 with cmd line like:
+> 
+> rpmbootstrap  -v centos-5.6-x86_64 -a
+> acl,anacron,attr,audit,bc,diffutils,file,ftp,grub,groff,ipsec-tools,iptables,iptables-ipv6,kbd,
+> jwhois,kernel-xen,man,man-pages,mgetty,ntp,passwd,quota,screen,checkpolicy,libselinux-utils,
+> policycoreutils,selinux-policy-targeted,sysfsutils,sysklogd,system-config-securitylevel-tui,
+> time,unzip,vim-enhanced,which,wget,openssh-clients,openssh,openssh-server,libselinux-utils,
+> libselinux-python,at,setools,setuptool,rootfiles,setarch,yum-priorities,yum-downloadonly,yum-utils,exim /root/t
+> 
+> can't determine mirror... if i specify version 5, it tries to install
+> 5.5 that not in kernel.org mirror... can i specify url where rpm lives?
+> 
+> 
+
+Hmm I'm specify mirror, but it not helps:
+rpmbootstrap  -v centos-5.6-x86_64  /root/t
+http://mirror.yandex.ru/centos/5.6/os/x86_64/CentOS
+
+process stopped with:
+Debug value: 1
+Starting VE build for centos-5.6-x86_64
+Downloading package list from  ...
+
+
+-- 
+Vasiliy G Tolstov <v.tolstov at selfip.ru>
+Selfip.Ru
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005276.html b/zarb-ml/mageia-dev/2011-June/005276.html new file mode 100644 index 000000000..bd219c3de --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005276.html @@ -0,0 +1,164 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Dexter Morgan + dmorganec at gmail.com +
+ Thu Jun 9 14:13:29 CEST 2011 +

+
+ +
On Thu, Jun 9, 2011 at 11:54 AM, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+> 'Twas brillig, and Christiaan Welvaart at 09/06/11 10:40 did gyre and
+> gimble:
+>> On Thu, 9 Jun 2011, Maarten Vanraes wrote:
+>>
+>>> otoh, perhaps a missing package is also a bugfix... maybe we could
+>>> file bug
+>>> reports for missing packages and go through the updates route...
+>>
+>> Filing bug reports is not a bad idea, even if the new package will go to
+>> backports. Just explain a little why it is important (to fix this in a
+>> stable release).
+>>
+>> We probably need a new "version" in bugzilla because mga1+backports is
+>> basically a new distro. A bug in backports shouldn't be filed against
+>> "1" IMHO.
+>
+> As I said in my original mail I really don't think backports is the
+> right approach.
+>
+> I'd prefer to have a 3rd party repo than abuse backports to get the
+> missing packages.
+>
+> I think updates would be the right place.
+
+Please no 3rd repo :)
+But i agree with you for updates for "new" packages ( no "new" versions ;) )
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005277.html b/zarb-ml/mageia-dev/2011-June/005277.html new file mode 100644 index 000000000..d5733cbe2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005277.html @@ -0,0 +1,170 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Sander Lepik + sander.lepik at eesti.ee +
+ Thu Jun 9 14:17:43 CEST 2011 +

+
+ +
09.06.2011 15:13, Dexter Morgan kirjutas:
+> On Thu, Jun 9, 2011 at 11:54 AM, Colin Guthrie<mageia at colin.guthr.ie>  wrote:
+>> 'Twas brillig, and Christiaan Welvaart at 09/06/11 10:40 did gyre and
+>> gimble:
+>>> On Thu, 9 Jun 2011, Maarten Vanraes wrote:
+>>>
+>>>> otoh, perhaps a missing package is also a bugfix... maybe we could
+>>>> file bug
+>>>> reports for missing packages and go through the updates route...
+>>> Filing bug reports is not a bad idea, even if the new package will go to
+>>> backports. Just explain a little why it is important (to fix this in a
+>>> stable release).
+>>>
+>>> We probably need a new "version" in bugzilla because mga1+backports is
+>>> basically a new distro. A bug in backports shouldn't be filed against
+>>> "1" IMHO.
+>> As I said in my original mail I really don't think backports is the
+>> right approach.
+>>
+>> I'd prefer to have a 3rd party repo than abuse backports to get the
+>> missing packages.
+>>
+>> I think updates would be the right place.
+> Please no 3rd repo :)
+> But i agree with you for updates for "new" packages ( no "new" versions ;) )
+Indeed it's not good idea to suggest backports for novice users. +1 for updates repo if the 
+new package is just new thing and nothing is going to depend on it or will suggest it before 
+new Mageia release.
+
+--
+Sander
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005278.html b/zarb-ml/mageia-dev/2011-June/005278.html new file mode 100644 index 000000000..4e94657dd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005278.html @@ -0,0 +1,172 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Thu Jun 9 14:22:29 CEST 2011 +

+
+ +
Dexter Morgan <dmorganec at gmail.com> schrieb am 09.06.2011
+> On Thu, Jun 9, 2011 at 11:54 AM, Colin Guthrie 
+<mageia at colin.guthr.ie> wrote:
+> > I think updates would be the right place.
+> 
+> Please no 3rd repo :)
+> But i agree with you for updates for "new" packages ( no "new"
+> versions ;) )
+
+
+
+
+
+I would prefer using updates over backports as well. If we use 
+backports we would get more problems then benefit (like people not 
+having backports enabled or people having backports enabled and thus 
+getting problems they can't handle e.g. with new kernels, graphic 
+drivers and so on).
+
+
+
+
+
+Perhaps we could upload them to updates/testing for a really short qa 
+before moving them to updates/ ?
+
+
+
+
+
+Oliver
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110609/9f425792/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005279.html b/zarb-ml/mageia-dev/2011-June/005279.html new file mode 100644 index 000000000..251ad0880 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005279.html @@ -0,0 +1,211 @@ + + + + [Mageia-dev] Switching from Cooker to Cauldron? + + + + + + + + + +

[Mageia-dev] Switching from Cooker to Cauldron?

+ Per Øyvind Karlsen + peroyvind at mandriva.org +
+ Thu Jun 9 14:24:33 CEST 2011 +

+
+ +
2011/6/9 Olav Vitters <olav at vitters.nl>:
+> Hello,
+>
+> Now that GNOME3 is being imported to Cauldron, I'd like to switch my
+> Mandriva Cooker installation to Cauldron.
+>
+> However, Cooker has a different rpm for a while and I have that
+> installed.
+>
+> I'm guessing if I attempt to switch to Cauldron, it likely cannot read
+> the rpm5 database.
+>
+> I can only think of a few things:
+> 1. Create a new partition, install Mageia 1 on that, switch to Cauldron,
+> install all the non-automatic installed packages, copy stuff from the
+> Cauldron partition to the existing one
+> -> Not too sure about the copying. I've modified various things over the
+> years (e.g. special Postfix setup and so on)
+> 2. Just attempt to install Cauldron, forcefully reinstall the packages,
+> and ignore the rpm difference
+> -> I think this will fail though
+> 3. Somehow export/downgrade the 'rpm5' info to rpm4. Is this possible
+> and how?
+Yes, there's a URPM::DB::convert() function in URPM >= 4.8 which can do this,
+and there's also a standalone utility provided with rpm5
+(/usr/lib/rpm/dbconvert)
+which also can do this.
+
+You want to convert the format from btree, big endian to hash, little
+endian in order
+for the rpmdb to work with rpm <= 5.2.
+
+--
+Regards,
+Per Øyvind
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005280.html b/zarb-ml/mageia-dev/2011-June/005280.html new file mode 100644 index 000000000..9b4d362b4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005280.html @@ -0,0 +1,222 @@ + + + + [Mageia-dev] Switching from Cooker to Cauldron? + + + + + + + + + +

[Mageia-dev] Switching from Cooker to Cauldron?

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Thu Jun 9 14:26:12 CEST 2011 +

+
+ +
On Thu, 9 Jun 2011, Olav Vitters wrote:
+
+> I'm guessing if I attempt to switch to Cauldron, it likely cannot read
+> the rpm5 database.
+>
+> I can only think of a few things:
+> 1. Create a new partition, install Mageia 1 on that, switch to Cauldron,
+> install all the non-automatic installed packages, copy stuff from the
+> Cauldron partition to the existing one
+> -> Not too sure about the copying. I've modified various things over the
+> years (e.g. special Postfix setup and so on)
+
+You can look for all config files you changed (probably using an rpm 
+command) and copy/merge those on the new system. Can be quite a bit of 
+work.
+
+> 2. Just attempt to install Cauldron, forcefully reinstall the packages,
+> and ignore the rpm difference
+> -> I think this will fail though
+
+You can wipe out the package database, but then after installing all 
+non-automatic installed packages, you'll probably have many files 
+unaccounted for (not owned by any installed package). Not a good idea 
+probably. Also all pre/post install scripts will be ran in new install 
+mode instead of upgrade mode. I did something like this with a VM (that 
+isn't very important to me) and I'm still finding new problems in it (but 
+it works anyway).
+
+> 3. Somehow export/downgrade the 'rpm5' info to rpm4. Is this possible
+> and how?
+
+There is supposedly a script that can convert the package database both 
+ways in mdv, but nobody probably tried this yet.
+
+> 4. Wait for Mageia to have rpm5. Is this planned?
+
+Not currently planned.
+
+> Note: I don't mind some ugly workaround. e.g. I switched from i386->x86_64
+> without reinstalling. My Cooker installation is from 2004 or so.
+
+A switch in architecture is not really ugly - the package database 
+supports this.
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005281.html b/zarb-ml/mageia-dev/2011-June/005281.html new file mode 100644 index 000000000..14ac3b333 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005281.html @@ -0,0 +1,223 @@ + + + + [Mageia-dev] Switching from Cooker to Cauldron? + + + + + + + + + +

[Mageia-dev] Switching from Cooker to Cauldron?

+ Per Øyvind Karlsen + peroyvind at mandriva.org +
+ Thu Jun 9 14:37:38 CEST 2011 +

+
+ +
2011/6/9 Christiaan Welvaart <cjw at daneel.dyndns.org>:
+> On Thu, 9 Jun 2011, Olav Vitters wrote:
+>
+>> I'm guessing if I attempt to switch to Cauldron, it likely cannot read
+>> the rpm5 database.
+>>
+>> I can only think of a few things:
+>> 1. Create a new partition, install Mageia 1 on that, switch to Cauldron,
+>> install all the non-automatic installed packages, copy stuff from the
+>> Cauldron partition to the existing one
+>> -> Not too sure about the copying. I've modified various things over the
+>> years (e.g. special Postfix setup and so on)
+>
+> You can look for all config files you changed (probably using an rpm
+> command) and copy/merge those on the new system. Can be quite a bit of work.
+>
+>> 2. Just attempt to install Cauldron, forcefully reinstall the packages,
+>> and ignore the rpm difference
+>> -> I think this will fail though
+>
+> You can wipe out the package database, but then after installing all
+> non-automatic installed packages, you'll probably have many files
+> unaccounted for (not owned by any installed package). Not a good idea
+> probably. Also all pre/post install scripts will be ran in new install mode
+> instead of upgrade mode. I did something like this with a VM (that isn't
+> very important to me) and I'm still finding new problems in it (but it works
+> anyway).
+>
+>> 3. Somehow export/downgrade the 'rpm5' info to rpm4. Is this possible
+>> and how?
+>
+> There is supposedly a script that can convert the package database both ways
+It's implemented in C using rpm & berkeley db api, so it's not a script.. ;)
+> in mdv, but nobody probably tried this yet.
+Not true, the functionality has even been implemented to be automatically
+used when installing older releases with urpmi.
+
+We're actually relying on it when installing older releases into clean
+chroots on
+cooker for building backports. :)
+
+The code in question should be trivial to swipe and implement in Mageia, I did
+offer to help with this previously, but with no interest..
+--
+Regards,
+Per Øyvind
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005282.html b/zarb-ml/mageia-dev/2011-June/005282.html new file mode 100644 index 000000000..a51ccc97e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005282.html @@ -0,0 +1,121 @@ + + + + [Mageia-dev] automatic chroot install using urpmi + + + + + + + + + +

[Mageia-dev] automatic chroot install using urpmi

+ Vasiliy G Tolstov + v.tolstov at selfip.ru +
+ Thu Jun 9 14:37:53 CEST 2011 +

+
+ +
On Thu, 2011-06-09 at 16:12 +0400, Vasiliy G Tolstov wrote:
+> On Thu, 2011-06-09 at 16:08 +0400, Vasiliy G Tolstov wrote:
+> > On Thu, 2011-06-09 at 05:47 +0200, Bruno Cornec wrote:
+> > > Vasiliy G Tolstov said on Wed, Jun 08, 2011 at 04:26:35PM +0400:
+> > > 
+> > > > Thank's for answer. Very well. If i use basesystem-minimal and append
+> > > > grub systemd ntpd openssh-server and kernel, does that system can
+> > > > boot-up ?
+> > > 
+> > > You may want to look at rpmbootstrap, which was working fine for
+> > > mdv2010.2 and thus should easily work for mageia 1 as well. (part of
+> > > project-builder.org), this tools creates operational chroot for RPM
+> > > based distros, similar to debbootstrap and better than rinse or mock ,
+> > > as being multi distro (fedora, rhel, opensuse, mdv, mageia, ...)
+> > > 
+> > > I use it to create the chroots (VEs) needed by project-builder.org to
+> > > build its packages, zhen not using VMs.
+> > > 
+> > > HTH,
+> > > Bruno.
+> > 
+> > I'm port project-builder to my linux distro - Exherbo. Fedora build
+> > success, but centos 5.6 with cmd line like:
+> > 
+> > rpmbootstrap  -v centos-5.6-x86_64 -a
+> > acl,anacron,attr,audit,bc,diffutils,file,ftp,grub,groff,ipsec-tools,iptables,iptables-ipv6,kbd,
+> > jwhois,kernel-xen,man,man-pages,mgetty,ntp,passwd,quota,screen,checkpolicy,libselinux-utils,
+> > policycoreutils,selinux-policy-targeted,sysfsutils,sysklogd,system-config-securitylevel-tui,
+> > time,unzip,vim-enhanced,which,wget,openssh-clients,openssh,openssh-server,libselinux-utils,
+> > libselinux-python,at,setools,setuptool,rootfiles,setarch,yum-priorities,yum-downloadonly,yum-utils,exim /root/t
+> > 
+> > can't determine mirror... if i specify version 5, it tries to install
+> > 5.5 that not in kernel.org mirror... can i specify url where rpm lives?
+> > 
+> > 
+> 
+> Hmm I'm specify mirror, but it not helps:
+> rpmbootstrap  -v centos-5.6-x86_64  /root/t
+> http://mirror.yandex.ru/centos/5.6/os/x86_64/CentOS
+> 
+> process stopped with:
+> Debug value: 1
+> Starting VE build for centos-5.6-x86_64
+> Downloading package list from  ...
+> 
+> 
+
+Ok. Error
+is /usr/lib/perl5/vendor_perl/5.12.3/ProjectBuilder/Distribution.pm line
+52
+
+sub pb_distro_conffile {
+
+return("/usr/local/etc/pb/pb.conf");
+}
+
+This path is incorrect and must depends on prefix .. in my case this
+config in /etc/pb.conf
+And please, upgrade centos version in it to 5.6 - 5.5 not in mirrors
+now.
+
+-- 
+Vasiliy G Tolstov <v.tolstov at selfip.ru>
+Selfip.Ru
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005283.html b/zarb-ml/mageia-dev/2011-June/005283.html new file mode 100644 index 000000000..1421073cd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005283.html @@ -0,0 +1,127 @@ + + + + [Mageia-dev] automatic chroot install using urpmi + + + + + + + + + +

[Mageia-dev] automatic chroot install using urpmi

+ Vasiliy G Tolstov + v.tolstov at selfip.ru +
+ Thu Jun 9 14:49:58 CEST 2011 +

+
+ +
On Thu, 2011-06-09 at 16:37 +0400, Vasiliy G Tolstov wrote:
+> On Thu, 2011-06-09 at 16:12 +0400, Vasiliy G Tolstov wrote:
+> > On Thu, 2011-06-09 at 16:08 +0400, Vasiliy G Tolstov wrote:
+> > > On Thu, 2011-06-09 at 05:47 +0200, Bruno Cornec wrote:
+> > > > Vasiliy G Tolstov said on Wed, Jun 08, 2011 at 04:26:35PM +0400:
+> > > > 
+> > > > > Thank's for answer. Very well. If i use basesystem-minimal and append
+> > > > > grub systemd ntpd openssh-server and kernel, does that system can
+> > > > > boot-up ?
+> > > > 
+> > > > You may want to look at rpmbootstrap, which was working fine for
+> > > > mdv2010.2 and thus should easily work for mageia 1 as well. (part of
+> > > > project-builder.org), this tools creates operational chroot for RPM
+> > > > based distros, similar to debbootstrap and better than rinse or mock ,
+> > > > as being multi distro (fedora, rhel, opensuse, mdv, mageia, ...)
+> > > > 
+> > > > I use it to create the chroots (VEs) needed by project-builder.org to
+> > > > build its packages, zhen not using VMs.
+> > > > 
+> > > > HTH,
+> > > > Bruno.
+> > > 
+> > > I'm port project-builder to my linux distro - Exherbo. Fedora build
+> > > success, but centos 5.6 with cmd line like:
+> > > 
+> > > rpmbootstrap  -v centos-5.6-x86_64 -a
+> > > acl,anacron,attr,audit,bc,diffutils,file,ftp,grub,groff,ipsec-tools,iptables,iptables-ipv6,kbd,
+> > > jwhois,kernel-xen,man,man-pages,mgetty,ntp,passwd,quota,screen,checkpolicy,libselinux-utils,
+> > > policycoreutils,selinux-policy-targeted,sysfsutils,sysklogd,system-config-securitylevel-tui,
+> > > time,unzip,vim-enhanced,which,wget,openssh-clients,openssh,openssh-server,libselinux-utils,
+> > > libselinux-python,at,setools,setuptool,rootfiles,setarch,yum-priorities,yum-downloadonly,yum-utils,exim /root/t
+> > > 
+> > > can't determine mirror... if i specify version 5, it tries to install
+> > > 5.5 that not in kernel.org mirror... can i specify url where rpm lives?
+> > > 
+> > > 
+> > 
+> > Hmm I'm specify mirror, but it not helps:
+> > rpmbootstrap  -v centos-5.6-x86_64  /root/t
+> > http://mirror.yandex.ru/centos/5.6/os/x86_64/CentOS
+> > 
+> > process stopped with:
+> > Debug value: 1
+> > Starting VE build for centos-5.6-x86_64
+> > Downloading package list from  ...
+> > 
+> > 
+> 
+> Ok. Error
+> is /usr/lib/perl5/vendor_perl/5.12.3/ProjectBuilder/Distribution.pm line
+> 52
+> 
+> sub pb_distro_conffile {
+> 
+> return("/usr/local/etc/pb/pb.conf");
+> }
+> 
+> This path is incorrect and must depends on prefix .. in my case this
+> config in /etc/pb.conf
+
+This is my error, invalid configure...
+
+> And please, upgrade centos version in it to 5.6 - 5.5 not in mirrors
+> now.
+> 
+
+This need your writing to ProjectBuilder config.
+
+-- 
+Vasiliy G Tolstov <v.tolstov at selfip.ru>
+Selfip.Ru
+
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005284.html b/zarb-ml/mageia-dev/2011-June/005284.html new file mode 100644 index 000000000..c678e7316 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005284.html @@ -0,0 +1,186 @@ + + + + [Mageia-dev] lib64gdata conflict + + + + + + + + + +

[Mageia-dev] lib64gdata conflict

+ Frank Griffin + ftg at roadrunner.com +
+ Thu Jun 9 15:40:11 CEST 2011 +

+
+ +
Installation failed:    file 
+/usr/lib64/girepository-1.0/GData-0.0.typelib from install of 
+lib64gdata10-0.7.1-1.mga2.x86_64 conflicts with file from package 
+lib64gdata7-0.6.6-1.mga1.x86_64
+     libgdata.so.10()(64bit) is needed by 
+evolution-data-server-3.0.2.1-1.mga2.x86_64
+     libgweather-3.so.0()(64bit) is needed by 
+evolution-data-server-3.0.2.1-1.mga2.x86_64
+     atk1.0-common >= 2.0.0-2.mga2 is needed by 
+libatk1.0_0-2.0.0-2.mga2.i586
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005285.html b/zarb-ml/mageia-dev/2011-June/005285.html new file mode 100644 index 000000000..cbe04a165 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005285.html @@ -0,0 +1,200 @@ + + + + [Mageia-dev] Mageia 2 specifications + + + + + + + + + +

[Mageia-dev] Mageia 2 specifications

+ Anne nicolas + ennael at mageia.org +
+ Thu Jun 9 15:57:15 CEST 2011 +

+
+ +
Hi all
+
+Following yesterday's meeting (See httpt please h://
+meetbot.mageia.org/mageia-dev/2011/mageia-dev.2011-06-08-19.04.html), we
+will start now listing what we could have in Mageia 2 technical
+specifications. As a result, please have a look in
+http://mageia.org/wiki/doku.php?id=iso2:technical_specification.
+
+Feel free to add proposals in any listed items (or add new one). Please add
+your name and explanations about it.
+
+Deadline for proposals is 22th of June. Of course we will have to discuss
+about proposed choice, reject some if not reasonable or plan some others on
+long term projects. This will also depend on decision regarding release
+cycle (discussion on that point will start tomorrow)
+
+Cheers
+
+-- 
+Anne
+http://www.mageia.org
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110609/b6632ee3/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005286.html b/zarb-ml/mageia-dev/2011-June/005286.html new file mode 100644 index 000000000..dfc8ae3e0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005286.html @@ -0,0 +1,187 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Thu Jun 9 18:42:12 CEST 2011 +

+
+ +
On 9 June 2011 14:22, Oliver Burger <oliver.bgr at googlemail.com> wrote:
+> Dexter Morgan <dmorganec at gmail.com> schrieb am 09.06.2011
+>
+>> On Thu, Jun 9, 2011 at 11:54 AM, Colin Guthrie <mageia at colin.guthr.ie>
+>> wrote:
+>
+>> > I think updates would be the right place.
+>
+>>
+>
+>> Please no 3rd repo :)
+>
+>> But i agree with you for updates for "new" packages ( no "new"
+>
+>> versions ;) )
+>
+>
+> I would prefer using updates over backports as well. If we use backports we
+> would get more problems then benefit (like people not having backports
+> enabled or people having backports enabled and thus getting problems they
+> can't handle e.g. with new kernels, graphic drivers and so on).
+>
+>
+> Perhaps we could upload them to updates/testing for a really short qa before
+> moving them to updates/ ?
+>
+>
+> Oliver
+
+If it's pushed to /updates then it should be imported to the stable
+release SVN tree; note that at some point Cauldron could get a newer
+version than the one in /updates, and maybe it's not backportable, new
+deps, regressions... etc. But now if there's a bug in the version in
+the stable */updates, and it needs a patch, what are you gonna base
+the patch on if you submit directly from the Cauldron SVN checkout to
+*/updates, and the Cauldron package has already changed?
+
+But if new package can go directly to updates.. that doesn't look
+right to me, because at which point will "new" packages stop going to
+a stable release */updates? if it goes on and on, then we're talking
+about a semi-cauldron-like repo.
+
+Also note that a new package in Cauldron gets tested for a while
+(depending at which point it was imported during the release cycle),
+but if gets pushed to /updates and not backports (which is "not
+supported"), that testing period is short-circuited.
+
+Just my 0.002€
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005287.html b/zarb-ml/mageia-dev/2011-June/005287.html new file mode 100644 index 000000000..e75a9b8df --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005287.html @@ -0,0 +1,183 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Thu Jun 9 18:43:28 CEST 2011 +

+
+ +
On 9 June 2011 14:17, Sander Lepik <sander.lepik at eesti.ee> wrote:
+> 09.06.2011 15:13, Dexter Morgan kirjutas:
+>>
+>> On Thu, Jun 9, 2011 at 11:54 AM, Colin Guthrie<mageia at colin.guthr.ie>
+>>  wrote:
+>>>
+>>> 'Twas brillig, and Christiaan Welvaart at 09/06/11 10:40 did gyre and
+>>> gimble:
+>>>>
+>>>> On Thu, 9 Jun 2011, Maarten Vanraes wrote:
+>>>>
+>>>>> otoh, perhaps a missing package is also a bugfix... maybe we could
+>>>>> file bug
+>>>>> reports for missing packages and go through the updates route...
+>>>>
+>>>> Filing bug reports is not a bad idea, even if the new package will go to
+>>>> backports. Just explain a little why it is important (to fix this in a
+>>>> stable release).
+>>>>
+>>>> We probably need a new "version" in bugzilla because mga1+backports is
+>>>> basically a new distro. A bug in backports shouldn't be filed against
+>>>> "1" IMHO.
+>>>
+>>> As I said in my original mail I really don't think backports is the
+>>> right approach.
+>>>
+>>> I'd prefer to have a 3rd party repo than abuse backports to get the
+>>> missing packages.
+>>>
+>>> I think updates would be the right place.
+>>
+>> Please no 3rd repo :)
+>> But i agree with you for updates for "new" packages ( no "new" versions ;)
+>> )
+>
+> Indeed it's not good idea to suggest backports for novice users. +1 for
+> updates repo if the new package is just new thing and nothing is going to
+> depend on it or will suggest it before new Mageia release.
+>
+> --
+> Sander
+>
+>
+
+I think some novice users want the latest version of foo yesterday, so
+they do enable backports anyway.
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005288.html b/zarb-ml/mageia-dev/2011-June/005288.html new file mode 100644 index 000000000..d2e137a02 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005288.html @@ -0,0 +1,187 @@ + + + + [Mageia-dev] [RFC] Removing .la files + + + + + + + + + +

[Mageia-dev] [RFC] Removing .la files

+ Dexter Morgan + dmorganec at gmail.com +
+ Thu Jun 9 19:35:22 CEST 2011 +

+
+ +
Hello,
+
+as other distributions we started to remove .la files from mageia
+during mageia 1 development.
+
+Unfortunatly we didn't had enough time to finish this.
+
+I restarted this task today.
+
+
+Please tell me if a build fails because of a missing la file.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005289.html b/zarb-ml/mageia-dev/2011-June/005289.html new file mode 100644 index 000000000..17a83ff94 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005289.html @@ -0,0 +1,250 @@ + + + + [Mageia-dev] glib commit problems + + + + + + + + + +

[Mageia-dev] glib commit problems

+ Zé + mmodem00 at gmail.com +
+ Thu Jun 9 20:48:07 CEST 2011 +

+
+ +
I have got glib from mandriva and did the necessary changes for
+mageia, since its a package needed by others, but when i tried to
+import it into mageia i got this error output:
+
+srpms]$ mgarepo submit glib
+Fetching revision...
+URL: svn+ssh://svn.mageia.org/svn/packages/cauldron/glib
+Commit: 102067 | ze | imported package glib
+Implicit target: cauldron
+error: command failed: ssh pkgsubmit.mageia.org
+/usr/local/bin/submit_package -t cauldron --define
+sid=005a19f9-7c5c-4db1-a847-43d2f1b7774b -r 102067
+svn+ssh://svn.mageia.org/svn/packages/cauldron/glib
+A    /var/lib/schedbot/repsys/tmp/tmpmT6I4j/SOURCES-bin
+error: Failed to upload svn+ssh://svn.mageia.org/svn/packages/cauldron/glib:
+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=ze --define
+sid=005a19f9-7c5c-4db1-a847-43d2f1b7774b cauldron
+/var/lib/schedbot/repsys/srpms/@102067:glib-1.2.10-25.mga2.src.rpm
+(sudo_user ze)
+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 glib of any version
+error: File /var/lib/schedbot/rpmbuild/SOURCES/glib-1.2.10-isowarning.patch:
+No such file or directory
+error: File /var/lib/schedbot/rpmbuild/SOURCES/glib-1.2.10-multilib.patch:
+No such file or directory
+error: File /var/lib/schedbot/rpmbuild/SOURCES/glib-1.2.10-gcc34.patch:
+No such file or directory
+error: File /var/lib/schedbot/rpmbuild/SOURCES/glib-1.2.10-underquoted.patch:
+No such file or directory
+error: File /var/lib/schedbot/rpmbuild/SOURCES/glib-1.2.10-libtool.patch:
+No such file or directory
+error: File /var/lib/schedbot/rpmbuild/SOURCES/glib-1.2.10-underlinking.patch:
+No such file or directory
+error: File /var/lib/schedbot/rpmbuild/SOURCES/glib-1.2.10-format_not_a_string_literal_and_no_format_arguments.diff:
+No such file or directory
+error: File /var/lib/schedbot/rpmbuild/SOURCES/glib_divert.patch: No
+such file or directory
+Deprecated method, use as_string now at
+/usr/lib/perl5/site_perl/5.10.1/Youri/Repository/Mageia.pm line 457
+Submission errors, aborting:
+- glib-1.2.10-25.mga2.src:
+ - ze is not authorized to upload packages belonging to glib in
+section core/release (authorized persons: ^blacklisted$)
+
+could anyone check this? or mail me that ill provide the glib src.rpm
+publicly so it can be imported into mageia.
+
+TIA,
+-- 
+Zé
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005290.html b/zarb-ml/mageia-dev/2011-June/005290.html new file mode 100644 index 000000000..b434e4f33 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005290.html @@ -0,0 +1,256 @@ + + + + [Mageia-dev] glib commit problems + + + + + + + + + +

[Mageia-dev] glib commit problems

+ Dexter Morgan + dmorganec at gmail.com +
+ Thu Jun 9 20:53:43 CEST 2011 +

+
+ +
On Thu, Jun 9, 2011 at 8:48 PM, Zé <mmodem00 at gmail.com> wrote:
+> I have got glib from mandriva and did the necessary changes for
+> mageia, since its a package needed by others, but when i tried to
+> import it into mageia i got this error output:
+>
+> srpms]$ mgarepo submit glib
+> Fetching revision...
+> URL: svn+ssh://svn.mageia.org/svn/packages/cauldron/glib
+> Commit: 102067 | ze | imported package glib
+> Implicit target: cauldron
+> error: command failed: ssh pkgsubmit.mageia.org
+> /usr/local/bin/submit_package -t cauldron --define
+> sid=005a19f9-7c5c-4db1-a847-43d2f1b7774b -r 102067
+> svn+ssh://svn.mageia.org/svn/packages/cauldron/glib
+> A    /var/lib/schedbot/repsys/tmp/tmpmT6I4j/SOURCES-bin
+> error: Failed to upload svn+ssh://svn.mageia.org/svn/packages/cauldron/glib:
+> 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=ze --define
+> sid=005a19f9-7c5c-4db1-a847-43d2f1b7774b cauldron
+> /var/lib/schedbot/repsys/srpms/@102067:glib-1.2.10-25.mga2.src.rpm
+> (sudo_user ze)
+> 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 glib of any version
+> error: File /var/lib/schedbot/rpmbuild/SOURCES/glib-1.2.10-isowarning.patch:
+> No such file or directory
+> error: File /var/lib/schedbot/rpmbuild/SOURCES/glib-1.2.10-multilib.patch:
+> No such file or directory
+> error: File /var/lib/schedbot/rpmbuild/SOURCES/glib-1.2.10-gcc34.patch:
+> No such file or directory
+> error: File /var/lib/schedbot/rpmbuild/SOURCES/glib-1.2.10-underquoted.patch:
+> No such file or directory
+> error: File /var/lib/schedbot/rpmbuild/SOURCES/glib-1.2.10-libtool.patch:
+> No such file or directory
+> error: File /var/lib/schedbot/rpmbuild/SOURCES/glib-1.2.10-underlinking.patch:
+> No such file or directory
+> error: File /var/lib/schedbot/rpmbuild/SOURCES/glib-1.2.10-format_not_a_string_literal_and_no_format_arguments.diff:
+> No such file or directory
+> error: File /var/lib/schedbot/rpmbuild/SOURCES/glib_divert.patch: No
+> such file or directory
+> Deprecated method, use as_string now at
+> /usr/lib/perl5/site_perl/5.10.1/Youri/Repository/Mageia.pm line 457
+> Submission errors, aborting:
+> - glib-1.2.10-25.mga2.src:
+>  - ze is not authorized to upload packages belonging to glib in
+> section core/release (authorized persons: ^blacklisted$)
+>
+> could anyone check this? or mail me that ill provide the glib src.rpm
+> publicly so it can be imported into mageia.
+>
+> TIA,
+> --
+> Zé
+>
+
+For what do you need glib ?
+
+glib is on the same list as gtk1 and Qt3, => Apps we want to get rid of.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005291.html b/zarb-ml/mageia-dev/2011-June/005291.html new file mode 100644 index 000000000..f25015384 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005291.html @@ -0,0 +1,268 @@ + + + + [Mageia-dev] glib commit problems + + + + + + + + + +

[Mageia-dev] glib commit problems

+ Zé + mmodem00 at gmail.com +
+ Thu Jun 9 21:01:43 CEST 2011 +

+
+ +
2011/6/9 Dexter Morgan <dmorganec at gmail.com>:
+> On Thu, Jun 9, 2011 at 8:48 PM, Zé <mmodem00 at gmail.com> wrote:
+>> I have got glib from mandriva and did the necessary changes for
+>> mageia, since its a package needed by others, but when i tried to
+>> import it into mageia i got this error output:
+>>
+>> srpms]$ mgarepo submit glib
+>> Fetching revision...
+>> URL: svn+ssh://svn.mageia.org/svn/packages/cauldron/glib
+>> Commit: 102067 | ze | imported package glib
+>> Implicit target: cauldron
+>> error: command failed: ssh pkgsubmit.mageia.org
+>> /usr/local/bin/submit_package -t cauldron --define
+>> sid=005a19f9-7c5c-4db1-a847-43d2f1b7774b -r 102067
+>> svn+ssh://svn.mageia.org/svn/packages/cauldron/glib
+>> A    /var/lib/schedbot/repsys/tmp/tmpmT6I4j/SOURCES-bin
+>> error: Failed to upload svn+ssh://svn.mageia.org/svn/packages/cauldron/glib:
+>> 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=ze --define
+>> sid=005a19f9-7c5c-4db1-a847-43d2f1b7774b cauldron
+>> /var/lib/schedbot/repsys/srpms/@102067:glib-1.2.10-25.mga2.src.rpm
+>> (sudo_user ze)
+>> 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 glib of any version
+>> error: File /var/lib/schedbot/rpmbuild/SOURCES/glib-1.2.10-isowarning.patch:
+>> No such file or directory
+>> error: File /var/lib/schedbot/rpmbuild/SOURCES/glib-1.2.10-multilib.patch:
+>> No such file or directory
+>> error: File /var/lib/schedbot/rpmbuild/SOURCES/glib-1.2.10-gcc34.patch:
+>> No such file or directory
+>> error: File /var/lib/schedbot/rpmbuild/SOURCES/glib-1.2.10-underquoted.patch:
+>> No such file or directory
+>> error: File /var/lib/schedbot/rpmbuild/SOURCES/glib-1.2.10-libtool.patch:
+>> No such file or directory
+>> error: File /var/lib/schedbot/rpmbuild/SOURCES/glib-1.2.10-underlinking.patch:
+>> No such file or directory
+>> error: File /var/lib/schedbot/rpmbuild/SOURCES/glib-1.2.10-format_not_a_string_literal_and_no_format_arguments.diff:
+>> No such file or directory
+>> error: File /var/lib/schedbot/rpmbuild/SOURCES/glib_divert.patch: No
+>> such file or directory
+>> Deprecated method, use as_string now at
+>> /usr/lib/perl5/site_perl/5.10.1/Youri/Repository/Mageia.pm line 457
+>> Submission errors, aborting:
+>> - glib-1.2.10-25.mga2.src:
+>>  - ze is not authorized to upload packages belonging to glib in
+>> section core/release (authorized persons: ^blacklisted$)
+>>
+>> could anyone check this? or mail me that ill provide the glib src.rpm
+>> publicly so it can be imported into mageia.
+>>
+>> TIA,
+>> --
+>> Zé
+>>
+>
+> For what do you need glib ?
+
+xmms needs ORbit, that needs glib, and AFAIK these are still
+maintained apps, and xmms is still a needed buildrequire needed by
+kdenetwork (its optional but still exists), so i dont understand the
+hurry to drop these applications.
+
+> glib is on the same list as gtk1 and Qt3, => Apps we want to get rid of.
+>
+
+
+
+-- 
+Zé
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005292.html b/zarb-ml/mageia-dev/2011-June/005292.html new file mode 100644 index 000000000..38b85bedf --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005292.html @@ -0,0 +1,201 @@ + + + + [Mageia-dev] glib commit problems + + + + + + + + + +

[Mageia-dev] glib commit problems

+ Dexter Morgan + dmorganec at gmail.com +
+ Thu Jun 9 21:10:53 CEST 2011 +

+
+ +
On Thu, Jun 9, 2011 at 9:01 PM, Zé <mmodem00 at gmail.com> wrote:
+
+> xmms needs ORbit, that needs glib, and AFAIK these are still
+> maintained apps, and xmms is still a needed buildrequire needed by
+> kdenetwork (its optional but still exists), so i dont understand the
+> hurry to drop these applications.
+
+You don't want to add xmms as a dep of kdenetwork4 w/o asking to mikala.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005293.html b/zarb-ml/mageia-dev/2011-June/005293.html new file mode 100644 index 000000000..b6418111e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005293.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Samuel Verschelde + stormi at laposte.net +
+ Thu Jun 9 21:30:04 CEST 2011 +

+
+ +
Le jeudi 9 juin 2011 11:05:16, Colin Guthrie a écrit :
+> 'Twas brillig, and Ahmad Samir at 08/06/11 22:48 did gyre and gimble:
+> > On 8 June 2011 23:38, Stew Benedict <stewbintn at gmail.com> wrote: 
+> >> If you're going to rebuild *after* QA, you've just invalidated your QA.
+> >> (yeah, I know it *should* be the same, but stuff happens)
+> > 
+> > You're right (even if that's never happened for 3-4 years in mdv,
+> > since sec team rebuilt the packages when pushing to */updates IIRC).
+> 
+> Personally, and this might just be me, I always submit my packages to
+> *testing with a subrel of 0.1, 0.2 0.3 etc etc. Users then test my
+> various iterations. When I'm happy and when it's ready to pass to QA, I
+> set the subrel to 1. This way the final version that should hit updates
+> is nice and neat.
+> 
+> In an ideal world, QA would validate it for me then change the subrel
+> for me. That process would require a rebuild.
+> 
+> I'm not sure what others feel about this? It's not impossible to just do
+> this as a matter of course as part of the process we go through and
+> increment subrel to a round number before handing over to QA... although
+> maybe I'm just a bit too anal about neat version numbers :p
+> 
+
+Neat version numbers are great, so I like your way of doing updates :)
+
+Samuel
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110609/28b8e024/attachment-0001.html>
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005294.html b/zarb-ml/mageia-dev/2011-June/005294.html new file mode 100644 index 000000000..788f13c43 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005294.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Samuel Verschelde + stormi at laposte.net +
+ Thu Jun 9 21:32:20 CEST 2011 +

+
+ +
Le jeudi 9 juin 2011 07:00:24, Anssi Hannula a écrit :
+> On 09.06.2011 02:25, Michael Scherer wrote:
+> > I guess we can start with a list of exception :
+> > 
+> > - stuff that should be updated to latest version, because the security
+> > support for older releases ( firefox, chrome ) is too hard
+> > -> we update to latest version if there is no regression and a strong
+> > reason to upgrade ( severe bugfixes, security issue, breakages ).
+> > Exception of this category should be very expectional
+> > 
+> > - stuff where there is strict bugfixes only release
+> > ( postgresql ), or update to a stable version ( which should be a bugfix
+> > only release when compared to beta/rc :) )
+> > -> we upgrade to stable ( for rc/beta )
+> > -> we do version update if it is bug fixes and if the packager is ok
+> > with it ( and if the rules of the bugfix branches are clearly documented
+> > )
+> > 
+> > - everything else
+> > -> only minimal patches
+> > 
+> > The question of game is still open, ie, should it go in 1st category, or
+> > should we have different rules to see what should be there or not ?
+> > 
+> > I guess this would only be for networked game ?
+> 
+> Yes. Note that this applies to some other software that communicates
+> with outside systems as well, e.g. subdownloader. Maybe also Vuze if the
+> content delivery system requires a version update.
+> 
+> Maybe the correct phrasing would be something like:
+> - Packages where some functions no longer work due to remote server
+>   changes, requiring a newer version of the package.
+
+Agreed.
+
+Samuel
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110609/bb4de47b/attachment.html>
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005295.html b/zarb-ml/mageia-dev/2011-June/005295.html new file mode 100644 index 000000000..288f9e15b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005295.html @@ -0,0 +1,217 @@ + + + + [Mageia-dev] glib commit problems + + + + + + + + + +

[Mageia-dev] glib commit problems

+ Zé + mmodem00 at gmail.com +
+ Thu Jun 9 21:31:51 CEST 2011 +

+
+ +
2011/6/9 Dexter Morgan <dmorganec at gmail.com>:
+> On Thu, Jun 9, 2011 at 9:01 PM, Zé <mmodem00 at gmail.com> wrote:
+>
+>> xmms needs ORbit, that needs glib, and AFAIK these are still
+>> maintained apps, and xmms is still a needed buildrequire needed by
+>> kdenetwork (its optional but still exists), so i dont understand the
+>> hurry to drop these applications.
+>
+> You don't want to add xmms as a dep of kdenetwork4 w/o asking to mikala.
+I havent added anything, and thats not the main problem, and the
+buildrequire i add to kdegraphics i did first talked with mikala. I
+saw you have removed it again saying it was a bad require, thats not
+correct, kgamma needs xf86vm (i know its a dev package thats called by
+other apps, thats why i didnt refered anything when you removed it
+from kdegraphics.
+
+Regarding xmms, glib and ORbit are apps that should be provided to the user.
+The user may still want to build kdenetwork with xmms and currently
+mageia isnt providing it.
+To remember that exist other apps that need ORbit and glib (and these
+are apps that continue being developed) and mageia isnt providing
+them.
+
+-- 
+Zé
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005296.html b/zarb-ml/mageia-dev/2011-June/005296.html new file mode 100644 index 000000000..81872ffdd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005296.html @@ -0,0 +1,196 @@ + + + + [Mageia-dev] Switching from Cooker to Cauldron? + + + + + + + + + +

[Mageia-dev] Switching from Cooker to Cauldron?

+ Dick Gevers + dvgevers at xs4all.nl +
+ Thu Jun 9 21:35:23 CEST 2011 +

+
+ +
On Thu, 9 Jun 2011 13:44:25 +0200, Olav Vitters wrote about [Mageia-dev]
+Switching from Cooker to Cauldron?:
+
+>Hello,
+>
+>Now that GNOME3 is being imported to Cauldron, I'd like to switch my
+>Mandriva Cooker installation to Cauldron.
+>
+>However, Cooker has a different rpm for a while and I have that
+>installed.
+>
+>I'm guessing if I attempt to switch to Cauldron, it likely cannot read
+>the rpm5 database.
+>
+>I can only think of a few things:
+
+My experience: not bad, but takes a little effort: tarred everything on the
+machine and newly installed Mageia official, upgraded to cauldron and
+untarred local machine settings I require. For example shorewall, aliases,
+urpmi's skiplist, rkhunter.conf, logrotate specific settings, /usr/local
+and anything else privately configured. Merely kept my home and formatted
+everything else. I got into the hang of this when half a year ago I upgraded
+32 to 64 bits. 
+
+HTH
+mvg
+=Dick Gevers=
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005297.html b/zarb-ml/mageia-dev/2011-June/005297.html new file mode 100644 index 000000000..834f36db6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005297.html @@ -0,0 +1,186 @@ + + + + [Mageia-dev] Supybot rpms rebuilt on mageia + + + + + + + + + +

[Mageia-dev] Supybot rpms rebuilt on mageia

+ Lee + lee8oi at gmail.com +
+ Thu Jun 9 21:40:38 CEST 2011 +

+
+ +
I was asked to look into supybot and meetbot to work on patches an 
+fixes. First things first I had to rebuild rpms for my mageia 1 system 
+(i586). I built the following from src rpms:
+
+supybot-0.83.4.1-1.mga1.noarch.rpm
+supybot-Dcc-0.83.4.1-1.mga1.noarch.rpm
+supybot-ExternalNotice-0.83.4.1-1.mga1.noarch.rpm
+supybot-Gateway-0.83.4.1-1.mga1.noarch.rpm
+supybot-Meetbot-0.1.4-2.mga1.noarch.rpm
+supybot-Sshd-0.83.4.1-1.mga1.noarch.rpm
+supybot-Webserver-0.83.4.1-1.mga1.noarch.rpm
+
+I don't have a mentor, I'm not a packager, and nobody so far has ported 
+these packages over. And the ones I have here haven't been officially 
+'cleansed' but they work. Not sure how to move forward from here.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005298.html b/zarb-ml/mageia-dev/2011-June/005298.html new file mode 100644 index 000000000..037e689e5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005298.html @@ -0,0 +1,208 @@ + + + + [Mageia-dev] glib commit problems + + + + + + + + + +

[Mageia-dev] glib commit problems

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Thu Jun 9 21:39:46 CEST 2011 +

+
+ +
On Thu, 9 Jun 2011, Zé wrote:
+
+> 2011/6/9 Dexter Morgan <dmorganec at gmail.com>:
+>> For what do you need glib ?
+>
+> xmms needs ORbit, that needs glib, and AFAIK these are still
+> maintained apps, and xmms is still a needed buildrequire needed by
+> kdenetwork (its optional but still exists), so i dont understand the
+> hurry to drop these applications.
+
+But what feature does it provide for kdenetwork? You can use e.g. 
+audacious (gtk2 version) instead of xmms itself. I don't know how 
+compatible audacious is, though.
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005299.html b/zarb-ml/mageia-dev/2011-June/005299.html new file mode 100644 index 000000000..4ca318425 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005299.html @@ -0,0 +1,216 @@ + + + + [Mageia-dev] Mageia 1 post-mortem + + + + + + + + + +

[Mageia-dev] Mageia 1 post-mortem

+ Anne nicolas + ennael at mageia.org +
+ Thu Jun 9 21:50:56 CEST 2011 +

+
+ +
Hi there
+
+More homework :). Following Mageia 1 final release, we would like to
+summarize what went wrong or right during development. This will help us to
+formalize things and improve all process.
+
+Please add your comments here with all needed explanations if you have
+contributed to i18n, packaging, testing...
+http://mageia.org/wiki/doku.php?id=iso1:mageia1_postmortem
+
+Cheers
+
+-- 
+Anne
+http://www.mageia.org
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110609/e5a49f78/attachment-0001.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005300.html b/zarb-ml/mageia-dev/2011-June/005300.html new file mode 100644 index 000000000..0e4eac8a1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005300.html @@ -0,0 +1,224 @@ + + + + [Mageia-dev] glib commit problems + + + + + + + + + +

[Mageia-dev] glib commit problems

+ Zé + mmodem00 at gmail.com +
+ Thu Jun 9 22:06:34 CEST 2011 +

+
+ +
2011/6/9 Christiaan Welvaart <cjw at daneel.dyndns.org>:
+> On Thu, 9 Jun 2011, Zé wrote:
+>
+>> 2011/6/9 Dexter Morgan <dmorganec at gmail.com>:
+>>>
+>>> For what do you need glib ?
+>>
+>> xmms needs ORbit, that needs glib, and AFAIK these are still
+>> maintained apps, and xmms is still a needed buildrequire needed by
+>> kdenetwork (its optional but still exists), so i dont understand the
+>> hurry to drop these applications.
+>
+> But what feature does it provide for kdenetwork? You can use e.g. audacious
+> (gtk2 version) instead of xmms itself. I don't know how compatible audacious
+> is, though.
+>
+>
+>    Christiaan
+>
+
+kopete/CMakeLists.txt:macro_log_feature(XMMS_FOUND "XMMS" "X
+MultiMedia System development libraries" "http://www.xmms.org" FALSE
+"" "Used by the Kopete nowlistening plugin to support the XMMS
+player.")
+
+But this isnt the main issue, these packages should be provided by
+mageia (they are provided by the main linux distros), if the packages
+were no longer maintained than i would agree that wouldnt be needed to
+put them available in mageia, but thats not the case.
+
+
+-- 
+Zé
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005301.html b/zarb-ml/mageia-dev/2011-June/005301.html new file mode 100644 index 000000000..5d894e9a4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005301.html @@ -0,0 +1,242 @@ + + + + [Mageia-dev] glib commit problems + + + + + + + + + +

[Mageia-dev] glib commit problems

+ Dexter Morgan + dmorganec at gmail.com +
+ Thu Jun 9 22:44:18 CEST 2011 +

+
+ +
On Thu, Jun 9, 2011 at 10:06 PM, Zé <mmodem00 at gmail.com> wrote:
+> 2011/6/9 Christiaan Welvaart <cjw at daneel.dyndns.org>:
+>> On Thu, 9 Jun 2011, Zé wrote:
+>>
+>>> 2011/6/9 Dexter Morgan <dmorganec at gmail.com>:
+>>>>
+>>>> For what do you need glib ?
+>>>
+>>> xmms needs ORbit, that needs glib, and AFAIK these are still
+>>> maintained apps, and xmms is still a needed buildrequire needed by
+>>> kdenetwork (its optional but still exists), so i dont understand the
+>>> hurry to drop these applications.
+>>
+>> But what feature does it provide for kdenetwork? You can use e.g. audacious
+>> (gtk2 version) instead of xmms itself. I don't know how compatible audacious
+>> is, though.
+>>
+>>
+>>    Christiaan
+>>
+>
+> kopete/CMakeLists.txt:macro_log_feature(XMMS_FOUND "XMMS" "X
+> MultiMedia System development libraries" "http://www.xmms.org" FALSE
+> "" "Used by the Kopete nowlistening plugin to support the XMMS
+> player.")
+>
+> But this isnt the main issue, these packages should be provided by
+> mageia (they are provided by the main linux distros), if the packages
+> were no longer maintained than i would agree that wouldnt be needed to
+> put them available in mageia, but thats not the case.
+>
+>
+> --
+> Zé
+>
+
+"provided by" is != from "maintained".
+
+if you look on fedora :
+
+xmms-1.2.11-12.20071117cvs.fc15.src.rpm
+
+since 2007 this is only rebuilded and fixed for the build but we can't
+call this "maintained" upstream.
+
+
+Gentoo have removed xmms
+Ubuntu have removed xmms too
+
+So please stop FUDing to "force" to push the packages you want.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005302.html b/zarb-ml/mageia-dev/2011-June/005302.html new file mode 100644 index 000000000..d1d397ee6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005302.html @@ -0,0 +1,203 @@ + + + + [Mageia-dev] P.S. (supybot packages) + + + + + + + + + +

[Mageia-dev] P.S. (supybot packages)

+ Lee + lee8oi at gmail.com +
+ Thu Jun 9 22:46:50 CEST 2011 +

+
+ +
I have uploaded the src rpms to my webhosting for whoever necessary that 
+needs to review them the address is 
+http://dukelovett.org/mageia/rpms/supybot/noarch/ Please do let me know 
+if I got this right, and if so maybe someone would consider being my 
+mentor? I've been working with linux for about 10 years mostly as an 
+administrator/user/webdeveloper/irc scriptor/etc but never really did 
+any packaging. But since I'm fixin to try and solve some of these 
+supybot problems. I have a feeling I'll be throwing more of these 
+packages together in the future. Always good to take on new challenges eh?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005303.html b/zarb-ml/mageia-dev/2011-June/005303.html new file mode 100644 index 000000000..0dd851101 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005303.html @@ -0,0 +1,258 @@ + + + + [Mageia-dev] glib commit problems + + + + + + + + + +

[Mageia-dev] glib commit problems

+ Anne nicolas + ennael at mageia.org +
+ Thu Jun 9 22:50:56 CEST 2011 +

+
+ +
2011/6/9 Dexter Morgan <dmorganec at gmail.com>
+
+> On Thu, Jun 9, 2011 at 10:06 PM, Zé <mmodem00 at gmail.com> wrote:
+> > 2011/6/9 Christiaan Welvaart <cjw at daneel.dyndns.org>:
+> >> On Thu, 9 Jun 2011, Zé wrote:
+> >>
+> >>> 2011/6/9 Dexter Morgan <dmorganec at gmail.com>:
+> >>>>
+> >>>> For what do you need glib ?
+> >>>
+> >>> xmms needs ORbit, that needs glib, and AFAIK these are still
+> >>> maintained apps, and xmms is still a needed buildrequire needed by
+> >>> kdenetwork (its optional but still exists), so i dont understand the
+> >>> hurry to drop these applications.
+> >>
+> >> But what feature does it provide for kdenetwork? You can use e.g.
+> audacious
+> >> (gtk2 version) instead of xmms itself. I don't know how compatible
+> audacious
+> >> is, though.
+> >>
+> >>
+> >>    Christiaan
+> >>
+> >
+> > kopete/CMakeLists.txt:macro_log_feature(XMMS_FOUND "XMMS" "X
+> > MultiMedia System development libraries" "http://www.xmms.org" FALSE
+> > "" "Used by the Kopete nowlistening plugin to support the XMMS
+> > player.")
+> >
+> > But this isnt the main issue, these packages should be provided by
+> > mageia (they are provided by the main linux distros), if the packages
+> > were no longer maintained than i would agree that wouldnt be needed to
+> > put them available in mageia, but thats not the case.
+> >
+> >
+> > --
+> > Zé
+> >
+>
+> "provided by" is != from "maintained".
+>
+> if you look on fedora :
+>
+> xmms-1.2.11-12.20071117cvs.fc15.src.rpm
+>
+> since 2007 this is only rebuilded and fixed for the build but we can't
+> call this "maintained" upstream.
+>
+>
+> Gentoo have removed xmms
+> Ubuntu have removed xmms too
+>
+> So please stop FUDing to "force" to push the packages you want.
+>
+
+btw please have a look here
+http://wiki.debian.org/ReleaseGoals/RemoveOldLibs
+
+It's not only Mageia's fact
+
+-- 
+Anne
+http://www.mageia.org
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110609/940c03e2/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005304.html b/zarb-ml/mageia-dev/2011-June/005304.html new file mode 100644 index 000000000..ea2686444 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005304.html @@ -0,0 +1,265 @@ + + + + [Mageia-dev] glib commit problems + + + + + + + + + +

[Mageia-dev] glib commit problems

+ Zé + mmodem00 at gmail.com +
+ Thu Jun 9 22:58:56 CEST 2011 +

+
+ +
2011/6/9 Anne nicolas <ennael at mageia.org>:
+>
+>
+> 2011/6/9 Dexter Morgan <dmorganec at gmail.com>
+>>
+>> On Thu, Jun 9, 2011 at 10:06 PM, Zé <mmodem00 at gmail.com> wrote:
+>> > 2011/6/9 Christiaan Welvaart <cjw at daneel.dyndns.org>:
+>> >> On Thu, 9 Jun 2011, Zé wrote:
+>> >>
+>> >>> 2011/6/9 Dexter Morgan <dmorganec at gmail.com>:
+>> >>>>
+>> >>>> For what do you need glib ?
+>> >>>
+>> >>> xmms needs ORbit, that needs glib, and AFAIK these are still
+>> >>> maintained apps, and xmms is still a needed buildrequire needed by
+>> >>> kdenetwork (its optional but still exists), so i dont understand the
+>> >>> hurry to drop these applications.
+>> >>
+>> >> But what feature does it provide for kdenetwork? You can use e.g.
+>> >> audacious
+>> >> (gtk2 version) instead of xmms itself. I don't know how compatible
+>> >> audacious
+>> >> is, though.
+>> >>
+>> >>
+>> >>    Christiaan
+>> >>
+>> >
+>> > kopete/CMakeLists.txt:macro_log_feature(XMMS_FOUND "XMMS" "X
+>> > MultiMedia System development libraries" "http://www.xmms.org" FALSE
+>> > "" "Used by the Kopete nowlistening plugin to support the XMMS
+>> > player.")
+>> >
+>> > But this isnt the main issue, these packages should be provided by
+>> > mageia (they are provided by the main linux distros), if the packages
+>> > were no longer maintained than i would agree that wouldnt be needed to
+>> > put them available in mageia, but thats not the case.
+>> >
+>> >
+>> > --
+>> > Zé
+>> >
+>>
+>> "provided by" is != from "maintained".
+>>
+>> if you look on fedora :
+>>
+>> xmms-1.2.11-12.20071117cvs.fc15.src.rpm
+>>
+>> since 2007 this is only rebuilded and fixed for the build but we can't
+>> call this "maintained" upstream.
+>>
+>>
+>> Gentoo have removed xmms
+>> Ubuntu have removed xmms too
+>>
+>> So please stop FUDing to "force" to push the packages you want.
+>
+> btw please have a look here
+> http://wiki.debian.org/ReleaseGoals/RemoveOldLibs
+> It's not only Mageia's fact
+
+Yes i agree but i dont think should be for now but in a near future,
+e.g. ORbit its currently maintained apps that depend on glib.
+
+> --
+> Anne
+> http://www.mageia.org
+>
+
+
+
+-- 
+Zé
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005305.html b/zarb-ml/mageia-dev/2011-June/005305.html new file mode 100644 index 000000000..d83262bbd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005305.html @@ -0,0 +1,208 @@ + + + + [Mageia-dev] glib commit problems + + + + + + + + + +

[Mageia-dev] glib commit problems

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Thu Jun 9 23:01:54 CEST 2011 +

+
+ +
Zé <mmodem00 at gmail.com> schrieb am 09.06.2011
+> 2011/6/9 Anne nicolas <ennael at mageia.org>:
+> > btw please have a look here
+> > http://wiki.debian.org/ReleaseGoals/RemoveOldLibs
+> > It's not only Mageia's fact
+> 
+> Yes i agree but i dont think should be for now but in a near
+> future, e.g. ORbit its currently maintained apps that depend on
+> glib.
+Now is the big chance to do such things since we are starting new. It 
+will be much harder to remove things later than not to add them at 
+all.
+
+Oliver
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110609/ab92fc2f/attachment-0001.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005306.html b/zarb-ml/mageia-dev/2011-June/005306.html new file mode 100644 index 000000000..62b85744d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005306.html @@ -0,0 +1,248 @@ + + + + [Mageia-dev] glib commit problems + + + + + + + + + +

[Mageia-dev] glib commit problems

+ Zé + mmodem00 at gmail.com +
+ Thu Jun 9 23:02:41 CEST 2011 +

+
+ +
2011/6/9 Dexter Morgan <dmorganec at gmail.com>:
+> On Thu, Jun 9, 2011 at 10:06 PM, Zé <mmodem00 at gmail.com> wrote:
+>> 2011/6/9 Christiaan Welvaart <cjw at daneel.dyndns.org>:
+>>> On Thu, 9 Jun 2011, Zé wrote:
+>>>
+>>>> 2011/6/9 Dexter Morgan <dmorganec at gmail.com>:
+>>>>>
+>>>>> For what do you need glib ?
+>>>>
+>>>> xmms needs ORbit, that needs glib, and AFAIK these are still
+>>>> maintained apps, and xmms is still a needed buildrequire needed by
+>>>> kdenetwork (its optional but still exists), so i dont understand the
+>>>> hurry to drop these applications.
+>>>
+>>> But what feature does it provide for kdenetwork? You can use e.g. audacious
+>>> (gtk2 version) instead of xmms itself. I don't know how compatible audacious
+>>> is, though.
+>>>
+>>>
+>>>    Christiaan
+>>>
+>>
+>> kopete/CMakeLists.txt:macro_log_feature(XMMS_FOUND "XMMS" "X
+>> MultiMedia System development libraries" "http://www.xmms.org" FALSE
+>> "" "Used by the Kopete nowlistening plugin to support the XMMS
+>> player.")
+>>
+>> But this isnt the main issue, these packages should be provided by
+>> mageia (they are provided by the main linux distros), if the packages
+>> were no longer maintained than i would agree that wouldnt be needed to
+>> put them available in mageia, but thats not the case.
+>>
+>>
+>> --
+>> Zé
+>>
+>
+> "provided by" is != from "maintained".
+>
+> if you look on fedora :
+>
+> xmms-1.2.11-12.20071117cvs.fc15.src.rpm
+>
+> since 2007 this is only rebuilded and fixed for the build but we can't
+> call this "maintained" upstream.
+>
+>
+> Gentoo have removed xmms
+> Ubuntu have removed xmms too
+>
+> So please stop FUDing to "force" to push the packages you want.
+>
+
+These are not packages i want, since i have them in my mahcines.
+And i dont come here with any attitude and bashing no one, so please behave.
+
+-- 
+Zé
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005307.html b/zarb-ml/mageia-dev/2011-June/005307.html new file mode 100644 index 000000000..ed94bf9cb --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005307.html @@ -0,0 +1,205 @@ + + + + [Mageia-dev] glib commit problems + + + + + + + + + +

[Mageia-dev] glib commit problems

+ Olav Vitters + olav at vitters.nl +
+ Thu Jun 9 23:04:29 CEST 2011 +

+
+ +
On Thu, Jun 09, 2011 at 08:31:51PM +0100, Zé wrote:
+> To remember that exist other apps that need ORbit and glib (and these
+> are apps that continue being developed) and mageia isnt providing
+> them.
+
+Some stuff is just obsolete. glib1 and ORbit are not maintained at all.
+The last release was in 2002. If you'd file a bug against it it'll be
+marked as obsolete.
+
+IMO, better to focus on making a good distro. If stuff is packaged,
+people should be able to trust they can file bugs and they get fixed.
+That is not the case with glib1, ORbit and anything that relies on
+these.
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005308.html b/zarb-ml/mageia-dev/2011-June/005308.html new file mode 100644 index 000000000..191b81d06 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005308.html @@ -0,0 +1,217 @@ + + + + [Mageia-dev] glib commit problems + + + + + + + + + +

[Mageia-dev] glib commit problems

+ Zé + mmodem00 at gmail.com +
+ Thu Jun 9 23:13:29 CEST 2011 +

+
+ +
2011/6/9 Olav Vitters <olav at vitters.nl>:
+> On Thu, Jun 09, 2011 at 08:31:51PM +0100, Zé wrote:
+>> To remember that exist other apps that need ORbit and glib (and these
+>> are apps that continue being developed) and mageia isnt providing
+>> them.
+>
+> Some stuff is just obsolete. glib1 and ORbit are not maintained at all.
+> The last release was in 2002. If you'd file a bug against it it'll be
+> marked as obsolete.
+
+Yes, its correct, ORbit lasat entry dates from 2002...
+I was almost sure that ORbit was still maintained, but im obvious
+wrong, so its better to drop these packages, but my doubt came
+specially from kdenetwork that still requires xmms for kopete, (a
+kopete xmms plugin).
+
+> IMO, better to focus on making a good distro. If stuff is packaged,
+> people should be able to trust they can file bugs and they get fixed.
+> That is not the case with glib1, ORbit and anything that relies on
+> these.
+> --
+> Regards,
+> Olav
+>
+
+
+
+-- 
+Zé
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005309.html b/zarb-ml/mageia-dev/2011-June/005309.html new file mode 100644 index 000000000..8c761e480 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005309.html @@ -0,0 +1,216 @@ + + + + [Mageia-dev] Mageia 2 - Improving educational programs + + + + + + + + + +

[Mageia-dev] Mageia 2 - Improving educational programs

+ Angelo Naselli + anaselli at linux.it +
+ Thu Jun 9 23:28:45 CEST 2011 +

+
+ +
Hi
+i'd like to add an item to mageia 2 specification, e.g.
+improving the educational part. (Already added into wiki)
+
+The main reason I moved the discussion here is that i'd like to
+see if other people are interested in this aim and would like to
+help.
+
+I see three main points but feel free to add yours,
+- add missing educational programs
+- group educational programs in specialized meta-packages (such as math, 
+  chemical, primary school, etc)
+- build one (or more) live cd -or improve draklive specs to make it 
+  buildable- to give to schools. 
+
+WDYT?
+
+-- 
+	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/20110609/45bc88f8/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005310.html b/zarb-ml/mageia-dev/2011-June/005310.html new file mode 100644 index 000000000..142ca9550 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005310.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ andre999 + andr55 at laposte.net +
+ Fri Jun 10 01:10:19 CEST 2011 +

+
+ +
Samuel Verschelde a écrit :
+> Le jeudi 9 juin 2011 11:05:16, Colin Guthrie a écrit :
+>  > 'Twas brillig, and Ahmad Samir at 08/06/11 22:48 did gyre and gimble:
+>  > > On 8 June 2011 23:38, Stew Benedict <stewbintn at gmail.com> wrote:
+>  > >> If you're going to rebuild *after* QA, you've just invalidated your QA.
+>  > >> (yeah, I know it *should* be the same, but stuff happens)
+>  > >
+>  > > You're right (even if that's never happened for 3-4 years in mdv,
+>  > > since sec team rebuilt the packages when pushing to */updates IIRC).
+>  >
+>  > Personally, and this might just be me, I always submit my packages to
+>  > *testing with a subrel of 0.1, 0.2 0.3 etc etc. Users then test my
+>  > various iterations. When I'm happy and when it's ready to pass to QA, I
+>  > set the subrel to 1. This way the final version that should hit updates
+>  > is nice and neat.
+>  >
+>  > In an ideal world, QA would validate it for me then change the subrel
+>  > for me. That process would require a rebuild.
+>  >
+>  > I'm not sure what others feel about this? It's not impossible to just do
+>  > this as a matter of course as part of the process we go through and
+>  > increment subrel to a round number before handing over to QA... although
+>  > maybe I'm just a bit too anal about neat version numbers :p
+>
+>
+> Neat version numbers are great, so I like your way of doing updates :)
+>
+> Samuel
+
+I like this approach too.  Very nice :)
+Especially the idea of incrementing subrel to a round number before handing to QA.
+And if QA finds a problem, we could revert to the decimal increment sequence until fixed, before 
+incrementing to a round number for QA again.
+(The same round number, or would it be better to use the next ?)
+
+-- 
+André
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005311.html b/zarb-ml/mageia-dev/2011-June/005311.html new file mode 100644 index 000000000..ab46ec1a4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005311.html @@ -0,0 +1,212 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Barry Jackson + zen25000 at zen.co.uk +
+ Fri Jun 10 01:56:12 CEST 2011 +

+
+ +
I have been working on a package to install Skype current stable release 
+and now feel that it is ready for submission for approval.
+
+It has already been improved/corrected/adapted many times following 
+discussions on #mageia-mentoring where I have been given lots of help.
+
+The idea evolved here https://bugs.mageia.org/show_bug.cgi?id=154
+where the current version is available as an attachment.
+https://bugs.mageia.org/attachment.cgi?id=551
+
+It has been a challenge and I have learned a lot in working on this. :)
+
+Barry
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005312.html b/zarb-ml/mageia-dev/2011-June/005312.html new file mode 100644 index 000000000..c176fac8a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005312.html @@ -0,0 +1,226 @@ + + + + [Mageia-dev] [RFC] Removing .la files + + + + + + + + + +

[Mageia-dev] [RFC] Removing .la files

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Fri Jun 10 02:47:08 CEST 2011 +

+
+ +
On 9 June 2011 19:35, Dexter Morgan <dmorganec at gmail.com> wrote:
+> Hello,
+>
+> as other distributions we started to remove .la files from mageia
+> during mageia 1 development.
+>
+> Unfortunatly we didn't had enough time to finish this.
+>
+> I restarted this task today.
+>
+>
+> Please tell me if a build fails because of a missing la file.
+>
+
+>From building pidgin-libnotify locally:
+libtool: link: cannot find the library `/usr/lib64/libatk-1.0.la' or
+unhandled argument `/usr/lib64/libatk-1.0.la'
+
+>From the chroot:
+$ cd usr/lib64/
+$ grep libatk-1.0.la *
+libindicate-gtk.la:dependency_libs=' /usr/lib64/libindicate.la
+/usr/lib64/libgtk-x11-2.0.la /usr/lib64/libgdk-x11-2.0.la
+/usr/lib64/libatk-1.0.la /usr/lib64/libpangocairo-1.0.la
+/usr/lib64/libpangoft2-1.0.la /usr/lib64/libgdk_pixbuf-2.0.la
+/usr/lib64/libcairo.la /usr/lib64/libpixman-1.la
+/usr/lib64/libXrender.la /usr/lib64/libX11.la /usr/lib64/libxcb.la
+/usr/lib64/libXau.la /usr/lib64/libXdmcp.la -lpng12
+/usr/lib64/libpango-1.0.la /usr/lib64/libfontconfig.la
+/usr/lib64/libfreetype.la /usr/lib64/libxml2.la -lm
+/usr/lib64/libdbusmenu-glib.la /usr/lib64/libgio-2.0.la -lresolv -lz
+/usr/lib64/libgmodule-2.0.la -ldl -ldbus-glib-1 -ldbus-1
+/usr/lib64/libgobject-2.0.la /usr/lib64/libgthread-2.0.la -lpthread
+/usr/lib64/libglib-2.0.la /usr/lib64/libpcre.la -lrt'
+
+
+I don't think just building packages and removing the .la will work,
+the inter-dependency is too wide, I count too many .la files up there.
+
+Reading these:
+http://wiki.debian.org/ReleaseGoals/LAFileRemoval
+http://lists.debian.org/debian-devel/2009/08/msg00783.html
+
+it looks like Debian are using sed to remove the .la files from
+dependency_libs field in .la files, there's a debhelper script, IIUC
+it's run before they build a package.
+
+This means it's something that a script run as root in the chroot can
+do, but I guess it needs to be fine-tuned.
+
+Meanwhile, just removing .la files will break a lot of builds (note
+that we have a lot of packages to rebuild for e.g. new libnotify major
+in Cauldron)... :(
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005313.html b/zarb-ml/mageia-dev/2011-June/005313.html new file mode 100644 index 000000000..686fee61f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005313.html @@ -0,0 +1,258 @@ + + + + [Mageia-dev] [RPM] cauldron core/release gecko-mediaplayer-1.0.3-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release gecko-mediaplayer-1.0.3-1.mga2

+ Dick Gevers + dvgevers at xs4all.nl +
+ Fri Jun 10 03:33:57 CEST 2011 +

+
+ +
On Fri, 10 Jun 2011 01:03:12 +0200 (CEST), Mageia Team wrote about [RPM]
+cauldron core/release gecko-mediaplayer-1.0.3-1.mga2:
+
+>Name        : gecko-mediaplayer            Relocations: (not relocatable)
+>Version     : 1.0.3                             Vendor: Mageia.Org
+>Release     : 1.mga2                        Build Date: Fri Jun 10
+>01:01:15 2011 Install Date: (not installed)               Build Host:
+>jonund Group       : Networking/WWW                Source RPM: (none)
+>Size        : 276237                           License: GPLv2+
+>Signature   : (none)
+>Packager    : Mageia Team <http://www.mageia.org>
+>URL         : http://kdekorte.googlepages.com/gecko-mediaplayer
+>Summary     : GNOME MPlayer browser plugin
+>Description :
+>Gecko Media Player is a browser plugin that uses GNOME MPlayer to
+>play media in a browser. It should work with all browsers on
+>Unix-ish systems(Linux, BSD, Solaris) and use the NS4 API (Mozilla,
+>Firefox, Opera, etc.).
+>
+>ahmad <ahmad> 1.0.3-1.mga2:
+>+ Revision: 102752
+>- Update to 1.0.3
+>- Drop gconf support, it uses gsettings by default now
+>- Add BR curl-devel, for e.g. apple.com support
+
+Using this version makes nearly every browser crash within a few clicks in
+history. Back to 1.0.0-2.mga1 fixes that. Same happened earlier on Cooker
+when I still had a cookbox.
+
+Ciao,
+=Dick Gevers=
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005314.html b/zarb-ml/mageia-dev/2011-June/005314.html new file mode 100644 index 000000000..fa075bbca --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005314.html @@ -0,0 +1,270 @@ + + + + [Mageia-dev] [RPM] cauldron core/release gecko-mediaplayer-1.0.3-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release gecko-mediaplayer-1.0.3-1.mga2

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Fri Jun 10 05:23:23 CEST 2011 +

+
+ +
On 10 June 2011 03:33, Dick Gevers <dvgevers at xs4all.nl> wrote:
+> On Fri, 10 Jun 2011 01:03:12 +0200 (CEST), Mageia Team wrote about [RPM]
+> cauldron core/release gecko-mediaplayer-1.0.3-1.mga2:
+>
+>>Name        : gecko-mediaplayer            Relocations: (not relocatable)
+>>Version     : 1.0.3                             Vendor: Mageia.Org
+>>Release     : 1.mga2                        Build Date: Fri Jun 10
+>>01:01:15 2011 Install Date: (not installed)               Build Host:
+>>jonund Group       : Networking/WWW                Source RPM: (none)
+>>Size        : 276237                           License: GPLv2+
+>>Signature   : (none)
+>>Packager    : Mageia Team <http://www.mageia.org>
+>>URL         : http://kdekorte.googlepages.com/gecko-mediaplayer
+>>Summary     : GNOME MPlayer browser plugin
+>>Description :
+>>Gecko Media Player is a browser plugin that uses GNOME MPlayer to
+>>play media in a browser. It should work with all browsers on
+>>Unix-ish systems(Linux, BSD, Solaris) and use the NS4 API (Mozilla,
+>>Firefox, Opera, etc.).
+>>
+>>ahmad <ahmad> 1.0.3-1.mga2:
+>>+ Revision: 102752
+>>- Update to 1.0.3
+>>- Drop gconf support, it uses gsettings by default now
+>>- Add BR curl-devel, for e.g. apple.com support
+>
+> Using this version makes nearly every browser crash within a few clicks in
+> history. Back to 1.0.0-2.mga1 fixes that. Same happened earlier on Cooker
+> when I still had a cookbox.
+>
+> Ciao,
+> =Dick Gevers=
+>
+
+Thanks for the heads up.
+
+gecko-mediaplayer requires a newer gnome-mplayer
+http://code.google.com/p/gecko-mediaplayer/issues/detail?id=131
+
+gnome-mplayer-1.0.3 should be on the mirrors soon.
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005315.html b/zarb-ml/mageia-dev/2011-June/005315.html new file mode 100644 index 000000000..49e8a4da7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005315.html @@ -0,0 +1,210 @@ + + + + [Mageia-dev] Mageia 2 - Improving educational programs + + + + + + + + + +

[Mageia-dev] Mageia 2 - Improving educational programs

+ Stefano Negro + stblack at gmail.com +
+ Fri Jun 10 08:47:54 CEST 2011 +

+
+ +
2011/6/9 Angelo Naselli <anaselli at linux.it>
+
+> Hi
+> i'd like to add an item to mageia 2 specification, e.g.
+> improving the educational part. (Already added into wiki)
+> .....
+>
+> WDYT?
+>
+> --
+>         Angelo
+>
+
+I think is a good task and I will help Angelo.
+First we need to discuss if develop under KDE or also Gnome (2), taking into
+consideration also the old hardware on which usually it's installed.
+
+-- 
+Stblack
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110610/ef33d041/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005316.html b/zarb-ml/mageia-dev/2011-June/005316.html new file mode 100644 index 000000000..080e56410 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005316.html @@ -0,0 +1,238 @@ + + + + [Mageia-dev] [RPM] cauldron core/release gecko-mediaplayer-1.0.3-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release gecko-mediaplayer-1.0.3-1.mga2

+ Dick Gevers + dvgevers at xs4all.nl +
+ Fri Jun 10 09:45:50 CEST 2011 +

+
+ +
On Fri, 10 Jun 2011 06:23:23 +0300, Ahmad Samir wrote about Re:
+[Mageia-dev] [RPM] cauldron core/release gecko-mediaplayer-1.0.3-1.mga2:
+
+>gecko-mediaplayer requires a newer gnome-mplayer
+>http://code.google.com/p/gecko-mediaplayer/issues/detail?id=131
+>
+>gnome-mplayer-1.0.3 should be on the mirrors soon.
+
+Thanks. "Problem" solved.
+
+Cheers,
+=Dick Gevers=
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005317.html b/zarb-ml/mageia-dev/2011-June/005317.html new file mode 100644 index 000000000..d312702db --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005317.html @@ -0,0 +1,204 @@ + + + + [Mageia-dev] Mageia 2 - Improving educational programs + + + + + + + + + +

[Mageia-dev] Mageia 2 - Improving educational programs

+ Angelo Naselli + anaselli at linux.it +
+ Fri Jun 10 10:09:49 CEST 2011 +

+
+ +
> WDYT?
+
+I'd add that this task could be a good start for padawans, well i could
+try to mentor someone here :) ... easier if we're going to be a team
+in this task (if dmorgan agrees and joins me/us :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/20110610/cd7d7cbd/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005318.html b/zarb-ml/mageia-dev/2011-June/005318.html new file mode 100644 index 000000000..f6642ebcb --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005318.html @@ -0,0 +1,198 @@ + + + + [Mageia-dev] Mageia 2 - Improving educational programs + + + + + + + + + +

[Mageia-dev] Mageia 2 - Improving educational programs

+ Dexter Morgan + dmorganec at gmail.com +
+ Fri Jun 10 10:17:53 CEST 2011 +

+
+ +
On Fri, Jun 10, 2011 at 10:09 AM, Angelo Naselli <anaselli at linux.it> wrote:
+>> WDYT?
+>
+> I'd add that this task could be a good start for padawans, well i could
+> try to mentor someone here :) ... easier if we're going to be a team
+> in this task (if dmorgan agrees and joins me/us :p )
+
+Yes of course :)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005319.html b/zarb-ml/mageia-dev/2011-June/005319.html new file mode 100644 index 000000000..3eaf534a8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005319.html @@ -0,0 +1,219 @@ + + + + [Mageia-dev] Mageia 2 - Improving educational programs + + + + + + + + + +

[Mageia-dev] Mageia 2 - Improving educational programs

+ Angelo Naselli + anaselli at linux.it +
+ Fri Jun 10 10:22:53 CEST 2011 +

+
+ +
Hi Stefano,
+> I think is a good task and I will help Angelo.
+Thanks.
+
+> First we need to discuss if develop under KDE or also Gnome (2), taking into
+> consideration also the old hardware on which usually it's installed.
+Well I know you and probably what you mean... but it's really hard to understand :)
+
+There's nothing to choose in the first two items - well maybe a little bit in 
+the second one :) - I mean importing programs is not related to a specific DE,
+if that program has been developed using a library more than another it will
+run better in a DE that is written for that library (e.g. gtk/gnome or qt/kde 
+for instance), but that does not avoid using such a program into other DEs ;)
+
+Now let's see if i understood your point, if you mean about live-cd well yes
+something has to be decided, but that's not a big priority task, i'd like to 
+have a more user friendly installable and with a wide choice system concerning 
+educational programs first.
+After that we could add more configuration files to draklive implementing one or
+more specific edu-tasks.
+
+WDYT?
+
+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/20110610/47f736c1/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005320.html b/zarb-ml/mageia-dev/2011-June/005320.html new file mode 100644 index 000000000..0a1dea8fb --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005320.html @@ -0,0 +1,209 @@ + + + + [Mageia-dev] Mageia 2 - Improving educational programs + + + + + + + + + +

[Mageia-dev] Mageia 2 - Improving educational programs

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Fri Jun 10 10:26:59 CEST 2011 +

+
+ +
Dexter Morgan <dmorganec at gmail.com> schrieb am 10.06.2011
+> On Fri, Jun 10, 2011 at 10:09 AM, Angelo Naselli <anaselli at linux.it> 
+wrote:
+> >> WDYT?
+> > 
+> > I'd add that this task could be a good start for padawans, well i
+> > could try to mentor someone here :) ... easier if we're going to
+> > be a team in this task (if dmorgan agrees and joins me/us :p )
+> 
+> Yes of course :)
+Last year at some German linux event I was talking with a guy from 
+Seminarix, a project providing a Sidux/Aptosid based distro for 
+teachers-to-be.
+So we could take their software collection as an example and look 
+what's left to do.
+
+Oliver
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110610/7076a19f/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005321.html b/zarb-ml/mageia-dev/2011-June/005321.html new file mode 100644 index 000000000..8fd80451e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005321.html @@ -0,0 +1,212 @@ + + + + [Mageia-dev] Mageia 2 - Improving educational programs + + + + + + + + + +

[Mageia-dev] Mageia 2 - Improving educational programs

+ Angelo Naselli + anaselli at linux.it +
+ Fri Jun 10 10:50:05 CEST 2011 +

+
+ +
venerdì 10 giugno 2011 alle 10:26, Oliver Burger ha scritto:
+> Last year at some German linux event I was talking with a guy from 
+> Seminarix, a project providing a Sidux/Aptosid based distro for 
+> teachers-to-be.
+> So we could take their software collection as an example and look 
+> what's left to do.
+Sounds good, can you add a link please?
+
+I'd prefer to go on this subject here on ML and add a wiki page later,
+but if someone has time can add it already...
+
+As a reminder, i started porting programs shown here:
+http://www.schoolforge.net/
+
+Thanks
+	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/20110610/d7bebd17/attachment-0001.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005322.html b/zarb-ml/mageia-dev/2011-June/005322.html new file mode 100644 index 000000000..2bc7ea0ce --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005322.html @@ -0,0 +1,216 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Fri Jun 10 10:56:35 CEST 2011 +

+
+ +
'Twas brillig, and Ahmad Samir at 09/06/11 17:42 did gyre and gimble:
+> On 9 June 2011 14:22, Oliver Burger <oliver.bgr at googlemail.com> wrote:
+>> Dexter Morgan <dmorganec at gmail.com> schrieb am 09.06.2011
+>>
+>>> On Thu, Jun 9, 2011 at 11:54 AM, Colin Guthrie <mageia at colin.guthr.ie>
+>>> wrote:
+>>
+>>>> I think updates would be the right place.
+>>
+>>>
+>>
+>>> Please no 3rd repo :)
+>>
+>>> But i agree with you for updates for "new" packages ( no "new"
+>>
+>>> versions ;) )
+>>
+>>
+>> I would prefer using updates over backports as well. If we use backports we
+>> would get more problems then benefit (like people not having backports
+>> enabled or people having backports enabled and thus getting problems they
+>> can't handle e.g. with new kernels, graphic drivers and so on).
+>>
+>>
+>> Perhaps we could upload them to updates/testing for a really short qa before
+>> moving them to updates/ ?
+>>
+>>
+>> Oliver
+> 
+> If it's pushed to /updates then it should be imported to the stable
+> release SVN tree; note that at some point Cauldron could get a newer
+> version than the one in /updates, and maybe it's not backportable, new
+> deps, regressions... etc. But now if there's a bug in the version in
+> the stable */updates, and it needs a patch, what are you gonna base
+> the patch on if you submit directly from the Cauldron SVN checkout to
+> */updates, and the Cauldron package has already changed?
+> 
+> But if new package can go directly to updates.. that doesn't look
+> right to me, because at which point will "new" packages stop going to
+> a stable release */updates? if it goes on and on, then we're talking
+> about a semi-cauldron-like repo.
+
+So just svn cp it to the /1/updates tree in svn and job's a good 'un.
+(well svn cp is no longer just one step due to source separation, but
+the principle is the same!).
+
+
+> Also note that a new package in Cauldron gets tested for a while
+> (depending at which point it was imported during the release cycle),
+> but if gets pushed to /updates and not backports (which is "not
+> supported"), that testing period is short-circuited.
+
+Yeah but then the examples I've got so far are:
+
+ * trac
+ * supybot
+ * supybot-Meetbot
+ * passwd-gen
+ * dd_rescue
+
+In all these cases, these are packages I use. I will be testing them on
+that version of the distro. And when I don't use them every day, (e.g.
+passwd-gen, dd_rescue), they are pretty standard, stable and standalone
+apps.
+
+IMO we can over-analyse the "risk" factor here massive to the detriment
+of the overall offering.
+
+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-June/005323.html b/zarb-ml/mageia-dev/2011-June/005323.html new file mode 100644 index 000000000..1283787c1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005323.html @@ -0,0 +1,205 @@ + + + + [Mageia-dev] Mageia 2 - Improving educational programs + + + + + + + + + +

[Mageia-dev] Mageia 2 - Improving educational programs

+ Pierre Jarillon + jarillon at abul.org +
+ Fri Jun 10 11:44:37 CEST 2011 +

+
+ +
Le jeudi 9 juin 2011 23:28:45, Angelo Naselli a écrit :
+> i'd like to add an item to mageia 2 specification, e.g.
+> improving the educational part. (Already added into wiki)
+
+Do you know http://www.abuledu.org/en/accueil ?
+This is a free/libre project created in 1999 and very dynamic.
+Ryxeo offers a professional support.
+
+The first release was built on Mandrake but was difficult to maintain.
+Then the project has migrated on Debian and Ubuntu because of this.
+It is perhaps the good time to make Abuledu running on Mageia.
+
+Eric Seigne is the leader of the Abuledu project since 1999.
+-- 
+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-June/005324.html b/zarb-ml/mageia-dev/2011-June/005324.html new file mode 100644 index 000000000..a1909623b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005324.html @@ -0,0 +1,207 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Samuel Verschelde + stormi at laposte.net +
+ Fri Jun 10 11:52:51 CEST 2011 +

+
+ +
+Le vendredi 10 juin 2011 10:56:35, Colin Guthrie a écrit :
+> 'Twas brillig, and Ahmad Samir at 09/06/11 17:42 did gyre and gimble:
+> > On 9 June 2011 14:22, Oliver Burger <oliver.bgr at googlemail.com> wrote:
+> >> Dexter Morgan <dmorganec at gmail.com> schrieb am 09.06.2011
+> >> 
+> >>> On Thu, Jun 9, 2011 at 11:54 AM, Colin Guthrie <mageia at colin.guthr.ie>
+> >>> 
+> >>> wrote:
+> >>>> I think updates would be the right place.
+> >>> 
+> >>> Please no 3rd repo :)
+> >>> 
+> >>> But i agree with you for updates for "new" packages ( no "new"
+> >>> 
+> >>> versions ;) )
+> >> 
+> >> I would prefer using updates over backports as well. If we use backports
+> >> we would get more problems then benefit (like people not having
+> >> backports enabled or people having backports enabled and thus getting
+> >> problems they can't handle e.g. with new kernels, graphic drivers and
+> >> so on).
+> >> 
+> >> 
+> >> Perhaps we could upload them to updates/testing for a really short qa
+> >> before moving them to updates/ ?
+> >> 
+> >> 
+> >> Oliver
+> > 
+> > If it's pushed to /updates then it should be imported to the stable
+> > release SVN tree; note that at some point Cauldron could get a newer
+> > version than the one in /updates, and maybe it's not backportable, new
+> > deps, regressions... etc. But now if there's a bug in the version in
+> > the stable */updates, and it needs a patch, what are you gonna base
+> > the patch on if you submit directly from the Cauldron SVN checkout to
+> > */updates, and the Cauldron package has already changed?
+> > 
+> > But if new package can go directly to updates.. that doesn't look
+> > right to me, because at which point will "new" packages stop going to
+> > a stable release */updates? if it goes on and on, then we're talking
+> > about a semi-cauldron-like repo.
+> 
+> So just svn cp it to the /1/updates tree in svn and job's a good 'un.
+> (well svn cp is no longer just one step due to source separation, but
+> the principle is the same!).
+> 
+> > Also note that a new package in Cauldron gets tested for a while
+> > (depending at which point it was imported during the release cycle),
+> > but if gets pushed to /updates and not backports (which is "not
+> > supported"), that testing period is short-circuited.
+> 
+> Yeah but then the examples I've got so far are:
+> 
+>  * trac
+>  * supybot
+>  * supybot-Meetbot
+>  * passwd-gen
+>  * dd_rescue
+> 
+> In all these cases, these are packages I use. I will be testing them on
+> that version of the distro. And when I don't use them every day, (e.g.
+> passwd-gen, dd_rescue), they are pretty standard, stable and standalone
+> apps.
+> 
+> IMO we can over-analyse the "risk" factor here massive to the detriment
+> of the overall offering.
+> 
+> Col
+
+I agree with Colin here.
+
+Samuel
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005325.html b/zarb-ml/mageia-dev/2011-June/005325.html new file mode 100644 index 000000000..e2566e94e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005325.html @@ -0,0 +1,183 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process) + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process)

+ Michael Scherer + misc at zarb.org +
+ Fri Jun 10 12:27:49 CEST 2011 +

+
+ +
Le jeudi 09 juin 2011 à 10:14 +0100, Colin Guthrie a écrit :
+> Hi,
+> 
+> As I upgrade my various machines (I only really have about 5, so not
+> that many) I'm running into a few packages that are missing (this is
+> inevitable).
+> 
+> Nothing major just little things like trac and supybot etc.
+> 
+> What is the best way to add these packages to the v1 tree?
+> 
+> Using backports seems a little odd as this is "unsupported" and we don't
+> really want to encourage using it as a means to get the missing packages.
+
+If we do not want to have people use backports, we wouldn't have added
+it in the first place.
+
+I do think backport is perfectly suited for that.
+
+
+> release is obviously frozen so no go there.
+> 
+> The only real option is updates, but that should obviously have some QA
+> on it.
+
+Updates is not for new version of software, not for new softwares. And
+backporting something from cauldron is not a update.
+
+> Perhaps we need to have some kind of exemption to get these missing
+> packages added?
+> 
+> Does anyone have any opinions on this?
+
+Yes, I do.
+
+We have used backports in the past for that, and I see no reason to
+change that. 
+
+If the problem is that backports were too buggy in the past, then we
+should fix backports process, not bypassing them.
+
+And if we start by pushing new version in update, people will soon
+wonder why the new version of X is in updates, while the new version of
+Y is not, just because we didn't have X in release and Y was there.
+
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005326.html b/zarb-ml/mageia-dev/2011-June/005326.html new file mode 100644 index 000000000..c113a5684 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005326.html @@ -0,0 +1,150 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Michael Scherer + misc at zarb.org +
+ Fri Jun 10 12:29:28 CEST 2011 +

+
+ +
Le vendredi 10 juin 2011 à 09:56 +0100, Colin Guthrie a écrit :
+> 'Twas brillig, and Ahmad Samir at 09/06/11 17:42 did gyre and gimble:
+
+> > But if new package can go directly to updates.. that doesn't look
+> > right to me, because at which point will "new" packages stop going to
+> > a stable release */updates? if it goes on and on, then we're talking
+> > about a semi-cauldron-like repo.
+> 
+> So just svn cp it to the /1/updates tree in svn and job's a good 'un.
+> (well svn cp is no longer just one step due to source separation, but
+> the principle is the same!).
+
+The bin repository is a different svn, so it will not work.
+
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005327.html b/zarb-ml/mageia-dev/2011-June/005327.html new file mode 100644 index 000000000..b5ebceebf --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005327.html @@ -0,0 +1,165 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Fri Jun 10 12:35:02 CEST 2011 +

+
+ +
'Twas brillig, and Michael Scherer at 10/06/11 11:29 did gyre and gimble:
+> Le vendredi 10 juin 2011 à 09:56 +0100, Colin Guthrie a écrit :
+>> 'Twas brillig, and Ahmad Samir at 09/06/11 17:42 did gyre and gimble:
+> 
+>>> But if new package can go directly to updates.. that doesn't look
+>>> right to me, because at which point will "new" packages stop going to
+>>> a stable release */updates? if it goes on and on, then we're talking
+>>> about a semi-cauldron-like repo.
+>>
+>> So just svn cp it to the /1/updates tree in svn and job's a good 'un.
+>> (well svn cp is no longer just one step due to source separation, but
+>> the principle is the same!).
+> 
+> The bin repository is a different svn, so it will not work.
+
+Isn't that what I said? (I referred to the binary sources as just
+"source"). I maintain the principle is still the same albeit we need to
+do a bit more tweaking/scripting, or am I missing something?
+
+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-June/005328.html b/zarb-ml/mageia-dev/2011-June/005328.html new file mode 100644 index 000000000..8e275ced5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005328.html @@ -0,0 +1,210 @@ + + + + [Mageia-dev] Mageia 2 - Improving educational programs + + + + + + + + + +

[Mageia-dev] Mageia 2 - Improving educational programs

+ Angelo Naselli + anaselli at linux.it +
+ Fri Jun 10 12:37:40 CEST 2011 +

+
+ +
venerdì 10 giugno 2011 alle 11:44, Pierre Jarillon ha scritto:
+> Le jeudi 9 juin 2011 23:28:45, Angelo Naselli a écrit :
+> > i'd like to add an item to mageia 2 specification, e.g.
+> > improving the educational part. (Already added into wiki)
+> 
+> Do you know http://www.abuledu.org/en/accueil ?
+> This is a free/libre project created in 1999 and very dynamic.
+> Ryxeo offers a professional support.
+> 
+> The first release was built on Mandrake but was difficult to maintain.
+> Then the project has migrated on Debian and Ubuntu because of this.
+> It is perhaps the good time to make Abuledu running on Mageia.
+> 
+> Eric Seigne is the leader of the Abuledu project since 1999.
+> 
+
+Pierre, honestly it's hard to me following that site, nice
+at first sight but in French for the most :/
+
+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/20110610/a675003e/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005329.html b/zarb-ml/mageia-dev/2011-June/005329.html new file mode 100644 index 000000000..5a652ecd3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005329.html @@ -0,0 +1,234 @@ + + + + [Mageia-dev] [RFC] Removing .la files + + + + + + + + + +

[Mageia-dev] [RFC] Removing .la files

+ Michael Scherer + misc at zarb.org +
+ Fri Jun 10 12:41:46 CEST 2011 +

+
+ +
Le vendredi 10 juin 2011 à 03:47 +0300, Ahmad Samir a écrit :
+> On 9 June 2011 19:35, Dexter Morgan <dmorganec at gmail.com> wrote:
+> > Hello,
+> >
+> > as other distributions we started to remove .la files from mageia
+> > during mageia 1 development.
+
+Could you explain the rational of removing them ?
+
+AFAIK, the .la removal was not discussed, so starting by saying "we
+remove them now because last time, we didn't discussed and it broke lots
+of thing" is a little bit weird.
+
+
+> > Unfortunatly we didn't had enough time to finish this.
+> >
+> > I restarted this task today.
+> >
+> >
+> > Please tell me if a build fails because of a missing la file.
+> >
+> 
+> >From building pidgin-libnotify locally:
+> libtool: link: cannot find the library `/usr/lib64/libatk-1.0.la' or
+> unhandled argument `/usr/lib64/libatk-1.0.la'
+> 
+> >From the chroot:
+> $ cd usr/lib64/
+> $ grep libatk-1.0.la *
+> libindicate-gtk.la:dependency_libs=' /usr/lib64/libindicate.la
+> /usr/lib64/libgtk-x11-2.0.la /usr/lib64/libgdk-x11-2.0.la
+> /usr/lib64/libatk-1.0.la /usr/lib64/libpangocairo-1.0.la
+> /usr/lib64/libpangoft2-1.0.la /usr/lib64/libgdk_pixbuf-2.0.la
+> /usr/lib64/libcairo.la /usr/lib64/libpixman-1.la
+> /usr/lib64/libXrender.la /usr/lib64/libX11.la /usr/lib64/libxcb.la
+> /usr/lib64/libXau.la /usr/lib64/libXdmcp.la -lpng12
+> /usr/lib64/libpango-1.0.la /usr/lib64/libfontconfig.la
+> /usr/lib64/libfreetype.la /usr/lib64/libxml2.la -lm
+> /usr/lib64/libdbusmenu-glib.la /usr/lib64/libgio-2.0.la -lresolv -lz
+> /usr/lib64/libgmodule-2.0.la -ldl -ldbus-glib-1 -ldbus-1
+> /usr/lib64/libgobject-2.0.la /usr/lib64/libgthread-2.0.la -lpthread
+> /usr/lib64/libglib-2.0.la /usr/lib64/libpcre.la -lrt'
+> 
+> 
+> I don't think just building packages and removing the .la will work,
+> the inter-dependency is too wide, I count too many .la files up there.
+> 
+> Reading these:
+> http://wiki.debian.org/ReleaseGoals/LAFileRemoval
+> http://lists.debian.org/debian-devel/2009/08/msg00783.html
+> 
+> it looks like Debian are using sed to remove the .la files from
+> dependency_libs field in .la files, there's a debhelper script, IIUC
+> it's run before they build a package.
+> 
+> This means it's something that a script run as root in the chroot can
+> do, but I guess it needs to be fine-tuned.
+> 
+> Meanwhile, just removing .la files will break a lot of builds (note
+> that we have a lot of packages to rebuild for e.g. new libnotify major
+> in Cauldron)... :(
+
+Ie, we need to remove them in the proper order. 
+One first step would be to find the dependency tree ( should be
+basically the same as BuildRequires ) and start bu shaving the leafs.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005330.html b/zarb-ml/mageia-dev/2011-June/005330.html new file mode 100644 index 000000000..d6524be6f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005330.html @@ -0,0 +1,222 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Fri Jun 10 12:44:06 CEST 2011 +

+
+ +
'Twas brillig, and Michael Scherer at 10/06/11 11:27 did gyre and gimble:
+> Le jeudi 09 juin 2011 à 10:14 +0100, Colin Guthrie a écrit :
+>> Hi,
+>>
+>> As I upgrade my various machines (I only really have about 5, so not
+>> that many) I'm running into a few packages that are missing (this is
+>> inevitable).
+>>
+>> Nothing major just little things like trac and supybot etc.
+>>
+>> What is the best way to add these packages to the v1 tree?
+>>
+>> Using backports seems a little odd as this is "unsupported" and we don't
+>> really want to encourage using it as a means to get the missing packages.
+> 
+> If we do not want to have people use backports, we wouldn't have added
+> it in the first place.
+> 
+> I do think backport is perfectly suited for that.
+
+So the user that just wants to install supybot has to expose themselves
+to the risk of updating to a backported version of gnome or KDE.... this
+is hardly ideal. Especially for novice users.
+
+>> release is obviously frozen so no go there.
+>>
+>> The only real option is updates, but that should obviously have some QA
+>> on it.
+> 
+> Updates is not for new version of software, not for new softwares. And
+> backporting something from cauldron is not a update.
+
+This seems like a strange statement as */updates on mdv was allowed to
+have new packages in some cases (I've done it before, although I think
+only for * == contrib), so I don't see why we have to restrict this
+possibility in Mageia.
+
+>> Perhaps we need to have some kind of exemption to get these missing
+>> packages added?
+>>
+>> Does anyone have any opinions on this?
+> 
+> Yes, I do.
+> 
+> We have used backports in the past for that, and I see no reason to
+> change that.
+
+This is fine in the regular course of distro evolution, but here we're
+talking about users migrating from Mdv to Mga and finding "stale" Mdv
+packages still installed on their system when they want (and we want to
+provide) a Mageia version. This is very much a special case for this
+transitional period but I feel it's an important one, particularly
+*because* it's the first release.
+
+I think you're thinking in absolute terms rather than transitional
+terms. In absolute terms I agree with you on principle, but I think we
+need to deal with transitional issues gracefully and not treat them as
+second class considerations.
+
+> If the problem is that backports were too buggy in the past, then we
+> should fix backports process, not bypassing them.
+
+I don't think this is particularly relevant. Backports are unsupported
+generally. That's a given. If we encourage people to enable backports to
+get missing packages (this is very distinct and separate from the
+unsupported backports).
+
+> And if we start by pushing new version in update, people will soon
+> wonder why the new version of X is in updates, while the new version of
+> Y is not, just because we didn't have X in release and Y was there.
+
+I very much consider "nothing -> version X" quite different from
+"version X -> version Y". I don't think it's a hard concept for anyone
+to grasp.
+
+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-June/005331.html b/zarb-ml/mageia-dev/2011-June/005331.html new file mode 100644 index 000000000..364ebed47 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005331.html @@ -0,0 +1,137 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Michael Scherer + misc at zarb.org +
+ Fri Jun 10 12:46:38 CEST 2011 +

+
+ +
Le jeudi 09 juin 2011 à 10:49 +0100, Colin Guthrie a écrit :
+> 'Twas brillig, and Wolfgang Bornath at 09/06/11 10:25 did gyre and gimble:
+> > 2011/6/9 JA Magallón <jamagallon at ono.com>:
+> >>
+> >> No need, Cauldron is Cauldron. The only strange thing is that I had
+> >> heard on other threads that update to Gnome 3 was being discussed,
+> >> but never realized it had finally agreed on.
+> > 
+> > Same here, I'm a bit surprised.
+> 
+> We're on the next cycle now. Quite frankly I'd be stunned (and hugely
+> disappointed) if we *didn't* have Gnome 3!
+
+While I have no issue with gnome-shell, I have read enough reports of
+people not happy with it to know we would head to a 2nd kde 4.0 story.
+So maybe we could start to learn from the past and discuss with users to
+explain the update, see why they do not want etc, instead of being
+purely focused on "it is cauldron, let's update everything".  
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005332.html b/zarb-ml/mageia-dev/2011-June/005332.html new file mode 100644 index 000000000..f067650ee --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005332.html @@ -0,0 +1,160 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Fri Jun 10 12:53:23 CEST 2011 +

+
+ +
[Didn't finish this sentence]
+
+'Twas brillig, and Colin Guthrie at 10/06/11 11:44 did gyre and gimble:
+> I don't think this is particularly relevant. Backports are unsupported
+> generally. That's a given. If we encourage people to enable backports to
+> get missing packages (this is very distinct and separate from the
+> unsupported backports)
+
+... then we will end up having to support people who have accidentally
+updated to a backported package they didn't intend or want to install.
+This is likely more hassle for us in the long run.
+
+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-June/005333.html b/zarb-ml/mageia-dev/2011-June/005333.html new file mode 100644 index 000000000..3af1085e5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005333.html @@ -0,0 +1,129 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Frank Griffin + ftg at roadrunner.com +
+ Fri Jun 10 13:20:41 CEST 2011 +

+
+ +
On 06/10/2011 06:46 AM, Michael Scherer wrote:
+> While I have no issue with gnome-shell, I have read enough reports of
+> people not happy with it to know we would head to a 2nd kde 4.0 story.
+> So maybe we could start to learn from the past and discuss with users to
+> explain the update, see why they do not want etc, instead of being
+> purely focused on "it is cauldron, let's update everything".
++1
+
+3 is rumored to have a lot of ideological change, and probably the usual 
+GNOME removal of working stuff that people expect to be there (GDM 
+config).  It would be very nice to have a tool to switch back and forth 
+for experimentation, at least a minimal list of things from each release 
+that can be removed via rpm --nodeps prior to reinstalling the other 
+release, so that urpmi doesn't try to remove the world to make the change.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005334.html b/zarb-ml/mageia-dev/2011-June/005334.html new file mode 100644 index 000000000..0a0278110 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005334.html @@ -0,0 +1,136 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Kira + elegant.pegasus at gmail.com +
+ Fri Jun 10 13:39:16 CEST 2011 +

+
+ +
在 Fri, 10 Jun 2011 19:20:41 +0800, Frank Griffin <ftg at roadrunner.com>寫道:
+
+> On 06/10/2011 06:46 AM, Michael Scherer wrote:
+>> While I have no issue with gnome-shell, I have read enough reports of
+>> people not happy with it to know we would head to a 2nd kde 4.0 story.
+>> So maybe we could start to learn from the past and discuss with users to
+>> explain the update, see why they do not want etc, instead of being
+>> purely focused on "it is cauldron, let's update everything".
+> +1
+>
+> 3 is rumored to have a lot of ideological change, and probably the usual  
+> GNOME removal of working stuff that people expect to be there (GDM  
+> config).  It would be very nice to have a tool to switch back and forth  
+> for experimentation, at least a minimal list of things from each release  
+> that can be removed via rpm --nodeps prior to reinstalling the other  
+> release, so that urpmi doesn't try to remove the world to make the  
+> change.
+In the past time, there's KDE3 and KDE4 co-exist together in the  
+repository,
+
+maybe we can do it again?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005335.html b/zarb-ml/mageia-dev/2011-June/005335.html new file mode 100644 index 000000000..c21209fc2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005335.html @@ -0,0 +1,142 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Dexter Morgan + dmorganec at gmail.com +
+ Fri Jun 10 13:44:14 CEST 2011 +

+
+ +
2011/6/10 Kira <elegant.pegasus at gmail.com>:
+> 在 Fri, 10 Jun 2011 19:20:41 +0800, Frank Griffin <ftg at roadrunner.com>寫道:
+>
+>> On 06/10/2011 06:46 AM, Michael Scherer wrote:
+>>>
+>>> While I have no issue with gnome-shell, I have read enough reports of
+>>> people not happy with it to know we would head to a 2nd kde 4.0 story.
+>>> So maybe we could start to learn from the past and discuss with users to
+>>> explain the update, see why they do not want etc, instead of being
+>>> purely focused on "it is cauldron, let's update everything".
+>>
+>> +1
+>>
+>> 3 is rumored to have a lot of ideological change, and probably the usual
+>> GNOME removal of working stuff that people expect to be there (GDM config).
+>>  It would be very nice to have a tool to switch back and forth for
+>> experimentation, at least a minimal list of things from each release that
+>> can be removed via rpm --nodeps prior to reinstalling the other release, so
+>> that urpmi doesn't try to remove the world to make the change.
+>
+> In the past time, there's KDE3 and KDE4 co-exist together in the repository,
+>
+> maybe we can do it again?
+>
+
+maybe 1 wait to have gnome 3 and then speak about gnome2
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005336.html b/zarb-ml/mageia-dev/2011-June/005336.html new file mode 100644 index 000000000..9f399ab10 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005336.html @@ -0,0 +1,164 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process) + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process)

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Fri Jun 10 13:44:29 CEST 2011 +

+
+ +
2011/6/10 Michael Scherer <misc at zarb.org>:
+>
+> We have used backports in the past for that, and I see no reason to
+> change that.
+>
+> If the problem is that backports were too buggy in the past, then we
+> should fix backports process, not bypassing them.
+>
+> And if we start by pushing new version in update, people will soon
+> wonder why the new version of X is in updates, while the new version of
+> Y is not, just because we didn't have X in release and Y was there.
+
+Problem I see:
+So far (in Mandriva), example:  we have used 2010.0/main/backports to
+offer new versions of software which had an older version in 2010/main
+but the newer version in 2010.1/main, or as the name says: backporting
+a newer version of a software from the current release to a previous
+release, as often used for Firefox.
+
+For Mageia it means, /backports should hold backports of software
+which has an older version in 1/core but a newer version in cauldron.
+If we put new software (aka missing packages) in /backports and the
+user activates /backports he also runs the risk that existing packages
+of his stable installation will be replaced by real backports of newer
+versions, backported from Cauldron - which he may not want to do.
+
+I wonder why we do not put these "missing packages" in /testing and
+after a while in /core or /non-free or /tainted (wherever they
+belong). These packages are software which were supposed to be in
+/core or /non-free or /tainted, they were just forgotten|came too
+late|whatever for Mageia 1 release freeze.
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005337.html b/zarb-ml/mageia-dev/2011-June/005337.html new file mode 100644 index 000000000..f7405e713 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005337.html @@ -0,0 +1,183 @@ + + + + [Mageia-dev] [RFC] Removing .la files + + + + + + + + + +

[Mageia-dev] [RFC] Removing .la files

+ Olav Vitters + olav at vitters.nl +
+ Fri Jun 10 13:51:38 CEST 2011 +

+
+ +
On Fri, Jun 10, 2011 at 12:41:46PM +0200, Michael Scherer wrote:
+> Le vendredi 10 juin 2011 à 03:47 +0300, Ahmad Samir a écrit :
+> > On 9 June 2011 19:35, Dexter Morgan <dmorganec at gmail.com> wrote:
+> > > Hello,
+> > >
+> > > as other distributions we started to remove .la files from mageia
+> > > during mageia 1 development.
+> 
+> Could you explain the rational of removing them ?
+> 
+> AFAIK, the .la removal was not discussed, so starting by saying "we
+> remove them now because last time, we didn't discussed and it broke lots
+> of thing" is a little bit weird.
+
+https://live.gnome.org/GnomeShell/RemovingLaFiles
+
+Seems some distributions misunderstand the need and changed the wiki
+page. Removing .la files is needed however, otherwise you'll quickly mix
+distribution installed libraries and self-compiled libraries.
+
+Difficulty is that this only works when you remove *all* .la files. If
+only one is left compilation is broken.
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005338.html b/zarb-ml/mageia-dev/2011-June/005338.html new file mode 100644 index 000000000..30fa4e674 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005338.html @@ -0,0 +1,158 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Fri Jun 10 13:55:40 CEST 2011 +

+
+ +
2011/6/10 Michael Scherer <misc at zarb.org>:
+> Le jeudi 09 juin 2011 à 10:49 +0100, Colin Guthrie a écrit :
+>> 'Twas brillig, and Wolfgang Bornath at 09/06/11 10:25 did gyre and gimble:
+>> > 2011/6/9 JA Magallón <jamagallon at ono.com>:
+>> >>
+>> >> No need, Cauldron is Cauldron. The only strange thing is that I had
+>> >> heard on other threads that update to Gnome 3 was being discussed,
+>> >> but never realized it had finally agreed on.
+>> >
+>> > Same here, I'm a bit surprised.
+>>
+>> We're on the next cycle now. Quite frankly I'd be stunned (and hugely
+>> disappointed) if we *didn't* have Gnome 3!
+>
+> While I have no issue with gnome-shell, I have read enough reports of
+> people not happy with it to know we would head to a 2nd kde 4.0 story.
+> So maybe we could start to learn from the past and discuss with users to
+> explain the update, see why they do not want etc, instead of being
+> purely focused on "it is cauldron, let's update everything".
+
+I do have a problem with gnome-shell, that is my individual opinion.
+But I also read a lot of discussions among Gnome users where the new
+way of Gnome seems to split the community much more than the KDE3.5 to
+KDE4 change. This has been said already way back when we started to
+get the first requests for Gnome3 in Mageia1. Since that time we
+always told the users that implementing Gnome3 will be subject to
+discussion after the Mageia 1 release.
+
+So I was a bit surprised that this was done kind of automagically
+without any discussion.
+
+Besides this I agree to Michael's suggestion.
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005339.html b/zarb-ml/mageia-dev/2011-June/005339.html new file mode 100644 index 000000000..259cc2e42 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005339.html @@ -0,0 +1,182 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Thomas Backlund + tmb at mageia.org +
+ Fri Jun 10 13:57:54 CEST 2011 +

+
+ +
Wolfgang Bornath skrev 10.6.2011 14:44:
+> 2011/6/10 Michael Scherer<misc at zarb.org>:
+>>
+>> We have used backports in the past for that, and I see no reason to
+>> change that.
+>>
+>> If the problem is that backports were too buggy in the past, then we
+>> should fix backports process, not bypassing them.
+>>
+>> And if we start by pushing new version in update, people will soon
+>> wonder why the new version of X is in updates, while the new version of
+>> Y is not, just because we didn't have X in release and Y was there.
+>
+> Problem I see:
+> So far (in Mandriva), example:  we have used 2010.0/main/backports to
+> offer new versions of software which had an older version in 2010/main
+> but the newer version in 2010.1/main, or as the name says: backporting
+> a newer version of a software from the current release to a previous
+> release, as often used for Firefox.
+>
+> For Mageia it means, /backports should hold backports of software
+> which has an older version in 1/core but a newer version in cauldron.
+> If we put new software (aka missing packages) in /backports and the
+> user activates /backports he also runs the risk that existing packages
+> of his stable installation will be replaced by real backports of newer
+> versions, backported from Cauldron - which he may not want to do.
+>
+> I wonder why we do not put these "missing packages" in /testing and
+> after a while in /core or /non-free or /tainted (wherever they
+> belong). These packages are software which were supposed to be in
+> /core or /non-free or /tainted, they were just forgotten|came too
+> late|whatever for Mageia 1 release freeze.
+>
+
+well, media/*/release tree is frozen, so _nothing_ new goes in there.
+
+So the path would then be */updates_testing -> */updates _if_ we decide
+that's the way to go...
+
+Problem is that a "missing" package introcuced in updates also can 
+introduce regressions with wrong obsoletes/provides or %pre/%post scripts.
+
+So it has to go through the same qa as the rest of the stuff heading for 
+*/updates
+
+So question becomes, do we have enough qa/security people to make it work ?
+
+And if we introduce "filtering" on what goes in and what does not,
+then who decides ?
+
+--
+Thomas
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005340.html b/zarb-ml/mageia-dev/2011-June/005340.html new file mode 100644 index 000000000..c3bef5102 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005340.html @@ -0,0 +1,187 @@ + + + + [Mageia-dev] [RFC] Removing .la files + + + + + + + + + +

[Mageia-dev] [RFC] Removing .la files

+ Dexter Morgan + dmorganec at gmail.com +
+ Fri Jun 10 14:12:54 CEST 2011 +

+
+ +
On Fri, Jun 10, 2011 at 1:51 PM, Olav Vitters <olav at vitters.nl> wrote:
+> On Fri, Jun 10, 2011 at 12:41:46PM +0200, Michael Scherer wrote:
+>> Le vendredi 10 juin 2011 à 03:47 +0300, Ahmad Samir a écrit :
+>> > On 9 June 2011 19:35, Dexter Morgan <dmorganec at gmail.com> wrote:
+>> > > Hello,
+>> > >
+>> > > as other distributions we started to remove .la files from mageia
+>> > > during mageia 1 development.
+>>
+>> Could you explain the rational of removing them ?
+>>
+>> AFAIK, the .la removal was not discussed, so starting by saying "we
+>> remove them now because last time, we didn't discussed and it broke lots
+>> of thing" is a little bit weird.
+>
+> https://live.gnome.org/GnomeShell/RemovingLaFiles
+>
+> Seems some distributions misunderstand the need and changed the wiki
+> page. Removing .la files is needed however, otherwise you'll quickly mix
+> distribution installed libraries and self-compiled libraries.
+>
+> Difficulty is that this only works when you remove *all* .la files. If
+> only one is left compilation is broken.
+> --
+> Regards,
+> Olav
+>
+
+i will try a new way to remove them and btw we maybe should add a
+rpmlint reject to reject packages with la files inside . but not yet
+as we may need to still build some the time of the transition.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005341.html b/zarb-ml/mageia-dev/2011-June/005341.html new file mode 100644 index 000000000..20da8f512 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005341.html @@ -0,0 +1,120 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Frank Griffin + ftg at roadrunner.com +
+ Fri Jun 10 14:16:02 CEST 2011 +

+
+ +
On 06/10/2011 07:44 AM, Dexter Morgan wrote:
+> maybe 1 wait to have gnome 3 and then speak about gnome2
+
+Could you post here when all of the GNOME3 packages are in Cauldron ?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005342.html b/zarb-ml/mageia-dev/2011-June/005342.html new file mode 100644 index 000000000..a05456a5b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005342.html @@ -0,0 +1,126 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Frank Griffin + ftg at roadrunner.com +
+ Fri Jun 10 14:18:15 CEST 2011 +

+
+ +
On 06/10/2011 07:39 AM, Kira wrote:
+> In the past time, there's KDE3 and KDE4 co-exist together in the
+> repository,
+>
+> maybe we can do it again?
+>
+
+Good idea. I'm not much of a KDE user, but I noticed that the DMs
+offered both KDE3 and 4, which seems like a very easy way to switch back
+and forth (if setting it up isn't too much work).
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005343.html b/zarb-ml/mageia-dev/2011-June/005343.html new file mode 100644 index 000000000..205c51d24 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005343.html @@ -0,0 +1,142 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Fri Jun 10 14:21:42 CEST 2011 +

+
+ +
Thomas Backlund <tmb at mageia.org> schrieb am 10.06.2011
+> So the path would then be */updates_testing -> */updates _if_ we
+> decide that's the way to go...
+As I see it, it's the only user friendly way. Using backports is fine 
+for experienced users who do know what to install from backports or 
+who are capable of facing the consequences.
+If a total newbie asks fort a package in the forums and is pointed to 
+backports he is in great danger of wrecking his system by installing 
+some new kernel, graphics driver, desktop or whatever, precisely 
+because there is no real qa on backports.
+
+Oliver
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110610/a16fa5f1/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005344.html b/zarb-ml/mageia-dev/2011-June/005344.html new file mode 100644 index 000000000..390bae027 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005344.html @@ -0,0 +1,223 @@ + + + + [Mageia-dev] Mageia 2 - Improving educational programs + + + + + + + + + +

[Mageia-dev] Mageia 2 - Improving educational programs

+ Daniel Kreuter + daniel.kreuter85 at googlemail.com +
+ Fri Jun 10 14:29:31 CEST 2011 +

+
+ +
On Fri, Jun 10, 2011 at 10:22 AM, Angelo Naselli <anaselli at linux.it> wrote:
+
+> Hi Stefano,
+> > I think is a good task and I will help Angelo.
+> Thanks.
+>
+> > First we need to discuss if develop under KDE or also Gnome (2), taking
+> into
+> > consideration also the old hardware on which usually it's installed.
+> Well I know you and probably what you mean... but it's really hard to
+> understand :)
+>
+> There's nothing to choose in the first two items - well maybe a little bit
+> in
+> the second one :) - I mean importing programs is not related to a specific
+> DE,
+> if that program has been developed using a library more than another it
+> will
+> run better in a DE that is written for that library (e.g. gtk/gnome or
+> qt/kde
+> for instance), but that does not avoid using such a program into other DEs
+> ;)
+>
+> Now let's see if i understood your point, if you mean about live-cd well
+> yes
+> something has to be decided, but that's not a big priority task, i'd like
+> to
+> have a more user friendly installable and with a wide choice system
+> concerning
+> educational programs first.
+> After that we could add more configuration files to draklive implementing
+> one or
+> more specific edu-tasks.
+>
+> WDYT?
+>
+> Cheers,
+>         Angelo
+>
+
+To run the educational programs even on new hardware and on old ones, i
+would propose not to choose kde or gnome. XFCE or LXDE would be a better
+choice i think. But it's only my point of view.
+
+As you mentioned, we don't need to decide that now. At first we need the
+programs than we can decide to create a live-cd out of it.
+
+-- 
+Mit freundlichen Grüßen
+
+Greetings
+
+Daniel Kreuter
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110610/92d2f88b/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005345.html b/zarb-ml/mageia-dev/2011-June/005345.html new file mode 100644 index 000000000..4f35a13bc --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005345.html @@ -0,0 +1,132 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ JA Magallón + jamagallon at ono.com +
+ Fri Jun 10 14:19:49 CEST 2011 +

+
+ +
+On 2011.06.10, at 14:16, Frank Griffin wrote:
+
+> On 06/10/2011 07:44 AM, Dexter Morgan wrote:
+>> maybe 1 wait to have gnome 3 and then speak about gnome2
+> 
+> Could you post here when all of the GNOME3 packages are in Cauldron ?
+
+And perhaps build a task-gnome rpm, so we can get all the dependencies
+for sure ?
+
+--
+J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:
+                                         \         It's better when it's free
+
+
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005346.html b/zarb-ml/mageia-dev/2011-June/005346.html new file mode 100644 index 000000000..cc688343d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005346.html @@ -0,0 +1,301 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Michael Scherer + misc at zarb.org +
+ Fri Jun 10 14:51:51 CEST 2011 +

+
+ +
Le vendredi 10 juin 2011 à 11:44 +0100, Colin Guthrie a écrit :
+> 'Twas brillig, and Michael Scherer at 10/06/11 11:27 did gyre and gimble:
+> > Le jeudi 09 juin 2011 à 10:14 +0100, Colin Guthrie a écrit :
+> >> Hi,
+> >>
+> >> As I upgrade my various machines (I only really have about 5, so not
+> >> that many) I'm running into a few packages that are missing (this is
+> >> inevitable).
+> >>
+> >> Nothing major just little things like trac and supybot etc.
+> >>
+> >> What is the best way to add these packages to the v1 tree?
+> >>
+> >> Using backports seems a little odd as this is "unsupported" and we don't
+> >> really want to encourage using it as a means to get the missing packages.
+> > 
+> > If we do not want to have people use backports, we wouldn't have added
+> > it in the first place.
+> > 
+> > I do think backport is perfectly suited for that.
+> 
+> So the user that just wants to install supybot has to expose themselves
+> to the risk of updating to a backported version of gnome or KDE.... this
+> is hardly ideal. Especially for novice users.
+
+One alternative would be to make sure that backports for version 1 are
+fully supported and break nothing. 
+
+> >> release is obviously frozen so no go there.
+> >>
+> >> The only real option is updates, but that should obviously have some QA
+> >> on it.
+> > 
+> > Updates is not for new version of software, not for new softwares. And
+> > backporting something from cauldron is not a update.
+> 
+> This seems like a strange statement as */updates on mdv was allowed to
+> have new packages in some cases (I've done it before, although I think
+> only for * == contrib), so I don't see why we have to restrict this
+> possibility in Mageia.
+
+contrib/updates was basically not watched at all. People could send
+anything without trouble, and there was no policy ( nor any enforcement
+). That's not really the best example to use :)
+
+
+> >> Perhaps we need to have some kind of exemption to get these missing
+> >> packages added?
+> >>
+> >> Does anyone have any opinions on this?
+> > 
+> > Yes, I do.
+> > 
+> > We have used backports in the past for that, and I see no reason to
+> > change that.
+> 
+> This is fine in the regular course of distro evolution, but here we're
+> talking about users migrating from Mdv to Mga and finding "stale" Mdv
+> packages still installed on their system when they want (and we want to
+> provide) a Mageia version. This is very much a special case for this
+> transitional period but I feel it's an important one, particularly
+> *because* it's the first release.
+
+All releases are equal. And we warned that we would not be able to do
+everything, so of course, we will have problem with those that lived on
+Mars under a rock, but I think that most people know that we couldn't
+have all.
+
+> I think you're thinking in absolute terms rather than transitional
+> terms. In absolute terms I agree with you on principle, but I think we
+> need to deal with transitional issues gracefully and not treat them as
+> second class considerations.
+
+It was not clear for me from your mail that this would be temporary. 
+
+So I assume we can agree to enforce the "new packages go to backports
+unless very specific and defined exceptions" policy for version 2 of the
+release ? 
+
+If this is temporary, it would be ok, provided we follows the usual
+rules about handling updates.
+
+As we do not want to have untested rpms backported in */updates, this
+mean that package must be checked by QA before ( and proper testing for
+a new rpm is more that just checking it doesn't break ). 
+
+So it should follow the proper policy ( once we agreed on that ).
+
+As discussed in the previous thread, that would for example mean that
+the packager that submit the backport is not the one testing it and
+giving the go, even if he can test before submitting to avoid wasting QA
+time.
+
+Since we want to restrict to package that people have used and missed
+for upgrade, I would also add that this part should be checked and
+requires :
+- a bug report saying "upgrade failed due to that"
+- if we want to be inclusive, a forum post could do the trick ( provided
+it is in english, or a bug referencing the forum )
+- package must be kept upgradable from mandriva 2010.1
+- ideally, the upgrade path should be tested, but I am pretty sure that
+people will not :).
+
+Finally, I would also add that as soon a package is in updates or
+release, the usual rules should apply ( ie, no more exception ). If I
+push the package to */updates once getmail because it is missing, but
+the next package do not go to */updates unless it fullfill the usual
+rules. Any following backports goes to */backports. 
+
+And, just to be clear, the policy only apply to version 1, for x86_64
+and i586.
+
+One question would be "what is a pacakge requires a complex backport",
+for example, someone yesterday asked for darcs, that requires ghc, that
+requires bootstrapping. 
+
+Yes, no ? Why ?
+
+> > If the problem is that backports were too buggy in the past, then we
+> > should fix backports process, not bypassing them.
+> 
+> I don't think this is particularly relevant. Backports are unsupported
+> generally. That's a given. 
+
+Before, it was Mandriva that said "we don't support backport", but we
+can do thing differently.
+ 
+We do offer them, we spoke of the application made by Stormi to manage
+backports request ( among others ), and it was asked to install it on
+our servers. So to me, for something unsupported, it seems to be rather
+well integrated.
+
+So the question is "what do people mean exactly when they say "backports
+are unsupported" and what would it change when compared to updates,
+which is supported by definition" ?
+
+Ie, I think we as a community support them to some extend, and so we
+should explain what can people expect, and what they cannot.
+And if possible, in a positive way ( as one issue we had with backport
+was that people kept telling "do not use it", which is why people do not
+use it ).
+
+Ie, I have a backport installed, would I receive new version, or not ?
+I found a bug, can I fill it in bugs.mageia.org, or not ?
+Etc, etc. 
+
+
+> If we encourage people to enable backports to
+> get missing packages (this is very distinct and separate from the
+> unsupported backports).
+
+>From the user point of view, any package he doesn't have is a missing
+packages, be it due to upgrade from mandriva or because it was not
+packaged when he needed :)
+
+
+> > And if we start by pushing new version in update, people will soon
+> > wonder why the new version of X is in updates, while the new version of
+> > Y is not, just because we didn't have X in release and Y was there.
+> 
+> I very much consider "nothing -> version X" quite different from
+> "version X -> version Y". I don't think it's a hard concept for anyone
+> to grasp.
+
+We kept telling to people that we do not want to place new version in
+update, and if we start to do the contrary, this is not really coherent.
+
+So while this can be justified, I think we should take in account
+communication with users to clearly explain why we do, and why this is
+temporary.
+
+I guess a blog post would do the trick, so would you be volunteer for
+that if needed ?
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005347.html b/zarb-ml/mageia-dev/2011-June/005347.html new file mode 100644 index 000000000..4ef8d2096 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005347.html @@ -0,0 +1,144 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Michael Scherer + misc at zarb.org +
+ Fri Jun 10 14:54:34 CEST 2011 +

+
+ +
Le vendredi 10 juin 2011 à 14:21 +0200, Oliver Burger a écrit :
+> Thomas Backlund <tmb at mageia.org> schrieb am 10.06.2011
+> > So the path would then be */updates_testing -> */updates _if_ we
+> > decide that's the way to go...
+> As I see it, it's the only user friendly way. Using backports is fine 
+> for experienced users who do know what to install from backports or 
+> who are capable of facing the consequences.
+> If a total newbie asks fort a package in the forums and is pointed to 
+> backports he is in great danger of wrecking his system by installing 
+> some new kernel, graphics driver, desktop or whatever, precisely 
+> because there is no real qa on backports.
+
+He can also wait for the release. Or he can enable backport just for the
+time needed to install and then disable it. I think rpmdrake have some
+stuff for that.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005348.html b/zarb-ml/mageia-dev/2011-June/005348.html new file mode 100644 index 000000000..8742c2ec7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005348.html @@ -0,0 +1,236 @@ + + + + [Mageia-dev] perl 5.14.0 should arrive soon + + + + + + + + + +

[Mageia-dev] perl 5.14.0 should arrive soon

+ Jerome Quelin + jquelin at gmail.com +
+ Fri Jun 10 14:59:29 CEST 2011 +

+
+ +
hi,
+
+perl 5.14.0 should arrive soon. it compiles fine on both i586 & x86_64,
+and it seem we fixed the only problem arisen in perl-URPM.
+
+since other packages need to be rebuilt in the same loop, and given that
+urpmi is written in perl, it needs a special treatment to bypass the
+regular bs upload.
+
+blino will likely do this magic dance & upload them in the coming hours -
+you may want to wait till his final go before updating your cauldron
+box.
+
+once this is done, it's still not time to update the perl modules to
+their latest version: binary perl modules need to be rebuilt against
+perl 5.14. to get the list:
+
+    $ urpmf --requires :perlapi-5.12 | cut -d: -f1 | sort -u
+
+there are 364 of them at the time of speaking. and of course some of
+them need to be rebuilt before others. [0]
+
+==>  help is welcome to rebuild them [1]
+
+to rebuild one of those binary packages:
+    1- wait for blino to announce perl 5.14.0 availability
+    2- check out the package
+    3- bump mkrel in package spec file
+    4- mgarepo submit
+    5- if build fails on bs, then it's likely that a missing binary
+       module is missing: proceed the missing package
+
+thanks,
+jérôme 
+
+[0] note to self: i'll create a "magpie sort" command to order those...
+but it's a bit too late for now. it'll be ready for perl 5.16 in one
+year! :-)
+[1] i should not be able to work on it this week-end, so feel free to
+give it a try.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005349.html b/zarb-ml/mageia-dev/2011-June/005349.html new file mode 100644 index 000000000..93960bfcd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005349.html @@ -0,0 +1,145 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Michael Scherer + misc at zarb.org +
+ Fri Jun 10 14:59:58 CEST 2011 +

+
+ +
Le vendredi 10 juin 2011 à 07:20 -0400, Frank Griffin a écrit :
+> On 06/10/2011 06:46 AM, Michael Scherer wrote:
+> > While I have no issue with gnome-shell, I have read enough reports of
+> > people not happy with it to know we would head to a 2nd kde 4.0 story.
+> > So maybe we could start to learn from the past and discuss with users to
+> > explain the update, see why they do not want etc, instead of being
+> > purely focused on "it is cauldron, let's update everything".
+> +1
+> 
+> 3 is rumored to have a lot of ideological change, and probably the usual 
+> GNOME removal of working stuff that people expect to be there (GDM 
+> config).
+
+The gdm config is more a missing feature due to rewrite not finished
+than a removal. I am running gnome 3 since 1 month, and I didn't even
+used a extension to change anything. 
+
+My main issue is more that not everything is finished ( like I miss the
+timezone clock stuff to see when to call on USAs and rest of Europa )
+
+And again, most changes in gnome-shell are justified in the light of
+newer computing experiences ( tablet, touchscreen ) but whatever people
+do, there is a transition period. There is a few discutable decision
+( the alt key to poweroff being the one ) but I think there isn't much,
+when compared to the others good changes.
+
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005350.html b/zarb-ml/mageia-dev/2011-June/005350.html new file mode 100644 index 000000000..a74ab14d7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005350.html @@ -0,0 +1,165 @@ + + + + [Mageia-dev] [RFC] Removing .la files + + + + + + + + + +

[Mageia-dev] [RFC] Removing .la files

+ Michael Scherer + misc at zarb.org +
+ Fri Jun 10 15:05:23 CEST 2011 +

+
+ +
Le vendredi 10 juin 2011 à 14:12 +0200, Dexter Morgan a écrit :
+> On Fri, Jun 10, 2011 at 1:51 PM, Olav Vitters <olav at vitters.nl> wrote:
+
+> 
+> i will try a new way to remove them and btw we maybe should add a
+> rpmlint reject to reject packages with la files inside . but not yet
+> as we may need to still build some the time of the transition.
+
+Better do like gentoo and debian, and remove them on build time.
+( like we strip binary, etc )
+
+( yes, that mean more work to you as the rpm maintainer than me as
+rpmlint maintainer :)  )
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005351.html b/zarb-ml/mageia-dev/2011-June/005351.html new file mode 100644 index 000000000..20c22b17a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005351.html @@ -0,0 +1,123 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Olav Vitters + olav at vitters.nl +
+ Fri Jun 10 15:11:36 CEST 2011 +

+
+ +
On Fri, Jun 10, 2011 at 02:59:58PM +0200, Michael Scherer wrote:
+> My main issue is more that not everything is finished ( like I miss the
+> timezone clock stuff to see when to call on USAs and rest of Europa )
+
+That's planned for 3.2 btw.
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005352.html b/zarb-ml/mageia-dev/2011-June/005352.html new file mode 100644 index 000000000..a8834b69f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005352.html @@ -0,0 +1,129 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Dexter Morgan + dmorganec at gmail.com +
+ Fri Jun 10 15:17:10 CEST 2011 +

+
+ +
On Fri, Jun 10, 2011 at 3:11 PM, Olav Vitters <olav at vitters.nl> wrote:
+> On Fri, Jun 10, 2011 at 02:59:58PM +0200, Michael Scherer wrote:
+>> My main issue is more that not everything is finished ( like I miss the
+>> timezone clock stuff to see when to call on USAs and rest of Europa )
+>
+> That's planned for 3.2 btw.
+> --
+> Regards,
+> Olav
+>
+
+which is planned for october iirc no ?
+
+so good for mageia 2 :)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005353.html b/zarb-ml/mageia-dev/2011-June/005353.html new file mode 100644 index 000000000..a8a003c29 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005353.html @@ -0,0 +1,134 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Olav Vitters + olav at vitters.nl +
+ Fri Jun 10 15:26:53 CEST 2011 +

+
+ +
On Fri, Jun 10, 2011 at 03:17:10PM +0200, Dexter Morgan wrote:
+> On Fri, Jun 10, 2011 at 3:11 PM, Olav Vitters <olav at vitters.nl> wrote:
+> > On Fri, Jun 10, 2011 at 02:59:58PM +0200, Michael Scherer wrote:
+> >> My main issue is more that not everything is finished ( like I miss the
+> >> timezone clock stuff to see when to call on USAs and rest of Europa )
+> >
+> > That's planned for 3.2 btw.
+> 
+> which is planned for october iirc no ?
+
+Yes (Sep 28), see www.gnome.org/start/unstable (standard link for the
+current schedule)
+
+> so good for mageia 2 :)
+
+Indeed :)
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005354.html b/zarb-ml/mageia-dev/2011-June/005354.html new file mode 100644 index 000000000..76e931444 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005354.html @@ -0,0 +1,167 @@ + + + + [Mageia-dev] Supybot rpms rebuilt on mageia + + + + + + + + + +

[Mageia-dev] Supybot rpms rebuilt on mageia

+ Michael Scherer + misc at zarb.org +
+ Fri Jun 10 15:29:11 CEST 2011 +

+
+ +
Le jeudi 09 juin 2011 à 15:40 -0400, Lee a écrit :
+> I was asked to look into supybot and meetbot to work on patches an 
+> fixes. First things first I had to rebuild rpms for my mageia 1 system 
+> (i586). I built the following from src rpms:
+> 
+> supybot-0.83.4.1-1.mga1.noarch.rpm
+> supybot-Dcc-0.83.4.1-1.mga1.noarch.rpm
+> supybot-ExternalNotice-0.83.4.1-1.mga1.noarch.rpm
+> supybot-Gateway-0.83.4.1-1.mga1.noarch.rpm
+> supybot-Meetbot-0.1.4-2.mga1.noarch.rpm
+> supybot-Sshd-0.83.4.1-1.mga1.noarch.rpm
+> supybot-Webserver-0.83.4.1-1.mga1.noarch.rpm
+> 
+> I don't have a mentor, I'm not a packager, and nobody so far has ported 
+> these packages over. And the ones I have here haven't been officially 
+> 'cleansed' but they work. Not sure how to move forward from here.
+
+I will import them ( was on my todo list, as that's why I done the
+supybot meetbot plugin rpm ).
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005355.html b/zarb-ml/mageia-dev/2011-June/005355.html new file mode 100644 index 000000000..105a60be2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005355.html @@ -0,0 +1,186 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Marc Paré + marc at marcpare.com +
+ Fri Jun 10 16:08:10 CEST 2011 +

+
+ +
Le 2011-06-09 19:56, Barry Jackson a écrit :
+> I have been working on a package to install Skype current stable release
+> and now feel that it is ready for submission for approval.
+>
+> It has already been improved/corrected/adapted many times following
+> discussions on #mageia-mentoring where I have been given lots of help.
+>
+> The idea evolved here https://bugs.mageia.org/show_bug.cgi?id=154
+> where the current version is available as an attachment.
+> https://bugs.mageia.org/attachment.cgi?id=551
+>
+> It has been a challenge and I have learned a lot in working on this. :)
+>
+> Barry
+>
+
+Hi Barry
+
+Thanks for doing this. I uncompressed the file. What is the difference 
+between the 2 .rpms? You may want to include a "readme" in the package 
+for people like me.
+
+Cheers
+
+Marc
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005356.html b/zarb-ml/mageia-dev/2011-June/005356.html new file mode 100644 index 000000000..79e2289d8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005356.html @@ -0,0 +1,146 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ James Kerr + jim at jkerr82508.free-online.co.uk +
+ Fri Jun 10 16:09:57 CEST 2011 +

+
+ +
On 10/06/11 13:54, Michael Scherer wrote:
+> Le vendredi 10 juin 2011 à 14:21 +0200, Oliver Burger a écrit :
+>> Thomas Backlund<tmb at mageia.org>  schrieb am 10.06.2011
+>>> So the path would then be */updates_testing ->  */updates _if_ we
+>>> decide that's the way to go...
+>> As I see it, it's the only user friendly way. Using backports is fine
+>> for experienced users who do know what to install from backports or
+>> who are capable of facing the consequences.
+>> If a total newbie asks fort a package in the forums and is pointed to
+>> backports he is in great danger of wrecking his system by installing
+>> some new kernel, graphics driver, desktop or whatever, precisely
+>> because there is no real qa on backports.
+>
+> He can also wait for the release. Or he can enable backport just for the
+> time needed to install and then disable it. I think rpmdrake have some
+> stuff for that.
+>
+
+Even though backports are disabled rpmdrake can display a list of 
+available backports. (The sources are automatically updated by 
+mgaonline.) A selected backport can then be installed, without enabling 
+the backports source. (I've just tested this on mdv 2010.0, the only mdv 
+system that I have available.)
+
+Jim
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005357.html b/zarb-ml/mageia-dev/2011-June/005357.html new file mode 100644 index 000000000..6ff4d7e83 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005357.html @@ -0,0 +1,182 @@ + + + + [Mageia-dev] [RFC] Removing .la files + + + + + + + + + +

[Mageia-dev] [RFC] Removing .la files

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Fri Jun 10 16:15:01 CEST 2011 +

+
+ +
On Fri, 10 Jun 2011, Olav Vitters wrote:
+
+> On Fri, Jun 10, 2011 at 12:41:46PM +0200, Michael Scherer wrote:
+>> Le vendredi 10 juin 2011 à 03:47 +0300, Ahmad Samir a écrit :
+>>> On 9 June 2011 19:35, Dexter Morgan <dmorganec at gmail.com> wrote:
+>>>> Hello,
+>>>>
+>>>> as other distributions we started to remove .la files from mageia
+>>>> during mageia 1 development.
+>>
+>> Could you explain the rational of removing them ?
+>>
+>> AFAIK, the .la removal was not discussed, so starting by saying "we
+>> remove them now because last time, we didn't discussed and it broke lots
+>> of thing" is a little bit weird.
+>
+> https://live.gnome.org/GnomeShell/RemovingLaFiles
+
+"... but the dirty hacks that jhbuild plays ..."
+
+Problems with dirty hacks are NOT a valid reason to remove libtool 
+convenience libraries aka .la files.
+
+> Seems some distributions misunderstand the need and changed the wiki
+> page. Removing .la files is needed however, otherwise you'll quickly mix
+> distribution installed libraries and self-compiled libraries.
+
+What are you talking about here?
+
+> Difficulty is that this only works when you remove *all* .la files. If
+> only one is left compilation is broken.
+
+It is more likely that your build system is broken. If you do not want to 
+link against system libraries, remove /lib and /usr/lib from the library 
+search dirs list.
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005358.html b/zarb-ml/mageia-dev/2011-June/005358.html new file mode 100644 index 000000000..8f049801c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005358.html @@ -0,0 +1,184 @@ + + + + [Mageia-dev] [RFC] Removing .la files + + + + + + + + + +

[Mageia-dev] [RFC] Removing .la files

+ Olav Vitters + olav at vitters.nl +
+ Fri Jun 10 16:26:35 CEST 2011 +

+
+ +
On Fri, Jun 10, 2011 at 04:15:01PM +0200, Christiaan Welvaart wrote:
+> >https://live.gnome.org/GnomeShell/RemovingLaFiles
+> 
+> "... but the dirty hacks that jhbuild plays ..."
+> 
+> Problems with dirty hacks are NOT a valid reason to remove libtool
+> convenience libraries aka .la files.
+
+Seems you skipped the initial bit, where it explains that the .la has
+the full path.
+
+> >Seems some distributions misunderstand the need and changed the wiki
+> >page. Removing .la files is needed however, otherwise you'll quickly mix
+> >distribution installed libraries and self-compiled libraries.
+> 
+> What are you talking about here?
+
+"The particular problem with these .la files is that they have hardcoded
+paths in them. So, for example, if /usr/lib/libgnome-menu.so just
+contains the information that it requires libglib-2.0.so.0 but
+/usr/lib/libgnome-menu.la says that it wants /usr/lib/libglib-2.0.la, it
+causes libtool to link against /usr/lib/libglib-2.0.so at link time.
+This is fine for a lot of typical build scenarios, but the dirty hacks
+that jhbuild plays to get it to sandbox your system understandably
+breaks. "
+
+> >Difficulty is that this only works when you remove *all* .la files. If
+> >only one is left compilation is broken.
+> 
+> It is more likely that your build system is broken. If you do not
+> want to link against system libraries, remove /lib and /usr/lib from
+> the library search dirs list.
+
+That's not enough, the .la files add libraries in /lib and /usr/lib.
+
+Fedora has for instance already removed the .la files. Other
+distributions are working on it (even Debian).
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005359.html b/zarb-ml/mageia-dev/2011-June/005359.html new file mode 100644 index 000000000..239c5c682 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005359.html @@ -0,0 +1,155 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ James Kerr + jim at jkerr82508.free-online.co.uk +
+ Fri Jun 10 16:27:19 CEST 2011 +

+
+ +
On 10/06/11 15:09, James Kerr wrote:
+> On 10/06/11 13:54, Michael Scherer wrote:
+>> Le vendredi 10 juin 2011 à 14:21 +0200, Oliver Burger a écrit :
+>>> Thomas Backlund<tmb at mageia.org> schrieb am 10.06.2011
+>>>> So the path would then be */updates_testing -> */updates _if_ we
+>>>> decide that's the way to go...
+>>> As I see it, it's the only user friendly way. Using backports is fine
+>>> for experienced users who do know what to install from backports or
+>>> who are capable of facing the consequences.
+>>> If a total newbie asks fort a package in the forums and is pointed to
+>>> backports he is in great danger of wrecking his system by installing
+>>> some new kernel, graphics driver, desktop or whatever, precisely
+>>> because there is no real qa on backports.
+>>
+>> He can also wait for the release. Or he can enable backport just for the
+>> time needed to install and then disable it. I think rpmdrake have some
+>> stuff for that.
+>>
+>
+> Even though backports are disabled rpmdrake can display a list of
+> available backports. (The sources are automatically updated by
+> mgaonline.) A selected backport can then be installed, without enabling
+> the backports source. (I've just tested this on mdv 2010.0, the only mdv
+> system that I have available.)
+>
+
+I've just realised there is a potential problem with this. Because 
+Mageia has /backports_testing repo's (mdv does not) packages from 
+/backports_testing may also be displayed. Mgaonline is updating those 
+sources.
+
+Jim
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005360.html b/zarb-ml/mageia-dev/2011-June/005360.html new file mode 100644 index 000000000..7b8a0c9a5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005360.html @@ -0,0 +1,145 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Fri Jun 10 16:27:28 CEST 2011 +

+
+ +
James Kerr <jim at jkerr82508.free-online.co.uk> schrieb am 10.06.2011
+> Even though backports are disabled rpmdrake can display a list of
+> available backports. (The sources are automatically updated by
+> mgaonline.)
+I make you parden, but: no!
+
+When a repo is disabled it doesn't get updated automatically and its 
+packages are not to be found in rpmdrake.
+Did you confuse "disabling repos" and "marking a repo for updates" 
+(sorry, me doesn't know the exact English strings).
+
+
+So you have to enable the backports repos and even though you don't 
+"mark them as update repos", urpmi will ignore that (rpmdrake won't 
+but urpmi will) and will update everything from those repos...
+
+Oliver
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110610/652f3c76/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005361.html b/zarb-ml/mageia-dev/2011-June/005361.html new file mode 100644 index 000000000..ebffb6872 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005361.html @@ -0,0 +1,172 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Thorsten van Lil + tvl83 at gmx.de +
+ Fri Jun 10 16:28:52 CEST 2011 +

+
+ +
Am 10.06.2011 16:09, schrieb James Kerr:
+> On 10/06/11 13:54, Michael Scherer wrote:
+>> Le vendredi 10 juin 2011 à 14:21 +0200, Oliver Burger a écrit :
+>>> Thomas Backlund<tmb at mageia.org> schrieb am 10.06.2011
+>>>> So the path would then be */updates_testing -> */updates _if_ we
+>>>> decide that's the way to go...
+>>> As I see it, it's the only user friendly way. Using backports is fine
+>>> for experienced users who do know what to install from backports or
+>>> who are capable of facing the consequences.
+>>> If a total newbie asks fort a package in the forums and is pointed to
+>>> backports he is in great danger of wrecking his system by installing
+>>> some new kernel, graphics driver, desktop or whatever, precisely
+>>> because there is no real qa on backports.
+>>
+>> He can also wait for the release. Or he can enable backport just for the
+>> time needed to install and then disable it. I think rpmdrake have some
+>> stuff for that.
+>>
+>
+> Even though backports are disabled rpmdrake can display a list of
+> available backports. (The sources are automatically updated by
+> mgaonline.) A selected backport can then be installed, without enabling
+> the backports source. (I've just tested this on mdv 2010.0, the only mdv
+> system that I have available.)
+>
+> Jim
+>
+
+I've tested it on Mageia right now. I've activated Core-testing and see 
+that there is one package inside it: iputils_20101006_3.mga1. After that 
+I've disabled the testing repo and searched for iputils. Rpmdrake lists 
+me the version 2.mga1. Therefore, rpmdrake only lists packages of the 
+activated repos.
+
+Greetings,
+Thorsten
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005362.html b/zarb-ml/mageia-dev/2011-June/005362.html new file mode 100644 index 000000000..b66b66173 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005362.html @@ -0,0 +1,171 @@ + + + + [Mageia-dev] [RFC] Removing .la files + + + + + + + + + +

[Mageia-dev] [RFC] Removing .la files

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Fri Jun 10 16:35:57 CEST 2011 +

+
+ +
On Fri, 10 Jun 2011, Olav Vitters wrote:
+
+> On Fri, Jun 10, 2011 at 04:15:01PM +0200, Christiaan Welvaart wrote:
+>>> https://live.gnome.org/GnomeShell/RemovingLaFiles
+>>
+>> "... but the dirty hacks that jhbuild plays ..."
+>>
+>> Problems with dirty hacks are NOT a valid reason to remove libtool
+>> convenience libraries aka .la files.
+>
+> Seems you skipped the initial bit, where it explains that the .la has
+> the full path.
+
+What's wrong with those paths? I'm saying the problem is in gnome-shell, 
+not in the .la files.
+
+>>> Seems some distributions misunderstand the need and changed the wiki
+>>> page. Removing .la files is needed however, otherwise you'll quickly mix
+>>> distribution installed libraries and self-compiled libraries.
+>>
+>> What are you talking about here?
+
+<gnome-shell stuff>
+
+So you are really talking only about gnome-shell, which I can't even test 
+because apparently it doesn't work in a VM. It is now packaged, so you 
+don't need to build it.
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005363.html b/zarb-ml/mageia-dev/2011-June/005363.html new file mode 100644 index 000000000..8b3c70c6a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005363.html @@ -0,0 +1,150 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ James Kerr + jim at jkerr82508.free-online.co.uk +
+ Fri Jun 10 16:46:17 CEST 2011 +

+
+ +
On 10/06/11 15:27, Oliver Burger wrote:
+> James Kerr<jim at jkerr82508.free-online.co.uk>  schrieb am 10.06.2011
+>> Even though backports are disabled rpmdrake can display a list of
+>> available backports. (The sources are automatically updated by
+>> mgaonline.)
+> I make you parden, but: no!
+>
+> When a repo is disabled it doesn't get updated automatically and its
+> packages are not to be found in rpmdrake.
+> Did you confuse "disabling repos" and "marking a repo for updates"
+> (sorry, me doesn't know the exact English strings).
+>
+>
+> So you have to enable the backports repos and even though you don't
+> "mark them as update repos", urpmi will ignore that (rpmdrake won't
+> but urpmi will) and will update everything from those repos...
+>
+
+I meant exactly what I wrote. Select Backports from the first filter in 
+rpmdrake and packages from disabled backports sources will be displayed.
+
+Check /var/log/auth.log to see what mgaonline is doing.
+
+Jim
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005364.html b/zarb-ml/mageia-dev/2011-June/005364.html new file mode 100644 index 000000000..50787d543 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005364.html @@ -0,0 +1,314 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Fri Jun 10 16:46:47 CEST 2011 +

+
+ +
'Twas brillig, and Michael Scherer at 10/06/11 13:51 did gyre and gimble:
+> Le vendredi 10 juin 2011 à 11:44 +0100, Colin Guthrie a écrit :
+>> So the user that just wants to install supybot has to expose themselves
+>> to the risk of updating to a backported version of gnome or KDE.... this
+>> is hardly ideal. Especially for novice users.
+> 
+> One alternative would be to make sure that backports for version 1 are
+> fully supported and break nothing. 
+
+That's certainly worth considering.
+
+>> This seems like a strange statement as */updates on mdv was allowed to
+>> have new packages in some cases (I've done it before, although I think
+>> only for * == contrib), so I don't see why we have to restrict this
+>> possibility in Mageia.
+> 
+> contrib/updates was basically not watched at all. People could send
+> anything without trouble, and there was no policy ( nor any enforcement
+> ). That's not really the best example to use :)
+
+Hmm, I can't really disagree with that statement :D
+
+>>> We have used backports in the past for that, and I see no reason to
+>>> change that.
+>>
+>> This is fine in the regular course of distro evolution, but here we're
+>> talking about users migrating from Mdv to Mga and finding "stale" Mdv
+>> packages still installed on their system when they want (and we want to
+>> provide) a Mageia version. This is very much a special case for this
+>> transitional period but I feel it's an important one, particularly
+>> *because* it's the first release.
+> 
+> All releases are equal. And we warned that we would not be able to do
+> everything, so of course, we will have problem with those that lived on
+> Mars under a rock, but I think that most people know that we couldn't
+> have all.
+
+Quite. But if the only reason for not providing a particular service or
+offering is due to a policy (i.e. people want to provide and others want
+to consume) then it's perhaps the policy that need re-evaluating. Just
+because it's policy, doesn't mean it's the best solution. Pragmatism
+often solves a lot of problems. As I said before I think we can easily
+over analyse things...
+
+>> I think you're thinking in absolute terms rather than transitional
+>> terms. In absolute terms I agree with you on principle, but I think we
+>> need to deal with transitional issues gracefully and not treat them as
+>> second class considerations.
+> 
+> It was not clear for me from your mail that this would be temporary. 
+> 
+> So I assume we can agree to enforce the "new packages go to backports
+> unless very specific and defined exceptions" policy for version 2 of the
+> release ? 
+
+Yeah I'd personally be more than happy with that.
+
+> If this is temporary, it would be ok, provided we follows the usual
+> rules about handling updates.
+> 
+> As we do not want to have untested rpms backported in */updates, this
+> mean that package must be checked by QA before ( and proper testing for
+> a new rpm is more that just checking it doesn't break ). 
+> 
+> So it should follow the proper policy ( once we agreed on that ).
+> 
+> As discussed in the previous thread, that would for example mean that
+> the packager that submit the backport is not the one testing it and
+> giving the go, even if he can test before submitting to avoid wasting QA
+> time.
+
+That all seems reasonable to me (although I think the QA people can also
+be a bit "fast and loose" with some requests (obviously at their own
+discretion) - e.g. I doubt they really need to massively test the impact
+to other packages of adding something like dd_rescue, more just test
+that it "runs OK")
+
+> Since we want to restrict to package that people have used and missed
+> for upgrade, I would also add that this part should be checked and
+> requires :
+> - a bug report saying "upgrade failed due to that"
+> - if we want to be inclusive, a forum post could do the trick ( provided
+> it is in english, or a bug referencing the forum )
+> - package must be kept upgradable from mandriva 2010.1
+> - ideally, the upgrade path should be tested, but I am pretty sure that
+> people will not :).
+
+Yeah I agree to that. I think that while you're right about testing the
+upgrade and that it will likely not be fully tested, we can still do a
+"what version does mdv 2010.2 have?, what version do we have? Will it
+upgrade?" conceptual test (i.e. ask the questions!) which should cover
+98.23% of the cases). (made up stat obviously!)
+
+
+> Finally, I would also add that as soon a package is in updates or
+> release, the usual rules should apply ( ie, no more exception ). If I
+> push the package to */updates once getmail because it is missing, but
+> the next package do not go to */updates unless it fullfill the usual
+> rules. Any following backports goes to */backports. 
+
+Makes sense yes.
+
+
+> And, just to be clear, the policy only apply to version 1, for x86_64
+> and i586.
+
+WFM.
+
+> One question would be "what is a pacakge requires a complex backport",
+> for example, someone yesterday asked for darcs, that requires ghc, that
+> requires bootstrapping. 
+> 
+> Yes, no ? Why ?
+
+If this kind of thing crops up, I think we can discuss it at the time.
+As we will have to go through QA process anyway (albeit fast tracked)
+there will have to be some packager<->QA interaction anyway.
+
+
+>>> If the problem is that backports were too buggy in the past, then we
+>>> should fix backports process, not bypassing them.
+>>
+>> I don't think this is particularly relevant. Backports are unsupported
+>> generally. That's a given. 
+> 
+> Before, it was Mandriva that said "we don't support backport", but we
+> can do thing differently.
+
+True...
+
+> We do offer them, we spoke of the application made by Stormi to manage
+> backports request ( among others ), and it was asked to install it on
+> our servers. So to me, for something unsupported, it seems to be rather
+> well integrated.
+
+Well we didn't purposefully break backports before either, and of course
+some people did look after it nicely. Just because it's not actively
+supported doesn't necessarily mean it's not well integrated either. They
+are not mutually exclusive.
+
+> So the question is "what do people mean exactly when they say "backports
+> are unsupported" and what would it change when compared to updates,
+> which is supported by definition" ?
+> 
+> Ie, I think we as a community support them to some extend, and so we
+> should explain what can people expect, and what they cannot.
+> And if possible, in a positive way ( as one issue we had with backport
+> was that people kept telling "do not use it", which is why people do not
+> use it ).
+> 
+> Ie, I have a backport installed, would I receive new version, or not ?
+> I found a bug, can I fill it in bugs.mageia.org, or not ?
+> Etc, etc. 
+
+Yes, this makes sense.
+
+
+>>> And if we start by pushing new version in update, people will soon
+>>> wonder why the new version of X is in updates, while the new version of
+>>> Y is not, just because we didn't have X in release and Y was there.
+>>
+>> I very much consider "nothing -> version X" quite different from
+>> "version X -> version Y". I don't think it's a hard concept for anyone
+>> to grasp.
+> 
+> We kept telling to people that we do not want to place new version in
+> update, and if we start to do the contrary, this is not really coherent.
+> 
+> So while this can be justified, I think we should take in account
+> communication with users to clearly explain why we do, and why this is
+> temporary.
+> 
+> I guess a blog post would do the trick, so would you be volunteer for
+> that if needed ?
+
+If required yeah I can write up the outcome of this once the dust has
+settled :)
+
+Cheers as always.
+
+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-June/005365.html b/zarb-ml/mageia-dev/2011-June/005365.html new file mode 100644 index 000000000..ec75262ef --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005365.html @@ -0,0 +1,192 @@ + + + + [Mageia-dev] [RFC] Removing .la files + + + + + + + + + +

[Mageia-dev] [RFC] Removing .la files

+ Olav Vitters + olav at vitters.nl +
+ Fri Jun 10 17:09:51 CEST 2011 +

+
+ +
On Fri, Jun 10, 2011 at 04:35:57PM +0200, Christiaan Welvaart wrote:
+> On Fri, 10 Jun 2011, Olav Vitters wrote:
+> 
+> >On Fri, Jun 10, 2011 at 04:15:01PM +0200, Christiaan Welvaart wrote:
+> >>>https://live.gnome.org/GnomeShell/RemovingLaFiles
+> >>
+> >>"... but the dirty hacks that jhbuild plays ..."
+> >>
+> >>Problems with dirty hacks are NOT a valid reason to remove libtool
+> >>convenience libraries aka .la files.
+> >
+> >Seems you skipped the initial bit, where it explains that the .la has
+> >the full path.
+> 
+> What's wrong with those paths? I'm saying the problem is in
+> gnome-shell, not in the .la files.
+
+You snipped the paragraph which explains it.
+
+To repeat: If you link against 1 system lib, the .la files will make it
+link to /usr/lib stuff, instead of the self compiled gtk or anything
+like that. If the .la does not exist (all of them), it links correctly.
+
+> >>>Seems some distributions misunderstand the need and changed the wiki
+> >>>page. Removing .la files is needed however, otherwise you'll quickly mix
+> >>>distribution installed libraries and self-compiled libraries.
+> >>
+> >>What are you talking about here?
+> 
+> <gnome-shell stuff>
+
+It is not gnome-shell, it is jhbuild and doing development (mainly
+GNOME). Basic GNOME already has ~200 modules.
+
+> So you are really talking only about gnome-shell, which I can't even
+> test because apparently it doesn't work in a VM. It is now packaged,
+> so you don't need to build it.
+
+Nope, I'm talking about doing development using jhbuild. E.g. if you
+want to contribute to GNOME, you'll have to get rid of all the .la
+files no matter which distribution you use.
+
+A new GNOME does not happen automatically. It requires people to compile
+the Git versions and committing stuff until a tarball is released and
+packaged.
+
+Making such development easier would result in a better GNOME, and I
+don't mind if the .la files stay, but prefer if they are removed.
+
+Jhbuild is also used by Wayland and Hildon btw.
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005366.html b/zarb-ml/mageia-dev/2011-June/005366.html new file mode 100644 index 000000000..2ce2968c2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005366.html @@ -0,0 +1,169 @@ + + + + [Mageia-dev] Mageia 2 - Improving educational programs + + + + + + + + + +

[Mageia-dev] Mageia 2 - Improving educational programs

+ Angelo Naselli + anaselli at linux.it +
+ Fri Jun 10 17:12:23 CEST 2011 +

+
+ +
venerdì 10 giugno 2011 alle 14:29, Daniel Kreuter ha scritto:
+> To run the educational programs even on new hardware and on old ones, i
+> would propose not to choose kde or gnome. XFCE or LXDE would be a better
+> choice i think. But it's only my point of view.
+That's the idea. I started build a lxde live-cd adding task-edu to see
+how big the image was... well i believe i should do a better configuration
+even if it's not so bigger than 800 Mb...
+
+> As you mentioned, we don't need to decide that now. At first we need the
+> programs than we can decide to create a live-cd out of it.
+Yes we need to work to make life easier to those of whom want install
+educational programs in mageia, then we can go on on this subject 
+-imho of course- :)
+
+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/20110610/e3b271e1/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005367.html b/zarb-ml/mageia-dev/2011-June/005367.html new file mode 100644 index 000000000..ad76798f2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005367.html @@ -0,0 +1,166 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Michael Scherer + misc at zarb.org +
+ Fri Jun 10 17:18:54 CEST 2011 +

+
+ +
Le vendredi 10 juin 2011 à 16:27 +0200, Oliver Burger a écrit :
+> James Kerr <jim at jkerr82508.free-online.co.uk> schrieb am 10.06.2011
+> > Even though backports are disabled rpmdrake can display a list of
+> > available backports. (The sources are automatically updated by
+> > mgaonline.)
+> I make you parden, but: no!
+> 
+> When a repo is disabled it doesn't get updated automatically and its 
+> packages are not to be found in rpmdrake.
+> Did you confuse "disabling repos" and "marking a repo for updates" 
+> (sorry, me doesn't know the exact English strings).
+> 
+> 
+> So you have to enable the backports repos and even though you don't 
+> "mark them as update repos", urpmi will ignore that (rpmdrake won't 
+> but urpmi will) and will update everything from those repos...
+
+UI wise, I think it would make sense to have that ( even if a idea is
+not sufficient, and we need a patch ) :
+
+User search for a package, he should see the latest recommended version
+( ie, release/updates ). 
+
+If he say "also provides newer versions", then we could show backports,
+with some indication that we provides a tested version, and a
+potentially newer ones. 
+
+We can agree that everybody want something newer for some rpms, but few
+people want everything to be newer ( ie, now one run backports as a
+update media, I think ). So as much as I am against asking to users
+questions, we must show them the choice somewhere, in a non obstrusive
+way. 
+
+And for testing integration, I think we could have a different workflow,
+maybe something linked to a bug reporting tool. I have a bug on kde and
+use some custom bug reporting tool, the tools notice that something
+could be tested, and say to the user "we have a update candidate, do you
+want to test ? If unsure, say no" ?
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005368.html b/zarb-ml/mageia-dev/2011-June/005368.html new file mode 100644 index 000000000..3839cccbd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005368.html @@ -0,0 +1,149 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Fri Jun 10 17:30:12 CEST 2011 +

+
+ +
Op vrijdag 10 juni 2011 17:18:54 schreef Michael Scherer:
+[...]
+> UI wise, I think it would make sense to have that ( even if a idea is
+> not sufficient, and we need a patch ) :
+> 
+> User search for a package, he should see the latest recommended version
+> ( ie, release/updates ).
+> 
+> If he say "also provides newer versions", then we could show backports,
+> with some indication that we provides a tested version, and a
+> potentially newer ones.
+> 
+> We can agree that everybody want something newer for some rpms, but few
+> people want everything to be newer ( ie, now one run backports as a
+> update media, I think ). So as much as I am against asking to users
+> questions, we must show them the choice somewhere, in a non obstrusive
+> way.
+> 
+> And for testing integration, I think we could have a different workflow,
+> maybe something linked to a bug reporting tool. I have a bug on kde and
+> use some custom bug reporting tool, the tools notice that something
+> could be tested, and say to the user "we have a update candidate, do you
+> want to test ? If unsure, say no" ?
+
++1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005369.html b/zarb-ml/mageia-dev/2011-June/005369.html new file mode 100644 index 000000000..8655393dd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005369.html @@ -0,0 +1,186 @@ + + + + [Mageia-dev] [RFC] Removing .la files + + + + + + + + + +

[Mageia-dev] [RFC] Removing .la files

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Fri Jun 10 17:34:40 CEST 2011 +

+
+ +
On Fri, 10 Jun 2011, Olav Vitters wrote:
+
+> On Fri, Jun 10, 2011 at 04:35:57PM +0200, Christiaan Welvaart wrote:
+>> On Fri, 10 Jun 2011, Olav Vitters wrote:
+>>
+>>> On Fri, Jun 10, 2011 at 04:15:01PM +0200, Christiaan Welvaart wrote:
+....
+
+>>>>> Seems some distributions misunderstand the need and changed the wiki
+>>>>> page. Removing .la files is needed however, otherwise you'll quickly mix
+>>>>> distribution installed libraries and self-compiled libraries.
+>>>>
+>>>> What are you talking about here?
+>>
+>> <gnome-shell stuff>
+>
+> It is not gnome-shell, it is jhbuild and doing development (mainly
+> GNOME). Basic GNOME already has ~200 modules.
+
+Then why did you quote the webpage instead of saying just that?
+
+>> So you are really talking only about gnome-shell, which I can't even
+>> test because apparently it doesn't work in a VM. It is now packaged,
+>> so you don't need to build it.
+>
+> Nope, I'm talking about doing development using jhbuild. E.g. if you
+> want to contribute to GNOME, you'll have to get rid of all the .la
+> files no matter which distribution you use.
+>
+> A new GNOME does not happen automatically. It requires people to compile
+> the Git versions and committing stuff until a tarball is released and
+> packaged.
+>
+> Making such development easier would result in a better GNOME, and I
+> don't mind if the .la files stay, but prefer if they are removed.
+
+I think doing software development related to the system you're working on 
+isn't easy. For example jhbuild may not like .la files but if you want to 
+use static libraries supplied by the system, .la files are quite useful 
+AFAIK.
+
+So why did you point to that webpage if it's not related to mageia at all, 
+it's purely a jhbuild problem. If people are using a system with gnome 
+installed to develop gnome, it's not strange they run into problems. And I 
+wonder why they would have gnome related -devel packages installed in the 
+first place, they're not needed to *use* the system software.
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005370.html b/zarb-ml/mageia-dev/2011-June/005370.html new file mode 100644 index 000000000..578afa49a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005370.html @@ -0,0 +1,167 @@ + + + + [Mageia-dev] [RFC] Removing .la files + + + + + + + + + +

[Mageia-dev] [RFC] Removing .la files

+ Liam R E Quin + liam at holoweb.net +
+ Fri Jun 10 17:56:12 CEST 2011 +

+
+ +
On Fri, 2011-06-10 at 17:34 +0200, Christiaan Welvaart wrote:
+>  If people are using a system with gnome 
+> installed to develop gnome, it's not strange they run into problems. 
+
+This is nonsense, sorry.  It's no stranger than a KDE-user wanting to
+recompile kwrite or krita.
+
+> And I 
+> wonder why they would have gnome related -devel packages installed in the 
+> first place, they're not needed to *use* the system software.
+Because they're developing.
+
+For example, I'm involved with the GIMP project (GIMP is an image
+editor), but I don't want to compile my own gnome, not all of it, so I
+have enough of the -devel packages to compile just what I need (libbabl,
+libgegl and gimp, basically).  I currently need the .la files so that
+configure and libtool will find them, since I'm building in a private
+prefix, not overwriting the system gnome of course... although that need
+for .la files may change in the future.
+
+Successful Linux distributions have communities of developers around
+them developing applications. It's not only about high priests of Linux
+and "users" who don't compile anything... :)
+
+Liam
+
+-- 
+Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
+Pictures from old books: http://fromoldbooks.org/
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005371.html b/zarb-ml/mageia-dev/2011-June/005371.html new file mode 100644 index 000000000..4d7c234dc --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005371.html @@ -0,0 +1,156 @@ + + + + [Mageia-dev] [RFC] Removing .la files + + + + + + + + + +

[Mageia-dev] [RFC] Removing .la files

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Fri Jun 10 18:01:29 CEST 2011 +

+
+ +
On 10 June 2011 17:56, Liam R E Quin <liam at holoweb.net> wrote:
+> On Fri, 2011-06-10 at 17:34 +0200, Christiaan Welvaart wrote:
+>>  If people are using a system with gnome
+>> installed to develop gnome, it's not strange they run into problems.
+>
+> This is nonsense, sorry.  It's no stranger than a KDE-user wanting to
+> recompile kwrite or krita.
+>
+
+If you want a proper package, you should build in a clean chroot; just
+like the BS does, every single package is built in a clean chroot,
+that's a necessary measure to ensure the quality of the produced
+packages. If you don't build in a clean chroot, the build will pick
+all sorts of old/new libs from the system... :)
+
+[...]
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005372.html b/zarb-ml/mageia-dev/2011-June/005372.html new file mode 100644 index 000000000..6cf484fd7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005372.html @@ -0,0 +1,195 @@ + + + + [Mageia-dev] GNOME 2.32 borked + + + + + + + + + +

[Mageia-dev] GNOME 2.32 borked

+ Frank Griffin + ftg at roadrunner.com +
+ Fri Jun 10 18:05:08 CEST 2011 +

+
+ +
Just updated and rebooted a system which was last rebooted Jun 7, and 
+both GDM and KDM fail to log into my GNOME DE with a greyish popup 
+saying "failed to load your GNOME session".
+
+/var/log/gdm/0.log shows a segfault backtrace in fglrx, but this could 
+be a red herring, since KDE starts fine for the same user.
+
+The GNOME configuration for the user seems to be OK, because booting an 
+earlier Mageia beta logs into the DE just fine.
+
+I've avoided installing GNOME3 by using urpmi --keep, but maybe some 
+GNOME3 package slipped through that doesn't depend on the ones that want 
+to remove 2.32 ?
+
+Anybody else ?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005373.html b/zarb-ml/mageia-dev/2011-June/005373.html new file mode 100644 index 000000000..2451fd645 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005373.html @@ -0,0 +1,157 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process) + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process)

+ nicolas vigier + boklm at mars-attacks.org +
+ Fri Jun 10 18:11:21 CEST 2011 +

+
+ +
On Fri, 10 Jun 2011, Michael Scherer wrote:
+
+> > release is obviously frozen so no go there.
+> > 
+> > The only real option is updates, but that should obviously have some QA
+> > on it.
+> 
+> Updates is not for new version of software, not for new softwares. And
+> backporting something from cauldron is not a update.
+
+Maybe we could change the definition of updates repository. Rather than
+a strict rule "no new version and no new software in updates", we could
+have something like this :
+
+ - updates : no regression, and no changes in interfaces / protocols /
+   config files since last package. You could have a cron script updating
+   from this repository and nothing should stop working.
+
+ - backports : possible regressions and/or changes in interfaces /
+   protocols / config files. Updates from this repository should not be
+   installed automatically but checked by user.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005374.html b/zarb-ml/mageia-dev/2011-June/005374.html new file mode 100644 index 000000000..0a606bf12 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005374.html @@ -0,0 +1,163 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Fri Jun 10 18:14:09 CEST 2011 +

+
+ +
On 10 June 2011 16:46, James Kerr <jim at jkerr82508.free-online.co.uk> wrote:
+> On 10/06/11 15:27, Oliver Burger wrote:
+>>
+>> James Kerr<jim at jkerr82508.free-online.co.uk>  schrieb am 10.06.2011
+>>>
+>>> Even though backports are disabled rpmdrake can display a list of
+>>> available backports. (The sources are automatically updated by
+>>> mgaonline.)
+>>
+>> I make you parden, but: no!
+>>
+>> When a repo is disabled it doesn't get updated automatically and its
+>> packages are not to be found in rpmdrake.
+>> Did you confuse "disabling repos" and "marking a repo for updates"
+>> (sorry, me doesn't know the exact English strings).
+>>
+>>
+>> So you have to enable the backports repos and even though you don't
+>> "mark them as update repos", urpmi will ignore that (rpmdrake won't
+>> but urpmi will) and will update everything from those repos...
+>>
+>
+> I meant exactly what I wrote. Select Backports from the first filter in
+> rpmdrake and packages from disabled backports sources will be displayed.
+>
+> Check /var/log/auth.log to see what mgaonline is doing.
+>
+> Jim
+>
+>
+
+Jim is right; rpmdrake treats "backports" in a special way, and they
+do get updated even when they're disabled. urpmi won't install
+packages from them by default (unless you explicitly enable them or
+use e.g. 'urpmi --searchmedia Core\ Backports'); rpmdrake can show
+packages from "disabled" backports repos when you select the
+"Backports" filter, assuming they were correctly updated by mgaonline
+which is what mgaonline does by default.
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005375.html b/zarb-ml/mageia-dev/2011-June/005375.html new file mode 100644 index 000000000..449db3a25 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005375.html @@ -0,0 +1,177 @@ + + + + [Mageia-dev] [RFC] Removing .la files + + + + + + + + + +

[Mageia-dev] [RFC] Removing .la files

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Fri Jun 10 18:24:10 CEST 2011 +

+
+ +
'Twas brillig, and Ahmad Samir at 10/06/11 17:01 did gyre and gimble:
+> On 10 June 2011 17:56, Liam R E Quin <liam at holoweb.net> wrote:
+>> On Fri, 2011-06-10 at 17:34 +0200, Christiaan Welvaart wrote:
+>>>  If people are using a system with gnome
+>>> installed to develop gnome, it's not strange they run into problems.
+>>
+>> This is nonsense, sorry.  It's no stranger than a KDE-user wanting to
+>> recompile kwrite or krita.
+>>
+> 
+> If you want a proper package, you should build in a clean chroot; just
+> like the BS does, every single package is built in a clean chroot,
+> that's a necessary measure to ensure the quality of the produced
+> packages. If you don't build in a clean chroot, the build will pick
+> all sorts of old/new libs from the system... :)
+
+
+I seriously doubt people do want that.
+
+I don't want to compile from kernel, glibc upwards just to build 5 gnome
+or KDE modules.... I will want to use *some* system stuff and *some*
+self compiled stuff.
+
+Removal of .la files will make this much easier. I can't count the times
+I've had to do dirty hacks to work around these linking issues.
+
+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-June/005376.html b/zarb-ml/mageia-dev/2011-June/005376.html new file mode 100644 index 000000000..aad97e8b8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005376.html @@ -0,0 +1,169 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Anssi Hannula + anssi.hannula at iki.fi +
+ Fri Jun 10 18:24:54 CEST 2011 +

+
+ +
On 10.06.2011 17:28, Thorsten van Lil wrote:
+> Am 10.06.2011 16:09, schrieb James Kerr:
+>> On 10/06/11 13:54, Michael Scherer wrote:
+>>> Le vendredi 10 juin 2011 à 14:21 +0200, Oliver Burger a écrit :
+>>>> Thomas Backlund<tmb at mageia.org> schrieb am 10.06.2011
+>>>>> So the path would then be */updates_testing -> */updates _if_ we
+>>>>> decide that's the way to go...
+>>>> As I see it, it's the only user friendly way. Using backports is fine
+>>>> for experienced users who do know what to install from backports or
+>>>> who are capable of facing the consequences.
+>>>> If a total newbie asks fort a package in the forums and is pointed to
+>>>> backports he is in great danger of wrecking his system by installing
+>>>> some new kernel, graphics driver, desktop or whatever, precisely
+>>>> because there is no real qa on backports.
+>>>
+>>> He can also wait for the release. Or he can enable backport just for the
+>>> time needed to install and then disable it. I think rpmdrake have some
+>>> stuff for that.
+>>>
+>>
+>> Even though backports are disabled rpmdrake can display a list of
+>> available backports. (The sources are automatically updated by
+>> mgaonline.) A selected backport can then be installed, without enabling
+>> the backports source. (I've just tested this on mdv 2010.0, the only mdv
+>> system that I have available.)
+>>
+>> Jim
+>>
+> 
+> I've tested it on Mageia right now. I've activated Core-testing and see
+> that there is one package inside it: iputils_20101006_3.mga1. After that
+> I've disabled the testing repo and searched for iputils. Rpmdrake lists
+> me the version 2.mga1. Therefore, rpmdrake only lists packages of the
+> activated repos.
+
+Core-testing is not backports. The behavior depends on media name.
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005377.html b/zarb-ml/mageia-dev/2011-June/005377.html new file mode 100644 index 000000000..e4600d474 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005377.html @@ -0,0 +1,217 @@ + + + + [Mageia-dev] [RFC] Removing .la files + + + + + + + + + +

[Mageia-dev] [RFC] Removing .la files

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Fri Jun 10 18:26:56 CEST 2011 +

+
+ +
'Twas brillig, and Christiaan Welvaart at 10/06/11 16:34 did gyre and
+gimble:
+> On Fri, 10 Jun 2011, Olav Vitters wrote:
+> 
+>> On Fri, Jun 10, 2011 at 04:35:57PM +0200, Christiaan Welvaart wrote:
+>>> On Fri, 10 Jun 2011, Olav Vitters wrote:
+>>>
+>>>> On Fri, Jun 10, 2011 at 04:15:01PM +0200, Christiaan Welvaart wrote:
+> ....
+> 
+>>>>>> Seems some distributions misunderstand the need and changed the wiki
+>>>>>> page. Removing .la files is needed however, otherwise you'll
+>>>>>> quickly mix
+>>>>>> distribution installed libraries and self-compiled libraries.
+>>>>>
+>>>>> What are you talking about here?
+>>>
+>>> <gnome-shell stuff>
+>>
+>> It is not gnome-shell, it is jhbuild and doing development (mainly
+>> GNOME). Basic GNOME already has ~200 modules.
+> 
+> Then why did you quote the webpage instead of saying just that?
+
+Because it was an example. I think most people could appreciate it as
+that and work it out.
+
+> 
+>>> So you are really talking only about gnome-shell, which I can't even
+>>> test because apparently it doesn't work in a VM. It is now packaged,
+>>> so you don't need to build it.
+>>
+>> Nope, I'm talking about doing development using jhbuild. E.g. if you
+>> want to contribute to GNOME, you'll have to get rid of all the .la
+>> files no matter which distribution you use.
+>>
+>> A new GNOME does not happen automatically. It requires people to compile
+>> the Git versions and committing stuff until a tarball is released and
+>> packaged.
+>>
+>> Making such development easier would result in a better GNOME, and I
+>> don't mind if the .la files stay, but prefer if they are removed.
+> 
+> I think doing software development related to the system you're working
+> on isn't easy. For example jhbuild may not like .la files but if you
+> want to use static libraries supplied by the system, .la files are quite
+> useful AFAIK.
+> 
+> So why did you point to that webpage if it's not related to mageia at
+> all, it's purely a jhbuild problem.
+
+Because it explains the issue and the problem that people would have
+using Mageia for development if the .la files remained.
+
+> If people are using a system with
+> gnome installed to develop gnome, it's not strange they run into
+> problems.
+
+I call shenanigans. I do this kind of stuff all the time. It's easy to
+use a custom prefix (i.e. not /usr) if you select the right configure
+options. It means you get a working system but can also develop the next
+version. I've been doing this kind of stuff for years. The removal of
+the .la files will make this approach much easier.
+
+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-June/005378.html b/zarb-ml/mageia-dev/2011-June/005378.html new file mode 100644 index 000000000..9836d8645 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005378.html @@ -0,0 +1,204 @@ + + + + [Mageia-dev] GNOME 2.32 borked + + + + + + + + + +

[Mageia-dev] GNOME 2.32 borked

+ Daniel Le Berre + le.berred at free.fr +
+ Fri Jun 10 18:37:53 CEST 2011 +

+
+ +
Le 10/06/2011 18:05, Frank Griffin a écrit :
+> Just updated and rebooted a system which was last rebooted Jun 7, and
+> both GDM and KDM fail to log into my GNOME DE with a greyish popup
+> saying "failed to load your GNOME session".
+> 
+> /var/log/gdm/0.log shows a segfault backtrace in fglrx, but this could
+> be a red herring, since KDE starts fine for the same user.
+> 
+> The GNOME configuration for the user seems to be OK, because booting an
+> earlier Mageia beta logs into the DE just fine.
+> 
+> I've avoided installing GNOME3 by using urpmi --keep, but maybe some
+> GNOME3 package slipped through that doesn't depend on the ones that want
+> to remove 2.32 ?
+> 
+> Anybody else ?
+> 
+
+Got the same problem this morning on a Mageia 1 RC that had not been
+updated for two weeks, and that I updated yesterday.
+
+(I wanted to keep it on MGA 1, but noticed too late that the
+repositories pointed to cauldron because it has not been updated with
+the right mga-release. I tried to avoid updating mga2 package, but go some)
+
+Same error message. Switched to icewm to be able to work.
+
+Daniel
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005379.html b/zarb-ml/mageia-dev/2011-June/005379.html new file mode 100644 index 000000000..950e25072 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005379.html @@ -0,0 +1,192 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process) + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process)

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Fri Jun 10 18:34:08 CEST 2011 +

+
+ +
On 10 June 2011 13:44, Wolfgang Bornath <molch.b at googlemail.com> wrote:
+> 2011/6/10 Michael Scherer <misc at zarb.org>:
+>>
+>> We have used backports in the past for that, and I see no reason to
+>> change that.
+>>
+>> If the problem is that backports were too buggy in the past, then we
+>> should fix backports process, not bypassing them.
+>>
+>> And if we start by pushing new version in update, people will soon
+>> wonder why the new version of X is in updates, while the new version of
+>> Y is not, just because we didn't have X in release and Y was there.
+>
+> Problem I see:
+> So far (in Mandriva), example:  we have used 2010.0/main/backports to
+> offer new versions of software which had an older version in 2010/main
+> but the newer version in 2010.1/main, or as the name says: backporting
+> a newer version of a software from the current release to a previous
+> release, as often used for Firefox.
+>
+
+Firefox should always go to /updates, not backports, usually it has
+many sec fixed, so firefox and thunderbird are special cases.
+
+> For Mageia it means, /backports should hold backports of software
+> which has an older version in 1/core but a newer version in cauldron.
+> If we put new software (aka missing packages) in /backports and the
+> user activates /backports he also runs the risk that existing packages
+> of his stable installation will be replaced by real backports of newer
+> versions, backported from Cauldron - which he may not want to do.
+>
+
+Then he shouldn't use backports; but the point is if a totally new
+package, to Mageia 1, that never existed in core, is in backports, the
+user shouldn't see any regression with regard to that package as his
+experience with it before using backports is null, it didn't exist.
+
+> I wonder why we do not put these "missing packages" in /testing and
+> after a while in /core or /non-free or /tainted (wherever they
+> belong). These packages are software which were supposed to be in
+> /core or /non-free or /tainted, they were just forgotten|came too
+> late|whatever for Mageia 1 release freeze.
+>
+
+There will always be late packages, always. One example is a new
+version of foo that was released two days before Mageia's release, it
+won't be submitted through freeze, but will go to backports.
+
+IMHO, backports is way to offer "late" packages to user, whether
+they're new packages or newer versions of packages in
+core/nonfree/tainted, instead of the user installing them from 3rd
+party repos or having to build them himself (not all users are savvy
+with [re]building src.rpm's).
+
+> --
+> wobo
+>
+
+
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005380.html b/zarb-ml/mageia-dev/2011-June/005380.html new file mode 100644 index 000000000..3c6b4ce88 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005380.html @@ -0,0 +1,193 @@ + + + + [Mageia-dev] [RFC] Removing .la files + + + + + + + + + +

[Mageia-dev] [RFC] Removing .la files

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Fri Jun 10 18:42:12 CEST 2011 +

+
+ +
On 10 June 2011 18:24, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+> 'Twas brillig, and Ahmad Samir at 10/06/11 17:01 did gyre and gimble:
+>> On 10 June 2011 17:56, Liam R E Quin <liam at holoweb.net> wrote:
+>>> On Fri, 2011-06-10 at 17:34 +0200, Christiaan Welvaart wrote:
+>>>>  If people are using a system with gnome
+>>>> installed to develop gnome, it's not strange they run into problems.
+>>>
+>>> This is nonsense, sorry.  It's no stranger than a KDE-user wanting to
+>>> recompile kwrite or krita.
+>>>
+>>
+>> If you want a proper package, you should build in a clean chroot; just
+>> like the BS does, every single package is built in a clean chroot,
+>> that's a necessary measure to ensure the quality of the produced
+>> packages. If you don't build in a clean chroot, the build will pick
+>> all sorts of old/new libs from the system... :)
+>
+>
+> I seriously doubt people do want that.
+>
+> I don't want to compile from kernel, glibc upwards just to build 5 gnome
+> or KDE modules.... I will want to use *some* system stuff and *some*
+> self compiled stuff.
+>
+> Removal of .la files will make this much easier. I can't count the times
+> I've had to do dirty hacks to work around these linking issues.
+>
+> Col
+>
+>
+
+I am not against removing them, but just deleting them in the specs at
+this point won't work (it would have worked at the beginning of the
+fork, we'd import packages without .la at all, if only this issue was
+raised 8months ago :)). It's an inter-dependency circle of hell; it'll
+have to be done in the chroot, by a helper script run as root to clean
+the dependency_libs field in .la files from .la deps.
+
+(What I said is still generally true, if you want to build a "proper"
+package you should do it in a clean chroot, which, of course, you
+already know :p).
+
+> --
+>
+> 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/]
+>
+
+
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005381.html b/zarb-ml/mageia-dev/2011-June/005381.html new file mode 100644 index 000000000..b4c42085d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005381.html @@ -0,0 +1,177 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Anssi Hannula + anssi.hannula at iki.fi +
+ Fri Jun 10 19:06:35 CEST 2011 +

+
+ +
On 10.06.2011 02:56, Barry Jackson wrote:
+> I have been working on a package to install Skype current stable release
+> and now feel that it is ready for submission for approval.
+> 
+> It has already been improved/corrected/adapted many times following
+> discussions on #mageia-mentoring where I have been given lots of help.
+> 
+> The idea evolved here https://bugs.mageia.org/show_bug.cgi?id=154
+> where the current version is available as an attachment.
+> https://bugs.mageia.org/attachment.cgi?id=551
+> 
+> It has been a challenge and I have learned a lot in working on this. :)
+
+I didn't test it, but the problems I see now:
+
+1. The MD5SUM isn't checked, IMO it should be.
+2. On error you exit with "|| exit 1" but leave
+   the files in /tmp, polluting it.
+3. You cp files to %_datadir using a wildcard (*), but these
+   files may not be removed on uninstallation as you only have filename
+   lists for avatars/sounds/langs. While it may work now (I didn't
+   test, I hope you did), this will cause unnoticed problems when the
+   skype tarball contents change.
+4. Provide the script/commandline used to create the filelist files.
+5. Versionize the filelist files to make sure they are renegerated
+   when the package is updated to a new version (avatars-%version.txt)
+6. Your usage of /tmp seems unsafe security-wise. What if some user
+   has created something under /tmp/skype-%version already?
+   Instead use mktemp to create a temporary directory.
+7. You never remove the tarball, and the tarball is not %ghost.
+
+Also BTW, here is a package of mine for gootleearth from 2006 that uses
+a similar system:
+http://www.zarb.org/cgi-bin/viewvc.cgi/plf/SPECS/non-free/googleearth/
+No need to make it like that, just pointing it out in case there are
+some ideas you'd like to use.
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005382.html b/zarb-ml/mageia-dev/2011-June/005382.html new file mode 100644 index 000000000..eceb8d32a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005382.html @@ -0,0 +1,143 @@ + + + + [Mageia-dev] [RFC] Removing .la files + + + + + + + + + +

[Mageia-dev] [RFC] Removing .la files

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Fri Jun 10 19:09:50 CEST 2011 +

+
+ +
Op vrijdag 10 juni 2011 18:26:56 schreef Colin Guthrie:
+[...]
+> I call shenanigans. I do this kind of stuff all the time. It's easy to
+> use a custom prefix (i.e. not /usr) if you select the right configure
+> options. It means you get a working system but can also develop the next
+> version. I've been doing this kind of stuff for years. The removal of
+> the .la files will make this approach much easier.
+
++1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005383.html b/zarb-ml/mageia-dev/2011-June/005383.html new file mode 100644 index 000000000..d980feb01 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005383.html @@ -0,0 +1,188 @@ + + + + [Mageia-dev] GNOME 2.32 borked + + + + + + + + + +

[Mageia-dev] GNOME 2.32 borked

+ Frank Griffin + ftg at roadrunner.com +
+ Fri Jun 10 19:59:54 CEST 2011 +

+
+ +
On 06/10/2011 12:37 PM, Daniel Le Berre wrote:
+>
+> Got the same problem this morning on a Mageia 1 RC that had not been
+> updated for two weeks, and that I updated yesterday.
+>
+
+The following GNOME3 packages seem to have gotten installed in spite of 
+--keep:
+   gnome-icon-theme
+   gnome-menus
+   gnome-session
+   gnome-terminal
+   lib64gnomekbd7
+   lib64gnomekbd-common
+
+So it looks like the only way to recover is to go forward with GNOME3.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005384.html b/zarb-ml/mageia-dev/2011-June/005384.html new file mode 100644 index 000000000..8f0057b4f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005384.html @@ -0,0 +1,154 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Daniel Kreuter + daniel.kreuter85 at googlemail.com +
+ Fri Jun 10 20:12:16 CEST 2011 +

+
+ +
On Fri, Jun 10, 2011 at 3:26 PM, Olav Vitters <olav at vitters.nl> wrote:
+
+> On Fri, Jun 10, 2011 at 03:17:10PM +0200, Dexter Morgan wrote:
+> > On Fri, Jun 10, 2011 at 3:11 PM, Olav Vitters <olav at vitters.nl> wrote:
+> > > On Fri, Jun 10, 2011 at 02:59:58PM +0200, Michael Scherer wrote:
+> > >> My main issue is more that not everything is finished ( like I miss
+> the
+> > >> timezone clock stuff to see when to call on USAs and rest of Europa )
+> > >
+> > > That's planned for 3.2 btw.
+> >
+> > which is planned for october iirc no ?
+>
+> Yes (Sep 28), see www.gnome.org/start/unstable (standard link for the
+> current schedule)
+>
+> > so good for mageia 2 :)
+>
+> Indeed :)
+> --
+> Regards,
+> Olav
+>
+
++1
+
+I would also suggest to jump directly to Gnome 3.2 instead of 3.0 in Mageia
+2 because they want to fix some of the annoying bugs and implement some cool
+features like the integration of Zeitgeist.
+
+-- 
+Mit freundlichen Grüßen
+
+Greetings
+
+Daniel Kreuter
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110610/47d0827f/attachment-0001.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005385.html b/zarb-ml/mageia-dev/2011-June/005385.html new file mode 100644 index 000000000..b4701b709 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005385.html @@ -0,0 +1,166 @@ + + + + [Mageia-dev] [RFC] Removing .la files + + + + + + + + + +

[Mageia-dev] [RFC] Removing .la files

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Fri Jun 10 20:15:11 CEST 2011 +

+
+ +
On Fri, 10 Jun 2011, Colin Guthrie wrote:
+
+> 'Twas brillig, and Ahmad Samir at 10/06/11 17:01 did gyre and gimble:
+>> On 10 June 2011 17:56, Liam R E Quin <liam at holoweb.net> wrote:
+>>> On Fri, 2011-06-10 at 17:34 +0200, Christiaan Welvaart wrote:
+>>>>  If people are using a system with gnome
+>>>> installed to develop gnome, it's not strange they run into problems.
+>>>
+>>> This is nonsense, sorry.  It's no stranger than a KDE-user wanting to
+>>> recompile kwrite or krita.
+>>>
+>>
+>> If you want a proper package, you should build in a clean chroot; just
+>> like the BS does, every single package is built in a clean chroot,
+>> that's a necessary measure to ensure the quality of the produced
+>> packages. If you don't build in a clean chroot, the build will pick
+>> all sorts of old/new libs from the system... :)
+>
+>
+> I seriously doubt people do want that.
+>
+> I don't want to compile from kernel, glibc upwards just to build 5 gnome
+> or KDE modules.... I will want to use *some* system stuff and *some*
+> self compiled stuff.
+>
+> Removal of .la files will make this much easier. I can't count the times
+> I've had to do dirty hacks to work around these linking issues.
+
+I hope you realize removal of those files is unlikely to solve all your 
+linking issues, or maybe even none of them. As long as you have the .so 
+files from the -devel packages installed, the software you build can be 
+linked against those system libraries.
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005386.html b/zarb-ml/mageia-dev/2011-June/005386.html new file mode 100644 index 000000000..c0cfce28a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005386.html @@ -0,0 +1,153 @@ + + + + [Mageia-dev] [RFC] Removing .la files + + + + + + + + + +

[Mageia-dev] [RFC] Removing .la files

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Fri Jun 10 20:23:04 CEST 2011 +

+
+ +
On Fri, 10 Jun 2011, Colin Guthrie wrote:
+
+> 'Twas brillig, and Christiaan Welvaart at 10/06/11 16:34 did gyre and
+> gimble:
+
+>> If people are using a system with
+>> gnome installed to develop gnome, it's not strange they run into
+>> problems.
+>
+> I call shenanigans. I do this kind of stuff all the time. It's easy to
+> use a custom prefix (i.e. not /usr) if you select the right configure
+> options. It means you get a working system but can also develop the next
+> version. I've been doing this kind of stuff for years. The removal of
+> the .la files will make this approach much easier.
+
+Let's make one thing clear, however. These .la files are not created or 
+installed by packagers, but rather by the build system of (in this case) 
+gnome libraries. And maybe you are quite happy with the absolute paths 
+in the .la files in your buildroot/prefix.
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005387.html b/zarb-ml/mageia-dev/2011-June/005387.html new file mode 100644 index 000000000..b56d7d2de --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005387.html @@ -0,0 +1,179 @@ + + + + [Mageia-dev] GNOME 2.32 borked + + + + + + + + + +

[Mageia-dev] GNOME 2.32 borked

+ Bernard Siaud alias Troumad + liste at siaud.org +
+ Fri Jun 10 18:40:40 CEST 2011 +

+
+ +
Le 10/06/2011 18:37, Daniel Le Berre a écrit :
+> Same error message. Switched to icewm to be able to work.
+xfce is also a good chose.
+
+But, we want try gnome 3 ;)
+
+-- 
+Amicalement vOOotre              Troumad Alias Bernard SIAUD
+mon site : http://troumad.org : AD&D maths WEB...
+Pour la liberté http://www.developpez.net/forums/f17/systemes/linux/ 
+N'envoyez que des documents avec des formats ouverts, comme 
+http://fr.libreoffice.org
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005388.html b/zarb-ml/mageia-dev/2011-June/005388.html new file mode 100644 index 000000000..861b6e0ca --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005388.html @@ -0,0 +1,182 @@ + + + + [Mageia-dev] GNOME 2.32 borked + + + + + + + + + +

[Mageia-dev] GNOME 2.32 borked

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Fri Jun 10 23:21:44 CEST 2011 +

+
+ +
On Fri, 10 Jun 2011, Daniel Le Berre wrote:
+
+> Le 10/06/2011 18:05, Frank Griffin a écrit :
+>> Just updated and rebooted a system which was last rebooted Jun 7, and
+>> both GDM and KDM fail to log into my GNOME DE with a greyish popup
+>> saying "failed to load your GNOME session".
+
+> Same error message. Switched to icewm to be able to work.
+
+Does it work with the new notification-daemon-0.7.1-1.mga2 ?
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005389.html b/zarb-ml/mageia-dev/2011-June/005389.html new file mode 100644 index 000000000..df319782a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005389.html @@ -0,0 +1,161 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ andre999 + andr55 at laposte.net +
+ Fri Jun 10 23:44:18 CEST 2011 +

+
+ +
James Kerr a écrit :
+>
+> On 10/06/11 15:09, James Kerr wrote:
+>> On 10/06/11 13:54, Michael Scherer wrote:
+>>> Le vendredi 10 juin 2011 à 14:21 +0200, Oliver Burger a écrit :
+>>>> Thomas Backlund<tmb at mageia.org> schrieb am 10.06.2011
+>>>>> So the path would then be */updates_testing -> */updates _if_ we
+>>>>> decide that's the way to go...
+>>>> As I see it, it's the only user friendly way. Using backports is fine
+>>>> for experienced users who do know what to install from backports or
+>>>> who are capable of facing the consequences.
+>>>> If a total newbie asks fort a package in the forums and is pointed to
+>>>> backports he is in great danger of wrecking his system by installing
+>>>> some new kernel, graphics driver, desktop or whatever, precisely
+>>>> because there is no real qa on backports.
+>>>
+>>> He can also wait for the release. Or he can enable backport just for the
+>>> time needed to install and then disable it. I think rpmdrake have some
+>>> stuff for that.
+>>
+>> Even though backports are disabled rpmdrake can display a list of
+>> available backports. (The sources are automatically updated by
+>> mgaonline.) A selected backport can then be installed, without enabling
+>> the backports source. (I've just tested this on mdv 2010.0, the only mdv
+>> system that I have available.)
+>
+> I've just realised there is a potential problem with this. Because
+> Mageia has /backports_testing repo's (mdv does not) packages from
+> /backports_testing may also be displayed. Mgaonline is updating those
+> sources.
+>
+> Jim
+
+That was a bug in rpmdrake.
+If you had updated the repos with backports media enabled, when the backports media was 
+subsequently disabled, the previously available backports packages remained displayed/installable. 
+  But new backports were not added if the repos were updated with backports disabled.  There was 
+the same problem for other media (like non-free).
+Otherwise enabling/disabling backports (or any other media) wouldn't make any sense.
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005390.html b/zarb-ml/mageia-dev/2011-June/005390.html new file mode 100644 index 000000000..699017511 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005390.html @@ -0,0 +1,159 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ JA Magallón + jamagallon at ono.com +
+ Sat Jun 11 00:17:11 CEST 2011 +

+
+ +
On Thu, 9 Jun 2011 10:45:03 +0200, JA Magallón <jamagallon at ono.com> wrote:
+
+> Hi all...
+> 
+> I have a problem with this first big change in Cauldron...
+> I have a couple test boxes in which I have updated everything, and I can't
+> get Gnome 3 to work properly. I suppose it is still work in progress, but as
+> other people sent messages telling this or that application doesn't work...
+> 
+> I can't even get an application to launch. I log in, get gnome-shell running,
+> but:
+> - no applet is shown in the bar. and they are there, i can press moue button
+>   on right menu, hover it over there and the volume bubble pops, but I see no
+>   icon on the bar.
+> - if I select "System settings" o launch firefox, immediately I get a fullscreen
+>   error about "something went wrong, plz logout and in again"
+> 
+> I suppose probably I miss some depdency not correctly handled, but I can not
+> guess what.
+> 
+> Any ideas ?
+> 
+> TIA
+> 
+> 
+
+Well, after latest updates I can see things in gnome-shell, launch apps,
+see preferences, but suddenly I get kicked out, and I think this is the
+problem:
+
+gnome-settings-[2556]: segfault at 7fb8612fb1d0 ip 00007fb8612fb1d0 sp 00007fff830282d8 error 14 in libnsl-2.12.1.so[7fb8639dc000+15000]
+gnome-settings-[3257]: segfault at 7fae815011d0 ip 00007fae815011d0 sp 00007fff72cc8b58 error 14 in libnsl-2.12.1.so[7fae83be2000+15000]
+gnome-settings-[3723]: segfault at 7f42989871d0 ip 00007f42989871d0 sp 00007fffa8d55858 error 14 in libnsl-2.12.1.so[7f429b068000+15000]
+
+(from dmesg)
+
+Sometines it lasts longer, other less, but I get the error fullscreen message
+all the time. And perhaps it's because the session loses connection to gnome-settings-daemon.
+
+Any idea ?
+
+-- 
+J.A. Magallon <jamagallon()ono!com>     \                 Winter is coming...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005391.html b/zarb-ml/mageia-dev/2011-June/005391.html new file mode 100644 index 000000000..a17ac0e88 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005391.html @@ -0,0 +1,164 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Dexter Morgan + dmorganec at gmail.com +
+ Sat Jun 11 00:47:36 CEST 2011 +

+
+ +
2011/6/11 JA Magallón <jamagallon at ono.com>:
+> On Thu, 9 Jun 2011 10:45:03 +0200, JA Magallón <jamagallon at ono.com> wrote:
+>
+>> Hi all...
+>>
+>> I have a problem with this first big change in Cauldron...
+>> I have a couple test boxes in which I have updated everything, and I can't
+>> get Gnome 3 to work properly. I suppose it is still work in progress, but as
+>> other people sent messages telling this or that application doesn't work...
+>>
+>> I can't even get an application to launch. I log in, get gnome-shell running,
+>> but:
+>> - no applet is shown in the bar. and they are there, i can press moue button
+>>   on right menu, hover it over there and the volume bubble pops, but I see no
+>>   icon on the bar.
+>> - if I select "System settings" o launch firefox, immediately I get a fullscreen
+>>   error about "something went wrong, plz logout and in again"
+>>
+>> I suppose probably I miss some depdency not correctly handled, but I can not
+>> guess what.
+>>
+>> Any ideas ?
+>>
+>> TIA
+>>
+>>
+>
+> Well, after latest updates I can see things in gnome-shell, launch apps,
+> see preferences, but suddenly I get kicked out, and I think this is the
+> problem:
+>
+> gnome-settings-[2556]: segfault at 7fb8612fb1d0 ip 00007fb8612fb1d0 sp 00007fff830282d8 error 14 in libnsl-2.12.1.so[7fb8639dc000+15000]
+> gnome-settings-[3257]: segfault at 7fae815011d0 ip 00007fae815011d0 sp 00007fff72cc8b58 error 14 in libnsl-2.12.1.so[7fae83be2000+15000]
+> gnome-settings-[3723]: segfault at 7f42989871d0 ip 00007f42989871d0 sp 00007fffa8d55858 error 14 in libnsl-2.12.1.so[7f429b068000+15000]
+>
+> (from dmesg)
+>
+> Sometines it lasts longer, other less, but I get the error fullscreen message
+> all the time. And perhaps it's because the session loses connection to gnome-settings-daemon.
+>
+> Any idea ?
+>
+> --
+> J.A. Magallon <jamagallon()ono!com>     \                 Winter is coming...
+>
+
+i think that it can be interesting to start gnome-settings inside gdb
+to have some infos about the crash
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005392.html b/zarb-ml/mageia-dev/2011-June/005392.html new file mode 100644 index 000000000..7e869cb5a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005392.html @@ -0,0 +1,179 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ James Kerr + jim at jkerr82508.free-online.co.uk +
+ Sat Jun 11 01:52:51 CEST 2011 +

+
+ +
On 10/06/11 22:44, andre999 wrote:
+> James Kerr a écrit :
+>>
+>> On 10/06/11 15:09, James Kerr wrote:
+>>> On 10/06/11 13:54, Michael Scherer wrote:
+>>>> Le vendredi 10 juin 2011 à 14:21 +0200, Oliver Burger a écrit :
+>>>>> Thomas Backlund<tmb at mageia.org> schrieb am 10.06.2011
+>>>>>> So the path would then be */updates_testing -> */updates _if_ we
+>>>>>> decide that's the way to go...
+>>>>> As I see it, it's the only user friendly way. Using backports is fine
+>>>>> for experienced users who do know what to install from backports or
+>>>>> who are capable of facing the consequences.
+>>>>> If a total newbie asks fort a package in the forums and is pointed to
+>>>>> backports he is in great danger of wrecking his system by installing
+>>>>> some new kernel, graphics driver, desktop or whatever, precisely
+>>>>> because there is no real qa on backports.
+>>>>
+>>>> He can also wait for the release. Or he can enable backport just for
+>>>> the
+>>>> time needed to install and then disable it. I think rpmdrake have some
+>>>> stuff for that.
+>>>
+>>> Even though backports are disabled rpmdrake can display a list of
+>>> available backports. (The sources are automatically updated by
+>>> mgaonline.) A selected backport can then be installed, without enabling
+>>> the backports source. (I've just tested this on mdv 2010.0, the only mdv
+>>> system that I have available.)
+>>
+>> I've just realised there is a potential problem with this. Because
+>> Mageia has /backports_testing repo's (mdv does not) packages from
+>> /backports_testing may also be displayed. Mgaonline is updating those
+>> sources.
+>>
+>> Jim
+>
+> That was a bug in rpmdrake.
+> If you had updated the repos with backports media enabled, when the
+> backports media was subsequently disabled, the previously available
+> backports packages remained displayed/installable. But new backports
+> were not added if the repos were updated with backports disabled. There
+> was the same problem for other media (like non-free).
+> Otherwise enabling/disabling backports (or any other media) wouldn't
+> make any sense.
+>
+
+It is not a bug, but intended behaviour. When mdkonline/mgaonline is 
+running it updates backports sources each time it checks for updates. As 
+I indicated in an earlier email you can see that this is done if you 
+check /var/log/auth.log.
+
+The system that I tested on, has never had backports sources enabled and 
+I was able to install a recent package from a disabled backports source, 
+by selecting it from Backports, displayed using the first filter in 
+rpmdrake.
+
+This facility was set up to allow inexperienced users to selectively 
+install backports, without enabling the backports sources.
+
+Jim
+
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005393.html b/zarb-ml/mageia-dev/2011-June/005393.html new file mode 100644 index 000000000..ecef6bb06 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005393.html @@ -0,0 +1,201 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Barry Jackson + zen25000 at zen.co.uk +
+ Sat Jun 11 02:05:32 CEST 2011 +

+
+ +
On 10/06/11 18:06, Anssi Hannula wrote:
+
+> I didn't test it, but the problems I see now:
+>
+> 1. The MD5SUM isn't checked, IMO it should be.
+
+I was just discussing that on IRC with Ahmad ;)
+I now have that working OK
+
+> 2. On error you exit with "|| exit 1" but leave
+>     the files in /tmp, polluting it.
+
+OK - will fix
+
+> 3. You cp files to %_datadir using a wildcard (*), but these
+>     files may not be removed on uninstallation as you only have filename
+>     lists for avatars/sounds/langs. While it may work now (I didn't
+>     test, I hope you did), this will cause unnoticed problems when the
+>     skype tarball contents change.
+
+The wildcard is used to move the remaining files which are all 
+individually handled by touch and the dir is removed by a %ghost.
+I was just saving spec lines.
+
+Yes it does work fine and all files/dirs are removed on uninstall.
+
+The tarball contents can't change or the md5sum would fail :\
+
+> 4. Provide the script/commandline used to create the filelist files.
+
+Do you mean the avatars.txt etc.
+It was all done semi-manually, but I will write a script if necessary.
+It did cross my mind, but it was quicker to just copy/paste into txt files.
+I was assuming I could maintain it manually.
+
+> 5. Versionize the filelist files to make sure they are renegerated
+>     when the package is updated to a new version (avatars-%version.txt)
+
+OK - again I was expecting to maintain it manually.
+
+> 6. Your usage of /tmp seems unsafe security-wise. What if some user
+>     has created something under /tmp/skype-%version already?
+
+Hmm.. point taken
+
+>     Instead use mktemp to create a temporary directory.
+
+OK ... but:
+I can't figure out how to get a temp filename into a %define
+If I use
+%define mytmp $(mktemp -d -q)
+then every reference to the %define generates a new tmp file.
+How can I assign the output of a command expansion to a %define so it's 
+evaluated only once on assignment?
+I can use a variable in %pre but that is invisible in %post as it's in 
+another shell so I'm sorta stuck on that for now :(
+
+> 7. You never remove the tarball, and the tarball is not %ghost.
+
+Will do - that was temporary for testing.
+
+>
+> Also BTW, here is a package of mine for gootleearth from 2006 that uses
+> a similar system:
+> http://www.zarb.org/cgi-bin/viewvc.cgi/plf/SPECS/non-free/googleearth/
+> No need to make it like that, just pointing it out in case there are
+> some ideas you'd like to use.
+>
+
+I'll take a look - thanks
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005394.html b/zarb-ml/mageia-dev/2011-June/005394.html new file mode 100644 index 000000000..04ebe578b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005394.html @@ -0,0 +1,147 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Barry Jackson + zen25000 at zen.co.uk +
+ Sat Jun 11 02:13:14 CEST 2011 +

+
+ +
On 10/06/11 15:08, Marc Paré wrote:
+>
+> Hi Barry
+>
+> Thanks for doing this. I uncompressed the file. What is the difference
+> between the 2 .rpms? You may want to include a "readme" in the package
+> for people like me.
+>
+> Cheers
+>
+> Marc
+>
+>
+Marc,
+It is not really ready for general consumption yet (although it does work).
+If you want to test it the noarch.rpm is the one to install, not the 
+src.rpm.
+
+Barry
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005395.html b/zarb-ml/mageia-dev/2011-June/005395.html new file mode 100644 index 000000000..a4a56a17e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005395.html @@ -0,0 +1,154 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Marc Paré + marc at marcpare.com +
+ Sat Jun 11 03:53:04 CEST 2011 +

+
+ +
Le 2011-06-10 20:13, Barry Jackson a écrit :
+> On 10/06/11 15:08, Marc Paré wrote:
+>>
+>> Hi Barry
+>>
+>> Thanks for doing this. I uncompressed the file. What is the difference
+>> between the 2 .rpms? You may want to include a "readme" in the package
+>> for people like me.
+>>
+>> Cheers
+>>
+>> Marc
+>>
+>>
+> Marc,
+> It is not really ready for general consumption yet (although it does work).
+> If you want to test it the noarch.rpm is the one to install, not the
+> src.rpm.
+>
+> Barry
+>
+Thanks, I'll give it a try.
+
+Cheers
+
+Marc
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005396.html b/zarb-ml/mageia-dev/2011-June/005396.html new file mode 100644 index 000000000..7bf2f63ff --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005396.html @@ -0,0 +1,191 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ andre999 + andr55 at laposte.net +
+ Sat Jun 11 04:33:16 CEST 2011 +

+
+ +
James Kerr a écrit :
+>
+> On 10/06/11 22:44, andre999 wrote:
+>> James Kerr a écrit :
+>>>
+>>> On 10/06/11 15:09, James Kerr wrote:
+>>>> On 10/06/11 13:54, Michael Scherer wrote:
+>>>>> Le vendredi 10 juin 2011 à 14:21 +0200, Oliver Burger a écrit :
+>>>>>> Thomas Backlund<tmb at mageia.org> schrieb am 10.06.2011
+>>>>>>> So the path would then be */updates_testing -> */updates _if_ we
+>>>>>>> decide that's the way to go...
+>>>>>> As I see it, it's the only user friendly way. Using backports is fine
+>>>>>> for experienced users who do know what to install from backports or
+>>>>>> who are capable of facing the consequences.
+>>>>>> If a total newbie asks fort a package in the forums and is pointed to
+>>>>>> backports he is in great danger of wrecking his system by installing
+>>>>>> some new kernel, graphics driver, desktop or whatever, precisely
+>>>>>> because there is no real qa on backports.
+>>>>>
+>>>>> He can also wait for the release. Or he can enable backport just for
+>>>>> the
+>>>>> time needed to install and then disable it. I think rpmdrake have some
+>>>>> stuff for that.
+>>>>
+>>>> Even though backports are disabled rpmdrake can display a list of
+>>>> available backports. (The sources are automatically updated by
+>>>> mgaonline.) A selected backport can then be installed, without enabling
+>>>> the backports source. (I've just tested this on mdv 2010.0, the only
+>>>> mdv
+>>>> system that I have available.)
+>>>
+>>> I've just realised there is a potential problem with this. Because
+>>> Mageia has /backports_testing repo's (mdv does not) packages from
+>>> /backports_testing may also be displayed. Mgaonline is updating those
+>>> sources.
+>>>
+>>> Jim
+>>
+>> That was a bug in rpmdrake.
+>> If you had updated the repos with backports media enabled, when the
+>> backports media was subsequently disabled, the previously available
+>> backports packages remained displayed/installable. But new backports
+>> were not added if the repos were updated with backports disabled. There
+>> was the same problem for other media (like non-free).
+>> Otherwise enabling/disabling backports (or any other media) wouldn't
+>> make any sense.
+>>
+>
+> It is not a bug, but intended behaviour. When mdkonline/mgaonline is
+> running it updates backports sources each time it checks for updates. As
+> I indicated in an earlier email you can see that this is done if you
+> check /var/log/auth.log.
+>
+> The system that I tested on, has never had backports sources enabled and
+> I was able to install a recent package from a disabled backports source,
+> by selecting it from Backports, displayed using the first filter in
+> rpmdrake.
+>
+> This facility was set up to allow inexperienced users to selectively
+> install backports, without enabling the backports sources.
+>
+> Jim
+
+OK, I just verified.  As you say, backports are visible if viewing backports alone, even if the 
+backports medias are not selected.  (This is the first time I have selected viewing backports alone.)
+
+I have, however, temporarily enabled at least one backports media on occasion, which were then 
+viewable under "all" (packages).  The backports packages in question remained viewable under "all", 
+after all the backports media were disabled.
+Note that if backports media are not enabled, backports are normally not visible under "all" 
+(packages) or "all updates".
+The same thing has happened with "non-free" medias, which I normally leave disabled.
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005397.html b/zarb-ml/mageia-dev/2011-June/005397.html new file mode 100644 index 000000000..6dfaaaad9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005397.html @@ -0,0 +1,200 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Anssi Hannula + anssi.hannula at iki.fi +
+ Sat Jun 11 10:14:34 CEST 2011 +

+
+ +
On 11.06.2011 03:05, Barry Jackson wrote:
+> On 10/06/11 18:06, Anssi Hannula wrote:
+
+>> 3. You cp files to %_datadir using a wildcard (*), but these
+>>     files may not be removed on uninstallation as you only have filename
+>>     lists for avatars/sounds/langs. While it may work now (I didn't
+>>     test, I hope you did), this will cause unnoticed problems when the
+>>     skype tarball contents change.
+> 
+> The wildcard is used to move the remaining files which are all
+> individually handled by touch and the dir is removed by a %ghost.
+> I was just saving spec lines.
+> 
+> Yes it does work fine and all files/dirs are removed on uninstall.
+> 
+> The tarball contents can't change or the md5sum would fail :\
+
+I meant that when updating the package to a new version it is easy to
+not notice some added files in the tarball, leaving the wildcard in
+place but not add respective %ghosted files.
+
+>> 4. Provide the script/commandline used to create the filelist files.
+> 
+> Do you mean the avatars.txt etc.
+> It was all done semi-manually, but I will write a script if necessary.
+> It did cross my mind, but it was quicker to just copy/paste into txt files.
+> I was assuming I could maintain it manually.
+
+Maintaining manually is fine, just add a comment beside the SourceXX
+lines to tell what to do.
+
+>> 5. Versionize the filelist files to make sure they are renegerated
+>>     when the package is updated to a new version (avatars-%version.txt)
+> 
+> OK - again I was expecting to maintain it manually.
+
+Yes, but this makes sure they are not forgotten (i.e. the pkg build
+fails completely if you forget to update them, instead of creating a
+broken package).
+
+>> 6. Your usage of /tmp seems unsafe security-wise. What if some user
+>>     has created something under /tmp/skype-%version already?
+> 
+> Hmm.. point taken
+> 
+>>     Instead use mktemp to create a temporary directory.
+> 
+> OK ... but:
+> I can't figure out how to get a temp filename into a %define
+> If I use
+> %define mytmp $(mktemp -d -q)
+> then every reference to the %define generates a new tmp file.
+> How can I assign the output of a command expansion to a %define so it's
+> evaluated only once on assignment?
+
+%global mytmp %(mktemp -d -q)
+
+However, that doesn't do what you want. That creates a temporary
+directory in the system where package build is not done, while you want
+to create a temporary directory in the user system. See below.
+
+> I can use a variable in %pre but that is invisible in %post as it's in
+> another shell so I'm sorta stuck on that for now :(
+
+Probably the easiest way is to use a fixed location under
+%{_localstatedir}/lib/%{name} for the tarball instead. Then you can use
+mktemp locally in %post.
+
+Also, is there a need to use -q for mktemp?
+
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005398.html b/zarb-ml/mageia-dev/2011-June/005398.html new file mode 100644 index 000000000..0cbcf88d0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005398.html @@ -0,0 +1,148 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Sat Jun 11 12:06:55 CEST 2011 +

+
+ +
On Fri, 10 Jun 2011, Michael Scherer wrote:
+
+> We can agree that everybody want something newer for some rpms, but few
+> people want everything to be newer ( ie, now one run backports as a
+> update media, I think ). So as much as I am against asking to users
+> questions, we must show them the choice somewhere, in a non obstrusive
+> way.
+
+Maybe, but how would be "support" this? We must be able to reproduce a 
+reported problem. This becomes complicated when we don't know what is 
+installed on the user's system. A guideline for bug reporters is (or 
+should be) "make sure you installed the latest updates". What would be the 
+equivalent for backports? I'm afraid it should be "if you installed any 
+backports, make sure you installed all backports that are relevant for 
+your system". If someone has a problem with any other combination, the bug 
+report might be rejected. How would QA even work when only selected 
+packages are upgraded from backports, or integration testing: 
+integration with what?
+
+So the only combinations we can support are:
+   - release + updates
+   - release + updates + backports
+
+More practical: for mga1 I have a VM that I can keep updated. For mga1 
+backports I can install another VM with backports enabled. But for bugs 
+reported with only selected backports installed I suppose I would have to 
+install a new VM with mga1, update it, and install only those backports - 
+for each bug report. But maybe I'm missing something, please explain. (:
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005399.html b/zarb-ml/mageia-dev/2011-June/005399.html new file mode 100644 index 000000000..d9227042d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005399.html @@ -0,0 +1,177 @@ + + + + [Mageia-dev] perl 5.14.0 now available + + + + + + + + + +

[Mageia-dev] perl 5.14.0 now available

+ Olivier Blin + mageia at blino.org +
+ Sat Jun 11 12:33:18 CEST 2011 +

+
+ +
Jerome Quelin <jquelin at gmail.com> writes:
+
+> hi,
+>
+> perl 5.14.0 should arrive soon. it compiles fine on both i586 & x86_64,
+> and it seem we fixed the only problem arisen in perl-URPM.
+>
+> since other packages need to be rebuilt in the same loop, and given that
+> urpmi is written in perl, it needs a special treatment to bypass the
+> regular bs upload.
+>
+> blino will likely do this magic dance & upload them in the coming hours -
+> you may want to wait till his final go before updating your cauldron
+> box.
+
+Hi,
+
+I've uploaded perl 5.14 last night.
+(I just had to update perl-FCGI to a newer version, since it didn't
+build anymore)
+
+Help is welcome to rebuild perlapi-5.12-dependent packages.
+
+Thanks Jérôme!
+
+-- 
+Olivier Blin - blino
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005400.html b/zarb-ml/mageia-dev/2011-June/005400.html new file mode 100644 index 000000000..126bd84d5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005400.html @@ -0,0 +1,161 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Samuel Verschelde + stormi at laposte.net +
+ Sat Jun 11 13:14:29 CEST 2011 +

+
+ +
Le samedi 11 juin 2011 12:06:55, Christiaan Welvaart a écrit :
+> On Fri, 10 Jun 2011, Michael Scherer wrote:
+> > We can agree that everybody want something newer for some rpms, but few
+> > people want everything to be newer ( ie, now one run backports as a
+> > update media, I think ). So as much as I am against asking to users
+> > questions, we must show them the choice somewhere, in a non obstrusive
+> > way.
+> 
+> Maybe, but how would be "support" this? We must be able to reproduce a
+> reported problem. This becomes complicated when we don't know what is
+> installed on the user's system. A guideline for bug reporters is (or
+> should be) "make sure you installed the latest updates". What would be the
+> equivalent for backports? I'm afraid it should be "if you installed any
+> backports, make sure you installed all backports that are relevant for
+> your system". If someone has a problem with any other combination, the bug
+> report might be rejected. How would QA even work when only selected
+> packages are upgraded from backports, or integration testing:
+> integration with what?
+> 
+> So the only combinations we can support are:
+>    - release + updates
+>    - release + updates + backports
+> 
+> More practical: for mga1 I have a VM that I can keep updated. For mga1
+> backports I can install another VM with backports enabled. But for bugs
+> reported with only selected backports installed I suppose I would have to
+> install a new VM with mga1, update it, and install only those backports -
+> for each bug report. But maybe I'm missing something, please explain. (:
+> 
+
+If we suppose that either updates or backports are supported (with a support 
+level to be defined), the situation is simpler to me :  a good backport must 
+work  with all its dependencies coming from updates or release OR it must 
+explicitly require higher versions, found only in the backports media and so 
+automatically pulled.
+
+So I don't think that having picked up only certain backported packages is a 
+problem for the maintainer's support. Maybe I over-simplified the situation, 
+but I don't think it will be as complex as you say.
+
+Samuel 
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110611/976fba78/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005401.html b/zarb-ml/mageia-dev/2011-June/005401.html new file mode 100644 index 000000000..006854119 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005401.html @@ -0,0 +1,165 @@ + + + + [Mageia-dev] subscribe where to submit list? + + + + + + + + + +

[Mageia-dev] subscribe where to submit list?

+ Dick Gevers + dvgevers at xs4all.nl +
+ Sat Jun 11 13:20:37 CEST 2011 +

+
+ +
Not that I understand half of what is posted, but for reference and
+satisfying my curiosity, I'd like to subscribe to the submit ML, but can't
+find it at https://mageia.org/mailman/
+
+Obviously I can send a subscribe mail, but I dunno the details.
+
+TIA!
+=Dick Gevers=
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005402.html b/zarb-ml/mageia-dev/2011-June/005402.html new file mode 100644 index 000000000..b5a3d6a7a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005402.html @@ -0,0 +1,186 @@ + + + + [Mageia-dev] subscribe where to submit list? + + + + + + + + + +

[Mageia-dev] subscribe where to submit list?

+ Anne nicolas + ennael at mageia.org +
+ Sat Jun 11 13:24:11 CEST 2011 +

+
+ +
2011/6/11 Dick Gevers <dvgevers at xs4all.nl>
+
+> Not that I understand half of what is posted, but for reference and
+> satisfying my curiosity, I'd like to subscribe to the submit ML, but can't
+> find it at https://mageia.org/mailman/
+>
+> Obviously I can send a subscribe mail, but I dunno the details.
+>
+
+
+have a look on https://ml.mageia.org/. Some of the ML are still hosted on
+Zarb server and others have been created on Mageia servers. This is on
+sysadmin todo list
+
+
+>
+> TIA!
+> =Dick Gevers=
+>
+
+
+
+-- 
+Anne
+http://www.mageia.org
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110611/286e7c35/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005403.html b/zarb-ml/mageia-dev/2011-June/005403.html new file mode 100644 index 000000000..535a8a866 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005403.html @@ -0,0 +1,165 @@ + + + + [Mageia-dev] subscribe where to submit list? + + + + + + + + + +

[Mageia-dev] subscribe where to submit list?

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Sat Jun 11 13:25:16 CEST 2011 +

+
+ +
On Sat, 11 Jun 2011, Dick Gevers wrote:
+
+> Not that I understand half of what is posted, but for reference and
+> satisfying my curiosity, I'd like to subscribe to the submit ML, but can't
+> find it at https://mageia.org/mailman/
+
+https://ml.mageia.org/
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005404.html b/zarb-ml/mageia-dev/2011-June/005404.html new file mode 100644 index 000000000..8cf5652ef --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005404.html @@ -0,0 +1,161 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Sat Jun 11 14:26:19 CEST 2011 +

+
+ +
Op zaterdag 11 juni 2011 13:14:29 schreef Samuel Verschelde:
+> Le samedi 11 juin 2011 12:06:55, Christiaan Welvaart a écrit :
+> > On Fri, 10 Jun 2011, Michael Scherer wrote:
+> > > We can agree that everybody want something newer for some rpms, but few
+> > > people want everything to be newer ( ie, now one run backports as a
+> > > update media, I think ). So as much as I am against asking to users
+> > > questions, we must show them the choice somewhere, in a non obstrusive
+> > > way.
+> > 
+> > Maybe, but how would be "support" this? We must be able to reproduce a
+> > reported problem. This becomes complicated when we don't know what is
+> > installed on the user's system. A guideline for bug reporters is (or
+> > should be) "make sure you installed the latest updates". What would be
+> > the equivalent for backports? I'm afraid it should be "if you installed
+> > any backports, make sure you installed all backports that are relevant
+> > for your system". If someone has a problem with any other combination,
+> > the bug report might be rejected. How would QA even work when only
+> > selected packages are upgraded from backports, or integration testing:
+> > integration with what?
+> > 
+> > So the only combinations we can support are:
+> >    - release + updates
+> >    - release + updates + backports
+> > 
+> > More practical: for mga1 I have a VM that I can keep updated. For mga1
+> > backports I can install another VM with backports enabled. But for bugs
+> > reported with only selected backports installed I suppose I would have to
+> > install a new VM with mga1, update it, and install only those backports -
+> 
+> > for each bug report. But maybe I'm missing something, please explain. (:
+> If we suppose that either updates or backports are supported (with a
+> support level to be defined), the situation is simpler to me :  a good
+> backport must work  with all its dependencies coming from updates or
+> release OR it must explicitly require higher versions, found only in the
+> backports media and so automatically pulled.
+> 
+> So I don't think that having picked up only certain backported packages is
+> a problem for the maintainer's support. Maybe I over-simplified the
+> situation, but I don't think it will be as complex as you say.
+> 
+> Samuel
+
+imho this creates more work for packagers or qa team to support backports, i'm 
+not really in favor of this solution
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005405.html b/zarb-ml/mageia-dev/2011-June/005405.html new file mode 100644 index 000000000..d3c268216 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005405.html @@ -0,0 +1,188 @@ + + + + [Mageia-dev] subscribe where to submit list? + + + + + + + + + +

[Mageia-dev] subscribe where to submit list?

+ Dick Gevers + dvgevers at xs4all.nl +
+ Sat Jun 11 15:08:23 CEST 2011 +

+
+ +
On Sat, 11 Jun 2011 13:24:11 +0200, Anne nicolas wrote about Re:
+[Mageia-dev] subscribe where to submit list?:
+
+>2011/6/11 Dick Gevers <dvgevers at xs4all.nl>
+>
+>> Not that I understand half of what is posted, but for reference and
+>> satisfying my curiosity, I'd like to subscribe to the submit ML, but
+>> can't find it at https://mageia.org/mailman/
+>>
+>> Obviously I can send a subscribe mail, but I dunno the details.
+>>
+>
+>
+>have a look on https://ml.mageia.org/. Some of the ML are still hosted on
+>Zarb server and others have been created on Mageia servers. This is on
+>sysadmin todo list
+>
+>
+>>
+>> TIA!
+>> =Dick Gevers=
+>>
+>
+>
+>
+>-- 
+>Anne
+>http://www.mageia.org
+
+Merci (en Christiaan ook).
+
+grtz.
+=Dick Gevers=
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005406.html b/zarb-ml/mageia-dev/2011-June/005406.html new file mode 100644 index 000000000..37c2801a7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005406.html @@ -0,0 +1,129 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Sat Jun 11 15:08:38 CEST 2011 +

+
+ +
On Thu, 9 Jun 2011, JA Magallón wrote:
+
+> - if I select "System settings" o launch firefox, immediately I get a fullscreen
+>  error about "something went wrong, plz logout and in again"
+
+> I suppose probably I miss some depdency not correctly handled, but I can not
+> guess what.
+
+Do you have 'gtk+3.0' installed? I had a problem with gnome-panel's 
+"Properties" menu item, installing gtk+3.0 fixed it (dependency added in 
+svn, I'll upload later).
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005407.html b/zarb-ml/mageia-dev/2011-June/005407.html new file mode 100644 index 000000000..cff41daab --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005407.html @@ -0,0 +1,190 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Samuel Verschelde + stormi at laposte.net +
+ Sat Jun 11 16:55:00 CEST 2011 +

+
+ +
Le samedi 11 juin 2011 14:26:19, Maarten Vanraes a écrit :
+> Op zaterdag 11 juni 2011 13:14:29 schreef Samuel Verschelde:
+> > Le samedi 11 juin 2011 12:06:55, Christiaan Welvaart a écrit :
+> > > On Fri, 10 Jun 2011, Michael Scherer wrote:
+> > > > We can agree that everybody want something newer for some rpms, but
+> > > > few people want everything to be newer ( ie, now one run backports
+> > > > as a update media, I think ). So as much as I am against asking to
+> > > > users questions, we must show them the choice somewhere, in a non
+> > > > obstrusive way.
+> > > 
+> > > Maybe, but how would be "support" this? We must be able to reproduce a
+> > > reported problem. This becomes complicated when we don't know what is
+> > > installed on the user's system. A guideline for bug reporters is (or
+> > > should be) "make sure you installed the latest updates". What would be
+> > > the equivalent for backports? I'm afraid it should be "if you installed
+> > > any backports, make sure you installed all backports that are relevant
+> > > for your system". If someone has a problem with any other combination,
+> > > the bug report might be rejected. How would QA even work when only
+> > > selected packages are upgraded from backports, or integration testing:
+> > > integration with what?
+> > > 
+> > > So the only combinations we can support are:
+> > >    - release + updates
+> > >    - release + updates + backports
+> > > 
+> > > More practical: for mga1 I have a VM that I can keep updated. For mga1
+> > > backports I can install another VM with backports enabled. But for bugs
+> > > reported with only selected backports installed I suppose I would have
+> > > to install a new VM with mga1, update it, and install only those
+> > > backports -
+> > 
+> > > for each bug report. But maybe I'm missing something, please explain. (:
+> > If we suppose that either updates or backports are supported (with a
+> > support level to be defined), the situation is simpler to me :  a good
+> > backport must work  with all its dependencies coming from updates or
+> > release OR it must explicitly require higher versions, found only in the
+> > backports media and so automatically pulled.
+> > 
+> > So I don't think that having picked up only certain backported packages
+> > is a problem for the maintainer's support. Maybe I over-simplified the
+> > situation, but I don't think it will be as complex as you say.
+> > 
+> > Samuel
+> 
+> imho this creates more work for packagers or qa team to support backports,
+> i'm not really in favor of this solution
+
+So it someone has a problem with a package you backported and reports it in 
+bugzilla, you'll answer "not supported" and close the door ? Then we have not 
+a single chance to have users accept to use backports rather than ask for a 
+rolling release (supposing that we want to stay with stable releases model, 
+which hasn't been decided yet).
+
+In my opinion, a backport must be either supported or not exist. Even in 
+Mandriva, where everybody keep saying "backports ain't supported", usually 
+people try to solve the problems caused by backports.
+
+However, the level of support can be different between backports and updates, 
+as I said in my previous message. The differences are yet to define, but here 
+are some I see :
+- when a critical bug in a backport exists, you can simply update to a newer 
+version and see if it's solved
+- if the program already is in its the latest version and has an upstream bug, 
+you can answer "report the bug upstream" and stop there until upstream solves 
+the bug. For packages in release or updates, ideally you have to try to help 
+fixing it or work it around because the bug is considered part of the whole 
+distribution.
+
+Best regards
+
+Samuel
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110611/e0b9ab4a/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005408.html b/zarb-ml/mageia-dev/2011-June/005408.html new file mode 100644 index 000000000..ae84916b6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005408.html @@ -0,0 +1,173 @@ + + + + [Mageia-dev] perl 5.14.0 now available + + + + + + + + + +

[Mageia-dev] perl 5.14.0 now available

+ Thomas Spuhler + thomas at btspuhler.com +
+ Sat Jun 11 17:00:13 CEST 2011 +

+
+ +
On Saturday, June 11, 2011 03:33:18 am Olivier Blin wrote:
+> Jerome Quelin <jquelin at gmail.com> writes:
+> > hi,
+> > 
+> > perl 5.14.0 should arrive soon. it compiles fine on both i586 & x86_64,
+> > and it seem we fixed the only problem arisen in perl-URPM.
+> > 
+> > since other packages need to be rebuilt in the same loop, and given that
+> > urpmi is written in perl, it needs a special treatment to bypass the
+> > regular bs upload.
+> > 
+> > blino will likely do this magic dance & upload them in the coming hours -
+> > you may want to wait till his final go before updating your cauldron
+> > box.
+> 
+> Hi,
+> 
+> I've uploaded perl 5.14 last night.
+> (I just had to update perl-FCGI to a newer version, since it didn't
+> build anymore)
+> 
+> Help is welcome to rebuild perlapi-5.12-dependent packages.
+> 
+> Thanks Jérôme!
+I'll help to build
+-- 
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005409.html b/zarb-ml/mageia-dev/2011-June/005409.html new file mode 100644 index 000000000..adce5faed --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005409.html @@ -0,0 +1,197 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Sat Jun 11 18:01:54 CEST 2011 +

+
+ +
Op zaterdag 11 juni 2011 16:55:00 schreef Samuel Verschelde:
+> Le samedi 11 juin 2011 14:26:19, Maarten Vanraes a écrit :
+> > Op zaterdag 11 juni 2011 13:14:29 schreef Samuel Verschelde:
+> > > Le samedi 11 juin 2011 12:06:55, Christiaan Welvaart a écrit :
+> > > > On Fri, 10 Jun 2011, Michael Scherer wrote:
+> > > > > We can agree that everybody want something newer for some rpms, but
+> > > > > few people want everything to be newer ( ie, now one run backports
+> > > > > as a update media, I think ). So as much as I am against asking to
+> > > > > users questions, we must show them the choice somewhere, in a non
+> > > > > obstrusive way.
+> > > > 
+> > > > Maybe, but how would be "support" this? We must be able to reproduce
+> > > > a reported problem. This becomes complicated when we don't know what
+> > > > is installed on the user's system. A guideline for bug reporters is
+> > > > (or should be) "make sure you installed the latest updates". What
+> > > > would be the equivalent for backports? I'm afraid it should be "if
+> > > > you installed any backports, make sure you installed all backports
+> > > > that are relevant for your system". If someone has a problem with
+> > > > any other combination, the bug report might be rejected. How would
+> > > > QA even work when only selected packages are upgraded from
+> > > > backports, or integration testing: integration with what?
+> > > > 
+> > > > So the only combinations we can support are:
+> > > >    - release + updates
+> > > >    - release + updates + backports
+> > > > 
+> > > > More practical: for mga1 I have a VM that I can keep updated. For
+> > > > mga1 backports I can install another VM with backports enabled. But
+> > > > for bugs reported with only selected backports installed I suppose I
+> > > > would have to install a new VM with mga1, update it, and install
+> > > > only those backports -
+> > > 
+> > > > for each bug report. But maybe I'm missing something, please explain. 
+(:
+> > > If we suppose that either updates or backports are supported (with a
+> > > support level to be defined), the situation is simpler to me :  a good
+> > > backport must work  with all its dependencies coming from updates or
+> > > release OR it must explicitly require higher versions, found only in
+> > > the backports media and so automatically pulled.
+> > > 
+> > > So I don't think that having picked up only certain backported packages
+> > > is a problem for the maintainer's support. Maybe I over-simplified the
+> > > situation, but I don't think it will be as complex as you say.
+> > > 
+> > > Samuel
+> > 
+> > imho this creates more work for packagers or qa team to support
+> > backports, i'm not really in favor of this solution
+> 
+> So it someone has a problem with a package you backported and reports it in
+> bugzilla, you'll answer "not supported" and close the door ? Then we have
+> not a single chance to have users accept to use backports rather than ask
+> for a rolling release (supposing that we want to stay with stable releases
+> model, which hasn't been decided yet).
+> 
+> In my opinion, a backport must be either supported or not exist. Even in
+> Mandriva, where everybody keep saying "backports ain't supported", usually
+> people try to solve the problems caused by backports.
+> 
+> However, the level of support can be different between backports and
+> updates, as I said in my previous message. The differences are yet to
+> define, but here are some I see :
+> - when a critical bug in a backport exists, you can simply update to a
+> newer version and see if it's solved
+> - if the program already is in its the latest version and has an upstream
+> bug, you can answer "report the bug upstream" and stop there until
+> upstream solves the bug. For packages in release or updates, ideally you
+> have to try to help fixing it or work it around because the bug is
+> considered part of the whole distribution.
+> 
+> Best regards
+> 
+> Samuel
+
+What about security fixes? if there's 1 version in release and 10 in backports? 
+do the older backported packages have to be securitypatched?
+
+imho not supported backports means that if backports has an issue, try a newer 
+backports...
+
+imho that is a good level, that doesn't require much effort.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005410.html b/zarb-ml/mageia-dev/2011-June/005410.html new file mode 100644 index 000000000..5523b75af --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005410.html @@ -0,0 +1,212 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Samuel Verschelde + stormi at laposte.net +
+ Sat Jun 11 18:03:12 CEST 2011 +

+
+ +
Le samedi 11 juin 2011 18:01:54, Maarten Vanraes a écrit :
+> Op zaterdag 11 juni 2011 16:55:00 schreef Samuel Verschelde:
+> > Le samedi 11 juin 2011 14:26:19, Maarten Vanraes a écrit :
+> > > Op zaterdag 11 juni 2011 13:14:29 schreef Samuel Verschelde:
+> > > > Le samedi 11 juin 2011 12:06:55, Christiaan Welvaart a écrit :
+> > > > > On Fri, 10 Jun 2011, Michael Scherer wrote:
+> > > > > > We can agree that everybody want something newer for some rpms,
+> > > > > > but few people want everything to be newer ( ie, now one run
+> > > > > > backports as a update media, I think ). So as much as I am
+> > > > > > against asking to users questions, we must show them the choice
+> > > > > > somewhere, in a non obstrusive way.
+> > > > > 
+> > > > > Maybe, but how would be "support" this? We must be able to
+> > > > > reproduce a reported problem. This becomes complicated when we
+> > > > > don't know what is installed on the user's system. A guideline for
+> > > > > bug reporters is (or should be) "make sure you installed the
+> > > > > latest updates". What would be the equivalent for backports? I'm
+> > > > > afraid it should be "if you installed any backports, make sure you
+> > > > > installed all backports that are relevant for your system". If
+> > > > > someone has a problem with any other combination, the bug report
+> > > > > might be rejected. How would QA even work when only selected
+> > > > > packages are upgraded from backports, or integration testing:
+> > > > > integration with what?
+> > > > > 
+> > > > > So the only combinations we can support are:
+> > > > >    - release + updates
+> > > > >    - release + updates + backports
+> > > > > 
+> > > > > More practical: for mga1 I have a VM that I can keep updated. For
+> > > > > mga1 backports I can install another VM with backports enabled. But
+> > > > > for bugs reported with only selected backports installed I suppose
+> > > > > I would have to install a new VM with mga1, update it, and install
+> > > > > only those backports -
+> > > > > 
+> > > > > for each bug report. But maybe I'm missing something, please
+> > > > > explain.
+> 
+> (:
+> > > > If we suppose that either updates or backports are supported (with a
+> > > > support level to be defined), the situation is simpler to me :  a
+> > > > good backport must work  with all its dependencies coming from
+> > > > updates or release OR it must explicitly require higher versions,
+> > > > found only in the backports media and so automatically pulled.
+> > > > 
+> > > > So I don't think that having picked up only certain backported
+> > > > packages is a problem for the maintainer's support. Maybe I
+> > > > over-simplified the situation, but I don't think it will be as
+> > > > complex as you say.
+> > > > 
+> > > > Samuel
+> > > 
+> > > imho this creates more work for packagers or qa team to support
+> > > backports, i'm not really in favor of this solution
+> > 
+> > So it someone has a problem with a package you backported and reports it
+> > in bugzilla, you'll answer "not supported" and close the door ? Then we
+> > have not a single chance to have users accept to use backports rather
+> > than ask for a rolling release (supposing that we want to stay with
+> > stable releases model, which hasn't been decided yet).
+> > 
+> > In my opinion, a backport must be either supported or not exist. Even in
+> > Mandriva, where everybody keep saying "backports ain't supported",
+> > usually people try to solve the problems caused by backports.
+> > 
+> > However, the level of support can be different between backports and
+> > updates, as I said in my previous message. The differences are yet to
+> > define, but here are some I see :
+> > - when a critical bug in a backport exists, you can simply update to a
+> > newer version and see if it's solved
+> > - if the program already is in its the latest version and has an upstream
+> > bug, you can answer "report the bug upstream" and stop there until
+> > upstream solves the bug. For packages in release or updates, ideally you
+> > have to try to help fixing it or work it around because the bug is
+> > considered part of the whole distribution.
+> > 
+> > Best regards
+> > 
+> > Samuel
+> 
+> What about security fixes? if there's 1 version in release and 10 in
+> backports? do the older backported packages have to be securitypatched?
+> 
+> imho not supported backports means that if backports has an issue, try a
+> newer backports...
+> 
+> imho that is a good level, that doesn't require much effort.
+
+I think we agree, because if we follow the Mandriva way, upload of a new 
+backport for a given package removes the old one if there is one. So at a 
+given time, you only have to support the package in release or updates + 0 or 
+1 backport.
+
+Samuel
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110611/cd906686/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005411.html b/zarb-ml/mageia-dev/2011-June/005411.html new file mode 100644 index 000000000..d037afd89 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005411.html @@ -0,0 +1,145 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Barry Jackson + zen25000 at zen.co.uk +
+ Sat Jun 11 18:13:16 CEST 2011 +

+
+ +
On 11/06/11 09:14, Anssi Hannula wrote:
+---------snip---------
+> Probably the easiest way is to use a fixed location under
+> %{_localstatedir}/lib/%{name} for the tarball instead. Then you can use
+> mktemp locally in %post.
+>
+> Also, is there a need to use -q for mktemp?
+>
+
+Thanks - that works fine and is certainly the least complicated way to 
+do this. I could have created a script for use in %post while in %pre, 
+but it would have made the spec harder to read.
+
+I have dealt with all the points you raised in the attached spec which 
+is working OK.
+Please dissect it and comment again if you see any blunders ;)
+
+I will update the tar.gz in the bug report with this latest version.
+
+Barry
+
+-------------- next part --------------
+An embedded and charset-unspecified text was scrubbed...
+Name: get-skype.spec
+URL: </pipermail/mageia-dev/attachments/20110611/87fe5693/attachment-0001.ksh>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005412.html b/zarb-ml/mageia-dev/2011-June/005412.html new file mode 100644 index 000000000..2f23dfaf7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005412.html @@ -0,0 +1,175 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Anssi Hannula + anssi.hannula at iki.fi +
+ Sat Jun 11 19:03:10 CEST 2011 +

+
+ +
On 11.06.2011 19:13, Barry Jackson wrote:
+> On 11/06/11 09:14, Anssi Hannula wrote:
+> ---------snip---------
+>> Probably the easiest way is to use a fixed location under
+>> %{_localstatedir}/lib/%{name} for the tarball instead. Then you can use
+>> mktemp locally in %post.
+>>
+>> Also, is there a need to use -q for mktemp?
+>>
+> 
+> Thanks - that works fine and is certainly the least complicated way to
+> do this. I could have created a script for use in %post while in %pre,
+> but it would have made the spec harder to read.
+> 
+> I have dealt with all the points you raised in the attached spec which
+> is working OK.
+> Please dissect it and comment again if you see any blunders ;)
+> 
+> I will update the tar.gz in the bug report with this latest version.
+
+OK, here goes :)
+
+- I see you didn't get what I meant with the versionized filelist files.
+  The idea was that if someone updates the package to a new skype
+  version, the rpmbuild process would fail if one didn't touch the
+  filelist files.  With your changes such a failure doesn't happen.
+  You need to use lang-%{version}.txt instead, so that when someone
+  updates %version, it will automatically start failing until the lang
+  list file is updated/moved.
+
+- Best to add a comment in the %post script to remind that any new files
+  need to have a %ghost entry created.
+  (btw: an alternative idea is to create a post-script and the filelist
+   at the same time in a single for loop in %build/%install, so that
+   the lists can never get out of sync as they are created from a single
+   list; however, your current solution is adequate as well)
+
+- Why define %tmpextdir instead of using $newtmp directly? Quite
+  confusing as %variables are defined at build-time while $variables
+  at run-time.
+
+- You don't check for failures. If the mktemp call fails, you extract
+  the tarball into /root etc.etc.. You need to check for failures on
+  the mktemp/mkdir/cd commands (mktemp failure can be detected by
+  checking if $newtmp string is empty), or alternatively run "set -e"
+  to make the shell exit on failures (this leaves the tmpdir polluted,
+  but it doesn't matter as much as it is an uncommon failure case and
+  /tmp is cleaned periodically anyway).
+
+- Dot in Summary.
+
+- Noarch seems wrong to me.
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005413.html b/zarb-ml/mageia-dev/2011-June/005413.html new file mode 100644 index 000000000..b69e38532 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005413.html @@ -0,0 +1,189 @@ + + + + [Mageia-dev] perl 5.14.0 now available + + + + + + + + + +

[Mageia-dev] perl 5.14.0 now available

+ Pascal Terjan + pterjan at gmail.com +
+ Sat Jun 11 23:52:43 CEST 2011 +

+
+ +
On Sat, Jun 11, 2011 at 17:00, Thomas Spuhler <thomas at btspuhler.com> wrote:
+> On Saturday, June 11, 2011 03:33:18 am Olivier Blin wrote:
+>> Jerome Quelin <jquelin at gmail.com> writes:
+>> > hi,
+>> >
+>> > perl 5.14.0 should arrive soon. it compiles fine on both i586 & x86_64,
+>> > and it seem we fixed the only problem arisen in perl-URPM.
+>> >
+>> > since other packages need to be rebuilt in the same loop, and given that
+>> > urpmi is written in perl, it needs a special treatment to bypass the
+>> > regular bs upload.
+>> >
+>> > blino will likely do this magic dance & upload them in the coming hours -
+>> > you may want to wait till his final go before updating your cauldron
+>> > box.
+>>
+>> Hi,
+>>
+>> I've uploaded perl 5.14 last night.
+>> (I just had to update perl-FCGI to a newer version, since it didn't
+>> build anymore)
+>>
+>> Help is welcome to rebuild perlapi-5.12-dependent packages.
+>>
+>> Thanks Jérôme!
+> I'll help to build
+
+Thanks for helping but
+1) Please use a better changelog message, like "Rebuild for perl
+5.14". Increase rel for rebuild is not interesting when looking at the
+history of a package.
+2) How did you get the list of packages to rebuild? You seem to
+rebuild packages which don't need to be rebuilt. I noticed
+perl-Youri-Package which I wouldn't expect needing to be rebuilt.
+
+
+# rpm -qp --requires
+/distrib/bootstrap/distrib/1/i586/media/core/release/perl-Youri-Package-0.2.2-4.mga1.noarch.rpm
+perl-version
+rpmlib(PayloadFilesHavePrefix) <= 4.0-1
+rpmlib(CompressedFileNames) <= 3.0.4-1
+rpmlib(VersionedDependencies) <= 3.0.3-1
+perl-base >= 2:5.12.3
+rpmlib(PayloadIsLzma) <= 4.4.6-1
+
+It does not depend on perlapi-5.12
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005414.html b/zarb-ml/mageia-dev/2011-June/005414.html new file mode 100644 index 000000000..48e3f8c41 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005414.html @@ -0,0 +1,178 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Barry Jackson + zen25000 at zen.co.uk +
+ Sun Jun 12 01:37:53 CEST 2011 +

+
+ +
On 11/06/11 18:03, Anssi Hannula wrote:
+
+> OK, here goes :)
+>
+> - I see you didn't get what I meant with the versionized filelist files.
+>    The idea was that if someone updates the package to a new skype
+>    version, the rpmbuild process would fail if one didn't touch the
+>    filelist files.  With your changes such a failure doesn't happen.
+>    You need to use lang-%{version}.txt instead, so that when someone
+>    updates %version, it will automatically start failing until the lang
+>    list file is updated/moved.
+
+I did follow - just had brain fail when implementing it - sorted now.
+
+>
+> - Best to add a comment in the %post script to remind that any new files
+>    need to have a %ghost entry created.
+>    (btw: an alternative idea is to create a post-script and the filelist
+>     at the same time in a single for loop in %build/%install, so that
+>     the lists can never get out of sync as they are created from a single
+>     list; however, your current solution is adequate as well)
+
+Note added - keep it simple.
+
+>
+> - Why define %tmpextdir instead of using $newtmp directly? Quite
+>    confusing as %variables are defined at build-time while $variables
+>    at run-time.
+
+Quite ! - Fixed.
+
+>
+> - You don't check for failures. If the mktemp call fails, you extract
+>    the tarball into /root etc.etc.. You need to check for failures on
+>    the mktemp/mkdir/cd commands (mktemp failure can be detected by
+>    checking if $newtmp string is empty), or alternatively run "set -e"
+>    to make the shell exit on failures (this leaves the tmpdir polluted,
+>    but it doesn't matter as much as it is an uncommon failure case and
+>    /tmp is cleaned periodically anyway).
+
+Added some checks - with clean-up of previously created dirs etc on fail.
+
+>
+> - Dot in Summary.
+
+?? I don't see one.
+
+>
+> - Noarch seems wrong to me.
+
+Pass. I wondered about that.  It uses 32 bit libs in both arch, and 
+seems to test OK in both, but I am open to suggestions.
+
+Barry
+-------------- next part --------------
+An embedded and charset-unspecified text was scrubbed...
+Name: get-skype.spec
+URL: </pipermail/mageia-dev/attachments/20110612/addf59a4/attachment.ksh>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005415.html b/zarb-ml/mageia-dev/2011-June/005415.html new file mode 100644 index 000000000..1da37ca02 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005415.html @@ -0,0 +1,195 @@ + + + + [Mageia-dev] perl 5.14.0 should arrive soon + + + + + + + + + +

[Mageia-dev] perl 5.14.0 should arrive soon

+ Zé + mmodem00 at gmail.com +
+ Sun Jun 12 02:22:58 CEST 2011 +

+
+ +
2011/6/10 Jerome Quelin <jquelin at gmail.com>:
+> hi,
+>
+> perl 5.14.0 should arrive soon. it compiles fine on both i586 & x86_64,
+> and it seem we fixed the only problem arisen in perl-URPM.
+>
+> since other packages need to be rebuilt in the same loop, and given that
+> urpmi is written in perl, it needs a special treatment to bypass the
+> regular bs upload.
+>
+> blino will likely do this magic dance & upload them in the coming hours -
+> you may want to wait till his final go before updating your cauldron
+> box.
+>
+> once this is done, it's still not time to update the perl modules to
+> their latest version: binary perl modules need to be rebuilt against
+> perl 5.14. to get the list:
+>
+>    $ urpmf --requires :perlapi-5.12 | cut -d: -f1 | sort -u
+>
+> there are 364 of them at the time of speaking. and of course some of
+> them need to be rebuilt before others. [0]
+>
+> ==>  help is welcome to rebuild them [1]
+>
+> to rebuild one of those binary packages:
+>    1- wait for blino to announce perl 5.14.0 availability
+>    2- check out the package
+>    3- bump mkrel in package spec file
+>    4- mgarepo submit
+>    5- if build fails on bs, then it's likely that a missing binary
+>       module is missing: proceed the missing package
+>
+> thanks,
+> jérôme
+>
+> [0] note to self: i'll create a "magpie sort" command to order those...
+> but it's a bit too late for now. it'll be ready for perl 5.16 in one
+> year! :-)
+> [1] i should not be able to work on it this week-end, so feel free to
+> give it a try.
+>
+
+Theres a new version for perl-CGI.
+I have asked sophie whos the maintainer for perl-CGI wich got no
+answer, asked sanders about it and tould me you would be the person
+indicated.
+
+regards,
+-- 
+Zé
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005416.html b/zarb-ml/mageia-dev/2011-June/005416.html new file mode 100644 index 000000000..342453551 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005416.html @@ -0,0 +1,180 @@ + + + + [Mageia-dev] [104363] SILENT: new binary files SOURCES/ia_ora-kde4-0.3.2.tar.bz2 + + + + + + + + + +

[Mageia-dev] [104363] SILENT: new binary files SOURCES/ia_ora-kde4-0.3.2.tar.bz2

+ Balcaen John + mikala at mageia.org +
+ Sun Jun 12 04:49:04 CEST 2011 +

+
+ +
Le samedi 11 juin 2011 20:25:00, root at mageia.org a écrit :
+> Revision: 104363
+> Author:   ze
+> Date:     2011-06-12 01:24:59 +0200 (Sun, 12 Jun 2011)
+> Log Message:
+> -----------
+> SILENT: new binary files SOURCES/ia_ora-kde4-0.3.2.tar.bz2
+> 
+> Modified Paths:
+> --------------
+>     cauldron/kde4-style-iaora/current/SOURCES/sha1.lst
+> 
+> Modified: cauldron/kde4-style-iaora/current/SOURCES/sha1.lst
+> ===================================================================
+> --- cauldron/kde4-style-iaora/current/SOURCES/sha1.lst	2011-06-11 23:24:59 
+UTC (rev 104362)
+> +++ cauldron/kde4-style-iaora/current/SOURCES/sha1.lst	2011-06-11 23:24:59 
+UTC (rev 104363)
+> @@ -0,0 +1 @@
+> +965ef5b1cd020e307f9e3adab42f0ee20ff142fc  ia_ora-kde4-0.3.2.tar.bz2
+> 
+
+Where does come from this new  tarball when there's no new commit in svn soft 
+?
+Could you please *ask* before updating a package ?
+That's not the first time you're doing some changes/patchs without even asking 
+before....
+I thought we were agree to talk about changes related to kde's package before 
+applying them even if you're a 10 years old packager... It's just to work as a 
+community...
+
+-- 
+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-June/005417.html b/zarb-ml/mageia-dev/2011-June/005417.html new file mode 100644 index 000000000..c298d91dd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005417.html @@ -0,0 +1,206 @@ + + + + [Mageia-dev] [104363] SILENT: new binary files SOURCES/ia_ora-kde4-0.3.2.tar.bz2 + + + + + + + + + +

[Mageia-dev] [104363] SILENT: new binary files SOURCES/ia_ora-kde4-0.3.2.tar.bz2

+ Zé + mmodem00 at gmail.com +
+ Sun Jun 12 05:46:56 CEST 2011 +

+
+ +
2011/6/12 Balcaen John <mikala at mageia.org>:
+> Le samedi 11 juin 2011 20:25:00, root at mageia.org a écrit :
+>> Revision: 104363
+>> Author:   ze
+>> Date:     2011-06-12 01:24:59 +0200 (Sun, 12 Jun 2011)
+>> Log Message:
+>> -----------
+>> SILENT: new binary files SOURCES/ia_ora-kde4-0.3.2.tar.bz2
+>>
+>> Modified Paths:
+>> --------------
+>>     cauldron/kde4-style-iaora/current/SOURCES/sha1.lst
+>>
+>> Modified: cauldron/kde4-style-iaora/current/SOURCES/sha1.lst
+>> ===================================================================
+>> --- cauldron/kde4-style-iaora/current/SOURCES/sha1.lst        2011-06-11 23:24:59
+> UTC (rev 104362)
+>> +++ cauldron/kde4-style-iaora/current/SOURCES/sha1.lst        2011-06-11 23:24:59
+> UTC (rev 104363)
+>> @@ -0,0 +1 @@
+>> +965ef5b1cd020e307f9e3adab42f0ee20ff142fc  ia_ora-kde4-0.3.2.tar.bz2
+>>
+>
+> Where does come from this new  tarball when there's no new commit in svn soft
+> ?
+This is the mandriva tarball used in mandriva kde4-style-iaora-0.3.2-1.src.rpm
+
+> Could you please *ask* before updating a package ?
+> That's not the first time you're doing some changes/patchs without even asking
+> before....
+
+Like i said in the mail i first sent you i did said that i shoud have
+done it and it just passed me, in fact i did mailed you reporting
+this, so it wasnt all like not saying any.
+In the other 2 changes i made in kde, i did discussed one first with
+you and the other i did also discussed it but was in fact after the
+commit.
+Regarding this one i first queried sophie to see if this was a
+maintained package in wich there wasnt any output so i commited and
+then i realized that even without being set as maintained by someone
+it was still a kde package, so then i mailed you reporting it in wich
+i also stated that i would from now on first discuss with you any
+changes i would have in mind.
+I also asked you if was possible to join the kde team, but you have
+ignored those emails.
+
+
+> I thought we were agree to talk about changes related to kde's package before
+> applying them even if you're a 10 years old packager... It's just to work as a
+> community...
+>
+> --
+> Balcaen John
+> Jabber ID: mikala at jabber.littleboboy.net
+>
+Yes
+
+
+-- 
+Zé
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005418.html b/zarb-ml/mageia-dev/2011-June/005418.html new file mode 100644 index 000000000..bb85b4177 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005418.html @@ -0,0 +1,186 @@ + + + + [Mageia-dev] [104363] SILENT: new binary files SOURCES/ia_ora-kde4-0.3.2.tar.bz2 + + + + + + + + + +

[Mageia-dev] [104363] SILENT: new binary files SOURCES/ia_ora-kde4-0.3.2.tar.bz2

+ Balcaen John + mikala at mageia.org +
+ Sun Jun 12 06:18:32 CEST 2011 +

+
+ +
Le dimanche 12 juin 2011 00:46:56, Zé a écrit :
+[...]
+> > Could you please *ask* before updating a package ?
+> > That's not the first time you're doing some changes/patchs without even 
+asking
+> > before....
+> 
+> Like i said in the mail i first sent you i did said that i shoud have
+> done it and it just passed me, in fact i did mailed you reporting
+> this, so it wasnt all like not saying any.
+
+Sorry but  i did not read/notice your mail before noticing the commit & the 
+package on changelog...
+
+> In the other 2 changes i made in kde, i did discussed one first with
+> you and the other i did also discussed it but was in fact after the
+> commit.
+> Regarding this one i first queried sophie to see if this was a
+> maintained package in wich there wasnt any output so i commited and
+> then i realized that even without being set as maintained by someone
+> it was still a kde package, so then i mailed you reporting it in wich
+> i also stated that i would from now on first discuss with you any
+> changes i would have in mind.
+There's no maintainer database for now, so you can check the changelog history 
+to know who did import the package and/or work essentially on the package.
+
+
+> I also asked you if was possible to join the kde team, but you have
+> ignored those emails.
+I did not ignore them, i just did not notice them until you just pointed them 
+to me.
+We do have a kde channel on #mageia-kde so you're of course welcome to join 
+us.
+
+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-June/005419.html b/zarb-ml/mageia-dev/2011-June/005419.html new file mode 100644 index 000000000..6136525dc --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005419.html @@ -0,0 +1,218 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ andre999 + andr55 at laposte.net +
+ Sun Jun 12 06:52:27 CEST 2011 +

+
+ +
Samuel Verschelde a écrit :
+> Le samedi 11 juin 2011 18:01:54, Maarten Vanraes a écrit :
+>  > Op zaterdag 11 juni 2011 16:55:00 schreef Samuel Verschelde:
+>  > > Le samedi 11 juin 2011 14:26:19, Maarten Vanraes a écrit :
+>  > > > Op zaterdag 11 juni 2011 13:14:29 schreef Samuel Verschelde:
+>  > > > > Le samedi 11 juin 2011 12:06:55, Christiaan Welvaart a écrit :
+>  > > > > > On Fri, 10 Jun 2011, Michael Scherer wrote:
+>  > > > > > > We can agree that everybody want something newer for some rpms,
+>  > > > > > > but few people want everything to be newer ( ie, now one run
+>  > > > > > > backports as a update media, I think ). So as much as I am
+>  > > > > > > against asking to users questions, we must show them the choice
+>  > > > > > > somewhere, in a non obstrusive way.
+>  > > > > >
+>  > > > > > Maybe, but how would be "support" this? We must be able to
+>  > > > > > reproduce a reported problem. This becomes complicated when we
+>  > > > > > don't know what is installed on the user's system. A guideline for
+>  > > > > > bug reporters is (or should be) "make sure you installed the
+>  > > > > > latest updates". What would be the equivalent for backports? I'm
+>  > > > > > afraid it should be "if you installed any backports, make sure you
+>  > > > > > installed all backports that are relevant for your system". If
+>  > > > > > someone has a problem with any other combination, the bug report
+>  > > > > > might be rejected. How would QA even work when only selected
+>  > > > > > packages are upgraded from backports, or integration testing:
+>  > > > > > integration with what?
+>  > > > > >
+>  > > > > > So the only combinations we can support are:
+>  > > > > > - release + updates
+>  > > > > > - release + updates + backports
+>  > > > > >
+>  > > > > > More practical: for mga1 I have a VM that I can keep updated. For
+>  > > > > > mga1 backports I can install another VM with backports enabled. But
+>  > > > > > for bugs reported with only selected backports installed I suppose
+>  > > > > > I would have to install a new VM with mga1, update it, and install
+>  > > > > > only those backports -
+>  > > > > >
+>  > > > > > for each bug report. But maybe I'm missing something, please
+>  > > > > > explain.
+>  >
+>  > (:
+>  > > > > If we suppose that either updates or backports are supported (with a
+>  > > > > support level to be defined), the situation is simpler to me : a
+>  > > > > good backport must work with all its dependencies coming from
+>  > > > > updates or release OR it must explicitly require higher versions,
+>  > > > > found only in the backports media and so automatically pulled.
+>  > > > >
+>  > > > > So I don't think that having picked up only certain backported
+>  > > > > packages is a problem for the maintainer's support. Maybe I
+>  > > > > over-simplified the situation, but I don't think it will be as
+>  > > > > complex as you say.
+>  > > > >
+>  > > > > Samuel
+>  > > >
+>  > > > imho this creates more work for packagers or qa team to support
+>  > > > backports, i'm not really in favor of this solution
+>  > >
+>  > > So it someone has a problem with a package you backported and  reports it
+>  > > in bugzilla, you'll answer "not supported" and close the door ? Then we
+>  > > have not a single chance to have users accept to use backports rather
+>  > > than ask for a rolling release (supposing that we want to stay with
+>  > > stable releases model, which hasn't been decided yet).
+
+Not only would users tend to avoid backports, they would tend to avoid Mageia after a bad experience.
+
+>  > > In my opinion, a backport must be either supported or not exist.  Even in
+>  > > Mandriva, where everybody keep saying "backports ain't supported",
+>  > > usually people try to solve the problems caused by backports.
+>  > >
+>  > > However, the level of support can be different between backports and
+>  > > updates, as I said in my previous message. The differences are yet to
+>  > > define, but here are some I see :
+>  > > - when a critical bug in a backport exists, you can simply update to a
+>  > > newer version and see if it's solved
+>  > > - if the program already is in its the latest version and has an upstream
+>  > > bug, you can answer "report the bug upstream" and stop there until
+>  > > upstream solves the bug. For packages in release or updates, ideally you
+>  > > have to try to help fixing it or work it around because the bug is
+>  > > considered part of the whole distribution.
+
+Exactly.  Backports supported, but to a lesser degree.
+
+>  > > Best regards
+>  > >
+>  > > Samuel
+>  >
+>  > What about security fixes? if there's 1 version in release and 10 in
+>  > backports? do the older backported packages have to be securitypatched?
+>  >
+>  > imho not supported backports means that if backports has an issue, try a
+>  > newer backports...
+>  >
+>  > imho that is a good level, that doesn't require much effort.
+>
+> I think we agree, because if we follow the Mandriva way, upload of a new
+> backport for a given package removes the old one if there is one. So at
+> a given time, you only have to support the package in release or updates
+> + 0 or 1 backport.
+>
+> Samuel
+
+I think that this is a good approach to the issue.
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005420.html b/zarb-ml/mageia-dev/2011-June/005420.html new file mode 100644 index 000000000..1f6395701 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005420.html @@ -0,0 +1,194 @@ + + + + [Mageia-dev] [104363] SILENT: new binary files SOURCES/ia_ora-kde4-0.3.2.tar.bz2 + + + + + + + + + +

[Mageia-dev] [104363] SILENT: new binary files SOURCES/ia_ora-kde4-0.3.2.tar.bz2

+ Zé + mmodem00 at gmail.com +
+ Sun Jun 12 07:33:26 CEST 2011 +

+
+ +
2011/6/12 Balcaen John <mikala at mageia.org>:
+> Le dimanche 12 juin 2011 00:46:56, Zé a écrit :
+> [...]
+>> > Could you please *ask* before updating a package ?
+>> > That's not the first time you're doing some changes/patchs without even
+> asking
+>> > before....
+>>
+>> Like i said in the mail i first sent you i did said that i shoud have
+>> done it and it just passed me, in fact i did mailed you reporting
+>> this, so it wasnt all like not saying any.
+>
+> Sorry but  i did not read/notice your mail before noticing the commit & the
+> package on changelog...
+>
+>> In the other 2 changes i made in kde, i did discussed one first with
+>> you and the other i did also discussed it but was in fact after the
+>> commit.
+>> Regarding this one i first queried sophie to see if this was a
+>> maintained package in wich there wasnt any output so i commited and
+>> then i realized that even without being set as maintained by someone
+>> it was still a kde package, so then i mailed you reporting it in wich
+>> i also stated that i would from now on first discuss with you any
+>> changes i would have in mind.
+> There's no maintainer database for now, so you can check the changelog history
+> to know who did import the package and/or work essentially on the package.
+>
+>
+>> I also asked you if was possible to join the kde team, but you have
+>> ignored those emails.
+> I did not ignore them, i just did not notice them until you just pointed them
+> to me.
+> We do have a kde channel on #mageia-kde so you're of course welcome to join
+> us.
+
+What i was refering, was if i can officially join the kde packaging team.
+
+> Regards,
+>
+>
+> --
+> Balcaen John
+> Jabber ID: mikala at jabber.littleboboy.net
+>
+
+
+
+-- 
+Zé
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005421.html b/zarb-ml/mageia-dev/2011-June/005421.html new file mode 100644 index 000000000..574fef0e4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005421.html @@ -0,0 +1,161 @@ + + + + [Mageia-dev] perl 5.14.0 should arrive soon + + + + + + + + + +

[Mageia-dev] perl 5.14.0 should arrive soon

+ Jerome Quelin + jquelin at gmail.com +
+ Sun Jun 12 09:39:41 CEST 2011 +

+
+ +
On 11/06/12 01:22 +0100, Zé wrote:
+> Theres a new version for perl-CGI.
+> I have asked sophie whos the maintainer for perl-CGI wich got no
+> answer, asked sanders about it and tould me you would be the person
+> indicated.
+
+as i said, i'd like to have perl 5.14 in place before updating the
+module to their latest cpan version. (unless it's needed to work with
+5.14 of course!)
+
+note that once perl 5.14 transition is done, updating the packages is
+quite easy with magpie - just run the following:
+
+    $ magpie dwim
+
+and you're done (well, you'll have to check whether it builds fine on
+bs).
+
+jérôme 
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005422.html b/zarb-ml/mageia-dev/2011-June/005422.html new file mode 100644 index 000000000..601434449 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005422.html @@ -0,0 +1,165 @@ + + + + [Mageia-dev] [104363] SILENT: new binary files SOURCES/ia_ora-kde4-0.3.2.tar.bz2 + + + + + + + + + +

[Mageia-dev] [104363] SILENT: new binary files SOURCES/ia_ora-kde4-0.3.2.tar.bz2

+ Michael Scherer + misc at zarb.org +
+ Sun Jun 12 09:43:56 CEST 2011 +

+
+ +
Le dimanche 12 juin 2011 à 06:33 +0100, Zé a écrit :
+> 2011/6/12 Balcaen John <mikala at mageia.org>:
+> > Le dimanche 12 juin 2011 00:46:56, Zé a écrit :
+> >> I also asked you if was possible to join the kde team, but you have
+> >> ignored those emails.
+> > I did not ignore them, i just did not notice them until you just pointed them
+> > to me.
+> > We do have a kde channel on #mageia-kde so you're of course welcome to join
+> > us.
+> 
+> What i was refering, was if i can officially join the kde packaging team.
+
+There is no officially any kde team ( no specific ressources, no alias,
+no group in ldap ) and there is no plan to have one before any plan
+about what it would need and mean have been discussed ( and no plan if
+they are not generic enough ).
+ 
+There is just a group of 2 people, and a irc channel.
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005423.html b/zarb-ml/mageia-dev/2011-June/005423.html new file mode 100644 index 000000000..20d3ae1dc --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005423.html @@ -0,0 +1,132 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Michael Scherer + misc at zarb.org +
+ Sun Jun 12 10:10:48 CEST 2011 +

+
+ +
Le vendredi 10 juin 2011 à 20:12 +0200, Daniel Kreuter a écrit :
+
+> 
+> I would also suggest to jump directly to Gnome 3.2 instead of 3.0 in Mageia
+> 2 because they want to fix some of the annoying bugs and implement some cool
+> features like the integration of Zeitgeist.
+
+It is better to first do the integration using a stable version of the
+software ( so we are sure that the problem comes from us ). 
+
+Moreover, if we aim to have testers, we must keep cauldron in a runnable
+state, and integrating the git version of gnome-shell do not look like a
+step in this directions. While there is no guarantee of being usable, we
+can at least do our best to make it happens.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005424.html b/zarb-ml/mageia-dev/2011-June/005424.html new file mode 100644 index 000000000..f61eba0ee --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005424.html @@ -0,0 +1,77 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Angelo Naselli + anaselli at linux.it +
+ Sun Jun 12 14:25:50 CEST 2011 +

+
+ +
In data mercoledì 8 giugno 2011 23:53:51, Ahmad Samir ha scritto:
+> >> Right, I probably phrased that one wrongly; I meant:
+> >> fixes a serious bug, e.g. crashing, segfaulting
+> > 
+> > I don't think we should exclude non-serious bugs :)
+> 
+> Depends, overworking the sec team doesn't look like a good aspect...
+> (that's why I liked contrib in mdv, I could push an update any time,
+> without having to go though the bug report -> QA -> Sec team loop).
+Well here we could stop at QA team step, or at least someone more that can 
+test  and say that the fixing is good...
+
+-- 
+	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/20110612/d793c819/attachment.asc>
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005425.html b/zarb-ml/mageia-dev/2011-June/005425.html new file mode 100644 index 000000000..0d91331ca --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005425.html @@ -0,0 +1,155 @@ + + + + [Mageia-dev] KDE SC 4.6.4 + + + + + + + + + +

[Mageia-dev] KDE SC 4.6.4

+ Daniel Kreuter + daniel.kreuter85 at googlemail.com +
+ Sun Jun 12 14:39:20 CEST 2011 +

+
+ +
Hello,
+
+will we get this as update for Mageia 1?
+
+-- 
+Mit freundlichen Grüßen
+
+Greetings
+
+Daniel Kreuter
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110612/470d84ba/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005426.html b/zarb-ml/mageia-dev/2011-June/005426.html new file mode 100644 index 000000000..bd2683972 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005426.html @@ -0,0 +1,155 @@ + + + + [Mageia-dev] KDE SC 4.6.4 + + + + + + + + + +

[Mageia-dev] KDE SC 4.6.4

+ Balcaen John + mikala at mageia.org +
+ Sun Jun 12 15:10:02 CEST 2011 +

+
+ +
Le dimanche 12 juin 2011 09:39:20, Daniel Kreuter a écrit :
+> Hello,
+> 
+> will we get this as update for Mageia 1?
+> 
+It's ready in svn, i'm just waiting for the perl update before pushing it so 
+probably today.
+
+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-June/005427.html b/zarb-ml/mageia-dev/2011-June/005427.html new file mode 100644 index 000000000..92c4630fc --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005427.html @@ -0,0 +1,157 @@ + + + + [Mageia-dev] KDE SC 4.6.4 + + + + + + + + + +

[Mageia-dev] KDE SC 4.6.4

+ Thomas Backlund + tmb at mageia.org +
+ Sun Jun 12 15:14:35 CEST 2011 +

+
+ +
On 12.6.2011 16:10, Balcaen John wrote:
+> Le dimanche 12 juin 2011 09:39:20, Daniel Kreuter a écrit :
+>> Hello,
+>>
+>> will we get this as update for Mageia 1?
+>>
+> It's ready in svn, i'm just waiting for the perl update before pushing it so
+> probably today.
+>
+
+For Cauldron that is... AFAIK not decided yet for mga1
+
+--
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005428.html b/zarb-ml/mageia-dev/2011-June/005428.html new file mode 100644 index 000000000..e95f64a4d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005428.html @@ -0,0 +1,225 @@ + + + + [Mageia-dev] "Job offer" : mentoring program coordinator + + + + + + + + + +

[Mageia-dev] "Job offer" : mentoring program coordinator

+ Samuel Verschelde + stormi at laposte.net +
+ Sun Jun 12 15:27:59 CEST 2011 +

+
+ +
Hello to everyone,
+
+I'm sure there's someone among you who wants to help Mageia but hasn't found 
+yet the good way to do it. Today is your lucky day, because there's a job 
+that's available and can be really useful and interesting: coordinating the 
+packagers mentoring program.
+
+You know that one key point of success for Mageia is in the ability to welcome 
+new packagers. The better we will be at it, the better the distro will be. The 
+packagers mentoring program has been created for that reason and several 
+packagers have been or are being mentored. But we have some difficulty knowing 
+who is being mentored by who and who hasn't found a mentor. And we need also 
+to find more mentors and more apprentices.
+
+During a packagers weekly meeting, misc invited us to read the following 
+article about mentoring programs in open-source projects: 
+http://blogs.gnome.org/bolsh/2011/05/31/effective-mentoring-programs/
+
+I invite those who haven't read it yet, to read it. I'll quote one of the 
+mentoring best practices that were given: "In bigger projects, keeping track 
+of who is a mentor, and who is mentoring who, and inviting new mentors, and 
+ensuring that no-one falls through the cracks when a mentor gets too busy, is 
+a job of itself."
+
+I'm looking for someone who could fill that "job".
+
+Description of the job:
+
+- keep track of:
+-- who's being mentored by who, how well it's going
+-- who needs a mentor and hasn't found one yet (this is one of the most 
+important parts: no volunteer must be forgotten, volunteers are too precious 
+!)
+-- who can mentor more apprentices (and sometimes convince packagers to become 
+mentors or accept one more apprentice)
+
+- be available for questions from apprentices or mentors, by mail, and if 
+possible, to be present on the IRC channel #mageia-mentoring on freenode
+
+- help mentors with gathering "junior tasks" (bugzilla is a never empty 
+reserve that can be used for that. Maybe ask the bug triage team to help 
+identify such tasks. Maybe a "junior task" keyword in bugzilla would do the 
+trick)
+-- small bugs to fix
+-- new small packages to import in the distribution
+-- backports
+
+- promote mentoring (empower users into contributers. Working with the 
+marketing team would be great I think):
+-- make the mentoring program known (MLs, forums, web, etc.)
+-- look for new apprentices
+-- look for new mentors
+
+Some useful skills:
+- be autonomous (ie no need to check that you're doing the work)
+- good written english (communication is very important in this job)
+- knowledge about packaging is a plus but not mandatory (the key aspects can 
+be taught to you)
+- being or having been a mentor, or having been mentored would be a plus, but 
+not mandatory
+
+More information about the job:
+- does not require a big amount of work, but real committment to the task and 
+regularity
+- remember that you have a coordination role, not an authoritative role. The 
+difference in that is that you're not here to give orders but to facilitate the 
+mentoring program.
+- you don't have to be alone to do this job if it's too much for one person: 
+you can find other helpful people wanting to help you if needed and rely on the 
+other teams (but finding them *is* part of your job ;) ).
+-  this "job offer" concerns everything that revolves around the mentoring of 
+new packagers, but if it's successful maybe other teams can follow the same 
+approach (i18n, QA, etc... ).
+-  depending on your level of confidence, experience and will, you could be 
+helped in your work. Maybe someone from the council can supervise and help you 
+at least at the beginning; or, if no one steps up, I can help you bootstrap 
+and organize your new "job".
+
+So, who's in?
+
+Samuel Verschelde
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005429.html b/zarb-ml/mageia-dev/2011-June/005429.html new file mode 100644 index 000000000..194586265 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005429.html @@ -0,0 +1,162 @@ + + + + [Mageia-dev] KDE SC 4.6.4 + + + + + + + + + +

[Mageia-dev] KDE SC 4.6.4

+ Balcaen John + mikala at mageia.org +
+ Sun Jun 12 15:32:57 CEST 2011 +

+
+ +
Le dimanche 12 juin 2011 10:14:35, Thomas Backlund a écrit :
+> On 12.6.2011 16:10, Balcaen John wrote:
+> > Le dimanche 12 juin 2011 09:39:20, Daniel Kreuter a écrit :
+> >> Hello,
+> >>
+> >> will we get this as update for Mageia 1?
+> >>
+> > It's ready in svn, i'm just waiting for the perl update before pushing it 
+so
+> > probably today.
+> >
+> 
+> For Cauldron that is... AFAIK not decided yet for mga1
+I'll be pleased to provide all 4.6.x update for mageia1 but we need indeed to 
+check how is it possible to handle that with qa team.
+
+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-June/005430.html b/zarb-ml/mageia-dev/2011-June/005430.html new file mode 100644 index 000000000..251d22fe2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005430.html @@ -0,0 +1,273 @@ + + + + [Mageia-dev] "Job offer" : mentoring program coordinator + + + + + + + + + +

[Mageia-dev] "Job offer" : mentoring program coordinator

+ Daniel Kreuter + daniel.kreuter85 at googlemail.com +
+ Sun Jun 12 17:43:38 CEST 2011 +

+
+ +
On Sun, Jun 12, 2011 at 3:27 PM, Samuel Verschelde <stormi at laposte.net>wrote:
+
+> Hello to everyone,
+>
+> I'm sure there's someone among you who wants to help Mageia but hasn't
+> found
+> yet the good way to do it. Today is your lucky day, because there's a job
+> that's available and can be really useful and interesting: coordinating the
+> packagers mentoring program.
+>
+> You know that one key point of success for Mageia is in the ability to
+> welcome
+> new packagers. The better we will be at it, the better the distro will be.
+> The
+> packagers mentoring program has been created for that reason and several
+> packagers have been or are being mentored. But we have some difficulty
+> knowing
+> who is being mentored by who and who hasn't found a mentor. And we need
+> also
+> to find more mentors and more apprentices.
+>
+> During a packagers weekly meeting, misc invited us to read the following
+> article about mentoring programs in open-source projects:
+> http://blogs.gnome.org/bolsh/2011/05/31/effective-mentoring-programs/
+>
+> I invite those who haven't read it yet, to read it. I'll quote one of the
+> mentoring best practices that were given: "In bigger projects, keeping
+> track
+> of who is a mentor, and who is mentoring who, and inviting new mentors, and
+> ensuring that no-one falls through the cracks when a mentor gets too busy,
+> is
+> a job of itself."
+>
+> I'm looking for someone who could fill that "job".
+>
+> Description of the job:
+>
+> - keep track of:
+> -- who's being mentored by who, how well it's going
+> -- who needs a mentor and hasn't found one yet (this is one of the most
+> important parts: no volunteer must be forgotten, volunteers are too
+> precious
+> !)
+> -- who can mentor more apprentices (and sometimes convince packagers to
+> become
+> mentors or accept one more apprentice)
+>
+> - be available for questions from apprentices or mentors, by mail, and if
+> possible, to be present on the IRC channel #mageia-mentoring on freenode
+>
+> - help mentors with gathering "junior tasks" (bugzilla is a never empty
+> reserve that can be used for that. Maybe ask the bug triage team to help
+> identify such tasks. Maybe a "junior task" keyword in bugzilla would do the
+> trick)
+> -- small bugs to fix
+> -- new small packages to import in the distribution
+> -- backports
+>
+> - promote mentoring (empower users into contributers. Working with the
+> marketing team would be great I think):
+> -- make the mentoring program known (MLs, forums, web, etc.)
+> -- look for new apprentices
+> -- look for new mentors
+>
+> Some useful skills:
+> - be autonomous (ie no need to check that you're doing the work)
+> - good written english (communication is very important in this job)
+> - knowledge about packaging is a plus but not mandatory (the key aspects
+> can
+> be taught to you)
+> - being or having been a mentor, or having been mentored would be a plus,
+> but
+> not mandatory
+>
+> More information about the job:
+> - does not require a big amount of work, but real committment to the task
+> and
+> regularity
+> - remember that you have a coordination role, not an authoritative role.
+> The
+> difference in that is that you're not here to give orders but to facilitate
+> the
+> mentoring program.
+> - you don't have to be alone to do this job if it's too much for one
+> person:
+> you can find other helpful people wanting to help you if needed and rely on
+> the
+> other teams (but finding them *is* part of your job ;) ).
+> -  this "job offer" concerns everything that revolves around the mentoring
+> of
+> new packagers, but if it's successful maybe other teams can follow the same
+> approach (i18n, QA, etc... ).
+> -  depending on your level of confidence, experience and will, you could be
+> helped in your work. Maybe someone from the council can supervise and help
+> you
+> at least at the beginning; or, if no one steps up, I can help you bootstrap
+> and organize your new "job".
+>
+> So, who's in?
+>
+> Samuel Verschelde
+>
+>
+Hello Samuel,
+
+the offer sounds nice. Maybe I can give it a try?
+
+What do I already have in my mind?
+
+- Creating a table on Mageia wiki where someone who wants to be mentored can
+put his name on, + the date he enters his name (so we can see how long he's
+waiting for a mentor)
+- A table with all available mentors and the actual apprentices
+- On a regular base asking the mentors if they can mentor someone new or if
+his apprentice is ready for a full membership
+- Regular meeting where everyone can vote for a full mentorship of an
+apprentice
+
+So what do you think?
+
+
+
+-- 
+Mit freundlichen Grüßen
+
+Greetings
+
+Daniel Kreuter
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110612/59929418/attachment-0001.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005431.html b/zarb-ml/mageia-dev/2011-June/005431.html new file mode 100644 index 000000000..b079b0489 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005431.html @@ -0,0 +1,184 @@ + + + + [Mageia-dev] "Job offer" : mentoring program coordinator + + + + + + + + + +

[Mageia-dev] "Job offer" : mentoring program coordinator

+ Samuel Verschelde + stormi at laposte.net +
+ Sun Jun 12 17:58:20 CEST 2011 +

+
+ +
Le dimanche 12 juin 2011 17:43:38, Daniel Kreuter a écrit :
+> Hello Samuel,
+> 
+> the offer sounds nice. Maybe I can give it a try?
+
+I feared I would get no volunteer, so I sure won't say no ! I just want to 
+wait a bit just in case there would be several volunteers, but I'm really glad 
+you proposed your help :)
+
+> 
+> What do I already have in my mind?
+> 
+> - Creating a table on Mageia wiki where someone who wants to be mentored
+> can put his name on, + the date he enters his name (so we can see how long
+> he's waiting for a mentor)
+> - A table with all available mentors and the actual apprentices
+
+Those already exist but need to be maintained because they're often out of 
+date :  http://mageia.org/wiki/doku.php?id=packages_mentoring
+
+But this page must not be the only place where you should look for 
+apprentices. IIRC the standard procedure is to create a mentoring request on 
+bugzilla (or is it only to ask for an account ?), and we must not forget those 
+who ask in the mailing lists.
+
+> - On a regular base asking the mentors if they can mentor someone new or if
+> his apprentice is ready for a full membership
+
+This would be great yes.
+
+> - Regular meeting where everyone can vote for a full mentorship of an
+> apprentice
+
+I don't know if this is needed in your "job", because AFAIK each mentors 
+decides alone when his apprentice is ready.
+
+Best regards
+
+Samuel
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110612/99d16db2/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005432.html b/zarb-ml/mageia-dev/2011-June/005432.html new file mode 100644 index 000000000..edf61902d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005432.html @@ -0,0 +1,187 @@ + + + + [Mageia-dev] "Job offer" : mentoring program coordinator + + + + + + + + + +

[Mageia-dev] "Job offer" : mentoring program coordinator

+ Samuel Verschelde + stormi at laposte.net +
+ Sun Jun 12 18:03:43 CEST 2011 +

+
+ +
Le dimanche 12 juin 2011 17:58:20, Samuel Verschelde a écrit :
+> Le dimanche 12 juin 2011 17:43:38, Daniel Kreuter a écrit :
+> > Hello Samuel,
+> > 
+> > the offer sounds nice. Maybe I can give it a try?
+> 
+> I feared I would get no volunteer, so I sure won't say no ! I just want to
+> wait a bit just in case there would be several volunteers, but I'm really
+> glad you proposed your help :)
+> 
+> > What do I already have in my mind?
+> > 
+> > - Creating a table on Mageia wiki where someone who wants to be mentored
+> > can put his name on, + the date he enters his name (so we can see how
+> > long he's waiting for a mentor)
+> > - A table with all available mentors and the actual apprentices
+> 
+> Those already exist but need to be maintained because they're often out of
+> date :  http://mageia.org/wiki/doku.php?id=packages_mentoring
+> 
+> But this page must not be the only place where you should look for
+> apprentices. IIRC the standard procedure is to create a mentoring request
+> on bugzilla (or is it only to ask for an account ?), and we must not
+> forget those who ask in the mailing lists.
+> 
+> > - On a regular base asking the mentors if they can mentor someone new or
+> > if his apprentice is ready for a full membership
+> 
+> This would be great yes.
+> 
+> > - Regular meeting where everyone can vote for a full mentorship of an
+> > apprentice
+> 
+> I don't know if this is needed in your "job", because AFAIK each mentors
+> decides alone when his apprentice is ready.
+> 
+> Best regards
+> 
+> Samuel
+
+Sorry for the HTML message, I don't know why kmail suddenly decided to send 
+messages sometimes in text and sometimes in HTML :/
+
+Samuel
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005433.html b/zarb-ml/mageia-dev/2011-June/005433.html new file mode 100644 index 000000000..a171c27a1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005433.html @@ -0,0 +1,245 @@ + + + + [Mageia-dev] weird bs behaviour + + + + + + + + + +

[Mageia-dev] weird bs behaviour

+ Jerome Quelin + jquelin at gmail.com +
+ Sun Jun 12 18:13:32 CEST 2011 +

+
+ +
hi,
+
+when rebuilding perl-DBD-SQLite and perl -DBD-SQLite2, i get some
+strange cpio errors:
+
+=== PASTE ===
++ /usr/bin/perl Makefile.PL INSTALLDIRS=vendor
+Checking if your kit is complete...
+Looks good
+Using DBI 1.616 (for perl 5.014000 on i386-linux-thread-multi) installed in /usr/lib/perl5/vendor_perl/5.14.0/i386-linux-thread-multi/auto/DBI/
+Writing Makefile for DBD::SQLite
+Writing MYMETA.yml
++ make -j8 'CCFLAGS=-O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fomit-frame-pointer -march=i586 -mtune=generic -fasynchronous-unwind-tables -DNDEBUG=1 -DSQLITE_PTR_SZ=4'
+/usr/bin/perl5.14.0 -p -e "s/~DRIVER~/SQLite/g" /usr/lib/perl5/vendor_perl/5.14.0/i386-linux-thread-multi/auto/DBI/Driver.xst > SQLite.xsi
+i586-mageia-linux-gnu-gcc -c  -I. -I/usr/lib/perl5/vendor_perl/5.14.0/i386-linux-thread-multi/auto/DBI -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fomit-frame-pointer -march=i586 -mtune=generic -fasynchronous-unwind-tables -DNDEBUG=1 -DSQLITE_PTR_SZ=4 -O2   -DVERSION=\"1.33\" -DXS_VERSION=\"1.33\" -fPIC "-I/usr/lib/perl5/5.14.0/i386-linux-thread-multi/CORE"  -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_FTS3_PARENTHESIS -DSQLITE_ENABLE_RTREE -DSQLITE_ENABLE_COLUMN_METADATA -DNDEBUG=1 -DHAVE_USLEEP=1 dbdimp.c
+i586-mageia-linux-gnu-gcc -c  -I. -I/usr/lib/perl5/vendor_perl/5.14.0/i386-linux-thread-multi/auto/DBI -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fomit-frame-pointer -march=i586 -mtune=generic -fasynchronous-unwind-tables -DNDEBUG=1 -DSQLITE_PTR_SZ=4 -O2   -DVERSION=\"1.33\" -DXS_VERSION=\"1.33\" -fPIC "-I/usr/lib/perl5/5.14.0/i386-linux-thread-multi/CORE"  -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_FTS3_PARENTHESIS -DSQLITE_ENABLE_RTREE -DSQLITE_ENABLE_COLUMN_METADATA -DNDEBUG=1 -DHAVE_USLEEP=1 sqlite3.c
+Running Mkbootstrap for DBD::SQLite ()
+/usr/bin/perl5.14.0 /usr/lib/perl5/5.14.0/ExtUtils/xsubpp  -typemap /usr/lib/perl5/5.14.0/ExtUtils/typemap  SQLite.xs > SQLite.xsc && mv SQLite.xsc SQLite.c
+chmod 644 SQLite.bs
+cp SQLite.bs blib/arch/auto/DBD/SQLite/SQLite.bs
+chmod 644 blib/arch/auto/DBD/SQLite/SQLite.bs
+cp lib/DBD/SQLite.pm blib/lib/DBD/SQLite.pm
+cp lib/DBD/SQLite/Cookbook.pod blib/lib/DBD/SQLite/Cookbook.pod
+i586-mageia-linux-gnu-gcc -c  -I. -I/usr/lib/perl5/vendor_perl/5.14.0/i386-linux-thread-multi/auto/DBI -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fomit-frame-pointer -march=i586 -mtune=generic -fasynchronous-unwind-tables -DNDEBUG=1 -DSQLITE_PTR_SZ=4 -O2   -DVERSION=\"1.33\" -DXS_VERSION=\"1.33\" -fPIC "-I/usr/lib/perl5/5.14.0/i386-linux-thread-multi/CORE"  -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_FTS3_PARENTHESIS -DSQLITE_ENABLE_RTREE -DSQLITE_ENABLE_COLUMN_METADATA -DNDEBUG=1 -DHAVE_USLEEP=1 SQLite.c
+rm -f blib/arch/auto/DBD/SQLite/SQLite.so
+i586-mageia-linux-gnu-gcc  -shared -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fomit-frame-pointer -march=i586 -mtune=generic -fasynchronous-unwind-tables -L/usr/local/lib SQLite.o dbdimp.o sqlite3.o  -o blib/arch/auto/DBD/SQLite/SQLite.so  \
+        \
+  
+chmod 755 blib/arch/auto/DBD/SQLite/SQLite.so
+Manifying blib/man3/DBD::SQLite.3pm
+Manifying blib/man3/DBD::SQLite::Cookbook.3pm
++ exit 0
+Executing(%install): /bin/sh -e /home/iurt/rpm/tmp/rpm-tmp.Pf7CFt
++ umask 022
++ cd /home/iurt/rpm/BUILD
++ cd DBD-SQLite-1.33
++ '[' 1 -eq 1 ']'
++ rm -rf /home/iurt/rpm/BUILDROOT/perl-DBD-SQLite-1.330.0-1.mga2.i386
++ make DESTDIR=/home/iurt/rpm/BUILDROOT/perl-DBD-SQLite-1.330.0-1.mga2.i386 install
+Files found in blib/arch: installing files in blib/lib into architecture dependent library tree
+Installing /home/iurt/rpm/BUILDROOT/perl-DBD-SQLite-1.330.0-1.mga2.i386/usr/lib/perl5/vendor_perl/5.14.0/i386-linux-thread-multi/auto/DBD/SQLite/SQLite.bs
+Installing /home/iurt/rpm/BUILDROOT/perl-DBD-SQLite-1.330.0-1.mga2.i386/usr/lib/perl5/vendor_perl/5.14.0/i386-linux-thread-multi/auto/DBD/SQLite/SQLite.so
+Installing /home/iurt/rpm/BUILDROOT/perl-DBD-SQLite-1.330.0-1.mga2.i386/usr/lib/perl5/vendor_perl/5.14.0/i386-linux-thread-multi/DBD/SQLite.pm
+Installing /home/iurt/rpm/BUILDROOT/perl-DBD-SQLite-1.330.0-1.mga2.i386/usr/lib/perl5/vendor_perl/5.14.0/i386-linux-thread-multi/DBD/SQLite/Cookbook.pod
+Installing /home/iurt/rpm/BUILDROOT/perl-DBD-SQLite-1.330.0-1.mga2.i386/usr/lib/perl5/vendor_perl/5.14.0/i386-linux-thread-multi/auto/share/dist/DBD-SQLite/sqlite3.h
+Installing /home/iurt/rpm/BUILDROOT/perl-DBD-SQLite-1.330.0-1.mga2.i386/usr/lib/perl5/vendor_perl/5.14.0/i386-linux-thread-multi/auto/share/dist/DBD-SQLite/sqlite3.c
+Installing /home/iurt/rpm/BUILDROOT/perl-DBD-SQLite-1.330.0-1.mga2.i386/usr/share/man/man3/DBD::SQLite.3pm
+Installing /home/iurt/rpm/BUILDROOT/perl-DBD-SQLite-1.330.0-1.mga2.i386/usr/share/man/man3/DBD::SQLite::Cookbook.3pm
+Appending installation info to /home/iurt/rpm/BUILDROOT/perl-DBD-SQLite-1.330.0-1.mga2.i386/usr/lib/perl5/5.14.0/i386-linux-thread-multi/perllocal.pod
++ rm -f /home/iurt/rpm/BUILDROOT/perl-DBD-SQLite-1.330.0-1.mga2.i386/usr/lib/perl5/vendor_perl/5.14.0/i386-linux-thread-multi/auto/share/dist/DBD-SQLite/sqlite3.c
++ rm -f /home/iurt/rpm/BUILDROOT/perl-DBD-SQLite-1.330.0-1.mga2.i386/usr/lib/perl5/vendor_perl/5.14.0/i386-linux-thread-multi/auto/share/dist/DBD-SQLite/sqlite3.h
++ /usr/lib/rpm/mageia/find-debuginfo.sh /home/iurt/rpm/BUILD/DBD-SQLite-1.33
+
+extracting debug info from /home/iurt/rpm/BUILDROOT/perl-DBD-SQLite-1.330.0-1.mga2.i386/usr/lib/perl5/vendor_perl/5.14.0/i386-linux-thread-multi/auto/DBD/SQLite/SQLite.so
+*** WARNING: No build ID note found in /home/iurt/rpm/BUILDROOT/perl-DBD-SQLite-1.330.0-1.mga2.i386/usr/lib/perl5/vendor_perl/5.14.0/i386-linux-thread-multi/auto/DBD/SQLite/SQLite.so
+cpio: gcc-4.5.2/gcc/libgcc2.c: Cannot stat: No such file or directory
+cpio: gcc-4.5.2/gcc/libgcc2.h: Cannot stat: No such file or directory
+cpio: gcc-4.5.2/obj-i586-mageia-linux-gnu/gcc/include/stddef.h: Cannot stat: No such file or directory
+cpio: gcc-4.5.2/obj-i586-mageia-linux-gnu/i586-mageia-linux-gnu/libgcc: Cannot stat: No such file or directory
+cpio: glibc-2.12.1/bits/types.h: Cannot stat: No such file or directory
+cpio: glibc-2.12.1/debug: Cannot stat: No such file or directory
+cpio: glibc-2.12.1/debug/stack_chk_fail_local.c: Cannot stat: No such file or directory
+cpio: glibc-2.12.1/io: Cannot stat: No such file or directory
+cpio: glibc-2.12.1/io/fstat64.c: Cannot stat: No such file or directory
+cpio: glibc-2.12.1/io/stat64.c: Cannot stat: No such file or directory
+cpio: glibc-2.12.1/sysdeps/unix/sysv/linux/bits/stat.h: Cannot stat: No such file or directory
+cpio: glibc-2.12.1/time/time.h: Cannot stat: No such file or directory
+9611 blocks
+=== /PASTE ===
+
+of course, tests fail afterwards.
+
+however, building perl-DBD-SQLite module in iurt on my machine yields no
+problem. (note that my machine is a x86_64, whereas the build fails on
+i586 bs node - but i don't know if it's related).
+
+==> can someone more fluent with the bs / rpm can help please?
+
+thanks,
+jérôme 
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005434.html b/zarb-ml/mageia-dev/2011-June/005434.html new file mode 100644 index 000000000..3c67e6a5e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005434.html @@ -0,0 +1,237 @@ + + + + [Mageia-dev] "Job offer" : mentoring program coordinator + + + + + + + + + +

[Mageia-dev] "Job offer" : mentoring program coordinator

+ Cazzaniga Sandro + cazzaniga.sandro at gmail.com +
+ Sun Jun 12 18:55:58 CEST 2011 +

+
+ +
Le 12/06/2011 15:27, Samuel Verschelde a écrit :
+> Hello to everyone,
+> 
+> I'm sure there's someone among you who wants to help Mageia but hasn't found 
+> yet the good way to do it. Today is your lucky day, because there's a job 
+> that's available and can be really useful and interesting: coordinating the 
+> packagers mentoring program.
+> 
+> You know that one key point of success for Mageia is in the ability to welcome 
+> new packagers. The better we will be at it, the better the distro will be. The 
+> packagers mentoring program has been created for that reason and several 
+> packagers have been or are being mentored. But we have some difficulty knowing 
+> who is being mentored by who and who hasn't found a mentor. And we need also 
+> to find more mentors and more apprentices.
+> 
+> During a packagers weekly meeting, misc invited us to read the following 
+> article about mentoring programs in open-source projects: 
+> http://blogs.gnome.org/bolsh/2011/05/31/effective-mentoring-programs/
+> 
+> I invite those who haven't read it yet, to read it. I'll quote one of the 
+> mentoring best practices that were given: "In bigger projects, keeping track 
+> of who is a mentor, and who is mentoring who, and inviting new mentors, and 
+> ensuring that no-one falls through the cracks when a mentor gets too busy, is 
+> a job of itself."
+> 
+> I'm looking for someone who could fill that "job".
+> 
+> Description of the job:
+> 
+> - keep track of:
+> -- who's being mentored by who, how well it's going
+> -- who needs a mentor and hasn't found one yet (this is one of the most 
+> important parts: no volunteer must be forgotten, volunteers are too precious 
+> !)
+> -- who can mentor more apprentices (and sometimes convince packagers to become 
+> mentors or accept one more apprentice)
+> 
+> - be available for questions from apprentices or mentors, by mail, and if 
+> possible, to be present on the IRC channel #mageia-mentoring on freenode
+> 
+> - help mentors with gathering "junior tasks" (bugzilla is a never empty 
+> reserve that can be used for that. Maybe ask the bug triage team to help 
+> identify such tasks. Maybe a "junior task" keyword in bugzilla would do the 
+> trick)
+> -- small bugs to fix
+> -- new small packages to import in the distribution
+> -- backports
+> 
+> - promote mentoring (empower users into contributers. Working with the 
+> marketing team would be great I think):
+> -- make the mentoring program known (MLs, forums, web, etc.)
+> -- look for new apprentices
+> -- look for new mentors
+> 
+> Some useful skills:
+> - be autonomous (ie no need to check that you're doing the work)
+> - good written english (communication is very important in this job)
+> - knowledge about packaging is a plus but not mandatory (the key aspects can 
+> be taught to you)
+> - being or having been a mentor, or having been mentored would be a plus, but 
+> not mandatory
+> 
+> More information about the job:
+> - does not require a big amount of work, but real committment to the task and 
+> regularity
+> - remember that you have a coordination role, not an authoritative role. The 
+> difference in that is that you're not here to give orders but to facilitate the 
+> mentoring program.
+> - you don't have to be alone to do this job if it's too much for one person: 
+> you can find other helpful people wanting to help you if needed and rely on the 
+> other teams (but finding them *is* part of your job ;) ).
+> -  this "job offer" concerns everything that revolves around the mentoring of 
+> new packagers, but if it's successful maybe other teams can follow the same 
+> approach (i18n, QA, etc... ).
+> -  depending on your level of confidence, experience and will, you could be 
+> helped in your work. Maybe someone from the council can supervise and help you 
+> at least at the beginning; or, if no one steps up, I can help you bootstrap 
+> and organize your new "job".
+> 
+> So, who's in?
+> 
+> Samuel Verschelde
+> 
+I offer my candidacy. I was mentored by shikamaru and i'm a mandriva
+packager since 2009 and a mageia packager since the start.
+My english level is pretty good and i'm pretty sociable.
+
+so!
+-- 
+Sandro Cazzaniga - https://lederniercoupdarchet.wordpress.com
+IRC: Kharec (irc.freenode.net)
+Software/Hardware geek
+Conceptor
+Magnum's Coordinator/editor (http://wiki.mandriva.com/fr/Magnum)
+Mageia and Mandriva contributor
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005435.html b/zarb-ml/mageia-dev/2011-June/005435.html new file mode 100644 index 000000000..225763c68 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005435.html @@ -0,0 +1,260 @@ + + + + [Mageia-dev] Perl conflicts + + + + + + + + + +

[Mageia-dev] Perl conflicts

+ Frank Griffin + ftg at roadrunner.com +
+ Sun Jun 12 19:44:17 CEST 2011 +

+
+ +
I'm not sure if this is because the perl upgrade in't complete, but just 
+in case it's of use:
+
+Installation failed:    file /usr/bin/json_pp from install of 
+perl-devel-2:5.14.0-3.mga2.x86_64 conflicts with file from package 
+perl-JSON-PP-2.271.50-1.mga1.noarch
+     file 
+/usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP.pm 
+conflicts between attempted installs of 
+perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64
+     file 
+/usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Attribute.pm 
+conflicts between attempted installs of 
+perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64
+     file 
+/usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Class.pm 
+conflicts between attempted installs of 
+perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64
+     file 
+/usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Class/Immutable/Trait.pm 
+conflicts between attempted installs of 
+perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64
+     file 
+/usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Deprecated.pm 
+conflicts between attempted installs of 
+perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64
+     file 
+/usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Instance.pm 
+conflicts between attempted installs of 
+perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64
+     file 
+/usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Method.pm 
+conflicts between attempted installs of 
+perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64
+     file 
+/usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Method/Accessor.pm 
+conflicts between attempted installs of 
+perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64
+     file 
+/usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Method/Constructor.pm 
+conflicts between attempted installs of 
+perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64
+     file 
+/usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Method/Generated.pm 
+conflicts between attempted installs of 
+perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64
+     file 
+/usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Method/Inlined.pm 
+conflicts between attempted installs of 
+perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64
+     file 
+/usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Method/Meta.pm 
+conflicts between attempted installs of 
+perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64
+     file 
+/usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Method/Wrapped.pm 
+conflicts between attempted installs of 
+perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64
+     file 
+/usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/MiniTrait.pm 
+conflicts between attempted installs of 
+perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64
+     file 
+/usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Mixin.pm 
+conflicts between attempted installs of 
+perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64
+     file 
+/usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Mixin/AttributeCore.pm 
+conflicts between attempted installs of 
+perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64
+     file 
+/usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Mixin/HasAttributes.pm 
+conflicts between attempted installs of 
+perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64
+     file 
+/usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Mixin/HasMethods.pm 
+conflicts between attempted installs of 
+perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64
+     file 
+/usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Module.pm 
+conflicts between attempted installs of 
+perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64
+     file 
+/usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Object.pm 
+conflicts between attempted installs of 
+perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64
+     file 
+/usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Package.pm 
+conflicts between attempted installs of 
+perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64
+     file 
+/usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/metaclass.pm 
+conflicts between attempted installs of 
+perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005436.html b/zarb-ml/mageia-dev/2011-June/005436.html new file mode 100644 index 000000000..07bb44f12 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005436.html @@ -0,0 +1,208 @@ + + + + [Mageia-dev] "Job offer" : mentoring program coordinator + + + + + + + + + +

[Mageia-dev] "Job offer" : mentoring program coordinator

+ magnus + magnus.mud at googlemail.com +
+ Sun Jun 12 19:49:31 CEST 2011 +

+
+ +
Hello,
+I'm not offer my candidacy, I'm only a simple user.
+But I offer my help as secrtary of the secratary of ...... the coordinator
+
+As Mageia and I have the same birthday I'm following the upgroth since the
+beginning.
+Also with a little help during qa for the final.
+
+As I saw some requests for mentoring on the ml, I think it is important to
+show a quick response.
+So mentoring team can do this, ask for the skill or say look to foo1, foo2
+or foo3 on the bug-list
+during we are looking for mentor.
+(perhaps the packagers can classify the complexity of new-package-request
+and "simple" bugs)
+
+Also very important ist the actuality of the wiki.
+So we must have a look on the bug-list, ml and irc not to loose any request
+for mentoring.
+On the other side we must have/build a very good communicatio to the
+packagers to avoid double work on packages
+and to help for equal distribution of the mentoring work.
+
+Although not filling the wanted skills (no packager, no being a mentor, not
+good english knowledge)
+I'm ready to help.
+
+I think some more eyes are always good :-)
+
+So if I can help call me
+
+Magnus
+
+PS: In my job as it-auditor documentation, communication and learning new
+thinks are the normal things
+
+
+
+
+
+
+
+
+
+
+
+
+
+> > Some useful skills:
+> > - be autonomous (ie no need to check that you're doing the work)
+> > - good written english (communication is very important in this job)
+> > - knowledge about packaging is a plus but not mandatory (the key aspects
+> can
+> > be taught to you)
+> > - being or having been a mentor, or having been mentored would be a plus,
+> but
+> > not mandatoryI offer my candidacy. I was mentored by shikamaru and i'm a
+> mandriva
+> packager since 2009 and a mageia packager since the start.
+> My english level is pretty good and i'm pretty sociable.
+>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110612/6a5faa22/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005437.html b/zarb-ml/mageia-dev/2011-June/005437.html new file mode 100644 index 000000000..88c496ac3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005437.html @@ -0,0 +1,255 @@ + + + + [Mageia-dev] Perl conflicts + + + + + + + + + +

[Mageia-dev] Perl conflicts

+ Sander Lepik + sander.lepik at eesti.ee +
+ Sun Jun 12 20:02:51 CEST 2011 +

+
+ +
12.06.2011 20:44, Frank Griffin kirjutas:
+> I'm not sure if this is because the perl upgrade in't complete, but just in case it's of use:
+>
+> Installation failed:    file /usr/bin/json_pp from install of 
+> perl-devel-2:5.14.0-3.mga2.x86_64 conflicts with file from package 
+> perl-JSON-PP-2.271.50-1.mga1.noarch
+>     file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP.pm 
+> conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and 
+> perl-Moose-2.0.0-2.mga2.x86_64
+>     file 
+> /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Attribute.pm 
+> conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and 
+> perl-Moose-2.0.0-2.mga2.x86_64
+>     file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Class.pm 
+> conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and 
+> perl-Moose-2.0.0-2.mga2.x86_64
+>     file 
+> /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Class/Immutable/Trait.pm 
+> conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and 
+> perl-Moose-2.0.0-2.mga2.x86_64
+>     file 
+> /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Deprecated.pm 
+> conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and 
+> perl-Moose-2.0.0-2.mga2.x86_64
+>     file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Instance.pm 
+> conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and 
+> perl-Moose-2.0.0-2.mga2.x86_64
+>     file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Method.pm 
+> conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and 
+> perl-Moose-2.0.0-2.mga2.x86_64
+>     file 
+> /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Method/Accessor.pm 
+> conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and 
+> perl-Moose-2.0.0-2.mga2.x86_64
+>     file 
+> /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Method/Constructor.pm conflicts 
+> between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and 
+> perl-Moose-2.0.0-2.mga2.x86_64
+>     file 
+> /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Method/Generated.pm 
+> conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and 
+> perl-Moose-2.0.0-2.mga2.x86_64
+>     file 
+> /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Method/Inlined.pm 
+> conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and 
+> perl-Moose-2.0.0-2.mga2.x86_64
+>     file 
+> /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Method/Meta.pm 
+> conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and 
+> perl-Moose-2.0.0-2.mga2.x86_64
+>     file 
+> /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Method/Wrapped.pm 
+> conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and 
+> perl-Moose-2.0.0-2.mga2.x86_64
+>     file 
+> /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/MiniTrait.pm 
+> conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and 
+> perl-Moose-2.0.0-2.mga2.x86_64
+>     file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Mixin.pm 
+> conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and 
+> perl-Moose-2.0.0-2.mga2.x86_64
+>     file 
+> /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Mixin/AttributeCore.pm 
+> conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and 
+> perl-Moose-2.0.0-2.mga2.x86_64
+>     file 
+> /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Mixin/HasAttributes.pm 
+> conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and 
+> perl-Moose-2.0.0-2.mga2.x86_64
+>     file 
+> /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Mixin/HasMethods.pm 
+> conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and 
+> perl-Moose-2.0.0-2.mga2.x86_64
+>     file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Module.pm 
+> conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and 
+> perl-Moose-2.0.0-2.mga2.x86_64
+>     file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Object.pm 
+> conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and 
+> perl-Moose-2.0.0-2.mga2.x86_64
+>     file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Package.pm 
+> conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and 
+> perl-Moose-2.0.0-2.mga2.x86_64
+>     file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/metaclass.pm 
+> conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and 
+> perl-Moose-2.0.0-2.mga2.x86_64
+>
+https://bugs.mageia.org/show_bug.cgi?id=1756
+
+--
+Sander
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005438.html b/zarb-ml/mageia-dev/2011-June/005438.html new file mode 100644 index 000000000..2b7107cae --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005438.html @@ -0,0 +1,171 @@ + + + + [Mageia-dev] Perl conflicts + + + + + + + + + +

[Mageia-dev] Perl conflicts

+ Frank Griffin + ftg at roadrunner.com +
+ Sun Jun 12 20:13:47 CEST 2011 +

+
+ +
On 06/12/2011 02:02 PM, Sander Lepik wrote:
+>
+> https://bugs.mageia.org/show_bug.cgi?id=1756
+Thanks for the response.  I saw that one, but it only deals with JSON, 
+and it's marked FIXED.  There seemed to be more involved here.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005439.html b/zarb-ml/mageia-dev/2011-June/005439.html new file mode 100644 index 000000000..d88b0ca67 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005439.html @@ -0,0 +1,133 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Angelo Naselli + anaselli at linux.it +
+ Sun Jun 12 20:35:56 CEST 2011 +

+
+ +
In data domenica 12 giugno 2011 01:37:53, Barry Jackson ha scritto:
+> > - Dot in Summary.
+> 
+> ?? I don't see one.
+Summary:	Download and Install Skype. <------
+
+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/20110612/c9a07f06/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005440.html b/zarb-ml/mageia-dev/2011-June/005440.html new file mode 100644 index 000000000..dd48eb7f4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005440.html @@ -0,0 +1,134 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ yvan munoz + mr.yvan.munoz at gmail.com +
+ Sun Jun 12 20:37:45 CEST 2011 +

+
+ +
2011/6/12 Angelo Naselli <anaselli at linux.it>
+
+> In data domenica 12 giugno 2011 01:37:53, Barry Jackson ha scritto:
+> > > - Dot in Summary.
+> >
+> > ?? I don't see one.
+> Summary:        Download and Install Skype. <------
+>
+> Cheers,
+> --
+>         Angelo
+>
+
+finally back on dl-stuff ? :)
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110612/dbbb4aa2/attachment-0001.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005441.html b/zarb-ml/mageia-dev/2011-June/005441.html new file mode 100644 index 000000000..253bdfcf1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005441.html @@ -0,0 +1,129 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Angelo Naselli + anaselli at linux.it +
+ Sun Jun 12 20:50:43 CEST 2011 +

+
+ +
> finally back on dl-stuff ? :)
+Sorry?
+
+-- 
+	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/20110612/690b3be7/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005442.html b/zarb-ml/mageia-dev/2011-June/005442.html new file mode 100644 index 000000000..af6022170 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005442.html @@ -0,0 +1,318 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Michael Scherer + misc at zarb.org +
+ Sun Jun 12 22:46:33 CEST 2011 +

+
+ +
Hi,
+
+so , with a little bit delay due to various things ( like everybody
+asking stuff to us on irc on a hourly fashion ( people will I hope
+recognize themselves )), Anne and I have reviewed the various proposals
+made through years during the early period of the distribution, and
+before at Mandriva. We took in account the feedback of people on forum,
+on ml, nd those we have seen during events. We also discussed with
+others distributions developers we know from Opensuse, Fedora, Debian,
+Ubuntu about their release cycle, the choices they made and their
+reasons. 
+
+Before going to the proposal, a few point of vocabulary :
+
+Release cycle mean the time between 2 releases.
+
+Life cycle means the time where we offer the distribution on most
+mirrors, and plan to offer infra for that ( backports, security update
+), and accept/correct bugs. IE, "support" on the distribution level.
+
+
+To simplify the discussion, the proposals are all based on the fact that
+2 or 3 releases could be supported at a time. We could have different
+schemes for that ( LTS every X release ( ubuntu ), different level of
+support ( mandriva )), but as this is a slightly different discussion,
+let's assume 2 supported releases for now, and let's discuss later for
+that ( ie next week, once this one is finished )
+
+And roughly, to start the discussion, we have 3 potential releases
+cycles, based on all inputs we had :
+
+Proposal 1: 
+6 months release cycle -> 12 months life cycle
+( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
+
+Proposal 2: 
+9 months release cycle -> 18 months life cycle  
+( ~ opensuse and the one we used for Mageia 1 )
+
+Proposal 3: 
+12 months release cycle -> 24 months life cycle
+( Mandriva > 2010.1 )
+
+
+
+Proposal 1 :
+---------------
+Pros:
+- better hardware support
+- up to date versions / upstream projects (must have for developers)
+
+
+Cons:
+- very tight schedule: must include brainstorm, specifications,
+developments, development releases
+- feeling to be releasing all the time
+- short lifecycle ( nothing long term )
+
+
+Proposal 2
+----------------
+Pros:
+- compromise between proposal 1 and proposal 3 
+- development release more manageable to include all steps
+- allow to release when no others distributions , so we can be sure to
+have enough communication
+
+
+Cons:
+- not synchronized with gnome or others that use a 6 month cycle
+- potentially release when there isn't much activity ( like during
+Holidays )
+
+
+Proposal 3 :
+------------
+
+Pros:
+- users do upgrade less often, as this is often seen as tedious.
+- asked by some professionnal users
+
+
+Cons:
+- less visibility, because there is less communication
+- coders and packagers feel some urge to push last minute feature to not
+wait one year, adding difficulty to manage the planning on 1 year
+without intermediary release
+- hardware support potentially lagging behind
+
+
+
+Astute readers will see that the 3 proposals are all time based and the
+2 alternatives type of release would be :
+- no release
+- features based.
+
+We didn't develop any proposal on them.
+The no-release model is not really a release cycle per definition ( if
+the release planning is to do nothing, that's not a planning ). 
+
+The feature based model ( aka "release when it is ready" ), while being
+tempting, is a dangerous path, since too many project are late due to
+lack of formal planning. Being based on features add more complexity on
+something like a distribution given the wide scale of change to
+implement, and the high number of interaction. So it was not taken in
+account for that.
+
+
+Out of theses 3 propositions, Anne was in favor of the version 2 ( 9
+months ), based on her experience with 1 ( Mandriva ) and 3 ( Mandriva
+2006.0 ). 
+
+I was personally pleased with 1 and 3 as a user, mainly because I am
+perfectly able to take care of any issue, so I am not really in a
+position to give a preference. ( I use desktop and server, even if the
+dichotomy is rather "stuff that I want to upgrade often" ( personal
+workstation, home server ) and "stuff that I prefer to not upgrade
+often" ( parents workstation, some external server ).
+
+
+Now, remember the rules. 
+
+- all proposals must be justified ( and why they are better than the
+current ones ).
+
+- the discussion will finished the 22 June. After that, it is too late
+until we rediscuss again ( like a few years if everything changed ).
+
+- if no clear consensus emerge, we will have to decide using another
+way. It will likely make some people sad if their favorite option is not
+the one used, but such is life.
+ 
+- if the discussion become unmanageable, remember the pictures in topic
+of the irc channel of sysadmins.
+
+
+Now, if someone could point others teams to this discussion, this would
+be helpful. Anne promised me to send a note to english forums about
+that.
+
+But do not forward the mail, ask to people to speak on -dev rather than
+discuss on $others_comm_channel ( like irc, forum, others mls ). People
+not posting on -dev will lose their right to complain they were not
+listened. If someone is volunteer to gather feedback for their own
+group, it will be fine.
+
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005443.html b/zarb-ml/mageia-dev/2011-June/005443.html new file mode 100644 index 000000000..11b443cd1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005443.html @@ -0,0 +1,198 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Dexter Morgan + dmorganec at gmail.com +
+ Sun Jun 12 23:02:44 CEST 2011 +

+
+ +
On Sun, Jun 12, 2011 at 10:46 PM, Michael Scherer <misc at zarb.org> wrote:
+> Hi,
+>
+> so , with a little bit delay due to various things ( like everybody
+> asking stuff to us on irc on a hourly fashion ( people will I hope
+> recognize themselves )), Anne and I have reviewed the various proposals
+> made through years during the early period of the distribution, and
+> before at Mandriva. We took in account the feedback of people on forum,
+> on ml, nd those we have seen during events. We also discussed with
+> others distributions developers we know from Opensuse, Fedora, Debian,
+> Ubuntu about their release cycle, the choices they made and their
+> reasons.
+>
+> Before going to the proposal, a few point of vocabulary :
+>
+> Release cycle mean the time between 2 releases.
+>
+
+ Hello, i would be in favor of proposal 2.
+
+For not beeing in sync with upstream projects ( gnome, kde, ... ) this
+is for me a "false problem"  because we won't provide the first
+release ( like gnome 3.2 or kde 4.7 ) but we will be able to release a
+bugfix release ( gnome 3.2.x , kde 4.7.5 ) which means less work for
+QA team during stable release.
+
+This proposal allow us to do more "long term" projects too.
+
+I think that with proposition 3 we will have less visibility because
+ppl will have real news of us only once per year.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005444.html b/zarb-ml/mageia-dev/2011-June/005444.html new file mode 100644 index 000000000..9c780eaa9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005444.html @@ -0,0 +1,200 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Angelo Naselli + anaselli at linux.it +
+ Sun Jun 12 23:38:48 CEST 2011 +

+
+ +
In data domenica 12 giugno 2011 22:46:33, Michael Scherer ha scritto:
+> Proposal 1: 
+> 6 months release cycle -> 12 months life cycle
+> ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
+> 
+> Proposal 2: 
+> 9 months release cycle -> 18 months life cycle  
+> ( ~ opensuse and the one we used for Mageia 1 )
+> 
+> Proposal 3: 
+> 12 months release cycle -> 24 months life cycle
+> ( Mandriva > 2010.1 )
+
+Well imo extending too much release cycle means also to
+have a lot of backports and patches for fixings.
+
+So 1 or 2 are better, more upstream packages than fixings.
+
+If we cannot afford 6 mo release cycle because we're all volunteers for 
+instance, 9 mo one is the right compromise, i believe.
+
+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/20110612/6d7f16e1/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005445.html b/zarb-ml/mageia-dev/2011-June/005445.html new file mode 100644 index 000000000..7c8af5c20 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005445.html @@ -0,0 +1,134 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Barry Jackson + zen25000 at zen.co.uk +
+ Sun Jun 12 23:45:32 CEST 2011 +

+
+ +
On 12/06/11 19:35, Angelo Naselli wrote:
+> In data domenica 12 giugno 2011 01:37:53, Barry Jackson ha scritto:
+>>> - Dot in Summary.
+>>
+>> ?? I don't see one.
+> Summary:	Download and Install Skype.<------
+>
+> Cheers,
+ >
+
+Ah - sorry, that is a full stop. I was looking for an extraneous dot.
+I assume then that a full stop is either not required or ilegal in a 
+summary? Does it break something?
+
+I will remove it ;)
+
+Barry
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005446.html b/zarb-ml/mageia-dev/2011-June/005446.html new file mode 100644 index 000000000..ac464ce22 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005446.html @@ -0,0 +1,169 @@ + + + + [Mageia-dev] update of compiz + + + + + + + + + +

[Mageia-dev] update of compiz

+ julien + mjulien.m at gmail.com +
+ Sun Jun 12 21:39:10 CEST 2011 +

+
+ +
Hi,
+
+I would like to update compiz to v0.8.8.
+
+any objection ?
+
+regards
+julien
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005447.html b/zarb-ml/mageia-dev/2011-June/005447.html new file mode 100644 index 000000000..403a3fe23 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005447.html @@ -0,0 +1,207 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Sander Lepik + sander.lepik at eesti.ee +
+ Mon Jun 13 00:06:11 CEST 2011 +

+
+ +
12.06.2011 23:46, Michael Scherer kirjutas:
+> Proposal 1:
+> 6 months release cycle ->  12 months life cycle
+> ( Fedora, Ubuntu, Mandriva<  2010.1&&  Mandriva != 2006.0 )
+>
+> Proposal 2:
+> 9 months release cycle ->  18 months life cycle
+> ( ~ opensuse and the one we used for Mageia 1 )
+>
+> Proposal 3:
+> 12 months release cycle ->  24 months life cycle
+> ( Mandriva>  2010.1 )
+ From those options i would go with the second one. Third is way too much wanted from users 
+(and first has too short life cycle). They are always eager for new stuff and waiting one 
+year ain't option for them. We could also try to have some LTS versions. But in a bit 
+different manner than Ubuntu. Like if we notice that some release is good and stable we 
+could extend its support period (ie mdv2008.1 was really stabel and also mdv2010.1 was 
+pretty good - for me neither had too many problems and i would have keeped 2008.1 for longer 
+but its support ended).
+
+One more thing i didn't like with Mageia 1. Official launch date that you know is coming and 
+you see that not all things are ready for prime time but you go anyway as there is launch 
+date announced. Ubuntu has failed with that at least few times.
+Debian (Mozilla somewhat too) does better job here. They don't release if they see critical 
+problems and they don't announce release too far away.
+In that hurry we probably missed ATI graphics problem and could have solved it better.
+
+Maybe we should try to have 9 months but if it will be 10 with more stable release i would 
+go with 10 (or mabye final freeze in 8 months and then we'll see how fast we can make it 
+stable).
+
+(And we have to keep up the good job with upgrading smoothness - in the future it must be 
+tested even more, that way users who want longer cycle will complain less if they can 
+upgrade their system w/o big problems.)
+
+--
+my 0.02€ (or a bit more :P)
+Sander
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005448.html b/zarb-ml/mageia-dev/2011-June/005448.html new file mode 100644 index 000000000..9f733648e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005448.html @@ -0,0 +1,209 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Zé + mmodem00 at gmail.com +
+ Mon Jun 13 00:07:35 CEST 2011 +

+
+ +
Em 2011/6/12 Michael Scherer <misc at zarb.org> escreveu:
+> Proposal 1 :
+> ---------------
+> Pros:
+> - better hardware support
+> - up to date versions / upstream projects (must have for developers)
+>
+>
+> Cons:
+> - very tight schedule: must include brainstorm, specifications,
+> developments, development releases
+> - feeling to be releasing all the time
+> - short lifecycle ( nothing long term )
+>
+>
+> Proposal 2
+> ----------------
+> Pros:
+> - compromise between proposal 1 and proposal 3
+> - development release more manageable to include all steps
+> - allow to release when no others distributions , so we can be sure to
+> have enough communication
+>
+>
+> Cons:
+> - not synchronized with gnome or others that use a 6 month cycle
+> - potentially release when there isn't much activity ( like during
+> Holidays )
+
+I think proposal 3 would not be the best option since as commnity
+users expect things faster, so i think they would in favour of
+proposal 1 or 2.
+But since this its distro vollunteer-based would be more real to have
+9 months between a release, this considering we have the backports and
+update sections to handle beetween apps releases and to please those
+more impatient users.
+So in conclusion my preference goes with proposal 2.
+
+-- 
+Zé
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005449.html b/zarb-ml/mageia-dev/2011-June/005449.html new file mode 100644 index 000000000..5252e9b53 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005449.html @@ -0,0 +1,183 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Dick Gevers + dvgevers at xs4all.nl +
+ Mon Jun 13 00:14:19 CEST 2011 +

+
+ +
On Sun, 12 Jun 2011 22:46:33 +0200, Michael Scherer wrote about
+[Mageia-dev] Release cycles proposals, and discussion:
+
+>Out of theses 3 propositions, Anne was in favor of the version 2 ( 9
+>months ), based on her experience with 1 ( Mandriva ) and 3 ( Mandriva
+>2006.0 ). 
+
+I personally prefer a quick turnaround and keep it exciting: proposition #
+1, but otherwise I follow the leader. One whole year release cycle (# 3)
+appears to dull for me: we are cooking the Cauldron and not granny's tea
+kettle.
+
+Viva Mageia !
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005450.html b/zarb-ml/mageia-dev/2011-June/005450.html new file mode 100644 index 000000000..b56c4d5c2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005450.html @@ -0,0 +1,177 @@ + + + + [Mageia-dev] update of compiz + + + + + + + + + +

[Mageia-dev] update of compiz

+ Dexter Morgan + dmorganec at gmail.com +
+ Mon Jun 13 00:16:16 CEST 2011 +

+
+ +
On Sun, Jun 12, 2011 at 9:39 PM, julien <mjulien.m at gmail.com> wrote:
+> Hi,
+>
+> I would like to update compiz to v0.8.8.
+>
+> any objection ?
+>
+> regards
+> julien
+>
+
+Hello,
+
+fedora uses compiz 0.9.4 do you think we can directly go to this version ?
+
+Btw, glad to see someone taking compiz maintainership, congrats.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005451.html b/zarb-ml/mageia-dev/2011-June/005451.html new file mode 100644 index 000000000..b1bf37dd0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005451.html @@ -0,0 +1,287 @@ + + + + [Mageia-dev] about release cycle + + + + + + + + + +

[Mageia-dev] about release cycle

+ Ron + corbintechboy at yahoo.com +
+ Mon Jun 13 00:25:43 CEST 2011 +

+
+ +
Hello,
+I hope I am doing this right as I have never used this type of thing before, I will apologize before hand if not.
+I wrote a proposal on the forums and I think it is very good and I would like it at the very least just heard and seen if it might work in the ideals of the project. I joined this list to get this out here. I am going to do copy/paste from my original post(s) to get this here.. Post 1:
+Here is what I propose:
+
+Unstable- This is the place where it all starts! Packages come from upstream end up here and move forward if no show stopper bugs are found
+Rolling Unstable- Packages that leave Unstable come here to be tested for stability and made stable... Bleeding edge rolling (Debian Unstable)
+Rolling Stable- Packages that are stable in Rolling Unstable for X amount of time come here.... Stable rolling (Arch)
+Point releases- These releases are taken from the stable rolling release and supported for X amount of time... Security updates only 
+LTS release- These are rock solid stable (Debian stable) and snap shots from point release on whole number
+
+So we would have unstable (easy to understand), unstable rolling for those who want cutting edge software, stable rolling for those who want to roll stable, point releases for those who like to install every now and then and LTS which after the way down the line should be VERY stable!
+Further info:
+1 developer releases 1 package. Package maintainer pulls package into unstable (developers don't make a habit of making crappy packages, stability is judged by the whole system running in harmony). Maintainers job is to make sure it works before it leaves unstable. When the package gains stability in unstable (basically you are able to install the package and have a usable system) the package moves to the next stage, rolling unstable. Rolling unstable is a test bed of bleeding edge software from the package maintainer for a X amount of time (we are still on this one package). Now, the next time this package moves it is from a scheduled pull, so this package after X amount of time now gets "pulled" into the next phase (rolling stable (as long as there are no show stopper bugs)). From here on out the "team" responsible pulls in packages from up stream (rolling unstable) and the package maintainer just repeats this process in working at the top of the
+ ladder. Security updates and bug fixes can be "pushed" down by the maintainer.
+
+Where is this hard? Sounds like any other distribution to me... Debian maybe?
+
+Anyway...
+
+2.0 will become an LTS. Not a packaging nightmare at all... A snapshot of rolling stable from a point in time that matures with bug fixes and security updates. Kernel only updates within kernel branch (2.6.30-XX).
+
+2.1 is a point release... Snapshot of rolling unstable (again easy on package maintainer). Supported for X amount of time. Becomes slightly mature as bug fixes and core updates make it so (from stuff already coming down from up stream).
+
+So we have 1 package maintainer working packages that are pushed into rolling unstable (think testing) and trickle on down the line with help from the community team of "distribution" maintainers.
+
+One rolling set of packages ever changing like a fine oiled machine. The logic just sounds right to me and very efficient I think...
+
+EDIT: If you wanted to "shorten" the amount of "projects (I guess)" you could omit anything below rolling unstable.
+
+Rolling unstable for instance could roll into a full fledged release (Not a good idea IMHO)
+Rolling stable we could do without and we would be Debian all over (maybe more bleeding edge on the release)
+LTS does not have to be... But LTS would be a very good way to get us used on servers...
+Point releases are for those who don't like the rolling model... This is a "showcase" release to show everyone what we are without having to roll 
+
+Up to anyone really but this model is so versatile it really don't matter. You could omit about any point below the maintainer and have working mechanics.________________________________________________________________________Last post was in response to a disagreement with someone else. To help make my idea more fitting I was suggesting ways within my idea where things can change. Was under the impression the other part thought the idea would be hard on the package maintainer, I didn't and still don't see this problem. With everything being snapshots of the rolling model, maintaining should be very easy.
+We could become fully rolling with this model, rolling and stable (debian but with newer packages), rolling unstable with LTS releases, rolling with general releases... Really there are a lot of possibilities based on this model. 
+I like it...
+
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110612/1fc5ea8a/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005452.html b/zarb-ml/mageia-dev/2011-June/005452.html new file mode 100644 index 000000000..96924b5ef --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005452.html @@ -0,0 +1,279 @@ + + + + [Mageia-dev] autologin + consolekit + + + + + + + + + +

[Mageia-dev] autologin + consolekit

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Mon Jun 13 00:45:41 CEST 2011 +

+
+ +
Hi,
+
+The autologin package is broken due to the fact that it doesn't connect
+to consolekit and thus the user who is automatically logged in doesn't
+get any permissions etc.
+
+I've fixed this by changing the autologin pam.d definition to include
+"login" rather than "system-auth".
+
+login adds the optional session module for pam_ck_connector.
+
+But I'm not sure whether this makes sense, or whether we should just add
+the ck_connector to the autologin pam.d definition itself.
+
+There may be other login systems that have similar problems (e.g. the
+autologin features of gdm or slim etc) but I've not tested.
+
+Any thoughts.
+
+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-June/005453.html b/zarb-ml/mageia-dev/2011-June/005453.html new file mode 100644 index 000000000..beab704fd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005453.html @@ -0,0 +1,237 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Mon Jun 13 00:48:17 CEST 2011 +

+
+ +
Op zondag 12 juni 2011 23:38:48 schreef Angelo Naselli:
+> In data domenica 12 giugno 2011 22:46:33, Michael Scherer ha scritto:
+> > Proposal 1:
+> > 6 months release cycle -> 12 months life cycle
+> > ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
+> > 
+> > Proposal 2:
+> > 9 months release cycle -> 18 months life cycle
+> > ( ~ opensuse and the one we used for Mageia 1 )
+> > 
+> > Proposal 3:
+> > 12 months release cycle -> 24 months life cycle
+> > ( Mandriva > 2010.1 )
+> 
+> Well imo extending too much release cycle means also to
+> have a lot of backports and patches for fixings.
+> 
+> So 1 or 2 are better, more upstream packages than fixings.
+> 
+> If we cannot afford 6 mo release cycle because we're all volunteers for
+> instance, 9 mo one is the right compromise, i believe.
+> 
+> Cheers,
+
++1
+
+allthough, _perhaps_ there is another option: (i didn't think about the effect 
+this would have on life cycles):
+
+i was thinking, that maybe we want 9months now, because of big changes coming, 
+but maybe in the future we would do less big changes for instance.
+
+Proposal 4:
+JIT-fixed months release cycle -> ? months life cycle
+
+explanation:
+the idea is to have the following things happen after release:
+1. postmortem
+2. discussion of features
+3. decision of features
+4. making planning and deciding time based on the featurelist and an educated 
+guess on time required to implement and bugfix. (generally between 6 and 12 
+months)
+....
+
+pro:
+ - allows to plan release taking into account everything:
+    - list of features to be done (and amount of packagers)
+    - holidays
+    - releases of other distros
+    - stuff i hadn't thought of
+
+con:
+ - there could be a pitfall that we ALWAYS don't fulfill the planning
+ - unknown months life cycle
+
+
+in general, it would mean, what we do right now, there's a separate decision 
+every time.
+
+thinking specifically on this time:
+ - 8months: 1st febr, bad idea: because of christmas holidays there will 
+likely be no good testing.
+ - 9months is 1st march? (sounds like a busy time for other distros)
+ - 10months:  1st april (april fools joke? not good)
+
+I'm thinking 10,5 months for this one: April 15th. perhaps next time most big 
+changes will be done, and we could go for a short 6 or 7month release if we 
+have more resources at that time.
+
+just my personal opinion,
+
+Maarten
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005454.html b/zarb-ml/mageia-dev/2011-June/005454.html new file mode 100644 index 000000000..2d2b62445 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005454.html @@ -0,0 +1,200 @@ + + + + [Mageia-dev] update of compiz + + + + + + + + + +

[Mageia-dev] update of compiz

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Mon Jun 13 00:47:01 CEST 2011 +

+
+ +
'Twas brillig, and Dexter Morgan at 12/06/11 23:16 did gyre and gimble:
+> On Sun, Jun 12, 2011 at 9:39 PM, julien <mjulien.m at gmail.com> wrote:
+>> Hi,
+>>
+>> I would like to update compiz to v0.8.8.
+>>
+>> any objection ?
+>>
+>> regards
+>> julien
+>>
+> 
+> Hello,
+> 
+> fedora uses compiz 0.9.4 do you think we can directly go to this version ?
+> 
+> Btw, glad to see someone taking compiz maintainership, congrats.
+
+It would be nice to go to the latest compiz I did update it locally a
+while back to the 0.9 series but it crashed on my system before I got a
+chance to really look into it.
+
+I've still got the packages here, so I could commit them and/or publish
+patches if you could use them as a base?
+
+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-June/005455.html b/zarb-ml/mageia-dev/2011-June/005455.html new file mode 100644 index 000000000..0131ccea7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005455.html @@ -0,0 +1,265 @@ + + + + [Mageia-dev] "Job offer" : mentoring program coordinator + + + + + + + + + +

[Mageia-dev] "Job offer" : mentoring program coordinator

+ andre999 + andr55 at laposte.net +
+ Mon Jun 13 00:52:18 CEST 2011 +

+
+ +
Samuel Verschelde a écrit :
+>
+> Hello to everyone,
+>
+> I'm sure there's someone among you who wants to help Mageia but hasn't found
+> yet the good way to do it. Today is your lucky day, because there's a job
+> that's available and can be really useful and interesting: coordinating the
+> packagers mentoring program.
+>
+> You know that one key point of success for Mageia is in the ability to welcome
+> new packagers. The better we will be at it, the better the distro will be. The
+> packagers mentoring program has been created for that reason and several
+> packagers have been or are being mentored. But we have some difficulty knowing
+> who is being mentored by who and who hasn't found a mentor. And we need also
+> to find more mentors and more apprentices.
+>
+> During a packagers weekly meeting, misc invited us to read the following
+> article about mentoring programs in open-source projects:
+> http://blogs.gnome.org/bolsh/2011/05/31/effective-mentoring-programs/
+
+Very interesting, especially many of the comments.
+
+> I invite those who haven't read it yet, to read it. I'll quote one of the
+> mentoring best practices that were given: "In bigger projects, keeping track
+> of who is a mentor, and who is mentoring who, and inviting new mentors, and
+> ensuring that no-one falls through the cracks when a mentor gets too busy, is
+> a job of itself."
+>
+> I'm looking for someone who could fill that "job".
+>
+> Description of the job:
+>
+> - keep track of:
+> -- who's being mentored by who, how well it's going
+> -- who needs a mentor and hasn't found one yet (this is one of the most
+> important parts: no volunteer must be forgotten, volunteers are too precious
+> !)
+> -- who can mentor more apprentices (and sometimes convince packagers to become
+> mentors or accept one more apprentice)
+>
+> - be available for questions from apprentices or mentors, by mail, and if
+> possible, to be present on the IRC channel #mageia-mentoring on freenode
+>
+> - help mentors with gathering "junior tasks" (bugzilla is a never empty
+> reserve that can be used for that. Maybe ask the bug triage team to help
+> identify such tasks. Maybe a "junior task" keyword in bugzilla would do the
+> trick)
+> -- small bugs to fix
+> -- new small packages to import in the distribution
+> -- backports
+>
+> - promote mentoring (empower users into contributers. Working with the
+> marketing team would be great I think):
+> -- make the mentoring program known (MLs, forums, web, etc.)
+> -- look for new apprentices
+> -- look for new mentors
+>
+> Some useful skills:
+> - be autonomous (ie no need to check that you're doing the work)
+> - good written english (communication is very important in this job)
+> - knowledge about packaging is a plus but not mandatory (the key aspects can
+> be taught to you)
+> - being or having been a mentor, or having been mentored would be a plus, but
+> not mandatory
+>
+> More information about the job:
+> - does not require a big amount of work, but real committment to the task and
+> regularity
+> - remember that you have a coordination role, not an authoritative role. The
+> difference in that is that you're not here to give orders but to facilitate the
+> mentoring program.
+> - you don't have to be alone to do this job if it's too much for one person:
+> you can find other helpful people wanting to help you if needed and rely on the
+> other teams (but finding them *is* part of your job ;) ).
+> -  this "job offer" concerns everything that revolves around the mentoring of
+> new packagers, but if it's successful maybe other teams can follow the same
+> approach (i18n, QA, etc... ).
+> -  depending on your level of confidence, experience and will, you could be
+> helped in your work. Maybe someone from the council can supervise and help you
+> at least at the beginning; or, if no one steps up, I can help you bootstrap
+> and organize your new "job".
+>
+> So, who's in?
+>
+> Samuel Verschelde
+
+That is an excellent idea, a mentoring program coordinator.
+I've had some thoughts along those lines for some time.
+I'd be glad to contribute, especially via email and editing the wiki, where I could almost always 
+respond the same day.
+But my time zone availability (generally after 22h utc) puts me at a disadvantage for irc 
+communications and meetings.
+(But as part of a coordinating team, that should work well.)
+
+Maintaining the mentor/apprentice database, as Kharec suggested, is to me a key part of the role.
+Information such as mentors available, and their strengths/focus, usual time zones available, 
+communication modes preferred, languages spoken, and current apprentices,
+Would-be apprentices should have similar information listed.
+Not much different from the information currently in variously wiki pages, but maintained by the 
+coordinator in one location.
+
+<aside>
+One thing that occurred to me is that there is no imperative that mentoring process happens only in 
+English.  If an apprentice is more comfortable in another language, and they find a mentor speaking 
+that language, why not ?  Sure, it is useful to have basic English knowledge, but it is evident 
+that many (if not most) contributors speak English as a second language.
+</aside>
+
+Experience packaging, either as a mentor or apprentice is highly recommended in my view, at least 
+for the key person.  (My experience is as a apprentice with Shikamaru -- an excellent mentor, btw 
+-- and my time zone availability is probably why I haven't officially completed the process.)
+Also some programming experience could be useful.  (I imagine that most candidates would have that.)
+
+But also mentoring can apply to other things than packaging.  So maybe we should give a broader 
+scope to the mentoring coordinator job ?
+Including bugteam, QA, as well as packaging.
+That would make it more useful, as well as more interesting.
+(I would be very interested in contributing to something like that.)
+
+So what does everyone think ?
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005456.html b/zarb-ml/mageia-dev/2011-June/005456.html new file mode 100644 index 000000000..d58a36f05 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005456.html @@ -0,0 +1,198 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Mon Jun 13 00:57:24 CEST 2011 +

+
+ +
'Twas brillig, and Michael Scherer at 12/06/11 21:46 did gyre and gimble:
+> Proposal 1: 
+> 6 months release cycle -> 12 months life cycle
+> ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
+> 
+> Proposal 2: 
+> 9 months release cycle -> 18 months life cycle  
+> ( ~ opensuse and the one we used for Mageia 1 )
+> 
+> Proposal 3: 
+> 12 months release cycle -> 24 months life cycle
+> ( Mandriva > 2010.1 )
+
+I'll take 1 or 2 please! 3 would would be sacrificing too much IMO.
+
+Between 1 or 2, I think I'd likely prefer option 1, but there is not a
+massive swing either way for me.
+
+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-June/005457.html b/zarb-ml/mageia-dev/2011-June/005457.html new file mode 100644 index 000000000..16772bb31 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005457.html @@ -0,0 +1,178 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Zézinho + lists.jjorge at free.fr +
+ Mon Jun 13 00:58:36 CEST 2011 +

+
+ +
Em 12-06-2011 22:46, Michael Scherer escreveu:
+> - all proposals must be justified ( and why they are better than the
+> current ones ).
+>
+9 months means no yearly loop. Humans are used to seasons, and except 
+for things that do not happen yearly, this is inside our genetics ;-) 
+Think olympic games, etc.
+
+So either 6 or 12 or 24 months seems a good release time IMHO. Then 
+looking at other main distributions, 12 months means "loosing" users 
+(future contributors) every time we don't release near others release.
+So 6 months ends up as the only way to keep the head out of water...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005458.html b/zarb-ml/mageia-dev/2011-June/005458.html new file mode 100644 index 000000000..8d5dcce63 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005458.html @@ -0,0 +1,192 @@ + + + + [Mageia-dev] perl 5.14.0 now available + + + + + + + + + +

[Mageia-dev] perl 5.14.0 now available

+ Thomas Spuhler + thomas at btspuhler.com +
+ Mon Jun 13 01:02:34 CEST 2011 +

+
+ +
On Saturday, June 11, 2011 02:52:43 pm Pascal Terjan wrote:
+> On Sat, Jun 11, 2011 at 17:00, Thomas Spuhler <thomas at btspuhler.com> wrote:
+> > On Saturday, June 11, 2011 03:33:18 am Olivier Blin wrote:
+> >> Jerome Quelin <jquelin at gmail.com> writes:
+> >> > hi,
+> >> > 
+> >> > perl 5.14.0 should arrive soon. it compiles fine on both i586 &
+> >> > x86_64, and it seem we fixed the only problem arisen in perl-URPM.
+> >> > 
+> >> > since other packages need to be rebuilt in the same loop, and given
+> >> > that urpmi is written in perl, it needs a special treatment to bypass
+> >> > the regular bs upload.
+> >> > 
+> >> > blino will likely do this magic dance & upload them in the coming
+> >> > hours - you may want to wait till his final go before updating your
+> >> > cauldron box.
+> >> 
+> >> Hi,
+> >> 
+> >> I've uploaded perl 5.14 last night.
+> >> (I just had to update perl-FCGI to a newer version, since it didn't
+> >> build anymore)
+> >> 
+> >> Help is welcome to rebuild perlapi-5.12-dependent packages.
+> >> 
+> >> Thanks Jérôme!
+> > 
+> > I'll help to build
+> 
+> Thanks for helping but
+> 1) Please use a better changelog message, like "Rebuild for perl
+> 5.14". Increase rel for rebuild is not interesting when looking at the
+> history of a package.
+OK will do next time
+> 2) How did you get the list of packages to rebuild? You seem to
+> rebuild packages which don't need to be rebuilt. I noticed
+> perl-Youri-Package which I wouldn't expect needing to be rebuilt.
+
+I am not a perl guru. I agreed with sander85 to start at the end so we don't 
+both work on the same packages. 
+I used this list: http://pkgsubmit.mageia.org/data/src.txt
+Will it hurt to build one that is not needed?
+
+> 
+> 
+> # rpm -qp --requires
+> /distrib/bootstrap/distrib/1/i586/media/core/release/perl-Youri-Package-0.2
+> .2-4.mga1.noarch.rpm perl-version
+> rpmlib(PayloadFilesHavePrefix) <= 4.0-1
+> rpmlib(CompressedFileNames) <= 3.0.4-1
+> rpmlib(VersionedDependencies) <= 3.0.3-1
+> perl-base >= 2:5.12.3
+> rpmlib(PayloadIsLzma) <= 4.4.6-1
+> 
+> It does not depend on perlapi-5.12
+
+-- 
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005459.html b/zarb-ml/mageia-dev/2011-June/005459.html new file mode 100644 index 000000000..b87024199 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005459.html @@ -0,0 +1,249 @@ + + + + [Mageia-dev] [RPM] cauldron core/release perl_checker-1.2.11-7.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release perl_checker-1.2.11-7.mga2

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Mon Jun 13 01:03:29 CEST 2011 +

+
+ +
On 11 June 2011 18:16, Mageia Team <buildsystem-daemon at mageia.org> wrote:
+> spuhler <spuhler> 1.2.11-7.mga2:
+> + Revision: 103687
+> - increase rel for rebuild
+
+Why?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005460.html b/zarb-ml/mageia-dev/2011-June/005460.html new file mode 100644 index 000000000..b124560a3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005460.html @@ -0,0 +1,273 @@ + + + + [Mageia-dev] Cross compile x86_64 on i586 for icecream? + + + + + + + + + +

[Mageia-dev] Cross compile x86_64 on i586 for icecream?

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Mon Jun 13 01:08:25 CEST 2011 +

+
+ +
Hi,
+
+I'm not exactly a guru with icecream but is it possible to build a
+toolchain that can allow i586 nodes to compile x86_64 code?
+
+I've got a few powerful machines at home but one is a network booting
+i586 machine (I'd prefer to keep it that way due to the fact that the
+network base can be shared between a couple machines and not all are 64
+bit native machines).
+
+I think there is an OpenSuse package for this (likely due to the OBS stuff).
+
+Does anyone with more knowledge in this area have a clue about all this
+jazz?
+
+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-June/005461.html b/zarb-ml/mageia-dev/2011-June/005461.html new file mode 100644 index 000000000..ed058c883 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005461.html @@ -0,0 +1,210 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Renaud MICHEL + r.h.michel+mageia at gmail.com +
+ Mon Jun 13 01:56:22 CEST 2011 +

+
+ +
Hello
+On Sunday 12 June 2011 at 22:46, Michael Scherer wrote :
+> To simplify the discussion, the proposals are all based on the fact that
+> 2 or 3 releases could be supported at a time. We could have different
+> schemes for that ( LTS every X release ( ubuntu ), different level of
+> support ( mandriva )), but as this is a slightly different discussion,
+> let's assume 2 supported releases for now, and let's discuss later for
+> that ( ie next week, once this one is finished )
+> 
+> And roughly, to start the discussion, we have 3 potential releases
+> cycles, based on all inputs we had :
+> 
+> Proposal 1: 
+> 6 months release cycle -> 12 months life cycle
+> ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
+> 
+> Proposal 2: 
+> 9 months release cycle -> 18 months life cycle  
+> ( ~ opensuse and the one we used for Mageia 1 )
+> 
+> Proposal 3: 
+> 12 months release cycle -> 24 months life cycle
+> ( Mandriva > 2010.1 )
+
+From a long time mandriva (and now mageia) user POV, for myself I was quite 
+fine with 6 month release cycle, but at work I'd rather not update too 
+frequently and same goes for the rest of the family who generally don't care 
+much for newer versions. And I know that for some people, a big upgrade 
+every 6 month is a lot of work (and skipping a release is more risky).
+
+So I think either proposal #2 or #3 would do, my preference depending on how 
+much could be backported to the latest stable release.
+What I mean is, if it is possible to have backports of newer releases for 
+big projects, like KDE (and other DEs), libreoffice, firefox, samba 
+(important at work), ..., then I am fine with a 1 year release cycle of 
+proposal #3.
+
+If the maintainer of such big projects (especially the DEs) think it would 
+be too hard to backports newer versions to the 8-10 months old stack of the 
+latest stable release (as I have seen recently such discussions on KDE MLs), 
+then I would prefer proposal #2 to not be lacking behind too much.
+
+cheers
+-- 
+Renaud Michel
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005462.html b/zarb-ml/mageia-dev/2011-June/005462.html new file mode 100644 index 000000000..75f4a8e61 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005462.html @@ -0,0 +1,265 @@ + + + + [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2

+ Dick Gevers + dvgevers at xs4all.nl +
+ Mon Jun 13 03:19:16 CEST 2011 +

+
+ +
On Sun, 12 Jun 2011 14:24:11 +0200 (CEST), Mageia Team wrote about [RPM]
+cauldron core/release biew-6.1.0-1.mga2:
+
+>Name        : biew                         Relocations: (not relocatable)
+>Version     : 6.1.0                             Vendor: Mageia.Org
+>Release     : 1.mga2                        Build Date: Sun Jun 12
+>14:22:51 2011 Install Date: (not installed)               Build Host:
+
+
+>kharec <kharec> 6.1.0-1.mga2:
+>+ Revision: 104890
+>- imported package biew
+
+Quite a few packages reached the mirrors since this one, but biew has not.
+
+( I have enabled distrib-coffee.ipsl.jussieu.fr and $MIRRORLIST ).
+
+Ciao,
+=Dick Gevers=
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005463.html b/zarb-ml/mageia-dev/2011-June/005463.html new file mode 100644 index 000000000..69d903af5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005463.html @@ -0,0 +1,194 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ magnus + magnus.mud at googlemail.com +
+ Mon Jun 13 08:56:00 CEST 2011 +

+
+ +
>From a long time mandriva (and now mageia) user POV, for myself I was quite
+> fine with 6 month release cycle, but at work I'd rather not update too
+> frequently and same goes for the rest of the family who generally don't
+> care
+> much for newer versions. And I know that for some people, a big upgrade
+> every 6 month is a lot of work (and skipping a release is more risky).
+>
+I agree and think this the the sight of most of the "normal" users.
+
+Proposal #2 is the right time to discuss, to do greater changes and to
+test.
+Especially testing-time should be a focus to get a standing as very stable
+distri.
+
+Other hand, we should not hang too close to the nine month.
+The release date could be a good "human readable" date:
+
+Mageia 2 = Spring time (2012-03-20)
+Mageia 3 = Nicolas (2012-12-06)
+Mageia 4 = Revolution (2013-07-14) or Birthday (2013-09-18)
+
+or someting like this
+
+Proposal #3 is too long, for the patience of the users and developers
+
+Magnus
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110613/8c643b61/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005464.html b/zarb-ml/mageia-dev/2011-June/005464.html new file mode 100644 index 000000000..68ac5c686 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005464.html @@ -0,0 +1,176 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Dick Gevers + dvgevers at xs4all.nl +
+ Mon Jun 13 09:18:30 CEST 2011 +

+
+ +
On Mon, 13 Jun 2011 00:58:36 +0200, Zézinho wrote about Re: [Mageia-dev]
+Release cycles proposals, and discussion:
+
+>Em 12-06-2011 22:46, Michael Scherer escreveu:
+>> - all proposals must be justified ( and why they are better than the
+>> current ones ).
+>>
+>9 months means no yearly loop. Humans are used to seasons, and except 
+>for things that do not happen yearly, this is inside our genetics ;-) 
+
+Nine months is genetically very human: the average human female carries
+it's offspring for that length of time. So why not Mageia ?
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005465.html b/zarb-ml/mageia-dev/2011-June/005465.html new file mode 100644 index 000000000..0b4143b91 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005465.html @@ -0,0 +1,181 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Andres Kaaber + andres.kaaber at gmail.com +
+ Mon Jun 13 09:19:59 CEST 2011 +

+
+ +
...
+I wold go for the 9 mo cycle (most probably I will use cauldron for
+myself ;) ) 9 mo release gives enoug time for developers and its not
+so long time (for me, my wifes pregnancy went so quckly :) ) and for
+users with a need for a longer support LTS. I dont remember who said
+it but I liked the idea that we decide wich release will be LTS.
+Another thing ... for me A new "release" devides into two. First -
+upgraded software, KDE, GNOME, LibO, kernel etc. software that is not
+made by Mageia developers and second software that is made by Mageia
+developers drak* etc. For me the real value of distro comes from these
+tools wich are made by distro developers. There where lots of Mandriva
+releases with no noticeable changes in Mandriva tools. So the 9 mo
+release will give more time to make better / bugfree distro specific
+tools.
+
+-- 
+A. Kaaber
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005466.html b/zarb-ml/mageia-dev/2011-June/005466.html new file mode 100644 index 000000000..47cd420ca --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005466.html @@ -0,0 +1,273 @@ + + + + [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2

+ Cazzaniga Sandro + cazzaniga.sandro at gmail.com +
+ Mon Jun 13 09:37:40 CEST 2011 +

+
+ +
Le 13/06/2011 03:19, Dick Gevers a écrit :
+> On Sun, 12 Jun 2011 14:24:11 +0200 (CEST), Mageia Team wrote about [RPM]
+> cauldron core/release biew-6.1.0-1.mga2:
+> 
+>> Name        : biew                         Relocations: (not relocatable)
+>> Version     : 6.1.0                             Vendor: Mageia.Org
+>> Release     : 1.mga2                        Build Date: Sun Jun 12
+>> 14:22:51 2011 Install Date: (not installed)               Build Host:
+> 
+> 
+>> kharec <kharec> 6.1.0-1.mga2:
+>> + Revision: 104890
+>> - imported package biew
+> 
+> Quite a few packages reached the mirrors since this one, but biew has not.
+> 
+> ( I have enabled distrib-coffee.ipsl.jussieu.fr and $MIRRORLIST ).
+> 
+> Ciao,
+> =Dick Gevers=
+So it needs a rebuild?
+
+-- 
+Sandro Cazzaniga - https://lederniercoupdarchet.wordpress.com
+IRC: Kharec (irc.freenode.net)
+Software/Hardware geek
+Conceptor
+Magnum's Coordinator/editor (http://wiki.mandriva.com/fr/Magnum)
+Mageia and Mandriva contributor
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005467.html b/zarb-ml/mageia-dev/2011-June/005467.html new file mode 100644 index 000000000..81e89a373 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005467.html @@ -0,0 +1,154 @@ + + + + [Mageia-dev] perl 5.14.0 now available + + + + + + + + + +

[Mageia-dev] perl 5.14.0 now available

+ Jerome Quelin + jquelin at gmail.com +
+ Mon Jun 13 10:00:23 CEST 2011 +

+
+ +
On 11/06/12 16:02 -0700, Thomas Spuhler wrote:
+> I am not a perl guru. I agreed with sander85 to start at the end so we don't 
+> both work on the same packages. 
+
+thanks for your help!
+
+> I used this list: http://pkgsubmit.mageia.org/data/src.txt
+
+the list to use is:
+$ urpmf --requires :perlapi-5.12 | cut -d: -f1 | sort -u
+
+> Will it hurt to build one that is not needed?
+
+no, it's just useless. :-)
+
+anyway, thanks for the work: only 12 packages are left in the list. the
+bad news is that perl-DBD-SQLite is not rebuilt, and a central package.
+i need to dig further...
+
+jérôme 
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005468.html b/zarb-ml/mageia-dev/2011-June/005468.html new file mode 100644 index 000000000..35ba14af1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005468.html @@ -0,0 +1,132 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Angelo Naselli + anaselli at linux.it +
+ Mon Jun 13 10:17:49 CEST 2011 +

+
+ +
domenica 12 giugno 2011 alle 23:45, Barry Jackson ha scritto:
+> Ah - sorry, that is a full stop. I was looking for an extraneous dot.
+> I assume then that a full stop is either not required or ilegal in a 
+> summary? Does it break something?
+> 
+IIRC rpmlint should tell you as a warning.
+
+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/20110613/f90a3a85/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005469.html b/zarb-ml/mageia-dev/2011-June/005469.html new file mode 100644 index 000000000..39b434a48 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005469.html @@ -0,0 +1,175 @@ + + + + [Mageia-dev] Perl conflicts + + + + + + + + + +

[Mageia-dev] Perl conflicts

+ Jerome Quelin + jquelin at gmail.com +
+ Mon Jun 13 10:52:49 CEST 2011 +

+
+ +
On 11/06/12 14:13 -0400, Frank Griffin wrote:
+> On 06/12/2011 02:02 PM, Sander Lepik wrote:
+> >
+> >https://bugs.mageia.org/show_bug.cgi?id=1756
+> Thanks for the response.  I saw that one, but it only deals with
+> JSON, and it's marked FIXED.  There seemed to be more involved here.
+
+Class::MOP has been merged in upstream Moose since version 2.0000
+
+it's not a problem in mageia 1 since class::mop was last compiled with
+perl 5.12.2 and moose with perl 5.12.3, therefore they have different
+paths.
+
+i've just fixed perl-Moose to obsoletes: & provides perl-Class-MOP, so
+this conflicts should be gone next time you refresh your mirror.
+
+keep me informed if that's not the case.
+
+thanks,
+jérôme 
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005470.html b/zarb-ml/mageia-dev/2011-June/005470.html new file mode 100644 index 000000000..9bd6825da --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005470.html @@ -0,0 +1,153 @@ + + + + [Mageia-dev] "Job offer" : mentoring program coordinator + + + + + + + + + +

[Mageia-dev] "Job offer" : mentoring program coordinator

+ Michael Scherer + misc at zarb.org +
+ Mon Jun 13 11:20:30 CEST 2011 +

+
+ +
Le dimanche 12 juin 2011 à 18:52 -0400, andre999 a écrit :
+
+> But also mentoring can apply to other things than packaging.  So maybe we should give a broader 
+> scope to the mentoring coordinator job ?
+> Including bugteam, QA, as well as packaging.
+> That would make it more useful, as well as more interesting.
+> (I would be very interested in contributing to something like that.)
+
+Given there is no mentoring program for others teams, I do not think
+adding a coordinator is gonna coordinate much.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005471.html b/zarb-ml/mageia-dev/2011-June/005471.html new file mode 100644 index 000000000..23763a688 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005471.html @@ -0,0 +1,259 @@ + + + + [Mageia-dev] Some news regarding rpm packaging rules : %clean section + + + + + + + + + +

[Mageia-dev] Some news regarding rpm packaging rules : %clean section

+ Dexter Morgan + dmorganec at gmail.com +
+ Mon Jun 13 11:31:26 CEST 2011 +

+
+ +
Hello,
+
+i will regurlarly mail this list when things change regarding
+packaging rules in rpm itself.
+
+
+First change, since rpm 4.8.0 you don't need to add the %clean
+section, if none is on the spec file, a default one will be used .
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005472.html b/zarb-ml/mageia-dev/2011-June/005472.html new file mode 100644 index 000000000..6dd89f3cc --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005472.html @@ -0,0 +1,280 @@ + + + + [Mageia-dev] Question about backports: calibre (bug 1659) + + + + + + + + + +

[Mageia-dev] Question about backports: calibre (bug 1659)

+ Radu-Cristian FOTESCU + beranger5ca at yahoo.ca +
+ Mon Jun 13 11:51:18 CEST 2011 +

+
+ +
Folks, 
+
+WRT https://bugs.mageia.org/show_bug.cgi?id=1659
+[Bug 1659] Calibre is too old (0.7.32 vs. 0.8.4, i.e. 31 versions behind!)
+
+
+Two people asserted that a newer calibre package should go into backports, not updates.
+
+I strongly believe quite the contrary.
+
+
+I'd like to bring to your attention that calibre, the e-book reader and converter, has an extremely dynamic lifecycle: it released 32 versions in 6 months! Thirty-two versions! (I don't know of any other software that does that, virus signatures not counted.)
+
+
+Sure thing, some releases might bring some regressions, but each and every version fixes bugs, adds new features, adds support for newer e-reader models, etc. etc. Also, the developer of calibre quickly releases a newer build in the case of serious regressions -- most of the times within 0 to a few days.
+
+Calibre is not like Firefox, to have security fixes that would _require_ a new release to be updated rather than ignored, however, as it's a one-person project (yet a very, very, very popular one! and quite unique in features), it has a number of bugs. Newer versions are most of the time bug-fix releases too, so it's usually a bad idea to skip upgrading it.
+
+Therefore, I strongly believe that all calibre updates be packaged into updates, not backports, especially as there isn't any Mageia 2.0 as of yet. Once Mageia 2.0 is released, whatever newer calibre releases will be available might go into backports instead -- if at all. (Although I'd say that it should still be updated to updates for the whole supported time of 1.0.)
+
+What do you think?
+
+Thank you,
+R-C (aka Beranger with an acute accent)
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005473.html b/zarb-ml/mageia-dev/2011-June/005473.html new file mode 100644 index 000000000..671e1976f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005473.html @@ -0,0 +1,291 @@ + + + + [Mageia-dev] Some news regarding rpm packaging rules : %clean section + + + + + + + + + +

[Mageia-dev] Some news regarding rpm packaging rules : %clean section

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Mon Jun 13 11:52:32 CEST 2011 +

+
+ +
'Twas brillig, and Dexter Morgan at 13/06/11 10:31 did gyre and gimble:
+> Hello,
+> 
+> i will regurlarly mail this list when things change regarding
+> packaging rules in rpm itself.
+> 
+> 
+> First change, since rpm 4.8.0 you don't need to add the %clean
+> section, if none is on the spec file, a default one will be used .
+
+Nice :)
+
+Note to other packagers: Please don't go cleaning (no pun intended) spec
+files without thinking. As with all changes to rpm specs (such as the
+infamous buildroot change of '09 :D) making the specs clean for one
+distro version makes it harder/impossible to backport. This is not
+always a problem, so we should try and keep things clean if possible,
+but keep in mind that it can take ~2years before such new features can
+be used in all packages without worrying (obviously this is the extreme
+example - for the vast majority of packages, backporting is not really a
+consideration).
+
+All the best
+
+
+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-June/005474.html b/zarb-ml/mageia-dev/2011-June/005474.html new file mode 100644 index 000000000..46dac93f6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005474.html @@ -0,0 +1,285 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Ron + corbintechboy at yahoo.com +
+ Mon Jun 13 12:07:38 CEST 2011 +

+
+ +
I made another post in a different thread about the way I feel the release cycle should go. After more thinking I do think that I really have the right idea and here is why...
+Going the route of release cycles really does not make this distribution fit into anything. You going to try and appeal to new people? Ubuntu has that covered and you will never steal that role. Hoping to become a geek type distro? There are many that have that covered. 
+The best thing you can do as a team is try to come up with something that makes you stand apart from the crowd. I never understood the release cycle model anyhow, whats the goal of that? To show off the latest tech in the open source world? Really? With Slackware and Fedora and Suse and hosts of other flavors of GNU/Linux all doing the same thing?
+What do we have that others don't? We have something new that can be great if planned right. There are 100's of distros releasing in cycles, let's get out of that and truly showcase the best of open source through:
+Unstable branch - absolute latest software here...Rolling unstable - Still risky but not on the lines of unstableRolling stable - everyday use and very stable 
+You could throw in "snapshots" and support those for X amount of time as I have posted in the other place if you wanted (based on rolling unstable). You could also have LTS releases based on Rolling stable.... It's up to you.
+I don't believe we need yet another "burn new disk every X months for????" distribution. 
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110613/e6448a8c/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005475.html b/zarb-ml/mageia-dev/2011-June/005475.html new file mode 100644 index 000000000..9f245e6c0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005475.html @@ -0,0 +1,349 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Michael Scherer + misc at zarb.org +
+ Mon Jun 13 12:40:39 CEST 2011 +

+
+ +
Le lundi 13 juin 2011 à 03:07 -0700, Ron a écrit :
+> I made another post in a different thread about the way I feel the release cycle should go. After more thinking
+>  I do think that I really have the right idea and here is why...
+> Going the route of release cycles really does not make this distribution fit into anything. You going to try 
+> and appeal to new people? Ubuntu has that covered and you will never steal that role. Hoping to become a geek type 
+> distro? There are many that have that covered. 
+>
+> The best thing you can do as a team is try to come up with something that makes you stand apart from the crowd.
+
+There is a limited set of options, and as you can see, none of your idea
+was not already explored by someone else.
+
+>  I never understood the release cycle model anyhow, whats the goal of that? 
+
+If everything move all days, you cannot :
+- translate software ( as the string will change every day )
+- create documentation ( for the same reason )
+- communicate ( as everything ca be broken at any time )
+- ensure stability ( as each change can bring unstability )
+
+And for user, some do not want to redo training every week for their
+users, because libreoffice got updated, because ff 4 just arrived and
+75% of extensions do not work, etc. 
+
+In fact, the whole release model is basically what is used all over the
+place, from lower level like kernel to higher level like kde. So you can
+get lots of feedback on it.
+
+> To show off the latest tech in the open source world? Really? With Slackware and Fedora and 
+> Suse and hosts of other flavors of GNU/Linux all doing the same thing?
+
+So basically, you suggest that since everybody is already doing it, this
+is useless. So the logical conclusion is we should drop the
+distribution ?
+
+> What do we have that others don't? 
+
+We have the same thing, this is the strength of free software. We
+basically all work together.
+
+
+> We have something new that can be great 
+> if planned right. There are 100's of distros releasing in cycles, let's get 
+> out of that and truly showcase the best of open source through:
+> Unstable branch - absolute latest software here...
+
+like cauldron ? or debian unstable, fedora rawhide, opensuse factory,
+mandriva cooker ?
+
+> Rolling unstable - Still risky but not on the lines of unstable
+
+like debian testing ( and CUT ) ? suse tumbleweed ? arch linux ?
+
+
+> Rolling stable - everyday use and very stable 
+
+Very stable for a distribution mean "that do not change". That's
+incompatible with the idea of rolling per definition. And in order to
+have stable software, you have to freeze them and fix bugs. So to have
+that on the whole distribution, you need to freeze the whole
+distribution for a time, and then ask for test, fix bugs and then
+release. Which is exactly what we currently do since years. 
+
+> You could throw in "snapshots" and support those for X amount of time 
+> as I have posted in the other place if you wanted (based on rolling unstable). 
+> You could also have LTS releases based on Rolling stable.... It's up to you.
+> I don't believe we need yet another "burn new disk every X months for????" distribution. 
+
+So basically, you just reinvented the concept of release, and the way
+Mandriva, Debian, Fedora work since years. 
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005476.html b/zarb-ml/mageia-dev/2011-June/005476.html new file mode 100644 index 000000000..ae08a8995 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005476.html @@ -0,0 +1,267 @@ + + + + [Mageia-dev] Some news regarding rpm packaging rules : %clean section + + + + + + + + + +

[Mageia-dev] Some news regarding rpm packaging rules : %clean section

+ Balcaen John + mikala at mageia.org +
+ Mon Jun 13 12:46:37 CEST 2011 +

+
+ +
Le lundi 13 juin 2011 06:31:26, Dexter Morgan a écrit :
+> Hello,
+> 
+> i will regurlarly mail this list when things change regarding
+> packaging rules in rpm itself.
+> 
+> 
+> First change, since rpm 4.8.0 you don't need to add the %clean
+> section, if none is on the spec file, a default one will be used .
+> 
+We'll need to fix also rpmlint-mageia-policy to remove the warning in case of 
+missing %clean section.
+
+-- 
+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-June/005477.html b/zarb-ml/mageia-dev/2011-June/005477.html new file mode 100644 index 000000000..c495e6139 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005477.html @@ -0,0 +1,179 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Thorsten van Lil + tvl83 at gmx.de +
+ Mon Jun 13 13:01:30 CEST 2011 +

+
+ +
Am Sonntag, 12. Juni 2011, 22:46:33 schrieb Michael Scherer:
+> Proposal 1: 
+> 6 months release cycle -> 12 months life cycle
+> ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
+> 
+> Proposal 2: 
+> 9 months release cycle -> 18 months life cycle  
+> ( ~ opensuse and the one we used for Mageia 1 )
+> 
+> Proposal 3: 
+> 12 months release cycle -> 24 months life cycle
+> ( Mandriva > 2010.1 )
+
+Has there already been a discussion about the general release model (static, 
+rolling, light rolling, ...)? I only saw one on the forum but not a (official) 
+discussion on the ml.
+
+Greetings,
+Thorsten
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005478.html b/zarb-ml/mageia-dev/2011-June/005478.html new file mode 100644 index 000000000..74323e183 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005478.html @@ -0,0 +1,294 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ P. Christeas + xrg at linux.gr +
+ Mon Jun 13 12:59:43 CEST 2011 +

+
+ +
On Monday 13 June 2011, Michael Scherer wrote:
+
+> > What do we have that others don't?
+> 
+> We have the same thing, this is the strength of free software. We
+> basically all work together.
+
+
+Well, what I've always enjoyed about Mandriva (as implemented by some people 
+of a company called "Edge-IT") was they worked a little different than other 
+major distros (see. Debian) :
+- they would take any latest minor number of upstream projects, based just on 
+the promise that minor releases were bugfix ones on otherwise stable series.
+- lacking the luxury of a huge community and extensive tests, they would 
+immediately package that and push it to Cooker, at least.
+
+Most of the time, that strategy worked marvelously. We had all the upstream 
+bugfixes, truly imported with their release number. 
+
+-- 
+Say NO to spam and viruses. Stop using Microsoft Windows!
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005479.html b/zarb-ml/mageia-dev/2011-June/005479.html new file mode 100644 index 000000000..0401ff669 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005479.html @@ -0,0 +1,134 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Barry Jackson + zen25000 at zen.co.uk +
+ Mon Jun 13 13:08:24 CEST 2011 +

+
+ +
On 13/06/11 09:17, Angelo Naselli wrote:
+
+> IIRC rpmlint should tell you as a warning.
+>
+> Angelo
+
+Thanks Angelo,
+I never used rpmlint before, so I installed it.
+It did not warn about the dot, but it did pick up a few spaces/tabs etc.
+There is a warning about Group: Networking/Instant messaging being 
+non-standard, however this is used by the pidgin package.
+
+I am adding a script to generate the text file sources used in %install, 
+I assume that this should be included in the package as a SOURCE with a 
+comment, but not referenced elsewhere as it is only a packaging tool.
+
+Barry
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005480.html b/zarb-ml/mageia-dev/2011-June/005480.html new file mode 100644 index 000000000..e8b895d53 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005480.html @@ -0,0 +1,134 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Mon Jun 13 13:13:41 CEST 2011 +

+
+ +
Barry Jackson <zen25000 at zen.co.uk> schrieb am 13.06.2011
+> On 13/06/11 09:17, Angelo Naselli wrote:
+> > IIRC rpmlint should tell you as a warning.
+> 
+> Thanks Angelo,
+> I never used rpmlint before, so I installed it.
+> It did not warn about the dot, but it did pick up a few spaces/tabs
+> etc. There is a warning about Group: Networking/Instant messaging
+> being non-standard, however this is used by the pidgin package.
+Have you also installed rpmlint-mageia-policy?
+Otherwise rpmlint will give you quite some warnings about Mageia 
+specific things.
+
+Oliver
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110613/1149e3a9/attachment-0001.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005481.html b/zarb-ml/mageia-dev/2011-June/005481.html new file mode 100644 index 000000000..2fdcee3e6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005481.html @@ -0,0 +1,300 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Radu-Cristian FOTESCU + beranger5ca at yahoo.ca +
+ Mon Jun 13 13:16:22 CEST 2011 +

+
+ +
> Unstable branch - absolute latest software here...
+> Rolling unstable - Still risky but not on the lines of unstable
+> Rolling stable - everyday use and very stable 
+
+May I add my bit of unrequested thoughts?
+
+This discussion seems to only differentiate between "degrees of unstability and risks", but nothing about "user roles". 
+IMHO, a distro is not only about "risk vs. features", but also about what people are expecting from it.
+
+I could imagine for user roles:
+
+"rolling-user" branch: 
+-- KDE4, GNOME3, XFCE, LibreOffice, Firefox/Thunderbird, Chromium are always kept to the latest _stable_ (not development) version;
+-- other applications might be kept (or not) to the latest _stable_ (not development) version; 
+-- other libraries are to be upgraded _only_ if they're required by newer applications.
+
+"rolling-user-risky" branch: 
+-- KDE4, GNOME3, XFCE, LibreOffice, Firefox/Thunderbird, Chromium are always kept to the latest _development_/_unstable_ version;
+-- other applications might be kept to the latest _development_/_unstable_ version, otherwise most are kept to the latest _stable_ version; 
+-- other libraries are to be upgraded _only_ as they're required by newer applications.
+
+"rolling-developer" branch: 
+-- everything updated to the latest _development_/_unstable_ versions of everything.
+
+Does this make any sense?
+
+Best regards,
+R-C (aka Beranger with an e acute)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005482.html b/zarb-ml/mageia-dev/2011-June/005482.html new file mode 100644 index 000000000..a7709aff0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005482.html @@ -0,0 +1,153 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Barry Jackson + zen25000 at zen.co.uk +
+ Mon Jun 13 13:22:42 CEST 2011 +

+
+ +
On 13/06/11 12:13, Oliver Burger wrote:
+> Barry Jackson <zen25000 at zen.co.uk> schrieb am 13.06.2011
+>
+>  > On 13/06/11 09:17, Angelo Naselli wrote:
+>
+>  > > IIRC rpmlint should tell you as a warning.
+>
+>  >
+>
+>  > Thanks Angelo,
+>
+>  > I never used rpmlint before, so I installed it.
+>
+>  > It did not warn about the dot, but it did pick up a few spaces/tabs
+>
+>  > etc. There is a warning about Group: Networking/Instant messaging
+>
+>  > being non-standard, however this is used by the pidgin package.
+>
+> Have you also installed rpmlint-mageia-policy?
+>
+> Otherwise rpmlint will give you quite some warnings about Mageia
+> specific things.
+>
+>
+> Oliver
+>
+
+Thanks Oliver
+
+No, I did not know about that, I was wondering where rpmlint got it's 
+references from.
+
+That fixed it ;)
+
+Barry
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005483.html b/zarb-ml/mageia-dev/2011-June/005483.html new file mode 100644 index 000000000..1c0efb88a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005483.html @@ -0,0 +1,241 @@ + + + + [Mageia-dev] Cross compile x86_64 on i586 for icecream? + + + + + + + + + +

[Mageia-dev] Cross compile x86_64 on i586 for icecream?

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Mon Jun 13 13:24:37 CEST 2011 +

+
+ +
On Mon, 13 Jun 2011, Colin Guthrie wrote:
+
+> I'm not exactly a guru with icecream but is it possible to build a
+> toolchain that can allow i586 nodes to compile x86_64 code?
+
+If your question is about the toolchain, have you tried simply passing 
+-m64 to gcc?
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005484.html b/zarb-ml/mageia-dev/2011-June/005484.html new file mode 100644 index 000000000..379ef6ea3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005484.html @@ -0,0 +1,217 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Michael Scherer + misc at zarb.org +
+ Mon Jun 13 13:36:07 CEST 2011 +

+
+ +
Le lundi 13 juin 2011 à 01:06 +0300, Sander Lepik a écrit :
+> 12.06.2011 23:46, Michael Scherer kirjutas:
+> > Proposal 1:
+> > 6 months release cycle ->  12 months life cycle
+> > ( Fedora, Ubuntu, Mandriva<  2010.1&&  Mandriva != 2006.0 )
+> >
+> > Proposal 2:
+> > 9 months release cycle ->  18 months life cycle
+> > ( ~ opensuse and the one we used for Mageia 1 )
+> >
+> > Proposal 3:
+> > 12 months release cycle ->  24 months life cycle
+> > ( Mandriva>  2010.1 )
+>  From those options i would go with the second one. Third is way too much wanted from users 
+> (and first has too short life cycle). They are always eager for new stuff and waiting one 
+> year ain't option for them. We could also try to have some LTS versions. But in a bit 
+> different manner than Ubuntu. Like if we notice that some release is good and stable we 
+> could extend its support period (ie mdv2008.1 was really stabel and also mdv2010.1 was 
+> pretty good - for me neither had too many problems and i would have keeped 2008.1 for longer 
+> but its support ended).
+
+The LTS discussion is for next week :)
+
+> One more thing i didn't like with Mageia 1. Official launch date that you know is coming and 
+> you see that not all things are ready for prime time but you go anyway as there is launch 
+> date announced. Ubuntu has failed with that at least few times.
+> Debian (Mozilla somewhat too) does better job here. They don't release if they see critical 
+> problems and they don't announce release too far away.
+> In that hurry we probably missed ATI graphics problem and could have solved it better.
+
+Another solution is to  have a longer freeze period, so people focus
+less on last minutes changes and packages upgrades, and more on bug
+fixing.
+
+And we also do not release if there is critical problem, the question is
+more "what is critical". It must also be take in account that we didn't
+finish the setup of infrastructure, so we will have likely more time and
+less burden next time. 
+
+
+> Maybe we should try to have 9 months but if it will be 10 with more stable release i would 
+> go with 10 (or mabye final freeze in 8 months and then we'll see how fast we can make it 
+> stable).
+> 
+> (And we have to keep up the good job with upgrading smoothness - in the future it must be 
+> tested even more, that way users who want longer cycle will complain less if they can 
+> upgrade their system w/o big problems.)
+
+For that, I guess we could do automated upgrade testing, something
+like : 
+ - we setup a vm ( scriptable + tftp + pxe )
+ - we install as much as possible ( auto installation )
+ - we do a scripted upgrade ( auto installation + at / cron )
+ - we check if it reboot fine ( a init script + a timeout somewhere ? )
+
+this will not solve everything, but this would be a good start. The main
+problem is to decide if the upgrade went well or not for all possible
+case.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005485.html b/zarb-ml/mageia-dev/2011-June/005485.html new file mode 100644 index 000000000..d029ab836 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005485.html @@ -0,0 +1,259 @@ + + + + [Mageia-dev] Question about backports: calibre (bug 1659) + + + + + + + + + +

[Mageia-dev] Question about backports: calibre (bug 1659)

+ James Kerr + jim at jkerr82508.free-online.co.uk +
+ Mon Jun 13 13:41:14 CEST 2011 +

+
+ +
On 13/06/11 10:51, Radu-Cristian FOTESCU wrote:
+
+>
+> Therefore, I strongly believe that all calibre updates be packaged
+> into updates, not backports, especially as there isn't any Mageia 2.0
+> as of yet.
+>
+
+The reference to backporting means backporting from Cauldron.
+
+Jim
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005486.html b/zarb-ml/mageia-dev/2011-June/005486.html new file mode 100644 index 000000000..cddff5b56 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005486.html @@ -0,0 +1,162 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Mon Jun 13 13:46:19 CEST 2011 +

+
+ +
Op maandag 13 juni 2011 13:36:07 schreef Michael Scherer:
+[...]
+> Another solution is to  have a longer freeze period, so people focus
+> less on last minutes changes and packages upgrades, and more on bug
+> fixing.
+
+i would be in favor of that.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005487.html b/zarb-ml/mageia-dev/2011-June/005487.html new file mode 100644 index 000000000..35d81f63e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005487.html @@ -0,0 +1,179 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ David Sjölin + david.sjolin at gmail.com +
+ Mon Jun 13 13:46:32 CEST 2011 +

+
+ +
On Mon, Jun 13, 2011 at 1:01 PM, Thorsten van Lil <tvl83 at gmx.de> wrote:
+> Am Sonntag, 12. Juni 2011, 22:46:33 schrieb Michael Scherer:
+>> Proposal 1:
+>> 6 months release cycle -> 12 months life cycle
+>> ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
+>>
+>> Proposal 2:
+>> 9 months release cycle -> 18 months life cycle
+>> ( ~ opensuse and the one we used for Mageia 1 )
+>>
+>> Proposal 3:
+>> 12 months release cycle -> 24 months life cycle
+>> ( Mandriva > 2010.1 )
+
+Hello!
+
+I'm for proposal 2 as well. I usually use LTS of Ubuntu at work, and
+at home just keep the distribution for a long time, so I would like
+far between, but I know a lot of colleagues who always install the
+latest so the middle ground of 9 months seems good to me.
+
+Regards,
+
+David
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005488.html b/zarb-ml/mageia-dev/2011-June/005488.html new file mode 100644 index 000000000..94ed45137 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005488.html @@ -0,0 +1,188 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Mon Jun 13 14:01:37 CEST 2011 +

+
+ +
Michael Scherer <misc at zarb.org> schrieb am 12.06.2011
+> Proposal 1:
+> 6 months release cycle -> 12 months life cycle
+> ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
+> 
+> Proposal 2:
+> 9 months release cycle -> 18 months life cycle
+> ( ~ opensuse and the one we used for Mageia 1 )
+> 
+> Proposal 3:
+> 12 months release cycle -> 24 months life cycle
+> ( Mandriva > 2010.1 )
+That's kind of a hard decison. I don't know if a 6 month cycle would 
+not put too much stress on the dev/packager community. But 12 months 
+are a bit much for the hordes of impatient users usually residing in 
+the forums.
+So I would - for now - prefer option 2, 9 months seeming a reasonable 
+time span.
+
+Especially since we would always be able to change that cycle to 
+something more fitting.
+
+As to the "rolling" and the "lts" discussion. I think it's something 
+for the future. We first have to see, how much manpower we really have, 
+to maintain the distro.
+
+I woul then kind of like the idea of a special rolling repo like 
+debian testing or suse tumbleweed.
+
+Oliver
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110613/def4bfb8/attachment-0001.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005489.html b/zarb-ml/mageia-dev/2011-June/005489.html new file mode 100644 index 000000000..aa2da6947 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005489.html @@ -0,0 +1,305 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Ron + corbintechboy at yahoo.com +
+ Mon Jun 13 14:04:51 CEST 2011 +

+
+ +
>There is a limited set of options, and as you can see, none of your >idea was not already explored by someone else.
+It has all been done before, in that sense let's just close up shop and call it a day???
+>If everything move all days, you cannot :
+>- translate software ( as the string will change every day )
+>- create documentation ( for the same reason )
+>- communicate ( as everything ca be broken at any time )
+>- ensure stability ( as each change can bring unstability )
+
+>And for user, some do not want to redo training every week for >their
+>users, because libreoffice got updated, because ff 4 just arrived >and
+>75% of extensions do not work, etc. 
+>
+>In fact, the whole release model is basically what is used all >over the
+>place, from lower level like kernel to higher level like kde. So >you can
+>get lots of feedback on it.
+You are correct on the release model being used everywhere, that fit's development and really there is no other way to do it as it takes time. But really, up stream does have to take time but package maintainers can pull things in pretty fast and make things work.
+I don't understand what's being said here? Are we a community of users or are we just teachers teaching a class? Help with changes is what forums and people are for. 
+You worried about not being able to keep up with documentation? I suggest you take a look at the Arch wiki, best Linux wiki there is and things change fast... Again, community...
+>So basically, you suggest that since everybody is already doing >it, this is useless. So the logical conclusion is we should drop >the distribution ?
+No that is not what I'm saying! 
+What I am saying is that you have 100+/- distributions all going by a release model and only a handful making rolling releases. There is only one defacto maker of a rolling release and that is Arch, why does this have to be? (Yes I know there are others but Arch is the leader of the pack)
+>We have the same thing, this is the strength of free software. We
+>basically all work together.
+It truly is redundant to do what everyone else is doing just because....
+>like cauldron ? or debian unstable, fedora rawhide, opensuse >factory,mandriva cooker ?
+Sure, there has to be an unstable branch whether rolling or not...
+>like debian testing ( and CUT ) ? suse tumbleweed ? arch linux
+Nope, gotta call you on this... Debian testing rolls with the purpose of becoming a release... Therefore things can grow outdated rather quickly. 
+Suse tumblweed IS NOT going to be a true rolling release! It is going to "tumble up" to the next release hence the name.
+This cannot be compared to Arch either as Arch has a set of rules as well and rolls into stable...
+>Very stable for a distribution mean "that do not change". That's
+>incompatible with the idea of rolling per definition. And inorder >to have stable software, you have to freeze them and fix bugs. So >to have that on the whole distribution, you need to freeze the >whole distribution for a time, and then ask for test, fix bugs >and then release. Which is exactly what we currently do since >years.
+Sorry, your wrong! I have been using Arch for years and have yet to meet a show stopper bug, it is very stable. 
+Stability simply means tested! It does not have to be like Debian testing that grows stale with time, you can remain very very close to bleeding edge and still remain stable...
+>So basically, you just reinvented the concept of release, and the >way Mandriva, Debian, Fedora work since years. 
+And I must have peed in your cheerios... I am all for giving people what they want, I also don't think you have to follow the status quo to do so... We don't have to be "just another distribution doing the same things the others are doing"... Sorry, but this is what I see....
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110613/b1599667/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005490.html b/zarb-ml/mageia-dev/2011-June/005490.html new file mode 100644 index 000000000..d52c9863b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005490.html @@ -0,0 +1,243 @@ + + + + [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2

+ Dick Gevers + dvgevers at xs4all.nl +
+ Mon Jun 13 14:06:28 CEST 2011 +

+
+ +
On Mon, 13 Jun 2011 09:37:40 +0200, Cazzaniga Sandro wrote about Re:
+[Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2:
+
+>> Quite a few packages reached the mirrors since this one, but biew has
+>> not.
+
+>So it needs a rebuild?
+
+Anything similar to rebuild, push, boot, shove, %mkrel or opening the window
+to let it fly: IANAE.
+
+Thanks in advance,
+=Dick Gevers=
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005491.html b/zarb-ml/mageia-dev/2011-June/005491.html new file mode 100644 index 000000000..6761058f7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005491.html @@ -0,0 +1,206 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Michael Scherer + misc at zarb.org +
+ Mon Jun 13 14:19:20 CEST 2011 +

+
+ +
Le lundi 13 juin 2011 à 14:01 +0200, Oliver Burger a écrit :
+> Michael Scherer <misc at zarb.org> schrieb am 12.06.2011
+> > Proposal 1:
+> > 6 months release cycle -> 12 months life cycle
+> > ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
+> > 
+> > Proposal 2:
+> > 9 months release cycle -> 18 months life cycle
+> > ( ~ opensuse and the one we used for Mageia 1 )
+> > 
+> > Proposal 3:
+> > 12 months release cycle -> 24 months life cycle
+> > ( Mandriva > 2010.1 )
+> That's kind of a hard decison. I don't know if a 6 month cycle would 
+> not put too much stress on the dev/packager community. But 12 months 
+> are a bit much for the hordes of impatient users usually residing in 
+> the forums.
+> So I would - for now - prefer option 2, 9 months seeming a reasonable 
+> time span.
+> 
+> Especially since we would always be able to change that cycle to 
+> something more fitting.
+> 
+> As to the "rolling" and the "lts" discussion. I think it's something 
+> for the future. We first have to see, how much manpower we really have, 
+> to maintain the distro.
+> 
+> I woul then kind of like the idea of a special rolling repo like 
+> debian testing or suse tumbleweed.
+
+Well, has someone looked at what they do ?
+
+Debian testing is not a rolling release for users, but it is a base for
+the release. And bigger packages updates are slow to migrate, for
+example, there is still iceweael/firefox 3.X
+http://packages.debian.org/testing/web/iceweasel . So I am not sure that
+it will really bring what people want ( as this is not what it was
+designed for in the first place ).
+
+Gentoo model is heavily dependent on sources recompilation on user
+workstation so not applicable ( even if this is the closest of what
+people could want in term of package management ).
+
+I didn't look at the tumbleweed system, but I fear this is highly
+dependent on the Suse workflow, so if someone could do the research to
+explain clearly what it does for the next discussion, it would surely
+help. ( this also mean that people should keep such research for next
+discussion and do not mix with the current one )
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005492.html b/zarb-ml/mageia-dev/2011-June/005492.html new file mode 100644 index 000000000..6d1581524 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005492.html @@ -0,0 +1,130 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Angelo Naselli + anaselli at linux.it +
+ Mon Jun 13 14:20:05 CEST 2011 +

+
+ +
lunedì 13 giugno 2011 alle 13:13, Oliver Burger ha scritto:
+> Have you also installed rpmlint-mageia-policy?
+Shouldn't it be at least suggested?
+
+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/20110613/3e6ddee7/attachment-0001.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005493.html b/zarb-ml/mageia-dev/2011-June/005493.html new file mode 100644 index 000000000..3b309ce41 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005493.html @@ -0,0 +1,182 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Mon Jun 13 14:20:26 CEST 2011 +

+
+ +
About the cycles:
+
+The problems with 6-months have been pointed out - my main concern
+would be the lack of manpower and the continuous state of
+"pre-release", no real room to sit back and contemplate hwat is and
+what could be and all the rest. IMHO such a "contemplating" time is
+necessary to keep the whole picture in focus.
+
+The problems with 12-months have also been pointed out and I agree
+with them (too long out of public focus, too long for the main
+userland applications, etc.).
+
+The 9-months seem to be a compromise - but I start to ask why we need
+such a fixed statement (which it would be, once published). We need a
+schedule for each cycle, that's true. Without a schedule we would
+never finish anything. But how about taking 9 months only as a "nice
+to meet" target, leaving us the option to set a roadmap after setting
+the specs of the next release - we could then go for a 8 or 10 months
+roadmap, depending on the specs.
+
+This being said, I am a friend of a rolling release like ArchLinux,
+but I fear that our main target group is not up to this. Despite of
+having to "burn yet another DVD" as somebody pointed out, the majority
+seems to see this as normal and a good way. Of course I may be totally
+wrong with this assessment!
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005494.html b/zarb-ml/mageia-dev/2011-June/005494.html new file mode 100644 index 000000000..9aa105315 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005494.html @@ -0,0 +1,251 @@ + + + + [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2

+ Cazzaniga Sandro + cazzaniga.sandro at gmail.com +
+ Mon Jun 13 14:20:36 CEST 2011 +

+
+ +
Le 13/06/2011 14:06, Dick Gevers a écrit :
+> On Mon, 13 Jun 2011 09:37:40 +0200, Cazzaniga Sandro wrote about Re:
+> [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2:
+> 
+>>> Quite a few packages reached the mirrors since this one, but biew has
+>>> not.
+> 
+>> So it needs a rebuild?
+> 
+> Anything similar to rebuild, push, boot, shove, %mkrel or opening the window
+> to let it fly: IANAE.
+> 
+> Thanks in advance,
+> =Dick Gevers=
+Could you be more clear, please?
+
+-- 
+Sandro Cazzaniga - https://lederniercoupdarchet.wordpress.com
+IRC: Kharec (irc.freenode.net)
+Software/Hardware geek
+Conceptor
+Magnum's Coordinator/editor (http://wiki.mandriva.com/fr/Magnum)
+Mageia and Mandriva contributor
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005495.html b/zarb-ml/mageia-dev/2011-June/005495.html new file mode 100644 index 000000000..30cb5291b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005495.html @@ -0,0 +1,174 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Anssi Hannula + anssi.hannula at iki.fi +
+ Mon Jun 13 14:24:53 CEST 2011 +

+
+ +
On 12.06.2011 02:37, Barry Jackson wrote:
+> On 11/06/11 18:03, Anssi Hannula wrote:
+>>
+>> - Best to add a comment in the %post script to remind that any new files
+>>    need to have a %ghost entry created.
+>>    (btw: an alternative idea is to create a post-script and the filelist
+>>     at the same time in a single for loop in %build/%install, so that
+>>     the lists can never get out of sync as they are created from a single
+>>     list; however, your current solution is adequate as well)
+> 
+> Note added - keep it simple.
+> 
+
+You added the note in the %files section, not in %post. The issue only
+happens if someone updates %post but not %files, so it doesn't make
+sense to put the reminder in %files :)
+
+>> - You don't check for failures. If the mktemp call fails, you extract
+>>    the tarball into /root etc.etc.. You need to check for failures on
+>>    the mktemp/mkdir/cd commands (mktemp failure can be detected by
+>>    checking if $newtmp string is empty), or alternatively run "set -e"
+>>    to make the shell exit on failures (this leaves the tmpdir polluted,
+>>    but it doesn't matter as much as it is an uncommon failure case and
+>>    /tmp is cleaned periodically anyway).
+> 
+> Added some checks - with clean-up of previously created dirs etc on fail.
+
+> mkdir %{mytmp}
+> [[ -d %{mytmp} ]] || exit 1
+> cd %{mytmp}
+
+cd is not guaranteed to work even if %mytmp exists. Add "|| exit 1".
+
+> cd ${tmpextdir}
+> tar jxf %{mytmp}/skype-%{version}.tar.bz2
+
+Same here...
+
+Well, actually these two aren't that serious, since they can't be
+exploited by non-root anyway. I'm somewhat ok with them, as long as your
+mentor is as well and no one else objects.
+
+Note that your "if ! [[ -d %{tmpdir} ]]; then" check is not 100%
+necessary, as %tmpdir not existing is unlikely and causes no side effects.
+
+Other nits:
+- Use better variable names- %mytmp, $tmpextdir, %tmpdir are confusing.
+- The description starts with an empty line. Remove it.
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005496.html b/zarb-ml/mageia-dev/2011-June/005496.html new file mode 100644 index 000000000..f08930b9b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005496.html @@ -0,0 +1,186 @@ + + + + [Mageia-dev] weird bs behaviour + + + + + + + + + +

[Mageia-dev] weird bs behaviour

+ Anssi Hannula + anssi.hannula at iki.fi +
+ Mon Jun 13 14:25:10 CEST 2011 +

+
+ +
On 12.06.2011 19:13, Jerome Quelin wrote:
+> hi,
+> 
+> when rebuilding perl-DBD-SQLite and perl -DBD-SQLite2, i get some
+> strange cpio errors:
+> 
+> === PASTE ===
+[...]
+> extracting debug info from /home/iurt/rpm/BUILDROOT/perl-DBD-SQLite-1.330.0-1.mga2.i386/usr/lib/perl5/vendor_perl/5.14.0/i386-linux-thread-multi/auto/DBD/SQLite/SQLite.so
+> *** WARNING: No build ID note found in /home/iurt/rpm/BUILDROOT/perl-DBD-SQLite-1.330.0-1.mga2.i386/usr/lib/perl5/vendor_perl/5.14.0/i386-linux-thread-multi/auto/DBD/SQLite/SQLite.so
+> cpio: gcc-4.5.2/gcc/libgcc2.c: Cannot stat: No such file or directory
+> cpio: gcc-4.5.2/gcc/libgcc2.h: Cannot stat: No such file or directory
+> cpio: gcc-4.5.2/obj-i586-mageia-linux-gnu/gcc/include/stddef.h: Cannot stat: No such file or directory
+> cpio: gcc-4.5.2/obj-i586-mageia-linux-gnu/i586-mageia-linux-gnu/libgcc: Cannot stat: No such file or directory
+> cpio: glibc-2.12.1/bits/types.h: Cannot stat: No such file or directory
+> cpio: glibc-2.12.1/debug: Cannot stat: No such file or directory
+> cpio: glibc-2.12.1/debug/stack_chk_fail_local.c: Cannot stat: No such file or directory
+> cpio: glibc-2.12.1/io: Cannot stat: No such file or directory
+> cpio: glibc-2.12.1/io/fstat64.c: Cannot stat: No such file or directory
+> cpio: glibc-2.12.1/io/stat64.c: Cannot stat: No such file or directory
+> cpio: glibc-2.12.1/sysdeps/unix/sysv/linux/bits/stat.h: Cannot stat: No such file or directory
+> cpio: glibc-2.12.1/time/time.h: Cannot stat: No such file or directory
+> 9611 blocks
+> === /PASTE ===
+> 
+> of course, tests fail afterwards.
+> 
+> however, building perl-DBD-SQLite module in iurt on my machine yields no
+> problem. (note that my machine is a x86_64, whereas the build fails on
+> i586 bs node - but i don't know if it's related).
+> 
+> ==> can someone more fluent with the bs / rpm can help please?
+
+cpio errors are normal during debug info extraction. They are most
+likely unrelated to your issue.
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005497.html b/zarb-ml/mageia-dev/2011-June/005497.html new file mode 100644 index 000000000..db96d83e9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005497.html @@ -0,0 +1,156 @@ + + + + [Mageia-dev] weird bs behaviour + + + + + + + + + +

[Mageia-dev] weird bs behaviour

+ Jerome Quelin + jquelin at gmail.com +
+ Mon Jun 13 14:26:25 CEST 2011 +

+
+ +
On 11/06/13 15:25 +0300, Anssi Hannula wrote:
+> cpio errors are normal during debug info extraction. They are most
+> likely unrelated to your issue.
+
+that's the first time i encounter (or notice) them.
+however, i found the problem and fixed it.
+
+thanks,
+jérôme 
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005498.html b/zarb-ml/mageia-dev/2011-June/005498.html new file mode 100644 index 000000000..1db61607d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005498.html @@ -0,0 +1,302 @@ + + + + [Mageia-dev] perl 5.14 migration almost complete, 3 (non-cpan) modules to go - need help from their owner! + + + + + + + + + +

[Mageia-dev] perl 5.14 migration almost complete, 3 (non-cpan) modules to go - need help from their owner!

+ Jerome Quelin + jquelin at gmail.com +
+ Mon Jun 13 14:42:02 CEST 2011 +

+
+ +
hi,
+
+perl 5.14 migration is almost complete. a big thanks to sander85,
+spuhler & ahmad for their help to rebuild the binary modules! 
+
+at the time of writing, the only packages left to rebuild are the
+following:
+
+- perl-Alias
+
+this module is old (1999) and no more maintained upstream, so i added a
+conflicts: in perl to remove it.
+
+- perl-DBD-Firebird
+
+this module does not compile with perl 5.14: no success reported by any
+cpan testers. i've added a conflicts in perl to have a smooth transition
+too. it'll be updated when a new version is available upstream.
+
+- perl-MIME-Explode
+
+doesn't compile with perl 5.14, bug opened upstream (rt#66966).
+conflicts: added in perl, waiting for new version.
+
+- perl-PDA-Pilot
+
+from pilot-link package. i don't have a clue what's the problem. maybe
+it doesn't support 5.14. can her maintainer chime in?
+
+- perl-SWF
+
+from ming package. the problem may be from specifying LIBS on
+command-line, but i'm not sure. can her maintainer chime in please?
+
+- perl-SWISH-API
+
+from swish-e package. the problem may be from specifying OTPIMIZE,
+CCFLAGS, LDFLAGS and others on command-line, but i'm not sure. can her
+maintainer chime in please?
+
+
+thanks,
+jérôme 
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005499.html b/zarb-ml/mageia-dev/2011-June/005499.html new file mode 100644 index 000000000..b1a9f0c33 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005499.html @@ -0,0 +1,188 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Thomas Backlund + tmb at mageia.org +
+ Mon Jun 13 14:51:54 CEST 2011 +

+
+ +
Wolfgang Bornath skrev 13.6.2011 15:20:
+> About the cycles:
+>
+> The 9-months seem to be a compromise - but I start to ask why we need
+> such a fixed statement (which it would be, once published). We need a
+> schedule for each cycle, that's true. Without a schedule we would
+> never finish anything. But how about taking 9 months only as a "nice
+> to meet" target, leaving us the option to set a roadmap after setting
+> the specs of the next release - we could then go for a 8 or 10 months
+> roadmap, depending on the specs.
+>
+
+This is somewhat like what I had in my mind to write too, but you beat 
+me to it :)
+
+It could allow us to adapt a little for upstream releases.
+But should we then decide that the limit is +/- 1 month ?
+
+Obviously there will still be people complaining that "you waited 10 
+months... if you had extended with ~2 more weeks... "this" or "that"
+package would have been available too... and so on....
+
+
+And something not to forget (this is more related to the specs):
+
+If an estimated upstream release of kde/gnome/... seem to fit our
+schedule it _must_ be in Cauldron before version freeze so we
+actually get some test/qa on it and not try to force it in by
+"hey it's released ~x days before final mageia release so it
+  must be added" attitude that tends to pop up at every freeze.
+
+--
+Thomas
+
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005500.html b/zarb-ml/mageia-dev/2011-June/005500.html new file mode 100644 index 000000000..c33669e98 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005500.html @@ -0,0 +1,224 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Samuel Verschelde + stormi at laposte.net +
+ Mon Jun 13 14:58:54 CEST 2011 +

+
+ +
Le dimanche 12 juin 2011 22:46:33, Michael Scherer a écrit :
+> Hi,
+> 
+> so , with a little bit delay due to various things ( like everybody
+> asking stuff to us on irc on a hourly fashion ( people will I hope
+> recognize themselves )), Anne and I have reviewed the various proposals
+> made through years during the early period of the distribution, and
+> before at Mandriva. We took in account the feedback of people on forum,
+> on ml, nd those we have seen during events. We also discussed with
+> others distributions developers we know from Opensuse, Fedora, Debian,
+> Ubuntu about their release cycle, the choices they made and their
+> reasons.
+
+A restitution to us of this overview of the other distros release cycles and 
+their choices, reasons, pros and cons would have been great, but I guess it 
+would have required much more time to write it. It would have helped 
+understand why the final decision you took was to keep the current model (not 
+counting the discussion about cycle duration and LTS). I'm not saying that I 
+want "rolling release", but beginning the discussion without saying much 
+concerning what has been a big discussion some months ago (and still is in the 
+forum) feels a bit weird to me. Especially when we kept telling people "wait, 
+we will have time to discuss it after Release 1".
+
+> To simplify the discussion, the proposals are all based on the fact that
+> 2 or 3 releases could be supported at a time. We could have different
+> schemes for that ( LTS every X release ( ubuntu ), different level of
+> support ( mandriva )), but as this is a slightly different discussion,
+> let's assume 2 supported releases for now, and let's discuss later for
+> that ( ie next week, once this one is finished )
+
+I can understand the reason for separating the discussions (simplification), 
+but it's hard to give a final opinion concerning the release cycle without 
+knowing whether there will be a LTS or not, when you care about the life cycle 
+duration. The backports policy also has a great impact to the matter : if we 
+manage to make using newer versions of popular software easy without much risk 
+nor obligatory need to upgrade, extending the release cycle is easier (I could 
+go with 12 months provided we find a way to improve hardware support as part of 
+the maintenance).
+
+To take an example concerning the impact of having an LTS release or not : 
+- 6 months release cycle + 1 LTS every few releases => ok for me (ubuntu way, 
+each intermediate release is an intermediate milestone to the LTS)
+- 6 months release cycle, without a LTS => not ok for me, life cycle really 
+too short
+
+That said, as a choice has to be made, my vote goes to the compromise proposal 
+: around 9 months release cycle (more or less 1 month depending on the amount 
+of work to be done, adjustment to a given upstream release, KDE or GNOME for 
+example, and marketing calendar considerations).
+
+Best regards
+
+Samuel Verschelde
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005501.html b/zarb-ml/mageia-dev/2011-June/005501.html new file mode 100644 index 000000000..748d4dd91 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005501.html @@ -0,0 +1,245 @@ + + + + [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Mon Jun 13 15:00:51 CEST 2011 +

+
+ +
Op maandag 13 juni 2011 14:20:36 schreef Cazzaniga Sandro:
+> Le 13/06/2011 14:06, Dick Gevers a écrit :
+> > On Mon, 13 Jun 2011 09:37:40 +0200, Cazzaniga Sandro wrote about Re:
+> > 
+> > [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2:
+> >>> Quite a few packages reached the mirrors since this one, but biew has
+> >>> not.
+> >> 
+> >> So it needs a rebuild?
+> > 
+> > Anything similar to rebuild, push, boot, shove, %mkrel or opening the
+> > window to let it fly: IANAE.
+> > 
+> > Thanks in advance,
+> > =Dick Gevers=
+> 
+> Could you be more clear, please?
+
+IANAE == i am not an expert
+
+so, in other words, he's saying: "don't ask me, i know nothing"
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005502.html b/zarb-ml/mageia-dev/2011-June/005502.html new file mode 100644 index 000000000..386035ea7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005502.html @@ -0,0 +1,237 @@ + + + + [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2

+ Dick Gevers + dvgevers at xs4all.nl +
+ Mon Jun 13 14:59:19 CEST 2011 +

+
+ +
On Mon, 13 Jun 2011 14:20:36 +0200, Cazzaniga Sandro wrote about Re:
+[Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2:
+
+>>> So it needs a rebuild?
+>> 
+>> Anything similar to rebuild, push, boot, shove, %mkrel or opening the
+>> window to let it fly: IANAE.
+
+>Could you be more clear, please?
+
+Yes: I dunno what needs to be done! Sorry, if I was not.
+
+Best regards,
+=Dick Gevers=
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005503.html b/zarb-ml/mageia-dev/2011-June/005503.html new file mode 100644 index 000000000..f8f4c8b5e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005503.html @@ -0,0 +1,192 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ David Sjölin + david.sjolin at gmail.com +
+ Mon Jun 13 15:00:11 CEST 2011 +

+
+ +
On Mon, Jun 13, 2011 at 2:51 PM, Thomas Backlund <tmb at mageia.org> wrote:
+> Wolfgang Bornath skrev 13.6.2011 15:20:
+>>
+>> About the cycles:
+>>
+>> The 9-months seem to be a compromise - but I start to ask why we need
+>> such a fixed statement (which it would be, once published). We need a
+>> schedule for each cycle, that's true. Without a schedule we would
+>> never finish anything. But how about taking 9 months only as a "nice
+>> to meet" target, leaving us the option to set a roadmap after setting
+>> the specs of the next release - we could then go for a 8 or 10 months
+>> roadmap, depending on the specs.
+>>
+>
+> This is somewhat like what I had in my mind to write too, but you beat me to
+> it :)
+>
+> It could allow us to adapt a little for upstream releases.
+> But should we then decide that the limit is +/- 1 month ?
+>
+> Obviously there will still be people complaining that "you waited 10
+> months... if you had extended with ~2 more weeks... "this" or "that"
+> package would have been available too... and so on....
+>
+>
+> And something not to forget (this is more related to the specs):
+>
+> If an estimated upstream release of kde/gnome/... seem to fit our
+> schedule it _must_ be in Cauldron before version freeze so we
+> actually get some test/qa on it and not try to force it in by
+> "hey it's released ~x days before final mageia release so it
+>  must be added" attitude that tends to pop up at every freeze.
+
+This point and the one above ("if you had extended...") seems to be
+arguments for a fixed time release cycle? With a fixed release cycle
+no one would question why we didn't wait for the release of a new
+gnome/kde/<any package which someone wants>, since waiting the extra
+weeks would go against the release cycle. I'm not sure if that is
+enough of an argument against having a looser release cycle but... But
+then again, I can see the point of having the possibility to be a bit
+flexible.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005504.html b/zarb-ml/mageia-dev/2011-June/005504.html new file mode 100644 index 000000000..e52df8046 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005504.html @@ -0,0 +1,242 @@ + + + + [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2

+ James Kerr + jim at jkerr82508.free-online.co.uk +
+ Mon Jun 13 15:01:00 CEST 2011 +

+
+ +
On 13/06/11 13:06, Dick Gevers wrote:
+> On Mon, 13 Jun 2011 09:37:40 +0200, Cazzaniga Sandro wrote about Re:
+> [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2:
+>
+>>> Quite a few packages reached the mirrors since this one, but biew has
+>>> not.
+>
+>> So it needs a rebuild?
+>
+> Anything similar to rebuild, push, boot, shove, %mkrel or opening the window
+> to let it fly: IANAE.
+>
+
+In case it's relevant - the i586 package is on the mirrors. It's only 
+x86-64 that's missing.
+
+Jim
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005505.html b/zarb-ml/mageia-dev/2011-June/005505.html new file mode 100644 index 000000000..1d9783978 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005505.html @@ -0,0 +1,247 @@ + + + + [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2

+ Thomas Backlund + tmb at mageia.org +
+ Mon Jun 13 15:03:34 CEST 2011 +

+
+ +
James Kerr skrev 13.6.2011 16:01:
+> On 13/06/11 13:06, Dick Gevers wrote:
+>> On Mon, 13 Jun 2011 09:37:40 +0200, Cazzaniga Sandro wrote about Re:
+>> [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2:
+>>
+>>>> Quite a few packages reached the mirrors since this one, but biew has
+>>>> not.
+>>
+>>> So it needs a rebuild?
+>>
+>> Anything similar to rebuild, push, boot, shove, %mkrel or opening the window
+>> to let it fly: IANAE.
+>>
+>
+> In case it's relevant - the i586 package is on the mirrors. It's only
+> x86-64 that's missing.
+
+That's because spec states:
+
+ExclusiveArch:  %ix86
+
+--
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005506.html b/zarb-ml/mageia-dev/2011-June/005506.html new file mode 100644 index 000000000..061141dc5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005506.html @@ -0,0 +1,267 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Angelo Naselli + anaselli at linux.it +
+ Mon Jun 13 15:06:44 CEST 2011 +

+
+ +
lunedì 13 giugno 2011 alle 12:07, Ron ha scritto:
+> I made another post in a different thread about the way I feel the release cycle should go. 
+Sorry i can't see why... couldn't we go on that thread?
+
+Hard to follow, quite long, but maybe easy to summarize at the end of discussion.
+Oh well ennael and misc have to do the big work to get info from all
+input, but please let's try to make their life easier :) At least that is my opinion...
+
+> After more thinking I do think that I really have the right idea and here is why...
+And please do not post html messages or your ideas is hard to follow as well ;)
+
+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/20110613/687bf147/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005507.html b/zarb-ml/mageia-dev/2011-June/005507.html new file mode 100644 index 000000000..d807e1ebf --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005507.html @@ -0,0 +1,201 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Thomas Backlund + tmb at mageia.org +
+ Mon Jun 13 15:08:51 CEST 2011 +

+
+ +
David Sjölin skrev 13.6.2011 16:00:
+> On Mon, Jun 13, 2011 at 2:51 PM, Thomas Backlund<tmb at mageia.org>  wrote:
+>> Wolfgang Bornath skrev 13.6.2011 15:20:
+>>>
+>>> About the cycles:
+>>>
+>>> The 9-months seem to be a compromise - but I start to ask why we need
+>>> such a fixed statement (which it would be, once published). We need a
+>>> schedule for each cycle, that's true. Without a schedule we would
+>>> never finish anything. But how about taking 9 months only as a "nice
+>>> to meet" target, leaving us the option to set a roadmap after setting
+>>> the specs of the next release - we could then go for a 8 or 10 months
+>>> roadmap, depending on the specs.
+>>>
+>>
+>> This is somewhat like what I had in my mind to write too, but you beat me to
+>> it :)
+>>
+>> It could allow us to adapt a little for upstream releases.
+>> But should we then decide that the limit is +/- 1 month ?
+>>
+>> Obviously there will still be people complaining that "you waited 10
+>> months... if you had extended with ~2 more weeks... "this" or "that"
+>> package would have been available too... and so on....
+>>
+>>
+>> And something not to forget (this is more related to the specs):
+>>
+>> If an estimated upstream release of kde/gnome/... seem to fit our
+>> schedule it _must_ be in Cauldron before version freeze so we
+>> actually get some test/qa on it and not try to force it in by
+>> "hey it's released ~x days before final mageia release so it
+>>   must be added" attitude that tends to pop up at every freeze.
+>
+> This point and the one above ("if you had extended...") seems to be
+> arguments for a fixed time release cycle? With a fixed release cycle
+> no one would question why we didn't wait for the release of a new
+> gnome/kde/<any package which someone wants>, since waiting the extra
+> weeks would go against the release cycle. I'm not sure if that is
+> enough of an argument against having a looser release cycle but... But
+> then again, I can see the point of having the possibility to be a bit
+> flexible.
+
+Well, it was intended to point out the problem with the "flexible" 
+approach, and a possible "fix" by deciding some limits to the flexibility.
+
+--
+Thomas
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005508.html b/zarb-ml/mageia-dev/2011-June/005508.html new file mode 100644 index 000000000..e93961a28 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005508.html @@ -0,0 +1,206 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ magnus + magnus.mud at googlemail.com +
+ Mon Jun 13 15:08:56 CEST 2011 +

+
+ +
2011/6/13 Thomas Backlund <tmb at mageia.org>
+
+> Wolfgang Bornath skrev 13.6.2011 15:20:
+>
+>> About the cycles:
+>>
+>>
+>> The 9-months seem to be a compromise - but I start to ask why we need
+>> such a fixed statement (which it would be, once published). We need a
+>> schedule for each cycle, that's true. Without a schedule we would
+>> never finish anything. But how about taking 9 months only as a "nice
+>> to meet" target, leaving us the option to set a roadmap after setting
+>> the specs of the next release - we could then go for a 8 or 10 months
+>> roadmap, depending on the specs.
+>>
+>>
+> This is somewhat like what I had in my mind to write too, but you beat me
+> to it :)
+>
+> It could allow us to adapt a little for upstream releases.
+> But should we then decide that the limit is +/- 1 month ?
+>
+> Obviously there will still be people complaining that "you waited 10
+> months... if you had extended with ~2 more weeks... "this" or "that"
+> package would have been available too... and so on....
+>
+>
+> And something not to forget (this is more related to the specs):
+>
+> If an estimated upstream release of kde/gnome/... seem to fit our
+> schedule it _must_ be in Cauldron before version freeze so we
+> actually get some test/qa on it and not try to force it in by
+> "hey it's released ~x days before final mageia release so it
+>  must be added" attitude that tends to pop up at every freeze.
+>
+> --
+> Thomas
+>
+>
+>
+> Let the 9 months as maximum, as a general target.
+
+Make the specs and then the roadmap with a fixed release date and a fixed
+enough time for freeze and testing.
+
+If an upstream release brings conflits, that's live.
+Main focus should be a stable release for simple users not a pot of the
+latest apps
+
+Magnus
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110613/30ac67d2/attachment-0001.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005509.html b/zarb-ml/mageia-dev/2011-June/005509.html new file mode 100644 index 000000000..b1f90c17d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005509.html @@ -0,0 +1,157 @@ + + + + [Mageia-dev] "Job offer" : mentoring program coordinator + + + + + + + + + +

[Mageia-dev] "Job offer" : mentoring program coordinator

+ andre999 + andr55 at laposte.net +
+ Mon Jun 13 15:07:39 CEST 2011 +

+
+ +
Michael Scherer a écrit :
+>
+> Le dimanche 12 juin 2011 à 18:52 -0400, andre999 a écrit :
+>
+>> But also mentoring can apply to other things than packaging.  So maybe we should give a broader
+>> scope to the mentoring coordinator job ?
+>> Including bugteam, QA, as well as packaging.
+>> That would make it more useful, as well as more interesting.
+>> (I would be very interested in contributing to something like that.)
+>
+> Given there is no mentoring program for others teams, I do not think
+> adding a coordinator is gonna coordinate much.
+
+I guess I wasn't very clear :)
+The idea was to (maybe) expand the role of the same mentoring coordinator to include other 
+mentoring (or training) programs which might be started/made more formal.
+Because it would be basically the same function, maintaining a wiki database (different for each 
+program), documenting and promoting, etc.
+It shouldn't be a very time-consuming function, albeit very important.
+Just a random thought ...
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005510.html b/zarb-ml/mageia-dev/2011-June/005510.html new file mode 100644 index 000000000..4572ae6df --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005510.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] [RPM] cauldron core/release libgdata-0.7.1-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release libgdata-0.7.1-1.mga2

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Mon Jun 13 15:10:04 CEST 2011 +

+
+ +
On Wed, 8 Jun 2011, Balcaen John wrote:
+
+> Le mercredi 8 juin 2011 16:52:16, Mageia Team a écrit :
+>> Name        : libgdata                     Relocations: (not relocatable)
+>> Version     : 0.7.1                             Vendor: Mageia.Org
+> [...]
+>> dmorgan <dmorgan> 0.7.1-1.mga2:
+>> + Revision: 102030
+>> - New version 0.7.1
+> There's a file conflict :
+> Installation failed:
+>        file /usr/lib64/girepository-1.0/GData-0.0.typelib from install of
+> lib64gdata10-0.7.1-1.mga2.x86_64 conflicts with file from package
+> lib64gdata7-0.6.6-1.mga1.x86_64
+>
+> Installation failed:    file /usr/lib64/girepository-1.0/GData-0.0.typelib
+> from install of lib64gdata10-0.7.1-1.mga2.x86_64 conflicts with file from
+> package lib64gdata7-0.6.6-1.mga1.x86_64
+>
+> Maybe this file should not be in the versionned library package ?
+
+Indeed, but I see no way to really fix the upgrade except by providing a 
+fixed lib(64)gdata7 in mga2.
+
+We have poppler-gir0.16 for girepository-1.0/Poppler-0.16.typelib .
+(In ubuntu they call the extra package gir1.0-gdata-0.0 .)
+
+So we should probably add lib(64)gdata-gir0.0 . It must be libified to 
+allow parallel installation of libgdata10 and lib64gdata10. The new 
+package will conflict with lib(64)gdata7 so all applications that use it 
+(totem and evolution) must be rebuilt.
+
+
+     Christiaan
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005511.html b/zarb-ml/mageia-dev/2011-June/005511.html new file mode 100644 index 000000000..e6e964e33 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005511.html @@ -0,0 +1,153 @@ + + + + [Mageia-dev] "Job offer" : mentoring program coordinator + + + + + + + + + +

[Mageia-dev] "Job offer" : mentoring program coordinator

+ Samuel Verschelde + stormi at laposte.net +
+ Mon Jun 13 15:12:14 CEST 2011 +

+
+ +
Le lundi 13 juin 2011 11:20:30, Michael Scherer a écrit :
+> Le dimanche 12 juin 2011 à 18:52 -0400, andre999 a écrit :
+> > But also mentoring can apply to other things than packaging.  So maybe we
+> > should give a broader scope to the mentoring coordinator job ?
+> > Including bugteam, QA, as well as packaging.
+> > That would make it more useful, as well as more interesting.
+> > (I would be very interested in contributing to something like that.)
+> 
+> Given there is no mentoring program for others teams, I do not think
+> adding a coordinator is gonna coordinate much.
+
+I would say it with other words : there's no need for a broader scope right 
+now, and the "job" is explicitly limited to packagers mentoring coordination, 
+but if this is successful, it can maybe give ideas to other teams in the 
+future. Then we will have to ask ourselves if an inter-teams mentoring 
+coordinator is needed or not, but it's too soon now.
+
+Best regards
+
+Samuel Verschelde
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005512.html b/zarb-ml/mageia-dev/2011-June/005512.html new file mode 100644 index 000000000..f2af454a2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005512.html @@ -0,0 +1,222 @@ + + + + [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2

+ Dick Gevers + dvgevers at xs4all.nl +
+ Mon Jun 13 15:13:04 CEST 2011 +

+
+ +
>so, in other words, he's saying: "don't ask me, i know nothing"
+
+Nou dank je wel
+
+:(
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005513.html b/zarb-ml/mageia-dev/2011-June/005513.html new file mode 100644 index 000000000..a0dbb9e6b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005513.html @@ -0,0 +1,266 @@ + + + + [Mageia-dev] "Job offer" : mentoring program coordinator + + + + + + + + + +

[Mageia-dev] "Job offer" : mentoring program coordinator

+ Samuel Verschelde + stormi at laposte.net +
+ Mon Jun 13 15:14:35 CEST 2011 +

+
+ +
Le lundi 13 juin 2011 00:52:18, andre999 a écrit :
+> Samuel Verschelde a écrit :
+> > Hello to everyone,
+> > 
+> > I'm sure there's someone among you who wants to help Mageia but hasn't
+> > found yet the good way to do it. Today is your lucky day, because
+> > there's a job that's available and can be really useful and interesting:
+> > coordinating the packagers mentoring program.
+> > 
+> > You know that one key point of success for Mageia is in the ability to
+> > welcome new packagers. The better we will be at it, the better the
+> > distro will be. The packagers mentoring program has been created for
+> > that reason and several packagers have been or are being mentored. But
+> > we have some difficulty knowing who is being mentored by who and who
+> > hasn't found a mentor. And we need also to find more mentors and more
+> > apprentices.
+> > 
+> > During a packagers weekly meeting, misc invited us to read the following
+> > article about mentoring programs in open-source projects:
+> > http://blogs.gnome.org/bolsh/2011/05/31/effective-mentoring-programs/
+> 
+> Very interesting, especially many of the comments.
+> 
+> > I invite those who haven't read it yet, to read it. I'll quote one of the
+> > mentoring best practices that were given: "In bigger projects, keeping
+> > track of who is a mentor, and who is mentoring who, and inviting new
+> > mentors, and ensuring that no-one falls through the cracks when a mentor
+> > gets too busy, is a job of itself."
+> > 
+> > I'm looking for someone who could fill that "job".
+> > 
+> > Description of the job:
+> > 
+> > - keep track of:
+> > -- who's being mentored by who, how well it's going
+> > -- who needs a mentor and hasn't found one yet (this is one of the most
+> > important parts: no volunteer must be forgotten, volunteers are too
+> > precious !)
+> > -- who can mentor more apprentices (and sometimes convince packagers to
+> > become mentors or accept one more apprentice)
+> > 
+> > - be available for questions from apprentices or mentors, by mail, and if
+> > possible, to be present on the IRC channel #mageia-mentoring on freenode
+> > 
+> > - help mentors with gathering "junior tasks" (bugzilla is a never empty
+> > reserve that can be used for that. Maybe ask the bug triage team to help
+> > identify such tasks. Maybe a "junior task" keyword in bugzilla would do
+> > the trick)
+> > -- small bugs to fix
+> > -- new small packages to import in the distribution
+> > -- backports
+> > 
+> > - promote mentoring (empower users into contributers. Working with the
+> > marketing team would be great I think):
+> > -- make the mentoring program known (MLs, forums, web, etc.)
+> > -- look for new apprentices
+> > -- look for new mentors
+> > 
+> > Some useful skills:
+> > - be autonomous (ie no need to check that you're doing the work)
+> > - good written english (communication is very important in this job)
+> > - knowledge about packaging is a plus but not mandatory (the key aspects
+> > can be taught to you)
+> > - being or having been a mentor, or having been mentored would be a plus,
+> > but not mandatory
+> > 
+> > More information about the job:
+> > - does not require a big amount of work, but real committment to the task
+> > and regularity
+> > - remember that you have a coordination role, not an authoritative role.
+> > The difference in that is that you're not here to give orders but to
+> > facilitate the mentoring program.
+> > - you don't have to be alone to do this job if it's too much for one
+> > person: you can find other helpful people wanting to help you if needed
+> > and rely on the other teams (but finding them *is* part of your job ;)
+> > ).
+> > -  this "job offer" concerns everything that revolves around the
+> > mentoring of new packagers, but if it's successful maybe other teams can
+> > follow the same approach (i18n, QA, etc... ).
+> > -  depending on your level of confidence, experience and will, you could
+> > be helped in your work. Maybe someone from the council can supervise and
+> > help you at least at the beginning; or, if no one steps up, I can help
+> > you bootstrap and organize your new "job".
+> > 
+> > So, who's in?
+> > 
+> > Samuel Verschelde
+> 
+> That is an excellent idea, a mentoring program coordinator.
+> I've had some thoughts along those lines for some time.
+> I'd be glad to contribute, especially via email and editing the wiki, where
+> I could almost always respond the same day.
+> But my time zone availability (generally after 22h utc) puts me at a
+> disadvantage for irc communications and meetings.
+> (But as part of a coordinating team, that should work well.)
+> 
+> Maintaining the mentor/apprentice database, as Kharec suggested, is to me a
+> key part of the role. Information such as mentors available, and their
+> strengths/focus, usual time zones available, communication modes
+> preferred, languages spoken, and current apprentices, Would-be apprentices
+> should have similar information listed.
+> Not much different from the information currently in variously wiki pages,
+> but maintained by the coordinator in one location.
+> 
+> <aside>
+> One thing that occurred to me is that there is no imperative that mentoring
+> process happens only in English.  If an apprentice is more comfortable in
+> another language, and they find a mentor speaking that language, why not ?
+>  Sure, it is useful to have basic English knowledge, but it is evident
+> that many (if not most) contributors speak English as a second language.
+> </aside>
+> 
+> Experience packaging, either as a mentor or apprentice is highly
+> recommended in my view, at least for the key person.  (My experience is as
+> a apprentice with Shikamaru -- an excellent mentor, btw -- and my time
+> zone availability is probably why I haven't officially completed the
+> process.) Also some programming experience could be useful.  (I imagine
+> that most candidates would have that.)
+> 
+> But also mentoring can apply to other things than packaging.  So maybe we
+> should give a broader scope to the mentoring coordinator job ?
+> Including bugteam, QA, as well as packaging.
+> That would make it more useful, as well as more interesting.
+> (I would be very interested in contributing to something like that.)
+> 
+> So what does everyone think ?
+
+Thanks for the input, but there's one point that's still unclear to me : do 
+you candidate for the job ? :p
+
+(the timezone question can be a problem, but not necessarily a blocking one)
+
+Samuel
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005514.html b/zarb-ml/mageia-dev/2011-June/005514.html new file mode 100644 index 000000000..33f4108f5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005514.html @@ -0,0 +1,173 @@ + + + + [Mageia-dev] "Job offer" : mentoring program coordinator + + + + + + + + + +

[Mageia-dev] "Job offer" : mentoring program coordinator

+ Samuel Verschelde + stormi at laposte.net +
+ Mon Jun 13 15:17:44 CEST 2011 +

+
+ +
Le dimanche 12 juin 2011 19:49:31, magnus a écrit :
+> Hello,
+> I'm not offer my candidacy, I'm only a simple user.
+> But I offer my help as secrtary of the secratary of ...... the coordinator
+> 
+> As Mageia and I have the same birthday I'm following the upgroth since the
+> beginning.
+> Also with a little help during qa for the final.
+> 
+> As I saw some requests for mentoring on the ml, I think it is important to
+> show a quick response.
+> So mentoring team can do this, ask for the skill or say look to foo1, foo2
+> or foo3 on the bug-list
+> during we are looking for mentor.
+> (perhaps the packagers can classify the complexity of new-package-request
+> and "simple" bugs)
+> 
+> Also very important ist the actuality of the wiki.
+> So we must have a look on the bug-list, ml and irc not to loose any request
+> for mentoring.
+> On the other side we must have/build a very good communicatio to the
+> packagers to avoid double work on packages
+> and to help for equal distribution of the mentoring work.
+> 
+> Although not filling the wanted skills (no packager, no being a mentor, not
+> good english knowledge)
+> I'm ready to help.
+> 
+> I think some more eyes are always good :-)
+> 
+> So if I can help call me
+> 
+> Magnus
+> 
+> PS: In my job as it-auditor documentation, communication and learning new
+> thinks are the normal things
+> 
+
+Thanks for your help proposal. I think the future coordinator (when choosen) 
+can take note of it and now that you can help him/her. As I said with different 
+words, not using a volunteer's help would be a crime !
+
+Samuel
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005515.html b/zarb-ml/mageia-dev/2011-June/005515.html new file mode 100644 index 000000000..18b3b82e0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005515.html @@ -0,0 +1,230 @@ + + + + [Mageia-dev] "Job offer" : mentoring program coordinator + + + + + + + + + +

[Mageia-dev] "Job offer" : mentoring program coordinator

+ Samuel Verschelde + stormi at laposte.net +
+ Mon Jun 13 15:19:26 CEST 2011 +

+
+ +
Le dimanche 12 juin 2011 18:55:58, Cazzaniga Sandro a écrit :
+> Le 12/06/2011 15:27, Samuel Verschelde a écrit :
+> > Hello to everyone,
+> > 
+> > I'm sure there's someone among you who wants to help Mageia but hasn't
+> > found yet the good way to do it. Today is your lucky day, because
+> > there's a job that's available and can be really useful and interesting:
+> > coordinating the packagers mentoring program.
+> > 
+> > You know that one key point of success for Mageia is in the ability to
+> > welcome new packagers. The better we will be at it, the better the
+> > distro will be. The packagers mentoring program has been created for
+> > that reason and several packagers have been or are being mentored. But
+> > we have some difficulty knowing who is being mentored by who and who
+> > hasn't found a mentor. And we need also to find more mentors and more
+> > apprentices.
+> > 
+> > During a packagers weekly meeting, misc invited us to read the following
+> > article about mentoring programs in open-source projects:
+> > http://blogs.gnome.org/bolsh/2011/05/31/effective-mentoring-programs/
+> > 
+> > I invite those who haven't read it yet, to read it. I'll quote one of the
+> > mentoring best practices that were given: "In bigger projects, keeping
+> > track of who is a mentor, and who is mentoring who, and inviting new
+> > mentors, and ensuring that no-one falls through the cracks when a mentor
+> > gets too busy, is a job of itself."
+> > 
+> > I'm looking for someone who could fill that "job".
+> > 
+> > Description of the job:
+> > 
+> > - keep track of:
+> > -- who's being mentored by who, how well it's going
+> > -- who needs a mentor and hasn't found one yet (this is one of the most
+> > important parts: no volunteer must be forgotten, volunteers are too
+> > precious !)
+> > -- who can mentor more apprentices (and sometimes convince packagers to
+> > become mentors or accept one more apprentice)
+> > 
+> > - be available for questions from apprentices or mentors, by mail, and if
+> > possible, to be present on the IRC channel #mageia-mentoring on freenode
+> > 
+> > - help mentors with gathering "junior tasks" (bugzilla is a never empty
+> > reserve that can be used for that. Maybe ask the bug triage team to help
+> > identify such tasks. Maybe a "junior task" keyword in bugzilla would do
+> > the trick)
+> > -- small bugs to fix
+> > -- new small packages to import in the distribution
+> > -- backports
+> > 
+> > - promote mentoring (empower users into contributers. Working with the
+> > marketing team would be great I think):
+> > -- make the mentoring program known (MLs, forums, web, etc.)
+> > -- look for new apprentices
+> > -- look for new mentors
+> > 
+> > Some useful skills:
+> > - be autonomous (ie no need to check that you're doing the work)
+> > - good written english (communication is very important in this job)
+> > - knowledge about packaging is a plus but not mandatory (the key aspects
+> > can be taught to you)
+> > - being or having been a mentor, or having been mentored would be a plus,
+> > but not mandatory
+> > 
+> > More information about the job:
+> > - does not require a big amount of work, but real committment to the task
+> > and regularity
+> > - remember that you have a coordination role, not an authoritative role.
+> > The difference in that is that you're not here to give orders but to
+> > facilitate the mentoring program.
+> > - you don't have to be alone to do this job if it's too much for one
+> > person: you can find other helpful people wanting to help you if needed
+> > and rely on the other teams (but finding them *is* part of your job ;)
+> > ).
+> > -  this "job offer" concerns everything that revolves around the
+> > mentoring of new packagers, but if it's successful maybe other teams can
+> > follow the same approach (i18n, QA, etc... ).
+> > -  depending on your level of confidence, experience and will, you could
+> > be helped in your work. Maybe someone from the council can supervise and
+> > help you at least at the beginning; or, if no one steps up, I can help
+> > you bootstrap and organize your new "job".
+> > 
+> > So, who's in?
+> > 
+> > Samuel Verschelde
+> 
+> I offer my candidacy. I was mentored by shikamaru and i'm a mandriva
+> packager since 2009 and a mageia packager since the start.
+> My english level is pretty good and i'm pretty sociable.
+> 
+
+Hi,
+
+As explained on IRC yesterday, your candidacy is interesting, but you have 
+already so many other engagements that I would prefer someone with more 
+availability :) So keep on the good work where you're already committed :)
+
+Best regards
+
+Samuel Verschelde
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005516.html b/zarb-ml/mageia-dev/2011-June/005516.html new file mode 100644 index 000000000..d80cbb04f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005516.html @@ -0,0 +1,143 @@ + + + + [Mageia-dev] "Job offer" : mentoring program coordinator + + + + + + + + + +

[Mageia-dev] "Job offer" : mentoring program coordinator

+ magnus + magnus.mud at googlemail.com +
+ Mon Jun 13 15:19:53 CEST 2011 +

+
+ +
>
+>
+>  As I said with different
+> words, not using a volunteer's help would be a crime !
+>
+> Samuel
+>
+
+:-))
+I ready to start
+
+Magnus
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110613/f23c0327/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005517.html b/zarb-ml/mageia-dev/2011-June/005517.html new file mode 100644 index 000000000..fc048db0c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005517.html @@ -0,0 +1,234 @@ + + + + [Mageia-dev] Question about backports: calibre (bug 1659) + + + + + + + + + +

[Mageia-dev] Question about backports: calibre (bug 1659)

+ Angelo Naselli + anaselli at linux.it +
+ Mon Jun 13 15:23:52 CEST 2011 +

+
+ +
>Two people asserted that a newer calibre package should go into backports, not updates.
+
+I said also that there could be exceptions...
+
+
+> Therefore, I strongly believe that all calibre updates be packaged into updates, not backports, especially as there isn't any Mageia 2.0 as of yet. Once Mageia 2.0 is released, whatever newer calibre releases will be available might go into backports instead -- if at all. (Although I'd say that it should still be updated to updates for the whole supported time of 1.0.)
+Backports is meant from cauldron
+
+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/20110613/f7a3e7a1/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005518.html b/zarb-ml/mageia-dev/2011-June/005518.html new file mode 100644 index 000000000..a50b014db --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005518.html @@ -0,0 +1,193 @@ + + + + [Mageia-dev] update of compiz + + + + + + + + + +

[Mageia-dev] update of compiz

+ Julien + mjulien.m at gmail.com +
+ Mon Jun 13 14:49:57 CEST 2011 +

+
+ +
Le Sun, 12 Jun 2011 23:47:01 +0100,
+Colin Guthrie <mageia at colin.guthr.ie> a écrit :
+
+> 'Twas brillig, and Dexter Morgan at 12/06/11 23:16 did gyre and
+> gimble:
+> > On Sun, Jun 12, 2011 at 9:39 PM, julien <mjulien.m at gmail.com> wrote:
+> >> Hi,
+> >>
+> >> I would like to update compiz to v0.8.8.
+> >>
+> >> any objection ?
+> >>
+> >> regards
+> >> julien
+> >>
+> > 
+> > Hello,
+> > 
+> > fedora uses compiz 0.9.4 do you think we can directly go to this
+> > version ?
+> > 
+> > Btw, glad to see someone taking compiz maintainership, congrats.
+> 
+> It would be nice to go to the latest compiz I did update it locally a
+> while back to the 0.9 series but it crashed on my system before I got
+> a chance to really look into it.
+> 
+> I've still got the packages here, so I could commit them and/or
+> publish patches if you could use them as a base?
+> 
+> Col
+> 
+
+Hi,
+
+(before continuing, keep in mind that I'm an apprentice since one week,
+so please forget me if I seem too presumptuous) 
+
+0.9.x series is an unstable series with major modification
+between release and some tools (such as the decorator emerald) are not
+yet available.
+
+So I would prefer doing it in 2 steps :
+ - update current compiz to 0.8.8 (and if possible, backport it to
+   mageia 1) and importing emerald
+ - when 0.9.x series will be more stable, upgrade to 0.9
+
+WDYT ?
+
+regards
+julien
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005519.html b/zarb-ml/mageia-dev/2011-June/005519.html new file mode 100644 index 000000000..19b014ec5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005519.html @@ -0,0 +1,219 @@ + + + + [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Mon Jun 13 15:39:55 CEST 2011 +

+
+ +
Op maandag 13 juni 2011 15:13:04 schreef Dick Gevers:
+> >so, in other words, he's saying: "don't ask me, i know nothing"
+> 
+> Nou dank je wel
+> 
+> :(
+
+it was kind of a semi-joke (a la monty python) :-S
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005520.html b/zarb-ml/mageia-dev/2011-June/005520.html new file mode 100644 index 000000000..b08cc314f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005520.html @@ -0,0 +1,166 @@ + + + + [Mageia-dev] update of compiz + + + + + + + + + +

[Mageia-dev] update of compiz

+ Balcaen John + mikala at mageia.org +
+ Mon Jun 13 15:39:11 CEST 2011 +

+
+ +
Le lundi 13 juin 2011 09:49:57, Julien a écrit :
+[...]
+> 
+> (before continuing, keep in mind that I'm an apprentice since one week,
+> so please forget me if I seem too presumptuous) 
+> 
+> 0.9.x series is an unstable series with major modification
+> between release and some tools (such as the decorator emerald) are not
+> yet available.
+> 
+> So I would prefer doing it in 2 steps :
+>  - update current compiz to 0.8.8 (and if possible, backport it to
+>    mageia 1) and importing emerald
+>  - when 0.9.x series will be more stable, upgrade to 0.9
+> 
+> WDYT ?
+It's a good decision as expected from the compiz maintainer :)
+
+Do we have any ETA regarding the 0.9 series ?
+
+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-June/005521.html b/zarb-ml/mageia-dev/2011-June/005521.html new file mode 100644 index 000000000..f41e14489 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005521.html @@ -0,0 +1,226 @@ + + + + [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2

+ Dick Gevers + dvgevers at xs4all.nl +
+ Mon Jun 13 15:47:09 CEST 2011 +

+
+ +
On Mon, 13 Jun 2011 15:39:55 +0200, Maarten Vanraes wrote about Re:
+[Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2:
+
+>Op maandag 13 juni 2011 15:13:04 schreef Dick Gevers:
+>> >so, in other words, he's saying: "don't ask me, i know nothing"
+>> 
+>> Nou dank je wel
+>> 
+>> :(
+>
+>it was kind of a semi-joke (a la monty python) :-S
+
+Then you should have said: "you're welcome".
+
+>:->
+
+(En dat wist ik wel!)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005522.html b/zarb-ml/mageia-dev/2011-June/005522.html new file mode 100644 index 000000000..2f12becdc --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005522.html @@ -0,0 +1,106 @@ + + + + [Mageia-dev] [RPM] cauldron core/release libgdata-0.7.1-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release libgdata-0.7.1-1.mga2

+ Anssi Hannula + anssi.hannula at iki.fi +
+ Mon Jun 13 15:58:21 CEST 2011 +

+
+ +
On 13.06.2011 16:10, Christiaan Welvaart wrote:
+> On Wed, 8 Jun 2011, Balcaen John wrote:
+> 
+>> Le mercredi 8 juin 2011 16:52:16, Mageia Team a écrit :
+>>> Name        : libgdata                     Relocations: (not
+>>> relocatable)
+>>> Version     : 0.7.1                             Vendor: Mageia.Org
+>> [...]
+>>> dmorgan <dmorgan> 0.7.1-1.mga2:
+>>> + Revision: 102030
+>>> - New version 0.7.1
+>> There's a file conflict :
+>> Installation failed:
+>>        file /usr/lib64/girepository-1.0/GData-0.0.typelib from install of
+>> lib64gdata10-0.7.1-1.mga2.x86_64 conflicts with file from package
+>> lib64gdata7-0.6.6-1.mga1.x86_64
+>>
+>> Installation failed:    file
+>> /usr/lib64/girepository-1.0/GData-0.0.typelib
+>> from install of lib64gdata10-0.7.1-1.mga2.x86_64 conflicts with file from
+>> package lib64gdata7-0.6.6-1.mga1.x86_64
+>>
+>> Maybe this file should not be in the versionned library package ?
+> 
+> Indeed, but I see no way to really fix the upgrade except by providing a
+> fixed lib(64)gdata7 in mga2.
+> 
+> We have poppler-gir0.16 for girepository-1.0/Poppler-0.16.typelib .
+> (In ubuntu they call the extra package gir1.0-gdata-0.0 .)
+> 
+> So we should probably add lib(64)gdata-gir0.0 . It must be libified to
+> allow parallel installation of libgdata10 and lib64gdata10. The new
+> package will conflict with lib(64)gdata7 so all applications that use it
+> (totem and evolution) must be rebuilt.
+
+BTW, I like the ubuntu(/debian?) naming convention here. But I'm not
+going to work on it, so feel free to name it as you like.
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005523.html b/zarb-ml/mageia-dev/2011-June/005523.html new file mode 100644 index 000000000..d83b8c0bf --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005523.html @@ -0,0 +1,113 @@ + + + + [Mageia-dev] [RPM] cauldron core/release libgdata-0.7.1-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release libgdata-0.7.1-1.mga2

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Mon Jun 13 16:06:29 CEST 2011 +

+
+ +
On Mon, 13 Jun 2011, Anssi Hannula wrote:
+
+> On 13.06.2011 16:10, Christiaan Welvaart wrote:
+>> On Wed, 8 Jun 2011, Balcaen John wrote:
+>>
+>>> Le mercredi 8 juin 2011 16:52:16, Mageia Team a écrit :
+>>>> Name        : libgdata                     Relocations: (not
+>>>> relocatable)
+>>>> Version     : 0.7.1                             Vendor: Mageia.Org
+>>> [...]
+>>>> dmorgan <dmorgan> 0.7.1-1.mga2:
+>>>> + Revision: 102030
+>>>> - New version 0.7.1
+>>> There's a file conflict :
+>>> Installation failed:
+>>>        file /usr/lib64/girepository-1.0/GData-0.0.typelib from install of
+>>> lib64gdata10-0.7.1-1.mga2.x86_64 conflicts with file from package
+>>> lib64gdata7-0.6.6-1.mga1.x86_64
+>>>
+>>> Installation failed:    file
+>>> /usr/lib64/girepository-1.0/GData-0.0.typelib
+>>> from install of lib64gdata10-0.7.1-1.mga2.x86_64 conflicts with file from
+>>> package lib64gdata7-0.6.6-1.mga1.x86_64
+>>>
+>>> Maybe this file should not be in the versionned library package ?
+>>
+>> Indeed, but I see no way to really fix the upgrade except by providing a
+>> fixed lib(64)gdata7 in mga2.
+>>
+>> We have poppler-gir0.16 for girepository-1.0/Poppler-0.16.typelib .
+>> (In ubuntu they call the extra package gir1.0-gdata-0.0 .)
+>>
+>> So we should probably add lib(64)gdata-gir0.0 . It must be libified to
+>> allow parallel installation of libgdata10 and lib64gdata10. The new
+>> package will conflict with lib(64)gdata7 so all applications that use it
+>> (totem and evolution) must be rebuilt.
+>
+> BTW, I like the ubuntu(/debian?) naming convention here. But I'm not
+> going to work on it, so feel free to name it as you like.
+
+It looks interesting, but I don't know anything about gobject 
+introspection so can't say if it makes more sense than what I proposed. 
+Anyway that naming is not going to work with biarch and I'm not going to 
+move all those files to %_datadir, that may not even work.
+
+
+     Christiaan
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005524.html b/zarb-ml/mageia-dev/2011-June/005524.html new file mode 100644 index 000000000..bbdaf2f99 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005524.html @@ -0,0 +1,233 @@ + + + + [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2

+ Dick Gevers + dvgevers at xs4all.nl +
+ Mon Jun 13 16:16:15 CEST 2011 +

+
+ +
On Mon, 13 Jun 2011 16:03:34 +0300, Thomas Backlund wrote about Re:
+[Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2:
+
+>James Kerr skrev 13.6.2011 16:01:
+>> On 13/06/11 13:06, Dick Gevers wrote:
+>>> On Mon, 13 Jun 2011 09:37:40 +0200, Cazzaniga Sandro wrote about Re:
+>>> [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2:
+>>>
+>>>>> Quite a few packages reached the mirrors since this one, but biew has
+>>>>> not.
+>>>
+>>>> So it needs a rebuild?
+>>>
+>>> Anything similar to rebuild, push, boot, shove, %mkrel or opening the
+>>> window to let it fly: IANAE.
+>>>
+>>
+>> In case it's relevant - the i586 package is on the mirrors. It's only
+>> x86-64 that's missing.
+>
+>That's because spec states:
+>
+>ExclusiveArch:  %ix86
+
+Oh. Shucks.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005525.html b/zarb-ml/mageia-dev/2011-June/005525.html new file mode 100644 index 000000000..506f35dc4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005525.html @@ -0,0 +1,207 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Barry Jackson + zen25000 at zen.co.uk +
+ Mon Jun 13 16:31:23 CEST 2011 +

+
+ +
On 13/06/11 13:24, Anssi Hannula wrote:
+> On 12.06.2011 02:37, Barry Jackson wrote:
+>> On 11/06/11 18:03, Anssi Hannula wrote:
+>>>
+>>> - Best to add a comment in the %post script to remind that any new files
+>>>     need to have a %ghost entry created.
+>>>     (btw: an alternative idea is to create a post-script and the filelist
+>>>      at the same time in a single for loop in %build/%install, so that
+>>>      the lists can never get out of sync as they are created from a single
+>>>      list; however, your current solution is adequate as well)
+>>
+>> Note added - keep it simple.
+>>
+>
+> You added the note in the %files section, not in %post. The issue only
+> happens if someone updates %post but not %files, so it doesn't make
+> sense to put the reminder in %files :)
+>
+
+OK moved
+
+>>> - You don't check for failures. If the mktemp call fails, you extract
+>>>     the tarball into /root etc.etc.. You need to check for failures on
+>>>     the mktemp/mkdir/cd commands (mktemp failure can be detected by
+>>>     checking if $newtmp string is empty), or alternatively run "set -e"
+>>>     to make the shell exit on failures (this leaves the tmpdir polluted,
+>>>     but it doesn't matter as much as it is an uncommon failure case and
+>>>     /tmp is cleaned periodically anyway).
+>>
+>> Added some checks - with clean-up of previously created dirs etc on fail.
+>
+>> mkdir %{mytmp}
+>> [[ -d %{mytmp} ]] || exit 1
+>> cd %{mytmp}
+>
+> cd is not guaranteed to work even if %mytmp exists. Add "|| exit 1".
+>
+
+OK - done.
+
+>> cd ${tmpextdir}
+>> tar jxf %{mytmp}/skype-%{version}.tar.bz2
+>
+> Same here...
+>
+> Well, actually these two aren't that serious, since they can't be
+> exploited by non-root anyway. I'm somewhat ok with them, as long as your
+> mentor is as well and no one else objects.
+>
+
+I need a mentor ;)
+
+> Note that your "if ! [[ -d %{tmpdir} ]]; then" check is not 100%
+> necessary, as %tmpdir not existing is unlikely and causes no side effects.
+>
+
+I added that as the dir is created by tar, so if the tarball had the 
+wrong content the dir may not be created with the correct name.
+Unlikely as you say.
+
+> Other nits:
+> - Use better variable names- %mytmp, $tmpextdir, %tmpdir are confusing.
+
+Changed to tmp_download_dir, tmp_extract_dir and tmp_skype_dir
+
+> - The description starts with an empty line. Remove it.
+
+Gone
+
+>
+
+I have started writing a script to generate the .txt files but can't 
+decide whether it should go as far as downloading the source from Skype 
+or simply be run on an extracted skype-<version> folder.
+A first draft of this is attached.
+I assume this would ultimately be added as a SOURCE file with notes in 
+the package.
+
+Barry
+-------------- next part --------------
+An embedded and charset-unspecified text was scrubbed...
+Name: get-skype.spec
+URL: </pipermail/mageia-dev/attachments/20110613/2c715ab6/attachment.ksh>
+-------------- next part --------------
+An embedded and charset-unspecified text was scrubbed...
+Name: skype-txt-gen
+URL: </pipermail/mageia-dev/attachments/20110613/2c715ab6/attachment-0001.ksh>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005526.html b/zarb-ml/mageia-dev/2011-June/005526.html new file mode 100644 index 000000000..624cfdb1d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005526.html @@ -0,0 +1,157 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Anssi Hannula + anssi.hannula at iki.fi +
+ Mon Jun 13 16:46:46 CEST 2011 +

+
+ +
On 13.06.2011 17:31, Barry Jackson wrote:
+> On 13/06/11 13:24, Anssi Hannula wrote:
+>> Note that your "if ! [[ -d %{tmpdir} ]]; then" check is not 100%
+>> necessary, as %tmpdir not existing is unlikely and causes no side
+>> effects.
+>>
+> 
+> I added that as the dir is created by tar, so if the tarball had the
+> wrong content the dir may not be created with the correct name.
+> Unlikely as you say.
+
+Yep, but in that case nothing bad happens anyway. A couple of errors
+from failing cp and mv commands are printed, but nothing else.
+
+> I have started writing a script to generate the .txt files but can't
+> decide whether it should go as far as downloading the source from Skype
+> or simply be run on an extracted skype-<version> folder.
+
+It could do both :)
+Doesn't really matter, this is all extra anyway.
+
+Note that if you make it download it, you could also implement:
+a) make it print md5sum automatically
+b) make it print the dependencies automatically
+(see e.g. the earlier google earth script which does those IIRC)
+
+But as said, all of this is extra. Maybe the priority should be getting
+you a mentor.
+
+> A first draft of this is attached.
+> I assume this would ultimately be added as a SOURCE file with notes in
+> the package.
+
+Yep.
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005527.html b/zarb-ml/mageia-dev/2011-June/005527.html new file mode 100644 index 000000000..c36a0ebaa --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005527.html @@ -0,0 +1,235 @@ + + + + [Mageia-dev] Cross compile x86_64 on i586 for icecream? + + + + + + + + + +

[Mageia-dev] Cross compile x86_64 on i586 for icecream?

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Mon Jun 13 17:01:47 CEST 2011 +

+
+ +
'Twas brillig, and Christiaan Welvaart at 13/06/11 12:24 did gyre and
+gimble:
+> On Mon, 13 Jun 2011, Colin Guthrie wrote:
+> 
+>> I'm not exactly a guru with icecream but is it possible to build a
+>> toolchain that can allow i586 nodes to compile x86_64 code?
+> 
+> If your question is about the toolchain, have you tried simply passing
+> -m64 to gcc?
+
+Do you happen to know how to do that magically via icecream (the problem
+I'm getting is that the other nodes are simply not doing anything...
+perhaps the problem is related to ccache on the node doing the actual
+building (the cache being seen as a superior option to the remote
+nodes). Or maybe I just don't have all the necessary bits installed on
+the other nodes....
+
+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-June/005528.html b/zarb-ml/mageia-dev/2011-June/005528.html new file mode 100644 index 000000000..632b4d80c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005528.html @@ -0,0 +1,177 @@ + + + + [Mageia-dev] update of compiz + + + + + + + + + +

[Mageia-dev] update of compiz

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Mon Jun 13 17:04:24 CEST 2011 +

+
+ +
'Twas brillig, and Balcaen John at 13/06/11 14:39 did gyre and gimble:
+> Le lundi 13 juin 2011 09:49:57, Julien a écrit :
+> [...]
+>>
+>> (before continuing, keep in mind that I'm an apprentice since one week,
+>> so please forget me if I seem too presumptuous) 
+>>
+>> 0.9.x series is an unstable series with major modification
+>> between release and some tools (such as the decorator emerald) are not
+>> yet available.
+>>
+>> So I would prefer doing it in 2 steps :
+>>  - update current compiz to 0.8.8 (and if possible, backport it to
+>>    mageia 1) and importing emerald
+>>  - when 0.9.x series will be more stable, upgrade to 0.9
+>>
+>> WDYT ?
+> It's a good decision as expected from the compiz maintainer :)
+> 
+> Do we have any ETA regarding the 0.9 series ?
+
+Well, AFAIK, Unity in Ubuntu is based on the 0.9 series of compiz.... (I
+thought that was pretty much what it was written for?) So in that sense
+is *should* be fairly stable..... but that wasn't my expiernce when
+testing it, but I didn't spend too long on it.
+
+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-June/005529.html b/zarb-ml/mageia-dev/2011-June/005529.html new file mode 100644 index 000000000..cfc01110e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005529.html @@ -0,0 +1,237 @@ + + + + [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2

+ Cazzaniga Sandro + cazzaniga.sandro at gmail.com +
+ Mon Jun 13 17:17:41 CEST 2011 +

+
+ +
Le 13/06/2011 15:03, Thomas Backlund a écrit :
+> James Kerr skrev 13.6.2011 16:01:
+>> On 13/06/11 13:06, Dick Gevers wrote:
+>>> On Mon, 13 Jun 2011 09:37:40 +0200, Cazzaniga Sandro wrote about Re:
+>>> [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2:
+>>>
+>>>>> Quite a few packages reached the mirrors since this one, but biew has
+>>>>> not.
+>>>
+>>>> So it needs a rebuild?
+>>>
+>>> Anything similar to rebuild, push, boot, shove, %mkrel or opening the
+>>> window
+>>> to let it fly: IANAE.
+>>>
+>>
+>> In case it's relevant - the i586 package is on the mirrors. It's only
+>> x86-64 that's missing.
+> 
+> That's because spec states:
+> 
+> ExclusiveArch:  %ix86
+> 
+> -- 
+> Thomas
+thanks all!
+
+-- 
+Sandro Cazzaniga - https://lederniercoupdarchet.wordpress.com
+IRC: Kharec (irc.freenode.net)
+Software/Hardware geek
+Conceptor
+Magnum's Coordinator/editor (http://wiki.mandriva.com/fr/Magnum)
+Mageia and Mandriva contributor
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005530.html b/zarb-ml/mageia-dev/2011-June/005530.html new file mode 100644 index 000000000..3893118e6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005530.html @@ -0,0 +1,234 @@ + + + + [Mageia-dev] "Job offer" : mentoring program coordinator + + + + + + + + + +

[Mageia-dev] "Job offer" : mentoring program coordinator

+ Cazzaniga Sandro + cazzaniga.sandro at gmail.com +
+ Mon Jun 13 17:18:45 CEST 2011 +

+
+ +
Le 13/06/2011 15:19, Samuel Verschelde a écrit :
+> Le dimanche 12 juin 2011 18:55:58, Cazzaniga Sandro a écrit :
+>> Le 12/06/2011 15:27, Samuel Verschelde a écrit :
+>>> Hello to everyone,
+>>>
+>>> I'm sure there's someone among you who wants to help Mageia but hasn't
+>>> found yet the good way to do it. Today is your lucky day, because
+>>> there's a job that's available and can be really useful and interesting:
+>>> coordinating the packagers mentoring program.
+>>>
+>>> You know that one key point of success for Mageia is in the ability to
+>>> welcome new packagers. The better we will be at it, the better the
+>>> distro will be. The packagers mentoring program has been created for
+>>> that reason and several packagers have been or are being mentored. But
+>>> we have some difficulty knowing who is being mentored by who and who
+>>> hasn't found a mentor. And we need also to find more mentors and more
+>>> apprentices.
+>>>
+>>> During a packagers weekly meeting, misc invited us to read the following
+>>> article about mentoring programs in open-source projects:
+>>> http://blogs.gnome.org/bolsh/2011/05/31/effective-mentoring-programs/
+>>>
+>>> I invite those who haven't read it yet, to read it. I'll quote one of the
+>>> mentoring best practices that were given: "In bigger projects, keeping
+>>> track of who is a mentor, and who is mentoring who, and inviting new
+>>> mentors, and ensuring that no-one falls through the cracks when a mentor
+>>> gets too busy, is a job of itself."
+>>>
+>>> I'm looking for someone who could fill that "job".
+>>>
+>>> Description of the job:
+>>>
+>>> - keep track of:
+>>> -- who's being mentored by who, how well it's going
+>>> -- who needs a mentor and hasn't found one yet (this is one of the most
+>>> important parts: no volunteer must be forgotten, volunteers are too
+>>> precious !)
+>>> -- who can mentor more apprentices (and sometimes convince packagers to
+>>> become mentors or accept one more apprentice)
+>>>
+>>> - be available for questions from apprentices or mentors, by mail, and if
+>>> possible, to be present on the IRC channel #mageia-mentoring on freenode
+>>>
+>>> - help mentors with gathering "junior tasks" (bugzilla is a never empty
+>>> reserve that can be used for that. Maybe ask the bug triage team to help
+>>> identify such tasks. Maybe a "junior task" keyword in bugzilla would do
+>>> the trick)
+>>> -- small bugs to fix
+>>> -- new small packages to import in the distribution
+>>> -- backports
+>>>
+>>> - promote mentoring (empower users into contributers. Working with the
+>>> marketing team would be great I think):
+>>> -- make the mentoring program known (MLs, forums, web, etc.)
+>>> -- look for new apprentices
+>>> -- look for new mentors
+>>>
+>>> Some useful skills:
+>>> - be autonomous (ie no need to check that you're doing the work)
+>>> - good written english (communication is very important in this job)
+>>> - knowledge about packaging is a plus but not mandatory (the key aspects
+>>> can be taught to you)
+>>> - being or having been a mentor, or having been mentored would be a plus,
+>>> but not mandatory
+>>>
+>>> More information about the job:
+>>> - does not require a big amount of work, but real committment to the task
+>>> and regularity
+>>> - remember that you have a coordination role, not an authoritative role.
+>>> The difference in that is that you're not here to give orders but to
+>>> facilitate the mentoring program.
+>>> - you don't have to be alone to do this job if it's too much for one
+>>> person: you can find other helpful people wanting to help you if needed
+>>> and rely on the other teams (but finding them *is* part of your job ;)
+>>> ).
+>>> -  this "job offer" concerns everything that revolves around the
+>>> mentoring of new packagers, but if it's successful maybe other teams can
+>>> follow the same approach (i18n, QA, etc... ).
+>>> -  depending on your level of confidence, experience and will, you could
+>>> be helped in your work. Maybe someone from the council can supervise and
+>>> help you at least at the beginning; or, if no one steps up, I can help
+>>> you bootstrap and organize your new "job".
+>>>
+>>> So, who's in?
+>>>
+>>> Samuel Verschelde
+>>
+>> I offer my candidacy. I was mentored by shikamaru and i'm a mandriva
+>> packager since 2009 and a mageia packager since the start.
+>> My english level is pretty good and i'm pretty sociable.
+>>
+> 
+> Hi,
+> 
+> As explained on IRC yesterday, your candidacy is interesting, but you have 
+> already so many other engagements that I would prefer someone with more 
+> availability :) So keep on the good work where you're already committed :)
+> 
+> Best regards
+> 
+> Samuel Verschelde
+!no problem, thanks!
+
+-- 
+Sandro Cazzaniga - https://lederniercoupdarchet.wordpress.com
+IRC: Kharec (irc.freenode.net)
+Software/Hardware geek
+Conceptor
+Magnum's Coordinator/editor (http://wiki.mandriva.com/fr/Magnum)
+Mageia and Mandriva contributor
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005531.html b/zarb-ml/mageia-dev/2011-June/005531.html new file mode 100644 index 000000000..69f1261ed --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005531.html @@ -0,0 +1,157 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Angelo Naselli + anaselli at linux.it +
+ Mon Jun 13 17:36:50 CEST 2011 +

+
+ +
lunedì 13 giugno 2011 alle 15:08, Thomas Backlund ha scritto:
+> Well, it was intended to point out the problem with the "flexible" 
+> approach, and a possible "fix" by deciding some limits to the flexibility.
+If the decision of how much (+X or -X) is taken during the post release
+phase (e.g. now in the pre new release working). it's not that problem.
+I mean we decide for 10 mo release because gnome (chose that because i like kde :p)
+is out in 8 months and we'd like to have 2 months testing -that allows a little 
+gnome release delay- so from that point on the release plan is fixed at 10 months.
+Next release we could decide for 6 months because no great changes from the world
+are expected....
+
+But i believe it's hard to follow, because every time we should spend
+a lot of time discussing for this stuff and that could be harmless...
+
+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/20110613/f7d7bb63/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005532.html b/zarb-ml/mageia-dev/2011-June/005532.html new file mode 100644 index 000000000..ac91a2c7c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005532.html @@ -0,0 +1,183 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Dale Huckeby + spock at evansville.net +
+ Mon Jun 13 17:37:25 CEST 2011 +

+
+ +
On Mon, 13 Jun 2011, Wolfgang Bornath wrote:
+
+> About the cycles:
+>
+> The problems with 6-months have been pointed out - my main concern
+> would be the lack of manpower and the continuous state of
+> "pre-release", no real room to sit back and contemplate hwat is and
+> what could be and all the rest. IMHO such a "contemplating" time is
+> necessary to keep the whole picture in focus.
+>
+> The problems with 12-months have also been pointed out and I agree
+> with them (too long out of public focus, too long for the main
+> userland applications, etc.).
+>
+> The 9-months seem to be a compromise - but I start to ask why we need
+> such a fixed statement (which it would be, once published). We need a
+> schedule for each cycle, that's true. Without a schedule we would
+> never finish anything. But how about taking 9 months only as a "nice
+> to meet" target, leaving us the option to set a roadmap after setting
+> the specs of the next release - we could then go for a 8 or 10 months
+> roadmap, depending on the specs.
+>
+> This being said, I am a friend of a rolling release like ArchLinux,
+> but I fear that our main target group is not up to this. Despite of
+> having to "burn yet another DVD" as somebody pointed out, the majority
+> seems to see this as normal and a good way. Of course I may be totally
+> wrong with this assessment!
+
++1
+
+The consensus so far seems to be:
+
+6 months is too short
+12 months is too long
+9 months is juuuuust about right
+
+and that applies not only to developers having a chance to catch their breath between versions, but
+users too.  A 6-month turnaround feels like I'm constantly updating, but a 12-month wait between
+versions is like forever.  And as wobo suggests, 9 months need be only an average, with a target date
+for the next release, taking into account upstream developments, decided on after each one.  Also,
+the target date should be approximate at first and firmed up only as we get closer to release.
+
+spock
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005533.html b/zarb-ml/mageia-dev/2011-June/005533.html new file mode 100644 index 000000000..ee7804df0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005533.html @@ -0,0 +1,111 @@ + + + + [Mageia-dev] [RPM] cauldron core/release libgdata-0.7.1-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release libgdata-0.7.1-1.mga2

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Mon Jun 13 17:59:28 CEST 2011 +

+
+ +
On 13 June 2011 15:10, Christiaan Welvaart <cjw at daneel.dyndns.org> wrote:
+> On Wed, 8 Jun 2011, Balcaen John wrote:
+>
+>> Le mercredi 8 juin 2011 16:52:16, Mageia Team a écrit :
+>>>
+>>> Name        : libgdata                     Relocations: (not relocatable)
+>>> Version     : 0.7.1                             Vendor: Mageia.Org
+>>
+>> [...]
+>>>
+>>> dmorgan <dmorgan> 0.7.1-1.mga2:
+>>> + Revision: 102030
+>>> - New version 0.7.1
+>>
+>> There's a file conflict :
+>> Installation failed:
+>>       file /usr/lib64/girepository-1.0/GData-0.0.typelib from install of
+>> lib64gdata10-0.7.1-1.mga2.x86_64 conflicts with file from package
+>> lib64gdata7-0.6.6-1.mga1.x86_64
+>>
+>> Installation failed:    file /usr/lib64/girepository-1.0/GData-0.0.typelib
+>> from install of lib64gdata10-0.7.1-1.mga2.x86_64 conflicts with file from
+>> package lib64gdata7-0.6.6-1.mga1.x86_64
+>>
+>> Maybe this file should not be in the versionned library package ?
+>
+> Indeed, but I see no way to really fix the upgrade except by providing a
+> fixed lib(64)gdata7 in mga2.
+>
+> We have poppler-gir0.16 for girepository-1.0/Poppler-0.16.typelib .
+> (In ubuntu they call the extra package gir1.0-gdata-0.0 .)
+>
+> So we should probably add lib(64)gdata-gir0.0 . It must be libified to allow
+> parallel installation of libgdata10 and lib64gdata10. The new package will
+> conflict with lib(64)gdata7 so all applications that use it (totem and
+> evolution) must be rebuilt.
+>
+>
+>    Christiaan
+>
+
+Actually, I think I should have libified poppler-gir (only spotted
+that issue yesterday updating the folks package... :( ).
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005534.html b/zarb-ml/mageia-dev/2011-June/005534.html new file mode 100644 index 000000000..a8acc2b4c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005534.html @@ -0,0 +1,134 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Angelo Naselli + anaselli at linux.it +
+ Mon Jun 13 18:20:44 CEST 2011 +

+
+ +
lunedì 13 giugno 2011 alle 16:46, Anssi Hannula ha scritto:
+> a) make it print md5sum automatically
+Just out of curiosity, md5 has been calculated by your download?
+So you trust your first download :D
+
+/me is joking
+
+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/20110613/7068a595/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005535.html b/zarb-ml/mageia-dev/2011-June/005535.html new file mode 100644 index 000000000..1a34d411b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005535.html @@ -0,0 +1,166 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ lebarhon + lebarhon at free.fr +
+ Mon Jun 13 18:29:14 CEST 2011 +

+
+ +
Le 13/06/2011 17:37, Dale Huckeby a écrit :
+>
+> The consensus so far seems to be:
+>
+> 6 months is too short
+> 12 months is too long
+> 9 months is juuuuust about right
+>
+
+You have to choose your public, 6 months is for geeks, 12 months is for 
+everybody, these people who aren't IT technicians.
+The installation of the new release is always something dangerous and 
+worrying because there is always the codecs, the nets or some 
+applications without rpm package. Moreover, the hardware evolution is 
+slowing down and doesn't need so closed together releases.
+I would prefer devs doing more different things less often that devs 
+doing more often the same things, that isn't going ahead. Take care 
+also, not developing things without any documentation, let this 
+specialty to KDE.
+I would like also that devs give more importance to the installation by 
+update than to the new installation  (too much work to configure, desk, 
+mail, ML, nets, backups, specific applications to be installed by hand 
+like Geneanet or Rawtherapee...)
+For all that, 12 months is already very short.
+
+Lebarhon
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005536.html b/zarb-ml/mageia-dev/2011-June/005536.html new file mode 100644 index 000000000..b0cb5b2d2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005536.html @@ -0,0 +1,232 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Ron + corbintechboy at yahoo.com +
+ Mon Jun 13 18:51:40 CEST 2011 +

+
+ +
I will say my part and I'm gone...
+I don't understand why everyone is acting like a rolling release is going to put so much strain on the project. What is so hard about developing in one place and allowing the updates to trickle down is so hard?
+It almost seems to me that you want to ask the opinion of people, but don't want to hear.
+And what is this posting here? I don't even know how to use this thing and yet I had to signup to get my voice heard because this is the way you want to do things? I don't understand where the whole community fits into this here right now, I think I actually say a lot when I say that many people want a rolling release.... It just seems the developers will have the way here... Why ask in the first place? Really?
+I am leaving the list and sorry about the HTML in my emails, must be a yahoo thing because I did not use HTML... Again I don't know how to use this thing and should not have been forced to.
+I would also say that I, for 1 will not be staying if you are going to do a release cycle only... I have loads of options if I just want snapshots of what's going on in the Linux world.... Arch gives me so much more and I had hopes of switching to this with a release model that made sense... But it seems we won't and we will just become yet another XXX release cycle distribution with no clear anything that sets us apart from X.
+On you, I'm gone and thanks for hearing me and sorry if my postings were done wrong....
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110613/a251d51e/attachment-0001.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005537.html b/zarb-ml/mageia-dev/2011-June/005537.html new file mode 100644 index 000000000..d37b1c9e1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005537.html @@ -0,0 +1,236 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Sander Lepik + sander.lepik at eesti.ee +
+ Mon Jun 13 19:07:26 CEST 2011 +

+
+ +
13.06.2011 19:51, Ron kirjutas:
+> I will say my part and I'm gone...
+>
+> I don't understand why everyone is acting like a rolling release is going to put so much 
+> strain on the project. What is so hard about developing in one place and allowing the 
+> updates to trickle down is so hard?
+>
+Well.. take Cauldron as a rolling release. It basically is :) So from that point of view.. 
+why would we need another rolling release if we already have one? :)
+
+--
+Sander
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005538.html b/zarb-ml/mageia-dev/2011-June/005538.html new file mode 100644 index 000000000..771dc8410 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005538.html @@ -0,0 +1,157 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Michael Scherer + misc at zarb.org +
+ Mon Jun 13 19:22:19 CEST 2011 +

+
+ +
Le lundi 13 juin 2011 à 18:29 +0200, lebarhon a écrit :
+> Le 13/06/2011 17:37, Dale Huckeby a écrit :
+> >
+> > The consensus so far seems to be:
+> >
+> > 6 months is too short
+> > 12 months is too long
+> > 9 months is juuuuust about right
+> >
+> 
+> You have to choose your public, 6 months is for geeks, 12 months is for 
+> everybody, these people who aren't IT technicians.
+
+That's why Debian, who release every 2 years, is such a hit in the non
+geek population.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005539.html b/zarb-ml/mageia-dev/2011-June/005539.html new file mode 100644 index 000000000..3582c40c5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005539.html @@ -0,0 +1,272 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Mon Jun 13 19:32:40 CEST 2011 +

+
+ +
Op maandag 13 juni 2011 18:51:40 schreef Ron:
+> I will say my part and I'm gone...
+> I don't understand why everyone is acting like a rolling release is going
+> to put so much strain on the project. What is so hard about developing in
+> one place and allowing the updates to trickle down is so hard? It almost
+> seems to me that you want to ask the opinion of people, but don't want to
+> hear. And what is this posting here? I don't even know how to use this
+> thing and yet I had to signup to get my voice heard because this is the
+> way you want to do things? I don't understand where the whole community
+> fits into this here right now, I think I actually say a lot when I say
+> that many people want a rolling release.... It just seems the developers
+> will have the way here... Why ask in the first place? Really? I am leaving
+> the list and sorry about the HTML in my emails, must be a yahoo thing
+> because I did not use HTML... Again I don't know how to use this thing and
+> should not have been forced to. I would also say that I, for 1 will not be
+> staying if you are going to do a release cycle only... I have loads of
+> options if I just want snapshots of what's going on in the Linux world....
+> Arch gives me so much more and I had hopes of switching to this with a
+> release model that made sense... But it seems we won't and we will just
+> become yet another XXX release cycle distribution with no clear anything
+> that sets us apart from X. On you, I'm gone and thanks for hearing me and
+> sorry if my postings were done wrong....
+
+complete rolling release would put a QA strain on each of the levels. think 
+about it, it's not only the current package being updated, but also the 
+combinations with other packages. (AND also all the long time supported 
+versions)
+
+This would mean that for each package being release, it'll have to work with 
+the current set of other packages, but also with the packages you'll be doing 
+next.
+
+if you have this constant level of QA, you need alot of resources (which we 
+don't have in QA), and as an extra result, you'll not have the same level of 
+QA you could have, when you're doing a release.
+
+it's much easier (as devs) to just choose a subset of packages, and test those 
+out.
+
+if you have X QA-devs, and you have 1 subset of versions of packages, you can 
+test alot more than if you have several versions of several packages that need 
+to work all with each other in almost any combinations...
+
+not to mention that you need an extra step with QA to put a "group" of 
+packages from one level to the next...
+
+sorry, but with our current resources, i vote no. i want current resources to 
+be used much more efficiently than with a rolling release.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005540.html b/zarb-ml/mageia-dev/2011-June/005540.html new file mode 100644 index 000000000..77343b355 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005540.html @@ -0,0 +1,272 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Lee Forest + lee8oi at gmail.com +
+ Mon Jun 13 19:30:57 CEST 2011 +

+
+ +
I like the idea of releasing when ready. Its done when the team thinks its
+ready and not because its being demanded by end users. In Linux Mint this
+does alot of good because of having to clean up after ubuntu so much. The
+releases are much more stable and polished. The way clement lefabre likes
+it. And everyone who uses it is usually satisfied with the end product.
+As for being in the news more, we dont have to put out a release just to be
+able blog about whats going on in the mageia community and remind everyone
+why mageia is special. But this must be the case because theres rarely any
+new news posted in mageia blog unless a release is coming out. Thats getting
+about as lame as these messages in this mailing list telling people they
+sent their message to the mailing list wrong.
+What is this distro really about? One upping mandriva and following the same
+mechanical routines they did to piss you guys off, or building a real
+community distribution of gnu/linux that cares more about keeping in touch
+with the community than they do about the way someone new sent a mailing
+list message. Theres more to a linux community then mailing lists.
+At first I was excited about using mageia, and being a part of the
+community. Now im dissappointed because I see how you treat people that are
+not on the team. Basically like their opinions
+(that you ask for) dont matter, and you are only concerned with the proper
+submission of mailing lists messages. Get someone on the blogs and start
+talking to the rest of the community the way they deserve. I agree with the
+gentleman leaving the mailing list. This isn't worth sticking around for.
+Time to remember why you started mageia in the first place.
+On Jun 13, 2011 12:51 PM, "Ron" <corbintechboy at yahoo.com> wrote:
+> I will say my part and I'm gone...
+> I don't understand why everyone is acting like a rolling release is going
+to put so much strain on the project. What is so hard about developing in
+one place and allowing the updates to trickle down is so hard?
+> It almost seems to me that you want to ask the opinion of people, but
+don't want to hear.
+> And what is this posting here? I don't even know how to use this thing and
+yet I had to signup to get my voice heard because this is the way you want
+to do things? I don't understand where the whole community fits into this
+here right now, I think I actually say a lot when I say that many people
+want a rolling release.... It just seems the developers will have the way
+here... Why ask in the first place? Really?
+> I am leaving the list and sorry about the HTML in my emails, must be a
+yahoo thing because I did not use HTML... Again I don't know how to use this
+thing and should not have been forced to.
+> I would also say that I, for 1 will not be staying if you are going to do
+a release cycle only... I have loads of options if I just want snapshots of
+what's going on in the Linux world.... Arch gives me so much more and I had
+hopes of switching to this with a release model that made sense... But it
+seems we won't and we will just become yet another XXX release cycle
+distribution with no clear anything that sets us apart from X.
+> On you, I'm gone and thanks for hearing me and sorry if my postings were
+done wrong....
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110613/9badc44d/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005541.html b/zarb-ml/mageia-dev/2011-June/005541.html new file mode 100644 index 000000000..8a8a4d65f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005541.html @@ -0,0 +1,276 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Mon Jun 13 20:12:21 CEST 2011 +

+
+ +
2011/6/13 Lee Forest <lee8oi at gmail.com>:
+> I like the idea of releasing when ready. Its done when the team thinks its
+> ready and not because its being demanded by end users.
+
+Yes. in a world without users this is the best solution. But there are
+users. Giving them a "when it's ready" as release date opens doors for
+all kinds of questions about this "it's ready", like, "how can you say
+it's ready when package foo is not included in it's newest version?"
+
+> As for being in the news more, we dont have to put out a release just to be
+> able blog about whats going on in the mageia community and remind everyone
+> why mageia is special. But this must be the case because theres rarely any
+> new news posted in mageia blog unless a release is coming out.
+
+Oh, you haven't read the blog for some time? The blog is about what we
+do, there was a release coming up on June 1st, so during pre-release
+time the blog was mainly about the release. But there have been a lot
+of other articles, if you miss a certain subject, tell us what you
+want to read about.
+
+> Thats getting
+> about as lame as these messages in this mailing list telling people they
+> sent their message to the mailing list wrong.
+
+Yes, it is a PITA that such messages seem to be needed again and again
+to keep the flow of mails readable in a thread.
+
+> At first I was excited about using mageia, and being a part of the
+> community. Now im dissappointed because I see how you treat people that are
+> not on the team. Basically like their opinions
+> (that you ask for) dont matter, and you are only concerned with the proper
+> submission of mailing lists messages. Get someone on the blogs and start
+> talking to the rest of the community the way they deserve. I agree with the
+> gentleman leaving the mailing list. This isn't worth sticking around for.
+> Time to remember why you started mageia in the first place.
+
+A community has almost as many different ideas and answers as the
+number of people involved. So it may be that one who gives his opinion
+gets replies with different opinions - this is called "discussions".
+
+The side question here was why Ron did not write his opinion in the
+thread where the rest of the discussion already took place. I would
+think this is a reasonable request to make it easier for those who
+will have the task of gathering all the opinions - to do just what you
+say we are neglecting. The remark about proper posting style was just
+a remark to keep the flow of discussion easy to follow, also a
+reasonable request.
+
+In an ideal world the person in question would have followed the
+remarks and kept up advocating his opinion where all others are
+discussing the matter. But if somebody prefers to put such reasonable
+requests in front instead, so be it.
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005542.html b/zarb-ml/mageia-dev/2011-June/005542.html new file mode 100644 index 000000000..93dbf9061 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005542.html @@ -0,0 +1,301 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Anne nicolas + ennael at mageia.org +
+ Mon Jun 13 20:14:07 CEST 2011 +

+
+ +
2011/6/13 Lee Forest <lee8oi at gmail.com>
+
+> I like the idea of releasing when ready. Its done when the team thinks its
+> ready and not because its being demanded by end users. In Linux Mint this
+> does alot of good because of having to clean up after ubuntu so much. The
+> releases are much more stable and polished. The way clement lefabre likes
+> it. And everyone who uses it is usually satisfied with the end product.
+>
+Well this is theway it seems we are going to, some people proposing 9 months
+release depending on release dates of main softwares. Anyway whatever the
+choice, it's obvious that we will not release final one if  this is not
+stable enough.
+
+> As for being in the news more, we dont have to put out a release just to be
+> able blog about whats going on in the mageia community and remind everyone
+> why mageia is special. But this must be the case because theres rarely any
+> new news posted in mageia blog unless a release is coming out. Thats getting
+> about as lame as these messages in this mailing list telling people they
+> sent their message to the mailing list wrong.
+> What is this distro really about? One upping mandriva and following the
+> same mechanical routines they did to piss you guys off, or building a real
+> community distribution of gnu/linux that cares more about keeping in touch
+> with the community than they do about the way someone new sent a mailing
+> list message. Theres more to a linux community then mailing lists.
+> At first I was excited about using mageia, and being a part of the
+> community. Now im dissappointed because I see how you treat people that are
+> not on the team. Basically like their opinions
+>
+Not at all. everyone can subscribe mailing- lists. The point is Mageia is a
+young project and we cannot afford for now at least to spread efforts on
+forums and mailing-lists and blogs... People still sleep during the night.
+It may not be perfect but it's a start. Our points is just to try to get all
+opinions in a same place, that's all.
+
+> (that you ask for) dont matter, and you are only concerned with the proper
+> submission of mailing lists messages. Get someone on the blogs and start
+> talking to the rest of the community the way they deserve. I agree with the
+> gentleman leaving the mailing list. This isn't worth sticking around for.
+> Time to remember why you started mageia in the first place.
+>
+Of course we are opened to any of your proposals and ideas and contributions
+to improve all this :)
+
+Cheers
+
+
+
+> On Jun 13, 2011 12:51 PM, "Ron" <corbintechboy at yahoo.com> wrote:
+> > I will say my part and I'm gone...
+> > I don't understand why everyone is acting like a rolling release is going
+> to put so much strain on the project. What is so hard about developing in
+> one place and allowing the updates to trickle down is so hard?
+> > It almost seems to me that you want to ask the opinion of people, but
+> don't want to hear.
+> > And what is this posting here? I don't even know how to use this thing
+> and yet I had to signup to get my voice heard because this is the way you
+> want to do things? I don't understand where the whole community fits into
+> this here right now, I think I actually say a lot when I say that many
+> people want a rolling release.... It just seems the developers will have the
+> way here... Why ask in the first place? Really?
+> > I am leaving the list and sorry about the HTML in my emails, must be a
+> yahoo thing because I did not use HTML... Again I don't know how to use this
+> thing and should not have been forced to.
+> > I would also say that I, for 1 will not be staying if you are going to do
+> a release cycle only... I have loads of options if I just want snapshots of
+> what's going on in the Linux world.... Arch gives me so much more and I had
+> hopes of switching to this with a release model that made sense... But it
+> seems we won't and we will just become yet another XXX release cycle
+> distribution with no clear anything that sets us apart from X.
+> > On you, I'm gone and thanks for hearing me and sorry if my postings were
+> done wrong....
+>
+
+
+
+-- 
+Anne
+http://www.mageia.org
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110613/533d939b/attachment-0001.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005543.html b/zarb-ml/mageia-dev/2011-June/005543.html new file mode 100644 index 000000000..ce57d6922 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005543.html @@ -0,0 +1,227 @@ + + + + [Mageia-dev] perl 5.14 migration almost complete, 3 (non-cpan) modules to go - need help from their owner! + + + + + + + + + +

[Mageia-dev] perl 5.14 migration almost complete, 3 (non-cpan) modules to go - need help from their owner!

+ philippe makowski + makowski.mageia at gmail.com +
+ Mon Jun 13 20:23:42 CEST 2011 +

+
+ +
2011/6/13 Jerome Quelin <jquelin at gmail.com>:
+> - perl-DBD-Firebird
+>
+> this module does not compile with perl 5.14: no success reported by any
+> cpan testers. i've added a conflicts in perl to have a smooth transition
+> too. it'll be updated when a new version is available upstream.
+>
+thanks reporting, I will contact upstream
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005544.html b/zarb-ml/mageia-dev/2011-June/005544.html new file mode 100644 index 000000000..f387feb24 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005544.html @@ -0,0 +1,158 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ lebarhon + lebarhon at free.fr +
+ Mon Jun 13 21:08:36 CEST 2011 +

+
+ +
Le 13/06/2011 19:22, Michael Scherer a écrit :
+> Le lundi 13 juin 2011 à 18:29 +0200, lebarhon a écrit :
+>> Le 13/06/2011 17:37, Dale Huckeby a écrit :
+>>> The consensus so far seems to be:
+>>>
+>>> 6 months is too short
+>>> 12 months is too long
+>>> 9 months is juuuuust about right
+>>>
+>> You have to choose your public, 6 months is for geeks, 12 months is for
+>> everybody, these people who aren't IT technicians.
+> That's why Debian, who release every 2 years, is such a hit in the non
+> geek population.
+>
+Funny boy, you get me stuck here !
+I would say, this people are geek enough to enjoy installing the same 
+release many times.
+But believe me, you have to be fluent to enjoy an OS installation.
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005545.html b/zarb-ml/mageia-dev/2011-June/005545.html new file mode 100644 index 000000000..abdd63d2a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005545.html @@ -0,0 +1,176 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ lebarhon + lebarhon at free.fr +
+ Mon Jun 13 21:18:19 CEST 2011 +

+
+ +
 From *pmithrandir 
+<https://forums.mageia.org/en/memberlist.php?mode=viewprofile&u=359>*  
+on the forum
+
+On my side, I think mageia should do a "mix" of others idea.
+
+I would say :
+- A release every year.
+- During this year, a way to update some popular stuff (firefox, chrome, 
+libreoffice...)
+- During this year also a way to add some new package if needed or if 
+there is some instant success for a new software.
+
+Every 3 years, the release is LTS and that mean it would be maintain for 
+4 years.
+
+So at the same time, mageia would be in 3 mode :
+- The LTS
+- The common release
+- The cauldron.
+
+With that kind of stuff, you should have no more than one release for 
+public at a time, and just one LTS.
+If you update main software(we could define a list of no more than 20 
+software) people who are crasy about new function, or developper who 
+need tham to develop new stuff would be happy.
+
+BTW : I think mailing list are totally outdated and that mageia should 
+have a special section in this forum for these discussion, or maybe 
+another forum.
+It's totally impossible for people who want to participate sometimes to 
+follow you emails everydays. It's much faster to read some topic on a 
+forum than dozens emails. And your final user should be able to know 
+what happen easily. It would be a big + in front of others distributions.
+
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110613/4f2f9de9/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005546.html b/zarb-ml/mageia-dev/2011-June/005546.html new file mode 100644 index 000000000..529271872 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005546.html @@ -0,0 +1,220 @@ + + + + [Mageia-dev] GNOME3 ? + + + + + + + + + +

[Mageia-dev] GNOME3 ?

+ Frank Griffin + ftg at roadrunner.com +
+ Mon Jun 13 21:49:15 CEST 2011 +

+
+ +
Is the GNOME3 upload complete to the point where bug reports will be 
+useful ?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005547.html b/zarb-ml/mageia-dev/2011-June/005547.html new file mode 100644 index 000000000..3a238b1eb --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005547.html @@ -0,0 +1,239 @@ + + + + [Mageia-dev] GNOME3 ? + + + + + + + + + +

[Mageia-dev] GNOME3 ?

+ Dick Gevers + dvgevers at xs4all.nl +
+ Mon Jun 13 22:04:28 CEST 2011 +

+
+ +
On Mon, 13 Jun 2011 15:49:15 -0400, Frank Griffin wrote about [Mageia-dev]
+GNOME3 ?:
+
+>Is the GNOME3 upload complete to the point where bug reports will be 
+>useful ?
+
+I doubt it:
+# rpm -qa |grep me-des
+
+gnome-desktop-2.32.1-1.mga1
+gnome-desktop3-3.0.2-3.mga2
+lib64gnome-desktop-3_0-3.0.2-3.mga2
+
+# rpm -ev gnome-desktop
+
+error: Failed dependencies:
+        gnome-desktop is needed by (installed)
+gnome-panel-3.0.2-2.mga2.x86_64
+
+Cheers,
+=Dick Gevers=
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005548.html b/zarb-ml/mageia-dev/2011-June/005548.html new file mode 100644 index 000000000..a0cb09f6c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005548.html @@ -0,0 +1,244 @@ + + + + [Mageia-dev] GNOME3 ? + + + + + + + + + +

[Mageia-dev] GNOME3 ?

+ Dexter Morgan + dmorganec at gmail.com +
+ Mon Jun 13 22:05:21 CEST 2011 +

+
+ +
On Mon, Jun 13, 2011 at 10:04 PM, Dick Gevers <dvgevers at xs4all.nl> wrote:
+> On Mon, 13 Jun 2011 15:49:15 -0400, Frank Griffin wrote about [Mageia-dev]
+> GNOME3 ?:
+>
+>>Is the GNOME3 upload complete to the point where bug reports will be
+>>useful ?
+>
+> I doubt it:
+> # rpm -qa |grep me-des
+>
+> gnome-desktop-2.32.1-1.mga1
+> gnome-desktop3-3.0.2-3.mga2
+> lib64gnome-desktop-3_0-3.0.2-3.mga2
+>
+> # rpm -ev gnome-desktop
+>
+> error: Failed dependencies:
+>        gnome-desktop is needed by (installed)
+> gnome-panel-3.0.2-2.mga2.x86_64
+>
+> Cheers,
+> =Dick Gevers=
+>
+
+nice i fix this one
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005549.html b/zarb-ml/mageia-dev/2011-June/005549.html new file mode 100644 index 000000000..c8e5c9280 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005549.html @@ -0,0 +1,255 @@ + + + + [Mageia-dev] GNOME3 ? + + + + + + + + + +

[Mageia-dev] GNOME3 ?

+ Dexter Morgan + dmorganec at gmail.com +
+ Mon Jun 13 22:06:56 CEST 2011 +

+
+ +
On Mon, Jun 13, 2011 at 10:04 PM, Dick Gevers <dvgevers at xs4all.nl> wrote:
+> On Mon, 13 Jun 2011 15:49:15 -0400, Frank Griffin wrote about [Mageia-dev]
+> GNOME3 ?:
+>
+>>Is the GNOME3 upload complete to the point where bug reports will be
+>>useful ?
+>
+> I doubt it:
+> # rpm -qa |grep me-des
+>
+> gnome-desktop-2.32.1-1.mga1
+> gnome-desktop3-3.0.2-3.mga2
+> lib64gnome-desktop-3_0-3.0.2-3.mga2
+>
+> # rpm -ev gnome-desktop
+>
+> error: Failed dependencies:
+>        gnome-desktop is needed by (installed)
+> gnome-panel-3.0.2-2.mga2.x86_64
+>
+> Cheers,
+> =Dick Gevers=
+>
+
+Should be fixed in next gnome-panel
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005550.html b/zarb-ml/mageia-dev/2011-June/005550.html new file mode 100644 index 000000000..4748f0945 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005550.html @@ -0,0 +1,229 @@ + + + + [Mageia-dev] GNOME3 ? + + + + + + + + + +

[Mageia-dev] GNOME3 ?

+ Frank Griffin + ftg at roadrunner.com +
+ Mon Jun 13 22:12:26 CEST 2011 +

+
+ +
On 06/13/2011 04:05 PM, Dexter Morgan wrote:
+> nice i fix this one
+
+
+The reason I ask is that on an ID previously using GNOME 2.32, the 
+desktop comes up, but launching any application drives the video crazy.  
+You can see the app window some of the time, but after a second or two 
+of video flashing you get a fullscreen  "Oops" panel and are told to log 
+out.  On a fresh ID, you can't even get the desktop to come up - you get 
+the blue background, the mouse pointer circles for a bit and then stops, 
+with no error and no recourse but CTRL-ALT-BKSP.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005551.html b/zarb-ml/mageia-dev/2011-June/005551.html new file mode 100644 index 000000000..20c388e25 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005551.html @@ -0,0 +1,232 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Thorsten van Lil + tvl83 at gmx.de +
+ Mon Jun 13 23:06:11 CEST 2011 +

+
+ +
Am Sonntag, 12. Juni 2011, 22:46:33 schrieb Michael Scherer:
+> Proposal 1: 
+> 6 months release cycle -> 12 months life cycle
+> ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
+> 
+> Proposal 2: 
+> 9 months release cycle -> 18 months life cycle  
+> ( ~ opensuse and the one we used for Mageia 1 )
+> 
+> Proposal 3: 
+> 12 months release cycle -> 24 months life cycle
+> ( Mandriva > 2010.1 )
+
+Here is my opinion for this discussion:
+
+The question of the release cycle is conected with the question of the release 
+model.
+
+And all proposals we make are restricted by the manpower.
+
+Actally there are two release models active in the linux scene:
+1. a static release every X months
+2. a rolling release
+
+*But* a mix of both is also possible.
+
+A rolling release has following advantages:
+1. the distribution is always up to date (also hardware support) 
+2. no re-install over and over again
+
+and following disadvantages
+1. it's a heavy load for the devs
+2. we can almost only ship vanilla software. No real integration in the 
+distribution. With all it's advantages and disadvantages
+3. hard to guarantee the stability over the years
+4. no inovations within the software (see second disadvantage)
+
+A static releas has the following advantages:
+1. less load for the devs
+2. easier to support
+3. patching is possible
+4. most distribution use this release model
+
+and followind disadvantages;
+1. no new hardware support
+2. no new software versions
+
+This is the current situation.
+
+Some users also wants the a mix of both (also called a light rolling release) 
+and combine the advantages as far as possible.
+This could look like this:
+Bring up a release once a year. The core (kernel, glib, ...) will only get 
+minor updates. Apllications like firefox, libreoffice, ... will always be up to 
+date (rolling). Maybe also the desktop envirenments could be rolling but this 
+is very heavy.
+
+The light rolling releas has the following advantages:
+1. the apps are always up to date
+2. less load for devs than a full rolling release
+3. patching is possible
+4. innovations are possible
+5. no other distribution is using such a release model
+6. the stability is easier to guarentee than rolling release
+
+and following disadvantages
+1. more load than static release
+2. no new hardware support (could be done via backports if needed)
+
+If such a release model is possible, is up to the devs to decide (I can't 
+evaluate the work load). But we have to bear in mind, that we have enough 
+range for new inovations. 
+
+Please keep also in mind, that a distribution doesn't or shouldn't exists for 
+end in itself. It's just a operating systems and as long as there isn't a real 
+need for re-installing we shouldn't. Thus, we shouldn't enforce the user for 
+re-installing more than needed.
+
+Hope this wasn't to much text ^^
+
+Greetings,
+Thorsten
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005552.html b/zarb-ml/mageia-dev/2011-June/005552.html new file mode 100644 index 000000000..e640de365 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005552.html @@ -0,0 +1,245 @@ + + + + [Mageia-dev] gtk+3.0 changes + + + + + + + + + +

[Mageia-dev] gtk+3.0 changes

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Mon Jun 13 23:06:48 CEST 2011 +

+
+ +
Hello,
+
+Just a minor change in gtk+3.0, the gtk-query-immodules* executable
+has been moved from the lib package to to the main package, so if you
+get get any file conflicts errors when updating, you should install
+the lib package first:
+# urpmi libgtk+3_0-3.0.11
+
+it's lib64gtk+3_0-3.0.11 if you're running x86_64. Then update your
+system (urpmi --auto-update).
+
+
+This issue only happened in Cauldron (for about 2 weeks), so no
+conflicts will be added.
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005553.html b/zarb-ml/mageia-dev/2011-June/005553.html new file mode 100644 index 000000000..32b8505d7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005553.html @@ -0,0 +1,252 @@ + + + + [Mageia-dev] [RPM] cauldron core/release iceape-2.1-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release iceape-2.1-1.mga2

+ Dick Gevers + dvgevers at xs4all.nl +
+ Mon Jun 13 23:08:52 CEST 2011 +

+
+ +
On Mon, 13 Jun 2011 15:10:47 +0200 (CEST), Mageia Team wrote about [RPM]
+cauldron core/release iceape-2.1-1.mga2:
+
+>Name        : iceape                       Relocations: (not relocatable)
+>Version     : 2.1                               Vendor: Mageia.Org
+>Release     : 1.mga2                        Build Date: Mon Jun 13
+>14:41:21 2011 Install Date: (not installed)               Build Host:
+>ecosse Group       : Networking/WWW                Source RPM: (none)
+>Size        : 103538083                        License: MPL
+>Signature   : (none)
+>Packager    : Mageia Team <http://www.mageia.org>
+>URL         : http://www.seamonkey-project.org/
+>Summary     : IceApe, the all-in-one internet application suite
+
+>cjw <cjw> 0:2.1-1.mga2:
+>+ Revision: 105755
+>- iceape 2.1
+
+
+The personal toolbar contains five Mandriva links.
+
+HTH
+=Dick Gevers=
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005554.html b/zarb-ml/mageia-dev/2011-June/005554.html new file mode 100644 index 000000000..1cb577672 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005554.html @@ -0,0 +1,239 @@ + + + + [Mageia-dev] [105941] imported package rake + + + + + + + + + +

[Mageia-dev] [105941] imported package rake

+ Dexter Morgan + dmorganec at gmail.com +
+ Mon Jun 13 23:20:52 CEST 2011 +

+
+ +
On Mon, Jun 13, 2011 at 11:14 PM,  <root at mageia.org> wrote:
+> Revision 105941 Author kharec Date 2011-06-13 23:14:01 +0200 (Mon, 13 Jun
+> 2011)
+>
+> Log Message
+>
+> imported package rake
+
+already exist in mageia in ruby-rake
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005555.html b/zarb-ml/mageia-dev/2011-June/005555.html new file mode 100644 index 000000000..10540fc05 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005555.html @@ -0,0 +1,241 @@ + + + + [Mageia-dev] [105941] imported package rake + + + + + + + + + +

[Mageia-dev] [105941] imported package rake

+ Cazzaniga Sandro + cazzaniga.sandro at gmail.com +
+ Mon Jun 13 23:21:39 CEST 2011 +

+
+ +
Le 13/06/2011 23:20, Dexter Morgan a écrit :
+> already exist in mageia in ruby-rake
+oops, why name it ruby-rake?
+
+-- 
+Sandro Cazzaniga - https://lederniercoupdarchet.wordpress.com
+IRC: Kharec (irc.freenode.net)
+Software/Hardware geek
+Conceptor
+Magnum's Coordinator/editor (http://wiki.mandriva.com/fr/Magnum)
+Mageia and Mandriva contributor
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005556.html b/zarb-ml/mageia-dev/2011-June/005556.html new file mode 100644 index 000000000..e43babf57 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005556.html @@ -0,0 +1,237 @@ + + + + [Mageia-dev] [105941] imported package rake + + + + + + + + + +

[Mageia-dev] [105941] imported package rake

+ Dexter Morgan + dmorganec at gmail.com +
+ Mon Jun 13 23:26:40 CEST 2011 +

+
+ +
On Mon, Jun 13, 2011 at 11:21 PM, Cazzaniga Sandro
+<cazzaniga.sandro at gmail.com> wrote:
+> Le 13/06/2011 23:20, Dexter Morgan a écrit :
+>> already exist in mageia in ruby-rake
+> oops, why name it ruby-rake?
+
+for policy reason, like python and perl packages
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005557.html b/zarb-ml/mageia-dev/2011-June/005557.html new file mode 100644 index 000000000..32df1a5ba --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005557.html @@ -0,0 +1,179 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Renaud MICHEL + r.h.michel+mageia at gmail.com +
+ Mon Jun 13 23:28:04 CEST 2011 +

+
+ +
On lundi 13 juin 2011 at 23:06, Thorsten van Lil wrote :
+> A rolling release has following advantages:
+> 1. the distribution is always up to date (also hardware support) 
+> 2. no re-install over and over again
+
+I don't get it why people think a re-install is necessary.
+My current computer was installed with mandriva 2007 (don't remember if it 
+was .0 or .1), it is now mageia 1 and has been updated to all intermediary 
+mdv releases.
+Another was not actually installed, an older was installed with mandrake 8.2 
+(yes, that is as old as 2002), was updated to each subsequent release, was 
+copied on a new computer (create partitions, copy, reinstall grub in MBR, 
+check graphic driver, and it worked), it is now running mandriva 2010.2 
+(mageia to come) without being reinstalled since.
+
+> Some users also wants the a mix of both (also called a light rolling
+> release)  and combine the advantages as far as possible.
+> This could look like this:
+> Bring up a release once a year. The core (kernel, glib, ...) will only
+> get  minor updates. Apllications like firefox, libreoffice, ... will
+> always be up to date (rolling). Maybe also the desktop envirenments
+> could be rolling but this is very heavy.
+
+If I understood correctly, that is exactly what the backports should 
+provide, new versions of programs when possible (no update of half of the 
+core system libraries).
+
+cheers
+-- 
+Renaud Michel
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005558.html b/zarb-ml/mageia-dev/2011-June/005558.html new file mode 100644 index 000000000..72741191a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005558.html @@ -0,0 +1,246 @@ + + + + [Mageia-dev] [105941] imported package rake + + + + + + + + + +

[Mageia-dev] [105941] imported package rake

+ Cazzaniga Sandro + cazzaniga.sandro at gmail.com +
+ Mon Jun 13 23:28:20 CEST 2011 +

+
+ +
Le 13/06/2011 23:26, Dexter Morgan a écrit :
+> On Mon, Jun 13, 2011 at 11:21 PM, Cazzaniga Sandro
+> <cazzaniga.sandro at gmail.com> wrote:
+>> Le 13/06/2011 23:20, Dexter Morgan a écrit :
+>>> already exist in mageia in ruby-rake
+>> oops, why name it ruby-rake?
+> 
+> for policy reason, like python and perl packages
+thanks for your help.
+
+-- 
+Sandro Cazzaniga - https://lederniercoupdarchet.wordpress.com
+IRC: Kharec (irc.freenode.net)
+Software/Hardware geek
+Conceptor
+Magnum's Coordinator/editor (http://wiki.mandriva.com/fr/Magnum)
+Mageia and Mandriva contributor
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005559.html b/zarb-ml/mageia-dev/2011-June/005559.html new file mode 100644 index 000000000..80166942f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005559.html @@ -0,0 +1,232 @@ + + + + [Mageia-dev] GNOME3 ? + + + + + + + + + +

[Mageia-dev] GNOME3 ?

+ Frank Griffin + ftg at roadrunner.com +
+ Mon Jun 13 23:33:20 CEST 2011 +

+
+ +
On 06/13/2011 04:12 PM, Frank Griffin wrote:
+> On 06/13/2011 04:05 PM, Dexter Morgan wrote:
+>> nice i fix this one
+>
+>
+> The reason I ask is that on an ID previously using GNOME 2.32, the 
+> desktop comes up, but launching any application drives the video 
+> crazy.  You can see the app window some of the time, but after a 
+> second or two of video flashing you get a fullscreen  "Oops" panel and 
+> are told to log out.  On a fresh ID, you can't even get the desktop to 
+> come up - you get the blue background, the mouse pointer circles for a 
+> bit and then stops, with no error and no recourse but CTRL-ALT-BKSP.
+>
+
+Ahh.  Correction with the latest updates: now the ID previously using 
+GNOME 2.32 doesn't get past the blue background either.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005560.html b/zarb-ml/mageia-dev/2011-June/005560.html new file mode 100644 index 000000000..20beed552 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005560.html @@ -0,0 +1,176 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Mon Jun 13 23:44:01 CEST 2011 +

+
+ +
'Twas brillig, and lebarhon at 13/06/11 20:18 did gyre and gimble:
+> BTW : I think mailing list are totally outdated and that mageia should
+> have a special section in this forum for these discussion, or maybe
+> another forum.
+> It's totally impossible for people who want to participate sometimes to
+> follow you emails everydays. It's much faster to read some topic on a
+> forum than dozens emails. And your final user should be able to know
+> what happen easily. It would be a big + in front of others distributions.
+
+This is offtopic here. I completely disagree, incidentally. I need to
+read about 30 or 40 different community lists. It's *much* quicker for
+me to have a standard UI and a standard way of operating and a standard
+look and feel.
+
+Each project having a separate forum, with separate logins, with
+separate style and separate features etc. makes for a very hard and time
+consuming reading experience. There is a similar argument for why HTML
+messages are bad too (consistent style makes everyone's life easier). So
+forums are only really good if you only follow a couple of projects or
+only follow projects fairly superficially. Mailing lists are better for
+the rest of us who are have to follow more projects.
+
+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-June/005561.html b/zarb-ml/mageia-dev/2011-June/005561.html new file mode 100644 index 000000000..447e862e9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005561.html @@ -0,0 +1,238 @@ + + + + [Mageia-dev] [RPM] cauldron core/release iceape-2.1-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release iceape-2.1-1.mga2

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Mon Jun 13 23:51:34 CEST 2011 +

+
+ +
On Mon, 13 Jun 2011, Dick Gevers wrote:
+
+> On Mon, 13 Jun 2011 15:10:47 +0200 (CEST), Mageia Team wrote about [RPM]
+> cauldron core/release iceape-2.1-1.mga2:
+
+> The personal toolbar contains five Mandriva links.
+
+Not here, can you check
+  /usr/lib*/iceape-2.1/defaults/profile/bookmarks.html
+? But that can't really be it so this should be in your personal profile.
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005562.html b/zarb-ml/mageia-dev/2011-June/005562.html new file mode 100644 index 000000000..da4be9bff --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005562.html @@ -0,0 +1,181 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ David W. Hodgins + davidwhodgins at gmail.com +
+ Tue Jun 14 00:08:56 CEST 2011 +

+
+ +
On Mon, 13 Jun 2011 17:28:04 -0400, Renaud MICHEL <r.h.michel+mageia at gmail.com> wrote:
+
+> On lundi 13 juin 2011 at 23:06, Thorsten van Lil wrote :
+>> A rolling release has following advantages:
+>> 1. the distribution is always up to date (also hardware support)
+>> 2. no re-install over and over again
+>
+> I don't get it why people think a re-install is necessary.
+> My current computer was installed with mandriva 2007 (don't remember if it
+> was .0 or .1), it is now mageia 1 and has been updated to all intermediary
+> mdv releases.
+
+My currently running install started as Mdv 2009.1, updated via urpmi to
+2010.2, then converted to Mageia cauldron during beta 1.
+
+With a little over 4400 packages, the upgrade from one release to the next
+takes over 8 hours, on this single core Celeron processor, so even though
+it's not an actual re-install, it still feels like one. /usr alone is 13GB.
+
+One possibly annoying part about that, is that there are many rpm packages
+where the only obvious change is the version.  I understand that for many
+of the packages, they have to be rebuilt due to perl/python/glib version
+changes, but anyone who doesn't know that will see what seems like a lot
+of unneeded updates.
+
+One con of a rolling release has been demonstrated by Cauldron over the last
+few days.  With the perl/gnome updates, it takes a few days for all of the
+needed packages to get built.  For a couple of days, running urpmi with
+--auto-select wanted to remove most of gnome.  I waited till the needed
+packages were available, whereas a less technical user may have ended up
+removing key parts of their desktop manager.
+
+Regards, Dave Hodgins
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005563.html b/zarb-ml/mageia-dev/2011-June/005563.html new file mode 100644 index 000000000..61c5cea99 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005563.html @@ -0,0 +1,160 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Barry Jackson + zen25000 at zen.co.uk +
+ Tue Jun 14 00:17:46 CEST 2011 +

+
+ +
On 13/06/11 15:46, Anssi Hannula wrote:
+>
+> It could do both :)
+> Doesn't really matter, this is all extra anyway.
+>
+> Note that if you make it download it, you could also implement:
+> a) make it print md5sum automatically
+
+Done that in the attached. It writes it to skype-<version>.md5 in /SOURCES
+
+> b) make it print the dependencies automatically
+> (see e.g. the earlier google earth script which does those IIRC)
+>
+
+Not yet implemented this.
+
+> But as said, all of this is extra. Maybe the priority should be getting
+> you a mentor.
+>
+
+Yes that would be really good.
+
+>> A first draft of this is attached.
+>> I assume this would ultimately be added as a SOURCE file with notes in
+>> the package.
+>
+> Yep.
+>
+
+Done. It's all included in the src package.
+
+So, anyone willing to mentor me and get this package on the road ?  ;)
+
+Barry
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: get-skype.tar.gz
+Type: application/gzip
+Size: 9483 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20110613/5adac570/attachment.bin>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005564.html b/zarb-ml/mageia-dev/2011-June/005564.html new file mode 100644 index 000000000..aeec4233b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005564.html @@ -0,0 +1,250 @@ + + + + [Mageia-dev] GNOME3 ? + + + + + + + + + +

[Mageia-dev] GNOME3 ?

+ JA Magallón + jamagallon at ono.com +
+ Tue Jun 14 00:45:24 CEST 2011 +

+
+ +
On Mon, 13 Jun 2011 17:33:20 -0400, Frank Griffin <ftg at roadrunner.com> wrote:
+
+> On 06/13/2011 04:12 PM, Frank Griffin wrote:
+> > On 06/13/2011 04:05 PM, Dexter Morgan wrote:
+> >> nice i fix this one
+> >
+> >
+> > The reason I ask is that on an ID previously using GNOME 2.32, the 
+> > desktop comes up, but launching any application drives the video 
+> > crazy.  You can see the app window some of the time, but after a 
+> > second or two of video flashing you get a fullscreen  "Oops" panel and 
+> > are told to log out.  On a fresh ID, you can't even get the desktop to 
+> > come up - you get the blue background, the mouse pointer circles for a 
+> > bit and then stops, with no error and no recourse but CTRL-ALT-BKSP.
+> >
+> 
+> Ahh.  Correction with the latest updates: now the ID previously using 
+> GNOME 2.32 doesn't get past the blue background either.
+
+Two kind of problems:
+- dependecies: make sure you have 'gtk+3.0' and 'gnome-themes-standard'
+  (latest will pick some themes and fonts...) You should see a striped
+  blue bg after login.
+- in my case I get kicked off because gnome-settings-daemon hangs on
+  libnsl (from glibc). I am thinkin on how to debug it (how to launch
+  g-s-d on a gdb shell and dump the output somewhere...)
+
+Check if you have something like this in your dmesg:
+
+gnome-settings-[2556]: segfault at 7fb8612fb1d0 ip 00007fb8612fb1d0 sp 00007fff830282d8 error 14 in libnsl-2.12.1.so[7fb8639dc000+15000]
+gnome-settings-[3257]: segfault at 7fae815011d0 ip 00007fae815011d0 sp 00007fff72cc8b58 error 14 in libnsl-2.12.1.so[7fae83be2000+15000]
+gnome-settings-[3723]: segfault at 7f42989871d0 ip 00007f42989871d0 sp 00007fffa8d55858 error 14 in libnsl-2.12.1.so[7f429b068000+15000]
+
+If yes, at least I'm not the only one :).
+
+-- 
+J.A. Magallon <jamagallon()ono!com>     \                 Winter is coming...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005565.html b/zarb-ml/mageia-dev/2011-June/005565.html new file mode 100644 index 000000000..8fb0d49a5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005565.html @@ -0,0 +1,286 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Michael Scherer + misc at zarb.org +
+ Tue Jun 14 00:50:48 CEST 2011 +

+
+ +
Le lundi 13 juin 2011 à 14:58 +0200, Samuel Verschelde a écrit :
+> Le dimanche 12 juin 2011 22:46:33, Michael Scherer a écrit :
+> > Hi,
+> > 
+> > so , with a little bit delay due to various things ( like everybody
+> > asking stuff to us on irc on a hourly fashion ( people will I hope
+> > recognize themselves )), Anne and I have reviewed the various proposals
+> > made through years during the early period of the distribution, and
+> > before at Mandriva. We took in account the feedback of people on forum,
+> > on ml, nd those we have seen during events. We also discussed with
+> > others distributions developers we know from Opensuse, Fedora, Debian,
+> > Ubuntu about their release cycle, the choices they made and their
+> > reasons.
+> 
+> A restitution to us of this overview of the other distros release cycles and 
+> their choices, reasons, pros and cons would have been great, but I guess it 
+> would have required much more time to write it.
+
+Given that time is already lacking, yes.
+
+But basically, Fedora use 6 months because they want to release often
+( Features, First ), according to Mathieu Bridon. That's also why they
+have a very agressive update policy ( which caused some issues like
+xorg/nvidia breakage, firefox breakage, thunderbird problem ). They do
+also have lots of upstream developers paid by RH, who prefer to have
+this model to be able to have fast feedback on their software
+( especially since almost no one run Rawhide, the equivalent of Cauldron
+)
+
+Discussing with Didier Roche, Ubuntu does this because they wanted to
+release with gnome, every 6 months. There was discussion 1 year ago
+about keeping a minimal distribution ( plateform model ) but it seems it
+didn't happened yet. He also confirmed that the pace was quite intense,
+letting them push lots of features they develop ( unity, etc ).
+
+According to Vincent Untz, Opensuse moved from 6 months to 8 months
+because they feel that 6 months was too much, too frequent. The only
+problem is that 1 cycle about 3, they run older software ( like Gnome ),
+but that's not a big problem. 
+
+I forgot the Debian stuff, but basically, their release model is a 3
+tiered one ( testing, unstable, experimental ), with experimental is
+were stuff that can break are uploaded, uploading almost everything,
+unstable unstable
+
+For obvious reason, everybody is happy of their choices :)
+
+>  It would have helped 
+> understand why the final decision
+
+If this as a final decision, I would not explain and ask to people their
+opinion. 
+
+>  you took was to keep the current model (not 
+> counting the discussion about cycle duration and LTS). I'm not saying that I 
+> want "rolling release", but beginning the discussion without saying much 
+> concerning what has been a big discussion some months ago (and still is in the 
+> forum) feels a bit weird to me. Especially when we kept telling people "wait, 
+> we will have time to discuss it after Release 1".
+
+Well, as I said, we didn't consider the "no release" option. After
+looking the document you wrote
+( http://mageiacauldron.tuxfamily.org/MageiaReleaseCycle ), the option
+"no release" ( I ) was deemed as not realistic, and so was also our
+opinion. 
+
+Now, we also took in account the summary and all others were a
+combination of release policy, backports policy, and update policy.
+Basically, on the release side, it was 1y or 6m, and we have seen that
+everybody was only considering theses 2 propositions, hence the proposal
+for 9 months ( partially inspired by the suse one ). 
+
+Something that was also apparent in your summary was the need to
+backports lots of things on all proposals, the only difference being if
+kernel/xorg would be backported or not depending on the release
+frequency. 
+
+So after reading this, my conclusion on that was that the release model
+would not change much on that part, since basically, either there is a
+release often, or your proposal would be to backports lots of things. So
+discussing release frequency only would be enough, since the other half
+of the discussion is dependent on this one.
+
+Or, as a mathematician would say : 
+backport_level(R) = stormi_constant / release_frequency(R) 
+
+( please not that you are now half as famous as Planck, Faraday and
+Boltzmann since there is a constant named after you, the other half is
+having a institute named after you )
+
+> > To simplify the discussion, the proposals are all based on the fact that
+> > 2 or 3 releases could be supported at a time. We could have different
+> > schemes for that ( LTS every X release ( ubuntu ), different level of
+> > support ( mandriva )), but as this is a slightly different discussion,
+> > let's assume 2 supported releases for now, and let's discuss later for
+> > that ( ie next week, once this one is finished )
+> 
+> I can understand the reason for separating the discussions (simplification), 
+> but it's hard to give a final opinion concerning the release cycle without 
+> knowing whether there will be a LTS or not, when you care about the life cycle 
+> duration. The backports policy also has a great impact to the matter : if we 
+> manage to make using newer versions of popular software easy without much risk 
+> nor obligatory need to upgrade, extending the release cycle is easier (I could 
+> go with 12 months provided we find a way to improve hardware support as part of 
+> the maintenance).
+
+As I said, having read your proposals, the only difference was backport
+or not, and the previous discussion about release showed that changing
+several parameter at the same time would lead to a complexity
+explosion :
+- with or without lts,
+  -> for lts, how long, and how often 
+that's already likely 5 propositions per itself
+
+- 6, 9, 12, or 8, 10 months, or variable ( like 6 one time, 12 another
+time ). We can surely have 7 propositions for that ( taking the "no
+release option" ).
+
+Updates policy could be : 
+- 1 release, 2 release, 3 releases, 4 releases
+- full, not full ( ie like Mandriva ), different for LTS 
+
+Let's assume 8 different variations.
+
+So, in total, discussing everything at the same time, this would be :
+8 * 5 * 7 = 280 combinations.
+
+Now, let's add a backport policy. We can have backport lots of thing,
+backport nothing, backport some stuff, and I think we can safely speak
+of 4 or 5 different policies.
+
+So that's between 1280 and 1400 possibilities. 
+
+If we assume that 90% of the propositions are bogus ( which is far from
+the reality, that's IMHO quite the contrary ), that's still 100
+possibility to discuss, and even with a so extreme and dictatorial
+removal, that's not manageable.
+
+So no, after doing the math, discussing everything at once is not
+doable. 
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005566.html b/zarb-ml/mageia-dev/2011-June/005566.html new file mode 100644 index 000000000..12f418421 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005566.html @@ -0,0 +1,185 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Tue Jun 14 01:02:20 CEST 2011 +

+
+ +
Op dinsdag 14 juni 2011 00:08:56 schreef David W. Hodgins:
+> On Mon, 13 Jun 2011 17:28:04 -0400, Renaud MICHEL 
+<r.h.michel+mageia at gmail.com> wrote:
+> > On lundi 13 juin 2011 at 23:06, Thorsten van Lil wrote :
+> >> A rolling release has following advantages:
+> >> 1. the distribution is always up to date (also hardware support)
+> >> 2. no re-install over and over again
+> > 
+> > I don't get it why people think a re-install is necessary.
+> > My current computer was installed with mandriva 2007 (don't remember if
+> > it was .0 or .1), it is now mageia 1 and has been updated to all
+> > intermediary mdv releases.
+> 
+> My currently running install started as Mdv 2009.1, updated via urpmi to
+> 2010.2, then converted to Mageia cauldron during beta 1.
+> 
+> With a little over 4400 packages, the upgrade from one release to the next
+> takes over 8 hours, on this single core Celeron processor, so even though
+> it's not an actual re-install, it still feels like one. /usr alone is 13GB.
+
+I have a similar machine, but updated through the applet, which means it only 
+takes about 1hour and you can work in the main time and reboot when you want. 
+i don't understand why users would be expressly wanting rolling release when 
+you don't need to reinstall, or "upgrade" in a traditional sense at all...
+
+> One possibly annoying part about that, is that there are many rpm packages
+> where the only obvious change is the version.  I understand that for many
+> of the packages, they have to be rebuilt due to perl/python/glib version
+> changes, but anyone who doesn't know that will see what seems like a lot
+> of unneeded updates.
+> 
+> One con of a rolling release has been demonstrated by Cauldron over the
+> last few days.  With the perl/gnome updates, it takes a few days for all
+> of the needed packages to get built.  For a couple of days, running urpmi
+> with --auto-select wanted to remove most of gnome.  I waited till the
+> needed packages were available, whereas a less technical user may have
+> ended up removing key parts of their desktop manager.
+> 
+> Regards, Dave Hodgins
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005567.html b/zarb-ml/mageia-dev/2011-June/005567.html new file mode 100644 index 000000000..b5543cc54 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005567.html @@ -0,0 +1,173 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Michael Scherer + misc at zarb.org +
+ Tue Jun 14 01:02:51 CEST 2011 +

+
+ +
Le lundi 13 juin 2011 à 15:51 +0300, Thomas Backlund a écrit :
+> Wolfgang Bornath skrev 13.6.2011 15:20:
+> > About the cycles:
+> >
+> > The 9-months seem to be a compromise - but I start to ask why we need
+> > such a fixed statement (which it would be, once published). We need a
+> > schedule for each cycle, that's true. Without a schedule we would
+> > never finish anything. But how about taking 9 months only as a "nice
+> > to meet" target, leaving us the option to set a roadmap after setting
+> > the specs of the next release - we could then go for a 8 or 10 months
+> > roadmap, depending on the specs.
+> >
+> 
+> This is somewhat like what I had in my mind to write too, but you beat 
+> me to it :)
+> 
+> It could allow us to adapt a little for upstream releases.
+> But should we then decide that the limit is +/- 1 month ?
+
+There is 2 problem :
+- for release of what software ?
+- what if the upstream planning is wrong, and their releases is late
+( as it happened when I was a trainee in Mandrakesoft, with xfree being
+3 months late and the distribution still shipping a broken pre release )
+
+
+> Obviously there will still be people complaining that "you waited 10 
+> months... if you had extended with ~2 more weeks... "this" or "that"
+> package would have been available too... and so on....
+
+Yes, there will be. 
+So let's be realist, 9 months with +/- 1 month is just 10 months +
+people complaining to have 10,5 months.
+
+We will never use the -1 month, because there will always be something
+worth waiting.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005568.html b/zarb-ml/mageia-dev/2011-June/005568.html new file mode 100644 index 000000000..9d2faf178 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005568.html @@ -0,0 +1,188 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Michael Scherer + misc at zarb.org +
+ Tue Jun 14 01:31:46 CEST 2011 +

+
+ +
Le lundi 13 juin 2011 à 14:20 +0200, Wolfgang Bornath a écrit :
+
+> The 9-months seem to be a compromise - but I start to ask why we need
+> such a fixed statement (which it would be, once published). We need a
+> schedule for each cycle, that's true. Without a schedule we would
+> never finish anything. But how about taking 9 months only as a "nice
+> to meet" target, leaving us the option to set a roadmap after setting
+> the specs of the next release - we could then go for a 8 or 10 months
+> roadmap, depending on the specs.
+
+As I said to Thomas, we will never use the 8 months option. If we say
+"we have selected less features to finish sooner", people will just ask
+for more features, and will say "why do you want to finish sooner, I
+prefer to have feature and wait 1 month more". 
+
+In fact, the same would go for 9 to 10 if we start to propose the
+possibility. 
+
+And deciding that we will decide later is not really deciding. We should
+select features based on time needed to implement them and how much time
+we can devote, not the contrary especially since no one will ever be
+able to give precise timing for anything, so one month of difference
+would be difficult to justify.  
+
+And I think we can already decide to release 1 week later if a
+release_critical bug appears. Fedora 15 for example was 2 weeks late,
+because they changed the release date twice after having seen some
+problem (http://fedoraproject.org/wiki/Releases/15/Schedule ).
+
+And we did it more than once at Mandriva.
+
+> This being said, I am a friend of a rolling release like ArchLinux,
+> but I fear that our main target group is not up to this. Despite of
+> having to "burn yet another DVD" as somebody pointed out, the majority
+> seems to see this as normal and a good way. Of course I may be totally
+> wrong with this assessment!
+
+Maybe people should maybe start to trust more mgaonline to do upgrade,
+there is nothing that pacman does that urpmi don't regarding upgrade,
+there is no magic involved : 
+- people should test before the release and fill bug reports.
+
+That's the secret behind debian upgrade, people just do lots of tests
+for that either automated ( using something like piupart
+( http://wiki.debian.org/piuparts ) ), or manual and lots of people do
+full system upgrade long before the release ( and not only after ).
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005569.html b/zarb-ml/mageia-dev/2011-June/005569.html new file mode 100644 index 000000000..779a27846 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005569.html @@ -0,0 +1,236 @@ + + + + [Mageia-dev] [RPM] cauldron core/release iceape-2.1-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release iceape-2.1-1.mga2

+ Dick Gevers + dvgevers at xs4all.nl +
+ Tue Jun 14 01:52:11 CEST 2011 +

+
+ +
On Mon, 13 Jun 2011 23:51:34 +0200 (CEST), Christiaan Welvaart wrote about
+Re: [Mageia-dev] [RPM] cauldron core/release iceape-2.1-1.mga2:
+
+>> The personal toolbar contains five Mandriva links.
+>
+>Not here, can you check
+>  /usr/lib*/iceape-2.1/defaults/profile/bookmarks.html
+>? But that can't really be it so this should be in your personal profile.
+>
+>
+>     Christiaan
+
+Yes now it is okay, but there was also /usr/lib64/iceape-2.0.14/ 
+leftover which I just removed. 
+
+I'm sure it must have been stg local then: so sorry for the noise.
+
+m.v.g.
+=Dick Gevers=
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005570.html b/zarb-ml/mageia-dev/2011-June/005570.html new file mode 100644 index 000000000..f8f8fb762 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005570.html @@ -0,0 +1,186 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Sam Bailey + cyprix at cyprix.com.au +
+ Tue Jun 14 01:50:12 CEST 2011 +

+
+ +
+
+ On Mon, 13 Jun 2011 10:37:25 -0500 (CDT), Dale Huckeby wrote:
+
+> +1
+>
+> The consensus so far seems to be:
+>
+> 6 months is too short
+> 12 months is too long
+> 9 months is juuuuust about right
+>
+> and that applies not only to developers having a chance to catch 
+> their
+> breath between versions, but
+> users too. A 6-month turnaround feels like I'm constantly updating, 
+> but a
+> 12-month wait between
+> versions is like forever. And as wobo suggests, 9 months need be only 
+> an
+> average, with a target date
+> for the next release, taking into account upstream developments, 
+> decided
+> on after each one. Also,
+> the target date should be approximate at first and firmed up only as 
+> we
+> get closer to release.
+>
+> spock
+
+ +1
+
+ 9 months seems to create a nice stable base - with enough time to add 
+ new
+ developments and breathe between releases (along with kernel updates 
+ for
+ new kit).
+
+ My suggestion is that for those who want faster access to new versions 
+ of
+ apps will be able to create a larger focus on backports for large and
+ common apps (from cauldron) without taking the focus away from the 9mth
+ release cycle.
+
+ This slightly extra use of backports may also help with the LTS 
+ proposals.
+
+-- 
+ Sam Bailey
+ (cyprix)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005571.html b/zarb-ml/mageia-dev/2011-June/005571.html new file mode 100644 index 000000000..9445ca69d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005571.html @@ -0,0 +1,168 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Bruno Cornec + Bruno.Cornec at hp.com +
+ Tue Jun 14 02:36:59 CEST 2011 +

+
+ +
Michael Scherer said on Tue, Jun 14, 2011 at 01:31:46AM +0200:
+
+> And I think we can already decide to release 1 week later if a
+> release_critical bug appears. Fedora 15 for example was 2 weeks late,
+> because they changed the release date twice after having seen some
+> problem (http://fedoraproject.org/wiki/Releases/15/Schedule ).
+
+I think that the level of flexibility that is really useful. Fixing a
+target is nice for all projects. Now, if a blocking point happens, it's
+wise to delay a bit.
+
+I personaly find ridiculous the Ubuntu approach to release at fixed
+dates, whatever happens, becasue it's 11.04, it should be in April 2011
+!! But then their community is just angry because of the lack of
+quality due to that.
+
+So maybe what would be interesting is to have something like:
+M1-M8: break and fix cauldron with lots of new stuff.
+M8-M8.5: freeze period. Only bug fixes or HW support improvements goes 
+through or mageia tools. In particular, no new KDE, Gnome, LibreO, FF, 
+...
+M8.5-M9: test period. Only bugs found there are fixed. As the cauldron
+is closed, people have more time to upgrage with an already stabilized
+distro, to make it really stable at the 9 months date.
+
+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-June/005572.html b/zarb-ml/mageia-dev/2011-June/005572.html new file mode 100644 index 000000000..d71e01fb3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005572.html @@ -0,0 +1,388 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Michael Scherer + misc at zarb.org +
+ Tue Jun 14 02:52:17 CEST 2011 +

+
+ +
Le lundi 13 juin 2011 à 05:04 -0700, Ron a écrit :
+> > There is a limited set of options, and as you can see, none of your 
+> > idea was not already explored by someone else.
+> It has all been done before, in that sense let's just close up shop and call it a day???
+
+Your first argument was "we should not do release, that's what all
+others do". I just explained that not doing release is not a new idea.
+
+And maybe I misunderstood your ideas, but if the mere fact that we are
+not alone on a segment is a reason to leave it because we cannot
+compete, then since by your own word, Arch is doing well, why should we
+try to compete too ?
+ 
+In fact, instead of telling what Arch does well, maybe you could start
+to say where Arch is not doing well, and how you propose to do things to
+do better if you want to convince there is room for another distribution
+and room for improvement.
+
+Because if Arch is already fulfilling all your needs, I fail to see what
+to do. So the first step would be to explain what Arch is not doing
+right if you hope to convince us we can do better.
+
+
+> > If everything move all days, you cannot :
+> > - translate software ( as the string will change every day )
+> > - create documentation ( for the same reason )
+> > - communicate ( as everything ca be broken at any time )
+> > - ensure stability ( as each change can bring unstability )
+> 
+> > And for user, some do not want to redo training every week for 
+> > their users, because libreoffice got updated, because ff 4 just arrived 
+> > and 75% of extensions do not work, etc. 
+> >
+> > In fact, the whole release model is basically what is used all >over the
+> > place, from lower level like kernel to higher level like kde. So >you can
+> > get lots of feedback on it.
+> You are correct on the release model being used everywhere, that fit's development 
+> and really there is no other way to do it as it takes time. 
+> But really, up stream does have to take time but package maintainers can pull things in pretty fast 
+> and make things work.
+
+Being myself a packager, and being a packager since a long time ( like 7
+years ), I feel that I have to disagree. While there isn't much breakage
+on packaging side, we also suffer from bugs like upstream developers
+does, mainly because we use the same software as them. We also develop
+our own software ( like the installer, drakxtools, etc ). We also do
+work on integration, etc.
+
+And I am a little bit disappointed to learn that my work as a packager
+do not take time. I must maybe do it wrong, as it seems to be a real
+work.
+
+> I don't understand what's being said here? Are we a community of users 
+> or are we just teachers teaching a class? Help with changes is what 
+> forums and people are for. 
+
+If people want changes, they either do it themselves, or they wait on
+someone else to do. And waiting for someone else to do mean to convince
+that someone. And that someone is everybody reading you on the list,
+which also mean me.  
+
+Wanting changes has never been sufficient for making them appear. We
+wanted to have a change regarding Mandriva, we made it.
+
+> You worried about not being able to keep up with documentation? 
+> I suggest you take a look at the Arch wiki, best Linux wiki 
+> there is and things change fast... Again, community...
+
+Then I would answer "just look at the ubuntu wiki" to see that the
+quality of a wiki is not related to the release model of a
+distribution. 
+
+And when I say documentation, I was speaking of something like :
+http://doc.mandriva.com/index.php 
+or like this :
+http://docs.fedoraproject.org/en-US/Fedora/15/html/Installation_Guide/index.html
+
+And so, since you didn't answer to the others points I made, shall I
+assume they are valid concerns ? 
+
+> > So basically, you suggest that since everybody is already doing 
+> > it, this is useless. So the logical conclusion is we should drop 
+> > the distribution ?
+> No that is not what I'm saying!
+>
+> What I am saying is that you have 100+/- distributions all going by a 
+> release model and only a handful making rolling releases. 
+
+A majority of distributions developers have independently decided to use
+a release model, so it is obviously something that is fulfilling their
+needs as well as the need of a majority of users, no ?
+
+
+> There is only one defacto maker of a rolling release and that is Arch, 
+> why does this have to be? (Yes I know there are others but Arch is the 
+> leader of the pack)
+
+Technically, there is Gentoo, and derived distribution  or Debian
+Testing, and I know more people running Gentoo and Debian than Arch
+users. I would even say that the *BSD and Slackware are a form of
+rolling release, since they have a fixed small base system updated from
+time to time, and a evolving upper level with updated software and
+others stuff. 
+
+In fact, if we look at the market share, the dominant unix system with a
+rolling release model would be mac os X. 
+
+( but I guess that you disagree with the fact that *BSD are a rolling
+release, which is yet another reason to use a different and more clearer
+term ).
+
+> >like debian testing ( and CUT ) ? suse tumbleweed ? arch linux
+> Nope, gotta call you on this... Debian testing rolls with the purpose of becoming a release... 
+> Therefore things can grow outdated rather quickly. 
+
+Well, that's still rolling none the less. But as I said several time for
+the previous discussion, rolling release is a term that people used to
+designate different things. 
+
+If things are too old, this is not rolling release ?
+And if things are too broken, this is not rolling release either ? 
+
+
+> Suse tumblweed IS NOT going to be a true rolling release! It is going to "tumble up" to the 
+> next release hence the name.
+
+That's not exactly what they say on their wiki page : 
+http://fr.opensuse.org/Portal:Tumbleweed
+But maybe I didn't understood that, and maybe they didn't explained to
+me when I asked the question 4 months ago.
+
+> > Very stable for a distribution mean "that do not change". That's
+> > incompatible with the idea of rolling per definition. And inorder 
+> > to have stable software, you have to freeze them and fix bugs. So 
+> > to have that on the whole distribution, you need to freeze the 
+> > whole distribution for a time, and then ask for test, fix bugs 
+> > and then release. Which is exactly what we currently do since >years.
+> Sorry, your wrong! I have been using Arch for years and have yet 
+> to meet a show stopper bug, it is very stable. 
+> Stability simply means tested! 
+
+When Debian people speak of the stable distribution, they mean it
+doesn't change much. When Mandriva speak of the stable distribution,
+they mean it doesn't change much. When we us that word for the
+distribution, we mean the same. 
+
+You use it differently, that's fine. But you cannot expect to be
+understood if you use a different vocabulary than the people you are
+talking with, unless you ask us to change our vocabulary to fit yours.
+
+> It does not have to be like Debian testing 
+> that grows stale with time, you can remain very very close to bleeding 
+> edge and still remain stable...
+
+Debian testing is what you would call stable because the way it is
+updated ( ie, no broken dependencies, no blocking bugs, waiting time
+before updating ). 
+
+> > So basically, you just reinvented the concept of release, and the 
+> > way Mandriva, Debian, Fedora work since years. 
+> And I must have peed in your cheerios... 
+
+I think there is no need to be vulgar.
+
+> I am all for giving people what they want, 
+> I also don't think you have to follow the status quo to do so... We don't have 
+> to be "just another distribution doing the same things the others are doing"... 
+> Sorry, but this is what I see....
+
+Then I guess we do not see that way, but I guess also that being myself
+involved in depth in the distribution and having participated since
+years to Mandriva and having looked at others ( as said in the
+introduction of my first mail ), I see details that you do not see
+( such as the governance, the openness of various others areas besides
+packaging, etc ).
+
+Now, you whole mail is "we should do like arch", and that's a motivation
+that I do not understand. What do you expect us to bring that arch does
+not bring for you ? What would be the added value ?
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005573.html b/zarb-ml/mageia-dev/2011-June/005573.html new file mode 100644 index 000000000..22a241f3d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005573.html @@ -0,0 +1,179 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Michael Scherer + misc at zarb.org +
+ Tue Jun 14 03:05:46 CEST 2011 +

+
+ +
Le mardi 14 juin 2011 à 02:36 +0200, Bruno Cornec a écrit :
+> Michael Scherer said on Tue, Jun 14, 2011 at 01:31:46AM +0200:
+> 
+> > And I think we can already decide to release 1 week later if a
+> > release_critical bug appears. Fedora 15 for example was 2 weeks late,
+> > because they changed the release date twice after having seen some
+> > problem (http://fedoraproject.org/wiki/Releases/15/Schedule ).
+> 
+> I think that the level of flexibility that is really useful. Fixing a
+> target is nice for all projects. Now, if a blocking point happens, it's
+> wise to delay a bit.
+> 
+> I personaly find ridiculous the Ubuntu approach to release at fixed
+> dates, whatever happens, becasue it's 11.04, it should be in April 2011
+> !! But then their community is just angry because of the lack of
+> quality due to that.
+
+They did a push of 2 months in 2006 ( 6.06 instead of 6.04 for Dapper
+Drake ). But I think that was a isolated change, and Mark Shuttleworth
+is pushing for keeping schedule. We were praised because we were not
+late too :)
+
+> So maybe what would be interesting is to have something like:
+> M1-M8: break and fix cauldron with lots of new stuff.
+> M8-M8.5: freeze period. Only bug fixes or HW support improvements goes 
+> through or mageia tools. In particular, no new KDE, Gnome, LibreO, FF, 
+> ...
+> M8.5-M9: test period. Only bugs found there are fixed. As the cauldron
+> is closed, people have more time to upgrage with an already stabilized
+> distro, to make it really stable at the 9 months date.
+
+Well, that's the plan, with the release date come then the decision
+about the freeze period, even if we got mixed signals here :
+- we want longer freeze because that mean less bugs
+- we also see that people always want to have freeze exception because
+bugfixing is less fun that adding feature :)
+
+So that warrant also another discussion ( even if I think the current
+division is fine, but it could be adapted if the release model is
+different ).
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005574.html b/zarb-ml/mageia-dev/2011-June/005574.html new file mode 100644 index 000000000..c3e0b8011 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005574.html @@ -0,0 +1,124 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Michael Scherer + misc at zarb.org +
+ Tue Jun 14 03:08:24 CEST 2011 +

+
+ +
Le lundi 13 juin 2011 à 14:20 +0200, Angelo Naselli a écrit :
+> lunedì 13 giugno 2011 alle 13:13, Oliver Burger ha scritto:
+> > Have you also installed rpmlint-mageia-policy?
+> Shouldn't it be at least suggested?
+
+I would prefer to find a better way than suggest :/
+( like a meta rpm pulling mgarepo, bm, the policy and rpmlint ).
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005575.html b/zarb-ml/mageia-dev/2011-June/005575.html new file mode 100644 index 000000000..01028642a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005575.html @@ -0,0 +1,220 @@ + + + + [Mageia-dev] Question about backports: calibre (bug 1659) + + + + + + + + + +

[Mageia-dev] Question about backports: calibre (bug 1659)

+ Michael Scherer + misc at zarb.org +
+ Tue Jun 14 03:16:42 CEST 2011 +

+
+ +
Le lundi 13 juin 2011 à 02:51 -0700, Radu-Cristian FOTESCU a écrit :
+> Folks, 
+> 
+> WRT https://bugs.mageia.org/show_bug.cgi?id=1659
+> [Bug 1659] Calibre is too old (0.7.32 vs. 0.8.4, i.e. 31 versions behind!)
+> 
+> 
+> Two people asserted that a newer calibre package should go into backports, not updates.
+
+And so would I. That's 3.
+
+> I strongly believe quite the contrary.
+> 
+> 
+> I'd like to bring to your attention that calibre, the e-book reader and converter, 
+> has an extremely dynamic lifecycle: it released 32 versions in 6 months! Thirty-two 
+> versions! (I don't know of any other software that does that, virus signatures not counted.)
+> 
+> 
+> Sure thing, some releases might bring some regressions, but each and every version fixes bugs, 
+> adds new features, adds support for newer e-reader models, etc. etc. Also, the developer of 
+> calibre quickly releases a newer build in the case of serious regressions -- most of the 
+> times within 0 to a few days.
+
+So that's like most softwares :
+- there is lots of release, 
+- there is a mix of features, bugfixes and regression.
+
+So why does it have to be treated differently than the others since
+there is nothing special about this release cycle  ?
+
+
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005576.html b/zarb-ml/mageia-dev/2011-June/005576.html new file mode 100644 index 000000000..7c5681572 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005576.html @@ -0,0 +1,180 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Tue Jun 14 03:30:56 CEST 2011 +

+
+ +
Op dinsdag 14 juni 2011 01:02:51 schreef Michael Scherer:
+> Le lundi 13 juin 2011 à 15:51 +0300, Thomas Backlund a écrit :
+> > Wolfgang Bornath skrev 13.6.2011 15:20:
+> > > About the cycles:
+> > > 
+> > > The 9-months seem to be a compromise - but I start to ask why we need
+> > > such a fixed statement (which it would be, once published). We need a
+> > > schedule for each cycle, that's true. Without a schedule we would
+> > > never finish anything. But how about taking 9 months only as a "nice
+> > > to meet" target, leaving us the option to set a roadmap after setting
+> > > the specs of the next release - we could then go for a 8 or 10 months
+> > > roadmap, depending on the specs.
+> > 
+> > This is somewhat like what I had in my mind to write too, but you beat
+> > me to it :)
+> > 
+> > It could allow us to adapt a little for upstream releases.
+> > But should we then decide that the limit is +/- 1 month ?
+> 
+> There is 2 problem :
+> - for release of what software ?
+> - what if the upstream planning is wrong, and their releases is late
+> ( as it happened when I was a trainee in Mandrakesoft, with xfree being
+> 3 months late and the distribution still shipping a broken pre release )
+> 
+> > Obviously there will still be people complaining that "you waited 10
+> > months... if you had extended with ~2 more weeks... "this" or "that"
+> > package would have been available too... and so on....
+> 
+> Yes, there will be.
+> So let's be realist, 9 months with +/- 1 month is just 10 months +
+> people complaining to have 10,5 months.
+> 
+> We will never use the -1 month, because there will always be something
+> worth waiting.
+
+actually, the real reason would be more to plan for whatever features you're 
+going to implement and the time it takes to do them. if that's 8 months, it's 
+8 months, if that's 9 or 10months, that's what it is.
+
+We proved that we can take a planning and follow it through, even the last 
+release_critical one was solved _just_in_time_...
+
+imho, we need to decide now on a sort of 9month period, look at what we're 
+going to do, then estimating how long it takes (with enough lenience), then 
+make a real planning for that, and stick to it, if features are not ready, 
+drop those features for next release, and make sure to fix all the 
+release_criticals.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005577.html b/zarb-ml/mageia-dev/2011-June/005577.html new file mode 100644 index 000000000..b92b85166 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005577.html @@ -0,0 +1,170 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Michael Scherer + misc at zarb.org +
+ Tue Jun 14 04:08:34 CEST 2011 +

+
+ +
Le mardi 14 juin 2011 à 03:30 +0200, Maarten Vanraes a écrit :
+> Op dinsdag 14 juni 2011 01:02:51 schreef Michael Scherer:
+> > Le lundi 13 juin 2011 à 15:51 +0300, Thomas Backlund a écrit :
+> > > Wolfgang Bornath skrev 13.6.2011 15:20:
+> > > Obviously there will still be people complaining that "you waited 10
+> > > months... if you had extended with ~2 more weeks... "this" or "that"
+> > > package would have been available too... and so on....
+> > 
+> > Yes, there will be.
+> > So let's be realist, 9 months with +/- 1 month is just 10 months +
+> > people complaining to have 10,5 months.
+> > 
+> > We will never use the -1 month, because there will always be something
+> > worth waiting.
+> 
+> actually, the real reason would be more to plan for whatever features you're 
+> going to implement and the time it takes to do them. if that's 8 months, it's 
+> 8 months, if that's 9 or 10months, that's what it is.
+
+See my answer to wobo.
+
+> We proved that we can take a planning and follow it through, even the last 
+> release_critical one was solved _just_in_time_...
+
+I still think the codecs stuff should not have been release_critical, as
+we could do the update later.
+
+> imho, we need to decide now on a sort of 9month period, look at what we're 
+> going to do, then estimating how long it takes (with enough lenience), then 
+> make a real planning for that, and stick to it, if features are not ready, 
+> drop those features for next release, and make sure to fix all the 
+> release_criticals.
+
+Great, so can you start by telling how long it will take for the feature
+you plan to work on ?
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005578.html b/zarb-ml/mageia-dev/2011-June/005578.html new file mode 100644 index 000000000..d28e58977 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005578.html @@ -0,0 +1,174 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Thorsten van Lil + tvl83 at gmx.de +
+ Tue Jun 14 07:55:12 CEST 2011 +

+
+ +
Am Montag, 13. Juni 2011, 23:28:04 schrieb Renaud MICHEL:
+> On lundi 13 juin 2011 at 23:06, Thorsten van Lil wrote :
+> > A rolling release has following advantages:
+> > 1. the distribution is always up to date (also hardware support)
+> > 2. no re-install over and over again
+> 
+> I don't get it why people think a re-install is necessary.
+> My current computer was installed with mandriva 2007 (don't remember if it
+> was .0 or .1), it is now mageia 1 and has been updated to all intermediary
+> mdv releases.
+
+An Upgrade is nearly the same, than reinstalling. The difference is only, that 
+you can use your system in the mean time and you are not forced to install the 
+missing packages. 
+
+> > This could look like this:
+> > Bring up a release once a year. The core (kernel, glib, ...) will only
+> > get  minor updates. Apllications like firefox, libreoffice, ... will
+> > always be up to date (rolling). Maybe also the desktop envirenments
+> > could be rolling but this is very heavy.
+> 
+> If I understood correctly, that is exactly what the backports should
+> provide, new versions of programs when possible (no update of half of the
+> core system libraries).
+> 
+
+Yes, but Backports are not officially supported and we wouldn't advice new users 
+to backports normally. It's not what is possible with current repos but what 
+we offer for the "normal" user. Because this also influence what release cycle 
+we use. If we use such a light rolling release, it's enough to offer one 
+release per year or maybe one in 18 month. If we stay with the static release 
+model, we are almost "forced" to release every 9 months or earlier.
+
+Greetings,
+Thorsten
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005579.html b/zarb-ml/mageia-dev/2011-June/005579.html new file mode 100644 index 000000000..8970ce5ca --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005579.html @@ -0,0 +1,166 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Tue Jun 14 08:48:34 CEST 2011 +

+
+ +
Thorsten van Lil <tvl83 at gmx.de> schrieb am 14.06.2011
+> Am Montag, 13. Juni 2011, 23:28:04 schrieb Renaud MICHEL:
+> > I don't get it why people think a re-install is necessary.
+> > My current computer was installed with mandriva 2007 (don't
+> > remember if it was .0 or .1), it is now mageia 1 and has been
+> > updated to all intermediary mdv releases.
+> 
+> An Upgrade is nearly the same, than reinstalling. The difference is
+> only, that you can use your system in the mean time and you are
+> not forced to install the missing packages.
+And you keep all your precious settings and databases and webroots 
+and...
+And of couse the software you did unstall outside of the package 
+management (proprietary stuff,...).
+
+And a bit to the argument of having to install loads of software at 
+the same time: When some basic libraries are upgraded, loads of 
+software have to be rebuilt against them, so with the rolling aproach 
+you will just get that massive upgrades more often, so where is the 
+bonus in it?
+If people want to have their software more up to date, use backports, 
+if they want to have it even more up to date, use cauldron, but don't 
+cry if anything breaks.
+
+Oliver
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110614/2822aa8a/attachment-0001.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005580.html b/zarb-ml/mageia-dev/2011-June/005580.html new file mode 100644 index 000000000..5b6106064 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005580.html @@ -0,0 +1,183 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Thorsten van Lil + tvl83 at gmx.de +
+ Tue Jun 14 09:25:30 CEST 2011 +

+
+ +
Am 14.06.2011 08:48, schrieb Oliver Burger:
+> Thorsten van Lil <tvl83 at gmx.de> schrieb am 14.06.2011
+>  > An Upgrade is nearly the same, than reinstalling. The difference is
+>  > only, that you can use your system in the mean time and you are
+>  > not forced to install the missing packages.
+>
+> And you keep all your precious settings and databases and webroots and...
+>
+> And of couse the software you did unstall outside of the package
+> management (proprietary stuff,...).
+>
+>
+> And a bit to the argument of having to install loads of software at the
+> same time: When some basic libraries are upgraded, loads of software
+> have to be rebuilt against them, so with the rolling aproach you will
+> just get that massive upgrades more often, so where is the bonus in it?
+
+For sure. No matter what release model you want to take, if you want an 
+up to date system, you have to update (if this is your counter 
+argument). But it's a different if I have to update everything (~3GB) at 
+once or if I have to update ~100MB in a week. And it's a difference if I 
+have to wait for the software 1/2 year or just a month (if I only want 
+to use official supported repos).
+
+> If people want to have their software more up to date, use backports
+
+Backports aren't supposed to be for the averaged user and shouldn't be 
+used to bring the half of your system up to date. We could rework the 
+backports and than officially support them (wouldn't this solve also the 
+issue with new packages in mga1?). But than we have almost 2 different 
+release models. I'm not sure this is what we want.
+
+Well, Oliver. You are a packager. I'm not. Our menpower is the 
+restriction in the whole discussion. If it isn't, we could provide every 
+thoughtable release model and cycle and everyone would be happy. But 
+that's not the case. So, if a proposal is unworkably please tell us, as 
+well as your other concerns.
+
+In my first post I tried to summarize all advantages and disadvantages 
+of the different release models. Did I miss a point, than please add it. 
+And I'm also fine with a static release model, but I think such a light 
+rolling can have a lot of advantages.
+
+Thorsten
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005581.html b/zarb-ml/mageia-dev/2011-June/005581.html new file mode 100644 index 000000000..352e76d44 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005581.html @@ -0,0 +1,209 @@ + + + + [Mageia-dev] autologin + consolekit + + + + + + + + + +

[Mageia-dev] autologin + consolekit

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Jun 14 10:07:00 CEST 2011 +

+
+ +
'Twas brillig, and Colin Guthrie at 12/06/11 23:45 did gyre and gimble:
+> Hi,
+> 
+> The autologin package is broken due to the fact that it doesn't connect
+> to consolekit and thus the user who is automatically logged in doesn't
+> get any permissions etc.
+> 
+> I've fixed this by changing the autologin pam.d definition to include
+> "login" rather than "system-auth".
+> 
+> login adds the optional session module for pam_ck_connector.
+> 
+> But I'm not sure whether this makes sense, or whether we should just add
+> the ck_connector to the autologin pam.d definition itself.
+> 
+> There may be other login systems that have similar problems (e.g. the
+> autologin features of gdm or slim etc) but I've not tested.
+> 
+> Any thoughts.
+
+Does anyone know what the right way to fix the above is?
+
+I'd like to issue an update when appropriate to take care of 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-June/005582.html b/zarb-ml/mageia-dev/2011-June/005582.html new file mode 100644 index 000000000..e760b43ac --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005582.html @@ -0,0 +1,218 @@ + + + + [Mageia-dev] [RPM] cauldron core/release mgaonline-2.77.30-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release mgaonline-2.77.30-1.mga2

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Jun 14 10:16:14 CEST 2011 +

+
+ +
On 14 June 2011 09:25, Mageia Team <buildsystem-daemon at mageia.org> wrote:
+>  + ze <ze>
+>    - correct renaming
+>    - use native rpm macros instead variables,not both in same spec
+
+1) try to make your commit logs real english
+2) please stop altering buildroot definition, this is pointless with rpm-4.8
+    Especially when you turn it into bullshit:
+BuildRoot:      %{_tmppath}/%{name}-%version}-%{release}-buildroot
+
+Hint: count "{" and "}"
+Thanks.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005583.html b/zarb-ml/mageia-dev/2011-June/005583.html new file mode 100644 index 000000000..d6a69ae45 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005583.html @@ -0,0 +1,125 @@ + + + + [Mageia-dev] perl 5.14.0 now available + + + + + + + + + +

[Mageia-dev] perl 5.14.0 now available

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Jun 14 10:21:03 CEST 2011 +

+
+ +
On 11 June 2011 23:52, Pascal Terjan <pterjan at gmail.com> wrote:
+> Thanks for helping but
+> 1) Please use a better changelog message, like "Rebuild for perl
+> 5.14". Increase rel for rebuild is not interesting when looking at the
+> history of a package.
+
+we should really reject "one word" commit messages, at least on /packages/...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005584.html b/zarb-ml/mageia-dev/2011-June/005584.html new file mode 100644 index 000000000..36f7a1b6f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005584.html @@ -0,0 +1,255 @@ + + + + [Mageia-dev] Cross compile x86_64 on i586 for icecream? + + + + + + + + + +

[Mageia-dev] Cross compile x86_64 on i586 for icecream?

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Jun 14 10:27:35 CEST 2011 +

+
+ +
'Twas brillig, and Christiaan Welvaart at 13/06/11 12:24 did gyre and
+gimble:
+> On Mon, 13 Jun 2011, Colin Guthrie wrote:
+> 
+>> I'm not exactly a guru with icecream but is it possible to build a
+>> toolchain that can allow i586 nodes to compile x86_64 code?
+> 
+> If your question is about the toolchain, have you tried simply passing
+> -m64 to gcc?
+
+OK, so for the record, this doesn't work.
+
+However I checked out our tool chain and the RPMs accept some handy
+arguments. Yay!
+
+Sadly they don't really work!
+
+I was able to build binutils via:
+ rpmbuild --define "cross x86_64" --define "_topdir $(pwd)" -bb
+SPECS/binutils.spec
+
+But then I tried gcc via:
+ rpmbuild --define "cross_bootstrap x86_64" --define "_topdir $(pwd)"
+-bb SPECS/gcc.spec
+
+(it needs to bootstrap to build glibc which can then be used to rebuild
+gcc again fully).
+
+Sadly this bombed out:
+/home/colin/Mageia/gcc/BUILD/gcc-4.5.2/obj-x86_64-mageia-linux-gnu/./gcc/xgcc
+-B/home/colin/Mageia/gcc/BUILD/gcc-4.5.2/obj-x86_64-mageia-linux-gnu/./gcc/
+-B/usr/x86_64-mageia-linux-gnu/bin/ -B/usr/x86_64-mageia-linux-gnu/lib/
+-isystem /usr/x86_64-mageia-linux-gnu/include -isystem
+/usr/x86_64-mageia-linux-gnu/sys-include
+--sysroot=/home/colin/Mageia/gcc/BUILD/gcc-4.5.2/obj-x86_64-mageia-linux-gnu/../sysroot
+  -O2 -g -pipe -m32 -O2  -O2 -g -pipe -DIN_GCC
+-DCROSS_DIRECTORY_STRUCTURE -DNATIVE_CROSS  -W -Wall -Wwrite-strings
+-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
+-Wold-style-definition  -isystem ./include  -fPIC -g  -DIN_LIBGCC2
+-D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../../.././gcc -I../../../../libgcc
+-I../../../../libgcc/. -I../../../../libgcc/../gcc
+-I../../../../libgcc/../include -I../../../../libgcc/config/libbid
+-DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS  -DUSE_TLS -o _muldi3.o -MT
+_muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
+../../../../libgcc/../gcc/libgcc2.c
+In file included from ../../../../libgcc/../gcc/tsystem.h:87:0,
+                 from ../../../../libgcc/../gcc/libgcc2.c:29:
+/home/colin/Mageia/gcc/BUILD/gcc-4.5.2/obj-x86_64-mageia-linux-gnu/./gcc/include-fixed/stdio.h:13:23:
+fatal error: sys/types.h: No such file or directory
+compilation terminated.
+
+
+
+Now it seems that adding -Dinhibit_libc here works a treat, but I've no
+idea if this is appropriate. The files sys/types.h is included in the
+source but e.g. sys/syscall.h is not (this is subsequently needed if you
+fix the include path to point at the included lsb headers).
+
+
+As I know nothing about the tool chain....
+
+ Q1. Should we be setting -Dinhibit_libc during this bootstrap stage?
+ Q2. Would it be better to use the lsb-headers instead and somehow find
+syscall.h?
+ Q3. Am I doing something dumb?
+
+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-June/005585.html b/zarb-ml/mageia-dev/2011-June/005585.html new file mode 100644 index 000000000..2ee07028b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005585.html @@ -0,0 +1,183 @@ + + + + [Mageia-dev] Some news regarding rpm packaging rules : %clean section + + + + + + + + + +

[Mageia-dev] Some news regarding rpm packaging rules : %clean section

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Jun 14 10:32:04 CEST 2011 +

+
+ +
On 13 June 2011 11:52, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+> Note to other packagers: Please don't go cleaning (no pun intended) spec
+> files without thinking. As with all changes to rpm specs (such as the
+> infamous buildroot change of '09 :D) making the specs clean for one
+> distro version makes it harder/impossible to backport.
+
+Note that I want to do such cleaning right now but:
+Err, all mageia distros (both stable 1 & cauldron) are based on rpm-4.8.1
+so we jus canNOT backport to sg using an older rpm...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005586.html b/zarb-ml/mageia-dev/2011-June/005586.html new file mode 100644 index 000000000..2f2c0c312 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005586.html @@ -0,0 +1,264 @@ + + + + [Mageia-dev] "Job offer" : mentoring program coordinator + + + + + + + + + +

[Mageia-dev] "Job offer" : mentoring program coordinator

+ andre999 + andr55 at laposte.net +
+ Tue Jun 14 10:51:18 CEST 2011 +

+
+ +
Samuel Verschelde a écrit :
+>
+> Le lundi 13 juin 2011 00:52:18, andre999 a écrit :
+>> Samuel Verschelde a écrit :
+>>> Hello to everyone,
+>>>
+>>> I'm sure there's someone among you who wants to help Mageia but hasn't
+>>> found yet the good way to do it. Today is your lucky day, because
+>>> there's a job that's available and can be really useful and interesting:
+>>> coordinating the packagers mentoring program.
+>>>
+>>> You know that one key point of success for Mageia is in the ability to
+>>> welcome new packagers. The better we will be at it, the better the
+>>> distro will be. The packagers mentoring program has been created for
+>>> that reason and several packagers have been or are being mentored. But
+>>> we have some difficulty knowing who is being mentored by who and who
+>>> hasn't found a mentor. And we need also to find more mentors and more
+>>> apprentices.
+>>>
+>>> During a packagers weekly meeting, misc invited us to read the following
+>>> article about mentoring programs in open-source projects:
+>>> http://blogs.gnome.org/bolsh/2011/05/31/effective-mentoring-programs/
+>>
+>> Very interesting, especially many of the comments.
+>>
+>>> I invite those who haven't read it yet, to read it. I'll quote one of the
+>>> mentoring best practices that were given: "In bigger projects, keeping
+>>> track of who is a mentor, and who is mentoring who, and inviting new
+>>> mentors, and ensuring that no-one falls through the cracks when a mentor
+>>> gets too busy, is a job of itself."
+>>>
+>>> I'm looking for someone who could fill that "job".
+>>>
+>>> Description of the job:
+>>>
+>>> - keep track of:
+>>> -- who's being mentored by who, how well it's going
+>>> -- who needs a mentor and hasn't found one yet (this is one of the most
+>>> important parts: no volunteer must be forgotten, volunteers are too
+>>> precious !)
+>>> -- who can mentor more apprentices (and sometimes convince packagers to
+>>> become mentors or accept one more apprentice)
+>>>
+>>> - be available for questions from apprentices or mentors, by mail, and if
+>>> possible, to be present on the IRC channel #mageia-mentoring on freenode
+>>>
+>>> - help mentors with gathering "junior tasks" (bugzilla is a never empty
+>>> reserve that can be used for that. Maybe ask the bug triage team to help
+>>> identify such tasks. Maybe a "junior task" keyword in bugzilla would do
+>>> the trick)
+>>> -- small bugs to fix
+>>> -- new small packages to import in the distribution
+>>> -- backports
+>>>
+>>> - promote mentoring (empower users into contributers. Working with the
+>>> marketing team would be great I think):
+>>> -- make the mentoring program known (MLs, forums, web, etc.)
+>>> -- look for new apprentices
+>>> -- look for new mentors
+>>>
+>>> Some useful skills:
+>>> - be autonomous (ie no need to check that you're doing the work)
+>>> - good written english (communication is very important in this job)
+>>> - knowledge about packaging is a plus but not mandatory (the key aspects
+>>> can be taught to you)
+>>> - being or having been a mentor, or having been mentored would be a plus,
+>>> but not mandatory
+>>>
+>>> More information about the job:
+>>> - does not require a big amount of work, but real committment to the task
+>>> and regularity
+>>> - remember that you have a coordination role, not an authoritative role.
+>>> The difference in that is that you're not here to give orders but to
+>>> facilitate the mentoring program.
+>>> - you don't have to be alone to do this job if it's too much for one
+>>> person: you can find other helpful people wanting to help you if needed
+>>> and rely on the other teams (but finding them *is* part of your job ;)
+>>> ).
+>>> -  this "job offer" concerns everything that revolves around the
+>>> mentoring of new packagers, but if it's successful maybe other teams can
+>>> follow the same approach (i18n, QA, etc... ).
+>>> -  depending on your level of confidence, experience and will, you could
+>>> be helped in your work. Maybe someone from the council can supervise and
+>>> help you at least at the beginning; or, if no one steps up, I can help
+>>> you bootstrap and organize your new "job".
+>>>
+>>> So, who's in?
+>>>
+>>> Samuel Verschelde
+>>
+>> That is an excellent idea, a mentoring program coordinator.
+>> I've had some thoughts along those lines for some time.
+>> I'd be glad to contribute, especially via email and editing the wiki, where
+>> I could almost always respond the same day.
+>> But my time zone availability (generally after 22h utc) puts me at a
+>> disadvantage for irc communications and meetings.
+>> (But as part of a coordinating team, that should work well.)
+>>
+>> Maintaining the mentor/apprentice database, as Kharec suggested, is to me a
+>> key part of the role. Information such as mentors available, and their
+>> strengths/focus, usual time zones available, communication modes
+>> preferred, languages spoken, and current apprentices, Would-be apprentices
+>> should have similar information listed.
+>> Not much different from the information currently in variously wiki pages,
+>> but maintained by the coordinator in one location.
+>>
+>> <aside>
+>> One thing that occurred to me is that there is no imperative that mentoring
+>> process happens only in English.  If an apprentice is more comfortable in
+>> another language, and they find a mentor speaking that language, why not ?
+>>   Sure, it is useful to have basic English knowledge, but it is evident
+>> that many (if not most) contributors speak English as a second language.
+>> </aside>
+>>
+>> Experience packaging, either as a mentor or apprentice is highly
+>> recommended in my view, at least for the key person.  (My experience is as
+>> a apprentice with Shikamaru -- an excellent mentor, btw -- and my time
+>> zone availability is probably why I haven't officially completed the
+>> process.) Also some programming experience could be useful.  (I imagine
+>> that most candidates would have that.)
+>>
+>> But also mentoring can apply to other things than packaging.  So maybe we
+>> should give a broader scope to the mentoring coordinator job ?
+>> Including bugteam, QA, as well as packaging.
+>> That would make it more useful, as well as more interesting.
+>> (I would be very interested in contributing to something like that.)
+>>
+>> So what does everyone think ?
+>
+> Thanks for the input, but there's one point that's still unclear to me : do
+> you candidate for the job ? :p
+>
+> (the timezone question can be a problem, but not necessarily a blocking one)
+>
+> Samuel
+
+Yes :)
+It's an important task, and I think I would do it well.
+With my (albeit somewhat limited) packaging experience and getting to better know the community, I 
+have a much better understanding of the whole Mageia development process than I did even a few 
+months ago.  And how this fits in.
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005587.html b/zarb-ml/mageia-dev/2011-June/005587.html new file mode 100644 index 000000000..7ff60cf19 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005587.html @@ -0,0 +1,189 @@ + + + + [Mageia-dev] Some news regarding rpm packaging rules : %clean section + + + + + + + + + +

[Mageia-dev] Some news regarding rpm packaging rules : %clean section

+ Michael Scherer + misc at zarb.org +
+ Tue Jun 14 11:21:53 CEST 2011 +

+
+ +
Le mardi 14 juin 2011 à 10:32 +0200, Thierry Vignaud a écrit :
+> On 13 June 2011 11:52, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+> > Note to other packagers: Please don't go cleaning (no pun intended) spec
+> > files without thinking. As with all changes to rpm specs (such as the
+> > infamous buildroot change of '09 :D) making the specs clean for one
+> > distro version makes it harder/impossible to backport.
+> 
+> Note that I want to do such cleaning right now but:
+> Err, all mageia distros (both stable 1 & cauldron) are based on rpm-4.8.1
+> so we jus canNOT backport to sg using an older rpm...
+
+We did some backport from cauldron to mandriva 2010.2 for our servers,
+so I think we should wait until we decide that such backports are no
+longer needed.
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005588.html b/zarb-ml/mageia-dev/2011-June/005588.html new file mode 100644 index 000000000..58925a83b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005588.html @@ -0,0 +1,256 @@ + + + + [Mageia-dev] Cross compile x86_64 on i586 for icecream? + + + + + + + + + +

[Mageia-dev] Cross compile x86_64 on i586 for icecream?

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Jun 14 11:45:04 CEST 2011 +

+
+ +
'Twas brillig, and Colin Guthrie at 14/06/11 09:27 did gyre and gimble:
+> 'Twas brillig, and Christiaan Welvaart at 13/06/11 12:24 did gyre and
+> gimble:
+>> On Mon, 13 Jun 2011, Colin Guthrie wrote:
+>>
+>>> I'm not exactly a guru with icecream but is it possible to build a
+>>> toolchain that can allow i586 nodes to compile x86_64 code?
+>>
+>> If your question is about the toolchain, have you tried simply passing
+>> -m64 to gcc?
+> 
+> OK, so for the record, this doesn't work.
+> 
+> However I checked out our tool chain and the RPMs accept some handy
+> arguments. Yay!
+> 
+> Sadly they don't really work!
+> 
+> I was able to build binutils via:
+>  rpmbuild --define "cross x86_64" --define "_topdir $(pwd)" -bb
+> SPECS/binutils.spec
+> 
+> But then I tried gcc via:
+>  rpmbuild --define "cross_bootstrap x86_64" --define "_topdir $(pwd)"
+> -bb SPECS/gcc.spec
+> 
+> (it needs to bootstrap to build glibc which can then be used to rebuild
+> gcc again fully).
+> 
+> Sadly this bombed out:
+> /home/colin/Mageia/gcc/BUILD/gcc-4.5.2/obj-x86_64-mageia-linux-gnu/./gcc/xgcc
+> -B/home/colin/Mageia/gcc/BUILD/gcc-4.5.2/obj-x86_64-mageia-linux-gnu/./gcc/
+> -B/usr/x86_64-mageia-linux-gnu/bin/ -B/usr/x86_64-mageia-linux-gnu/lib/
+> -isystem /usr/x86_64-mageia-linux-gnu/include -isystem
+> /usr/x86_64-mageia-linux-gnu/sys-include
+> --sysroot=/home/colin/Mageia/gcc/BUILD/gcc-4.5.2/obj-x86_64-mageia-linux-gnu/../sysroot
+>   -O2 -g -pipe -m32 -O2  -O2 -g -pipe -DIN_GCC
+> -DCROSS_DIRECTORY_STRUCTURE -DNATIVE_CROSS  -W -Wall -Wwrite-strings
+> -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
+> -Wold-style-definition  -isystem ./include  -fPIC -g  -DIN_LIBGCC2
+> -D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../../.././gcc -I../../../../libgcc
+> -I../../../../libgcc/. -I../../../../libgcc/../gcc
+> -I../../../../libgcc/../include -I../../../../libgcc/config/libbid
+> -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS  -DUSE_TLS -o _muldi3.o -MT
+> _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
+> ../../../../libgcc/../gcc/libgcc2.c
+> In file included from ../../../../libgcc/../gcc/tsystem.h:87:0,
+>                  from ../../../../libgcc/../gcc/libgcc2.c:29:
+> /home/colin/Mageia/gcc/BUILD/gcc-4.5.2/obj-x86_64-mageia-linux-gnu/./gcc/include-fixed/stdio.h:13:23:
+> fatal error: sys/types.h: No such file or directory
+> compilation terminated.
+> 
+> 
+> 
+> Now it seems that adding -Dinhibit_libc here works a treat, but I've no
+> idea if this is appropriate. The files sys/types.h is included in the
+> source but e.g. sys/syscall.h is not (this is subsequently needed if you
+> fix the include path to point at the included lsb headers).
+> 
+> 
+> As I know nothing about the tool chain....
+> 
+>  Q1. Should we be setting -Dinhibit_libc during this bootstrap stage?
+>  Q2. Would it be better to use the lsb-headers instead and somehow find
+> syscall.h?
+>  Q3. Am I doing something dumb?
+
+
+Added https://bugs.mageia.org/show_bug.cgi?id=1794 on RTPs request.
+
+:)
+
+
+-- 
+
+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-June/005589.html b/zarb-ml/mageia-dev/2011-June/005589.html new file mode 100644 index 000000000..021928537 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005589.html @@ -0,0 +1,193 @@ + + + + [Mageia-dev] Question about backports: calibre (bug 1659) + + + + + + + + + +

[Mageia-dev] Question about backports: calibre (bug 1659)

+ Radu-Cristian FOTESCU + beranger5ca at yahoo.ca +
+ Tue Jun 14 12:00:55 CEST 2011 +

+
+ +
+
+> So why does it have to be treated differently than the others since
+> there is nothing special about this release cycle  ?
+
+Michael, please give me an example of an application that releases on average 5 time a month. Really, give me an example.
+
+And, like it or not, calibre is _THE_ application for e-book lovers. For e-book users, it's as important as Firefox or Chromium is for the rest of the people.
+
+Also, Mageia 1.0 was released with a version of this application shamefully old. 
+
+Fedora made a better judgment (I might just consider switching to Fedora, although I like Mageia more): they released F15 with a recent version of calibre, 0.7.56, but they added in updates 0.8.0. For the time being they stopped at 0.8.0, and only in Rawhide they pushed 0.8.4, which in my opinion is a good judgment that would be a _balance_ between:
+
+-- announced bug-fixes
+-- announced new features
+-- announced new hardware supported
+-- ad-hoc assessment of the risk brought by the new features (a heuristic
+process based mainly on experience as a user, experience as a software
+developer, and common-sense).Of course, the people who _make_ a distro are its _owners_, and of course the reasoning of those who make Fedora is not necessarily the best example to be followed by everybody, but as it happens, I prefer their brains.
+
+R-C
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005590.html b/zarb-ml/mageia-dev/2011-June/005590.html new file mode 100644 index 000000000..b73825a60 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005590.html @@ -0,0 +1,203 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ lebarhon + lebarhon at free.fr +
+ Tue Jun 14 12:39:02 CEST 2011 +

+
+ +
Hello,
+I will forward in this thread the messages coming from the forum. They 
+aren't my opinion.
+Lebarhon.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005591.html b/zarb-ml/mageia-dev/2011-June/005591.html new file mode 100644 index 000000000..990a88dc7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005591.html @@ -0,0 +1,269 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ lebarhon + lebarhon at free.fr +
+ Tue Jun 14 12:40:33 CEST 2011 +

+
+ +
+by *corbintech 
+<https://forums.mageia.org/en/memberlist.php?mode=viewprofile&u=646>* » 
+Jun 13th, '11, 22:12
+I quit the ML because I was not doing it right (never used a list like 
+that before).
+
+So if I may, I will post here what somebody responded to me and write my 
+response here.
+
+    complete rolling release would put a QA strain on each of the
+    levels. think
+    about it, it's not only the current package being updated, but also the
+    combinations with other packages. (AND also all the long time supported
+    versions)
+
+    This would mean that for each package being release, it'll have to
+    work with
+    the current set of other packages, but also with the packages you'll
+    be doing
+    next.
+
+    if you have this constant level of QA, you need alot of resources
+    (which we
+    don't have in QA), and as an extra result, you'll not have the same
+    level of
+    QA you could have, when you're doing a release.
+
+    it's much easier (as devs) to just choose a subset of packages, and
+    test those
+    out.
+
+    if you have X QA-devs, and you have 1 subset of versions of
+    packages, you can
+    test alot more than if you have several versions of several packages
+    that need
+    to work all with each other in almost any combinations...
+
+    not to mention that you need an extra step with QA to put a "group" of
+    packages from one level to the next...
+
+    sorry, but with our current resources, i vote no. i want current
+    resources to
+    be used much more efficiently than with a rolling release.
+
+
+
+Why do we keep acting like there is no other way to pool resources? I 
+have never helped develop in any way, teach me something and I'll lend a 
+hand... Others may do the same.. ASK!
+
+QA comes from testing... Test... Test... And test more... To make sure 
+what you have works and works well. Let's change up my idea a bit and 
+satisfy everyone... Let's compromise...
+
+How about Cooker (or whatever you call) rolls to rolling (can be very 
+stable???!!!) with release cycle releases based on a snapshot of either 
+of the rolling models and supported for X amount of time? This could 
+make those whom want a rolling release model happy and those whom want a 
+release cycle.
+
+Would this be hard? I don't really think so as development is already 
+based on a rolling model (cooker or whatever), all that will have to be 
+done is packages roll down the line. I seen in the start of all these 
+talks you wanted to support 3 structures of systems... Here they are!
+
+What about this? Get the community involved!
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110614/74831276/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005592.html b/zarb-ml/mageia-dev/2011-June/005592.html new file mode 100644 index 000000000..2bfd40be7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005592.html @@ -0,0 +1,218 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ lebarhon + lebarhon at free.fr +
+ Tue Jun 14 12:42:15 CEST 2011 +

+
+ +
by *roadrunner 
+<https://forums.mageia.org/en/memberlist.php?mode=viewprofile&u=468>* » 
+Jun 13th, '11, 22:24
+
+    pmithrandir wrote:BTW : I think mailing list are totally outdated
+    and that mageia should have a special section in this forum for
+    these discussion, or maybe another forum.
+    It's totally impossible for people who want to participate sometimes
+    to follow you emails everydays. It's much faster to read some topic
+    on a forum than dozens emails. And your final user should be able to
+    know what happen easily. It would be a big + in front of others
+    distributions.
+
+Well said, I couldn't have put it better mysef and I agree 100%
+
+.\\artin
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110614/5c671be9/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005593.html b/zarb-ml/mageia-dev/2011-June/005593.html new file mode 100644 index 000000000..9e9148119 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005593.html @@ -0,0 +1,239 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Jun 14 13:03:59 CEST 2011 +

+
+ +
'Twas brillig, and lebarhon at 14/06/11 11:42 did gyre and gimble:
+> by *roadrunner
+> <https://forums.mageia.org/en/memberlist.php?mode=viewprofile&u=468>* »
+> Jun 13th, '11, 22:24
+> 
+>     pmithrandir wrote:BTW : I think mailing list are totally outdated
+>     and that mageia should have a special section in this forum for
+>     these discussion, or maybe another forum.
+>     It's totally impossible for people who want to participate sometimes
+>     to follow you emails everydays. It's much faster to read some topic
+>     on a forum than dozens emails. And your final user should be able to
+>     know what happen easily. It would be a big + in front of others
+>     distributions.
+> 
+> Well said, I couldn't have put it better mysef and I agree 100%
+
+This email is not about release cycles and peoples opinions of the
+options presented for discussion.
+
+While it's maybe a valid feeling that may require it's own discussion
+(I've already explained why I believe the exact opposite and that the
+use of forums for projects would seriously limit my ability to
+participate), it's not part of this discussion per se.
+
+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-June/005594.html b/zarb-ml/mageia-dev/2011-June/005594.html new file mode 100644 index 000000000..7b23888f6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005594.html @@ -0,0 +1,239 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Dexter Morgan + dmorganec at gmail.com +
+ Tue Jun 14 13:56:29 CEST 2011 +

+
+ +
Hello,
+
+do we wait firefox 5 rc or we can start to update to firefox 5 soon ?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005595.html b/zarb-ml/mageia-dev/2011-June/005595.html new file mode 100644 index 000000000..6fb933e94 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005595.html @@ -0,0 +1,246 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Sander Lepik + sander.lepik at eesti.ee +
+ Tue Jun 14 14:08:32 CEST 2011 +

+
+ +
14.06.2011 14:56, Dexter Morgan kirjutas:
+> Hello,
+>
+> do we wait firefox 5 rc or we can start to update to firefox 5 soon ?
+Will there be RC? I'm not so sure. They have now new dev cycle and 5 should be released next 
+week. As a silent update AFAIK.
+
+--
+Sander
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005596.html b/zarb-ml/mageia-dev/2011-June/005596.html new file mode 100644 index 000000000..6e7e85f82 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005596.html @@ -0,0 +1,250 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Balcaen John + mikala at mageia.org +
+ Tue Jun 14 14:13:39 CEST 2011 +

+
+ +
Le mardi 14 juin 2011 08:56:29, Dexter Morgan a écrit :
+> Hello,
+> 
+> do we wait firefox 5 rc or we can start to update to firefox 5 soon ?
+> 
+I noticed that mandriva is now providing a -stable, -beta  and -devel version
+of firefox, maybe we can use this solution.
+
+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-June/005597.html b/zarb-ml/mageia-dev/2011-June/005597.html new file mode 100644 index 000000000..c79f2146f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005597.html @@ -0,0 +1,248 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Samuel Verschelde + stormi at laposte.net +
+ Tue Jun 14 14:14:02 CEST 2011 +

+
+ +
+Le mardi 14 juin 2011 13:56:29, Dexter Morgan a écrit :
+> Hello,
+> 
+> do we wait firefox 5 rc or we can start to update to firefox 5 soon ?
+
+Mandriva now has several packages for firefox (like for chromium), following 
+the upstream channels, maybe we could envision doing it too ?
+
+Samuel
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005598.html b/zarb-ml/mageia-dev/2011-June/005598.html new file mode 100644 index 000000000..4e743b67b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005598.html @@ -0,0 +1,271 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Daniel Kreuter + daniel.kreuter85 at googlemail.com +
+ Tue Jun 14 14:15:41 CEST 2011 +

+
+ +
On Tue, Jun 14, 2011 at 2:13 PM, Balcaen John <mikala at mageia.org> wrote:
+
+> Le mardi 14 juin 2011 08:56:29, Dexter Morgan a écrit :
+> > Hello,
+> >
+> > do we wait firefox 5 rc or we can start to update to firefox 5 soon ?
+> >
+> I noticed that mandriva is now providing a -stable, -beta  and -devel
+> version
+> of firefox, maybe we can use this solution.
+>
+> Regards,
+>
+> --
+> Balcaen John
+> Jabber ID: mikala at jabber.littleboboy.net
+>
+
+We are already using this for the chromium-browser i just noticed that this
+morning.
+
+When I remember correct Mozilla doesn't plan to bring out a RC?? Maybe I'm
+wrong with that. But providing FF5 for Mga2 would be nice (maybe we can just
+go to Version 6 or 7 when it's out. When their new release cycle works FF7
+will be out before mga2)
+
+
+-- 
+Mit freundlichen Grüßen
+
+Greetings
+
+Daniel Kreuter
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110614/3742f6c5/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005599.html b/zarb-ml/mageia-dev/2011-June/005599.html new file mode 100644 index 000000000..1bcd9f812 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005599.html @@ -0,0 +1,254 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Dexter Morgan + dmorganec at gmail.com +
+ Tue Jun 14 14:18:37 CEST 2011 +

+
+ +
On Tue, Jun 14, 2011 at 2:14 PM, Samuel Verschelde <stormi at laposte.net> wrote:
+>
+> Le mardi 14 juin 2011 13:56:29, Dexter Morgan a écrit :
+>> Hello,
+>>
+>> do we wait firefox 5 rc or we can start to update to firefox 5 soon ?
+>
+> Mandriva now has several packages for firefox (like for chromium), following
+> the upstream channels, maybe we could envision doing it too ?
+>
+> Samuel
+>
+>
+
+which mean we will provide an unstable release with mageia 2 too ?
+
+i think we should focus to provide the stable firefox and this can be
+enough work
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005600.html b/zarb-ml/mageia-dev/2011-June/005600.html new file mode 100644 index 000000000..32aa8d6a1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005600.html @@ -0,0 +1,253 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Jun 14 14:22:21 CEST 2011 +

+
+ +
On 14 June 2011 14:18, Dexter Morgan <dmorganec at gmail.com> wrote:
+>>> do we wait firefox 5 rc or we can start to update to firefox 5 soon ?
+>>
+>> Mandriva now has several packages for firefox (like for chromium), following
+>> the upstream channels, maybe we could envision doing it too ?
+>
+> which mean we will provide an unstable release with mageia 2 too ?
+>
+> i think we should focus to provide the stable firefox and this can be
+> enough work
+
+Upgrading stable firefox to firefox5rc and importing firefox-{beta,aurora}
+are two distinct orthogonal things IMHO.
+
+since firefox5 is near being released, I think we should update
+main xulrunner+firefox to 5 anyway
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005601.html b/zarb-ml/mageia-dev/2011-June/005601.html new file mode 100644 index 000000000..4ebb06623 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005601.html @@ -0,0 +1,272 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Michael Scherer + misc at zarb.org +
+ Tue Jun 14 14:30:17 CEST 2011 +

+
+ +
Le mardi 14 juin 2011 à 14:14 +0200, Samuel Verschelde a écrit :
+> Le mardi 14 juin 2011 13:56:29, Dexter Morgan a écrit :
+> > Hello,
+> > 
+> > do we wait firefox 5 rc or we can start to update to firefox 5 soon ?
+> 
+> Mandriva now has several packages for firefox (like for chromium), following 
+> the upstream channels, maybe we could envision doing it too ?
+
+That's 3 times the work however, especially for extensions. 
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005602.html b/zarb-ml/mageia-dev/2011-June/005602.html new file mode 100644 index 000000000..a4132eeb4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005602.html @@ -0,0 +1,248 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Frank Griffin + ftg at roadrunner.com +
+ Tue Jun 14 14:32:48 CEST 2011 +

+
+ +
On 06/14/2011 08:22 AM, Thierry Vignaud wrote:
+>
+> Upgrading stable firefox to firefox5rc and importing firefox-{beta,aurora}
+> are two distinct orthogonal things IMHO.
+>
+> since firefox5 is near being released, I think we should update
+> main xulrunner+firefox to 5 anyway
+>
+Whatever we do, please don't put it in Core to replace FF4 until the 
+add-ons have been updated.  It was really annoying to lose the Tor 
+add-on for months because the beta FF4 just showed up and replaced FF3, 
+and the Tor add-on wasn't updated until the release or just before.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005603.html b/zarb-ml/mageia-dev/2011-June/005603.html new file mode 100644 index 000000000..8b2b2dfbb --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005603.html @@ -0,0 +1,273 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Sander Lepik + sander.lepik at eesti.ee +
+ Tue Jun 14 14:32:57 CEST 2011 +

+
+ +
14.06.2011 15:30, Michael Scherer kirjutas:
+> Le mardi 14 juin 2011 à 14:14 +0200, Samuel Verschelde a écrit :
+>> Le mardi 14 juin 2011 13:56:29, Dexter Morgan a écrit :
+>>> Hello,
+>>>
+>>> do we wait firefox 5 rc or we can start to update to firefox 5 soon ?
+>> Mandriva now has several packages for firefox (like for chromium), following
+>> the upstream channels, maybe we could envision doing it too ?
+> That's 3 times the work however, especially for extensions.
+>
+IMHO extensions and plugins should be same for all. They might not work but this will be the 
+choice of the user.
+
+--
+Sander
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005604.html b/zarb-ml/mageia-dev/2011-June/005604.html new file mode 100644 index 000000000..c0a19c983 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005604.html @@ -0,0 +1,255 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Sander Lepik + sander.lepik at eesti.ee +
+ Tue Jun 14 14:35:35 CEST 2011 +

+
+ +
14.06.2011 15:32, Frank Griffin kirjutas:
+> On 06/14/2011 08:22 AM, Thierry Vignaud wrote:
+>>
+>> Upgrading stable firefox to firefox5rc and importing firefox-{beta,aurora}
+>> are two distinct orthogonal things IMHO.
+>>
+>> since firefox5 is near being released, I think we should update
+>> main xulrunner+firefox to 5 anyway
+>>
+> Whatever we do, please don't put it in Core to replace FF4 until the add-ons have been 
+> updated.  It was really annoying to lose the Tor add-on for months because the beta FF4 
+> just showed up and replaced FF3, and the Tor add-on wasn't updated until the release or 
+> just before.
+Addons must be updated faster this time around. Firefox 5 will be next security update for 
+Firefox 4.0.1. This is Mozillas new policy. They won't support Firefox 4 any longer this time.
+
+--
+Sander
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005605.html b/zarb-ml/mageia-dev/2011-June/005605.html new file mode 100644 index 000000000..0e9d24a06 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005605.html @@ -0,0 +1,224 @@ + + + + [Mageia-dev] GNOME3 ? + + + + + + + + + +

[Mageia-dev] GNOME3 ?

+ Frank Griffin + ftg at roadrunner.com +
+ Tue Jun 14 14:38:49 CEST 2011 +

+
+ +
On 06/13/2011 06:45 PM, JA Magallón wrote:
+> On Mon, 13 Jun 2011 17:33:20 -0400, Frank Griffin<ftg at roadrunner.com>  wrote:
+>
+>> On 06/13/2011 04:12 PM, Frank Griffin wrote:
+>> Ahh.  Correction with the latest updates: now the ID previously using
+>> GNOME 2.32 doesn't get past the blue background either.
+> Two kind of problems:
+> - dependecies: make sure you have 'gtk+3.0' and 'gnome-themes-standard'
+>    (latest will pick some themes and fonts...) You should see a striped
+>    blue bg after login.
+
+You're right, gnome-themes-standard was never pulled in by the base 
+packages.  Adding it, now I get a blue striped background instead of 
+plain blue.  But still no "Activities    date     Username" at the top 
+of the screen as I used to.
+
+
+> - in my case I get kicked off because gnome-settings-daemon hangs on
+>    libnsl (from glibc). I am thinkin on how to debug it (how to launch
+>    g-s-d on a gdb shell and dump the output somewhere...)
+>
+> Check if you have something like this in your dmesg:
+>
+> gnome-settings-[2556]: segfault at 7fb8612fb1d0 ip 00007fb8612fb1d0 sp 00007fff830282d8 error 14 in libnsl-2.12.1.so[7fb8639dc000+15000]
+> gnome-settings-[3257]: segfault at 7fae815011d0 ip 00007fae815011d0 sp 00007fff72cc8b58 error 14 in libnsl-2.12.1.so[7fae83be2000+15000]
+> gnome-settings-[3723]: segfault at 7f42989871d0 ip 00007f42989871d0 sp 00007fffa8d55858 error 14 in libnsl-2.12.1.so[7f429b068000+15000]
+>
+> If yes, at least I'm not the only one :).
+
+I get exactly that, thanks for the tip.
+
+Also, I've found that most of the GNOME3 packages have to be forced on 
+because of file conflicts with 2.32 versions.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005606.html b/zarb-ml/mageia-dev/2011-June/005606.html new file mode 100644 index 000000000..6912bf2f3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005606.html @@ -0,0 +1,229 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ Lee Forest + lee8oi at gmail.com +
+ Tue Jun 14 14:52:50 CEST 2011 +

+
+ +
I agree. Mailing lists are messy and hard to follow. And sometimes the only
+response you get is about how you sent the message wrong. I bet more people
+would use the forums. Only a couple people so far are hooked on mailing
+lists. Im seeing more and more comments coming in about this. forums would
+at least would allow people to follow one version of the discussion instead
+of everyone posting a copy with their reply. And its easier to review past
+messages without sorting through all your emails that practically spam your
+box. People can subscribe to the topics they actually want, and browse the
+messages at their leisure. mailing list might work best for a couple people
+but is it worth inconveniencing the rest of the word because you are a die
+hard mailing list user?
+On Jun 14, 2011 6:42 AM, "lebarhon" <lebarhon at free.fr> wrote:
+> by *roadrunner
+> <https://forums.mageia.org/en/memberlist.php?mode=viewprofile&u=468>* »
+> Jun 13th, '11, 22:24
+>
+> pmithrandir wrote:BTW : I think mailing list are totally outdated
+> and that mageia should have a special section in this forum for
+> these discussion, or maybe another forum.
+> It's totally impossible for people who want to participate sometimes
+> to follow you emails everydays. It's much faster to read some topic
+> on a forum than dozens emails. And your final user should be able to
+> know what happen easily. It would be a big + in front of others
+> distributions.
+>
+> Well said, I couldn't have put it better mysef and I agree 100%
+>
+> .\\artin
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110614/08fac349/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005607.html b/zarb-ml/mageia-dev/2011-June/005607.html new file mode 100644 index 000000000..3d2975ec1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005607.html @@ -0,0 +1,239 @@ + + + + [Mageia-dev] GNOME3 ? + + + + + + + + + +

[Mageia-dev] GNOME3 ?

+ Dexter Morgan + dmorganec at gmail.com +
+ Tue Jun 14 14:56:56 CEST 2011 +

+
+ +
On Tue, Jun 14, 2011 at 2:38 PM, Frank Griffin <ftg at roadrunner.com> wrote:
+> On 06/13/2011 06:45 PM, JA Magallón wrote:
+>>
+>> On Mon, 13 Jun 2011 17:33:20 -0400, Frank Griffin<ftg at roadrunner.com>
+>>  wrote:
+>>
+>>> On 06/13/2011 04:12 PM, Frank Griffin wrote:
+>>> Ahh.  Correction with the latest updates: now the ID previously using
+>>> GNOME 2.32 doesn't get past the blue background either.
+>>
+>> Two kind of problems:
+>> - dependecies: make sure you have 'gtk+3.0' and 'gnome-themes-standard'
+>>   (latest will pick some themes and fonts...) You should see a striped
+>>   blue bg after login.
+>
+> You're right, gnome-themes-standard was never pulled in by the base
+> packages.
+
+i will add it on task-gnome
+
+Adding it, now I get a blue striped background instead of plain
+> blue.  But still no "Activities    date     Username" at the top of the
+> screen as I used to.
+>
+>
+>> - in my case I get kicked off because gnome-settings-daemon hangs on
+>>   libnsl (from glibc). I am thinkin on how to debug it (how to launch
+>>   g-s-d on a gdb shell and dump the output somewhere...)
+>>
+>> Check if you have something like this in your dmesg:
+>>
+>> gnome-settings-[2556]: segfault at 7fb8612fb1d0 ip 00007fb8612fb1d0 sp
+>> 00007fff830282d8 error 14 in libnsl-2.12.1.so[7fb8639dc000+15000]
+>> gnome-settings-[3257]: segfault at 7fae815011d0 ip 00007fae815011d0 sp
+>> 00007fff72cc8b58 error 14 in libnsl-2.12.1.so[7fae83be2000+15000]
+>> gnome-settings-[3723]: segfault at 7f42989871d0 ip 00007f42989871d0 sp
+>> 00007fffa8d55858 error 14 in libnsl-2.12.1.so[7f429b068000+15000]
+>>
+>> If yes, at least I'm not the only one :).
+>
+> I get exactly that, thanks for the tip.
+>
+> Also, I've found that most of the GNOME3 packages have to be forced on
+> because of file conflicts with 2.32 versions.
+>
+>
+
+if you can provide the urpmi logs i would be glad to fix this as
+quickly as possible
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005608.html b/zarb-ml/mageia-dev/2011-June/005608.html new file mode 100644 index 000000000..6d9cdb5ce --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005608.html @@ -0,0 +1,217 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Tue Jun 14 15:07:38 CEST 2011 +

+
+ +
I've been around when there were no forums, just news groups and
+mailing lists. And I have been posting in forums since they were
+invented (even in early CompuServe times). What I found out over all
+these years:
+
+1. All these reasons which have been posted here and in previous
+threads since the beginning of Mageia communication are the very same
+reasons (in favor and against both platforms) which have been posted
+10 years ago and zillions of times in between - nothing has changed
+one little bit on either side.
+
+2. If you handle both platforms right there is no difference at all
+between them (except that mailing lists are easier to handle in a
+text-only environment, which is quite rare these days)
+
+So, IMHO this discussion is as meaningless as the famous/infamous vi
+vs emacs discussions of way back when.
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005609.html b/zarb-ml/mageia-dev/2011-June/005609.html new file mode 100644 index 000000000..4049c7d89 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005609.html @@ -0,0 +1,200 @@ + + + + [Mageia-dev] GNOME3 ? + + + + + + + + + +

[Mageia-dev] GNOME3 ?

+ Frank Griffin + ftg at roadrunner.com +
+ Tue Jun 14 15:13:04 CEST 2011 +

+
+ +
On 06/14/2011 08:56 AM, Dexter Morgan wrote:
+> if you can provide the urpmi logs i would be glad to fix this as
+> quickly as possible
+I didn't keep the stdout, although the fact that the package is 
+installed is logged in /var/log/messages, the conflict errors are not.  
+However, the last ones I noticed were gnome-themes-standard 3.0 
+conflicting with gnome-themes-standard 2.32 (many, many files).
+
+You can probably reproduce this fairly easily by doing a fresh install 
+of MGA 1 and then doing an --auto-select with the Cauldron repositories.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005610.html b/zarb-ml/mageia-dev/2011-June/005610.html new file mode 100644 index 000000000..fd7779c40 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005610.html @@ -0,0 +1,206 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ Frank Griffin + ftg at roadrunner.com +
+ Tue Jun 14 15:16:24 CEST 2011 +

+
+ +
On 06/14/2011 09:07 AM, Wolfgang Bornath wrote:
+> So, IMHO this discussion is as meaningless as the famous/infamous vi
+> vs emacs discussions of way back when.
+
++1
+
+Not to mention that if you don't like getting emails, you can always 
+simply use the archives to find what interests you.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005611.html b/zarb-ml/mageia-dev/2011-June/005611.html new file mode 100644 index 000000000..3445f04f9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005611.html @@ -0,0 +1,262 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Jun 14 15:24:39 CEST 2011 +

+
+ +
On 14 June 2011 14:30, Michael Scherer <misc at zarb.org> wrote:
+>> > do we wait firefox 5 rc or we can start to update to firefox 5 soon ?
+>>
+>> Mandriva now has several packages for firefox (like for chromium), following
+>> the upstream channels, maybe we could envision doing it too ?
+>
+> That's 3 times the work however, especially for extensions.
+
+No.
+Either they're compat with firefox-4/5/6 or not
+(any combinaison)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005612.html b/zarb-ml/mageia-dev/2011-June/005612.html new file mode 100644 index 000000000..0f5dba868 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005612.html @@ -0,0 +1,206 @@ + + + + [Mageia-dev] GNOME3 ? + + + + + + + + + +

[Mageia-dev] GNOME3 ?

+ Dexter Morgan + dmorganec at gmail.com +
+ Tue Jun 14 15:27:29 CEST 2011 +

+
+ +
On Tue, Jun 14, 2011 at 3:13 PM, Frank Griffin <ftg at roadrunner.com> wrote:
+> On 06/14/2011 08:56 AM, Dexter Morgan wrote:
+>>
+>> if you can provide the urpmi logs i would be glad to fix this as
+>> quickly as possible
+>
+> I didn't keep the stdout, although the fact that the package is installed is
+> logged in /var/log/messages, the conflict errors are not.  However, the last
+> ones I noticed were gnome-themes-standard 3.0 conflicting with
+> gnome-themes-standard 2.32 (many, many files).
+>
+> You can probably reproduce this fairly easily by doing a fresh install of
+> MGA 1 and then doing an --auto-select with the Cauldron repositories.
+>
+
+Conflicts should be fixed now.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005613.html b/zarb-ml/mageia-dev/2011-June/005613.html new file mode 100644 index 000000000..45799ba8a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005613.html @@ -0,0 +1,220 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ Bruno Cornec + Bruno.Cornec at hp.com +
+ Tue Jun 14 15:33:07 CEST 2011 +

+
+ +
Lee Forest said on Tue, Jun 14, 2011 at 08:52:50AM -0400:
+
+> Only a couple people so far are hooked on mailing
+> lists. 
+
+Yes, all the ones who really work on making the distro ! And I can't take
+that opportunity to thank them :-)
+
+My self +1 for ML, -1 for forums.
+
+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-June/005614.html b/zarb-ml/mageia-dev/2011-June/005614.html new file mode 100644 index 000000000..0b06a967f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005614.html @@ -0,0 +1,217 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ Lee Forest + lee8oi at gmail.com +
+ Tue Jun 14 15:38:03 CEST 2011 +

+
+ +
And keeping one golden rule of software development in mind, don't let your
+system do redundant tasks. Look how many times a conversation is repeated
+throughout its life time in a mailing list. Thats alot of redundant data
+using up server traffic. In a forum everything is more central. A lot less
+redundancy. and you can still get topic replies. What about being able to
+reply to the notification email to reply to the thread? That would be a
+start on a compromise. Nice feature for a modern forum/mailing system. Maybe
+also be able to subscribe  to forum catagories. This would allow those who
+wish for emails to still use mail.
+On Jun 14, 2011 9:16 AM, "Frank Griffin" <ftg at roadrunner.com> wrote:
+> On 06/14/2011 09:07 AM, Wolfgang Bornath wrote:
+>> So, IMHO this discussion is as meaningless as the famous/infamous vi
+>> vs emacs discussions of way back when.
+>
+> +1
+>
+> Not to mention that if you don't like getting emails, you can always
+> simply use the archives to find what interests you.
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110614/27a82161/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005615.html b/zarb-ml/mageia-dev/2011-June/005615.html new file mode 100644 index 000000000..b62a4f2e6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005615.html @@ -0,0 +1,221 @@ + + + + [Mageia-dev] Question about backports: calibre (bug 1659) + + + + + + + + + +

[Mageia-dev] Question about backports: calibre (bug 1659)

+ Michael Scherer + misc at zarb.org +
+ Tue Jun 14 15:41:56 CEST 2011 +

+
+ +
Le mardi 14 juin 2011 à 03:00 -0700, Radu-Cristian FOTESCU a écrit :
+> 
+> > So why does it have to be treated differently than the others since
+> > there is nothing special about this release cycle  ?
+> 
+> Michael, please give me an example of an application that releases on average 5 time a month. Really, give me an example.
+
+Release frequency never was a criteria for differentiating between
+pushing something to updates and something to backports. 
+
+And I see no reason why it would be in favor of doing a bug fix update
+rather than a backport, especially if we ask to do a more stringent QA
+checking on updates, as it would put too much work on the team.
+
+> And, like it or not, calibre is _THE_ application for e-book lovers. For e-book users, it's as important as Firefox or
+>  Chromium is for the rest of the people.
+
+Again, that's not a criteria. Every software is important to at least
+one person, and that would mean we should update everything if we start
+to update everything important to one group of users. 
+
+
+> Also, Mageia 1.0 was released with a version of this application shamefully old. 
+>
+> Fedora made a better judgment (I might just consider switching to Fedora, although I like Mageia more): 
+> they released F15 with a recent version of calibre, 0.7.56, but they added in updates 0.8.0. For the 
+> time being they stopped at 0.8.0, and only in Rawhide they pushed 0.8.4, which in my opinion is a good 
+> judgment that would be a _balance_ between:
+> 
+> -- announced bug-fixes
+> -- announced new features
+> -- announced new hardware supported
+> -- ad-hoc assessment of the risk brought by the new features (a heuristic
+> process based mainly on experience as a user, experience as a software
+> developer, and common-sense).Of course, the people who _make_ a distro are 
+> its _owners_, and of course the reasoning of those who make Fedora is not 
+> necessarily the best example to be followed by everybody, but as it happens, I prefer their brains.
+
+You still do not explain where is the problem of using backports for
+that. 
+
+And for what it is worth, Fedora is discussing having separate update
+and backport ( https://fedorahosted.org/fesco/ticket/515 ), even if the
+discussion seems to be going nowhere at the moment 
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005616.html b/zarb-ml/mageia-dev/2011-June/005616.html new file mode 100644 index 000000000..b17188573 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005616.html @@ -0,0 +1,190 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Michael Scherer + misc at zarb.org +
+ Tue Jun 14 15:43:45 CEST 2011 +

+
+ +
Le mardi 14 juin 2011 à 07:55 +0200, Thorsten van Lil a écrit :
+> Am Montag, 13. Juni 2011, 23:28:04 schrieb Renaud MICHEL:
+> > On lundi 13 juin 2011 at 23:06, Thorsten van Lil wrote :
+> > > A rolling release has following advantages:
+> > > 1. the distribution is always up to date (also hardware support)
+> > > 2. no re-install over and over again
+> > 
+> > I don't get it why people think a re-install is necessary.
+> > My current computer was installed with mandriva 2007 (don't remember if it
+> > was .0 or .1), it is now mageia 1 and has been updated to all intermediary
+> > mdv releases.
+> 
+> An Upgrade is nearly the same, than reinstalling. The difference is only, that 
+> you can use your system in the mean time and you are not forced to install the 
+> missing packages. 
+
+Rolling is just the same as upgrade, except it take X months to do it
+with a small change everyday instead of having thing upgraded every X
+months.
+
+> > > This could look like this:
+> > > Bring up a release once a year. The core (kernel, glib, ...) will only
+> > > get  minor updates. Apllications like firefox, libreoffice, ... will
+> > > always be up to date (rolling). Maybe also the desktop envirenments
+> > > could be rolling but this is very heavy.
+> > 
+> > If I understood correctly, that is exactly what the backports should
+> > provide, new versions of programs when possible (no update of half of the
+> > core system libraries).
+> > 
+> 
+> Yes, but Backports are not officially supported and we wouldn't advice new users 
+> to backports normally. 
+
+I am sorry, but I fail to follow your reasoning.
+
+Why wouldn't you do a comparison where in one case not recommend
+backports, and in the others, recommend them for the whole system ?
+
+If this is for ressource related reasons, why would we have the
+ressources in one case and not in the others ? 
+
+And as I said in another mail, if people want to follow arch linux and
+do a better job, maybe they should start to explain what are the weak
+points of the distribution and then do proposal on stuff that can be
+done better instead of asking to copy cat hoping this would be better.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005617.html b/zarb-ml/mageia-dev/2011-June/005617.html new file mode 100644 index 000000000..a509930a4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005617.html @@ -0,0 +1,202 @@ + + + + [Mageia-dev] Question about backports: calibre (bug 1659) + + + + + + + + + +

[Mageia-dev] Question about backports: calibre (bug 1659)

+ Angelo Naselli + anaselli at linux.it +
+ Tue Jun 14 15:52:03 CEST 2011 +

+
+ +
martedì 14 giugno 2011 alle 12:00, Radu-Cristian FOTESCU ha scritto:
+> Fedora made a better judgment
+I didn't find my commoncpp2 version there, for me is blocking, they
+ship 0.7.x and 0.8.x is out with *important* fixings!
+Every time a kernel update (upgrade) is pushed, we need to wait
+nvidia kernel modules or switch to free drivers... 
+so all that glitters is not gold  (well i hope that is the English meaning)
+
+Said that every distros have problems. Mageia has no monodevelop
+for me taht's blocking as well...
+
+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/20110614/b761afda/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005618.html b/zarb-ml/mageia-dev/2011-June/005618.html new file mode 100644 index 000000000..85a7d317a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005618.html @@ -0,0 +1,217 @@ + + + + [Mageia-dev] GNOME3 ? + + + + + + + + + +

[Mageia-dev] GNOME3 ?

+ Frank Griffin + ftg at roadrunner.com +
+ Tue Jun 14 15:57:51 CEST 2011 +

+
+ +
On 06/14/2011 09:27 AM, Dexter Morgan wrote:
+> Conflicts should be fixed now.
+>
+
+In order to separate the upgrade issues, I just did a fresh Cauldron 
+GNOME install in a VBox VM, and tried to log in.
+
+I get the flat (not striped) blue background, probably because your 
+dependency fix hasn't come through yet, and I see the "Activity     
+Date     Username" flash briefly at the top of the screen and then 
+disappear.  If you leave it that way, every 5 or 10 seconds the "Oops, 
+something went wrong" screen flashes and disappears.
+
+If I try to install gnome-themes-standard, I get conflicts with 
+gnome-themes-2.32, which has been pulled in by epiphany-2.32.  Removing 
+gnome-themes-2.32 (along with epiphany) allows gnome-themes-standard to 
+install cleanly, at which point I get exactly the same behavior but with 
+a blue striped background.
+
+The only error I can find is in /var/log/messages, and says 
+"gnome-session: Warning - application gnome-shell.desktop failed to 
+register before timeout".  There is no mention in dmesg of libnsl or gnome.
+
+In short, the libnsl issue seems to be upgrade-related, but everything 
+else is just broken out-of-the-box.
+
+If you try to reproduce this, you have to use 128K video memory and 
+enable 3D acceleration in VBox, otherwise you get "fallback" mode, which 
+appears to work fine.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005619.html b/zarb-ml/mageia-dev/2011-June/005619.html new file mode 100644 index 000000000..89193fcf4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005619.html @@ -0,0 +1,202 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ Frank Griffin + ftg at roadrunner.com +
+ Tue Jun 14 16:03:39 CEST 2011 +

+
+ +
On 06/14/2011 09:38 AM, Lee Forest wrote:
+>
+> And keeping one golden rule of software development in mind, don't let 
+> your system do redundant tasks. Look how many times a conversation is 
+> repeated throughout its life time in a mailing list. Thats alot of 
+> redundant data using up server traffic.
+>
+That's not caused by an ML, it's caused by people being lazy and quoting 
+the entire message to which they're replying, which is a breach of 
+netiquette.  As is top-posting :-)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005620.html b/zarb-ml/mageia-dev/2011-June/005620.html new file mode 100644 index 000000000..c6a55b261 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005620.html @@ -0,0 +1,225 @@ + + + + [Mageia-dev] GNOME3 ? + + + + + + + + + +

[Mageia-dev] GNOME3 ?

+ Dexter Morgan + dmorganec at gmail.com +
+ Tue Jun 14 16:04:31 CEST 2011 +

+
+ +
On Tue, Jun 14, 2011 at 3:57 PM, Frank Griffin <ftg at roadrunner.com> wrote:
+> On 06/14/2011 09:27 AM, Dexter Morgan wrote:
+>>
+>> Conflicts should be fixed now.
+>>
+>
+> In order to separate the upgrade issues, I just did a fresh Cauldron GNOME
+> install in a VBox VM, and tried to log in.
+>
+> I get the flat (not striped) blue background, probably because your
+> dependency fix hasn't come through yet, and I see the "Activity     Date
+> Username" flash briefly at the top of the screen and then disappear.  If you
+> leave it that way, every 5 or 10 seconds the "Oops, something went wrong"
+> screen flashes and disappears.
+>
+> If I try to install gnome-themes-standard, I get conflicts with
+> gnome-themes-2.32, which has been pulled in by epiphany-2.32.  Removing
+> gnome-themes-2.32 (along with epiphany) allows gnome-themes-standard to
+> install cleanly, at which point I get exactly the same behavior but with a
+> blue striped background.
+
+do you have urpmi log this time ?
+
+> The only error I can find is in /var/log/messages, and says "gnome-session:
+> Warning - application gnome-shell.desktop failed to register before
+> timeout".  There is no mention in dmesg of libnsl or gnome.
+
+do you have the logs from ~/.xsession-errors  when the session fails please ?
+
+> In short, the libnsl issue seems to be upgrade-related, but everything else
+> is just broken out-of-the-box.
+>
+> If you try to reproduce this, you have to use 128K video memory and enable
+> 3D acceleration in VBox, otherwise you get "fallback" mode, which appears to
+> work fine.
+>
+>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005621.html b/zarb-ml/mageia-dev/2011-June/005621.html new file mode 100644 index 000000000..841c533d9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005621.html @@ -0,0 +1,172 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Thorsten van Lil + tvl83 at gmx.de +
+ Tue Jun 14 16:16:00 CEST 2011 +

+
+ +
Am 14.06.2011 15:43, schrieb Michael Scherer:
+>> Yes, but Backports are not officially supported and we wouldn't advice new users
+>> >  to backports normally.
+> I am sorry, but I fail to follow your reasoning.
+
+What I meant is: We can't tell the user to use the backports and if he 
+runs in trouble we let him alone and say he shouldn't have used it. If 
+we officially support and care for backports, than this is a different case.
+
+
+> And as I said in another mail, if people want to follow arch linux and
+> do a better job, maybe they should start to explain what are the weak
+> points of the distribution and then do proposal on stuff that can be
+> done better instead of asking to copy cat hoping this would be better.
+
+I don't want a full rolling release, because of the listed 
+disadvantages. So, if you ask me what is "wrong" with Arch, I would say:
+* due to the rolling release, it's nearly vanilla. This doesn't match 
+requirements of Mageia
+* no innovations (because of vanilla)
+* a rolling core system has a negative correlation with it's stability
+* heavy work load
+* ...
+
+So, I don't ask for a copy of Arch nor any other distribution. I asked 
+(although it wasn't my idea) for something new. An compromise: a light 
+rolling release.
+
+Further lack of clarity?
+
+Greetings,
+Thorsten
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005622.html b/zarb-ml/mageia-dev/2011-June/005622.html new file mode 100644 index 000000000..b1e4b1ec6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005622.html @@ -0,0 +1,241 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ Romain d'Alverny + rda at mageia.org +
+ Tue Jun 14 16:21:41 CEST 2011 +

+
+ +
On Tue, Jun 14, 2011 at 15:38, Lee Forest <lee8oi at gmail.com> wrote:
+> And keeping one golden rule of software development in mind, don't let your
+> system do redundant tasks.
+
+As golden as the need to not to have redundancy: it depends.
+Redundancy can be very, very appreciated. But not always in a
+discussion (be it with mail or web-based forum) where appropriately
+quoting is very, very appreciated too. :-)
+
+> What about being able to [...]
+
+Yes, that could be nice, only, Mageia is not about building first an
+improved mail/forum gateway, but about building first an improved
+operating system. You can't blame people for focusing on this and
+doing it with tools they are productive with already.
+
+Migrating everyone to forums is, here, not acceptable. Dismissing
+others from each side as well. Migrating everyone to ml was not even
+considered (or we wouldn't have planned to have forums, or we would
+have let them to local groups only).
+
+That this question gets discussed on and on is a (good) sign that
+people are motivated to participate. But are you motivated enough to
+cross the bridge, to change your habits and to meet the people where
+they gather to build this thing, and to instill improvements? The
+bridge is wide open and there's so much to built it further. Only,
+it's not necessarily what you expect it to be, at first.
+
+There have been several suggestions as to build a forum/mail gateway,
+only without the means to actually implement it within our
+infrastructure. For what is existing, tux99 used to provide a 3rd
+place showcase gateway in the past but I am not sure what its future
+status will be; or you have
+http://news.gmane.org/gmane.linux.mageia.devel or
+http://blog.gmane.org/gmane.linux.mageia.devel or we could consider
+another gateway if it's worth it (Google groups? other?) and if
+there's someone to lend a hand to... no, to join sysadmin team for
+that (and other things).
+
+Speaking of focus, this thread is about the release cycle. Now you are
+welcome to open a bug http://bugs.mageia.org/ in the Websites,
+forums.mageia.org section I guess; if you think it's worth it to
+dig/document this ml/forum thing further (and even better, if you have
+a better workable solution at hand). But please let this thread on
+topic.
+
+Romain
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005623.html b/zarb-ml/mageia-dev/2011-June/005623.html new file mode 100644 index 000000000..6db5f7bc9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005623.html @@ -0,0 +1,303 @@ + + + + [Mageia-dev] GNOME3 ? + + + + + + + + + +

[Mageia-dev] GNOME3 ?

+ Frank Griffin + ftg at roadrunner.com +
+ Tue Jun 14 16:22:21 CEST 2011 +

+
+ +
On 06/14/2011 10:04 AM, Dexter Morgan wrote:
+> On Tue, Jun 14, 2011 at 3:57 PM, Frank Griffin<ftg at roadrunner.com>  wrote:
+>> On 06/14/2011 09:27 AM, Dexter Morgan wrote:
+>> If I try to install gnome-themes-standard, I get conflicts with
+>> gnome-themes-2.32, which has been pulled in by epiphany-2.32.  Removing
+>> gnome-themes-2.32 (along with epiphany) allows gnome-themes-standard to
+>> install cleanly, at which point I get exactly the same behavior but with a
+>> blue striped background.
+> do you have urpmi log this time ?
+
+No, but the errors are very straightforward.  gnome-themes-standard 
+conflicts with gnome-themes-2.32 on 5 or 6 files.  If you urpme 
+gnome-themes-2.32, it wants to remove epiphany and epiphany-server, 
+which probably shouldn't be there to begin with.  If you allow this, 
+then installing gnome-themes-standard is fine.  The point is that if 
+you're installing GNOME 3.0, you probably shouldn't be installing 2.32 
+packages.  Isn't there an evolution 3.0 ?  Should there be ?
+
+> do you have the logs from ~/.xsession-errors  when the session fails please ?
+
+
+Here is .xsession-errors:
+
+/etc/X11/gdm/Xsession: Beginning session setup...
+/etc/X11/gdm/Xsession: ssh-agent not found!
+/etc/X11/gdm/Xsession: Setup done, will execute: 
+/usr/share/X11/xdm/Xsession GNOME
+localhost being added to access control list
+GNOME_KEYRING_CONTROL=/tmp/keyring-vzwU67
+GNOME_KEYRING_CONTROL=/tmp/keyring-vzwU67
+GPG_AGENT_INFO=/tmp/keyring-vzwU67/gpg:0:1
+GNOME_KEYRING_CONTROL=/tmp/keyring-vzwU67
+GPG_AGENT_INFO=/tmp/keyring-vzwU67/gpg:0:1
+GNOME_KEYRING_CONTROL=/tmp/keyring-vzwU67
+GPG_AGENT_INFO=/tmp/keyring-vzwU67/gpg:0:1
+SSH_AUTH_SOCK=/tmp/keyring-vzwU67/ssh
+OpenGL Info: Using XSHM for GLX_EXT_texture_from_pixmap
+     JS ERROR: !!!   Exception was: Error: Requiring NetworkManager, 
+version none: Typelib file for namespace 'NetworkManager' (any version) 
+not found
+     JS ERROR: !!!     lineNumber = '0'
+     JS ERROR: !!!     fileName = 'gjs_throw'
+     JS ERROR: !!!     stack = '("Requiring NetworkManager, version 
+none: Typelib file for namespace 'NetworkManager' (any version) not 
+found")@gjs_throw:0
+@/usr/share/gnome-shell/js/ui/status/network.js:8
+'
+     JS ERROR: !!!     message = 'Requiring NetworkManager, version 
+none: Typelib file for namespace 'NetworkManager' (any version) not found'
+       JS LOG: NMApplet is not supported. It is possible that your 
+NetworkManager version is too old
+       JS LOG: GNOME Shell started at Tue Jun 14 2011 10:07:16 GMT-0400 
+(EDT)
+
+(gnome-shell:2882): GdmUser-WARNING **: Unable to load CK history: no 
+seat-id found
+gnome-session[2661]: WARNING: Application 'gnome-shell.desktop' failed 
+to register before timeout
+Initializing tracker-miner-fs...
+Tracker-Message: Checking XDG_DATA_HOME is writable and exists
+Tracker-Message:   XDG_DATA_HOME is '(null)'
+Tracker-Message:   Path is OK
+Tracker-Message:   XDG_DATA_HOME set to '/home/dummy500/.local/share'
+Tracker-Message:   Path is OK
+Tracker-Message: Setting process priority
+Tracker-Message: Setting up monitor for changes to config 
+file:'/home/dummy500/.config/tracker/tracker-miner-fs.cfg'
+Initializing tracker-store...
+Tracker-Message: Checking XDG_DATA_HOME is writable and exists
+Tracker-Message:   XDG_DATA_HOME is '(null)'
+Tracker-Message:   Path is OK
+Tracker-Message:   XDG_DATA_HOME set to '/home/dummy500/.local/share'
+Tracker-Message:   Path is OK
+Tracker-Message: Setting up monitor for changes to config 
+file:'/home/dummy500/.config/tracker/tracker-store.cfg'
+Tracker-Message: Loading defaults into GKeyFile...
+Tracker-Message: Loading defaults into GKeyFile...
+Tracker-Message: Log verbosity is set to 0, disabling D-Bus client lookup
+Tracker-Message: Registering D-Bus service...
+   Name:'org.freedesktop.Tracker1'
+
+(gnome-shell:2882): Clutter-CRITICAL **: clutter_actor_queue_relayout: 
+assertion `CLUTTER_IS_ACTOR (self)' failed
+
+** (polkit-gnome-authentication-agent-1:3085): WARNING **: Unable to 
+register authentication agent: 
+GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: An authentication 
+agent already exists for the given subject
+Cannot register authentication agent: 
+GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: An authentication 
+agent already exists for the given subject
+Failed to play sound: File or data not found
+Tracker-Message: Setting up monitor for changes to config 
+file:'/home/dummy500/.config/tracker/tracker-status-icon.cfg'
+** Message: Loading defaults into GKeyFile...
+Starting log:
+   File:'/home/dummy500/.local/share/tracker/tracker-store.log'
+Starting log:
+   File:'/home/dummy500/.local/share/tracker/tracker-miner-fs.log'
+Cannot open /dev/input/eventX: Permission denied
+Cannot open /dev/input/eventX: Permission denied
+Cannot open /dev/input/eventX: Permission denied
+Cannot open /dev/input/eventX: Permission denied
+Cannot open /dev/input/eventX: Permission denied
+Deprecated use of my() in false conditional at /usr/bin/mgaapplet line 712.
+Deprecated use of my() in false conditional at /usr/bin/mgaapplet line 918.
+
+(gnome-shell:2882): Clutter-CRITICAL **: clutter_actor_queue_relayout: 
+assertion `CLUTTER_IS_ACTOR (self)' failed
+
+(gnome-shell:2882): Clutter-CRITICAL **: clutter_actor_queue_relayout: 
+assertion `CLUTTER_IS_ACTOR (self)' failed
+
+(gnome-shell:2882): Clutter-CRITICAL **: clutter_actor_queue_relayout: 
+assertion `CLUTTER_IS_ACTOR (self)' failed
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005624.html b/zarb-ml/mageia-dev/2011-June/005624.html new file mode 100644 index 000000000..89a7adcd9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005624.html @@ -0,0 +1,208 @@ + + + + [Mageia-dev] Question about backports: calibre (bug 1659) + + + + + + + + + +

[Mageia-dev] Question about backports: calibre (bug 1659)

+ Stefano Negro + stblack at gmail.com +
+ Tue Jun 14 16:22:38 CEST 2011 +

+
+ +
2011/6/14 Angelo Naselli <anaselli at linux.it>
+
+> martedì 14 giugno 2011 alle 12:00, Radu-Cristian FOTESCU ha scritto:
+> .....
+>
+> Said that every distros have problems. Mageia has no monodevelop
+> for me taht's blocking as well...
+>
+
+I will push monodevelop in svn asap (maybe this evening), for the revision
+of my mentor.
+
+
+>
+> Cheers,
+>         Angelo
+>
+
+
+
+-- 
+Ciao
+Stblack
+http://stblack.blogspot.com/
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110614/c2de0d6a/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005625.html b/zarb-ml/mageia-dev/2011-June/005625.html new file mode 100644 index 000000000..db2e35e9c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005625.html @@ -0,0 +1,212 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ Lee Forest + lee8oi at gmail.com +
+ Tue Jun 14 16:22:42 CEST 2011 +

+
+ +
On 06/14/2011 10:03 AM, Frank Griffin wrote:
+> On 06/14/2011 09:38 AM, Lee Forest wrote:
+>>
+>> And keeping one golden rule of software development in mind, don't
+>> let your system do redundant tasks. Look how many times a
+>> conversation is repeated throughout its life time in a mailing list.
+>> Thats alot of redundant data using up server traffic.
+>>
+> That's not caused by an ML, it's caused by people being lazy and
+> quoting the entire message to which they're replying, which is a
+> breach of netiquette.  As is top-posting :-)
+Android mail does that by default. But that just proves my other point.
+Half the time these replies complaining about top posting, lazyness, or
+'netiquette' are being shot back instead of useful respones. In a forum
+this is much less of a problem. Most forums are only setup to send just
+your own reply to the topic, and quoting a specific post instead of the
+whole thread. Thus not letting the user quote that much at a time by
+default. Less redundancy by design, and we can move past the
+'netiquette' complaints and focus on the topics more. And in the process
+actually modernize this communication system in a way that moves AWAY
+from mailboxes bombed with redundancy. Don't count on the users to use
+'netiquette' because its been long proven that 'common sense is not all
+that common', and its by definition 'insane' to expect everyone to use
+it. Because it will always be a problem with some new users who are new
+to mailing lists.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005626.html b/zarb-ml/mageia-dev/2011-June/005626.html new file mode 100644 index 000000000..dd0aadd6c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005626.html @@ -0,0 +1,219 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ Frank Griffin + ftg at roadrunner.com +
+ Tue Jun 14 16:42:16 CEST 2011 +

+
+ +
On 06/14/2011 10:22 AM, Lee Forest wrote:
+> On 06/14/2011 10:03 AM, Frank Griffin wrote:
+>> That's not caused by an ML, it's caused by people being lazy and
+>> quoting the entire message to which they're replying, which is a
+>> breach of netiquette.  As is top-posting :-)
+> Android mail does that by default.
+So does Thunderbird.  That's no reason to not prune the quote.
+
+> But that just proves my other point.
+> Half the time these replies complaining about top posting, lazyness, or
+> 'netiquette' are being shot back instead of useful respones.
+
+Well, aside from the fact that nobody here "owes" you a reply, and that 
+you're lucky to get one at all if you abuse the rules of the ML, forums 
+use considerably more system resource than text-based MLs as regards 
+footprint of the servers and clients and bandwidth.  
+Unnecessarily-quoted text is only a resource problem to archiving 
+services, and if you're not one you don't get to complain.
+
+You don't have to receive emails to be registered on most MLs.  You can 
+register, which allows you to post to the ML, and opt to receive no mail 
+from the list, then use the archives to read what you want.
+
+> Don't count on the users to use
+> 'netiquette' because its been long proven that 'common sense is not all
+> that common', and its by definition 'insane' to expect everyone to use
+> it. Because it will always be a problem with some new users who are new
+> to mailing lists.
+
+Nobody here is "counting" on anything.  People who don't bother to 
+follow netiquette will generally just be ignored after the first few 
+violations, which doesn't bother the rest of us a bit.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005627.html b/zarb-ml/mageia-dev/2011-June/005627.html new file mode 100644 index 000000000..9e46a9f6f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005627.html @@ -0,0 +1,266 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Jun 14 16:43:06 CEST 2011 +

+
+ +
'Twas brillig, and Lee Forest at 14/06/11 13:52 did gyre and gimble:
+> mailing list might work best for a couple people but is it worth
+> inconveniencing the rest of the word because you are a die hard mailing
+> list user
+
+I've posted the arguments before and I'll do it again, despite this
+thread going dangerously off topic.
+
+I find the use of forums to be a great drawback to project engagement as
+an upstream developer. I have to read communities from several updateam
+projects and I get as annoyed about forums as I do about people posting
+in HTML on mailing lists.
+
+Forums are disjoint and individually styled. When you are jumping from
+one project to another to get through your daily grind of information,
+it is exceptionally annoying to have to adjust your eyes and the way you
+operate to cope with the styles, features, login system etc. of each
+individual forums (forii, forum?).
+
+I want the information from these 30 or so projects I'm involved in to
+be available to me in one place, not have a series of inconvenient
+bookmarks and a procedure of checking one, then the next then the one
+after that until I've done the rounds (and of course repeating that
+procedure throughout the day if I want to see any new topics!). It's
+much less time consuming to have a single UI and central store of
+information in which I can look.
+
+Perhaps if all the forums could be aggregated into one handy feed per
+project and stripped of all their styling I could agree, but then that
+would just be reinventing mailing lists!
+
+It's all too easy to get lured by the guise of a forum-based system when
+you only follow a couple of projects, but please consider those of us
+who have several projects to follow.
+
+
+
+As for the server traffic argument, this is what NNTP is for and GMane
+does an excellent service of collecting and aggregating mailing list
+from most open source projects. When you look at the size of their feeds
+you'll realise just how many projects are run on mailing lists.
+
+
+Just like IRC, the fresh faced and full of wonder souls (not to mention
+many other types of souls too, I'm just picking on one demographic that
+suggests it more often than others!) often comment about how some more
+"modern" system is more appropriate for interaction. I don't dispute the
+lower barrier of entry for forums, and they can be a good way to engage
+with a less technical audience, but I will never be able to get involved
+in them (except when people specifically ask me to comment on topics) as
+it's just far too much of an intrusion in my daily grind.
+
+
+Build a nice forum to mail gateway (and vice versa) and it would likely
+please everyone. Technology can solve this!
+
+I won't comment again on this topic (at least on this thread!).
+
+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-June/005628.html b/zarb-ml/mageia-dev/2011-June/005628.html new file mode 100644 index 000000000..ff8ead273 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005628.html @@ -0,0 +1,163 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Tue Jun 14 16:59:52 CEST 2011 +

+
+ +
On Tue, 14 Jun 2011, Thorsten van Lil wrote:
+
+> I don't want a full rolling release, because of the listed disadvantages. So, 
+> if you ask me what is "wrong" with Arch, I would say:
+> * due to the rolling release, it's nearly vanilla. This doesn't match 
+> requirements of Mageia
+> * no innovations (because of vanilla)
+> * a rolling core system has a negative correlation with it's stability
+> * heavy work load
+> * ...
+>
+> So, I don't ask for a copy of Arch nor any other distribution. I asked 
+> (although it wasn't my idea) for something new. An compromise: a light 
+> rolling release.
+
+This is exactly what release + updates + backports can be, the only 
+requirement is enough people to do the work. I do not understand what 
+people are saying about backports being "unsupported". IMHO we should 
+either have backports that are supported, with fixes for security issues 
+and important bugs, or no backports.
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005629.html b/zarb-ml/mageia-dev/2011-June/005629.html new file mode 100644 index 000000000..9ef01d0a7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005629.html @@ -0,0 +1,182 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Anne nicolas + ennael at mageia.org +
+ Tue Jun 14 17:02:40 CEST 2011 +

+
+ +
2011/6/14 Christiaan Welvaart <cjw at daneel.dyndns.org>
+
+> On Tue, 14 Jun 2011, Thorsten van Lil wrote:
+>
+>  I don't want a full rolling release, because of the listed disadvantages.
+>> So, if you ask me what is "wrong" with Arch, I would say:
+>> * due to the rolling release, it's nearly vanilla. This doesn't match
+>> requirements of Mageia
+>> * no innovations (because of vanilla)
+>> * a rolling core system has a negative correlation with it's stability
+>> * heavy work load
+>> * ...
+>>
+>> So, I don't ask for a copy of Arch nor any other distribution. I asked
+>> (although it wasn't my idea) for something new. An compromise: a light
+>> rolling release.
+>>
+>
+> This is exactly what release + updates + backports can be, the only
+> requirement is enough people to do the work. I do not understand what people
+> are saying about backports being "unsupported". IMHO we should either have
+> backports that are supported, with fixes for security issues and important
+> bugs, or no backports.
+>
+
+I guess because of Mandriva policy. We did provide backports but it was
+explicitely said to be unsupported. "Use it at your own risks"
+We may have to rewrite  this and make things clear
+
+>
+>
+>    Christiaan
+>
+
+
+
+-- 
+Anne
+http://www.mageia.org
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110614/27b02af6/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005630.html b/zarb-ml/mageia-dev/2011-June/005630.html new file mode 100644 index 000000000..cb82cba56 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005630.html @@ -0,0 +1,197 @@ + + + + [Mageia-dev] GNOME3 ? + + + + + + + + + +

[Mageia-dev] GNOME3 ?

+ Damien Lallement + mageia at damsweb.net +
+ Tue Jun 14 16:09:44 CEST 2011 +

+
+ +
Le 14/06/2011 16:04, Dexter Morgan a écrit :
+> [...]
+> do you have the logs from ~/.xsession-errors  when the session fails please ?
+
+My session fails each time I try to launch an apps (even 
+gnome-terminal!). Here is my log: http://pastebin.mandriva.com/23048
+Nothing bad in my Xorg.log
+
+Help, I'm under IceWM now! :-p
+-- 
+Damien Lallement
+Treasurer of Mageia.Org
+
+twitter: damsweb - IRC: damsweb/coincoin
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005631.html b/zarb-ml/mageia-dev/2011-June/005631.html new file mode 100644 index 000000000..1704f8b7a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005631.html @@ -0,0 +1,155 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Thorsten van Lil + tvl83 at gmx.de +
+ Tue Jun 14 17:16:10 CEST 2011 +

+
+ +
Am 14.06.2011 17:02, schrieb Anne nicolas:
+>> I do not understand what people are saying about backports being
+>> "unsupported". IMHO we should either have backports that are
+>> supported, with fixes for security issues and important bugs, or no
+>> backports.
+>>
+>
+> I guess because of Mandriva policy. We did provide backports but it was
+> explicitely said to be unsupported. "Use it at your own risks"
+
+Exactly. If we don't restrict the use of backports on once own risk, I'm 
+at least totally happy with it :)
+
+Greetings,
+Thorsten
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005632.html b/zarb-ml/mageia-dev/2011-June/005632.html new file mode 100644 index 000000000..e47ae2149 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005632.html @@ -0,0 +1,156 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Tue Jun 14 17:40:32 CEST 2011 +

+
+ +
2011/6/14 Anne nicolas <ennael at mageia.org>:
+>
+> I guess because of Mandriva policy. We did provide backports but it was
+> explicitely said to be unsupported. "Use it at your own risks"
+> We may have to rewrite  this and make things clear
+
+Do you mean, just telling people that it is no risk or do you mean a
+change which lessens the risk?
+As Michael wrote earlier in this thread, if there was the risk to
+break the system by low quality of backports then the quality has to
+be improved (not his own words but that's how I understood it).
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005633.html b/zarb-ml/mageia-dev/2011-June/005633.html new file mode 100644 index 000000000..6dc094105 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005633.html @@ -0,0 +1,128 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Angelo Naselli + anaselli at linux.it +
+ Tue Jun 14 17:40:56 CEST 2011 +

+
+ +
+> I would prefer to find a better way than suggest :/
+> ( like a meta rpm pulling mgarepo, bm, the policy and rpmlint ).
+> 
+> 
+something like task-mageia-devel?
+
+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/20110614/cd3965de/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005634.html b/zarb-ml/mageia-dev/2011-June/005634.html new file mode 100644 index 000000000..6e765b51c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005634.html @@ -0,0 +1,246 @@ + + + + [Mageia-dev] forum/mailing list project + + + + + + + + + +

[Mageia-dev] forum/mailing list project

+ Lee Forest + lee8oi at gmail.com +
+ Tue Jun 14 17:42:31 CEST 2011 +

+
+ +
Mailing lists and forums I guess both have drawbacks and advantages. I am
+sorry if I sounded biased, and was off topic. I still think some kind of
+innovative new messaging/forum/blog/mailing list reimagining sounds like a
+fun project. But I do understand its not a feasible option right now for
+mageia. I definitly think im gonna ponder this more. I do have experience in
+php and other web related languages. Again sorry I was off topic in the
+other thread, and thanks for the healthy debate. Its refreshing to hear some
+brutal honesty and sense. If anyone is interested in talking more about this
+I would certainly be grateful for some constructive criticism from such a
+knowledgable group. I hope I did this right. Trying to make it a new topic.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110614/85bfd220/attachment-0001.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005635.html b/zarb-ml/mageia-dev/2011-June/005635.html new file mode 100644 index 000000000..a184b122f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005635.html @@ -0,0 +1,253 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Antoine Pitrou + solipsis at pitrou.net +
+ Tue Jun 14 17:54:05 CEST 2011 +

+
+ +
On Tue, 14 Jun 2011 14:14:02 +0200
+Samuel Verschelde <stormi at laposte.net>
+wrote:
+> 
+> Le mardi 14 juin 2011 13:56:29, Dexter Morgan a écrit :
+> > Hello,
+> > 
+> > do we wait firefox 5 rc or we can start to update to firefox 5 soon ?
+> 
+> Mandriva now has several packages for firefox (like for chromium), following 
+> the upstream channels, maybe we could envision doing it too ?
+
+As a user, I will download the mozilla.org binaries if I want to
+try/test a non-stable release. Not sure there's any point for Mageia in
+packaging beta versions (except to get feedback for distro-specific
+patches).
+
+Just my 2 cents.
+
+Regards
+
+Antoine.
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005636.html b/zarb-ml/mageia-dev/2011-June/005636.html new file mode 100644 index 000000000..624e37a14 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005636.html @@ -0,0 +1,191 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Patricia Fraser + trish at thefrasers.org +
+ Tue Jun 14 18:08:17 CEST 2011 +

+
+ +
Hi,
+
+2c from the marcomm team...
+
+> Proposal 1: 
+> 6 months release cycle -> 12 months life cycle
+> ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
+> 
+> Proposal 2: 
+> 9 months release cycle -> 18 months life cycle  
+> ( ~ opensuse and the one we used for Mageia 1 )
+> 
+> Proposal 3: 
+> 12 months release cycle -> 24 months life cycle
+> ( Mandriva > 2010.1 )
+
+The only reason for marcomm to take a position is that a release is a
+nice hook on which to hang another round of publicity.
+
+I think 9 months is good; it gives us a good amount of time to plan
+whatever marketing/comms work is needed for release time, but it's
+not too long so we fall out of the public consciousness altogether.
+
+And there are other things about us to publicise besides releases, so
+we can fill in the gaps nicely!
+
+Cheers,
+
+-- 
+Trish Fraser, JD9R RQ2D
+52.4161N,16.9303E
+di jun 14 18:04:15 CEST 2011
+GNU/Linux 1997-2010 #283226 counter.li.org
+andromeda up 0 hour(s), 26 min.
+kernel 2.6.38.7-desktop-1.mga
+--
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: signature.asc
+Type: application/pgp-signature
+Size: 490 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20110614/45746b6e/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005637.html b/zarb-ml/mageia-dev/2011-June/005637.html new file mode 100644 index 000000000..23fdfbb2b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005637.html @@ -0,0 +1,275 @@ + + + + [Mageia-dev] forum/mailing list project + + + + + + + + + +

[Mageia-dev] forum/mailing list project

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Tue Jun 14 18:09:23 CEST 2011 +

+
+ +
2011/6/14 Lee Forest <lee8oi at gmail.com>:
+> Mailing lists and forums I guess both have drawbacks and advantages. I am
+> sorry if I sounded biased, and was off topic. I still think some kind of
+> innovative new messaging/forum/blog/mailing list reimagining sounds like a
+> fun project. But I do understand its not a feasible option right now for
+> mageia. I definitly think im gonna ponder this more. I do have experience in
+> php and other web related languages. Again sorry I was off topic in the
+> other thread, and thanks for the healthy debate. Its refreshing to hear some
+> brutal honesty and sense. If anyone is interested in talking more about this
+> I would certainly be grateful for some constructive criticism from such a
+> knowledgable group. I hope I did this right. Trying to make it a new topic.
+
+/me thinks there is not much to debate. As already mentioned, all
+reasons in favour and against both platforms have been laid on the
+table for the zillionth time without ever changing by even one single
+character.
+
+Yes, a bridging tool is the only solution. Unfortunately I haven't
+seen a real working two-way bridge yet. This would only be possible if
+the number and names of the available mailing lists would match the
+available sections in the forum.
+
+ - gmane is clumsy, slow - my tests last September/October reveilled
+that with an active list you see 2 replies in the list before the
+initial mail is available in gmane. So, people using gmane for posting
+will always be behind and may destroy a thread or reply to already
+obsolete points. There were also missing mails in the middle of
+threads which made it unusable for me.
+
+ - the very nice bridge tux99 offers as a working model on
+http://mageia.linuxtech.net/forum/ (down at the moment) turned out to
+be fast and reliable during tests. Integrated into a forum, the forum
+users can participate in all mailing list discussions, but the mailing
+list people do not see any discussions which take place in other parts
+of the forum.
+
+Of course there are other half-way solutions for people not inclined
+to participate in discussion, only wanting to follow threads - you can
+always use the archives of the mailing lists and the rsa of the forum.
+
+What did I forget here?
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005638.html b/zarb-ml/mageia-dev/2011-June/005638.html new file mode 100644 index 000000000..cc636cba5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005638.html @@ -0,0 +1,274 @@ + + + + [Mageia-dev] Question about backports: calibre (bug 1659) + + + + + + + + + +

[Mageia-dev] Question about backports: calibre (bug 1659)

+ Radu-Cristian FOTESCU + beranger5ca at yahoo.ca +
+ Tue Jun 14 18:12:49 CEST 2011 +

+
+ +
> Release frequency never was a criteria for differentiating between
+> pushing something to updates and something to backports.
+
+It should be. Otherwise, we should all be using OpenOffice.org 1.0.1. -- 
+security issues set aside.
+
+> And I see no reason why it would be in favor of doing a bug fix update
+> rather than a backport, especially if we ask to do a more stringent QA
+> checking on updates, as it would put too much work on the team.
+
+Because Mageia (and Mandriva)'s vision of the concept of "backports" is not 
+compatible with my common-sense.
+
+I have not used Mandriva very much in the past, because I hate the concept of
+"backports" -- yes, Ubuntu does them too, but Ubuntu backports are totally
+unsupported, so you can imagine their "quality"... 
+
+I'd rather stick to "updates" -- this is also the reason I stopped using
+Debian, because the morons (yes, morons) were only pushing tzdata updates 
+in "volatile", not in "updates", whereas ALL the other distro weres pushing 
+tzdata updates in "updates".
+
+If Mageia considers that a 6-7 months old package (for an application that
+released 32 times in the meantime) only deserves updates in "backports", 
+then I will probably stop reporting any possible bugs with this distro 
+-- as a protest.
+
+It is indeed a matter of principle. I am personally using the latest 
+calibre installed in /opt, not the official one, but again, it's a 
+matter of principle.
+
+
+Whatever is important and comes from upstream  should go into updates IMHO. 
+Backports, in my view, only make sense if they're  coming from Release N+1 
+*and* if they represent a major version bump -- such as FF4 over FF3.6, etc.
+
+
+WRT calibre, Fedora has a simple way: it keeps a newer calibre packages in 
+updates/testing for 1 week, and if no user complains about regressions, it 
+goes into updates. This is because calibre is a "leaf" package -- no other 
+package depends on it, so it only impacts those who are using it.
+
+> Again, that's not a criteria. Every software is important to at least
+> one person, and that would mean we should update everything if we start
+> to update everything important to one group of users.
+
+I can see how important is calibre to Mageia users. Nobody noticed or cared 
+that it is an antiquated version. They could have as well used notepad.exe 
+from Win95.
+
+
+> And for what it is worth, Fedora is discussing having separate update
+> and backport ( https://fedorahosted.org/fesco/ticket/515 ), even if the
+> discussion seems to be going nowhere at the moment
+
+BS. I hope Fedora *never* uses backports!
+
+Their update policy is very clear *and* flexible:
+http://fedoraproject.org/wiki/Updates_Policy
+
+Please note these: 
+
+"Exceptions: Some classes of software will not fit in these guidelines. 
+If your package does not fit in one of the classes below, but you think 
+it should be allowed to update more rapidly . . . 
+
+
+Things that would make it more likely to grant a request:
+--  The package is a "leaf" node. Nothing depends on it or requires it."
+
+Calibre is a "leaf" package. 
+
+If not, in the same document:
+
+"All other updates must either:
+-- reach the criteria laid out in the previous section OR
+-- reach the positive Bodhi karma threshold specified by the updates submitter OR
+-- spend some minimum amount of time in updates-testing, currently one week."
+
+I am not sure why F15 stopped updating calibre to 0.8.0 in updates (Rawhide went 
+up to 0.8.4, maybe 0.8.5 now), but for the versions up to and including 0.8.0, 
+here's the dynamics of the updates:
+
+ChangeLog:
+
+* Fri May 6 2011 Kevin Fenzi <kevin at xxxxxxxxx> - 0.8.0-1
+- Update to 0.8.0
+* Wed May 4 2011 Dan HorÃak <dan at xxxxxxxx> - 0.7.59-2
+- rebuilt against podofo 0.9.1
+* Sat Apr 30 2011 Kevin Fenzi <kevin at xxxxxxxxx> - 0.7.59-1
+- Update to 0.7.59
+* Fri Apr 22 2011 Kevin Fenzi <kevin at xxxxxxxxx> - 0.7.57-1
+- Update to 0.7.57
+
+(F15 was released with 0.7.56)
+
+
+Indeed, Mageia does not have the number of packagers that Fedora has. 
+However, if Mageia's _policy_ is to rather have 6-7 months old versions in 
+updates, I should probably realize that Mageia is not for me.
+
+No, I have not, and never will use any repository called "backports". When a 
+newer stable  release of a distro is available, I should update to it if 
+updates I need are not pushed into Release N-1 "updates" (even if that release 
+is officially still supported with security patches), but again, "backports" 
+as Mandriva and Mageia are seeing them -- i.e. backporting 
+from  Cooker/Cauldron, not from "updates/testing" nor from "Release N+1" 
+-- does not fit my Zen.
+
+R-C
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005639.html b/zarb-ml/mageia-dev/2011-June/005639.html new file mode 100644 index 000000000..130849aa7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005639.html @@ -0,0 +1,256 @@ + + + + [Mageia-dev] gmane + + + + + + + + + +

[Mageia-dev] gmane

+ Antoine Pitrou + solipsis at pitrou.net +
+ Tue Jun 14 18:17:15 CEST 2011 +

+
+ +
On Tue, 14 Jun 2011 18:09:23 +0200
+Wolfgang Bornath <molch.b at googlemail.com>
+wrote:
+> 
+>  - gmane is clumsy, slow - my tests last September/October reveilled
+> that with an active list you see 2 replies in the list before the
+> initial mail is available in gmane. So, people using gmane for posting
+> will always be behind and may destroy a thread or reply to already
+> obsolete points. There were also missing mails in the middle of
+> threads which made it unusable for me.
+
+My experience with gmane is different. Yes it lags a bit but usually by
+a couple of minutes. Unless you want to use your mailing-list as some
+kind of real-time communication channel (you shouldn't ;-)), this is ok.
+
+gmane's Web UI is not great but its NNTP gateway, OTOH, works fine for
+me, both for reading and posting, using claws-mail as my NNTP client.
+
+And the fact that it doesn't ask you to sign for any kind of account is
+really nice.
+
+Regards
+
+Antoine.
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005640.html b/zarb-ml/mageia-dev/2011-June/005640.html new file mode 100644 index 000000000..aab0da1c9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005640.html @@ -0,0 +1,199 @@ + + + + [Mageia-dev] Question about backports: calibre (bug 1659) + + + + + + + + + +

[Mageia-dev] Question about backports: calibre (bug 1659)

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Tue Jun 14 18:28:43 CEST 2011 +

+
+ +
On 14 June 2011 15:52, Angelo Naselli <anaselli at linux.it> wrote:
+> martedì 14 giugno 2011 alle 12:00, Radu-Cristian FOTESCU ha scritto:
+>> Fedora made a better judgment
+> I didn't find my commoncpp2 version there, for me is blocking, they
+> ship 0.7.x and 0.8.x is out with *important* fixings!
+> Every time a kernel update (upgrade) is pushed, we need to wait
+> nvidia kernel modules or switch to free drivers...
+
+(FWIW I've not seen the nvidia proprietary kernel module fail to
+compile in about 6-8months, and the kernel got updated many times
+during the previous Cauldron release cycle).
+
+> so all that glitters is not gold  (well i hope that is the English meaning)
+>
+> Said that every distros have problems. Mageia has no monodevelop
+> for me taht's blocking as well...
+>
+> Cheers,
+>        Angelo
+>
+
+
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005641.html b/zarb-ml/mageia-dev/2011-June/005641.html new file mode 100644 index 000000000..8c73345c9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005641.html @@ -0,0 +1,257 @@ + + + + [Mageia-dev] gmane + + + + + + + + + +

[Mageia-dev] gmane

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Tue Jun 14 18:29:08 CEST 2011 +

+
+ +
2011/6/14 Antoine Pitrou <solipsis at pitrou.net>:
+> On Tue, 14 Jun 2011 18:09:23 +0200
+> Wolfgang Bornath <molch.b at googlemail.com>
+> wrote:
+>>
+>>  - gmane is clumsy, slow - my tests last September/October reveilled
+>> that with an active list you see 2 replies in the list before the
+>> initial mail is available in gmane. So, people using gmane for posting
+>> will always be behind and may destroy a thread or reply to already
+>> obsolete points. There were also missing mails in the middle of
+>> threads which made it unusable for me.
+>
+> My experience with gmane is different. Yes it lags a bit but usually by
+> a couple of minutes. Unless you want to use your mailing-list as some
+> kind of real-time communication channel (you shouldn't ;-)), this is ok.
+
+Well, a platform is only as good as it copes with heavy traffic. You
+should have seen the first weeks after the announcement last
+September/October - that's when I tested. :)
+
+> gmane's Web UI is not great but its NNTP gateway, OTOH, works fine for
+> me, both for reading and posting, using claws-mail as my NNTP client.
+
+We are talking about gateways between GUIs and mailing lists, so I did
+not test how the nntp gateway works.
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005642.html b/zarb-ml/mageia-dev/2011-June/005642.html new file mode 100644 index 000000000..42a89f66b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005642.html @@ -0,0 +1,191 @@ + + + + [Mageia-dev] Question about backports: calibre (bug 1659) + + + + + + + + + +

[Mageia-dev] Question about backports: calibre (bug 1659)

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Tue Jun 14 18:42:08 CEST 2011 +

+
+ +
On Tue, 14 Jun 2011, Radu-Cristian FOTESCU wrote:
+
+> Indeed, Mageia does not have the number of packagers that Fedora has.
+> However, if Mageia's _policy_ is to rather have 6-7 months old versions in
+> updates, I should probably realize that Mageia is not for me.
+
+This will ultimately be up to the people who do the stable updates. As you 
+can see from the fedora policy you quoted it is not possible to give exact 
+rules for what kind of updates will be accepted.
+
+> No, I have not, and never will use any repository called "backports". When a
+> newer stable  release of a distro is available, I should update to it if
+> updates I need are not pushed into Release N-1 "updates" (even if that release
+> is officially still supported with security patches), but again, "backports"
+> as Mandriva and Mageia are seeing them -- i.e. backporting
+> from  Cooker/Cauldron, not from "updates/testing" nor from "Release N+1"
+> -- does not fit my Zen.
+
+They will come from backports_testing I'd think. Likely packages will go 
+from cauldron where they are tested a bit into backports_testing, and 
+finally to backports.
+
+Would this 'backports' repository section sound better to you if it is 
+renamed e.g. to 'rolling' ? (:
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005643.html b/zarb-ml/mageia-dev/2011-June/005643.html new file mode 100644 index 000000000..fbac2e755 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005643.html @@ -0,0 +1,192 @@ + + + + [Mageia-dev] Question about backports: calibre (bug 1659) + + + + + + + + + +

[Mageia-dev] Question about backports: calibre (bug 1659)

+ Balcaen John + mikala at mageia.org +
+ Tue Jun 14 19:17:59 CEST 2011 +

+
+ +
Le mardi 14 juin 2011 13:28:43, Ahmad Samir a écrit :
+> On 14 June 2011 15:52, Angelo Naselli <anaselli at linux.it> wrote:
+> > martedì 14 giugno 2011 alle 12:00, Radu-Cristian FOTESCU ha scritto:
+> >> Fedora made a better judgment
+> > I didn't find my commoncpp2 version there, for me is blocking, they
+> > ship 0.7.x and 0.8.x is out with *important* fixings!
+> > Every time a kernel update (upgrade) is pushed, we need to wait
+> > nvidia kernel modules or switch to free drivers...
+> 
+> (FWIW I've not seen the nvidia proprietary kernel module fail to
+> compile in about 6-8months, and the kernel got updated many times
+> during the previous Cauldron release cycle).
+> 
+Maybe he was talking about fglrx :)
+
+
+-- 
+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-June/005644.html b/zarb-ml/mageia-dev/2011-June/005644.html new file mode 100644 index 000000000..bb1c12bcd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005644.html @@ -0,0 +1,189 @@ + + + + [Mageia-dev] Question about backports: calibre (bug 1659) + + + + + + + + + +

[Mageia-dev] Question about backports: calibre (bug 1659)

+ Radu-Cristian FOTESCU + beranger5ca at yahoo.ca +
+ Tue Jun 14 19:27:33 CEST 2011 +

+
+ +
+
+> Would this 'backports' repository section sound better to you if it is 
+> renamed e.g. to 'rolling' ? (:
+
+No, backports sounds very bad, except maybe for people coming from Mandriva. They (you!) must love the concept.
+
+(Oh, maybe "trolling" instead of "rolling" :-))
+
+Let me put it this way. People coming from Windows have this mind set:
+-- when I am using a release the OS called Windows XP, the system in itself gets minor updates: SP1, SP2, SP3. I therefore expect a release of a Linux distro to update KDE 4.6 to 4.6.1, 4.6.2, 4.6.3, 4.6.4... Now, KDE 4.8 would be more like upgrading XP to Vista so _no_, this should _not_ go into "updates".
+-- when I am using Windows XP, applications that don't need newer libraries, like Calibre, can be updated as they are released. I don't need a new release of the OS to update such an application! (And no, it's _not_ "backported" from Vista or Win7!) So why is this impossible in Linux? (Of course, when Calibre will need a newer Python , it would be a different matter, but this is not the case yet.)
+
+
+Nwo, in Windows it's easy to downgrade in case of significant regressions.
+Everyone can do that. Not that easy in Linux though. If I remember correctly
+from the times when I was using Synaptic with Ubuntu, it was possible from a
+menu to choose, for each package, what version to install -- this way,
+downgrades were easy. Mandriva does not offer such a possibility. Either way, knowing that some major distros released with Linux _kernels_ that
+brought major regressions, and that _ALL_ the distros release every now and
+then X.Org with Intel/Nvidia/ATI drivers that _break_ (i.e. major regressions),
+I feel that so much fuss for a "leaf" application (that only breaks some
+features from itself, when this happens) is... too much fuss.
+
+R-C
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005645.html b/zarb-ml/mageia-dev/2011-June/005645.html new file mode 100644 index 000000000..588202bde --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005645.html @@ -0,0 +1,207 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Jehan Pagès + jehan.marmottard at gmail.com +
+ Tue Jun 14 19:33:00 CEST 2011 +

+
+ +
Hi,
+
+On Tue, Jun 14, 2011 at 11:16 PM, Thorsten van Lil <tvl83 at gmx.de> wrote:
+> Am 14.06.2011 15:43, schrieb Michael Scherer:
+>>>
+>>> Yes, but Backports are not officially supported and we wouldn't advice
+>>> new users
+>>> >  to backports normally.
+>>
+>> I am sorry, but I fail to follow your reasoning.
+>
+> What I meant is: We can't tell the user to use the backports and if he runs
+> in trouble we let him alone and say he shouldn't have used it. If we
+> officially support and care for backports, than this is a different case.
+
+Agreed on this.
+
+>> And as I said in another mail, if people want to follow arch linux and
+>> do a better job, maybe they should start to explain what are the weak
+>> points of the distribution and then do proposal on stuff that can be
+>> done better instead of asking to copy cat hoping this would be better.
+>
+> I don't want a full rolling release, because of the listed disadvantages.
+> So, if you ask me what is "wrong" with Arch, I would say:
+> * due to the rolling release, it's nearly vanilla. This doesn't match
+> requirements of Mageia
+> * no innovations (because of vanilla)
+> * a rolling core system has a negative correlation with it's stability
+> * heavy work load
+> * ...
+>
+> So, I don't ask for a copy of Arch nor any other distribution. I asked
+> (although it wasn't my idea) for something new. An compromise: a light
+> rolling release.
+>
+> Further lack of clarity?
+
+So basically what people call a "light" rolling release in this thread
+is a rolling release where packages are tested and integrated? And
+what you call a (non-light) rolling release is a development rolling
+release (cooker, cauldron…) where packages are just dropped without
+prior security checked as fast as they are made available by their
+respective authors?
+
+If so, I would say, yeah obviously "light" (I find this naming quite
+paradoxical then) is the kind of rolling I would like. And that's not
+that new, that's the kind of rolling release in Gentoo (which I found
+much more stable than my years of experience in Mandriva, and also
+more peaceful as I don't have to fear the big update every 6 months
+which will definitely break a lot of small stuffs everywhere at once).
+
+Also yes, I guess this could be simulated using the current backport
+system becoming a supported repo (with package getting appropriately
+tested and the right integration into the distribution done). I don't
+say this is the ideal system, but that can be a first step in the
+evolution.
+As Anne Nicolas said, this may be only a matter of rewriting the policy.
+Yet if doing so, I think it would still need abstraction on UI side at
+least. User should not have to deal and even understand concept as
+backport, or whatever. On the user point of view, all one should care
+is knowing a newer version, which is supposed tested and approved, is
+available.
+
+Jehan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005646.html b/zarb-ml/mageia-dev/2011-June/005646.html new file mode 100644 index 000000000..0d7b0284c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005646.html @@ -0,0 +1,152 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Tue Jun 14 19:45:17 CEST 2011 +

+
+ +
2011/6/14 Jehan Pagès <jehan.marmottard at gmail.com>:
+>On the user point of view, all one should care
+> is knowing a newer version, which is supposed tested and approved, is
+> available.
+
+A BIG +1
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005647.html b/zarb-ml/mageia-dev/2011-June/005647.html new file mode 100644 index 000000000..2e342605c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005647.html @@ -0,0 +1,175 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Anne nicolas + ennael at mageia.org +
+ Tue Jun 14 20:00:39 CEST 2011 +

+
+ +
2011/6/14 Wolfgang Bornath <molch.b at googlemail.com>
+
+> 2011/6/14 Anne nicolas <ennael at mageia.org>:
+> >
+> > I guess because of Mandriva policy. We did provide backports but it was
+> > explicitely said to be unsupported. "Use it at your own risks"
+> > We may have to rewrite  this and make things clear
+>
+> Do you mean, just telling people that it is no risk or do you mean a
+> change which lessens the risk?
+>
+
+not at all
+
+
+> As Michael wrote earlier in this thread, if there was the risk to
+> break the system by low quality of backports then the quality has to
+> be improved (not his own words but that's how I understood it).
+>
+> exactly what I had in mind. Having backports can allow choice between "the
+last version of" and "the stable version with which I'm happy
+ with". But indeed we need more quality in backport rpms that is policy and
+tests.
+
+--
+> wobo
+>
+
+
+
+-- 
+Anne
+http://www.mageia.org
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110614/c3c82ec2/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005648.html b/zarb-ml/mageia-dev/2011-June/005648.html new file mode 100644 index 000000000..59c4dd289 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005648.html @@ -0,0 +1,170 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Tue Jun 14 20:06:44 CEST 2011 +

+
+ +
On 14 June 2011 09:25, Thorsten van Lil <tvl83 at gmx.de> wrote:
+[...]
+>
+> Backports aren't supposed to be for the averaged user
+
+I've seen this argument more than once in this thread. Why isn't
+backports suitable for the average user? that same average user would
+install an RPM package from a 3rd party repo or the official web site
+of an application in a heartbeat to get a new version of "foo".
+
+The "backports isn't supported" argument means that if backporting a
+new package requires a lot of changes then it won't be done, e.g. a
+new version of vlc/wine/foo isn't a problem, and if something goes
+wrong with the package after a while another backport will be done "if
+it's not too much hassle" (e.g. vlc requires a newer ffmpeg to make
+some video codec work better but that new ffmpeg is known to break
+some other apps then it won't be done).
+
+Packagers don't backport packages they know won't work or are crashy....
+
+> and shouldn't be used
+> to bring the half of your system up to date.
+
+The word "stable release" implies "doesn't change much"; so a new
+version of vlc or wine isn't a problem, but don't put "updating to
+GNOME3 or KDE 4.8 in Mageia 1" and "stable" in the same sentence, they
+don't fit..... such _huge_ changes need to happen in a development
+release so that the niggles (which are bound to show up) can be ironed
+out so that the distro becomes "stable" and ready to be released
+(Mageia 2).
+
+[...]
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005649.html b/zarb-ml/mageia-dev/2011-June/005649.html new file mode 100644 index 000000000..797530283 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005649.html @@ -0,0 +1,163 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Jehan Pagès + jehan.marmottard at gmail.com +
+ Tue Jun 14 20:23:53 CEST 2011 +

+
+ +
Hi,
+
+On Wed, Jun 15, 2011 at 3:06 AM, Ahmad Samir <ahmadsamir3891 at gmail.com> wrote:
+>> and shouldn't be used
+>> to bring the half of your system up to date.
+>
+> The word "stable release" implies "doesn't change much"; so a new
+> version of vlc or wine isn't a problem, but don't put "updating to
+> GNOME3 or KDE 4.8 in Mageia 1" and "stable" in the same sentence, they
+> don't fit..... such _huge_ changes need to happen in a development
+> release so that the niggles (which are bound to show up) can be ironed
+> out so that the distro becomes "stable" and ready to be released
+> (Mageia 2).
+
+I agree this could be a way to do it, which would maybe scare less
+some people of the "so-feared rolling", but there still would need a
+way to update "simply" one's installation without having to download a
+big iso with 90% in it we won't care in an upgrade (where we have
+updated most of the other packages, non critical, periodically through
+rolling release).
+
+I think it is so insane so many distributions are still with an
+"update by CD" logics (even though it is partly modernized with
+dropping the iso into an usb stick, or even simply mounting it
+directly, I think that is still so backwards that this is the major
+advertized way to do it).
+
+Jehan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005650.html b/zarb-ml/mageia-dev/2011-June/005650.html new file mode 100644 index 000000000..91b5589b5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005650.html @@ -0,0 +1,253 @@ + + + + [Mageia-dev] [RPM] cauldron core/release taskcoach-1.2.20-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release taskcoach-1.2.20-1.mga2

+ Damien Lallement + mageia at damsweb.net +
+ Tue Jun 14 15:44:10 CEST 2011 +

+
+ +
Le 14/06/2011 15:34, Mageia Team a écrit :
+> Name        : taskcoach                    Relocations: (not relocatable)
+> Version     : 1.2.20                            Vendor: Mageia.Org
+> Release     : 1.mga2                        Build Date: Tue Jun 14 15:33:18 2011
+> Install Date: (not installed)               Build Host: ecosse
+> Group       : Office                        Source RPM: (none)
+> Size        : 2176721                          License: GPLv3
+> Signature   : (none)
+> Packager    : Mageia Team<http://www.mageia.org>
+> URL         : http://www.taskcoach.org/
+> Summary     : Your friendly task manager
+> Description :
+> Task Coach is a simple open source todo manager to keep track of personal
+> tasks and todo lists. It grew out of a frustration that most task managers
+> do not provide facilities for composite tasks. Often, tasks and other
+> things todo consist of several activities. Task Coach is designed to deal
+> with composite tasks. In addition, it offers effort tracking, categories,
+> and notes.
+> Task Coach is available for Windows, Mac OS X, Linux, BSD, and iPhone and
+> iPod Touch.
+>
+> dams<dams>  1.2.20-1.mga2:
+> + Revision: 106109
+> + rebuild (emptylog)
+
+My bad...
+I mad a mistake with a first fail when commiting because of the same 
+release number in specfile.
+Sorry tv, I didn't noticed the upload was not done... :-/
+-- 
+Damien Lallement
+Treasurer of Mageia.Org
+
+twitter: damsweb - IRC: damsweb/coincoin
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005651.html b/zarb-ml/mageia-dev/2011-June/005651.html new file mode 100644 index 000000000..21d18c664 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005651.html @@ -0,0 +1,145 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Frank Griffin + ftg at roadrunner.com +
+ Tue Jun 14 21:15:37 CEST 2011 +

+
+ +
On 06/14/2011 01:33 PM, Jehan Pagès wrote:
+> Hi,
+>
+This has all been discussed before.  See the thread at 
+http://article.gmane.org/gmane.linux.mageia.devel/924
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005652.html b/zarb-ml/mageia-dev/2011-June/005652.html new file mode 100644 index 000000000..8f08872bd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005652.html @@ -0,0 +1,175 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Tue Jun 14 21:33:11 CEST 2011 +

+
+ +
2011/6/14 Jehan Pagès <jehan.marmottard at gmail.com>:
+> Hi,
+>
+> On Wed, Jun 15, 2011 at 3:06 AM, Ahmad Samir <ahmadsamir3891 at gmail.com> wrote:
+>>> and shouldn't be used
+>>> to bring the half of your system up to date.
+>>
+>> The word "stable release" implies "doesn't change much"; so a new
+>> version of vlc or wine isn't a problem, but don't put "updating to
+>> GNOME3 or KDE 4.8 in Mageia 1" and "stable" in the same sentence, they
+>> don't fit..... such _huge_ changes need to happen in a development
+>> release so that the niggles (which are bound to show up) can be ironed
+>> out so that the distro becomes "stable" and ready to be released
+>> (Mageia 2).
+>
+> I agree this could be a way to do it, which would maybe scare less
+> some people of the "so-feared rolling", but there still would need a
+> way to update "simply" one's installation without having to download a
+> big iso with 90% in it we won't care in an upgrade (where we have
+> updated most of the other packages, non critical, periodically through
+> rolling release).
+>
+> I think it is so insane so many distributions are still with an
+> "update by CD" logics (even though it is partly modernized with
+> dropping the iso into an usb stick, or even simply mounting it
+> directly, I think that is still so backwards that this is the major
+> advertized way to do it).
+>
+> Jehan
+>
+
+You're mixing cards here, I am talking about users running Mageia 1
+and using backports, not about full distro upgrade.
+
+A full distro upgrade, e.g. from Mageia 1 to 2, is supported and gets
+refined as much as possible before release (the same way the upgrade
+from mdv 2010.1 to mga1 was refined to ease the upgrades).
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005653.html b/zarb-ml/mageia-dev/2011-June/005653.html new file mode 100644 index 000000000..cd9788745 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005653.html @@ -0,0 +1,183 @@ + + + + [Mageia-dev] Question about backports: calibre (bug 1659) + + + + + + + + + +

[Mageia-dev] Question about backports: calibre (bug 1659)

+ Angelo Naselli + anaselli at linux.it +
+ Tue Jun 14 21:38:11 CEST 2011 +

+
+ +
I
+> > (FWIW I've not seen the nvidia proprietary kernel module fail to
+> > compile in about 6-8months, and the kernel got updated many times
+> > during the previous Cauldron release cycle).
+> 
+> Maybe he was talking about fglrx :)
+and not in Cauldron.... but in fedora not the last kernel update though (but 
+maybe we update it later :) )
+
+-- 
+	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/20110614/78a4528e/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005654.html b/zarb-ml/mageia-dev/2011-June/005654.html new file mode 100644 index 000000000..c4c9e025d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005654.html @@ -0,0 +1,203 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Tue Jun 14 21:57:03 CEST 2011 +

+
+ +
Op dinsdag 14 juni 2011 16:22:42 schreef Lee Forest:
+[...]
+> Android mail does that by default. But that just proves my other point.
+> Half the time these replies complaining about top posting, lazyness, or
+> 'netiquette' are being shot back instead of useful respones. In a forum
+> this is much less of a problem. Most forums are only setup to send just
+> your own reply to the topic, and quoting a specific post instead of the
+> whole thread. Thus not letting the user quote that much at a time by
+> default. Less redundancy by design, and we can move past the
+> 'netiquette' complaints and focus on the topics more. And in the process
+> actually modernize this communication system in a way that moves AWAY
+> from mailboxes bombed with redundancy. Don't count on the users to use
+> 'netiquette' because its been long proven that 'common sense is not all
+> that common', and its by definition 'insane' to expect everyone to use
+> it. Because it will always be a problem with some new users who are new
+> to mailing lists.
+
+I never visit any of the forums.
+
+the problem with forums is:
+ - no textonly, so too much junk like html, colors, fonts and whatnot: this 
+means emphasis on appearance and not on content.
+ - there are more than one forums in all kinds of languages
+
+so you see, there's people who like forums and people who like ML and it's one 
+of the holy wars like the vi vs emacs one, just like wobo said.
+
+this is completely open, everyone is allowed to say their saying, there are 
+only a few rules.
+
+i mean, if you _DO_ want to say your opinion, i think it's only normal to make 
+an effort for it. if you can't make the effort, then perhaps it's not as high 
+priority to yourself as you would like to believe.
+
+and lastly, i am not fond of your wording choice: "modernizing" ? makes me 
+feel like an old dinosaur...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005655.html b/zarb-ml/mageia-dev/2011-June/005655.html new file mode 100644 index 000000000..a3834d8a6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005655.html @@ -0,0 +1,152 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Angelo Naselli + anaselli at linux.it +
+ Tue Jun 14 22:09:19 CEST 2011 +

+
+ +
In data lunedì 13 giugno 2011 23:44:01, Colin Guthrie ha scritto:
+> read about 30 or 40 different community lists. It's much quicker for
+> me to have a standard UI and a standard way of operating and a standard
+> look and feel.
+> 
+> Each project having a separate forum, with separate logins, with
+> separate style and separate features etc. makes for a very hard and time
+> consuming reading experience. There is a similar argument for why HTML
+> messages are bad too (consistent style makes everyone's life easier). So
+> forums are only really good if you only follow a couple of projects or
+> only follow projects fairly superficially. Mailing lists are better for
+> the rest of us who are have to follow more projects.
++1
+totally agree
+-- 
+	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/20110614/803ecdc2/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005656.html b/zarb-ml/mageia-dev/2011-June/005656.html new file mode 100644 index 000000000..589ee3aa5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005656.html @@ -0,0 +1,122 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Tue Jun 14 22:13:22 CEST 2011 +

+
+ +
Op dinsdag 14 juni 2011 17:40:56 schreef Angelo Naselli:
+> > I would prefer to find a better way than suggest :/
+> > ( like a meta rpm pulling mgarepo, bm, the policy and rpmlint ).
+> 
+> something like task-mageia-devel?
+> 
+> Angelo
+
++1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005657.html b/zarb-ml/mageia-dev/2011-June/005657.html new file mode 100644 index 000000000..5aaff1304 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005657.html @@ -0,0 +1,202 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Tue Jun 14 22:21:31 CEST 2011 +

+
+ +
Op dinsdag 14 juni 2011 04:08:34 schreef Michael Scherer:
+> Le mardi 14 juin 2011 à 03:30 +0200, Maarten Vanraes a écrit :
+> > Op dinsdag 14 juni 2011 01:02:51 schreef Michael Scherer:
+> > > Le lundi 13 juin 2011 à 15:51 +0300, Thomas Backlund a écrit :
+> > > > Wolfgang Bornath skrev 13.6.2011 15:20:
+> > > > Obviously there will still be people complaining that "you waited 10
+> > > > months... if you had extended with ~2 more weeks... "this" or "that"
+> > > > package would have been available too... and so on....
+> > > 
+> > > Yes, there will be.
+> > > So let's be realist, 9 months with +/- 1 month is just 10 months +
+> > > people complaining to have 10,5 months.
+> > > 
+> > > We will never use the -1 month, because there will always be something
+> > > worth waiting.
+> > 
+> > actually, the real reason would be more to plan for whatever features
+> > you're going to implement and the time it takes to do them. if that's 8
+> > months, it's 8 months, if that's 9 or 10months, that's what it is.
+> 
+> See my answer to wobo.
+
+i did read that, that's partly a reason why i'm saying this. I think with the 
+proper whips things get in order, as we did, and i'm sure that no matter what 
+the eventual planning will be (in no matter what project), whippings will 
+always be needed, or the said project will never finish at all...
+
+so imho an 8month planning could be possible, or a 7.5month planning. it's 
+just that whatever the planning, we should follow it. (pending 
+release_critical of course)
+
+> > We proved that we can take a planning and follow it through, even the
+> > last release_critical one was solved _just_in_time_...
+> 
+> I still think the codecs stuff should not have been release_critical, as
+> we could do the update later.
+
+that is true, but i still think that would be bad, as:
+A) there is still no update afaik (and there have been reviews)
+B) even when updates is there, to properly solve it, it also still need some 
+work
+
+and eventually, those tainted stuff would likely take 3months or more.
+
+i'm pretty sure some people who review will likely play mp3s...
+
+but ok, that's passed now (but we still need to solve it the right way, let's 
+not forget this).
+
+> > imho, we need to decide now on a sort of 9month period, look at what
+> > we're going to do, then estimating how long it takes (with enough
+> > lenience), then make a real planning for that, and stick to it, if
+> > features are not ready, drop those features for next release, and make
+> > sure to fix all the release_criticals.
+> 
+> Great, so can you start by telling how long it will take for the feature
+> you plan to work on ?
+
+tbh, in my dayjob, that's often required of me to make an estimation. and if 
+we ARE going down that route, then of course i will do it. if you can't even 
+try an estimation for the things that you want to do, will you even start 
+doing them...
+
+fwiw, i think that 1month before freeze time, it's really clear which features 
+will get there in time and which won't.
+
+as an example; i knew right of the bat, that the maintainer db would not be 
+ready, and iinm i did warn about that. ok, it's not critical, but it would 
+still be very usefull.
+
+if we have a proper version control environment, it should be easy to drop 
+feature that aren't going to be in time, and are postponed for next release...
+
+in any case, let us know at the end if an estimation is required, and i'll 
+gladly do that
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005658.html b/zarb-ml/mageia-dev/2011-June/005658.html new file mode 100644 index 000000000..8c23bb245 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005658.html @@ -0,0 +1,172 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Tue Jun 14 22:27:39 CEST 2011 +

+
+ +
Op dinsdag 14 juni 2011 18:08:17 schreef Patricia Fraser:
+> Hi,
+> 
+> 2c from the marcomm team...
+> 
+> > Proposal 1:
+> > 6 months release cycle -> 12 months life cycle
+> > ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
+> > 
+> > Proposal 2:
+> > 9 months release cycle -> 18 months life cycle
+> > ( ~ opensuse and the one we used for Mageia 1 )
+> > 
+> > Proposal 3:
+> > 12 months release cycle -> 24 months life cycle
+> > ( Mandriva > 2010.1 )
+> 
+> The only reason for marcomm to take a position is that a release is a
+> nice hook on which to hang another round of publicity.
+> 
+> I think 9 months is good; it gives us a good amount of time to plan
+> whatever marketing/comms work is needed for release time, but it's
+> not too long so we fall out of the public consciousness altogether.
+> 
+> And there are other things about us to publicise besides releases, so
+> we can fill in the gaps nicely!
+> 
+> Cheers,
+
+ah yes, i didn't think about this at all... this alone is enough reason to do 
+a proper release cycle (instead of the rolling releases which seemed to have 
+found a way in this thread)
+
+a +3 is in order here.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005659.html b/zarb-ml/mageia-dev/2011-June/005659.html new file mode 100644 index 000000000..6972f0d18 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005659.html @@ -0,0 +1,217 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ Margot + margot at otfordduckscomputers.co.uk +
+ Tue Jun 14 22:35:21 CEST 2011 +

+
+ +
On Tue, 14 Jun 2011 21:57:03 +0200
+Maarten Vanraes <maarten.vanraes at gmail.com> wrote:
+
+> Op dinsdag 14 juni 2011 16:22:42 schreef Lee Forest:
+> [...]
+> > Android mail does that by default. But that just proves my
+> > other point. Half the time these replies complaining about top
+> > posting, lazyness, or 'netiquette' are being shot back instead
+> > of useful respones. In a forum this is much less of a problem.
+> > Most forums are only setup to send just your own reply to the
+> > topic, and quoting a specific post instead of the whole thread.
+> > Thus not letting the user quote that much at a time by default.
+> > Less redundancy by design, and we can move past the
+> > 'netiquette' complaints and focus on the topics more. And in
+> > the process actually modernize this communication system in a
+> > way that moves AWAY from mailboxes bombed with redundancy.
+> > Don't count on the users to use 'netiquette' because its been
+> > long proven that 'common sense is not all that common', and its
+> > by definition 'insane' to expect everyone to use it. Because it
+> > will always be a problem with some new users who are new to
+> > mailing lists.
+> 
+> I never visit any of the forums.
+> 
+> the problem with forums is:
+>  - no textonly, so too much junk like html, colors, fonts and
+> whatnot: this means emphasis on appearance and not on content.
+>  - there are more than one forums in all kinds of languages
+> 
+> so you see, there's people who like forums and people who like ML
+> and it's one of the holy wars like the vi vs emacs one, just like
+> wobo said.
+> 
+> this is completely open, everyone is allowed to say their saying,
+> there are only a few rules.
+> 
+> i mean, if you _DO_ want to say your opinion, i think it's only
+> normal to make an effort for it. if you can't make the effort,
+> then perhaps it's not as high priority to yourself as you would
+> like to believe.
+> 
+> and lastly, i am not fond of your wording choice: "modernizing" ?
+> makes me feel like an old dinosaur...
+
+Forums aren't exactly 'modern' - they're just a BBS with added
+graphics.
+
+-- 
+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-June/005660.html b/zarb-ml/mageia-dev/2011-June/005660.html new file mode 100644 index 000000000..7a0ba2121 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005660.html @@ -0,0 +1,215 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Tue Jun 14 22:49:55 CEST 2011 +

+
+ +
Op dinsdag 14 juni 2011 22:35:21 schreef Margot:
+> On Tue, 14 Jun 2011 21:57:03 +0200
+> 
+> Maarten Vanraes <maarten.vanraes at gmail.com> wrote:
+> > Op dinsdag 14 juni 2011 16:22:42 schreef Lee Forest:
+> > [...]
+> > 
+> > > Android mail does that by default. But that just proves my
+> > > other point. Half the time these replies complaining about top
+> > > posting, lazyness, or 'netiquette' are being shot back instead
+> > > of useful respones. In a forum this is much less of a problem.
+> > > Most forums are only setup to send just your own reply to the
+> > > topic, and quoting a specific post instead of the whole thread.
+> > > Thus not letting the user quote that much at a time by default.
+> > > Less redundancy by design, and we can move past the
+> > > 'netiquette' complaints and focus on the topics more. And in
+> > > the process actually modernize this communication system in a
+> > > way that moves AWAY from mailboxes bombed with redundancy.
+> > > Don't count on the users to use 'netiquette' because its been
+> > > long proven that 'common sense is not all that common', and its
+> > > by definition 'insane' to expect everyone to use it. Because it
+> > > will always be a problem with some new users who are new to
+> > > mailing lists.
+> > 
+> > I never visit any of the forums.
+> > 
+> > the problem with forums is:
+> >  - no textonly, so too much junk like html, colors, fonts and
+> > 
+> > whatnot: this means emphasis on appearance and not on content.
+> > 
+> >  - there are more than one forums in all kinds of languages
+> > 
+> > so you see, there's people who like forums and people who like ML
+> > and it's one of the holy wars like the vi vs emacs one, just like
+> > wobo said.
+> > 
+> > this is completely open, everyone is allowed to say their saying,
+> > there are only a few rules.
+> > 
+> > i mean, if you _DO_ want to say your opinion, i think it's only
+> > normal to make an effort for it. if you can't make the effort,
+> > then perhaps it's not as high priority to yourself as you would
+> > like to believe.
+> > 
+> > and lastly, i am not fond of your wording choice: "modernizing" ?
+> > makes me feel like an old dinosaur...
+> 
+> Forums aren't exactly 'modern' - they're just a BBS with added
+> graphics.
+
+lol +1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005661.html b/zarb-ml/mageia-dev/2011-June/005661.html new file mode 100644 index 000000000..c4031bef5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005661.html @@ -0,0 +1,161 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Samuel Verschelde + stormi at laposte.net +
+ Tue Jun 14 23:20:07 CEST 2011 +

+
+ +
Le mardi 14 juin 2011 20:00:39, Anne nicolas a écrit :
+> 2011/6/14 Wolfgang Bornath <molch.b at googlemail.com>
+> 
+> > 2011/6/14 Anne nicolas <ennael at mageia.org>:
+> > > I guess because of Mandriva policy. We did provide backports but it was
+> > > explicitely said to be unsupported. "Use it at your own risks"
+> > > We may have to rewrite  this and make things clear
+> > 
+> > Do you mean, just telling people that it is no risk or do you mean a
+> > change which lessens the risk?
+> 
+> not at all
+> 
+> > As Michael wrote earlier in this thread, if there was the risk to
+> > break the system by low quality of backports then the quality has to
+> > be improved (not his own words but that's how I understood it).
+> > 
+> exactly what I had in mind. Having backports can allow choice between
+> "the last version of" and "the stable version with which I'm happy
+>  with". But indeed we need more quality in backport rpms that is policy and
+> tests.
+
+Few words could make me more happy about the potential future status of our 
+backports. And if backports have a bad reputation among our users, maybe we 
+should rename updates to "maintenance updates" and backports to "feature 
+updates" ?
+
+Samuel
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005662.html b/zarb-ml/mageia-dev/2011-June/005662.html new file mode 100644 index 000000000..4ef02890a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005662.html @@ -0,0 +1,195 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Patricia Fraser + trish at thefrasers.org +
+ Tue Jun 14 23:19:18 CEST 2011 +

+
+ +
+
+> Op dinsdag 14 juni 2011 18:08:17 schreef Patricia Fraser:
+> > Hi,
+> > 
+> > 2c from the marcomm team...
+> > 
+> > > Proposal 1:
+> > > 6 months release cycle -> 12 months life cycle
+> > > ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
+> > > 
+> > > Proposal 2:
+> > > 9 months release cycle -> 18 months life cycle
+> > > ( ~ opensuse and the one we used for Mageia 1 )
+> > > 
+> > > Proposal 3:
+> > > 12 months release cycle -> 24 months life cycle
+> > > ( Mandriva > 2010.1 )
+> > 
+> > The only reason for marcomm to take a position is that a release
+> > is a nice hook on which to hang another round of publicity.
+> > 
+> > I think 9 months is good; it gives us a good amount of time to
+> > plan whatever marketing/comms work is needed for release time,
+> > but it's not too long so we fall out of the public consciousness
+> > altogether.
+> > 
+> > And there are other things about us to publicise besides
+> > releases, so we can fill in the gaps nicely!
+> > 
+> > Cheers,
+> 
+> ah yes, i didn't think about this at all... this alone is enough
+> reason to do a proper release cycle (instead of the rolling
+> releases which seemed to have found a way in this thread)
+> 
+> a +3 is in order here.
+
+Something else: new users (coming to Mageia for the first time)
+*need* a release - they have to have somewhere to start!
+
+Cheers,
+
+-- 
+Trish Fraser, JD9R RQ2D
+52.4161N,16.9303E
+di jun 14 23:18:34 CEST 2011
+GNU/Linux 1997-2010 #283226 counter.li.org
+andromeda up 5 hour(s), 40 min.
+kernel 2.6.38.7-desktop-1.mga
+--
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: signature.asc
+Type: application/pgp-signature
+Size: 490 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20110614/5d48db10/attachment-0001.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005663.html b/zarb-ml/mageia-dev/2011-June/005663.html new file mode 100644 index 000000000..a7d82a232 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005663.html @@ -0,0 +1,147 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Samuel Verschelde + stormi at laposte.net +
+ Tue Jun 14 23:43:57 CEST 2011 +

+
+ +
Le mardi 14 juin 2011 00:50:48, Michael Scherer a écrit :
+> 
+> Or, as a mathematician would say :
+> backport_level(R) = stormi_constant / release_frequency(R)
+> 
+> ( please not that you are now half as famous as Planck, Faraday and
+> Boltzmann since there is a constant named after you, the other half is
+> having a institute named after you )
+>
+
+Thanks for the fame :) Do you know how I could easily have an institute named 
+after me ?
+
+> So no, after doing the math, discussing everything at once is not
+> doable.
+
+I could come with less combinations, but probably still too much options :)
+
+Samuel
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005664.html b/zarb-ml/mageia-dev/2011-June/005664.html new file mode 100644 index 000000000..cd394e74f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005664.html @@ -0,0 +1,179 @@ + + + + [Mageia-dev] GNOME3 ? + + + + + + + + + +

[Mageia-dev] GNOME3 ?

+ JA Magallón + jamagallon at ono.com +
+ Wed Jun 15 00:06:37 CEST 2011 +

+
+ +
On Tue, 14 Jun 2011 16:09:44 +0200, Damien Lallement <mageia at damsweb.net> wrote:
+
+> Le 14/06/2011 16:04, Dexter Morgan a écrit :
+> > [...]
+> > do you have the logs from ~/.xsession-errors  when the session fails please ?
+> 
+> My session fails each time I try to launch an apps (even 
+> gnome-terminal!). Here is my log: http://pastebin.mandriva.com/23048
+> Nothing bad in my Xorg.log
+> 
+> Help, I'm under IceWM now! :-p
+
+these days I'm getting fond of XFCE. Try 'urpmi task-xfce task-xfce-plugins'.
+I think it will be my replacement for a traditional desktop if I don't get
+used to new Gnome.
+
+The only thing I miss is something similar to netspeed-applet, that shows
+throughput on the menu bar.
+
+-- 
+J.A. Magallon <jamagallon()ono!com>     \                 Winter is coming...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005665.html b/zarb-ml/mageia-dev/2011-June/005665.html new file mode 100644 index 000000000..d63270e2f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005665.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ JA Magallón + magallon at unizar.es +
+ Thu Jun 9 10:44:23 CEST 2011 +

+
+ +
Hi all...
+
+I have a problem with this first big change in Cauldron...
+I have a couple test boxes in which I have updated everything, and I can't
+get Gnome 3 to work properly. I suppose it is still work in progress, but as
+other people sent messages telling this or that application doesn't work...
+
+I can't even get an application to launch. I log in, get gnome-shell running,
+but:
+- no applet is shown in the bar. and they are there, i can press moue button
+  on right menu, hover it over there and the volume bubble pops, but I see no
+  icon on the bar.
+- if I select "System settings" o launch firefox, immediately I get a fullscreen
+  error about "something went wrong, plz logout and in again"
+
+I suppose probably I miss some depdency not correctly handled, but I can not
+guess what.
+
+Any ideas ?
+
+TIA
+
+-- 
+J.A. Magallon <magallon()unizar!es>     \               Software is like sex:
+                                         \         It's better when it's free
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005666.html b/zarb-ml/mageia-dev/2011-June/005666.html new file mode 100644 index 000000000..185bbf7cc --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005666.html @@ -0,0 +1,135 @@ + + + + [Mageia-dev] GNOME 2.32 borked + + + + + + + + + +

[Mageia-dev] GNOME 2.32 borked

+ Daniel Le Berre + leberre at cril.univ-artois.fr +
+ Sat Jun 11 11:50:36 CEST 2011 +

+
+ +
+Le 10 juin 2011 à 23:21, Christiaan Welvaart a écrit :
+
+> On Fri, 10 Jun 2011, Daniel Le Berre wrote:
+> 
+>> Le 10/06/2011 18:05, Frank Griffin a écrit :
+>>> Just updated and rebooted a system which was last rebooted Jun 7, and
+>>> both GDM and KDM fail to log into my GNOME DE with a greyish popup
+>>> saying "failed to load your GNOME session".
+> 
+>> Same error message. Switched to icewm to be able to work.
+> 
+> Does it work with the new notification-daemon-0.7.1-1.mga2 ?
+> 
+> 
+>   Christiaan
+
+I won't access that computer for 2 weeks, sorry.
+
+Daniel
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005667.html b/zarb-ml/mageia-dev/2011-June/005667.html new file mode 100644 index 000000000..eb7859f1f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005667.html @@ -0,0 +1,166 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Wed Jun 15 00:24:28 CEST 2011 +

+
+ +
2011/6/14 Margot <margot at otfordduckscomputers.co.uk>:
+>
+> Forums aren't exactly 'modern' - they're just a BBS with added
+> graphics.
+
+You put the whole discussion into the perspective it deserves!
+Thx for making my day!
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005668.html b/zarb-ml/mageia-dev/2011-June/005668.html new file mode 100644 index 000000000..ab04a8992 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005668.html @@ -0,0 +1,83 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Dexter Morgan + dmorganec at gmail.com +
+ Wed Jun 15 00:40:51 CEST 2011 +

+
+ +
2011/6/9 JA Magallón <magallon at unizar.es>:
+> Hi all...
+>
+> I have a problem with this first big change in Cauldron...
+> I have a couple test boxes in which I have updated everything, and I can't
+> get Gnome 3 to work properly. I suppose it is still work in progress, but as
+> other people sent messages telling this or that application doesn't work...
+>
+> I can't even get an application to launch. I log in, get gnome-shell running,
+> but:
+> - no applet is shown in the bar. and they are there, i can press moue button
+>  on right menu, hover it over there and the volume bubble pops, but I see no
+>  icon on the bar.
+> - if I select "System settings" o launch firefox, immediately I get a fullscreen
+>  error about "something went wrong, plz logout and in again"
+
+Do you have gnome-control-center installed ?
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005669.html b/zarb-ml/mageia-dev/2011-June/005669.html new file mode 100644 index 000000000..1f3a51e1a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005669.html @@ -0,0 +1,194 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Michael Scherer + misc at zarb.org +
+ Wed Jun 15 00:51:07 CEST 2011 +

+
+ +
Le mercredi 15 juin 2011 à 02:33 +0900, Jehan Pagès a écrit :
+
+> >> And as I said in another mail, if people want to follow arch linux and
+> >> do a better job, maybe they should start to explain what are the weak
+> >> points of the distribution and then do proposal on stuff that can be
+> >> done better instead of asking to copy cat hoping this would be better.
+> >
+> > I don't want a full rolling release, because of the listed disadvantages.
+> > So, if you ask me what is "wrong" with Arch, I would say:
+> > * due to the rolling release, it's nearly vanilla. This doesn't match
+> > requirements of Mageia
+> > * no innovations (because of vanilla)
+> > * a rolling core system has a negative correlation with it's stability
+> > * heavy work load
+> > * ...
+> >
+> > So, I don't ask for a copy of Arch nor any other distribution. I asked
+> > (although it wasn't my idea) for something new. An compromise: a light
+> > rolling release.
+> >
+> > Further lack of clarity?
+> 
+> So basically what people call a "light" rolling release in this thread
+> is a rolling release where packages are tested and integrated? And
+> what you call a (non-light) rolling release is a development rolling
+> release (cooker, cauldron…) where packages are just dropped without
+> prior security checked as fast as they are made available by their
+> respective authors?
+
+Then light is what arch does. They do tests before migrating. Now, this
+can be done faster because the integration is minimal, per philosophy
+( ie, you take care of configuration and fixing everything ). Heck, we
+could even fully automate that with mdvsys upgrade.
+
+> If so, I would say, yeah obviously "light" (I find this naming quite
+> paradoxical then) is the kind of rolling I would like. And that's not
+> that new, that's the kind of rolling release in Gentoo (which I found
+> much more stable than my years of experience in Mandriva, and also
+> more peaceful as I don't have to fear the big update every 6 months
+> which will definitely break a lot of small stuffs everywhere at once).
+
+Having lost access to my server for a whole weekend due to a library
+upgrade on Gentoo ( some stuff linked to libncurses or libreadline, so
+no more shell ), I beg to disagree.
+
+Also, gentoo seems to be updating more slowly nowadays :/ hence the
+stability
+
+> Also yes, I guess this could be simulated using the current backport
+> system becoming a supported repo (with package getting appropriately
+> tested and the right integration into the distribution done). I don't
+> say this is the ideal system, but that can be a first step in the
+> evolution.
+
+The problem is that the more testing we add, the more ressources it
+requires, and the more time it requires. And soon, people will complain
+that "packages are too old". 
+
+But if that what people want, we can have the same QA for backports and
+for updates. But then I hope there will be many testers.
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005670.html b/zarb-ml/mageia-dev/2011-June/005670.html new file mode 100644 index 000000000..b0c25c9df --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005670.html @@ -0,0 +1,159 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Michael Scherer + misc at zarb.org +
+ Wed Jun 15 00:58:18 CEST 2011 +

+
+ +
Le mercredi 15 juin 2011 à 03:23 +0900, Jehan Pagès a écrit :
+> Hi,
+
+> I think it is so insane so many distributions are still with an
+> "update by CD" logics (even though it is partly modernized with
+> dropping the iso into an usb stick, or even simply mounting it
+> directly, I think that is still so backwards that this is the major
+> advertized way to do it).
+
+I have updated my laptop from Fedora 11 to 15 using yum ( with all
+intermediary release ).
+I have updated several debian from sarge to lenny ( like 20 servers )
+using apt-get. 
+I updated my home server from Mandriva 2006.0 to 2010.2 ( with all
+intermediary releases ), and even downgraded it the day I half updated
+it to Mageia by error. We also did for the 3 zarb.org servers, among
+others.
+I updated the laptop of my girlfriend from Hardy Heron to Lucid Lynx.
+
+So where are all those distros that requires to use a cd, since I
+successfully avoided it for 4 popular distributions ( Debian, Fedora,
+Mandriva, Ubuntu ) ?
+
+If we want to have update with cd, we have the required software. We
+just need people to test before the release. 
+
+Now, of course, if people could stop saying "I reinstalled, it is safer"
+and just filled bug reports so we can fix the real issue, it would
+surely help.
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005671.html b/zarb-ml/mageia-dev/2011-June/005671.html new file mode 100644 index 000000000..9b55ff38a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005671.html @@ -0,0 +1,77 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Frank Griffin + ftg at roadrunner.com +
+ Wed Jun 15 01:03:53 CEST 2011 +

+
+ +
On 06/14/2011 06:40 PM, Dexter Morgan wrote:
+> Do you have gnome-control-center installed
+
+I have the same situation, and gnome-control-center is installed.
+
+I think it's time for you to actually test the reproducible cases we've 
+given you.  Unless you have first-hand knowledge that your packages 
+actually work in some scenario, the indication is that they don't work 
+at all, anywhere.  So please either fix them, or withdraw them until 
+they are functional.
+
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005672.html b/zarb-ml/mageia-dev/2011-June/005672.html new file mode 100644 index 000000000..fc0cef7d2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005672.html @@ -0,0 +1,160 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Michael Scherer + misc at zarb.org +
+ Wed Jun 15 01:08:36 CEST 2011 +

+
+ +
Le mardi 14 juin 2011 à 23:20 +0200, Samuel Verschelde a écrit :
+> Le mardi 14 juin 2011 20:00:39, Anne nicolas a écrit :
+> > 2011/6/14 Wolfgang Bornath <molch.b at googlemail.com>
+> > 
+> > > 2011/6/14 Anne nicolas <ennael at mageia.org>:
+> > > > I guess because of Mandriva policy. We did provide backports but it was
+> > > > explicitely said to be unsupported. "Use it at your own risks"
+> > > > We may have to rewrite  this and make things clear
+> > > 
+> > > Do you mean, just telling people that it is no risk or do you mean a
+> > > change which lessens the risk?
+> > 
+> > not at all
+> > 
+> > > As Michael wrote earlier in this thread, if there was the risk to
+> > > break the system by low quality of backports then the quality has to
+> > > be improved (not his own words but that's how I understood it).
+> > > 
+> > exactly what I had in mind. Having backports can allow choice between
+> > "the last version of" and "the stable version with which I'm happy
+> >  with". But indeed we need more quality in backport rpms that is policy and
+> > tests.
+> 
+> Few words could make me more happy about the potential future status of our 
+> backports. And if backports have a bad reputation among our users, maybe we 
+> should rename updates to "maintenance updates" and backports to "feature 
+> updates" ?
+
+Provided it doesn't requires  changes of the layout of the mirrors, yes.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005673.html b/zarb-ml/mageia-dev/2011-June/005673.html new file mode 100644 index 000000000..acf1527c6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005673.html @@ -0,0 +1,237 @@ + + + + [Mageia-dev] gmane + + + + + + + + + +

[Mageia-dev] gmane

+ Michael Scherer + misc at zarb.org +
+ Wed Jun 15 01:17:04 CEST 2011 +

+
+ +
Le mardi 14 juin 2011 à 18:17 +0200, Antoine Pitrou a écrit :
+> On Tue, 14 Jun 2011 18:09:23 +0200
+> Wolfgang Bornath <molch.b at googlemail.com>
+> wrote:
+> > 
+> >  - gmane is clumsy, slow - my tests last September/October reveilled
+> > that with an active list you see 2 replies in the list before the
+> > initial mail is available in gmane. So, people using gmane for posting
+> > will always be behind and may destroy a thread or reply to already
+> > obsolete points. There were also missing mails in the middle of
+> > threads which made it unusable for me.
+> 
+> My experience with gmane is different. Yes it lags a bit but usually by
+> a couple of minutes. Unless you want to use your mailing-list as some
+> kind of real-time communication channel (you shouldn't ;-)), this is ok.
+> 
+> gmane's Web UI is not great but its NNTP gateway, OTOH, works fine for
+> me, both for reading and posting, using claws-mail as my NNTP client.
+> 
+> And the fact that it doesn't ask you to sign for any kind of account is
+> really nice.
+
+For the record, I looked at nntp servers when we started the project as
+it seemed promising and was used by students in a school near my home.
+But from a sysadmin point of view, there isn't much choice :
+- there is inn, and some friends told me scary stories about it
+- cyrus support nntpd but I didn't understood to what extend
+- there is various half finished servers on freshmeat
+- there is proprietary servers ( used by giganews, etc )
+- there is lots of libraries
+- there is server that do not fullfill our need ( leafnode )
+
+So while it would help a lot ( as you can subscribe to lists using a
+rich interface without much hassle, get older mails, and unsubscribe at
+will ), it was not easy to do.
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005674.html b/zarb-ml/mageia-dev/2011-June/005674.html new file mode 100644 index 000000000..8a5063894 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005674.html @@ -0,0 +1,233 @@ + + + + [Mageia-dev] [RPM] cauldron core/release taskcoach-1.2.20-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release taskcoach-1.2.20-1.mga2

+ Michael Scherer + misc at zarb.org +
+ Wed Jun 15 01:21:06 CEST 2011 +

+
+ +
Le mardi 14 juin 2011 à 15:44 +0200, Damien Lallement a écrit :
+> Le 14/06/2011 15:34, Mageia Team a écrit :
+> > Name        : taskcoach                    Relocations: (not relocatable)
+> > Version     : 1.2.20                            Vendor: Mageia.Org
+> > Release     : 1.mga2                        Build Date: Tue Jun 14 15:33:18 2011
+> > Install Date: (not installed)               Build Host: ecosse
+> > Group       : Office                        Source RPM: (none)
+> > Size        : 2176721                          License: GPLv3
+> > Signature   : (none)
+> > Packager    : Mageia Team<http://www.mageia.org>
+> > URL         : http://www.taskcoach.org/
+> > Summary     : Your friendly task manager
+> > Description :
+> > Task Coach is a simple open source todo manager to keep track of personal
+> > tasks and todo lists. It grew out of a frustration that most task managers
+> > do not provide facilities for composite tasks. Often, tasks and other
+> > things todo consist of several activities. Task Coach is designed to deal
+> > with composite tasks. In addition, it offers effort tracking, categories,
+> > and notes.
+> > Task Coach is available for Windows, Mac OS X, Linux, BSD, and iPhone and
+> > iPod Touch.
+> >
+> > dams<dams>  1.2.20-1.mga2:
+> > + Revision: 106109
+> > + rebuild (emptylog)
+> 
+> My bad...
+> I mad a mistake with a first fail when commiting because of the same 
+> release number in specfile.
+> Sorry tv, I didn't noticed the upload was not done... :-/
+
+You can edit the changelog with svn propedit ( the answer is in the FAQ
+of svn ) so the changelog will be correct on next upload.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005675.html b/zarb-ml/mageia-dev/2011-June/005675.html new file mode 100644 index 000000000..fbc2f6bd5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005675.html @@ -0,0 +1,236 @@ + + + + [Mageia-dev] mesaglut versus freeglut in cauldron + + + + + + + + + +

[Mageia-dev] mesaglut versus freeglut in cauldron

+ Philippe DIDIER + philippedidier at laposte.net +
+ Wed Jun 15 01:25:41 CEST 2011 +

+
+ +
Hi !
+
+Wonderful job done by the team (congratulations)
+just some problems with some missing rpms in Mageia1 : waiting for a 
+solution to be found to add them (in backports or updates repo?) and it 
+will be perfect !
+
+Talking about future  (whatever the release cycle will be) :
+Just a reminder :
+On the mailing list we talked about it  on April 20th
+(and before that I evocated the problem on january 18th)
+
+Perhaps it is now the time to get rid of GLUT and use freeglut in cauldron
+It was not possible for Mageia1 which needed to be "upgrade compatible" 
+with Mandriva...
+
+Some rpm must be rebuilt with freeglut-devel and some dependancies 
+modified in their spec
+It's an old problem in Mandriva and PCLinuxOS (and no other 
+distribution) : Mageia might not inherit of it ...
+
+Here are some extract from the mails :
+
+>>Thank you to provide an answer to an old Mandriva package request....
+
+>>  https://qa.mandriva.com/show_bug.cgi?id=47090
+>>  in comment n°10 of this "bug" I provided a list of possible dependency
+>>  problems when replacing mesaglut with freeglut
+
+
+Thierry Vignaud answered :
+
+>  I haven't package it for no reason :-)
+
+>  mesa is ready to switch from its own implementation to freeglut.
+>  RH has switched to freeglut long ago.
+>  But we'll only consider doing it by default after Mageia 1 release.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005676.html b/zarb-ml/mageia-dev/2011-June/005676.html new file mode 100644 index 000000000..76b57afd2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005676.html @@ -0,0 +1,243 @@ + + + + [Mageia-dev] gmane + + + + + + + + + +

[Mageia-dev] gmane

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Wed Jun 15 01:44:47 CEST 2011 +

+
+ +
2011/6/15 Michael Scherer <misc at zarb.org>:
+> Le mardi 14 juin 2011 à 18:17 +0200, Antoine Pitrou a écrit :
+>> On Tue, 14 Jun 2011 18:09:23 +0200
+>> Wolfgang Bornath <molch.b at googlemail.com>
+>> wrote:
+>> >
+>> >  - gmane is clumsy, slow - my tests last September/October reveilled
+>> > that with an active list you see 2 replies in the list before the
+>> > initial mail is available in gmane. So, people using gmane for posting
+>> > will always be behind and may destroy a thread or reply to already
+>> > obsolete points. There were also missing mails in the middle of
+>> > threads which made it unusable for me.
+>>
+>> My experience with gmane is different. Yes it lags a bit but usually by
+>> a couple of minutes. Unless you want to use your mailing-list as some
+>> kind of real-time communication channel (you shouldn't ;-)), this is ok.
+>>
+>> gmane's Web UI is not great but its NNTP gateway, OTOH, works fine for
+>> me, both for reading and posting, using claws-mail as my NNTP client.
+>>
+>> And the fact that it doesn't ask you to sign for any kind of account is
+>> really nice.
+>
+> For the record, I looked at nntp servers when we started the project as
+> it seemed promising and was used by students in a school near my home.
+> But from a sysadmin point of view, there isn't much choice :
+> - there is inn, and some friends told me scary stories about it
+> - cyrus support nntpd but I didn't understood to what extend
+> - there is various half finished servers on freshmeat
+> - there is proprietary servers ( used by giganews, etc )
+> - there is lots of libraries
+> - there is server that do not fullfill our need ( leafnode )
+>
+> So while it would help a lot ( as you can subscribe to lists using a
+> rich interface without much hassle, get older mails, and unsubscribe at
+> will ), it was not easy to do.
+
+Wow, that puts me back in time more than a decade, when I spent time
+setting up inn on a remote server and leafnode as a local server,
+using Emacs/Gnus as client! :) As much as I appreciated the technical
+quality of this whole system, I would not go through these ordeals
+today. Well, leafnode was easy as a pie, but remembering inn still
+makes my neck hairs stand up and everybody knows that Emacs/Gnus is
+The Beast by definition!
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005677.html b/zarb-ml/mageia-dev/2011-June/005677.html new file mode 100644 index 000000000..a4474c121 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005677.html @@ -0,0 +1,83 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Wed Jun 15 03:02:16 CEST 2011 +

+
+ +
2011/6/15 Frank Griffin <ftg at roadrunner.com>:
+> On 06/14/2011 06:40 PM, Dexter Morgan wrote:
+>>
+>> Do you have gnome-control-center installed
+>
+> I have the same situation, and gnome-control-center is installed.
+
+Confirmed, same problem.
+
+Just switched a Mageia 1 to Cauldron via urpmi, installed task-gnome, no errors.
+After reboot and selecting Gnome3 the desktop builds nicely but as
+soon as I start any application after a couple of seconds I get the
+same error message, pressing "OK" does a restart of the xserver and
+I'm back at login.
+
+-- 
+wobo
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005678.html b/zarb-ml/mageia-dev/2011-June/005678.html new file mode 100644 index 000000000..ac774aabb --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005678.html @@ -0,0 +1,177 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Dick Gevers + dvgevers at xs4all.nl +
+ Wed Jun 15 04:25:27 CEST 2011 +

+
+ +
On Wed, 15 Jun 2011 03:02:16 +0200, Wolfgang Bornath wrote about Re:
+[Mageia-dev] Problems with Gnome 3:
+
+>2011/6/15 Frank Griffin <ftg at roadrunner.com>:
+>> On 06/14/2011 06:40 PM, Dexter Morgan wrote:
+>>>
+>>> Do you have gnome-control-center installed
+>>
+>> I have the same situation, and gnome-control-center is installed.
+>
+>Confirmed, same problem.
+>
+>Just switched a Mageia 1 to Cauldron via urpmi, installed task-gnome, no
+>errors. After reboot and selecting Gnome3 the desktop builds nicely but as
+>soon as I start any application after a couple of seconds I get the
+>same error message, pressing "OK" does a restart of the xserver and
+>I'm back at login.
+
+My GNOME3 is working better all the time. Still lots missing: can't find
+where to access theme and font settings, and any help can't find the path
+to same, but it's getting closer.
+
+I do confess removing some GNOME2 stuff which nothing depended on...
+
+rpm -qa |grep gnome
+gnome-backgrounds-3.0.2-1.mga2
+gnome-bluetooth-2.32.0-2.mga1
+gnome-commander-1.2.8.10-2.mga1
+gnome-control-center-3.0.2-2.mga2
+gnome-desktop3-3.0.2-4.mga2
+gnome-disk-utility-3.0.0-1.mga2
+gnome-doc-utils-0.20.5-1.mga1
+gnome-games-2.32.1-2.mga1
+gnome-games-common-2.32.1-2.mga1
+gnome-icon-theme-3.0.0-1.mga2
+gnome-keyring-2.32.1-1.mga1
+gnome-keyring-sharp-1.0.2-1.mga1
+gnome-mahjongg-2.32.1-2.mga1
+gnome-media-2.32.0-3.mga1
+gnome-menus-3.0.1-2.mga2
+gnome-mime-data-2.18.0-8.mga1
+gnome-mplayer-1.0.3-1.mga2
+gnome-packagekit-common-2.32.0-3.mga1
+gnome-panel-3.0.2-3.mga2
+gnome-python-2.28.1-2.mga1
+gnome-python-bonobo-2.28.1-2.mga1
+gnome-python-canvas-2.28.1-2.mga1
+gnome-python-desktop-2.32.0-6.mga1
+gnome-python-extras-2.25.3-24.mga1
+gnome-python-gconf-2.28.1-2.mga1
+gnome-python-gnomekeyring-2.32.0-6.mga1
+gnome-python-gnomevfs-2.28.1-2.mga1
+gnome-python-gtkspell-2.25.3-24.mga1
+gnome-screensaver-3.0.0-1.mga2
+gnome-session-3.0.1-2.mga2
+gnome-session-bin-3.0.1-2.mga2
+gnome-settings-daemon-3.1.1-1.mga2
+gnome-sharp2-2.24.2-1.mga1
+gnome-shell-3.0.2-1.mga2
+gnome-speech-0.4.25-5.mga1
+gnome-speech-driver-espeak-0.4.25-5.mga1
+gnome-sudoku-2.32.1-2.mga1
+gnome-terminal-3.0.1-1.mga2
+gnome-themes-standard-3.0.2-2.mga2
+gnome-user-docs-2.32.0-1.mga1
+gnome-utils-2.32.0-1.mga1
+gnome-vfs2-2.24.4-1.mga1
+gstreamer0.10-gnomevfs-0.10.32-3.mga1
+ia_ora-gnome-1.0.25-1.mga1
+icewm-gnome-1.3.3-7.mga1
+lib64gnome2_0-2.32.1-7.mga1
+lib64gnome-bluetooth8-2.32.0-2.mga1
+lib64gnomebreakpad-2.32.0-1.mga1
+lib64gnomecanvas2_0-2.30.3-2.mga2
+lib64gnomecanvasmm2.6_1-2.26.0-4.mga1
+lib64gnomecups-1.0_1-0.2.3-6.mga1
+lib64gnome-desktop-3_0-3.0.2-4.mga2
+lib64gnomekbd7-3.0.0.1-2.mga2
+lib64gnome-keyring0-2.32.0-1.mga1
+lib64gnome-media0-2.32.0-3.mga1
+lib64gnome-menu2-3.0.1-2.mga2
+lib64gnomemm2.6_1-2.30.0-2.mga1
+lib64gnomeprint2-2_0-2.18.8-1.mga1
+lib64gnomeprintui2-2_0-2.18.6-1.mga1
+lib64gnomespeech7-0.4.25-5.mga1
+lib64gnomesu0-1.0.0-6.mga1
+lib64gnomeui2_0-2.24.5-2.mga2
+lib64gnomeuimm2.6_1-2.28.0-3.mga1
+lib64gnome-vfs2_0-2.24.4-1.mga1
+lib64gnome-vfsmm2.6_1-2.26.0-3.mga1
+lib64gnome-window-settings1-3.0.2-2.mga2
+lib64ia_ora-gnome-1.0.25-1.mga1
+libgnome2-2.32.1-7.mga1
+libgnome2-schemas-2.32.1-7.mga1
+libgnomecanvas-2.30.3-2.mga2
+libgnomecups-0.2.3-6.mga1
+libgnomekbd-common-3.0.0.1-2.mga2
+libgnome-keyring-i18n-2.32.0-1.mga1
+libgnomeprint-2.18.8-1.mga1
+libgnomeprintui-2.18.6-1.mga1
+libgnomesu-1.0.0-6.mga1
+libgnomeui2-2.24.5-2.mga2
+perl-Gnome2-Vte-0.90.0-3.mga2
+polkit-gnome-0.101-2.mga1
+python-gnome-menus-3.0.1-2.mga2
+xchat-gnome-0.26.1-8.mga2
+xine-gnomevfs-1.1.19-5.mga1
+
+Ciao,
+=Dick Gevers=
+
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005679.html b/zarb-ml/mageia-dev/2011-June/005679.html new file mode 100644 index 000000000..f94a1fc06 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005679.html @@ -0,0 +1,85 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Dexter Morgan + dmorganec at gmail.com +
+ Wed Jun 15 07:24:53 CEST 2011 +

+
+ +
On Wed, Jun 15, 2011 at 3:02 AM, Wolfgang Bornath
+<molch.b at googlemail.com> wrote:
+> 2011/6/15 Frank Griffin <ftg at roadrunner.com>:
+>> On 06/14/2011 06:40 PM, Dexter Morgan wrote:
+>>>
+>>> Do you have gnome-control-center installed
+>>
+>> I have the same situation, and gnome-control-center is installed.
+>
+> Confirmed, same problem.
+>
+> Just switched a Mageia 1 to Cauldron via urpmi, installed task-gnome, no errors.
+> After reboot and selecting Gnome3 the desktop builds nicely but as
+> soon as I start any application after a couple of seconds I get the
+> same error message, pressing "OK" does a restart of the xserver and
+> I'm back at login.
+
+Do you have errors in your .xsession-errors ?
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005680.html b/zarb-ml/mageia-dev/2011-June/005680.html new file mode 100644 index 000000000..3ceebdc8b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005680.html @@ -0,0 +1,143 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Remco Rijnders + remco at webconquest.com +
+ Wed Jun 15 07:38:48 CEST 2011 +

+
+ +
On Tue, Jun 14, 2011 at 11:43:57PM +0200, Samuel Verschelde wrote:
+>Le mardi 14 juin 2011 00:50:48, Michael Scherer a écrit :
+>>
+>> Or, as a mathematician would say :
+>> backport_level(R) = stormi_constant / release_frequency(R)
+>>
+>> ( please not that you are now half as famous as Planck, Faraday and
+>> Boltzmann since there is a constant named after you, the other half is
+>> having a institute named after you )
+>>
+>
+>Thanks for the fame :) Do you know how I could easily have an institute named
+>after me ?
+
+I think huge monetary donations would be the quickest way :)
+-------------- 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/20110615/1485dd4c/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005681.html b/zarb-ml/mageia-dev/2011-June/005681.html new file mode 100644 index 000000000..ca085936a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005681.html @@ -0,0 +1,141 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Thorsten van Lil + tvl83 at gmx.de +
+ Wed Jun 15 07:49:41 CEST 2011 +

+
+ +
Am Dienstag, 14. Juni 2011, 19:33:00 schrieb Jehan Pagès:
+> So basically what people call a "light" rolling release in this thread
+> is a rolling release where packages are tested and integrated? And
+> what you call a (non-light) rolling release is a development rolling
+> release (cooker, cauldron…) where packages are just dropped without
+> prior security checked as fast as they are made available by their
+> respective authors?
+
+No.
+As said in my first mail. Light rolling is, when the core system only gets 
+minor updates (no upgrades) and only the apllications get major updates within 
+a release.
+Full rolling is, when everything will always get the latest version.
+
+Both versions have to be stable as possible.
+
+Regards,
+Thorsten
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005682.html b/zarb-ml/mageia-dev/2011-June/005682.html new file mode 100644 index 000000000..0624109e7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005682.html @@ -0,0 +1,218 @@ + + + + [Mageia-dev] [Bug 1793] System tool text needs proofreading + + + + + + + + + +

[Mageia-dev] [Bug 1793] System tool text needs proofreading

+ Olav Dahlum + odahlum at gmail.com +
+ Wed Jun 15 08:57:59 CEST 2011 +

+
+ +
On 15/06/11 01:32, Barry Jackson wrote:
+> https://bugs.mageia.org/show_bug.cgi?id=1793
+> 
+> --- Comment #5 from Barry Jackson <zen25000 at zen.co.uk> 2011-06-15 03:32:08 CEST ---
+> Comment on attachment 563
+>   --> https://bugs.mageia.org/attachment.cgi?id=563
+> Patched English strings for Live installer
+> 
+> -msgid "Do you want to save /etc/fstab modifications"
+> +msgid "Do you wish to save the changes to your fstab modifications"
+> 
+> The original makes sense the changed version does not.
+> 
+
+Could we also try to avoid using exclamation marks? We don't need
+to shout our messages all over the place...
+
+I would also recommend to cut the personal chatter in the strings,
+and just write something like this:
+
+"+"Should users be permitted to share their folders?\n""
+
+A bit cold, but very professional. :-)
+
+Sincerely,
+Olav Dahlum
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005683.html b/zarb-ml/mageia-dev/2011-June/005683.html new file mode 100644 index 000000000..acd466418 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005683.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Dexter Morgan + dmorganec at gmail.com +
+ Wed Jun 15 09:26:00 CEST 2011 +

+
+ +
On Wed, Jun 15, 2011 at 1:03 AM, Frank Griffin <ftg at roadrunner.com> wrote:
+> On 06/14/2011 06:40 PM, Dexter Morgan wrote:
+>>
+>> Do you have gnome-control-center installed
+>
+> I have the same situation, and gnome-control-center is installed.
+>
+> I think it's time for you to actually test the reproducible cases we've
+> given you.  Unless you have first-hand knowledge that your packages actually
+> work in some scenario, the indication is that they don't work at all,
+> anywhere.  So please either fix them, or withdraw them until they are
+> functional.
+>
+>
+
+i will install a mageia 1 on the new machine i just received .
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005684.html b/zarb-ml/mageia-dev/2011-June/005684.html new file mode 100644 index 000000000..b8c81662d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005684.html @@ -0,0 +1,197 @@ + + + + [Mageia-dev] Broken BS + + + + + + + + + +

[Mageia-dev] Broken BS

+ Dexter Morgan + dmorganec at gmail.com +
+ Wed Jun 15 10:16:32 CEST 2011 +

+
+ +
Hi,
+
+sorry the update of gnome keyring broke the BS.
+
+I am fixing it .
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005685.html b/zarb-ml/mageia-dev/2011-June/005685.html new file mode 100644 index 000000000..1d10646a3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005685.html @@ -0,0 +1,207 @@ + + + + [Mageia-dev] dokuwiki import + + + + + + + + + +

[Mageia-dev] dokuwiki import

+ Cazzaniga Sandro + cazzaniga.sandro at gmail.com +
+ Wed Jun 15 10:17:35 CEST 2011 +

+
+ +
hi,
+
+I've updated and imported dokuwiki
+(https://bugs.mageia.org/show_bug.cgi?id=1096). Can someone review it
+before push, please?
+
+thanks in advance.
+-- 
+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
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005686.html b/zarb-ml/mageia-dev/2011-June/005686.html new file mode 100644 index 000000000..e5872a857 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005686.html @@ -0,0 +1,214 @@ + + + + [Mageia-dev] Lib policy change needed ? + + + + + + + + + +

[Mageia-dev] Lib policy change needed ?

+ Dexter Morgan + dmorganec at gmail.com +
+ Wed Jun 15 10:26:10 CEST 2011 +

+
+ +
hello
+
+the last BS breakage makes me thing that we should adjust our
+packaging policy and add only one lib per lib package.
+
+
+On our last BS breakage we had as error :
+
+
+A requested package cannot be installed:
+seahorse-2.32.0-2.mga1.x86_64 (due to unsatisfied libgp11.so.0()(64bit))
+
+
+because libgp11.so.0 was in libgcr0 but disappeared.
+
+if it was on libgp11_0 we would have been able to rebuilde seahorse
+against new libgcr-devel and the remove libgp11_0 when not needed
+anymore .
+
+
+WDYT about this new policy ?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005687.html b/zarb-ml/mageia-dev/2011-June/005687.html new file mode 100644 index 000000000..978177eb4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005687.html @@ -0,0 +1,240 @@ + + + + [Mageia-dev] Lib policy change needed ? + + + + + + + + + +

[Mageia-dev] Lib policy change needed ?

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Wed Jun 15 10:32:38 CEST 2011 +

+
+ +
'Twas brillig, and Dexter Morgan at 15/06/11 09:26 did gyre and gimble:
+> hello
+> 
+> the last BS breakage makes me thing that we should adjust our
+> packaging policy and add only one lib per lib package.
+> 
+> 
+> On our last BS breakage we had as error :
+> 
+> 
+> A requested package cannot be installed:
+> seahorse-2.32.0-2.mga1.x86_64 (due to unsatisfied libgp11.so.0()(64bit))
+> 
+> 
+> because libgp11.so.0 was in libgcr0 but disappeared.
+> 
+> if it was on libgp11_0 we would have been able to rebuilde seahorse
+> against new libgcr-devel and the remove libgp11_0 when not needed
+> anymore .
+> 
+> 
+> WDYT about this new policy ?
+
+I'm not 100% sure it's all that different anyway. The same issue would
+be true of sticking two libs into one lib package when they happen to
+have the same major, but they later diverge and one of them changes
+major before the other... I guess it's just good practice to keep things
+separated out and I'm not sure the current lib policy actively
+encourages the opposite.
+
+I'd say this is more of clarification of the policy :)
+
+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-June/005688.html b/zarb-ml/mageia-dev/2011-June/005688.html new file mode 100644 index 000000000..08d272f7f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005688.html @@ -0,0 +1,106 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Wed Jun 15 10:34:46 CEST 2011 +

+
+ +
2011/6/15 Dexter Morgan <dmorganec at gmail.com>:
+> On Wed, Jun 15, 2011 at 3:02 AM, Wolfgang Bornath
+> <molch.b at googlemail.com> wrote:
+>> 2011/6/15 Frank Griffin <ftg at roadrunner.com>:
+>>> On 06/14/2011 06:40 PM, Dexter Morgan wrote:
+>>>>
+>>>> Do you have gnome-control-center installed
+>>>
+>>> I have the same situation, and gnome-control-center is installed.
+>>
+>> Confirmed, same problem.
+>>
+>> Just switched a Mageia 1 to Cauldron via urpmi, installed task-gnome, no errors.
+>> After reboot and selecting Gnome3 the desktop builds nicely but as
+>> soon as I start any application after a couple of seconds I get the
+>> same error message, pressing "OK" does a restart of the xserver and
+>> I'm back at login.
+>
+> Do you have errors in your .xsession-errors ?
+
+Yes. lots of them! Many things are missing:
+ - Theme "Adwaita" can't be loaded, file not found
+ - JS ERROR about NetworkManager
+ - gnome-session WARNING: Application 'gnome-shell.desktop' failed to
+register before timeout
+ - failed to play sound: file or data not found
+ ... and more
+
+Last section of errors is:
+---------------------------------------
+(gnome-shell:5091): Clutter-CRITICAL **: clutter_actor_queue_relayout:
+assertion 'CLUTTER_IS_ACTOR (self) failed
+Cannot open /dev/input/eventX: permission denied ## this was repeated 15 times
+
+(gnome-shell:5091): Clutter-CRITICAL **: clutter_actor_queue_relayout:
+assertion 'CLUTTER_IS_ACTOR (self) failed
+--EOF-------------------------------------
+
+-- 
+wobo
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005689.html b/zarb-ml/mageia-dev/2011-June/005689.html new file mode 100644 index 000000000..e1a757267 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005689.html @@ -0,0 +1,231 @@ + + + + [Mageia-dev] Lib policy change needed ? + + + + + + + + + +

[Mageia-dev] Lib policy change needed ?

+ Dexter Morgan + dmorganec at gmail.com +
+ Wed Jun 15 10:36:10 CEST 2011 +

+
+ +
On Wed, Jun 15, 2011 at 10:32 AM, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+> 'Twas brillig, and Dexter Morgan at 15/06/11 09:26 did gyre and gimble:
+>> hello
+>>
+>> the last BS breakage makes me thing that we should adjust our
+>> packaging policy and add only one lib per lib package.
+>>
+>>
+>> On our last BS breakage we had as error :
+>>
+>>
+>> A requested package cannot be installed:
+>> seahorse-2.32.0-2.mga1.x86_64 (due to unsatisfied libgp11.so.0()(64bit))
+>>
+>>
+>> because libgp11.so.0 was in libgcr0 but disappeared.
+>>
+>> if it was on libgp11_0 we would have been able to rebuilde seahorse
+>> against new libgcr-devel and the remove libgp11_0 when not needed
+>> anymore .
+>>
+>>
+>> WDYT about this new policy ?
+>
+> I'm not 100% sure it's all that different anyway. The same issue would
+> be true of sticking two libs into one lib package when they happen to
+> have the same major, but they later diverge and one of them changes
+> major before the other...
+
+Yes this is why i think we should enforce "one lib per package".
+
+
+> I guess it's just good practice to keep things
+> separated out and I'm not sure the current lib policy actively
+> encourages the opposite.
+>
+> I'd say this is more of clarification of the policy :)
+
+Maybe  but clarification is always good :D
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005690.html b/zarb-ml/mageia-dev/2011-June/005690.html new file mode 100644 index 000000000..1bea5d98b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005690.html @@ -0,0 +1,113 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Dexter Morgan + dmorganec at gmail.com +
+ Wed Jun 15 10:37:14 CEST 2011 +

+
+ +
On Wed, Jun 15, 2011 at 10:34 AM, Wolfgang Bornath
+<molch.b at googlemail.com> wrote:
+> 2011/6/15 Dexter Morgan <dmorganec at gmail.com>:
+>> On Wed, Jun 15, 2011 at 3:02 AM, Wolfgang Bornath
+>> <molch.b at googlemail.com> wrote:
+>>> 2011/6/15 Frank Griffin <ftg at roadrunner.com>:
+>>>> On 06/14/2011 06:40 PM, Dexter Morgan wrote:
+>>>>>
+>>>>> Do you have gnome-control-center installed
+>>>>
+>>>> I have the same situation, and gnome-control-center is installed.
+>>>
+>>> Confirmed, same problem.
+>>>
+>>> Just switched a Mageia 1 to Cauldron via urpmi, installed task-gnome, no errors.
+>>> After reboot and selecting Gnome3 the desktop builds nicely but as
+>>> soon as I start any application after a couple of seconds I get the
+>>> same error message, pressing "OK" does a restart of the xserver and
+>>> I'm back at login.
+>>
+>> Do you have errors in your .xsession-errors ?
+>
+> Yes. lots of them! Many things are missing:
+>  - Theme "Adwaita" can't be loaded, file not found
+>  - JS ERROR about NetworkManager
+>  - gnome-session WARNING: Application 'gnome-shell.desktop' failed to
+> register before timeout
+>  - failed to play sound: file or data not found
+>  ... and more
+>
+> Last section of errors is:
+> ---------------------------------------
+> (gnome-shell:5091): Clutter-CRITICAL **: clutter_actor_queue_relayout:
+> assertion 'CLUTTER_IS_ACTOR (self) failed
+> Cannot open /dev/input/eventX: permission denied ## this was repeated 15 times
+>
+> (gnome-shell:5091): Clutter-CRITICAL **: clutter_actor_queue_relayout:
+> assertion 'CLUTTER_IS_ACTOR (self) failed
+> --EOF-------------------------------------
+>
+> --
+> wobo
+>
+
+ok tks,  this is mor ethan task-gnome miss them.
+
+I will fix task-gnome and push it really quickly
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005691.html b/zarb-ml/mageia-dev/2011-June/005691.html new file mode 100644 index 000000000..d3fa91d29 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005691.html @@ -0,0 +1,220 @@ + + + + [Mageia-dev] Lib policy change needed ? + + + + + + + + + +

[Mageia-dev] Lib policy change needed ?

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Wed Jun 15 10:44:25 CEST 2011 +

+
+ +
On Wed, 15 Jun 2011, Dexter Morgan wrote:
+
+> the last BS breakage makes me thing that we should adjust our
+> packaging policy and add only one lib per lib package.
+>
+>
+> On our last BS breakage we had as error :
+>
+>
+> A requested package cannot be installed:
+> seahorse-2.32.0-2.mga1.x86_64 (due to unsatisfied libgp11.so.0()(64bit))
+>
+>
+> because libgp11.so.0 was in libgcr0 but disappeared.
+
+This was of course a packaging error, the version postfix in the package 
+name should have been modified.
+
+> WDYT about this new policy ?
+
+Fine with me, always considered it strange when the lib version in the pkg 
+name does not correspond to major version of some of the libraries in a 
+package. I agree this policy change or clarification (if followed) will 
+likely prevent such mistakes in the future. And it should not cause any 
+problems since we have automatic library provides and dependencies.
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005692.html b/zarb-ml/mageia-dev/2011-June/005692.html new file mode 100644 index 000000000..584270129 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005692.html @@ -0,0 +1,118 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Wed Jun 15 11:02:23 CEST 2011 +

+
+ +
2011/6/15 Dexter Morgan <dmorganec at gmail.com>:
+> On Wed, Jun 15, 2011 at 10:34 AM, Wolfgang Bornath
+> <molch.b at googlemail.com> wrote:
+>> 2011/6/15 Dexter Morgan <dmorganec at gmail.com>:
+>>> On Wed, Jun 15, 2011 at 3:02 AM, Wolfgang Bornath
+>>> <molch.b at googlemail.com> wrote:
+>>>> 2011/6/15 Frank Griffin <ftg at roadrunner.com>:
+>>>>> On 06/14/2011 06:40 PM, Dexter Morgan wrote:
+>>>>>>
+>>>>>> Do you have gnome-control-center installed
+>>>>>
+>>>>> I have the same situation, and gnome-control-center is installed.
+>>>>
+>>>> Confirmed, same problem.
+>>>>
+>>>> Just switched a Mageia 1 to Cauldron via urpmi, installed task-gnome, no errors.
+>>>> After reboot and selecting Gnome3 the desktop builds nicely but as
+>>>> soon as I start any application after a couple of seconds I get the
+>>>> same error message, pressing "OK" does a restart of the xserver and
+>>>> I'm back at login.
+>>>
+>>> Do you have errors in your .xsession-errors ?
+>>
+>> Yes. lots of them! Many things are missing:
+>>  - Theme "Adwaita" can't be loaded, file not found
+>>  - JS ERROR about NetworkManager
+>>  - gnome-session WARNING: Application 'gnome-shell.desktop' failed to
+>> register before timeout
+>>  - failed to play sound: file or data not found
+>>  ... and more
+>>
+>> Last section of errors is:
+>> ---------------------------------------
+>> (gnome-shell:5091): Clutter-CRITICAL **: clutter_actor_queue_relayout:
+>> assertion 'CLUTTER_IS_ACTOR (self) failed
+>> Cannot open /dev/input/eventX: permission denied ## this was repeated 15 times
+>>
+>> (gnome-shell:5091): Clutter-CRITICAL **: clutter_actor_queue_relayout:
+>> assertion 'CLUTTER_IS_ACTOR (self) failed
+>> --EOF-------------------------------------
+>>
+>
+> ok tks,  this is mor ethan task-gnome miss them.
+>
+> I will fix task-gnome and push it really quickly
+
+Take your time, Gnome3 is not on my priority list :)
+BTW: I get the same errors when starting Gnome (2.x) on the same system.
+
+Other installed DEs working fine (KDE, icewm)
+-- 
+wobo
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005693.html b/zarb-ml/mageia-dev/2011-June/005693.html new file mode 100644 index 000000000..3601f6409 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005693.html @@ -0,0 +1,196 @@ + + + + [Mageia-dev] Broken BS + + + + + + + + + +

[Mageia-dev] Broken BS

+ Dexter Morgan + dmorganec at gmail.com +
+ Wed Jun 15 11:22:26 CEST 2011 +

+
+ +
On Wed, Jun 15, 2011 at 10:16 AM, Dexter Morgan <dmorganec at gmail.com> wrote:
+> Hi,
+>
+> sorry the update of gnome keyring broke the BS.
+>
+> I am fixing it .
+>
+
+The BS is now fixed .
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005694.html b/zarb-ml/mageia-dev/2011-June/005694.html new file mode 100644 index 000000000..4726ddd4b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005694.html @@ -0,0 +1,130 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Dexter Morgan + dmorganec at gmail.com +
+ Wed Jun 15 12:01:15 CEST 2011 +

+
+ +
On Wed, Jun 15, 2011 at 11:02 AM, Wolfgang Bornath
+<molch.b at googlemail.com> wrote:
+> 2011/6/15 Dexter Morgan <dmorganec at gmail.com>:
+>> On Wed, Jun 15, 2011 at 10:34 AM, Wolfgang Bornath
+>> <molch.b at googlemail.com> wrote:
+>>> 2011/6/15 Dexter Morgan <dmorganec at gmail.com>:
+>>>> On Wed, Jun 15, 2011 at 3:02 AM, Wolfgang Bornath
+>>>> <molch.b at googlemail.com> wrote:
+>>>>> 2011/6/15 Frank Griffin <ftg at roadrunner.com>:
+>>>>>> On 06/14/2011 06:40 PM, Dexter Morgan wrote:
+>>>>>>>
+>>>>>>> Do you have gnome-control-center installed
+>>>>>>
+>>>>>> I have the same situation, and gnome-control-center is installed.
+>>>>>
+>>>>> Confirmed, same problem.
+>>>>>
+>>>>> Just switched a Mageia 1 to Cauldron via urpmi, installed task-gnome, no errors.
+>>>>> After reboot and selecting Gnome3 the desktop builds nicely but as
+>>>>> soon as I start any application after a couple of seconds I get the
+>>>>> same error message, pressing "OK" does a restart of the xserver and
+>>>>> I'm back at login.
+>>>>
+>>>> Do you have errors in your .xsession-errors ?
+>>>
+>>> Yes. lots of them! Many things are missing:
+>>>  - Theme "Adwaita" can't be loaded, file not found
+>>>  - JS ERROR about NetworkManager
+>>>  - gnome-session WARNING: Application 'gnome-shell.desktop' failed to
+>>> register before timeout
+>>>  - failed to play sound: file or data not found
+>>>  ... and more
+>>>
+>>> Last section of errors is:
+>>> ---------------------------------------
+>>> (gnome-shell:5091): Clutter-CRITICAL **: clutter_actor_queue_relayout:
+>>> assertion 'CLUTTER_IS_ACTOR (self) failed
+>>> Cannot open /dev/input/eventX: permission denied ## this was repeated 15 times
+>>>
+>>> (gnome-shell:5091): Clutter-CRITICAL **: clutter_actor_queue_relayout:
+>>> assertion 'CLUTTER_IS_ACTOR (self) failed
+>>> --EOF-------------------------------------
+>>>
+>>
+>> ok tks,  this is mor ethan task-gnome miss them.
+>>
+>> I will fix task-gnome and push it really quickly
+>
+> Take your time, Gnome3 is not on my priority list :)
+> BTW: I get the same errors when starting Gnome (2.x) on the same system.
+>
+> Other installed DEs working fine (KDE, icewm)
+> --
+> wobo
+>
+
+can you try to install :
+
+networkmanager
+adwaita-gtk3-theme
+adwaita-cursor-theme
+
+and to restart gnome 3 ?
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005695.html b/zarb-ml/mageia-dev/2011-June/005695.html new file mode 100644 index 000000000..5b3c569c6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005695.html @@ -0,0 +1,82 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Wed Jun 15 12:06:57 CEST 2011 +

+
+ +
On Wed, 15 Jun 2011, Wolfgang Bornath wrote:
+
+> BTW: I get the same errors when starting Gnome (2.x) on the same system.
+
+How do you start it? There's no gnome 2.x session listed in gdm, both 
+'GNOME' and GNOME3' are gnome 3 sessions (without any difference AFAIK). I 
+was thinking of making the current 'GNOME' start up a 'fallback' session, 
+while current 'GNOME3' would stay automatic: 'shell' session switching 
+to 'fallback' when no 3d acceleration is available. But this is not 
+entirely trivial.
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005696.html b/zarb-ml/mageia-dev/2011-June/005696.html new file mode 100644 index 000000000..6c806b038 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005696.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Dexter Morgan + dmorganec at gmail.com +
+ Wed Jun 15 12:20:34 CEST 2011 +

+
+ +
On Wed, Jun 15, 2011 at 12:06 PM, Christiaan Welvaart
+<cjw at daneel.dyndns.org> wrote:
+> On Wed, 15 Jun 2011, Wolfgang Bornath wrote:
+>
+>> BTW: I get the same errors when starting Gnome (2.x) on the same system.
+>
+> How do you start it? There's no gnome 2.x session listed in gdm, both
+> 'GNOME' and GNOME3' are gnome 3 sessions (without any difference AFAIK). I
+> was thinking of making the current 'GNOME' start up a 'fallback' session,
+> while current 'GNOME3' would stay automatic: 'shell' session switching to
+> 'fallback' when no 3d acceleration is available. But this is not entirely
+> trivial.
+>
+>
+>    Christiaan
+>
+
+For now there is only Gnome ( the Gnome 3 preview is not here anymore
+)  but as soon as you know how to start the fallback session we will
+be able to readd Gnome 3 startup
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005697.html b/zarb-ml/mageia-dev/2011-June/005697.html new file mode 100644 index 000000000..c320b8efe --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005697.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Wed Jun 15 13:22:54 CEST 2011 +

+
+ +
2011/6/15 Dexter Morgan <dmorganec at gmail.com>:
+>
+> can you try to install :
+>
+> networkmanager
+> adwaita-gtk3-theme
+> adwaita-cursor-theme
+>
+> and to restart gnome 3 ?
+
+Installed the packages including dependencies, rebooted, logged in for
+Gnome3 - same result!
+The warning about networkmanager is gone but some others came up. I
+saved .xsession-errors in the state when the desktop error message
+appeared on the screen.
+
+Attached is xsession-errors.sav
+
+-- 
+wobo
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: xsession-errors.sav
+Type: application/octet-stream
+Size: 6427 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20110615/69b5af16/attachment.obj>
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005698.html b/zarb-ml/mageia-dev/2011-June/005698.html new file mode 100644 index 000000000..0019a5a3b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005698.html @@ -0,0 +1,84 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Olav Vitters + olav at vitters.nl +
+ Wed Jun 15 13:44:13 CEST 2011 +

+
+ +
On Wed, Jun 15, 2011 at 01:22:54PM +0200, Wolfgang Bornath wrote:
+> Installed the packages including dependencies, rebooted, logged in for
+> Gnome3 - same result!
+
+Could you also run:
+  gnome-shell --replace > ~/tmp/gnome-shell-log 2>&1
+
+>From e.g. XFCE? This as I wonder what error messages gnome-shell
+produces.
+
+Regarding the xsession stuff. The network manager seems to be that it
+couldn't find the dbus service.
+
+The 'failed to register' seems to be related to gnome-power-manager:
+https://bugzilla.redhat.com/show_bug.cgi?id=480206
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005699.html b/zarb-ml/mageia-dev/2011-June/005699.html new file mode 100644 index 000000000..8e0fe385d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005699.html @@ -0,0 +1,199 @@ + + + + [Mageia-dev] dokuwiki import + + + + + + + + + +

[Mageia-dev] dokuwiki import

+ Cazzaniga Sandro + cazzaniga.sandro at gmail.com +
+ Wed Jun 15 13:39:20 CEST 2011 +

+
+ +
Le 15/06/2011 10:17, Cazzaniga Sandro a écrit :
+> hi,
+> 
+> I've updated and imported dokuwiki
+> (https://bugs.mageia.org/show_bug.cgi?id=1096). Can someone review it
+> before push, please?
+> 
+> thanks in advance.
+Any answers. I push it.
+
+-- 
+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
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005700.html b/zarb-ml/mageia-dev/2011-June/005700.html new file mode 100644 index 000000000..17bc49211 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005700.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Stew Benedict + stewbintn at gmail.com +
+ Wed Jun 15 13:55:24 CEST 2011 +

+
+ +
On 06/12/2011 08:25 AM, Angelo Naselli wrote:
+> In data mercoledì 8 giugno 2011 23:53:51, Ahmad Samir ha scritto:
+>>>> Right, I probably phrased that one wrongly; I meant:
+>>>> fixes a serious bug, e.g. crashing, segfaulting
+>>> I don't think we should exclude non-serious bugs :)
+>> Depends, overworking the sec team doesn't look like a good aspect...
+>> (that's why I liked contrib in mdv, I could push an update any time,
+>> without having to go though the bug report ->  QA ->  Sec team loop).
+> Well here we could stop at QA team step, or at least someone more that can
+> test  and say that the fixing is good...
+>
+So,
+
+We've had a lot of discussion, which is good, but imho we need to start 
+getting some updates out the door. Users are asking for them and the 
+CVEs just keep rolling in.
+
+As I understand it, the mechanics are in place to issue updates, and 
+I've put together a page as a first pass at a policy, based on my memory 
+of how things worked in the past and what I've picked up from the 
+discussion.
+
+http://mageia.org/wiki/doku.php?id=updates_policy
+
+Randomly, I'm targeting 2 bugs to push through, to test the process:
+
+https://bugs.mageia.org/show_bug.cgi?id=1084 (vde2, app crashes)
+https://bugs.mageia.org/show_bug.cgi?id=1521 (subversion, security issue)
+
+Now, first problem is we still don't have a maintainer database, so who 
+gets the assignment, the person that first imported the package?
+Perhaps this is the first change to the policy - maintainer or any 
+interested packager initiates the update
+
+-- 
+Stew Benedict
+
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005701.html b/zarb-ml/mageia-dev/2011-June/005701.html new file mode 100644 index 000000000..1322b1265 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005701.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Wed Jun 15 14:03:09 CEST 2011 +

+
+ +
2011/6/15 Olav Vitters <olav at vitters.nl>:
+> On Wed, Jun 15, 2011 at 01:22:54PM +0200, Wolfgang Bornath wrote:
+>> Installed the packages including dependencies, rebooted, logged in for
+>> Gnome3 - same result!
+>
+> Could you also run:
+>  gnome-shell --replace > ~/tmp/gnome-shell-log 2>&1
+>
+> >From e.g. XFCE? This as I wonder what error messages gnome-shell
+> produces.
+
+Did it in a xterm in icewm - hitting [Enter] with this command string
+*immediately* kicked me out of the session and restarted xserver.
+
+Contents of ~/tmp/gnome-shell-log is:
+-----------------------------------------------------------
+Fensterverwalter-Warnung:Thema »Adwaita« konnte nicht geladen werden:
+Es konnte keine gültige Datei für das Thema »Adwaita« gefunden werden
+-----------------------------------------------------------
+Translates to:
+windowmanager-warning: Theme "Adwaita" could not be loaded. No valid
+file found for theme "Adwaita".
+
+BTW: Before I carried out the command I did an update, last mirror
+sync was 11:30 UTC (32 minutes ago)
+
+-- 
+wobo
+
+ + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005702.html b/zarb-ml/mageia-dev/2011-June/005702.html new file mode 100644 index 000000000..3197f0cb2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005702.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Michael Scherer + misc at zarb.org +
+ Wed Jun 15 14:10:39 CEST 2011 +

+
+ +
Le mercredi 15 juin 2011 à 07:55 -0400, Stew Benedict a écrit :
+> On 06/12/2011 08:25 AM, Angelo Naselli wrote:
+> > In data mercoledì 8 giugno 2011 23:53:51, Ahmad Samir ha scritto:
+> >>>> Right, I probably phrased that one wrongly; I meant:
+> >>>> fixes a serious bug, e.g. crashing, segfaulting
+> >>> I don't think we should exclude non-serious bugs :)
+> >> Depends, overworking the sec team doesn't look like a good aspect...
+> >> (that's why I liked contrib in mdv, I could push an update any time,
+> >> without having to go though the bug report ->  QA ->  Sec team loop).
+> > Well here we could stop at QA team step, or at least someone more that can
+> > test  and say that the fixing is good...
+> >
+> So,
+> 
+> We've had a lot of discussion, which is good, but imho we need to start 
+> getting some updates out the door. Users are asking for them and the 
+> CVEs just keep rolling in.
+> 
+> As I understand it, the mechanics are in place to issue updates, and 
+> I've put together a page as a first pass at a policy, based on my memory 
+> of how things worked in the past and what I've picked up from the 
+> discussion.
+> 
+> http://mageia.org/wiki/doku.php?id=updates_policy
+> 
+> Randomly, I'm targeting 2 bugs to push through, to test the process:
+> 
+> https://bugs.mageia.org/show_bug.cgi?id=1084 (vde2, app crashes)
+> https://bugs.mageia.org/show_bug.cgi?id=1521 (subversion, security issue)
+> 
+> Now, first problem is we still don't have a maintainer database, so who 
+> gets the assignment, the person that first imported the package?
+> Perhaps this is the first change to the policy - maintainer or any 
+> interested packager initiates the update
+
+Sound sensible, yes.
+
+The idea IMHO is not to prevent people for doing the work if they wish,
+but if there is no volunteer, it should be the duty of someone, and this
+someone is the maintainer.
+Now, we do not have a official maintainer db, but the test instance is
+still here afaik. So yes, picking someone from the list of person that
+committed would do the trick. 
+
+-- 
+Michael Scherer
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005703.html b/zarb-ml/mageia-dev/2011-June/005703.html new file mode 100644 index 000000000..6737be5c3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005703.html @@ -0,0 +1,153 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ lebarhon + lebarhon at free.fr +
+ Wed Jun 15 14:15:11 CEST 2011 +

+
+ +
by *dave 
+<https://forums.mageia.org/en/memberlist.php?mode=viewprofile&u=194>* » 
+Jun 14th, '11, 22:32
+One release every year with the related updated (don't wait one year for 
+have ad updated software) is better. The best could be an half-rolling 
+like chakra but this option isn't in the proposals :lol:
+
+
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110615/475dfbf0/attachment.html>
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: icon_lol.gif
+Type: image/gif
+Size: 707 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20110615/475dfbf0/attachment.gif>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005704.html b/zarb-ml/mageia-dev/2011-June/005704.html new file mode 100644 index 000000000..5ed8982a3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005704.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Thomas Backlund + tmb at mageia.org +
+ Wed Jun 15 14:20:40 CEST 2011 +

+
+ +
Michael Scherer skrev 15.6.2011 15:10:
+> Le mercredi 15 juin 2011 à 07:55 -0400, Stew Benedict a écrit :
+>> On 06/12/2011 08:25 AM, Angelo Naselli wrote:
+>>> In data mercoledì 8 giugno 2011 23:53:51, Ahmad Samir ha scritto:
+>>>>>> Right, I probably phrased that one wrongly; I meant:
+>>>>>> fixes a serious bug, e.g. crashing, segfaulting
+>>>>> I don't think we should exclude non-serious bugs :)
+>>>> Depends, overworking the sec team doesn't look like a good aspect...
+>>>> (that's why I liked contrib in mdv, I could push an update any time,
+>>>> without having to go though the bug report ->   QA ->   Sec team loop).
+>>> Well here we could stop at QA team step, or at least someone more that can
+>>> test  and say that the fixing is good...
+>>>
+>> So,
+>>
+>> We've had a lot of discussion, which is good, but imho we need to start
+>> getting some updates out the door. Users are asking for them and the
+>> CVEs just keep rolling in.
+>>
+>> As I understand it, the mechanics are in place to issue updates, and
+>> I've put together a page as a first pass at a policy, based on my memory
+>> of how things worked in the past and what I've picked up from the
+>> discussion.
+>>
+>> http://mageia.org/wiki/doku.php?id=updates_policy
+>>
+>> Randomly, I'm targeting 2 bugs to push through, to test the process:
+>>
+>> https://bugs.mageia.org/show_bug.cgi?id=1084 (vde2, app crashes)
+>> https://bugs.mageia.org/show_bug.cgi?id=1521 (subversion, security issue)
+>>
+>> Now, first problem is we still don't have a maintainer database, so who
+>> gets the assignment, the person that first imported the package?
+>> Perhaps this is the first change to the policy - maintainer or any
+>> interested packager initiates the update
+>
+> Sound sensible, yes.
+>
+> The idea IMHO is not to prevent people for doing the work if they wish,
+> but if there is no volunteer, it should be the duty of someone, and this
+> someone is the maintainer.
+> Now, we do not have a official maintainer db, but the test instance is
+> still here afaik. So yes, picking someone from the list of person that
+> committed would do the trick.
+>
+
+BTW, should we have a read-only security/update-announce ml that where 
+we mail about all updates ?
+
+--
+Thomas
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005705.html b/zarb-ml/mageia-dev/2011-June/005705.html new file mode 100644 index 000000000..955ee3964 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005705.html @@ -0,0 +1,211 @@ + + + + [Mageia-dev] [RPM] cauldron core/release networkmanager-0.8.9997-0.1.1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release networkmanager-0.8.9997-0.1.1.mga2

+ JA Magallón + jamagallon at ono.com +
+ Wed Jun 15 14:42:30 CEST 2011 +

+
+ +
On Tue, 14 Jun 2011 20:12:24 +0200 (CEST), Mageia Team <buildsystem-daemon at mageia.org> wrote:
+
+> Name        : networkmanager               Relocations: (not relocatable)
+> Version     : 0.8.9997                          Vendor: Mageia.Org
+> Release     : 0.1.1.mga2                    Build Date: Tue Jun 14 20:07:17 2011
+> Install Date: (not installed)               Build Host: ecosse
+> Group       : System/Base                   Source RPM: (none)
+> Size        : 1554806                          License: GPLv2+
+> Signature   : (none)
+> Packager    : Mageia Team <http://www.mageia.org>
+> URL         : http://www.gnome.org/projects/NetworkManager/
+> Summary     : Network connection manager and user applications
+> Description :
+> NetworkManager attempts to keep an active network connection available at all
+> times.  It is intended only for the desktop use-case, and is not intended for
+> usage on servers.   The point of NetworkManager is to make networking
+> configuration and setup as painless and automatic as possible.  If using DHCP,
+> NetworkManager is _intended_ to replace default routes, obtain IP addresses
+> from a DHCP server, and change nameservers whenever it sees fit.
+> 
+> dmorgan <dmorgan> 0.8.9997-0.1.1.mga2:
+> + Revision: 106192
+> - Use autogen.sh
+> - New version 0.8.9997
+
+This is missing the 'ifcfg-mdv' and 'keyfile' plugins...
+
+-- 
+J.A. Magallon <jamagallon()ono!com>     \                 Winter is coming...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005706.html b/zarb-ml/mageia-dev/2011-June/005706.html new file mode 100644 index 000000000..707a80726 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005706.html @@ -0,0 +1,213 @@ + + + + [Mageia-dev] [RPM] cauldron core/release networkmanager-0.8.9997-0.1.1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release networkmanager-0.8.9997-0.1.1.mga2

+ Dexter Morgan + dmorganec at gmail.com +
+ Wed Jun 15 14:44:33 CEST 2011 +

+
+ +
On Tue, Jun 14, 2011 at 8:12 PM, Mageia Team
+<buildsystem-daemon at mageia.org> wrote:
+> Name        : networkmanager               Relocations: (not relocatable)
+> Version     : 0.8.9997                          Vendor: Mageia.Org
+> Release     : 0.1.1.mga2                    Build Date: Tue Jun 14 20:07:17 2011
+> Install Date: (not installed)               Build Host: ecosse
+> Group       : System/Base                   Source RPM: (none)
+> Size        : 1554806                          License: GPLv2+
+> Signature   : (none)
+> Packager    : Mageia Team <http://www.mageia.org>
+> URL         : http://www.gnome.org/projects/NetworkManager/
+> Summary     : Network connection manager and user applications
+> Description :
+> NetworkManager attempts to keep an active network connection available at all
+> times.  It is intended only for the desktop use-case, and is not intended for
+> usage on servers.   The point of NetworkManager is to make networking
+> configuration and setup as painless and automatic as possible.  If using DHCP,
+> NetworkManager is _intended_ to replace default routes, obtain IP addresses
+> from a DHCP server, and change nameservers whenever it sees fit.
+>
+> dmorgan <dmorgan> 0.8.9997-0.1.1.mga2:
+> + Revision: 106192
+> - Use autogen.sh
+> - New version 0.8.9997
+
+Yes i added a comment on the spec file telling  this need to be rediffed.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005707.html b/zarb-ml/mageia-dev/2011-June/005707.html new file mode 100644 index 000000000..49135a711 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005707.html @@ -0,0 +1,62 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Dexter Morgan + dmorganec at gmail.com +
+ Wed Jun 15 14:50:33 CEST 2011 +

+
+ +
On Wed, Jun 15, 2011 at 2:20 PM, Thomas Backlund <tmb at mageia.org> wrote:
+>
+> BTW, should we have a read-only security/update-announce ml that where we
+> mail about all updates ?
+>
+yes seems a must have to push updates descriptions , distributions affected, ...
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005708.html b/zarb-ml/mageia-dev/2011-June/005708.html new file mode 100644 index 000000000..c4571d118 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005708.html @@ -0,0 +1,190 @@ + + + + [Mageia-dev] [RPM] cauldron core/release networkmanager-0.8.9997-0.1.1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release networkmanager-0.8.9997-0.1.1.mga2

+ John Balcaen + mikala at mageia.org +
+ Wed Jun 15 15:02:21 CEST 2011 +

+
+ +
2011/6/15 JA Magallón <jamagallon at ono.com>:
+[...]
+>
+> This is missing the 'ifcfg-mdv' and 'keyfile' plugins...
+>
+in fact only the ifcfg-mdv plugin is really missing.
+keyfile should be available.
+
+-- 
+Balcaen John
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005709.html b/zarb-ml/mageia-dev/2011-June/005709.html new file mode 100644 index 000000000..b08ca93a0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005709.html @@ -0,0 +1,69 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Stew Benedict + stewbintn at gmail.com +
+ Wed Jun 15 15:22:42 CEST 2011 +

+
+ +
On 06/15/2011 08:50 AM, Dexter Morgan wrote:
+> On Wed, Jun 15, 2011 at 2:20 PM, Thomas Backlund<tmb at mageia.org>  wrote:
+>> BTW, should we have a read-only security/update-announce ml that where we
+>> mail about all updates ?
+>>
+> yes seems a must have to push updates descriptions , distributions affected, ...
+>
+That is accounted for in the policy document (last line)
+
+-- 
+Stew Benedict
+
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005710.html b/zarb-ml/mageia-dev/2011-June/005710.html new file mode 100644 index 000000000..104e452a3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005710.html @@ -0,0 +1,194 @@ + + + + [Mageia-dev] [RPM] cauldron core/release task-gnome-2-0.1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release task-gnome-2-0.1.mga2

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Wed Jun 15 15:31:50 CEST 2011 +

+
+ +
On 15 June 2011 12:07, Mageia Team <buildsystem-daemon at mageia.org> wrote:
+> dmorgan <dmorgan> 1:2-0.1.mga2:
+> + Revision: 106759
+> - Add some more requires for gnome3
+> - Remove buildroot
+>  Remove old obsoletes
+
+Shouldn't we have task-gnome3?
+Or do we plan to just have gnome3 in Mga2?
+See you
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005711.html b/zarb-ml/mageia-dev/2011-June/005711.html new file mode 100644 index 000000000..e68c0579e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005711.html @@ -0,0 +1,201 @@ + + + + [Mageia-dev] [RPM] cauldron core/release task-gnome-2-0.1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release task-gnome-2-0.1.mga2

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Wed Jun 15 15:48:05 CEST 2011 +

+
+ +
On Wed, 15 Jun 2011, Thierry Vignaud wrote:
+
+> On 15 June 2011 12:07, Mageia Team <buildsystem-daemon at mageia.org> wrote:
+>> dmorgan <dmorgan> 1:2-0.1.mga2:
+>> + Revision: 106759
+>> - Add some more requires for gnome3
+>> - Remove buildroot
+>>  Remove old obsoletes
+>
+> Shouldn't we have task-gnome3?
+> Or do we plan to just have gnome3 in Mga2?
+
+If someone fixes gnome2 so it's parallel installable we can have a 
+task-gnome2.
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005712.html b/zarb-ml/mageia-dev/2011-June/005712.html new file mode 100644 index 000000000..6af95214b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005712.html @@ -0,0 +1,154 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Olav Vitters + olav at vitters.nl +
+ Wed Jun 15 15:57:58 CEST 2011 +

+
+ +
On Sun, Jun 12, 2011 at 10:46:33PM +0200, Michael Scherer wrote:
+> Proposal 1: 
+> 6 months release cycle -> 12 months life cycle
+
+> Proposal 2: 
+> 9 months release cycle -> 18 months life cycle  
+
+> Proposal 3: 
+> 12 months release cycle -> 24 months life cycle
+
+
+Regarding release cycles from a GNOME perspective (so 6 months):
++ 6 months is great for stability; with the various freezes and so on,
+  there is not a lot of development going on, so code doesn't become too
+  unstable
+
++ very predictable for everyone (releases + freezes are always in the
+same period)
+
++ more immediate feedback from users
+
+- developers might get too focussed on the 6 months, and development
+  might slow down after a few years (happened with GNOME 2.x until 3.0
+  was suggested)
+  to avoid it you need something like a 'feature map' (plan beforehand
+  what to do next and when you think the development would be done;
+  don't focus too much on the next version)
+
+- big changes are difficult to do in 6 months; though you can branch and
+  so on, it isn't always possible (interaction between modules and so
+  on)
+  e.g. new GDM or the gnome-vfs -> gvfs switch
+
+- stable release is not supported/looked after for too long
+
+Distribution is of course different from just software, so feel free to
+ignore.
+
+There was discussion in the past to make a release every 6 months, but
+work on it for 9 (there would be a 3 month overlap where developers had
+to work on both branches). E.g. by having a restricted 'Mageia 2' while
+still having an 'anything goes' Cauldron.
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005713.html b/zarb-ml/mageia-dev/2011-June/005713.html new file mode 100644 index 000000000..2dd3c200f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005713.html @@ -0,0 +1,201 @@ + + + + [Mageia-dev] [RPM] cauldron core/release task-gnome-2-0.1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release task-gnome-2-0.1.mga2

+ Dexter Morgan + dmorganec at gmail.com +
+ Wed Jun 15 16:29:03 CEST 2011 +

+
+ +
On Wed, Jun 15, 2011 at 3:31 PM, Thierry Vignaud
+<thierry.vignaud at gmail.com> wrote:
+> On 15 June 2011 12:07, Mageia Team <buildsystem-daemon at mageia.org> wrote:
+>> dmorgan <dmorgan> 1:2-0.1.mga2:
+>> + Revision: 106759
+>> - Add some more requires for gnome3
+>> - Remove buildroot
+>>  Remove old obsoletes
+>
+> Shouldn't we have task-gnome3?
+> Or do we plan to just have gnome3 in Mga2?
+> See you
+>
+
+in fact i named it task-gnome because this is supposed to be '"main
+gnome" but i see no pb to rename it to task-gnom3 , just that i think
+it will add useless provides/obsoletes
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005714.html b/zarb-ml/mageia-dev/2011-June/005714.html new file mode 100644 index 000000000..8c380003b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005714.html @@ -0,0 +1,201 @@ + + + + [Mageia-dev] Tonight's meeting + + + + + + + + + +

[Mageia-dev] Tonight's meeting

+ Anne nicolas + ennael at mageia.org +
+ Wed Jun 15 17:00:03 CEST 2011 +

+
+ +
As usual at 19h UTC on #mageia-dev. Here are the topics
+
+- post-mortem review
+- quick summary of current cycle release discussion
+- start of stable updates
+- mentoring review
+
+Cheers !
+
+-- 
+Anne
+http://www.mageia.org
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110615/c4e03860/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005715.html b/zarb-ml/mageia-dev/2011-June/005715.html new file mode 100644 index 000000000..e64b4b2c5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005715.html @@ -0,0 +1,196 @@ + + + + [Mageia-dev] [RPM] cauldron core/release task-gnome-2-0.1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release task-gnome-2-0.1.mga2

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Wed Jun 15 17:05:04 CEST 2011 +

+
+ +
On 15 June 2011 16:29, Dexter Morgan <dmorganec at gmail.com> wrote:
+>> Shouldn't we have task-gnome3?
+>> Or do we plan to just have gnome3 in Mga2?
+>
+> in fact i named it task-gnome because this is supposed to be '"main
+> gnome"
+
+That's fine
+
+> but i see no pb to rename it to task-gnom3 , just that i think
+> it will add useless provides/obsoletes
+
+Logically we should got task-gnome & task-gnome2 if we ever support both
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005716.html b/zarb-ml/mageia-dev/2011-June/005716.html new file mode 100644 index 000000000..3ffb2ef9b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005716.html @@ -0,0 +1,200 @@ + + + + [Mageia-dev] [RPM] cauldron core/release task-gnome-2-0.1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release task-gnome-2-0.1.mga2

+ Dexter Morgan + dmorganec at gmail.com +
+ Wed Jun 15 17:07:41 CEST 2011 +

+
+ +
On Wed, Jun 15, 2011 at 5:05 PM, Thierry Vignaud
+<thierry.vignaud at gmail.com> wrote:
+> On 15 June 2011 16:29, Dexter Morgan <dmorganec at gmail.com> wrote:
+>>> Shouldn't we have task-gnome3?
+>>> Or do we plan to just have gnome3 in Mga2?
+>>
+>> in fact i named it task-gnome because this is supposed to be '"main
+>> gnome"
+>
+> That's fine
+>
+>> but i see no pb to rename it to task-gnom3 , just that i think
+>> it will add useless provides/obsoletes
+>
+> Logically we should got task-gnome & task-gnome2 if we ever support both
+>
+
+i am fine with this naming too.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005717.html b/zarb-ml/mageia-dev/2011-June/005717.html new file mode 100644 index 000000000..f4875ac5d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005717.html @@ -0,0 +1,195 @@ + + + + [Mageia-dev] Mageia 2 - Improving educational programs + + + + + + + + + +

[Mageia-dev] Mageia 2 - Improving educational programs

+ mammig_linux mammig_linux + mammig.linux at gmail.com +
+ Wed Jun 15 17:43:15 CEST 2011 +

+
+ +
Hello,
+
+I'm very interresting by this project.
+Currently i'm a member of the french i18n team ( transator ) and i
+never make those strange things you call "package".
+( but maybe i can learn how to do it )
+I will be happy to help you ( if i can )
+
+see you,
+mammig
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005718.html b/zarb-ml/mageia-dev/2011-June/005718.html new file mode 100644 index 000000000..75c6f6b7b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005718.html @@ -0,0 +1,218 @@ + + + + [Mageia-dev] nspluginwrapper reborn! + + + + + + + + + +

[Mageia-dev] nspluginwrapper reborn!

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Wed Jun 15 18:05:27 CEST 2011 +

+
+ +
Hello,
+
+nspluginwrapper has been updated to 1.3.x and now to 1.4.x, i.e. it
+has a new upstream maintainer http://nspluginwrapper.davidben.net
+
+For the first time in probably 2-3years, the 32bit Adobe Flash player
+seemed to work for me in a 64bit browser (I tested firefox and
+konqueror).
+
+So give it a shot.
+
+(I've been suggesting, to users, _not_ to use nspluginwrapper for some
+years now, since it never worked for me and I saw a lot of reports of
+it not working in forums and bug reports, so this is my "I take that
+back, it just needed some upstream love and care").
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005719.html b/zarb-ml/mageia-dev/2011-June/005719.html new file mode 100644 index 000000000..7de5c104d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005719.html @@ -0,0 +1,238 @@ + + + + [Mageia-dev] Lib policy change needed ? + + + + + + + + + +

[Mageia-dev] Lib policy change needed ?

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Wed Jun 15 18:15:58 CEST 2011 +

+
+ +
On 15 June 2011 10:44, Christiaan Welvaart <cjw at daneel.dyndns.org> wrote:
+> On Wed, 15 Jun 2011, Dexter Morgan wrote:
+>
+>> the last BS breakage makes me thing that we should adjust our
+>> packaging policy and add only one lib per lib package.
+>>
+>>
+>> On our last BS breakage we had as error :
+>>
+>>
+>> A requested package cannot be installed:
+>> seahorse-2.32.0-2.mga1.x86_64 (due to unsatisfied libgp11.so.0()(64bit))
+>>
+>>
+>> because libgp11.so.0 was in libgcr0 but disappeared.
+>
+> This was of course a packaging error, the version postfix in the package
+> name should have been modified.
+>
+>> WDYT about this new policy ?
+>
+> Fine with me, always considered it strange when the lib version in the pkg
+> name does not correspond to major version of some of the libraries in a
+> package. I agree this policy change or clarification (if followed) will
+> likely prevent such mistakes in the future. And it should not cause any
+> problems since we have automatic library provides and dependencies.
+>
+>
+>    Christiaan
+>
+
+Splitting every single lib in a separate package isn't ideal, IMHO
+(just look at how many kde library packages we have).
+
+Libraries that have the same major from the same src.rpm should be in
+the same sub-package as much as possible (i.e. all glib-related libs
+in one package, extensions (e.g. nautilus extensions) could be each in
+a sub-package); and split only if something would require one lib but
+not another from that lib package, i.e. split when needed, not
+generally.
+
+For example look at Amarok:
+$ urpmf --sourcerpm :amarok | sort | grep lib
+lib64amarokcore1:amarok-2.4.1-0.mga1.src.rpm
+lib64amaroklib1:amarok-2.4.1-0.mga1.src.rpm
+lib64amarokocsclient4:amarok-2.4.1-0.mga1.src.rpm
+lib64amarokpud1:amarok-2.4.1-0.mga1.src.rpm
+lib64amarok-sqlcollection1:amarok-2.4.1-0.mga1.src.rpm
+lib64amarok-transcoding1:amarok-2.4.1-0.mga1.src.rpm
+
+every lib is in a separate package, even though:
+- Nothing else uses any of those libs other than Amarok
+- Amarok is linked against all of those libs and it wouldn't work if
+you uninstall any of them
+
+In such a case grouping all of them in one lib*amarok package would be
+easier, there'll never be any file conflicts when the mojor of any of
+them changes.
+
+P.S. I am not a packaging expert.
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005720.html b/zarb-ml/mageia-dev/2011-June/005720.html new file mode 100644 index 000000000..74ddf6d2c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005720.html @@ -0,0 +1,218 @@ + + + + [Mageia-dev] Tonight's meeting + + + + + + + + + +

[Mageia-dev] Tonight's meeting

+ Angelo Naselli + anaselli at linux.it +
+ Wed Jun 15 18:19:02 CEST 2011 +

+
+ +
mercoledì 15 giugno 2011 alle 17:00, Anne nicolas ha scritto:
+> As usual at 19h UTC on #mageia-dev. Here are the topics
+> 
+> - post-mortem review
+> - quick summary of current cycle release discussion
+> - start of stable updates
+> - mentoring review
+> 
+> Cheers !
+I cannot attend tonight sorry, i will read all after.
+
+Once we've decided the release cycle etc, i'd like to add
+a topic, about my proposal of improving educational 
+programs.
+
+It seems people like the idea, I received some private good feed-backs.
+
+What they ask mainly is to have info from main channels (e.g. blog, forum...)
+in which users can give their contribution. Before having users requests though,
+i believe we need to know how to start/go on this adventure...
+
+I'm ready to go on working on what i started i mageia 1, but i'm also 
+need to be honest and tell people clear i do that in my very little spare
+time, so i could not probably be able to follow all the requests (and all
+our channels).
+
+Is that possible and make sense? -add a future topic, i mean-
+
+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/20110615/4bb89922/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005721.html b/zarb-ml/mageia-dev/2011-June/005721.html new file mode 100644 index 000000000..db3dd4cf3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005721.html @@ -0,0 +1,220 @@ + + + + [Mageia-dev] Mageia 2 - Improving educational programs + + + + + + + + + +

[Mageia-dev] Mageia 2 - Improving educational programs

+ Angelo Naselli + anaselli at linux.it +
+ Wed Jun 15 18:32:17 CEST 2011 +

+
+ +
mercoledì 15 giugno 2011 alle 17:43, mammig_linux mammig_linux ha scritto:
+> Hello,
+Hello and welcome!
+
+> I'm very interresting by this project.
+> Currently i'm a member of the french i18n team ( transator ) and i
+> never make those strange things you call "package".
+> ( but maybe i can learn how to do it )
+> I will be happy to help you ( if i can )
+As said via irc, we can start collecting the most educational project
+links, maybe starting to add what are into edubuntu and that
+are not in mageia already.
+It could be easier for me -and for other packagers who partecipate-
+to start packaging things, instead of looking for them and working on them after :) 
+
+We could start a wiki page in which adding missing packages for instance.
+Something like
+project name - project url - type  - packager 
+
+Edu Type could help to get a kind of group info, i mean how they could be
+grouped in.
+
+I'd like to start with international projects, those that have localizations
+and can be used by almost all. Local project should be added by users that can
+maintain them and can *understand* them ;)
+
+WDYT?
+
+Cheeers,
+	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/20110615/7085b5e6/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005722.html b/zarb-ml/mageia-dev/2011-June/005722.html new file mode 100644 index 000000000..56a2af030 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005722.html @@ -0,0 +1,71 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Thorsten van Lil + tvl83 at gmx.de +
+ Wed Jun 15 18:55:39 CEST 2011 +

+
+ +
Am Donnerstag, 9. Juni 2011, 10:44:23 schrieb JA Magallón:
+> if I select "System settings" o launch firefox, immediately I get a
+> fullscreen error about "something went wrong, plz logout and in again"
+
+Same for me two days back. Since yesterday it works relatively well. I get the 
+mentioned error right after login, but: If you just press Alt+F4 the error 
+message vanish and you can start working us usual.
+
+Regards,
+Thorsten
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005723.html b/zarb-ml/mageia-dev/2011-June/005723.html new file mode 100644 index 000000000..3668d52f7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005723.html @@ -0,0 +1,249 @@ + + + + [Mageia-dev] Lib policy change needed ? + + + + + + + + + +

[Mageia-dev] Lib policy change needed ?

+ Anssi Hannula + anssi.hannula at iki.fi +
+ Wed Jun 15 19:06:37 CEST 2011 +

+
+ +
On 15.06.2011 19:15, Ahmad Samir wrote:
+> On 15 June 2011 10:44, Christiaan Welvaart <cjw at daneel.dyndns.org> wrote:
+>> On Wed, 15 Jun 2011, Dexter Morgan wrote:
+>>
+>>> the last BS breakage makes me thing that we should adjust our
+>>> packaging policy and add only one lib per lib package.
+>>>
+>>>
+>>> On our last BS breakage we had as error :
+>>>
+>>>
+>>> A requested package cannot be installed:
+>>> seahorse-2.32.0-2.mga1.x86_64 (due to unsatisfied libgp11.so.0()(64bit))
+>>>
+>>>
+>>> because libgp11.so.0 was in libgcr0 but disappeared.
+>>
+>> This was of course a packaging error, the version postfix in the package
+>> name should have been modified.
+>>
+>>> WDYT about this new policy ?
+>>
+>> Fine with me, always considered it strange when the lib version in the pkg
+>> name does not correspond to major version of some of the libraries in a
+>> package. I agree this policy change or clarification (if followed) will
+>> likely prevent such mistakes in the future. And it should not cause any
+>> problems since we have automatic library provides and dependencies.
+>>
+>>
+>>    Christiaan
+>>
+> 
+> Splitting every single lib in a separate package isn't ideal, IMHO
+> (just look at how many kde library packages we have).
+> 
+> Libraries that have the same major from the same src.rpm should be in
+> the same sub-package as much as possible (i.e. all glib-related libs
+> in one package, extensions (e.g. nautilus extensions) could be each in
+> a sub-package); and split only if something would require one lib but
+> not another from that lib package, i.e. split when needed, not
+> generally.
+
+I'd do the split when there is a potential for the majors to be
+different (i.e. the major numbers are defined separately for each library).
+
+> For example look at Amarok:
+> $ urpmf --sourcerpm :amarok | sort | grep lib
+> lib64amarokcore1:amarok-2.4.1-0.mga1.src.rpm
+> lib64amaroklib1:amarok-2.4.1-0.mga1.src.rpm
+> lib64amarokocsclient4:amarok-2.4.1-0.mga1.src.rpm
+> lib64amarokpud1:amarok-2.4.1-0.mga1.src.rpm
+> lib64amarok-sqlcollection1:amarok-2.4.1-0.mga1.src.rpm
+> lib64amarok-transcoding1:amarok-2.4.1-0.mga1.src.rpm
+> 
+> every lib is in a separate package, even though:
+> - Nothing else uses any of those libs other than Amarok
+> - Amarok is linked against all of those libs and it wouldn't work if
+> you uninstall any of them
+> 
+> In such a case grouping all of them in one lib*amarok package would be
+> easier, there'll never be any file conflicts when the mojor of any of
+> them changes.
+
+IMO we should have an exception so that libraries like these that are
+related to and required by a single program/package that are not
+expected (i.e. there are no header files) to be used by others, should
+be packaged in the main package itself.
+
+I.e. I'd put all of those in amarok package itself, if there is zero
+advantage from splitting them.
+
+> P.S. I am not a packaging expert.
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005724.html b/zarb-ml/mageia-dev/2011-June/005724.html new file mode 100644 index 000000000..75ef5807e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005724.html @@ -0,0 +1,224 @@ + + + + [Mageia-dev] Mageia 2 - Improving educational programs + + + + + + + + + +

[Mageia-dev] Mageia 2 - Improving educational programs

+ mammig_linux mammig_linux + mammig.linux at gmail.com +
+ Wed Jun 15 19:10:14 CEST 2011 +

+
+ +
Hello
+
+I can begin the list of the edubuntu packages and check those who
+already are in Megeia ( with the project name/url/type/packager when
+it's possible ).
+When the wiki page will be open, we will only have to paste it.
+
+see you
+mammig
+
+
+2011/6/15 Angelo Naselli <anaselli at linux.it>:
+> mercoledì 15 giugno 2011 alle 17:43, mammig_linux mammig_linux ha scritto:
+>> Hello,
+> Hello and welcome!
+>
+>> I'm very interresting by this project.
+>> Currently i'm a member of the french i18n team ( transator ) and i
+>> never make those strange things you call "package".
+>> ( but maybe i can learn how to do it )
+>> I will be happy to help you ( if i can )
+> As said via irc, we can start collecting the most educational project
+> links, maybe starting to add what are into edubuntu and that
+> are not in mageia already.
+> It could be easier for me -and for other packagers who partecipate-
+> to start packaging things, instead of looking for them and working on them after :)
+>
+> We could start a wiki page in which adding missing packages for instance.
+> Something like
+> project name - project url - type  - packager
+>
+> Edu Type could help to get a kind of group info, i mean how they could be
+> grouped in.
+>
+> I'd like to start with international projects, those that have localizations
+> and can be used by almost all. Local project should be added by users that can
+> maintain them and can *understand* them ;)
+>
+> WDYT?
+>
+> Cheeers,
+>        Angelo
+>
+>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005725.html b/zarb-ml/mageia-dev/2011-June/005725.html new file mode 100644 index 000000000..33f6d24ca --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005725.html @@ -0,0 +1,190 @@ + + + + [Mageia-dev] Mageia 2 - Improving educational programs + + + + + + + + + +

[Mageia-dev] Mageia 2 - Improving educational programs

+ Angelo Naselli + anaselli at linux.it +
+ Wed Jun 15 19:13:53 CEST 2011 +

+
+ +
mercoledì 15 giugno 2011 alle 19:10, mammig_linux mammig_linux ha scritto:
+> packager
+Well packager should mean who of us take care about :)
+-------------- 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/20110615/62630732/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005726.html b/zarb-ml/mageia-dev/2011-June/005726.html new file mode 100644 index 000000000..aba981c22 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005726.html @@ -0,0 +1,195 @@ + + + + [Mageia-dev] Mageia 2 - Improving educational programs + + + + + + + + + +

[Mageia-dev] Mageia 2 - Improving educational programs

+ Dexter Morgan + dmorganec at gmail.com +
+ Wed Jun 15 20:27:52 CEST 2011 +

+
+ +
On Wed, Jun 15, 2011 at 7:10 PM, mammig_linux mammig_linux
+<mammig.linux at gmail.com> wrote:
+> Hello
+>
+> I can begin the list of the edubuntu packages and check those who
+> already are in Megeia ( with the project name/url/type/packager when
+> it's possible ).
+> When the wiki page will be open, we will only have to paste it.
+>
+> see you
+> mammig
+
+This is really a good idea for a start.
+
+i would say : go for it :)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005727.html b/zarb-ml/mageia-dev/2011-June/005727.html new file mode 100644 index 000000000..d33f87c60 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005727.html @@ -0,0 +1,186 @@ + + + + [Mageia-dev] Mageia 2 - Improving educational programs + + + + + + + + + +

[Mageia-dev] Mageia 2 - Improving educational programs

+ José Jorge + jjorge at free.fr +
+ Wed Jun 15 20:42:39 CEST 2011 +

+
+ +
Le mercredi 15 juin 2011 20:27:52, Dexter Morgan a écrit :
+> > I can begin the list of the edubuntu packages and check those who
+> > already are in Megeia ( with the project name/url/type/packager when
+> > it's possible ).
+
+A task-education rpm would be simple to use.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005728.html b/zarb-ml/mageia-dev/2011-June/005728.html new file mode 100644 index 000000000..63fe6ceff --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005728.html @@ -0,0 +1,186 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Wed Jun 15 22:18:00 CEST 2011 +

+
+ +
On 14 June 2011 17:54, Antoine Pitrou <solipsis at pitrou.net> wrote:
+>> > do we wait firefox 5 rc or we can start to update to firefox 5 soon ?
+>>
+>> Mandriva now has several packages for firefox (like for chromium), following
+>> the upstream channels, maybe we could envision doing it too ?
+>
+> As a user, I will download the mozilla.org binaries if I want to
+> try/test a non-stable release. Not sure there's any point for Mageia in
+> packaging beta versions (except to get feedback for distro-specific
+> patches).
+
+Well, a mdv package would integrate nicely with gnome & kde, aka
+it would run oowriter to open a document instead of asking you
+to choose an app...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005729.html b/zarb-ml/mageia-dev/2011-June/005729.html new file mode 100644 index 000000000..1dc2d9b3c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005729.html @@ -0,0 +1,209 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Wed Jun 15 22:32:21 CEST 2011 +

+
+ +
On 14 June 2011 17:54, Antoine Pitrou <solipsis at pitrou.net> wrote:
+> On Tue, 14 Jun 2011 14:14:02 +0200
+> Samuel Verschelde <stormi at laposte.net>
+> wrote:
+>>
+>> Le mardi 14 juin 2011 13:56:29, Dexter Morgan a écrit :
+>> > Hello,
+>> >
+>> > do we wait firefox 5 rc or we can start to update to firefox 5 soon ?
+>>
+>> Mandriva now has several packages for firefox (like for chromium), following
+>> the upstream channels, maybe we could envision doing it too ?
+>
+> As a user, I will download the mozilla.org binaries if I want to
+> try/test a non-stable release. Not sure there's any point for Mageia in
+> packaging beta versions (except to get feedback for distro-specific
+> patches).
+>
+> Just my 2 cents.
+>
+> Regards
+>
+> Antoine.
+>
+>
+>
+
+The whole alpha/beta/rc concept has changed a lot in Firefox upstream:
+https://developer.mozilla.org/devnews/index.php/2011/04/07/new-development-channels-and-repositories-for-rapid-releases/
+
+So, we have to have the Beta versions, so as to work out the niggles
+to be ready to push the stable version to stable releases (Mageia 1).
+
+As for Aurora... I don't know I think Beta should be enough, for the
+brave souls they can use the upstream binary tarballs, I think
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005730.html b/zarb-ml/mageia-dev/2011-June/005730.html new file mode 100644 index 000000000..71860e39f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005730.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Stew Benedict + stewbintn at gmail.com +
+ Wed Jun 15 22:32:35 CEST 2011 +

+
+ +
On 06/15/2011 09:22 AM, Stew Benedict wrote:
+> On 06/15/2011 08:50 AM, Dexter Morgan wrote:
+>> On Wed, Jun 15, 2011 at 2:20 PM, Thomas Backlund<tmb at mageia.org>  wrote:
+>>> BTW, should we have a read-only security/update-announce ml that 
+>>> where we
+>>> mail about all updates ?
+>>>
+>> yes seems a must have to push updates descriptions , distributions 
+>> affected, ...
+>>
+> That is accounted for in the policy document (last line)
+>
+Due to the unbridled enthusiasm for getting started on updates, we now 
+have 4 trial packages :)
+
+vde2, mysql, curl, subversion
+
+Bugs:
+
+https://bugs.mageia.org/show_bug.cgi?id=1678 (vde2)
+https://bugs.mageia.org/show_bug.cgi?id=1554 (mysql)
+https://bugs.mageia.org/show_bug.cgi?id=1813 (curl)
+https://bugs.mageia.org/show_bug.cgi?id=1521 (subversion)
+
+Packages need fixes applied, built for mga1 (I believe mysql is already 
+in updates_testing), packager should do some initial testing then 
+re-assign the bug to QA
+
+QA process for updates:
+
+http://mageia.org/wiki/doku.php?id=qa_updates
+
+
+
+-- 
+Stew Benedict
+
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005731.html b/zarb-ml/mageia-dev/2011-June/005731.html new file mode 100644 index 000000000..608fc36f2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005731.html @@ -0,0 +1,180 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Wed Jun 15 22:35:38 CEST 2011 +

+
+ +
On 14 June 2011 14:32, Frank Griffin <ftg at roadrunner.com> wrote:
+> On 06/14/2011 08:22 AM, Thierry Vignaud wrote:
+>>
+>> Upgrading stable firefox to firefox5rc and importing firefox-{beta,aurora}
+>> are two distinct orthogonal things IMHO.
+>>
+>> since firefox5 is near being released, I think we should update
+>> main xulrunner+firefox to 5 anyway
+>>
+> Whatever we do, please don't put it in Core to replace FF4 until the add-ons
+> have been updated.  It was really annoying to lose the Tor add-on for months
+> because the beta FF4 just showed up and replaced FF3, and the Tor add-on
+> wasn't updated until the release or just before.
+>
+
+As I said, we have to have the Beta versions, so as to work out the
+niggles to be ready to push the stable version to stable releases
+(Mageia 1).
+
+You can always workaround the compatibility, either:
+- Adding it manually http://kb.mozillazine.org/Extensions.checkCompatibility OR
+- Using this extension
+https://addons.mozilla.org/en-US/firefox/addon/add-on-compatibility-reporter/
+
+in my experience, 90% of the time the addon will work with a new
+version of FF (but then again I use a limited number of addons).
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005732.html b/zarb-ml/mageia-dev/2011-June/005732.html new file mode 100644 index 000000000..50d382a77 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005732.html @@ -0,0 +1,186 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Donald Stewart + watersnowrock at gmail.com +
+ Wed Jun 15 22:38:44 CEST 2011 +

+
+ +
On 15 June 2011 13:35, Ahmad Samir <ahmadsamir3891 at gmail.com> wrote:
+> On 14 June 2011 14:32, Frank Griffin <ftg at roadrunner.com> wrote:
+>> On 06/14/2011 08:22 AM, Thierry Vignaud wrote:
+>>>
+>>> Upgrading stable firefox to firefox5rc and importing firefox-{beta,aurora}
+>>> are two distinct orthogonal things IMHO.
+>>>
+>>> since firefox5 is near being released, I think we should update
+>>> main xulrunner+firefox to 5 anyway
+>>>
+>> Whatever we do, please don't put it in Core to replace FF4 until the add-ons
+>> have been updated.  It was really annoying to lose the Tor add-on for months
+>> because the beta FF4 just showed up and replaced FF3, and the Tor add-on
+>> wasn't updated until the release or just before.
+>>
+>
+> As I said, we have to have the Beta versions, so as to work out the
+> niggles to be ready to push the stable version to stable releases
+> (Mageia 1).
+>
+> You can always workaround the compatibility, either:
+> - Adding it manually http://kb.mozillazine.org/Extensions.checkCompatibility OR
+> - Using this extension
+> https://addons.mozilla.org/en-US/firefox/addon/add-on-compatibility-reporter/
+>
+> in my experience, 90% of the time the addon will work with a new
+> version of FF (but then again I use a limited number of addons).
+>
+> --
+> Ahmad Samir
+>
+
+I'm with Ahmad, going for beta for testing seems right. The beta
+release stage should be long enough for issues to be sorted so aurora
+isn't needed.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005733.html b/zarb-ml/mageia-dev/2011-June/005733.html new file mode 100644 index 000000000..3181de52a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005733.html @@ -0,0 +1,219 @@ + + + + [Mageia-dev] Lib policy change needed ? + + + + + + + + + +

[Mageia-dev] Lib policy change needed ?

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Jun 16 00:28:37 CEST 2011 +

+
+ +
'Twas brillig, and Anssi Hannula at 15/06/11 18:06 did gyre and gimble:
+> On 15.06.2011 19:15, Ahmad Samir wrote:
+>> For example look at Amarok:
+>> $ urpmf --sourcerpm :amarok | sort | grep lib
+>> lib64amarokcore1:amarok-2.4.1-0.mga1.src.rpm
+>> lib64amaroklib1:amarok-2.4.1-0.mga1.src.rpm
+>> lib64amarokocsclient4:amarok-2.4.1-0.mga1.src.rpm
+>> lib64amarokpud1:amarok-2.4.1-0.mga1.src.rpm
+>> lib64amarok-sqlcollection1:amarok-2.4.1-0.mga1.src.rpm
+>> lib64amarok-transcoding1:amarok-2.4.1-0.mga1.src.rpm
+>>
+>> every lib is in a separate package, even though:
+>> - Nothing else uses any of those libs other than Amarok
+>> - Amarok is linked against all of those libs and it wouldn't work if
+>> you uninstall any of them
+>>
+>> In such a case grouping all of them in one lib*amarok package would be
+>> easier, there'll never be any file conflicts when the mojor of any of
+>> them changes.
+> 
+> IMO we should have an exception so that libraries like these that are
+> related to and required by a single program/package that are not
+> expected (i.e. there are no header files) to be used by others, should
+> be packaged in the main package itself.
+> 
+> I.e. I'd put all of those in amarok package itself, if there is zero
+> advantage from splitting them.
+
+Yeah, on reflection, I think this makes sense. IMO the lib policy is
+generally very good and useful, particularly on 64 vs 32 bit systems,
+but I cannot install both amarok in 32 and 64 bit flavours anyway, so
+there is no advantage in this regard to splitting it's libs.
+
+That said, it makes the lib policy that bit vaguer and harder to
+understand... but it does also help keep orphaned files down.
+
+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-June/005734.html b/zarb-ml/mageia-dev/2011-June/005734.html new file mode 100644 index 000000000..ff4129d5b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005734.html @@ -0,0 +1,236 @@ + + + + [Mageia-dev] Question about backports: calibre (bug 1659) + + + + + + + + + +

[Mageia-dev] Question about backports: calibre (bug 1659)

+ andre999 + andr55 at laposte.net +
+ Thu Jun 16 00:29:12 CEST 2011 +

+
+ +
Radu-Cristian FOTESCU a écrit :
+>
+>> Release frequency never was a criteria for differentiating between
+>> pushing something to updates and something to backports.
+>
+> It should be. Otherwise, we should all be using OpenOffice.org 1.0.1. --
+> security issues set aside.
+>
+>> And I see no reason why it would be in favor of doing a bug fix update
+>> rather than a backport, especially if we ask to do a more stringent QA
+>> checking on updates, as it would put too much work on the team.
+>
+> Because Mageia (and Mandriva)'s vision of the concept of "backports" is not
+> compatible with my common-sense.
+>
+> I have not used Mandriva very much in the past, because I hate the concept of
+> "backports" -- yes, Ubuntu does them too, but Ubuntu backports are totally
+> unsupported, so you can imagine their "quality"...
+>
+> I'd rather stick to "updates" -- this is also the reason I stopped using
+> Debian, because the morons (yes, morons) were only pushing tzdata updates
+> in "volatile", not in "updates", whereas ALL the other distro weres pushing
+> tzdata updates in "updates".
+>
+> If Mageia considers that a 6-7 months old package (for an application that
+> released 32 times in the meantime) only deserves updates in "backports",
+> then I will probably stop reporting any possible bugs with this distro
+> -- as a protest.
+>
+> It is indeed a matter of principle. I am personally using the latest
+> calibre installed in /opt, not the official one, but again, it's a
+> matter of principle.
+>
+>
+> Whatever is important and comes from upstream  should go into updates IMHO.
+> Backports, in my view, only make sense if they're  coming from Release N+1
+> *and* if they represent a major version bump -- such as FF4 over FF3.6, etc.
+>
+>
+> WRT calibre, Fedora has a simple way: it keeps a newer calibre packages in
+> updates/testing for 1 week, and if no user complains about regressions, it
+> goes into updates. This is because calibre is a "leaf" package -- no other
+> package depends on it, so it only impacts those who are using it.
+>
+>> Again, that's not a criteria. Every software is important to at least
+>> one person, and that would mean we should update everything if we start
+>> to update everything important to one group of users.
+>
+> I can see how important is calibre to Mageia users. Nobody noticed or cared
+> that it is an antiquated version. They could have as well used notepad.exe
+> from Win95.
+>
+>
+>> And for what it is worth, Fedora is discussing having separate update
+>> and backport ( https://fedorahosted.org/fesco/ticket/515 ), even if the
+>> discussion seems to be going nowhere at the moment
+>
+> BS. I hope Fedora *never* uses backports!
+>
+> Their update policy is very clear *and* flexible:
+> http://fedoraproject.org/wiki/Updates_Policy
+>
+> Please note these:
+>
+> "Exceptions: Some classes of software will not fit in these guidelines.
+> If your package does not fit in one of the classes below, but you think
+> it should be allowed to update more rapidly . . .
+>
+>
+> Things that would make it more likely to grant a request:
+> --  The package is a "leaf" node. Nothing depends on it or requires it."
+>
+> Calibre is a "leaf" package.
+>
+> If not, in the same document:
+>
+> "All other updates must either:
+> -- reach the criteria laid out in the previous section OR
+> -- reach the positive Bodhi karma threshold specified by the updates submitter OR
+> -- spend some minimum amount of time in updates-testing, currently one week."
+>
+> I am not sure why F15 stopped updating calibre to 0.8.0 in updates (Rawhide went
+> up to 0.8.4, maybe 0.8.5 now), but for the versions up to and including 0.8.0,
+> here's the dynamics of the updates:
+>
+...
+> Indeed, Mageia does not have the number of packagers that Fedora has.
+> However, if Mageia's _policy_ is to rather have 6-7 months old versions in
+> updates, I should probably realize that Mageia is not for me.
+>
+> No, I have not, and never will use any repository called "backports". When a
+> newer stable  release of a distro is available, I should update to it if
+> updates I need are not pushed into Release N-1 "updates" (even if that release
+> is officially still supported with security patches), but again, "backports"
+> as Mandriva and Mageia are seeing them -- i.e. backporting
+> from  Cooker/Cauldron, not from "updates/testing" nor from "Release N+1"
+> -- does not fit my Zen.
+>
+> R-C
+
+In my mind you make an excellent case for upgrading this application from upstream, and installing 
+under /opt, as you say you do already.
+Which I do for Mozilla Seamonkey, for example, because of relatively frequent updates.  (In that 
+case I also apply some personal patches, but that is another question.)
+It is appropriate to report bugs for the application upstream.  The fixes will trickle down to Mageia.
+Just because you use Mageia (or any other distro) doesn't mean you can't install 3rd party 
+applications.  Although certainly it is preferable that most are packaged in Mageia.
+
+Which brings up another point.  Considering your concern for the application, maybe you would like 
+to package it for Mageia.  You could ensure that it is always up to date, and that it works 
+properly, and is properly supported.  (The packager is a key player in support.)
+Just because it is called a backport doesn't mean that it won't work.
+The packager mentoring program will help you get started :)
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005735.html b/zarb-ml/mageia-dev/2011-June/005735.html new file mode 100644 index 000000000..e88f4101a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005735.html @@ -0,0 +1,144 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ andre999 + andr55 at laposte.net +
+ Thu Jun 16 00:30:08 CEST 2011 +

+
+ +
Samuel Verschelde a écrit :
+>
+> Le mardi 14 juin 2011 20:00:39, Anne nicolas a écrit :
+>> 2011/6/14 Wolfgang Bornath<molch.b at googlemail.com>
+>>
+>>> 2011/6/14 Anne nicolas<ennael at mageia.org>:
+>>>> I guess because of Mandriva policy. We did provide backports but it was
+>>>> explicitely said to be unsupported. "Use it at your own risks"
+>>>> We may have to rewrite  this and make things clear
+
+Right.  Define a (somewhat lower) level of support -- but enough to assure most users that 
+backports can be reliable.
+Mandriva was defining _corporate_ support, which doesn't apply in a community volonteer-based distro.
+
+>>> Do you mean, just telling people that it is no risk or do you mean a
+>>> change which lessens the risk?
+>>
+>> not at all
+>>
+>>> As Michael wrote earlier in this thread, if there was the risk to
+>>> break the system by low quality of backports then the quality has to
+>>> be improved (not his own words but that's how I understood it).
+>>>
+>> exactly what I had in mind. Having backports can allow choice between
+>> "the last version of" and "the stable version with which I'm happy
+>>   with". But indeed we need more quality in backport rpms that is policy and
+>> tests.
+>
+> Few words could make me more happy about the potential future status of our
+> backports. And if backports have a bad reputation among our users, maybe we
+> should rename updates to "maintenance updates" and backports to "feature
+> updates" ?
+>
+> Samuel
+
+Not a bad idea -- even if only as a subtitle :)
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005736.html b/zarb-ml/mageia-dev/2011-June/005736.html new file mode 100644 index 000000000..ca5e9ed2d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005736.html @@ -0,0 +1,73 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Balcaen John + mikala at mageia.org +
+ Thu Jun 16 00:56:25 CEST 2011 +

+
+ +
Le mercredi 15 juin 2011 17:32:35, Stew Benedict a écrit :
+[...]
+> 
+> Bugs:
+> 
+> https://bugs.mageia.org/show_bug.cgi?id=1678 (vde2)
+> https://bugs.mageia.org/show_bug.cgi?id=1554 (mysql)
+> https://bugs.mageia.org/show_bug.cgi?id=1813 (curl)
+> https://bugs.mageia.org/show_bug.cgi?id=1521 (subversion)
+> 
+i've added a new one for gtkglext https://bugs.mageia.org/show_bug.cgi?id=1195 
+(i'm also installing 2 mageia for both arch in vm to help test them)
+
+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-June/005737.html b/zarb-ml/mageia-dev/2011-June/005737.html new file mode 100644 index 000000000..b7070d8cd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005737.html @@ -0,0 +1,153 @@ + + + + [Mageia-dev] Question about backports: calibre (bug 1659) + + + + + + + + + +

[Mageia-dev] Question about backports: calibre (bug 1659)

+ Radu-Cristian FOTESCU + beranger5ca at yahoo.ca +
+ Thu Jun 16 00:57:45 CEST 2011 +

+
+ +
>From: andre999 <andr55 at laposte.net>
+>
+[...]
+>
+>In my mind you make an excellent case for upgrading this application from upstream, and installing 
+>under /opt, as you say you do already.
+>Which I do for Mozilla Seamonkey, for example, because of relatively frequent updates.  (In that 
+>case I also apply some personal patches, but that is another question.)
+>It is appropriate to report bugs for the application upstream.  The fixes will trickle down to Mageia.
+>Just because you use Mageia (or any other distro) doesn't mean you can't install 3rd party 
+>applications.  Although certainly it is preferable that most are packaged in Mageia.
+>
+>Which brings up another point.  Considering your concern for the application, maybe you would like 
+>to package it for Mageia.  You could ensure that it is always up to date, and that it works 
+>properly, and is properly supported.  (The packager is a key player in support.)
+>Just because it is called a backport doesn't mean that it won't work.
+>The packager mentoring program will help you get started :)
+>
+>-- 
+>André
+
+
+Well, first of all, I never liked the _concept_ of backports. Too many repositories, too complex tree already. One of the reasons I wasn't very fond of Mandriva (the other reason being the IaOra theme(s).)
+
+From the NON-rolling distros, Fedora is arguably the only one who tries to bring newer versions of a number of applications throughout its 12+1 months lifecycle. w/o using backports. My opinion is that, as long as system libraries are _not_ upgraded, many other packages (applications!) should be updated as appropriate. Otherwise, the result would be that Windows users would have more freedom and ease in decided what version of the [multi-platform open-source] applications to use than Linux users! (Except, of course, the users of rolling-release distros, and except for users of unstable/rawhide/cooker/cauldron...)
+
+I know, I should probably be using Fedora as long as _some_ of their principles suit my views much more than Mageia does or than Mandriva did. However, Fedora lacks something like Mandriva Control Center, and yum is millions of times slower than urpmi, therefore...
+
+Not to mention that most of the best people Mandriva had are now with Mageia, which makes this distro hard to ignore... (Je crois qu'on appelle cela zugzwang...)
+
+R-C
+
+
+R-C
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005738.html b/zarb-ml/mageia-dev/2011-June/005738.html new file mode 100644 index 000000000..9ba8c8d68 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005738.html @@ -0,0 +1,223 @@ + + + + [Mageia-dev] [RPM] cauldron core/release gthumb-2.12.3-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release gthumb-2.12.3-1.mga2

+ JA Magallón + jamagallon at ono.com +
+ Thu Jun 16 01:06:02 CEST 2011 +

+
+ +
On Thu, 16 Jun 2011 00:22:18 +0200 (CEST), Mageia Team <buildsystem-daemon at mageia.org> wrote:
+
+> Name        : gthumb                       Relocations: (not relocatable)
+> Version     : 2.12.3                            Vendor: Mageia.Org
+> Release     : 1.mga2                        Build Date: Thu Jun 16 00:17:17 2011
+> Install Date: (not installed)               Build Host: ecosse
+> Group       : Graphics                      Source RPM: (none)
+> Size        : 5208589                          License: GPLv2+
+> Signature   : (none)
+> Packager    : Mageia Team <http://www.mageia.org>
+> URL         : http://gthumb.sourceforge.net/
+> Summary     : An image viewer and browser for GNOME
+> Description :
+> gThumb lets you browse your hard disk, showing you thumbnails of image files.
+> It also lets you view single files (including GIF animations), add comments to
+> images, organize images in catalogs, print images, view slideshows, set your
+> desktop background, and more.
+> 
+> dmorgan <dmorgan> 2.12.3-1.mga2:
+> + Revision: 107996
+> - Fix build
+
+one:~# urpmi gthumb
+A requested package cannot be installed:
+gthumb-2.12.3-1.mga1.x86_64 (due to unsatisfied libbrasero-burn.so.1()(64bit))
+Continue installation anyway? (Y/n)
+
+one:~# rpm -ql lib64brasero1
+/usr/lib64/girepository-1.0/BraseroBurn-3.0.0.typelib
+/usr/lib64/girepository-1.0/BraseroMedia-3.0.0.typelib
+/usr/lib64/libbrasero-burn3.so.1
+/usr/lib64/libbrasero-burn3.so.1.2.0
+/usr/lib64/libbrasero-media3.so.1
+/usr/lib64/libbrasero-media3.so.1.2.0
+/usr/lib64/libbrasero-utils3.so.1
+/usr/lib64/libbrasero-utils3.so.1.2.0
+
+Why the '3' digit in libraries ? We can not have this in parallel with old one...
+
+-- 
+J.A. Magallon <jamagallon()ono!com>     \                 Winter is coming...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005739.html b/zarb-ml/mageia-dev/2011-June/005739.html new file mode 100644 index 000000000..4a01b5a48 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005739.html @@ -0,0 +1,228 @@ + + + + [Mageia-dev] [RPM] cauldron core/release rhythmbox-0.13.3-7.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release rhythmbox-0.13.3-7.mga2

+ JA Magallón + jamagallon at ono.com +
+ Thu Jun 16 01:11:43 CEST 2011 +

+
+ +
On Tue, 14 Jun 2011 18:32:23 +0200 (CEST), Mageia Team <buildsystem-daemon at mageia.org> wrote:
+
+> Name        : rhythmbox                    Relocations: (not relocatable)
+> Version     : 0.13.3                            Vendor: Mageia.Org
+> Release     : 7.mga2                        Build Date: Tue Jun 14 18:24:25 2011
+> Install Date: (not installed)               Build Host: ecosse
+> Group       : Sound                         Source RPM: (none)
+> Size        : 10009472                         License: GPLv2+ with exception
+> Signature   : (none)
+> Packager    : Mageia Team <http://www.mageia.org>
+> URL         : http://www.gnome.org/projects/rhythmbox/
+> Summary     : Music Management Application
+> Description :
+> Music Management application with support for ripping audio-cd's,
+> playback of Ogg Vorbis and Mp3 and burning of CD-Rs.
+> 
+> dmorgan <dmorgan> 0.13.3-7.mga2:
+> + Revision: 106171
+> - Fix file list
+> - Add libproxy-devel as buildRequire
+> - Rebuild against new brasero
+> 
+
+Needs another rebuild for new gnome-media:
+
+ne:~# rpm -qa *gnome-media*
+lib64gnome-media0-2.32.0-3.mga1
+gnome-media-2.91.2-1.mga2
+libgnome-media-profiles-3.0.0-6.mga2
+lib64gnome-media-profiles0-3.0.0-6.mga2
+one:~# urpme lib64gnome-media0
+To satisfy dependencies, the following 3 packages will be removed (15MB):
+  lib64gnome-media0-2.32.0-3.mga1.x86_64
+  lib64rhythmbox3-0.13.3-7.mga2.x86_64
+   (due to missing libgnome-media-profiles.so.0()(64bit))
+  rhythmbox-0.13.3-7.mga2.x86_64
+   (due to missing librhythmbox-core.so.3()(64bit),
+    due to unsatisfied lib64rhythmbox3 >= 0.13.3-7.mga2)
+Remove 3 packages? (y/N)
+
+
+-- 
+J.A. Magallon <jamagallon()ono!com>     \                 Winter is coming...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005740.html b/zarb-ml/mageia-dev/2011-June/005740.html new file mode 100644 index 000000000..ac5b6ea63 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005740.html @@ -0,0 +1,79 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Thu Jun 16 02:47:16 CEST 2011 +

+
+ +
2011/6/15 Thorsten van Lil <tvl83 at gmx.de>:
+> Am Donnerstag, 9. Juni 2011, 10:44:23 schrieb JA Magallón:
+>> if I select "System settings" o launch firefox, immediately I get a
+>> fullscreen error about "something went wrong, plz logout and in again"
+>
+> Same for me two days back. Since yesterday it works relatively well. I get the
+> mentioned error right after login, but: If you just press Alt+F4 the error
+> message vanish and you can start working us usual.
+
+Wow! If I had known that you could get rid of error messages that easy
+I would have used Alt+F4 many years ago in my Windows systems!
+A nice lesson that you should not always do what a message box t4ells you to do!
+
+Ok, seems to work, so all my testing this afternoon was void :(
+
+Btw: after latest updates I don't have the nice blue background in
+Gnome, it is somehow distorted (blue but with lighter blue stripes,
+artefacts?). When I switch to KDE I have normal background, when
+switching back to Gnome I have those stripes again (Nvidia proprietary
+driver installed).
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005741.html b/zarb-ml/mageia-dev/2011-June/005741.html new file mode 100644 index 000000000..ad308ba3c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005741.html @@ -0,0 +1,231 @@ + + + + [Mageia-dev] [RPM] cauldron core/release gthumb-2.12.3-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release gthumb-2.12.3-1.mga2

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Thu Jun 16 04:31:44 CEST 2011 +

+
+ +
2011/6/16 JA Magallón <jamagallon at ono.com>:
+> On Thu, 16 Jun 2011 00:22:18 +0200 (CEST), Mageia Team <buildsystem-daemon at mageia.org> wrote:
+>
+>> Name        : gthumb                       Relocations: (not relocatable)
+>> Version     : 2.12.3                            Vendor: Mageia.Org
+>> Release     : 1.mga2                        Build Date: Thu Jun 16 00:17:17 2011
+>> Install Date: (not installed)               Build Host: ecosse
+>> Group       : Graphics                      Source RPM: (none)
+>> Size        : 5208589                          License: GPLv2+
+>> Signature   : (none)
+>> Packager    : Mageia Team <http://www.mageia.org>
+>> URL         : http://gthumb.sourceforge.net/
+>> Summary     : An image viewer and browser for GNOME
+>> Description :
+>> gThumb lets you browse your hard disk, showing you thumbnails of image files.
+>> It also lets you view single files (including GIF animations), add comments to
+>> images, organize images in catalogs, print images, view slideshows, set your
+>> desktop background, and more.
+>>
+>> dmorgan <dmorgan> 2.12.3-1.mga2:
+>> + Revision: 107996
+>> - Fix build
+>
+> one:~# urpmi gthumb
+> A requested package cannot be installed:
+> gthumb-2.12.3-1.mga1.x86_64 (due to unsatisfied libbrasero-burn.so.1()(64bit))
+> Continue installation anyway? (Y/n)
+>
+> one:~# rpm -ql lib64brasero1
+> /usr/lib64/girepository-1.0/BraseroBurn-3.0.0.typelib
+> /usr/lib64/girepository-1.0/BraseroMedia-3.0.0.typelib
+> /usr/lib64/libbrasero-burn3.so.1
+> /usr/lib64/libbrasero-burn3.so.1.2.0
+> /usr/lib64/libbrasero-media3.so.1
+> /usr/lib64/libbrasero-media3.so.1.2.0
+> /usr/lib64/libbrasero-utils3.so.1
+> /usr/lib64/libbrasero-utils3.so.1.2.0
+>
+> Why the '3' digit in libraries ? We can not have this in parallel with old one...
+>
+
+Ask upstream, we don't add suffix libs with '3' manually, IINM.
+
+> --
+> J.A. Magallon <jamagallon()ono!com>     \                 Winter is coming...
+>
+
+
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005742.html b/zarb-ml/mageia-dev/2011-June/005742.html new file mode 100644 index 000000000..5bd812e6e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005742.html @@ -0,0 +1,211 @@ + + + + [Mageia-dev] [RPM] cauldron core/release gthumb-2.12.3-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release gthumb-2.12.3-1.mga2

+ Charles A Edwards + CAE at eslrahc.com +
+ Thu Jun 16 05:27:35 CEST 2011 +

+
+ +
On Thu, 16 Jun 2011 05:31:44 +0300
+Ahmad Samir <ahmadsamir3891 at gmail.com> wrote:
+
+> > Why the '3' digit in libraries ? We can not have this in parallel
+> > with old one... 
+> 
+> Ask upstream, we don't add suffix libs with '3' manually, IINM.
+
+
+Probably because is for/requires gtk+3 and latest stable brasero-2.32.1
+is for gtk+2
+
+
+
+    Charles
+
+-- 
+You will wish you hadn't.
+----------------------
+Mandriva Linux release 2011.0 (Cooker) for x86_64$
+On SuperSize....http://www.eslrahc.com
+Registered Linux user #182463
+2.6.38.7-tmb-server-1mdv x86_64
+----------------------
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: signature.asc
+Type: application/pgp-signature
+Size: 198 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20110615/cbd05831/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005743.html b/zarb-ml/mageia-dev/2011-June/005743.html new file mode 100644 index 000000000..17f889fb3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005743.html @@ -0,0 +1,68 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Thorsten van Lil + tvl83 at gmx.de +
+ Thu Jun 16 07:55:08 CEST 2011 +

+
+ +
Am Donnerstag, 16. Juni 2011, 02:47:16 schrieb Wolfgang Bornath:
+> Btw: after latest updates I don't have the nice blue background in
+> Gnome, it is somehow distorted (blue but with lighter blue stripes,
+
+You mean like this?
+http://galleries.stefan-horning.de/d/7704-2/GNOME3-Info-o.png
+
+Greetings,
+Thorsten
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005744.html b/zarb-ml/mageia-dev/2011-June/005744.html new file mode 100644 index 000000000..649b692d2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005744.html @@ -0,0 +1,71 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Thu Jun 16 08:46:50 CEST 2011 +

+
+ +
2011/6/16 Thorsten van Lil <tvl83 at gmx.de>:
+> Am Donnerstag, 16. Juni 2011, 02:47:16 schrieb Wolfgang Bornath:
+>> Btw: after latest updates I don't have the nice blue background in
+>> Gnome, it is somehow distorted (blue but with lighter blue stripes,
+>
+> You mean like this?
+> http://galleries.stefan-horning.de/d/7704-2/GNOME3-Info-o.png
+
+Yes, exactly!
+
+-- 
+wobo
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005745.html b/zarb-ml/mageia-dev/2011-June/005745.html new file mode 100644 index 000000000..76a41983d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005745.html @@ -0,0 +1,204 @@ + + + + [Mageia-dev] [RPM] cauldron core/release gthumb-2.12.3-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release gthumb-2.12.3-1.mga2

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Thu Jun 16 09:06:27 CEST 2011 +

+
+ +
On Thu, 16 Jun 2011, Ahmad Samir wrote:
+
+> 2011/6/16 JA Magallón <jamagallon at ono.com>:
+>> one:~# urpmi gthumb
+>> A requested package cannot be installed:
+>> gthumb-2.12.3-1.mga1.x86_64 (due to unsatisfied libbrasero-burn.so.1()(64bit))
+>> Continue installation anyway? (Y/n)
+>>
+>> one:~# rpm -ql lib64brasero1
+>> /usr/lib64/girepository-1.0/BraseroBurn-3.0.0.typelib
+>> /usr/lib64/girepository-1.0/BraseroMedia-3.0.0.typelib
+>> /usr/lib64/libbrasero-burn3.so.1
+>> /usr/lib64/libbrasero-burn3.so.1.2.0
+>> /usr/lib64/libbrasero-media3.so.1
+>> /usr/lib64/libbrasero-media3.so.1.2.0
+>> /usr/lib64/libbrasero-utils3.so.1
+>> /usr/lib64/libbrasero-utils3.so.1.2.0
+>>
+>> Why the '3' digit in libraries ? We can not have this in parallel with old one...
+>>
+>
+> Ask upstream, we don't add suffix libs with '3' manually, IINM.
+
+So the package name is wrong and should be e.g. libbrasero3_1.
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005746.html b/zarb-ml/mageia-dev/2011-June/005746.html new file mode 100644 index 000000000..bd8da7862 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005746.html @@ -0,0 +1,72 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Thorsten van Lil + tvl83 at gmx.de +
+ Thu Jun 16 09:11:17 CEST 2011 +

+
+ +
Am 16.06.2011 08:46, schrieb Wolfgang Bornath:
+> 2011/6/16 Thorsten van Lil<tvl83 at gmx.de>:
+>> Am Donnerstag, 16. Juni 2011, 02:47:16 schrieb Wolfgang Bornath:
+>>> Btw: after latest updates I don't have the nice blue background in
+>>> Gnome, it is somehow distorted (blue but with lighter blue stripes,
+>>
+>> You mean like this?
+>> http://galleries.stefan-horning.de/d/7704-2/GNOME3-Info-o.png
+>
+> Yes, exactly!
+>
+
+Yeah, that's one of the default Gnome backgrounds.
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005747.html b/zarb-ml/mageia-dev/2011-June/005747.html new file mode 100644 index 000000000..6a1d38150 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005747.html @@ -0,0 +1,81 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Dexter Morgan + dmorganec at gmail.com +
+ Thu Jun 16 09:13:29 CEST 2011 +

+
+ +
On Thu, Jun 16, 2011 at 9:11 AM, Thorsten van Lil <tvl83 at gmx.de> wrote:
+> Am 16.06.2011 08:46, schrieb Wolfgang Bornath:
+>>
+>> 2011/6/16 Thorsten van Lil<tvl83 at gmx.de>:
+>>>
+>>> Am Donnerstag, 16. Juni 2011, 02:47:16 schrieb Wolfgang Bornath:
+>>>>
+>>>> Btw: after latest updates I don't have the nice blue background in
+>>>> Gnome, it is somehow distorted (blue but with lighter blue stripes,
+>>>
+>>> You mean like this?
+>>> http://galleries.stefan-horning.de/d/7704-2/GNOME3-Info-o.png
+>>
+>> Yes, exactly!
+>>
+>
+> Yeah, that's one of the default Gnome backgrounds.
+>
+
+Yes we lack customizations for mageia.
+This and rediffing some patches will come as soon as gnome3 will be on
+good shape
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005748.html b/zarb-ml/mageia-dev/2011-June/005748.html new file mode 100644 index 000000000..0ed70b298 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005748.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Thu Jun 16 09:27:38 CEST 2011 +

+
+ +
2011/6/16 Thorsten van Lil <tvl83 at gmx.de>:
+> Am 16.06.2011 08:46, schrieb Wolfgang Bornath:
+>>
+>> 2011/6/16 Thorsten van Lil<tvl83 at gmx.de>:
+>>>
+>>> Am Donnerstag, 16. Juni 2011, 02:47:16 schrieb Wolfgang Bornath:
+>>>>
+>>>> Btw: after latest updates I don't have the nice blue background in
+>>>> Gnome, it is somehow distorted (blue but with lighter blue stripes,
+>>>
+>>> You mean like this?
+>>> http://galleries.stefan-horning.de/d/7704-2/GNOME3-Info-o.png
+>>
+>> Yes, exactly!
+>>
+>
+> Yeah, that's one of the default Gnome backgrounds.
+
+Oops!
+I thought it was an error of the video driver! ( /me hides... )
+
+Will have to look up some documentation about Gnome3 - lots of things
+I know from KDE are missing (the handy little icons in systray, a
+switch for virtual desktops, etc.). For a KDE user this is a very
+alien environment.
+
+-- 
+wobo
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005749.html b/zarb-ml/mageia-dev/2011-June/005749.html new file mode 100644 index 000000000..dfa1dedf0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005749.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Thorsten van Lil + tvl83 at gmx.de +
+ Thu Jun 16 09:42:19 CEST 2011 +

+
+ +
Am 16.06.2011 09:27, schrieb Wolfgang Bornath:
+> 2011/6/16 Thorsten van Lil<tvl83 at gmx.de>:
+>> Am 16.06.2011 08:46, schrieb Wolfgang Bornath:
+>>>
+>>> 2011/6/16 Thorsten van Lil<tvl83 at gmx.de>:
+>>>>
+>>>> Am Donnerstag, 16. Juni 2011, 02:47:16 schrieb Wolfgang Bornath:
+>>>>>
+>>>>> Btw: after latest updates I don't have the nice blue background in
+>>>>> Gnome, it is somehow distorted (blue but with lighter blue stripes,
+>>>>
+>>>> You mean like this?
+>>>> http://galleries.stefan-horning.de/d/7704-2/GNOME3-Info-o.png
+>>>
+>>> Yes, exactly!
+>>>
+>>
+>> Yeah, that's one of the default Gnome backgrounds.
+>
+> Oops!
+> I thought it was an error of the video driver! ( /me hides... )
+>
+> Will have to look up some documentation about Gnome3 - lots of things
+> I know from KDE are missing (the handy little icons in systray, a
+> switch for virtual desktops, etc.). For a KDE user this is a very
+> alien environment.
+>
+
+I know what you mean. I feel the very same.
+* You get the a somelike systray, if you move the mouse to the 
+bottom-right corner (at least networkmanager and mgaonline is there).
+* virtual desktops are now known as "Activities". If a window is already 
+open, go to the top-left corner (like when you want to open new apps). 
+There you find on the right an extra panel, which enlarges if you hover 
+the mouse.
+
+Greetings
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005750.html b/zarb-ml/mageia-dev/2011-June/005750.html new file mode 100644 index 000000000..e4ecb7653 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005750.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Thu Jun 16 09:48:38 CEST 2011 +

+
+ +
2011/6/16 Thorsten van Lil <tvl83 at gmx.de>:
+> Am 16.06.2011 09:27, schrieb Wolfgang Bornath:
+>>
+>> 2011/6/16 Thorsten van Lil<tvl83 at gmx.de>:
+>>>
+>>> Am 16.06.2011 08:46, schrieb Wolfgang Bornath:
+>>>>
+>>>> 2011/6/16 Thorsten van Lil<tvl83 at gmx.de>:
+>>>>>
+>>>>> Am Donnerstag, 16. Juni 2011, 02:47:16 schrieb Wolfgang Bornath:
+>>>>>>
+>>>>>> Btw: after latest updates I don't have the nice blue background in
+>>>>>> Gnome, it is somehow distorted (blue but with lighter blue stripes,
+>>>>>
+>>>>> You mean like this?
+>>>>> http://galleries.stefan-horning.de/d/7704-2/GNOME3-Info-o.png
+>>>>
+>>>> Yes, exactly!
+>>>>
+>>>
+>>> Yeah, that's one of the default Gnome backgrounds.
+>>
+>> Oops!
+>> I thought it was an error of the video driver! ( /me hides... )
+>>
+>> Will have to look up some documentation about Gnome3 - lots of things
+>> I know from KDE are missing (the handy little icons in systray, a
+>> switch for virtual desktops, etc.). For a KDE user this is a very
+>> alien environment.
+>>
+>
+> I know what you mean. I feel the very same.
+> * You get the a somelike systray, if you move the mouse to the bottom-right
+> corner (at least networkmanager and mgaonline is there).
+> * virtual desktops are now known as "Activities". If a window is already
+> open, go to the top-left corner (like when you want to open new apps). There
+> you find on the right an extra panel, which enlarges if you hover the mouse.
+
+Thx, I think I will make a list first and then try to find a
+how-to-use-the-gnome-desktop.
+
+-- 
+wobo
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005751.html b/zarb-ml/mageia-dev/2011-June/005751.html new file mode 100644 index 000000000..b2ccbcd1e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005751.html @@ -0,0 +1,76 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Dexter Morgan + dmorganec at gmail.com +
+ Thu Jun 16 09:58:22 CEST 2011 +

+
+ +
On Thu, Jun 16, 2011 at 9:48 AM, Wolfgang Bornath
+<molch.b at googlemail.com> wrote:
+>> I know what you mean. I feel the very same.
+>> * You get the a somelike systray, if you move the mouse to the bottom-right
+>> corner (at least networkmanager and mgaonline is there).
+>> * virtual desktops are now known as "Activities". If a window is already
+>> open, go to the top-left corner (like when you want to open new apps). There
+>> you find on the right an extra panel, which enlarges if you hover the mouse.
+>
+> Thx, I think I will make a list first and then try to find a
+> how-to-use-the-gnome-desktop.
+>
+> --
+> wobo
+>
+
+so for you it doesn't crash anymore ?
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005752.html b/zarb-ml/mageia-dev/2011-June/005752.html new file mode 100644 index 000000000..c37b03380 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005752.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Thu Jun 16 10:08:30 CEST 2011 +

+
+ +
2011/6/16 Dexter Morgan <dmorganec at gmail.com>:
+> On Thu, Jun 16, 2011 at 9:48 AM, Wolfgang Bornath
+> <molch.b at googlemail.com> wrote:
+>>> I know what you mean. I feel the very same.
+>>> * You get the a somelike systray, if you move the mouse to the bottom-right
+>>> corner (at least networkmanager and mgaonline is there).
+>>> * virtual desktops are now known as "Activities". If a window is already
+>>> open, go to the top-left corner (like when you want to open new apps). There
+>>> you find on the right an extra panel, which enlarges if you hover the mouse.
+>>
+>> Thx, I think I will make a list first and then try to find a
+>> how-to-use-the-gnome-desktop.
+>>
+>> --
+>> wobo
+>>
+>
+> so for you it doesn't crash anymore ?
+
+"Any more" is not the correct expression here. I still get the full
+screen error message telling me to logout because of an error (nothing
+changed there), but closing this message with Alt+F4 lets me go on
+without problems - but it could well be that this was possible from
+the start.
+
+Of course, as an Absolute Beginner (credits to D.B.!) with the Gnome
+DE I don't know what else is an error or not (see my taking the
+default background as a graphic card error!)
+
+-- 
+wobo
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005753.html b/zarb-ml/mageia-dev/2011-June/005753.html new file mode 100644 index 000000000..60216902f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005753.html @@ -0,0 +1,130 @@ + + + + [Mageia-dev] Question about backports: calibre (bug 1659) + + + + + + + + + +

[Mageia-dev] Question about backports: calibre (bug 1659)

+ Samuel Verschelde + stormi at laposte.net +
+ Thu Jun 16 10:28:22 CEST 2011 +

+
+ +
+Le jeudi 16 juin 2011 00:57:45, Radu-Cristian FOTESCU a écrit :
+> Well, first of all, I never liked the _concept_ of backports. Too many
+> repositories, too complex tree already. One of the reasons I wasn't very
+> fond of Mandriva (the other reason being the IaOra theme(s).)
+> 
+
+Or, like some of us try to bring for the future, we could make backports easy 
+to use, without the user having to cope with the underlying mirror structure 
+complexity. If for each application that doesn't need big lib changes you had 
+2 available versions, one that doesn't add new features but only fixes, and one 
+that brings the latest upstream version, wouldn't it be good for you AND for 
+those who want stability above all ? (with the ability to have a mixed 
+approach : updates for most packages and backports for some of them).
+
+I agree that currently backports are not easy to use, but we're trying to 
+solve that, without sacrificing stability for those who need it (especially 
+institutions, schools, universities, and all environments with many computers 
+to maintain). 
+
+Samuel
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005754.html b/zarb-ml/mageia-dev/2011-June/005754.html new file mode 100644 index 000000000..bd76e7de5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005754.html @@ -0,0 +1,176 @@ + + + + [Mageia-dev] Mageia 2 - Improving educational programs + + + + + + + + + +

[Mageia-dev] Mageia 2 - Improving educational programs

+ Angelo Naselli + anaselli at linux.it +
+ Thu Jun 16 11:21:30 CEST 2011 +

+
+ +
+> A task-education rpm would be simple to use.
+> 
+At the moment, it's called task-edu but the aim of a wiki page
+is to get info about what is in mageia and what is missed.
+So that missing packages can be added to the meta-package,
+e.g. task-edu, but as said we could/should specialize it adding
+more meta-packages.
+
+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/20110616/693b2856/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005755.html b/zarb-ml/mageia-dev/2011-June/005755.html new file mode 100644 index 000000000..c474029bf --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005755.html @@ -0,0 +1,89 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Dexter Morgan + dmorganec at gmail.com +
+ Thu Jun 16 11:24:07 CEST 2011 +

+
+ +
On Thu, Jun 16, 2011 at 10:08 AM, Wolfgang Bornath
+<molch.b at googlemail.com> wrote:
+> 2011/6/16 Dexter Morgan <dmorganec at gmail.com>:
+>> On Thu, Jun 16, 2011 at 9:48 AM, Wolfgang Bornath
+>> <molch.b at googlemail.com> wrote:
+>>>> I know what you mean. I feel the very same.
+>>>> * You get the a somelike systray, if you move the mouse to the bottom-right
+>>>> corner (at least networkmanager and mgaonline is there).
+>>>> * virtual desktops are now known as "Activities". If a window is already
+>>>> open, go to the top-left corner (like when you want to open new apps). There
+>>>> you find on the right an extra panel, which enlarges if you hover the mouse.
+>>>
+>>> Thx, I think I will make a list first and then try to find a
+>>> how-to-use-the-gnome-desktop.
+>>>
+>>> --
+>>> wobo
+>>>
+>>
+>> so for you it doesn't crash anymore ?
+>
+> "Any more" is not the correct expression here. I still get the full
+> screen error message telling me to logout because of an error (nothing
+> changed there), but closing this message with Alt+F4 lets me go on
+> without problems - but it could well be that this was possible from
+> the start.
+
+ok like me then :)
+
+i am investigating now as i reproduce since this morning on a brand new install
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005756.html b/zarb-ml/mageia-dev/2011-June/005756.html new file mode 100644 index 000000000..b7f2836ca --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005756.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Olav Vitters + olav at vitters.nl +
+ Thu Jun 16 11:56:24 CEST 2011 +

+
+ +
On Thu, Jun 16, 2011 at 11:24:07AM +0200, Dexter Morgan wrote:
+> i am investigating now as i reproduce since this morning on a brand new install
+
+I haven't switched to Mageia yet (difficult as I run cooker), so cannot
+help yet. That said, suggest to also ask in #fedora-desktop or
+#gnome-shell on irc.gnome.org. Pretty sure they will have some debugging
+insights.
+
+Following might also be helpful:
+http://git.gnome.org/browse/gnome-shell/plain/tools/build/gnome-shell-build-setup.sh
+
+It shows you the system dependencies to build gnome-shell for Mandriva.
+
+Then the various modules it builds are in:
+http://git.gnome.org/browse/gnome-shell/plain/tools/build/gnome-shell.modules
+
+Maybe one of them needs rebuilding?
+-- 
+Regards,
+Olav
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005757.html b/zarb-ml/mageia-dev/2011-June/005757.html new file mode 100644 index 000000000..8f65330d4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005757.html @@ -0,0 +1,183 @@ + + + + [Mageia-dev] Mageia 2 - Improving educational programs + + + + + + + + + +

[Mageia-dev] Mageia 2 - Improving educational programs

+ Michael Scherer + misc at zarb.org +
+ Thu Jun 16 12:39:49 CEST 2011 +

+
+ +
Le mercredi 15 juin 2011 à 20:42 +0200, José Jorge a écrit :
+> Le mercredi 15 juin 2011 20:27:52, Dexter Morgan a écrit :
+> > > I can begin the list of the edubuntu packages and check those who
+> > > already are in Megeia ( with the project name/url/type/packager when
+> > > it's possible ).
+> 
+> A task-education rpm would be simple to use.
+
+I beg to differ.
+
+If you already know the software you want, task-education do not help
+you much.
+
+If you do not know, you have to :
+1) find that rpm ( but rpmdrake help you, except this is not translated
+)
+2) test all installed softwares to see which one would fit to what you
+need
+
+So I think we can find a better system for proposing software that
+grouping together in some rpm that pull everything. 
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005758.html b/zarb-ml/mageia-dev/2011-June/005758.html new file mode 100644 index 000000000..f2fdd3eef --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005758.html @@ -0,0 +1,72 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Frank Griffin + ftg at roadrunner.com +
+ Thu Jun 16 12:44:32 CEST 2011 +

+
+ +
On 06/16/2011 03:42 AM, Thorsten van Lil wrote:
+>
+> I know what you mean. I feel the very same.
+> * You get the a somelike systray, if you move the mouse to the 
+> bottom-right corner (at least networkmanager and mgaonline is there).
+> * virtual desktops are now known as "Activities". If a window is 
+> already open, go to the top-left corner (like when you want to open 
+> new apps). There you find on the right an extra panel, which enlarges 
+> if you hover the mouse.
+Thanks very much for figuring out the Alt-F4 trick.  I just assumed that 
+anything telling me my only option was to Logout had to be modal.
+
+With the latest updates, the desktop does actually come up, with the 
+striped background and showing 'Activities     Date     Username" at the 
+top, and I can once again scroll the applications.  Now, if the "Oops" 
+is not related to the launched application actually opening, I'll see 
+how far I can get.
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005759.html b/zarb-ml/mageia-dev/2011-June/005759.html new file mode 100644 index 000000000..0ac8c09c3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005759.html @@ -0,0 +1,76 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Frank Griffin + ftg at roadrunner.com +
+ Thu Jun 16 12:44:32 CEST 2011 +

+
+ +
On 06/16/2011 03:42 AM, Thorsten van Lil wrote:
+>
+> I know what you mean. I feel the very same.
+> * You get the a somelike systray, if you move the mouse to the 
+> bottom-right corner (at least networkmanager and mgaonline is there).
+> * virtual desktops are now known as "Activities". If a window is 
+> already open, go to the top-left corner (like when you want to open 
+> new apps). There you find on the right an extra panel, which enlarges 
+> if you hover the mouse.
+Thanks very much for figuring out the Alt-F4 trick.  I just assumed that 
+anything telling me my only option was to Logout had to be modal.
+
+With the latest updates, the desktop does actually come up, with the 
+striped background and showing 'Activities     Date     Username" at the 
+top, and I can once again scroll the applications.  Now, if the "Oops" 
+is not related to the launched application actually opening, I'll see 
+how far I can get.
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005760.html b/zarb-ml/mageia-dev/2011-June/005760.html new file mode 100644 index 000000000..c9099d7e8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005760.html @@ -0,0 +1,176 @@ + + + + [Mageia-dev] Mageia 2 - Improving educational programs + + + + + + + + + +

[Mageia-dev] Mageia 2 - Improving educational programs

+ Angelo Naselli + anaselli at linux.it +
+ Thu Jun 16 13:11:48 CEST 2011 +

+
+ +
HI,
+> This is really a good idea for a start.
+> 
+> i would say : go for it :)
+> 
+Here you are the start page! :)
+http://mageia.org/wiki/doku.php?id=sigedu
+
+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/20110616/5bcc37a5/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005761.html b/zarb-ml/mageia-dev/2011-June/005761.html new file mode 100644 index 000000000..d53e0bebc --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005761.html @@ -0,0 +1,81 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Thu Jun 16 13:21:26 CEST 2011 +

+
+ +
2011/6/16 Thorsten van Lil <tvl83 at gmx.de>:
+> * You get the a somelike systray, if you move the mouse to the bottom-right
+> corner (at least networkmanager and mgaonline is there).
+
+Yes, but:
+ - no icon visible, only the text, and the text is only visible one or
+the other, related to nouse moves. When I move the mouse inside the
+"systray" to the right, the text "net_applet" shows, when I move it a
+little bit to the left the net-applet text vanishes and the
+"mgaapplet" text appears.
+
+> * virtual desktops are now known as "Activities". If a window is already
+> open, go to the top-left corner (like when you want to open new apps). There
+> you find on the right an extra panel, which enlarges if you hover the mouse.
+
+Ok, now I have to see where I can set 4 virtual desktops and how to
+see the contents of all desktops (like in the task bar of KDE).
+
+Thx
+
+-- 
+wobo
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005762.html b/zarb-ml/mageia-dev/2011-June/005762.html new file mode 100644 index 000000000..4d357aaec --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005762.html @@ -0,0 +1,178 @@ + + + + [Mageia-dev] Mageia 2 - Improving educational programs + + + + + + + + + +

[Mageia-dev] Mageia 2 - Improving educational programs

+ mammig_linux mammig_linux + mammig.linux at gmail.com +
+ Thu Jun 16 14:19:38 CEST 2011 +

+
+ +
hello
+
+I'm register on the wiki, i will try to begin to complete the tables
+as soon as possible :)
+
+see you
+mammig
+
+2011/6/16 Angelo Naselli <anaselli at linux.it>:
+> HI,
+>> This is really a good idea for a start.
+>>
+>> i would say : go for it :)
+>>
+> Here you are the start page! :)
+> http://mageia.org/wiki/doku.php?id=sigedu
+>
+> Angelo
+>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005763.html b/zarb-ml/mageia-dev/2011-June/005763.html new file mode 100644 index 000000000..015b81866 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005763.html @@ -0,0 +1,188 @@ + + + + [Mageia-dev] nspluginwrapper reborn! + + + + + + + + + +

[Mageia-dev] nspluginwrapper reborn!

+ Zé + mmodem00 at gmail.com +
+ Thu Jun 16 14:58:00 CEST 2011 +

+
+ +
2011/6/15 Ahmad Samir <ahmadsamir3891 at gmail.com>:
+> Hello,
+>
+> nspluginwrapper has been updated to 1.3.x and now to 1.4.x, i.e. it
+> has a new upstream maintainer http://nspluginwrapper.davidben.net
+>
+> For the first time in probably 2-3years, the 32bit Adobe Flash player
+> seemed to work for me in a 64bit browser (I tested firefox and
+> konqueror).
+>
+> So give it a shot.
+>
+> (I've been suggesting, to users, _not_ to use nspluginwrapper for some
+> years now, since it never worked for me and I saw a lot of reports of
+> it not working in forums and bug reports, so this is my "I take that
+> back, it just needed some upstream love and care").
+
+Seams was needed new blood to have a new good push, maybe Gwenole
+Beauchesne was somehow tired of that project...
+I also stopped looking at nspluginwrapper source and did started with
+the native adobe flash-square for 64bit OS, but these are good news,
+so yes ill give it a try.
+
+> --
+> Ahmad Samir
+>
+
+-- 
+Zé
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005764.html b/zarb-ml/mageia-dev/2011-June/005764.html new file mode 100644 index 000000000..7e9be0a9d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005764.html @@ -0,0 +1,167 @@ + + + + [Mageia-dev] Mageia 2 - Improving educational programs + + + + + + + + + +

[Mageia-dev] Mageia 2 - Improving educational programs

+ Angelo Naselli + anaselli at linux.it +
+ Thu Jun 16 15:19:07 CEST 2011 +

+
+ +
giovedì 16 giugno 2011 alle 12:39, Michael Scherer ha scritto:
+> So I think we can find a better system for proposing software that
+> grouping together in some rpm that pull everything. 
+Agree, that's the idea.
+
+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/20110616/529b2dc1/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005765.html b/zarb-ml/mageia-dev/2011-June/005765.html new file mode 100644 index 000000000..8ed1852f1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005765.html @@ -0,0 +1,188 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Daniel Kreuter + daniel.kreuter85 at googlemail.com +
+ Thu Jun 16 16:18:07 CEST 2011 +

+
+ +
On Wed, Jun 15, 2011 at 10:38 PM, Donald Stewart <watersnowrock at gmail.com>wrote:
+
+> On 15 June 2011 13:35, Ahmad Samir <ahmadsamir3891 at gmail.com> wrote:
+> > On 14 June 2011 14:32, Frank Griffin <ftg at roadrunner.com> wrote:
+> >> On 06/14/2011 08:22 AM, Thierry Vignaud wrote:
+> >>>
+> >>> Upgrading stable firefox to firefox5rc and importing
+> firefox-{beta,aurora}
+> >>> are two distinct orthogonal things IMHO.
+> >>>
+> >>> since firefox5 is near being released, I think we should update
+> >>> main xulrunner+firefox to 5 anyway
+> >>>
+> >> Whatever we do, please don't put it in Core to replace FF4 until the
+> add-ons
+> >> have been updated.  It was really annoying to lose the Tor add-on for
+> months
+> >> because the beta FF4 just showed up and replaced FF3, and the Tor add-on
+> >> wasn't updated until the release or just before.
+> >>
+> >
+> > As I said, we have to have the Beta versions, so as to work out the
+> > niggles to be ready to push the stable version to stable releases
+> > (Mageia 1).
+> >
+> > You can always workaround the compatibility, either:
+> > - Adding it manually
+> http://kb.mozillazine.org/Extensions.checkCompatibility OR
+> > - Using this extension
+> >
+> https://addons.mozilla.org/en-US/firefox/addon/add-on-compatibility-reporter/
+> >
+> > in my experience, 90% of the time the addon will work with a new
+> > version of FF (but then again I use a limited number of addons).
+> >
+> > --
+> > Ahmad Samir
+> >
+>
+> I'm with Ahmad, going for beta for testing seems right. The beta
+> release stage should be long enough for issues to be sorted so aurora
+> isn't needed.
+>
+
+Ok Mozilla has the RC1 released. Final shall come on Tuesday 21st June so
+yeah we will include that in Mageia 2 I think (as least this one, maybe FF6
+or 7 depending on which version will be available i think)
+
+-- 
+Mit freundlichen Grüßen
+
+Greetings
+
+Daniel Kreuter
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110616/b89fd0ec/attachment-0001.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005766.html b/zarb-ml/mageia-dev/2011-June/005766.html new file mode 100644 index 000000000..3e6dc31e8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005766.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ JA Magallón + jamagallon at ono.com +
+ Thu Jun 16 16:47:07 CEST 2011 +

+
+ +
+On 2011.06.16, at 13:21, Wolfgang Bornath wrote:
+
+> 2011/6/16 Thorsten van Lil <tvl83 at gmx.de>:
+>> * You get the a somelike systray, if you move the mouse to the bottom-right
+>> corner (at least networkmanager and mgaonline is there).
+> 
+> Yes, but:
+> - no icon visible, only the text, and the text is only visible one or
+> the other, related to nouse moves. When I move the mouse inside the
+> "systray" to the right, the text "net_applet" shows, when I move it a
+> little bit to the left the net-applet text vanishes and the
+> "mgaapplet" text appears.
+
+Yup, there is a general lack of icons. For example, if I go to system
+settings panel, choose Sound, the 'little speaker' icons on the sides of
+slide bars are missing. The icon itself for the sound applet (and others)
+are also missing.
+
+And one other point: if you choose 'User Accounts' (or 'My account' in the
+right user menu), the panel complaints it can not contact to the 'accounts
+service'.
+
+I have googled it and it looks like it is time to get new gdm and
+accountsservice:
+
+https://bbs.archlinux.org/viewtopic.php?id=117501
+https://bugs.archlinux.org/task/23918
+
+http://www.freedesktop.org/software/accountsservice/
+
+--
+J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:
+                                         \         It's better when it's free
+
+
+
+
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005767.html b/zarb-ml/mageia-dev/2011-June/005767.html new file mode 100644 index 000000000..da4c9f58a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005767.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Thu Jun 16 16:55:38 CEST 2011 +

+
+ +
2011/6/16 JA Magallón <jamagallon at ono.com>:
+>
+> On 2011.06.16, at 13:21, Wolfgang Bornath wrote:
+>
+>> 2011/6/16 Thorsten van Lil <tvl83 at gmx.de>:
+>>> * You get the a somelike systray, if you move the mouse to the bottom-right
+>>> corner (at least networkmanager and mgaonline is there).
+>>
+>> Yes, but:
+>> - no icon visible, only the text, and the text is only visible one or
+>> the other, related to nouse moves. When I move the mouse inside the
+>> "systray" to the right, the text "net_applet" shows, when I move it a
+>> little bit to the left the net-applet text vanishes and the
+>> "mgaapplet" text appears.
+>
+> Yup, there is a general lack of icons. For example, if I go to system
+> settings panel, choose Sound, the 'little speaker' icons on the sides of
+> slide bars are missing. The icon itself for the sound applet (and others)
+> are also missing.
+>
+> And one other point: if you choose 'User Accounts' (or 'My account' in the
+> right user menu), the panel complaints it can not contact to the 'accounts
+> service'.
+
+Same here.
+
+Next: when I come from a locked screen, giving the password to unlock
+it, only the background shows. No top bar, nothing happening when I
+move the mouse to any side,top, bottom. I have to Clt+Alt+Back out.
+This happens 3 out of 5 today.
+
+-- 
+wobo
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005768.html b/zarb-ml/mageia-dev/2011-June/005768.html new file mode 100644 index 000000000..a1b21a7c0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005768.html @@ -0,0 +1,140 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Sander Lepik + sander.lepik at eesti.ee +
+ Thu Jun 16 17:14:14 CEST 2011 +

+
+ +
16.06.2011 17:18, Daniel Kreuter kirjutas:
+> Ok Mozilla has the RC1 released. Final shall come on Tuesday 21st June so yeah we will 
+> include that in Mageia 2 I think (as least this one, maybe FF6 or 7 depending on which 
+> version will be available i think)
+Well, it's quite possible that we have to include that in Mageia 1 as well, as this will be 
+security update for Firefox 4. If we don't want to patch every CVE then we have to include 
+it into Mageia 1 as well..
+
+--
+Sander
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005769.html b/zarb-ml/mageia-dev/2011-June/005769.html new file mode 100644 index 000000000..6f0301de2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005769.html @@ -0,0 +1,70 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Frank Griffin + ftg at roadrunner.com +
+ Thu Jun 16 18:07:02 CEST 2011 +

+
+ +
On 06/16/2011 10:55 AM, Wolfgang Bornath wrote:
+>
+> Next: when I come from a locked screen, giving the password to unlock
+> it, only the background shows. No top bar, nothing happening when I
+> move the mouse to any side,top, bottom. I have to Clt+Alt+Back out.
+> This happens 3 out of 5 today.
+>
+This was happening almost a week ago, but without the unlock, when I 
+mentioned that logging in gave a background screen with no 
+"Activities    Date   Username", and didn't respond to anything.  Could 
+be the same cause.
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005770.html b/zarb-ml/mageia-dev/2011-June/005770.html new file mode 100644 index 000000000..6e288c50b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005770.html @@ -0,0 +1,68 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Thu Jun 16 19:05:59 CEST 2011 +

+
+ +
Next:
+
+Am I blind or is there no chance to shutdown/reboot? The only way I
+found was "Log out" in the "wobo" menue (top right). This restarts the
+x server and there you can "Shutdown..." and then finally "Shutdown
+computer".
+
+-- 
+wobo
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005771.html b/zarb-ml/mageia-dev/2011-June/005771.html new file mode 100644 index 000000000..7c6d04c43 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005771.html @@ -0,0 +1,169 @@ + + + + [Mageia-dev] GNOME 3 and Video + + + + + + + + + +

[Mageia-dev] GNOME 3 and Video

+ Frank Griffin + ftg at roadrunner.com +
+ Thu Jun 16 19:09:59 CEST 2011 +

+
+ +
I'm finding that GNOME 3 is exhibiting a lot of video strangeness.  I 
+have a Radeon HD 3300 Graphics chip with the fglrx driver, and I'm 
+seeing a lot of flashing, "shaking", and skewing.  Redrawing the screen 
+when you switch windows with the cursor tends to exhibit this.  
+"Terminal" skews with a diagonal line from lower left to upper right, 
+and the text and graphics in the window appear italic in the extreme.  
+Tooltips in Thunderbird, e.g. floating the mouse over a message subject, 
+gives the same skewing.  The application icons come up fine, and then 
+disappear and stay gone for the rest of the session, although if you 
+right-click an app and choose "Add to Favorites", the correct icon is 
+added to Favorites.
+
+Do these symptoms suggest anything ?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005772.html b/zarb-ml/mageia-dev/2011-June/005772.html new file mode 100644 index 000000000..d521c562a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005772.html @@ -0,0 +1,68 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Frank Griffin + ftg at roadrunner.com +
+ Thu Jun 16 19:12:48 CEST 2011 +

+
+ +
On 06/16/2011 01:05 PM, Wolfgang Bornath wrote:
+> Am I blind or is there no chance to shutdown/reboot? The only way I
+> found was "Log out" in the "wobo" menue (top right). This restarts the
+> x server and there you can "Shutdown..." and then finally "Shutdown
+> computer".
+It doesn't restart the server for me (with KDM).  It doesn't always 
+work, but when it does you get a black-themed popup saying that you'll 
+log out in 60 seconds, and your options are Cancel of Logout (now), 
+which does take you back to KDM.  I'll try with GDM.
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005773.html b/zarb-ml/mageia-dev/2011-June/005773.html new file mode 100644 index 000000000..d92fbbb38 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005773.html @@ -0,0 +1,165 @@ + + + + [Mageia-dev] Mageia 2 - Improving educational programs + + + + + + + + + +

[Mageia-dev] Mageia 2 - Improving educational programs

+ José Jorge + jjorge at free.fr +
+ Thu Jun 16 19:14:07 CEST 2011 +

+
+ +
Le jeudi 16 juin 2011 13:11:48, Angelo Naselli a écrit :
+> HI,
+> 
+> > This is really a good idea for a start.
+> > 
+> > i would say : go for it :)
+> 
+> Here you are the start page! :)
+> http://mageia.org/wiki/doku.php?id=sigedu
+> 
+> Angelo
+
+Nice. Ktuberling is already packaged : part of kdegames, I have 
+
+ktuberling-4.6.3-1.mga1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005774.html b/zarb-ml/mageia-dev/2011-June/005774.html new file mode 100644 index 000000000..c4ac2657b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005774.html @@ -0,0 +1,160 @@ + + + + [Mageia-dev] Mageia 2 - Improving educational programs + + + + + + + + + +

[Mageia-dev] Mageia 2 - Improving educational programs

+ José Jorge + jjorge at free.fr +
+ Thu Jun 16 19:16:14 CEST 2011 +

+
+ +
Le jeudi 16 juin 2011 12:39:49, Michael Scherer a écrit :
+> So I think we can find a better system for proposing software that
+> grouping together in some rpm that pull everything.
+
+You mean something like Ubuntu's "logithèque"? I agree, but that's lots of 
+work. A task package by my view is used this way :
+
+- hi I discover linux, is there any education soft?
+- install task-edu, and try them.
+
+I always do that for newcomers
+
+José
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005775.html b/zarb-ml/mageia-dev/2011-June/005775.html new file mode 100644 index 000000000..2766cb67a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005775.html @@ -0,0 +1,79 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Thu Jun 16 19:21:40 CEST 2011 +

+
+ +
2011/6/16 Frank Griffin <ftg at roadrunner.com>:
+> On 06/16/2011 01:05 PM, Wolfgang Bornath wrote:
+>>
+>> Am I blind or is there no chance to shutdown/reboot? The only way I
+>> found was "Log out" in the "wobo" menue (top right). This restarts the
+>> x server and there you can "Shutdown..." and then finally "Shutdown
+>> computer".
+>
+> It doesn't restart the server for me (with KDM).  It doesn't always work,
+> but when it does you get a black-themed popup saying that you'll log out in
+> 60 seconds, and your options are Cancel of Logout (now), which does take you
+> back to KDM.  I'll try with GDM.
+
+I'm using KDM as well, but the problem is not the restart of the x
+server - it is the unavailability of a shutdown/restart dialogue in
+the menue, task bar, systray, wherever, which is annoying.
+
+-- 
+wobo
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005776.html b/zarb-ml/mageia-dev/2011-June/005776.html new file mode 100644 index 000000000..0d6453022 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005776.html @@ -0,0 +1,167 @@ + + + + [Mageia-dev] GNOME 3 and Video + + + + + + + + + +

[Mageia-dev] GNOME 3 and Video

+ Balcaen John + mikala at mageia.org +
+ Thu Jun 16 19:28:39 CEST 2011 +

+
+ +
Le jeudi 16 juin 2011 14:09:59, Frank Griffin a écrit :
+> I'm finding that GNOME 3 is exhibiting a lot of video strangeness.  I 
+> have a Radeon HD 3300 Graphics chip with the fglrx driver, and I'm 
+[...]
+> 
+> Do these symptoms suggest anything ?
+While testing Fedora 15 i found same problem with the fglrx driver, switching 
+back to the Free driver fix it. (i 've got  a radeon HD5700)
+
+
+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-June/005777.html b/zarb-ml/mageia-dev/2011-June/005777.html new file mode 100644 index 000000000..def8a76a4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005777.html @@ -0,0 +1,76 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Balcaen John + mikala at mageia.org +
+ Thu Jun 16 19:33:01 CEST 2011 +

+
+ +
Le jeudi 16 juin 2011 14:05:59, Wolfgang Bornath a écrit :
+> Next:
+> 
+> Am I blind or is there no chance to shutdown/reboot? The only way I
+> found was "Log out" in the "wobo" menue (top right). This restarts the
+> x server and there you can "Shutdown..." and then finally "Shutdown
+> computer".
+You need to push ALT to see the shutdown button.
+
+
+-- 
+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-June/005778.html b/zarb-ml/mageia-dev/2011-June/005778.html new file mode 100644 index 000000000..d99b60cf8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005778.html @@ -0,0 +1,176 @@ + + + + [Mageia-dev] Mageia 2 - Improving educational programs + + + + + + + + + +

[Mageia-dev] Mageia 2 - Improving educational programs

+ Marianne Lombard + marianne at tuxette.fr +
+ Thu Jun 16 19:34:17 CEST 2011 +

+
+ +
Le 16/06/2011 19:16, José Jorge a écrit :
+> Le jeudi 16 juin 2011 12:39:49, Michael Scherer a écrit :
+>> So I think we can find a better system for proposing software that
+>> grouping together in some rpm that pull everything.
+> You mean something like Ubuntu's "logithèque"? I agree, but that's lots of
+> work. A task package by my view is used this way :
+>
+> - hi I discover linux, is there any education soft?
+> - install task-edu, and try them.
+>
+> I always do that for newcomers
+>
+> José
+I think a web page (or a group of ) will be better
+We can present the software, explain how to install, etc
+
+The need are very different between a 4 or 5 years child (who will love 
+Gcompris or other similar programm) and 10-12 years, very fond of 
+stargazing, who will ask for stellarium or marble
+
+My 2 cents
+
+Jehane
+
+
+
+-- 
+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-June/005779.html b/zarb-ml/mageia-dev/2011-June/005779.html new file mode 100644 index 000000000..3b1fe0e1a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005779.html @@ -0,0 +1,138 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ lebarhon + lebarhon at free.fr +
+ Thu Jun 16 19:55:53 CEST 2011 +

+
+ +
by *pmithrandir 
+<https://forums.mageia.org/en/memberlist.php?mode=viewprofile&u=359>* » 
+Jun 13th, '11, 20:21
+On my side, I think mageia should do a "mix" of others idea.
+
+I would say :
+- A release every year.
+- During this year, a way to update some popular stuff (firefox, chrome, 
+libreoffice...)
+- During this year also a way to add some new package if needed or if 
+there is some instant success for a new software.
+
+Every 3 years, the release is LTS and that mean it would be maintain for 
+4 years.
+
+So at the same time, mageia would be in 3 mode :
+- The LTS
+- The common release
+- The cauldron.
+
+With that kind of stuff, you should have no more than one release for 
+public at a time, and just one LTS.
+If you update main software(we could define a list of no more than 20 
+software) people who are crasy about new function, or developper who 
+need tham to develop new stuff would be happy.
+
+BTW : I think mailing list are totally outdated and that mageia should 
+have a special section in this forum for these discussion, or maybe 
+another forum.
+It's totally impossible for people who want to participate sometimes to 
+follow you emails everydays. It's much faster to read some topic on a 
+forum than dozens emails. And your final user should be able to know 
+what happen easily. It would be a big + in front of others distributions.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110616/acf83a0c/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005780.html b/zarb-ml/mageia-dev/2011-June/005780.html new file mode 100644 index 000000000..90f32745f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005780.html @@ -0,0 +1,182 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ lebarhon + lebarhon at free.fr +
+ Thu Jun 16 19:57:52 CEST 2011 +

+
+ +
  by *pmithrandir 
+<https://forums.mageia.org/en/memberlist.php?mode=viewprofile&u=359>* » 
+Jun 13th, '11, 20:21
+> On my side, I think mageia should do a "mix" of others idea.
+>
+> I would say :
+> - A release every year.
+> - During this year, a way to update some popular stuff (firefox, 
+> chrome, libreoffice...)
+> - During this year also a way to add some new package if needed or if 
+> there is some instant success for a new software.
+>
+> Every 3 years, the release is LTS and that mean it would be maintain 
+> for 4 years.
+>
+> So at the same time, mageia would be in 3 mode :
+> - The LTS
+> - The common release
+> - The cauldron.
+>
+> With that kind of stuff, you should have no more than one release for 
+> public at a time, and just one LTS.
+> If you update main software(we could define a list of no more than 20 
+> software) people who are crasy about new function, or developper who 
+> need tham to develop new stuff would be happy.
+>
+> BTW : I think mailing list are totally outdated and that mageia should 
+> have a special section in this forum for these discussion, or maybe 
+> another forum.
+> It's totally impossible for people who want to participate sometimes 
+> to follow you emails everydays. It's much faster to read some topic on 
+> a forum than dozens emails. And your final user should be able to know 
+> what happen easily. It would be a big + in front of others distributions.
+by *claire 
+<https://forums.mageia.org/en/memberlist.php?mode=viewprofile&u=448>* » 
+Jun 16th, '11, 14:27
+
+    pmithrandir wrote:On my side, I think mageia should do a "mix" of
+    others idea.
+
+    I would say :
+    - A release every year.
+    - During this year, a way to update some popular stuff (firefox,
+    chrome, libreoffice...)
+    - During this year also a way to add some new package if needed or
+    if there is some instant success for a new software.
+
+    Every 3 years, the release is LTS and that mean it would be maintain
+    for 4 years.
+
+    So at the same time, mageia would be in 3 mode :
+    - The LTS
+    - The common release
+    - The cauldron.
+
+
+
+I completely agree with this. There is no real need to rush releases as 
+long as new versions are easily available. I know backports repo is 
+available but its not very user friendly. As an example, the newer 
+versions of Openshot video editor have a very nice feature of being able 
+to do animated titles. To be able to use them you need Blender 2.5. 
+Whilst Mageia includes Openshot 1.3.1 (which errors with missing plugins 
+btw) which at time of writing is current it still has Blender 2.49b.
+
+It would be useful if there were a nice user friendly way to upgrade 
+Blender when it is backported. Something to let ordinary users know a 
+newer version is available and a simple click to upgrade it.
+
+LTS releases in Ubuntu IMHO are a great idea and one which would add 
+value to mageia as a potential server/business OS where stability over 
+time is crucial.
+
+I dont think Joe Bloggs really cares about a 6 monthly distribution 
+upgrade, only that new versions of the software they use are easily 
+obtainable in the mean time and won't break the distribution upgrade 
+when it comes around.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110616/5663f737/attachment-0001.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005781.html b/zarb-ml/mageia-dev/2011-June/005781.html new file mode 100644 index 000000000..235ca9e47 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005781.html @@ -0,0 +1,207 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ lebarhon + lebarhon at free.fr +
+ Thu Jun 16 19:59:14 CEST 2011 +

+
+ +
Le 16/06/2011 19:57, lebarhon a écrit :
+>  by *pmithrandir 
+> <https://forums.mageia.org/en/memberlist.php?mode=viewprofile&u=359>* 
+> » Jun 13th, '11, 20:21
+>> On my side, I think mageia should do a "mix" of others idea.
+>>
+>> I would say :
+>> - A release every year.
+>> - During this year, a way to update some popular stuff (firefox, 
+>> chrome, libreoffice...)
+>> - During this year also a way to add some new package if needed or if 
+>> there is some instant success for a new software.
+>>
+>> Every 3 years, the release is LTS and that mean it would be maintain 
+>> for 4 years.
+>>
+>> So at the same time, mageia would be in 3 mode :
+>> - The LTS
+>> - The common release
+>> - The cauldron.
+>>
+>> With that kind of stuff, you should have no more than one release for 
+>> public at a time, and just one LTS.
+>> If you update main software(we could define a list of no more than 20 
+>> software) people who are crasy about new function, or developper who 
+>> need tham to develop new stuff would be happy.
+>>
+>> BTW : I think mailing list are totally outdated and that mageia 
+>> should have a special section in this forum for these discussion, or 
+>> maybe another forum.
+>> It's totally impossible for people who want to participate sometimes 
+>> to follow you emails everydays. It's much faster to read some topic 
+>> on a forum than dozens emails. And your final user should be able to 
+>> know what happen easily. It would be a big + in front of others 
+>> distributions.
+> by *claire 
+> <https://forums.mageia.org/en/memberlist.php?mode=viewprofile&u=448>* 
+> » Jun 16th, '11, 14:27
+>
+>     pmithrandir wrote:On my side, I think mageia should do a "mix" of
+>     others idea.
+>
+>     I would say :
+>     - A release every year.
+>     - During this year, a way to update some popular stuff (firefox,
+>     chrome, libreoffice...)
+>     - During this year also a way to add some new package if needed or
+>     if there is some instant success for a new software.
+>
+>     Every 3 years, the release is LTS and that mean it would be
+>     maintain for 4 years.
+>
+>     So at the same time, mageia would be in 3 mode :
+>     - The LTS
+>     - The common release
+>     - The cauldron.
+>
+>
+>
+> I completely agree with this. There is no real need to rush releases 
+> as long as new versions are easily available. I know backports repo is 
+> available but its not very user friendly. As an example, the newer 
+> versions of Openshot video editor have a very nice feature of being 
+> able to do animated titles. To be able to use them you need Blender 
+> 2.5. Whilst Mageia includes Openshot 1.3.1 (which errors with missing 
+> plugins btw) which at time of writing is current it still has Blender 
+> 2.49b.
+>
+> It would be useful if there were a nice user friendly way to upgrade 
+> Blender when it is backported. Something to let ordinary users know a 
+> newer version is available and a simple click to upgrade it.
+>
+> LTS releases in Ubuntu IMHO are a great idea and one which would add 
+> value to mageia as a potential server/business OS where stability over 
+> time is crucial.
+>
+> I dont think Joe Bloggs really cares about a 6 monthly distribution 
+> upgrade, only that new versions of the software they use are easily 
+> obtainable in the mean time and won't break the distribution upgrade 
+> when it comes around.
+by *roadrunner 
+<https://forums.mageia.org/en/memberlist.php?mode=viewprofile&u=468>* » 
+Jun 16th, '11, 15:35
+
+    claire wrote:
+
+        pmithrandir wrote:I dont think Joe Bloggs really cares about a 6
+        monthly distribution upgrade, only that new versions of the
+        software they use are easily obtainable in the mean time and
+        won't break the distribution upgrade when it comes around.
+
+Speaking as a typical "Joe Bloggs", all I'm interested in is keeping my 
+applications up to date with the occasional distribution upgrade. I'm 
+not interested in regular release cycles because I feel that this leads 
+to "rush-jobs", which in turn, leads to bugs galore. I'm more interested 
+in a solid reliable distribution upgrade on the "it'll be ready when 
+it's ready" basis.
+
+.\\artin
+- Mageia 1 32-bit - KDE SC 4.6.3 -
+- AMD Athlon 64 X2 5000+ CPU -
+- 4Gb RAM - nVidia 8500GT GPU -
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110616/50b25b5c/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005782.html b/zarb-ml/mageia-dev/2011-June/005782.html new file mode 100644 index 000000000..873d9328d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005782.html @@ -0,0 +1,196 @@ + + + + [Mageia-dev] [RPM] cauldron core/release rhythmbox-0.13.3-7.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release rhythmbox-0.13.3-7.mga2

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Thu Jun 16 20:12:39 CEST 2011 +

+
+ +
2011/6/16 JA Magallón <jamagallon at ono.com>:
+> On Tue, 14 Jun 2011 18:32:23 +0200 (CEST), Mageia Team <buildsystem-daemon at mageia.org> wrote:
+>
+>> Name        : rhythmbox                    Relocations: (not relocatable)
+>> Version     : 0.13.3                            Vendor: Mageia.Org
+>> Release     : 7.mga2                        Build Date: Tue Jun 14 18:24:25 2011
+>> Install Date: (not installed)               Build Host: ecosse
+>> Group       : Sound                         Source RPM: (none)
+>> Size        : 10009472                         License: GPLv2+ with exception
+>> Signature   : (none)
+>> Packager    : Mageia Team <http://www.mageia.org>
+>> URL         : http://www.gnome.org/projects/rhythmbox/
+>> Summary     : Music Management Application
+>> Description :
+>> Music Management application with support for ripping audio-cd's,
+>> playback of Ogg Vorbis and Mp3 and burning of CD-Rs.
+>>
+>> dmorgan <dmorgan> 0.13.3-7.mga2:
+>> + Revision: 106171
+>> - Fix file list
+>> - Add libproxy-devel as buildRequire
+>> - Rebuild against new brasero
+>>
+>
+> Needs another rebuild for new gnome-media:
+>
+> ne:~# rpm -qa *gnome-media*
+> lib64gnome-media0-2.32.0-3.mga1
+> gnome-media-2.91.2-1.mga2
+> libgnome-media-profiles-3.0.0-6.mga2
+> lib64gnome-media-profiles0-3.0.0-6.mga2
+> one:~# urpme lib64gnome-media0
+> To satisfy dependencies, the following 3 packages will be removed (15MB):
+>  lib64gnome-media0-2.32.0-3.mga1.x86_64
+>  lib64rhythmbox3-0.13.3-7.mga2.x86_64
+>   (due to missing libgnome-media-profiles.so.0()(64bit))
+>  rhythmbox-0.13.3-7.mga2.x86_64
+>   (due to missing librhythmbox-core.so.3()(64bit),
+>    due to unsatisfied lib64rhythmbox3 >= 0.13.3-7.mga2)
+> Remove 3 packages? (y/N)
+>
+>
+> --
+> J.A. Magallon <jamagallon()ono!com>     \                 Winter is coming...
+>
+
+It'll require more than a rebuild; most likely we'll have to push a
+git snapshot of rhythmbox due to the gtk+3.0 changes (pterjan said
+he'll take care of it), should be soon.
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005783.html b/zarb-ml/mageia-dev/2011-June/005783.html new file mode 100644 index 000000000..eb30c7f5a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005783.html @@ -0,0 +1,69 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Thorsten van Lil + tvl83 at gmx.de +
+ Thu Jun 16 20:20:06 CEST 2011 +

+
+ +
Am Donnerstag, 16. Juni 2011, 19:21:40 schrieb Wolfgang Bornath:
+> I'm using KDM as well, but the problem is not the restart of the x
+> server - it is the unavailability of a shutdown/restart dialogue in
+> the menue, task bar, systray, wherever, which is annoying.
+
+Yeah. I noticed that too. There is only log off and suspend.
+As moblin also lacks in such a shutdown function, I have the bad feeling that 
+it's not a bug, but i "feature".
+
+Regards
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005784.html b/zarb-ml/mageia-dev/2011-June/005784.html new file mode 100644 index 000000000..897e6fbc1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005784.html @@ -0,0 +1,75 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Thu Jun 16 20:27:03 CEST 2011 +

+
+ +
2011/6/16 Thorsten van Lil <tvl83 at gmx.de>:
+> Am Donnerstag, 16. Juni 2011, 19:21:40 schrieb Wolfgang Bornath:
+>> I'm using KDM as well, but the problem is not the restart of the x
+>> server - it is the unavailability of a shutdown/restart dialogue in
+>> the menue, task bar, systray, wherever, which is annoying.
+>
+> Yeah. I noticed that too. There is only log off and suspend.
+> As moblin also lacks in such a shutdown function, I have the bad feeling that
+> it's not a bug, but i "feature".
+
+A long time Linux protagonist who I admire and who has my deepest
+respect once said:
+"In Gnome the border between bug and feature is floating!"
+
+-- 
+wobo
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005785.html b/zarb-ml/mageia-dev/2011-June/005785.html new file mode 100644 index 000000000..6e2abbef3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005785.html @@ -0,0 +1,115 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ magnus + magnus.mud at googlemail.com +
+ Thu Jun 16 20:36:13 CEST 2011 +

+
+ +
2011/6/16 lebarhon <lebarhon at free.fr>
+
+> It would be useful if there were a nice user friendly way to upgrade
+> Blender when it is backported. Something to let ordinary users know a newer
+> version is available and a simple click to upgrade it.
+>
+
+Look to Mageia App DB (in testing)
+There is growing a good interface.
+
+http://88.191.121.20/madb/mageia/index.php/rpm/list/distrelease/2/application/0/arch/2/source/0/listtype/updates_testing/page/1
+The link shows the update soon coming.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110616/98096292/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005786.html b/zarb-ml/mageia-dev/2011-June/005786.html new file mode 100644 index 000000000..9dcc4cd37 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005786.html @@ -0,0 +1,75 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Thu Jun 16 20:54:10 CEST 2011 +

+
+ +
On Thu, 16 Jun 2011, Thorsten van Lil wrote:
+
+> Am Donnerstag, 16. Juni 2011, 19:21:40 schrieb Wolfgang Bornath:
+>> I'm using KDM as well, but the problem is not the restart of the x
+>> server - it is the unavailability of a shutdown/restart dialogue in
+>> the menue, task bar, systray, wherever, which is annoying.
+>
+> Yeah. I noticed that too. There is only log off and suspend.
+> As moblin also lacks in such a shutdown function, I have the bad feeling that
+> it's not a bug, but i "feature".
+
+Unlike the 'gnome shell', the gnome 3 panel does have a Shutdown item in 
+the user menu (but no Suspend).
+
+
+     Christiaan
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005787.html b/zarb-ml/mageia-dev/2011-June/005787.html new file mode 100644 index 000000000..6eb8ea0eb --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005787.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Thu Jun 16 20:58:18 CEST 2011 +

+
+ +
2011/6/16 Christiaan Welvaart <cjw at daneel.dyndns.org>:
+> On Thu, 16 Jun 2011, Thorsten van Lil wrote:
+>
+>> Am Donnerstag, 16. Juni 2011, 19:21:40 schrieb Wolfgang Bornath:
+>>>
+>>> I'm using KDM as well, but the problem is not the restart of the x
+>>> server - it is the unavailability of a shutdown/restart dialogue in
+>>> the menue, task bar, systray, wherever, which is annoying.
+>>
+>> Yeah. I noticed that too. There is only log off and suspend.
+>> As moblin also lacks in such a shutdown function, I have the bad feeling
+>> that
+>> it's not a bug, but i "feature".
+>
+> Unlike the 'gnome shell', the gnome 3 panel does have a Shutdown item in the
+> user menu (but no Suspend).
+
+Ah! Now I understand!
+Shutdown is old-school, the young generation only suspends!
+
+wobo, adjusting his suspenders.....
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005788.html b/zarb-ml/mageia-dev/2011-June/005788.html new file mode 100644 index 000000000..03fcbaadd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005788.html @@ -0,0 +1,189 @@ + + + + [Mageia-dev] Mageia 2 - Improving educational programs + + + + + + + + + +

[Mageia-dev] Mageia 2 - Improving educational programs

+ Daniel Kreuter + daniel.kreuter85 at googlemail.com +
+ Thu Jun 16 21:02:20 CEST 2011 +

+
+ +
On Thu, Jun 16, 2011 at 7:34 PM, Marianne Lombard <marianne at tuxette.fr>wrote:
+
+> Le 16/06/2011 19:16, José Jorge a écrit :
+>
+>  Le jeudi 16 juin 2011 12:39:49, Michael Scherer a écrit :
+>>
+>>> So I think we can find a better system for proposing software that
+>>> grouping together in some rpm that pull everything.
+>>>
+>> You mean something like Ubuntu's "logithèque"? I agree, but that's lots of
+>> work. A task package by my view is used this way :
+>>
+>> - hi I discover linux, is there any education soft?
+>> - install task-edu, and try them.
+>>
+>> I always do that for newcomers
+>>
+>> José
+>>
+> I think a web page (or a group of ) will be better
+> We can present the software, explain how to install, etc
+>
+> The need are very different between a 4 or 5 years child (who will love
+> Gcompris or other similar programm) and 10-12 years, very fond of
+> stargazing, who will ask for stellarium or marble
+>
+> My 2 cents
+>
+> Jehane
+>
+>
+>
+> --
+> 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
+>
+>
+A Live CD which will provide all of this programs would be nice too. And we
+will need a little bit of advertisement to find new people and even children
+using this programs.
+
+-- 
+Mit freundlichen Grüßen
+
+Greetings
+
+Daniel Kreuter
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110616/5e3bb9b0/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005789.html b/zarb-ml/mageia-dev/2011-June/005789.html new file mode 100644 index 000000000..26b975d73 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005789.html @@ -0,0 +1,82 @@ + + + + [Mageia-dev] Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Problems with Gnome 3

+ Dick Gevers + dvgevers at xs4all.nl +
+ Thu Jun 16 21:29:59 CEST 2011 +

+
+ +
On Thu, 16 Jun 2011 20:58:18 +0200, Wolfgang Bornath wrote about Re:
+[Mageia-dev] Problems with Gnome 3:
+
+>2011/6/16 Christiaan Welvaart <cjw at daneel.dyndns.org>:
+>> On Thu, 16 Jun 2011, Thorsten van Lil wrote:
+>>
+>>> Am Donnerstag, 16. Juni 2011, 19:21:40 schrieb Wolfgang Bornath:
+>>>>
+>>>> I'm using KDM as well, but the problem is not the restart of the x
+>>>> server - it is the unavailability of a shutdown/restart dialogue in
+>>>> the menue, task bar, systray, wherever, which is annoying.
+>>>
+>>> Yeah. I noticed that too. There is only log off and suspend.
+>>> As moblin also lacks in such a shutdown function, I have the bad feeling
+>>> that
+>>> it's not a bug, but i "feature".
+>>
+>> Unlike the 'gnome shell', the gnome 3 panel does have a Shutdown item in
+>> the user menu (but no Suspend).
+
+Press 'Shut Down' and you see suspend, hibernate, restart, cancel, shut
+down 
+
+HTH
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005790.html b/zarb-ml/mageia-dev/2011-June/005790.html new file mode 100644 index 000000000..9e44802a0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005790.html @@ -0,0 +1,162 @@ + + + + [Mageia-dev] Question about backports: calibre (bug 1659) + + + + + + + + + +

[Mageia-dev] Question about backports: calibre (bug 1659)

+ andre999 + andr55 at laposte.net +
+ Thu Jun 16 23:29:14 CEST 2011 +

+
+ +
Radu-Cristian FOTESCU a écrit :
+>
+>> From: andre999<andr55 at laposte.net>
+>>
+> [...]
+>>
+>> ...
+>> Considering your concern for the application, maybe you would
+>> like to package it for Mageia.  You could ensure that it is always up to date, and that it
+>> works properly, and is properly supported.  (The packager is a key player in support.) Just
+>> because it is called a backport doesn't mean that it won't work. The packager mentoring
+>> program will help you get started :)
+>>
+>> -- André
+>
+>
+> Well, first of all, I never liked the _concept_ of backports. Too many repositories, too complex
+> tree already. One of the reasons I wasn't very fond of Mandriva (the other reason being the
+> IaOra theme(s).)
+
+As Stormi suggested, you could consider backports as "feature updates".  (Whether or not the 
+repository names change.)
+There is a certain logic for having separate backport repositories.
+It is normal to put more focus on security updates and bug fixes, than introducing new features.
+The former could also be considered release blockers, but never backports.
+So QA focuses on security updates and bug fixes.
+Also, Mandriva provided corporate support for the former, but not backports.  Of course this 
+concept doesn't apply to a volonteer community distro such as Mageia.
+Mageia policy is inherited from Mandriva, but is evidently subject to changes.
+In terms of support, the nature of support by Mageia is yet to be defined, but it is starting to be 
+discussed.
+
+> From the NON-rolling distros, Fedora is arguably the only one who tries to bring newer versions
+> of a number of applications throughout its 12+1 months lifecycle. w/o using backports. My
+> opinion is that, as long as system libraries are _not_ upgraded, many other packages
+> (applications!) should be updated as appropriate. Otherwise, the result would be that Windows
+> users would have more freedom and ease in decided what version of the [multi-platform
+> open-source] applications to use than Linux users! (Except, of course, the users of
+> rolling-release distros, and except for users of unstable/rawhide/cooker/cauldron...)
+>
+> I know, I should probably be using Fedora as long as _some_ of their principles suit my views
+> much more than Mageia does or than Mandriva did. However, Fedora lacks something like Mandriva
+> Control Center, and yum is millions of times slower than urpmi, therefore...
+
+I appreciate the same strengths inherited by Mageia.
+
+> Not to mention that most of the best people Mandriva had are now with Mageia, which makes this
+> distro hard to ignore... (Je crois qu'on appelle cela zugzwang...)
+
+I agree totally.  Mageia is the best of the old Mandriva.
+
+So what I propose is that you seriously consider packaging your application for Mageia.
+We find a mentor for you to apprentice with, to familiarise you with the process.
+In choosing a mentor, it would help to find someone in the same time zone.
+You're in Canada ?  What time zone ?
+(I'd offer to mentor you myself, being also in Canada, but I'm not yet a full packager.)
+When I started, I was able to package my favorite application to start with, hopefully you can do 
+the same, if it's not too complicated.  (Since you indicate that it doesn't have dependancies 
+to/from other packages, I suspect that it would be relatively straight-forward.)
+Once you have started packaging, you have a better chance to influence Mageia policy, if you still 
+think that it should be changed.
+But in any case you would be able to ensure that your package is available on Mageia, and is always 
+up to date.
+And of course, ensure that it works properly.
+
+So, isn't it worth a try ? :)
+>
+> R-C
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005791.html b/zarb-ml/mageia-dev/2011-June/005791.html new file mode 100644 index 000000000..a803d6501 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005791.html @@ -0,0 +1,175 @@ + + + + [Mageia-dev] [RPM] cauldron core/release rhythmbox-0.13.3-7.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release rhythmbox-0.13.3-7.mga2

+ JA Magallón + jamagallon at ono.com +
+ Fri Jun 17 00:11:09 CEST 2011 +

+
+ +
On Thu, 16 Jun 2011 21:12:39 +0300, Ahmad Samir <ahmadsamir3891 at gmail.com> wrote:
+
+> 2011/6/16 JA Magallón <jamagallon at ono.com>:
+> > On Tue, 14 Jun 2011 18:32:23 +0200 (CEST), Mageia Team <buildsystem-daemon at mageia.org> wrote:
+> >
+> >> Name        : rhythmbox                    Relocations: (not relocatable)
+> >> Version     : 0.13.3                            Vendor: Mageia.Org
+> >> Release     : 7.mga2                        Build Date: Tue Jun 14 18:24:25 2011
+> >
+> > Needs another rebuild for new gnome-media:
+> >
+> > ne:~# rpm -qa *gnome-media*
+> > lib64gnome-media0-2.32.0-3.mga1
+> > gnome-media-2.91.2-1.mga2
+> > libgnome-media-profiles-3.0.0-6.mga2
+> > lib64gnome-media-profiles0-3.0.0-6.mga2
+> > one:~# urpme lib64gnome-media0
+> > To satisfy dependencies, the following 3 packages will be removed (15MB):
+> >  lib64gnome-media0-2.32.0-3.mga1.x86_64
+> >  lib64rhythmbox3-0.13.3-7.mga2.x86_64
+> >   (due to missing libgnome-media-profiles.so.0()(64bit))
+> >  rhythmbox-0.13.3-7.mga2.x86_64
+> >   (due to missing librhythmbox-core.so.3()(64bit),
+> >    due to unsatisfied lib64rhythmbox3 >= 0.13.3-7.mga2)
+> > Remove 3 packages? (y/N)
+...
+> 
+> It'll require more than a rebuild; most likely we'll have to push a
+> git snapshot of rhythmbox due to the gtk+3.0 changes (pterjan said
+> he'll take care of it), should be soon.
+> 
+
+Ahh, the pleasure of going bleeding edge...
+
+So the release of Gnome 3 is just the platform, everything around it has not
+caught up yet...
+
+-- 
+J.A. Magallon <jamagallon()ono!com>     \                 Winter is coming...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005792.html b/zarb-ml/mageia-dev/2011-June/005792.html new file mode 100644 index 000000000..9fdbd099e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005792.html @@ -0,0 +1,187 @@ + + + + [Mageia-dev] [RPM] cauldron core/release rhythmbox-0.13.3-7.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release rhythmbox-0.13.3-7.mga2

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Fri Jun 17 00:33:47 CEST 2011 +

+
+ +
2011/6/17 JA Magallón <jamagallon at ono.com>:
+> On Thu, 16 Jun 2011 21:12:39 +0300, Ahmad Samir <ahmadsamir3891 at gmail.com> wrote:
+>
+>> 2011/6/16 JA Magallón <jamagallon at ono.com>:
+>> > On Tue, 14 Jun 2011 18:32:23 +0200 (CEST), Mageia Team <buildsystem-daemon at mageia.org> wrote:
+>> >
+>> >> Name        : rhythmbox                    Relocations: (not relocatable)
+>> >> Version     : 0.13.3                            Vendor: Mageia.Org
+>> >> Release     : 7.mga2                        Build Date: Tue Jun 14 18:24:25 2011
+>> >
+>> > Needs another rebuild for new gnome-media:
+>> >
+>> > ne:~# rpm -qa *gnome-media*
+>> > lib64gnome-media0-2.32.0-3.mga1
+>> > gnome-media-2.91.2-1.mga2
+>> > libgnome-media-profiles-3.0.0-6.mga2
+>> > lib64gnome-media-profiles0-3.0.0-6.mga2
+>> > one:~# urpme lib64gnome-media0
+>> > To satisfy dependencies, the following 3 packages will be removed (15MB):
+>> >  lib64gnome-media0-2.32.0-3.mga1.x86_64
+>> >  lib64rhythmbox3-0.13.3-7.mga2.x86_64
+>> >   (due to missing libgnome-media-profiles.so.0()(64bit))
+>> >  rhythmbox-0.13.3-7.mga2.x86_64
+>> >   (due to missing librhythmbox-core.so.3()(64bit),
+>> >    due to unsatisfied lib64rhythmbox3 >= 0.13.3-7.mga2)
+>> > Remove 3 packages? (y/N)
+> ...
+>>
+>> It'll require more than a rebuild; most likely we'll have to push a
+>> git snapshot of rhythmbox due to the gtk+3.0 changes (pterjan said
+>> he'll take care of it), should be soon.
+>>
+>
+> Ahh, the pleasure of going bleeding edge...
+>
+> So the release of Gnome 3 is just the platform, everything around it has not
+> caught up yet...
+>
+
+One or two apps != everything :)
+
+I guess, that's normal with huge changes, it takes time till the
+ripple effect covers the whole pond.
+
+> --
+> J.A. Magallon <jamagallon()ono!com>     \                 Winter is coming...
+>
+
+
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005793.html b/zarb-ml/mageia-dev/2011-June/005793.html new file mode 100644 index 000000000..faea165c5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005793.html @@ -0,0 +1,161 @@ + + + + [Mageia-dev] [RPM] cauldron core/release task-gnome-2-0.3.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release task-gnome-2-0.3.mga2

+ JA Magallón + jamagallon at ono.com +
+ Fri Jun 17 00:42:21 CEST 2011 +

+
+ +
On Thu, 16 Jun 2011 21:38:10 +0200 (CEST), Mageia Team <buildsystem-daemon at mageia.org> wrote:
+
+> Name        : task-gnome                   Relocations: (not relocatable)
+> Version     : 2                                 Vendor: Mageia.Org
+> Release     : 0.3.mga2                      Build Date: Thu Jun 16 21:37:15 2011
+> Install Date: (not installed)               Build Host: jonund
+> Group       : Graphical desktop/GNOME       Source RPM: (none)
+> Size        : 7141                             License: GPLv2+
+> Signature   : (none)
+> Packager    : Mageia Team <http://www.mageia.org>
+> Summary     : Metapackage for GNOME desktop environment
+> Description :
+> This package is a meta-package, meaning that its purpose is to contain
+> dependencies for running the GNOME2.
+> 
+> dmorgan <dmorgan> 1:2-0.3.mga2:
+> + Revision: 108331
+> - Update requires
+
+If this is fot accountsservice, should not this (and perhaps others) go to
+task-gnome-minimal ?
+They are required, not extra things, IMHO ;)
+
+-- 
+J.A. Magallon <jamagallon()ono!com>     \                 Winter is coming...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005794.html b/zarb-ml/mageia-dev/2011-June/005794.html new file mode 100644 index 000000000..095cad633 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005794.html @@ -0,0 +1,113 @@ + + + + [Mageia-dev] Question about backports: calibre (bug 1659) + + + + + + + + + +

[Mageia-dev] Question about backports: calibre (bug 1659)

+ Radu-Cristian FOTESCU + beranger5ca at yahoo.ca +
+ Fri Jun 17 06:56:12 CEST 2011 +

+
+ +
>So what I propose is that you seriously consider packaging your application for Mageia.
+>We find a mentor for you to apprentice with, to familiarise you with the process.
+>In choosing a mentor, it would help to find someone in the same time zone.
+>You're in Canada ?  What time zone ?
+>(I'd offer to mentor you myself, being also in Canada, but I'm not yet a full packager.)
+
+André,
+
+No matter what my e-mail address is, I am not in Canada, but in Romania.
+
+Anyway, I'll think of packaging once I fix some other issues. Right now I'm investigating a very peculiar crash in KCharSelect (an upstream issue), which actually means KCharSelect crashes when a bad font is used (DejaVu _is_ having some bad issues). As I am not familiar with Qt4/KDE development, it's a kinky issue. And the bug is not where it seems to be. (I can't report the bug right now, but if you want details, ask me.) I am stunned that such an application like KCharSelect can crash such badly and nobody fixes it (yes, to reproduce the bug you must know to identify the actual conditions, however there are some upstream bug reports about this crashes, poorly defined). This being said, CharMap in Windows _never_ crashed, in no version of Windows, whereas KCharSelect _always_ crashes, from KDE 4.0 onwards. If I won't be able to pinpoint the bug (yes, I want to fix it), I might reconsider one more time using KDE4 (hence Linux) on my laptop, as this is
+ utterly ridiculous to have KCharSelect crashing like shit (ask me and I'll tell you how to crash it on _any_ distro) and nobody doing anything! Millions of Linux users and developers!
+
+
+>When I started, I was able to package my favorite application to start with, hopefully you can do 
+>the same, if it's not too complicated.  (Since you indicate that it doesn't have dependancies 
+>to/from other packages, I suspect that it would be relatively straight-forward.)
+
+It needs Python 2.7 and whatnot, but this is not an issue. (I've packaged some RPMs in 2009, just not for Mandriva, for EL5-compatible distros.)
+
+R-C
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005795.html b/zarb-ml/mageia-dev/2011-June/005795.html new file mode 100644 index 000000000..9c3b5f431 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005795.html @@ -0,0 +1,159 @@ + + + + [Mageia-dev] [RPM] cauldron core/release task-gnome-2-0.3.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release task-gnome-2-0.3.mga2

+ Dexter Morgan + dmorganec at gmail.com +
+ Fri Jun 17 07:20:23 CEST 2011 +

+
+ +
2011/6/17 JA Magallón <jamagallon at ono.com>:
+> On Thu, 16 Jun 2011 21:38:10 +0200 (CEST), Mageia Team <buildsystem-daemon at mageia.org> wrote:
+>
+>> Name        : task-gnome                   Relocations: (not relocatable)
+>> Version     : 2                                 Vendor: Mageia.Org
+>> Release     : 0.3.mga2                      Build Date: Thu Jun 16 21:37:15 2011
+>> Install Date: (not installed)               Build Host: jonund
+>> Group       : Graphical desktop/GNOME       Source RPM: (none)
+>> Size        : 7141                             License: GPLv2+
+>> Signature   : (none)
+>> Packager    : Mageia Team <http://www.mageia.org>
+>> Summary     : Metapackage for GNOME desktop environment
+>> Description :
+>> This package is a meta-package, meaning that its purpose is to contain
+>> dependencies for running the GNOME2.
+>>
+>> dmorgan <dmorgan> 1:2-0.3.mga2:
+>> + Revision: 108331
+>> - Update requires
+>
+> If this is fot accountsservice, should not this (and perhaps others) go to
+> task-gnome-minimal ?
+
+this is already in task-gnome-minimal
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005796.html b/zarb-ml/mageia-dev/2011-June/005796.html new file mode 100644 index 000000000..99927ef95 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005796.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] Question about backports: calibre (bug 1659) + + + + + + + + + +

[Mageia-dev] Question about backports: calibre (bug 1659)

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Fri Jun 17 11:24:22 CEST 2011 +

+
+ +
On 13 June 2011 11:51, Radu-Cristian FOTESCU <beranger5ca at yahoo.ca> wrote:
+> Therefore, I strongly believe that all calibre updates be packaged into updates, not backports, especially as there isn't any Mageia 2.0 as of yet. Once Mageia 2.0 is released, whatever newer calibre releases will be available might go into backports instead -- if at all. (Although I'd say that it should still be updated to updates for the whole supported time of 1.0.)
+>
+> What do you think?
+
+I think that before thinking of updating or backporting that new version,
+you could start by actually update the package in cauldron so that:
+1) it can be tested...
+2) we're sure we won't have packages in mga1/updates newer that those
+of mga2/release
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005797.html b/zarb-ml/mageia-dev/2011-June/005797.html new file mode 100644 index 000000000..a277ffaae --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005797.html @@ -0,0 +1,152 @@ + + + + [Mageia-dev] [RPM] cauldron core/release mageia-kde4-config-1-13.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release mageia-kde4-config-1-13.mga2

+ Dick Gevers + dvgevers at xs4all.nl +
+ Fri Jun 17 12:07:42 CEST 2011 +

+
+ +
On Fri, 17 Jun 2011 05:15:13 +0200 (CEST), Mageia Team wrote about [RPM]
+cauldron core/release mageia-kde4-config-1-13.mga2:
+
+>Name        : mageia-kde4-config           Relocations: (not relocatable)
+>Version     : 1                                 Vendor: Mageia.Org
+>Release     : 13.mga2                       Build Date: Fri Jun 17
+>05:10:17 2011 
+
+>mikala <mikala> 1-13.mga2:
+>+ Revision: 108603
+>- Don't use -nr as an argument for ServerArgsLocal
+
+Well I'm checking kdmrc against kdmrc.cppbackup with meld but I still
+see '-nr' included as 'ServerArgsLocal'.
+
+HTH
+=Dick Gevers=
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005798.html b/zarb-ml/mageia-dev/2011-June/005798.html new file mode 100644 index 000000000..f9d5ddade --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005798.html @@ -0,0 +1,150 @@ + + + + [Mageia-dev] [RPM] cauldron core/release mageia-kde4-config-1-13.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release mageia-kde4-config-1-13.mga2

+ Balcaen John + mikala at mageia.org +
+ Fri Jun 17 15:45:06 CEST 2011 +

+
+ +
Le vendredi 17 juin 2011 07:07:42, Dick Gevers a écrit :
+[...]
+> Well I'm checking kdmrc against kdmrc.cppbackup with meld but I still
+> see '-nr' included as 'ServerArgsLocal'.
+> 
+Hum, it's strange.
+Did you change something in your kdmrc ?
+you should have at least a /var/lib/mageia/kde4-
+profiles/Default/share/config/kdm/kdmrc.rpmnew  
+
+with the correct ServerArgsLocal
+
+-- 
+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-June/005799.html b/zarb-ml/mageia-dev/2011-June/005799.html new file mode 100644 index 000000000..0c87f78cb --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005799.html @@ -0,0 +1,189 @@ + + + + [Mageia-dev] Fw: Re: Problems with Gnome 3 + + + + + + + + + +

[Mageia-dev] Fw: Re: Problems with Gnome 3

+ Dick Gevers + dvgevers at xs4all.nl +
+ Fri Jun 17 15:58:19 CEST 2011 +

+
+ +
Begin forwarded message:
+.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
+Date: Fri, 17 Jun 2011 14:26:20 +0200
+From: Wolfgang Bornath 
+To: Dick Gevers
+Subject: Re: [Mageia-dev] Problems with Gnome 3
+
+
+2011/6/16 Dick Gevers :
+> On Thu, 16 Jun 2011 20:58:18 +0200, Wolfgang Bornath wrote about Re:
+> [Mageia-dev] Problems with Gnome 3:
+>
+>>2011/6/16 Christiaan Welvaart:
+>>> On Thu, 16 Jun 2011, Thorsten van Lil wrote:
+>>>
+>>>> Am Donnerstag, 16. Juni 2011, 19:21:40 schrieb Wolfgang Bornath:
+>>>>>
+>>>>> I'm using KDM as well, but the problem is not the restart of the x
+>>>>> server - it is the unavailability of a shutdown/restart dialogue in
+>>>>> the menue, task bar, systray, wherever, which is annoying.
+>>>>
+>>>> Yeah. I noticed that too. There is only log off and suspend.
+>>>> As moblin also lacks in such a shutdown function, I have the bad
+>>>> feeling that
+>>>> it's not a bug, but i "feature".
+>>>
+>>> Unlike the 'gnome shell', the gnome 3 panel does have a Shutdown item in
+>>> the user menu (but no Suspend).
+>
+> Press 'Shut Down' and you see suspend, hibernate, restart, cancel, shut
+> down
+
+Well, I have to give credit to the Gnome project: their documentation
+is quite up-to-date!
+
+The official way to shutdown/reboot from gnome-shell is actually
+logging off via user menue, then select shutdown or reboot in the
+context menue in the login screen.
+
+BUT:
+Open the user menue and then press the ALT key - the "Suspend" option
+changes to "Power Off" !
+Or, even faster: In "System settings -> Power" change the action for
+"Press power button" to "Shutdown" (values translated from German, so
+they may be a bit different)
+ - you get a dialogue with options [shutdown, reboot, cancel], if you
+do nothing the system shuts down in 60 seconds.
+
+http://library.gnome.org/users/gnome-help/stable/ - recommended read!
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005800.html b/zarb-ml/mageia-dev/2011-June/005800.html new file mode 100644 index 000000000..0364b7e22 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005800.html @@ -0,0 +1,165 @@ + + + + [Mageia-dev] [RPM] cauldron core/release mageia-kde4-config-1-13.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release mageia-kde4-config-1-13.mga2

+ Dick Gevers + dvgevers at xs4all.nl +
+ Fri Jun 17 16:28:11 CEST 2011 +

+
+ +
On Fri, 17 Jun 2011 10:45:06 -0300, Balcaen John wrote about Re:
+[Mageia-dev] [RPM] cauldron core/release mageia-kde4-config-1-13.mga2:
+
+>> Well I'm checking kdmrc against kdmrc.cppbackup with meld but I still
+>> see '-nr' included as 'ServerArgsLocal'.
+>> 
+>Hum, it's strange.
+>Did you change something in your kdmrc ?
+>you should have at least a /var/lib/mageia/kde4-
+>profiles/Default/share/config/kdm/kdmrc.rpmnew  
+>
+>with the correct ServerArgsLocal
+
+Yup, that's what urpmi said when done, but when all scripts had run, I still
+had line 191 and 192 as below in kdmrc.cppbackup and no *rpmnew in said
+directory.
+
+grep -n tcp kdmrc
+191:# Default is "-nolisten tcp"
+192:ServerArgsLocal=-deferglyphs 16 -nolisten tcp
+
+but instead of '-deferglyphs 16' I had '-nr' as argument.
+
+I just changed it before my previous msg, hence the grep as above.
+
+As far as I remember, and memory serves reasonably well, the kdmrc was set
+up during install-after-format of Mageia 1 final on a formatted drive and
+not changed by me (I use gdm).
+
+Cheers,
+=Dick Gevers=
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005801.html b/zarb-ml/mageia-dev/2011-June/005801.html new file mode 100644 index 000000000..c775ea16c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005801.html @@ -0,0 +1,132 @@ + + + + [Mageia-dev] Question about backports: calibre (bug 1659) + + + + + + + + + +

[Mageia-dev] Question about backports: calibre (bug 1659)

+ andre999 + andr55 at laposte.net +
+ Fri Jun 17 18:14:13 CEST 2011 +

+
+ +
Radu-Cristian FOTESCU a écrit :
+>
+> André,
+>
+> No matter what my e-mail address is, I am not in Canada, but in Romania.
+
+Ok.  So you're close (in time zone) to most contributors :)
+
+> Anyway, I'll think of packaging once I fix some other issues. Right now I'm investigating a very
+> peculiar crash in KCharSelect (an upstream issue), which actually means KCharSelect crashes when
+> a bad font is used (DejaVu _is_ having some bad issues). As I am not familiar with Qt4/KDE
+> development, it's a kinky issue. And the bug is not where it seems to be. (I can't report the
+> bug right now, but if you want details, ask me.) I am stunned that such an application like
+> KCharSelect can crash such badly and nobody fixes it (yes, to reproduce the bug you must know to
+> identify the actual conditions, however there are some upstream bug reports about this crashes,
+> poorly defined). This being said, CharMap in Windows _never_ crashed, in no version of Windows,
+> whereas KCharSelect _always_ crashes, from KDE 4.0 onwards. If I won't be able to pinpoint the
+> bug (yes, I want to fix it), I might reconsider one more time using KDE4 (hence Linux) on my
+> laptop, as this is utterly ridiculous to have KCharSelect crashing  ...
+
+Maybe KCharSelect wasn't updated for KDE 4 ?
+Why not use gucharmap ?  It seems complete, is desktop-neutral, and has never given me any problems.
+It's on the regular mageia dvd's (but not the dual).  And of course in the repositories.
+Problem solved :)
+
+>> When I started, I was able to package my favorite application to start with, hopefully you can
+>> do the same, if it's not too complicated.  (Since you indicate that it doesn't have
+>> dependancies to/from other packages, I suspect that it would be relatively straight-forward.)
+>
+> It needs Python 2.7 and whatnot, but this is not an issue. (I've packaged some RPMs in 2009,
+> just not for Mandriva, for EL5-compatible distros.)
+
+Python 2.7 is in Mageia 1.
+If you've already had a Mandriva packaging account, you already qualify to be a Mageia packager.
+Otherwise you have to be mentored, but being familiar with packaging, it should be a very quick 
+process :)
+
+> R-C
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005802.html b/zarb-ml/mageia-dev/2011-June/005802.html new file mode 100644 index 000000000..030b6afcd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005802.html @@ -0,0 +1,113 @@ + + + + [Mageia-dev] Question about backports: calibre (bug 1659) + + + + + + + + + +

[Mageia-dev] Question about backports: calibre (bug 1659)

+ Radu-Cristian FOTESCU + beranger5ca at yahoo.ca +
+ Fri Jun 17 18:26:34 CEST 2011 +

+
+ +
>Maybe KCharSelect wasn't updated for KDE 4 ?
+
+It was, and very much so. Before having a kcharselect binary in kdeutils, it had prepared especially for that purpose a kcharselect widget as part of kdeui, in kdelibs. Amazing contournement...
+
+
+>Why not use gucharmap ?  It seems complete, is desktop-neutral, and has never 
+
+> given me any problems.
+>It's on the regular mageia dvd's (but not the dual).  And of course in the repositories.
+>Problem solved :)
+
+On the contrary, the idea is not to avoid fixing the bugs, but to face the issues, identify them, and pinpoint the root cause.
+
+>If you've already had a Mandriva packaging account, you already qualify to be a Mageia packager.
+
+Did not.
+
+
+>André
+
+R-C
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005803.html b/zarb-ml/mageia-dev/2011-June/005803.html new file mode 100644 index 000000000..72b69e3e3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005803.html @@ -0,0 +1,152 @@ + + + + [Mageia-dev] [RPM] cauldron core/release mageia-kde4-config-1-13.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release mageia-kde4-config-1-13.mga2

+ Balcaen John + mikala at mageia.org +
+ Fri Jun 17 18:28:50 CEST 2011 +

+
+ +
Le vendredi 17 juin 2011 11:28:11, Dick Gevers a écrit :
+[...]
+> 
+> Yup, that's what urpmi said when done, but when all scripts had run, I still
+> had line 191 and 192 as below in kdmrc.cppbackup and no *rpmnew in said
+> directory.
+[...]
+> As far as I remember, and memory serves reasonably well, the kdmrc was set
+> up during install-after-format of Mageia 1 final on a formatted drive and
+> not changed by me (I use gdm).
+
+It's strange, i just done the upgrade on another box & i'll end up with a 
+kdmrc.rpmnew in /var/lib/...
+I also noticed that in fact the /usr/share/config/kdm/kdmrc was also rewritten 
+(probably by genkdmconf which explain why i end up with a kdmrc.rpmnew)
+
+
+-- 
+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-June/005804.html b/zarb-ml/mageia-dev/2011-June/005804.html new file mode 100644 index 000000000..51bbd2760 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005804.html @@ -0,0 +1,145 @@ + + + + [Mageia-dev] [RPM] cauldron core/release mageia-kde4-config-1-13.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release mageia-kde4-config-1-13.mga2

+ Dick Gevers + dvgevers at xs4all.nl +
+ Fri Jun 17 18:45:21 CEST 2011 +

+
+ +
On Fri, 17 Jun 2011 13:28:50 -0300, Balcaen John wrote about Re:
+[Mageia-dev] [RPM] cauldron core/release mageia-kde4-config-1-13.mga2:
+
+>It's strange, i just done the upgrade on another box & i'll end up with a 
+>kdmrc.rpmnew in /var/lib/...
+>I also noticed that in fact the /usr/share/config/kdm/kdmrc was also
+>rewritten (probably by genkdmconf which explain why i end up with a
+>kdmrc.rpmnew)
+
+Yes my first boot after install of mga 1 was of course with kdm, but I
+didn't configure it myself. Still I saw urpmi's warning about an *rpmnew
+written, whilst it was not there when I went to diff in there!
+
+BFN
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005805.html b/zarb-ml/mageia-dev/2011-June/005805.html new file mode 100644 index 000000000..658f02832 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005805.html @@ -0,0 +1,142 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ lebarhon + lebarhon at free.fr +
+ Fri Jun 17 19:33:35 CEST 2011 +

+
+ +
by *Trio3b 
+<https://forums.mageia.org/en/memberlist.php?mode=viewprofile&u=395>* » 
+Jun 17th, '11, 17:55
+Must preface this reply by saying I am not a coder, developer, packager. 
+Just an end user. Long time MDV user (ver. 10.0). I have tried almost 
+every distro out there for fun but on my main desktop I use MDV 
+2008.1KDE3.5.x and have stuck with it b/c it is used for business.
+
+I have been tinkering with PCLOS for the past two years. It is very easy 
+to succumb to the "grass is greener" mindset and I too have fallen into 
+that trap with PCLOS. It really is a fine distro (originally and to some 
+extent still based on MDV) but have come to the conclusion that for fun, 
+upgrading/Updating is fine, but for day to day business use it is not 
+really an option.
+
+I understand that Mageia has little or no control over certain elements 
+of the IT landscape.Witness KDE fiasco with distro forums full of 
+problems, breaks, memory leaks, Plasma configuration problems. I have 
+experienced that with PCLOS being a rolling distro so I have NOT 
+migrated to it for business as of yet.
+
+I believe that a great deal of credibility can be given to opensource if 
+it can be seen to be stable and useable for long periods of time in the 
+business community. I haven't a clue about the technical requirements in 
+determining a release schedule but can speak from a users standpoint and 
+that is many small businesses such as myself CAN NOT employ technology 
+people. I really enjoy installing and configuring linux OS on various 
+hardware but I have to be realistic and stand firm in the belief that if 
+one of my office crew is faced with a blank screen (as has happened with 
+recent PCLOS2011.6 test release), then the fun of "fixing" it must take 
+a back seat to getting on with work.
+
+It is mentioned that several releases can be maintained at the same 
+time. Can't a long term stable release be made to sync up with new 
+advances every couple years, with the long term user UNDERSTANDING that 
+a major reinstall will be necessary at the end of that 2-3 yr . THAT IS 
+INFINITELY preferable to an upgrade that breaks something.
+
+Speaking of planning, when you KNOW you have to upgrade you will have 
+your work flow and backups planned. An upgrade that breaks a system 
+disrupts workflow and even if you have data backed up it destroys 
+confidence in the ability of the software to support workflow.
+
+Workflow disruption is an enemy to running a business and constant KDE4 
+upgrades have kept me from leaving KDE3.5.x
+
+Hope this helps some devs
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110617/e17a3bfb/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005806.html b/zarb-ml/mageia-dev/2011-June/005806.html new file mode 100644 index 000000000..724c166f7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005806.html @@ -0,0 +1,133 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ lebarhon + lebarhon at free.fr +
+ Fri Jun 17 19:38:40 CEST 2011 +

+
+ +
by *wobo 
+<https://forums.mageia.org/en/memberlist.php?mode=viewprofile&u=77>* » 
+Jun 17th, '11, 18:50
+Several points jumped through my synapses reading Trio3b's post.
+
+A thought I had many times before: are the users ready for such Linux 
+distributions? I do not mean any technical skills, no user is supposed 
+to learn how to create scripts and configure things by editing config 
+files any more. But I often see that users lack the mindset, the way of 
+thinking which is required by administrating your own *nix system. One 
+nice example was the KDE switch to 4.x which Trio3b described as fiasco. 
+But was this fiasco not really caused by the users demand for "the 
+latest" although KDE stated that 4.0 (and a few following versions) were 
+not for userland? With the proper mindset users without development 
+skills would have stayed away from KDE 4 until it was declared as 
+"userland-ready", which was with 4.2 [1]. This is just one example but 
+could also be ported to other "fiascos".
+
+As often said, Linux is a system which forces the user to be a sysadmin 
+as well - but as a sysadmin you think different than a user does. IMHO 
+this is one point which is not communicated enough to the user. Of 
+course, marketing would have a fit seeing the question "Are you ready to 
+be a sysadmin?" all over the portal site of our Linux distribution. But 
+isn't this really the question here when we talk about backports, 
+updates, rolling releases and all the rest? These are expressions and 
+tasks for a sysadmin, not a user.
+
+In business we do have IT departments and sysadmins who care for those 
+things - your average Dilbert in his cubicle is not supposed to care for 
+updates. But for the user at home we see this dual personality with the 
+different mindsets to be a given fact. Is that so?
+
+As you can see, I did not aim at a certain conclusion here, I just let 
+my thoughts roam free (could well be an exposé for a editor's article).
+
+[1] Of course, for the real "fiasco" we have to blame a certain 
+distribution as well which could not wait to be "the first to offer the 
+new KDE!" and thus caused other distributions to follow.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110617/0a76ff20/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005807.html b/zarb-ml/mageia-dev/2011-June/005807.html new file mode 100644 index 000000000..a45bd4109 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005807.html @@ -0,0 +1,126 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ lebarhon + lebarhon at free.fr +
+ Fri Jun 17 19:39:27 CEST 2011 +

+
+ +
by *magnus 
+<https://forums.mageia.org/en/memberlist.php?mode=viewprofile&u=82>* » 
+Jun 17th, '11, 19:26 I think the whole discussion is dominated by 
+"technical" users.
+I, as a simple user, need a stable, secure system where I can use my 
+applications.
+
+Gnome 2, 3, 4 ??? KDE 4.6, 4. 7, 5.0 ??? What does it matter.
+At the office a must use a system called xp, but for our 10.000 girls 
+and boys it runs stable.
+That's it.
+
+I admit, this is a very simple view.
+But for me and a lot of users a very important criterion.
+I don`t believe this can provide a "rolling release" (in the moment).
+
+So I prefer a a reasonable release cycle with enough time for the 
+development and the qa.
+For example, a new release every nine months brings me the new 
+developments, not just the latest.
+But I can also update my system with a clear conscience and without 
+great risks.
+
+The technicans can play with cauldron and the latest developments ;-)
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110617/906ffe59/attachment.html>
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: icon_e_wink.gif
+Type: image/gif
+Size: 630 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20110617/906ffe59/attachment.gif>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005808.html b/zarb-ml/mageia-dev/2011-June/005808.html new file mode 100644 index 000000000..8b949ce49 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005808.html @@ -0,0 +1,112 @@ + + + + [Mageia-dev] Question about backports: calibre (bug 1659) + + + + + + + + + +

[Mageia-dev] Question about backports: calibre (bug 1659)

+ andre999 + andr55 at laposte.net +
+ Sat Jun 18 06:31:59 CEST 2011 +

+
+ +
Radu-Cristian FOTESCU a écrit :
+>
+>> Maybe KCharSelect wasn't updated for KDE 4 ?
+>
+> It was, and very much so. Before having a kcharselect binary in kdeutils, it had prepared especially for that purpose a kcharselect widget as part of kdeui, in kdelibs. Amazing contournement...
+>
+>> Why not use gucharmap ?  It seems complete, is desktop-neutral, and has never given me any problems.
+>> It's on the regular mageia dvd's (but not the dual).  And of course in the repositories.
+>> Problem solved :)
+>
+> On the contrary, the idea is not to avoid fixing the bugs, but to face the issues, identify them, and pinpoint the root cause.
+
+OK.  Good luck.
+Hope you filed a bug report.  Don't forget that 10 people doing the same 10% of a solution is not 
+as effective as 10 people cooperating :)
+>
+>> André
+>
+> R-C
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005809.html b/zarb-ml/mageia-dev/2011-June/005809.html new file mode 100644 index 000000000..4ad493c63 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005809.html @@ -0,0 +1,159 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ andre999 + andr55 at laposte.net +
+ Sat Jun 18 09:38:49 CEST 2011 +

+
+ +
Michael Scherer a écrit :
+
+> Proposal 1:
+> 6 months release cycle ->  12 months life cycle
+> ( Fedora, Ubuntu, Mandriva<  2010.1&&  Mandriva != 2006.0 )
+>
+> Proposal 2:
+> 9 months release cycle ->  18 months life cycle
+> ( ~ opensuse and the one we used for Mageia 1 )
+>
+> Proposal 3:
+> 12 months release cycle ->  24 months life cycle
+> ( Mandriva>  2010.1 )
+
+
+First, suggest an amended freeze process (idea from recent report of another project)
+Instead of a freeze on cauldron until everything is ready for the release, we do
+1) short freeze on cauldron
+2) copy cauldron to pre-release branch, which remains frozen until release
+3) immediately unfreeze cauldron.
+
+- we avoid blocking cauldron, while leaving pre-release frozen for bug fixes.
+- updates can continue on cauldron.  Bugfixes can be applied to newer versions, if present in 
+cauldron, at the same time as corresponding bugfixes in pre-release.
+- activities like translation can continue in cauldron, meaning less rush for such updates.
+- because cauldron is open to changes (virtually) all the time, they don't have to be put off and 
+perhaps forgotten.
+- the cauldron cycle is extented by the time of the pre-release freeze.  e.g. In a release cycle of 
+6 months and a pre-release freeze of 1 month, the cauldron cycle would be 7 months.
+This allows more time to iron out the pre-release bugs and more time for cauldron.
+- with the longer pre-release freeze, it may be appropriate to modify somewhat the policy on what 
+is accepted during freeze.  (Certain more recent packages or translations, for example.)
+- note that we would still have to monitor cauldron to avoid freezing partially implemented complex 
+changes, such as a major update of kde or gnome or perl, etc.  But we have to do that now, anyway.
+
+
+> Proposal 1 :
+> ---------------
+My personal preference
+
+> Pros:
+> - better hardware support
+> - up to date versions / upstream projects (must have for developers)
+- coincides with kde/gnome releases
+- amended freeze process (outlined above) would lengthen both pre-release freeze time and cauldron 
+development time.
+A 1-month pre-release freeze would add 1 month to cauldron development time.
+This would tend to alleviate the rush of the 6-month release cycle.
+
+> - short life cycle
+would be alleviated by having periodic long term support releases (lasting at least 2 years).
+
+
+> Proposal 2
+> ----------------
+> Pros:
+- amended freeze process outlined above would still be advantageous, to a lessor degree.
+
+> Cons:
+> - not synchronized with gnome or others that use a 6 month cycle
+> - potentially release when there isn't much activity (like during Holidays)
+- release would not be the same month every year
+e.g. 2011 june ; 2012 mar ; 2012 dec ; 2013 sep ; 2014 june ...
+so users won't know when to expect a release
+
+
+> Proposal 3 :
+> ------------
+Would prefer to avoid this.
+
+Additional cons :
+- periodic long-term support releases with a shorter release cycle would be more advantageous, in 
+terms of providing long-term stability for the few who would prefer it, while allowing a more 
+up-to-date distro.
+- requires more updates and backports, in order to keep up to date with upstream, which doesn't 
+necessarily reduce workload over shorter release cycles.
+
+my 2 cents :)
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005810.html b/zarb-ml/mageia-dev/2011-June/005810.html new file mode 100644 index 000000000..42a52bedb --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005810.html @@ -0,0 +1,84 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Dick Gevers + dvgevers at xs4all.nl +
+ Sat Jun 18 10:16:53 CEST 2011 +

+
+ +
On Tue, 14 Jun 2011 23:43:57 +0200, Samuel Verschelde wrote about Re:
+[Mageia-dev] Release cycles proposals, and discussion:
+
+>Thanks for the fame :) Do you know how I could easily have an institute
+>named after me ?
+
+With the meteorlogical service of a windy nation (small island group for
+instance): Stormi Weather Institute.
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005811.html b/zarb-ml/mageia-dev/2011-June/005811.html new file mode 100644 index 000000000..accf04af3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005811.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ John + john at neodoc.biz +
+ Sat Jun 18 10:36:50 CEST 2011 +

+
+ +
On Sat, 18 Jun 2011 08:16:53 +0000
+Dick Gevers wrote:
+
+> On Tue, 14 Jun 2011 23:43:57 +0200, Samuel Verschelde wrote about Re:
+> [Mageia-dev] Release cycles proposals, and discussion:
+> 
+> >Thanks for the fame :) Do you know how I could easily have an institute
+> >named after me ?
+> 
+> With the meteorlogical service of a windy nation (small island group for
+> instance): Stormi Weather Institute.
+
+Pitcairn ?
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005812.html b/zarb-ml/mageia-dev/2011-June/005812.html new file mode 100644 index 000000000..13decdf7f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005812.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ lebarhon + lebarhon at free.fr +
+ Sat Jun 18 12:10:36 CEST 2011 +

+
+ +
by *isadora 
+<https://forums.mageia.org/en/memberlist.php?mode=viewprofile&u=90>* » 
+Jun 17th, '11, 20:04
+Must admit magnus is right about the difference between "technical" and 
+"regular"-users.
+Today i started adding the cauldron-repositories, and did a first update 
+to my test-Mageia.
+The first bunch of packages (about 40) went without a hassle through MCC.
+But then MCC stopped functioning, and i had to change to konsole to get 
+in the other 600.
+Due to a sloppy internet-connection, i had to restart the 
+updating-process twice, and in the end i was missing four packages.
+I managed to install them all in the end, but you have to be familiar 
+with the command-line.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110618/0db929a7/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005813.html b/zarb-ml/mageia-dev/2011-June/005813.html new file mode 100644 index 000000000..b3c815ec5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005813.html @@ -0,0 +1,117 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ lebarhon + lebarhon at free.fr +
+ Sat Jun 18 12:11:17 CEST 2011 +

+
+ +
by *magnus 
+<https://forums.mageia.org/en/memberlist.php?mode=viewprofile&u=82>* » 
+Jun 17th, '11, 20:55
+
+    isadora wrote:Today i started adding the cauldron-repositories, and
+    did a first update to my test-Mageia.
+
+
+Today I have done the same job.
+about 20 minutes - good internet connection and ssd :)
+(In the past ELP had a song "Lucky man")
+
+one package has a missing signature
+
+    isadora wrote:....... but you have to be familiar with the command-line.
+
+
+I think for Cauldron is the command-line with "urpmi --auto-update" the 
+better way for updates
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110618/00f5d6a8/attachment.html>
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: icon_e_smile.gif
+Type: image/gif
+Size: 630 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20110618/00f5d6a8/attachment.gif>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005814.html b/zarb-ml/mageia-dev/2011-June/005814.html new file mode 100644 index 000000000..c4e48c11c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005814.html @@ -0,0 +1,110 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ lebarhon + lebarhon at free.fr +
+ Sat Jun 18 12:12:05 CEST 2011 +

+
+ +
by *wobo 
+<https://forums.mageia.org/en/memberlist.php?mode=viewprofile&u=77>* » 
+Jun 18th, '11, 00:54
+
+    magnus wrote:(In the past ELP had a song "Lucky man")
+
+
+Most people forget that Lucky Man became worm fodder at the end of the song.
+But you can always enter the Zeppelin and take the Stairway to Heaven 
+for spiritual healing... :)
+
+(...Clementine is now playing ELP's 4-Bridges-Suite)
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110618/0694df3e/attachment.html>
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: icon_e_smile.gif
+Type: image/gif
+Size: 630 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20110618/0694df3e/attachment.gif>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005815.html b/zarb-ml/mageia-dev/2011-June/005815.html new file mode 100644 index 000000000..2d1696fe2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005815.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ lebarhon + lebarhon at free.fr +
+ Sat Jun 18 12:13:09 CEST 2011 +

+
+ +
by *keksbaecker 
+<https://forums.mageia.org/en/memberlist.php?mode=viewprofile&u=698>* » 
+Jun 18th, '11, 11:07
+I am also just a simple end user and for me it is more important to have 
+a stable and running System than having the the latest Desktop 
+Environment installed.
+
+Personally I think a new release every nine months would be great but I 
+could also imagine a release every year if it is possible to install a 
+newer (even it is not the newest) version of e.g. LibreOffice or Pidgin 
+using the official Mageia repositories instead of downloading it from 
+their Homepage and maybe have to compile myself (I tried once and failed)..
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110618/4bff2a4f/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005816.html b/zarb-ml/mageia-dev/2011-June/005816.html new file mode 100644 index 000000000..77033f199 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005816.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ Michael Scherer + misc at zarb.org +
+ Sat Jun 18 13:19:16 CEST 2011 +

+
+ +
Le samedi 18 juin 2011 à 12:12 +0200, lebarhon a écrit :
+
+1) can you please avoid posting as html to the list ?
+
+2) if you wish to serve as a human gateway really between forum and ml
+( which I didn't ask, I am smart enough to read forum by myself, as I
+helped install them among others ), 
+can you at least be smart and forward only on topic discussion ? 
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005817.html b/zarb-ml/mageia-dev/2011-June/005817.html new file mode 100644 index 000000000..90b46983b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005817.html @@ -0,0 +1,106 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ Samuel Verschelde + stormi at laposte.net +
+ Sat Jun 18 13:35:34 CEST 2011 +

+
+ +
Le samedi 18 juin 2011 13:19:16, Michael Scherer a écrit :
+> Le samedi 18 juin 2011 à 12:12 +0200, lebarhon a écrit :
+> 
+> 1) can you please avoid posting as html to the list ?
+> 
+> 2) if you wish to serve as a human gateway really between forum and ml
+> ( which I didn't ask, I am smart enough to read forum by myself, as I
+> helped install them among others ),
+> can you at least be smart and forward only on topic discussion ?
+
+Misc, I agree with the main idea (html and forward only on topic messages), 
+but not with the way you say it, a bit sharp. By the way, you didn't ask for 
+this "gateway", but it is, at least a good intention, and personnally I think 
+it is useful to forward what users say about it in the forum. You read them, 
+but several people here recognized they don't want to or can't read the 
+forums.
+
+Samuel
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005818.html b/zarb-ml/mageia-dev/2011-June/005818.html new file mode 100644 index 000000000..44263a5a3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005818.html @@ -0,0 +1,115 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Sat Jun 18 13:42:28 CEST 2011 +

+
+ +
Op zaterdag 18 juni 2011 13:35:34 schreef Samuel Verschelde:
+> Le samedi 18 juin 2011 13:19:16, Michael Scherer a écrit :
+> > Le samedi 18 juin 2011 à 12:12 +0200, lebarhon a écrit :
+> > 
+> > 1) can you please avoid posting as html to the list ?
+> > 
+> > 2) if you wish to serve as a human gateway really between forum and ml
+> > ( which I didn't ask, I am smart enough to read forum by myself, as I
+> > helped install them among others ),
+> > can you at least be smart and forward only on topic discussion ?
+> 
+> Misc, I agree with the main idea (html and forward only on topic messages),
+> but not with the way you say it, a bit sharp. By the way, you didn't ask
+> for this "gateway", but it is, at least a good intention, and personnally
+> I think it is useful to forward what users say about it in the forum. You
+> read them, but several people here recognized they don't want to or can't
+> read the forums.
+> 
+> Samuel
+
+i agree, i don't read the forums, i have no problem with people relaying this 
+on this subject, even though i feel that if they want to say something they 
+should talk here...
+
+but, misc, iirc, you said that if someone wanted to capture the forums 
+reactions and take responsibility of being a bridge, they could.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005819.html b/zarb-ml/mageia-dev/2011-June/005819.html new file mode 100644 index 000000000..fc50cfb0a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005819.html @@ -0,0 +1,182 @@ + + + + [Mageia-dev] "Job offer" : mentoring program coordinator + + + + + + + + + +

[Mageia-dev] "Job offer" : mentoring program coordinator

+ Samuel Verschelde + stormi at laposte.net +
+ Sat Jun 18 14:55:45 CEST 2011 +

+
+ +
Le dimanche 12 juin 2011 15:27:59, Samuel Verschelde a écrit :
+> Hello to everyone,
+> 
+> I'm sure there's someone among you who wants to help Mageia but hasn't
+> found yet the good way to do it. Today is your lucky day, because there's
+> a job that's available and can be really useful and interesting:
+> coordinating the packagers mentoring program.
+> 
+> You know that one key point of success for Mageia is in the ability to
+> welcome new packagers. The better we will be at it, the better the distro
+> will be. The packagers mentoring program has been created for that reason
+> and several packagers have been or are being mentored. But we have some
+> difficulty knowing who is being mentored by who and who hasn't found a
+> mentor. And we need also to find more mentors and more apprentices.
+> 
+> During a packagers weekly meeting, misc invited us to read the following
+> article about mentoring programs in open-source projects:
+> http://blogs.gnome.org/bolsh/2011/05/31/effective-mentoring-programs/
+> 
+> I invite those who haven't read it yet, to read it. I'll quote one of the
+> mentoring best practices that were given: "In bigger projects, keeping
+> track of who is a mentor, and who is mentoring who, and inviting new
+> mentors, and ensuring that no-one falls through the cracks when a mentor
+> gets too busy, is a job of itself."
+> 
+> I'm looking for someone who could fill that "job".
+> 
+> Description of the job:
+> 
+> - keep track of:
+> -- who's being mentored by who, how well it's going
+> -- who needs a mentor and hasn't found one yet (this is one of the most
+> important parts: no volunteer must be forgotten, volunteers are too
+> precious !)
+> -- who can mentor more apprentices (and sometimes convince packagers to
+> become mentors or accept one more apprentice)
+> 
+> - be available for questions from apprentices or mentors, by mail, and if
+> possible, to be present on the IRC channel #mageia-mentoring on freenode
+> 
+> - help mentors with gathering "junior tasks" (bugzilla is a never empty
+> reserve that can be used for that. Maybe ask the bug triage team to help
+> identify such tasks. Maybe a "junior task" keyword in bugzilla would do the
+> trick)
+> -- small bugs to fix
+> -- new small packages to import in the distribution
+> -- backports
+> 
+> - promote mentoring (empower users into contributers. Working with the
+> marketing team would be great I think):
+> -- make the mentoring program known (MLs, forums, web, etc.)
+> -- look for new apprentices
+> -- look for new mentors
+> 
+> Some useful skills:
+> - be autonomous (ie no need to check that you're doing the work)
+> - good written english (communication is very important in this job)
+> - knowledge about packaging is a plus but not mandatory (the key aspects
+> can be taught to you)
+> - being or having been a mentor, or having been mentored would be a plus,
+> but not mandatory
+> 
+> More information about the job:
+> - does not require a big amount of work, but real committment to the task
+> and regularity
+> - remember that you have a coordination role, not an authoritative role.
+> The difference in that is that you're not here to give orders but to
+> facilitate the mentoring program.
+> - you don't have to be alone to do this job if it's too much for one
+> person: you can find other helpful people wanting to help you if needed
+> and rely on the other teams (but finding them *is* part of your job ;) ).
+> -  this "job offer" concerns everything that revolves around the mentoring
+> of new packagers, but if it's successful maybe other teams can follow the
+> same approach (i18n, QA, etc... ).
+> -  depending on your level of confidence, experience and will, you could be
+> helped in your work. Maybe someone from the council can supervise and help
+> you at least at the beginning; or, if no one steps up, I can help you
+> bootstrap and organize your new "job".
+> 
+> So, who's in?
+> 
+> Samuel Verschelde
+
+Hello to all,
+
+First, thanks to those to offered to help.
+
+We had 3 candidates, plus one who offered help whoever will be in charge. 2 
+candidates were retained (Kharec has too many duties already to take the job), 
+who I interviewed on IRC to try to see who would fit best.
+
+The 2 candidates were good, which complicated my task because I had to make a 
+choice, but I finally came to a decision : I propose andre999 as a mentoring 
+program coordinator (or facilitator, if you think it fits the job better).
+
+What made me choose him over Daniel Kreuter (whose candidacy was good, I 
+repeat it) is the fact he already showed interest in this subject before the 
+"job offer", has been mentored (even if the mentoring has not been completed 
+for now), and I already had enough occasions to exchange with him in the past 
+to think that he will have the required communication skills and diplomacy to 
+do the job.
+
+Now, it doesn't mean he has to be alone, so I hope than magnus will help him, 
+for example to bring an IRC presence at hours where André is not available due 
+to his timezone, and if Daniel is still interested in helping for those tasks, 
+I'm sure André will be glad to receive his help.
+
+If you have any questions or remarks, don't hesitate to comment.
+
+To ennael and misc : do you want to take part in the boostrapping of André's 
+work ? I think it could be good to avoid any misunderstandings and be sure we 
+set the good direction.
+
+Best regards
+
+Samuel Verschelde
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005820.html b/zarb-ml/mageia-dev/2011-June/005820.html new file mode 100644 index 000000000..d37fcfd0c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005820.html @@ -0,0 +1,216 @@ + + + + [Mageia-dev] "Job offer" : mentoring program coordinator + + + + + + + + + +

[Mageia-dev] "Job offer" : mentoring program coordinator

+ Daniel Kreuter + daniel.kreuter85 at googlemail.com +
+ Sat Jun 18 15:03:28 CEST 2011 +

+
+ +
On Sat, Jun 18, 2011 at 2:55 PM, Samuel Verschelde <stormi at laposte.net>wrote:
+
+> Le dimanche 12 juin 2011 15:27:59, Samuel Verschelde a écrit :
+> > Hello to everyone,
+> >
+> > I'm sure there's someone among you who wants to help Mageia but hasn't
+> > found yet the good way to do it. Today is your lucky day, because there's
+> > a job that's available and can be really useful and interesting:
+> > coordinating the packagers mentoring program.
+> >
+> > You know that one key point of success for Mageia is in the ability to
+> > welcome new packagers. The better we will be at it, the better the distro
+> > will be. The packagers mentoring program has been created for that reason
+> > and several packagers have been or are being mentored. But we have some
+> > difficulty knowing who is being mentored by who and who hasn't found a
+> > mentor. And we need also to find more mentors and more apprentices.
+> >
+> > During a packagers weekly meeting, misc invited us to read the following
+> > article about mentoring programs in open-source projects:
+> > http://blogs.gnome.org/bolsh/2011/05/31/effective-mentoring-programs/
+> >
+> > I invite those who haven't read it yet, to read it. I'll quote one of the
+> > mentoring best practices that were given: "In bigger projects, keeping
+> > track of who is a mentor, and who is mentoring who, and inviting new
+> > mentors, and ensuring that no-one falls through the cracks when a mentor
+> > gets too busy, is a job of itself."
+> >
+> > I'm looking for someone who could fill that "job".
+> >
+> > Description of the job:
+> >
+> > - keep track of:
+> > -- who's being mentored by who, how well it's going
+> > -- who needs a mentor and hasn't found one yet (this is one of the most
+> > important parts: no volunteer must be forgotten, volunteers are too
+> > precious !)
+> > -- who can mentor more apprentices (and sometimes convince packagers to
+> > become mentors or accept one more apprentice)
+> >
+> > - be available for questions from apprentices or mentors, by mail, and if
+> > possible, to be present on the IRC channel #mageia-mentoring on freenode
+> >
+> > - help mentors with gathering "junior tasks" (bugzilla is a never empty
+> > reserve that can be used for that. Maybe ask the bug triage team to help
+> > identify such tasks. Maybe a "junior task" keyword in bugzilla would do
+> the
+> > trick)
+> > -- small bugs to fix
+> > -- new small packages to import in the distribution
+> > -- backports
+> >
+> > - promote mentoring (empower users into contributers. Working with the
+> > marketing team would be great I think):
+> > -- make the mentoring program known (MLs, forums, web, etc.)
+> > -- look for new apprentices
+> > -- look for new mentors
+> >
+> > Some useful skills:
+> > - be autonomous (ie no need to check that you're doing the work)
+> > - good written english (communication is very important in this job)
+> > - knowledge about packaging is a plus but not mandatory (the key aspects
+> > can be taught to you)
+> > - being or having been a mentor, or having been mentored would be a plus,
+> > but not mandatory
+> >
+> > More information about the job:
+> > - does not require a big amount of work, but real committment to the task
+> > and regularity
+> > - remember that you have a coordination role, not an authoritative role.
+> > The difference in that is that you're not here to give orders but to
+> > facilitate the mentoring program.
+> > - you don't have to be alone to do this job if it's too much for one
+> > person: you can find other helpful people wanting to help you if needed
+> > and rely on the other teams (but finding them *is* part of your job ;) ).
+> > -  this "job offer" concerns everything that revolves around the
+> mentoring
+> > of new packagers, but if it's successful maybe other teams can follow the
+> > same approach (i18n, QA, etc... ).
+> > -  depending on your level of confidence, experience and will, you could
+> be
+> > helped in your work. Maybe someone from the council can supervise and
+> help
+> > you at least at the beginning; or, if no one steps up, I can help you
+> > bootstrap and organize your new "job".
+> >
+> > So, who's in?
+> >
+> > Samuel Verschelde
+>
+> Hello to all,
+>
+> First, thanks to those to offered to help.
+>
+> We had 3 candidates, plus one who offered help whoever will be in charge. 2
+> candidates were retained (Kharec has too many duties already to take the
+> job),
+> who I interviewed on IRC to try to see who would fit best.
+>
+> The 2 candidates were good, which complicated my task because I had to make
+> a
+> choice, but I finally came to a decision : I propose andre999 as a
+> mentoring
+> program coordinator (or facilitator, if you think it fits the job better).
+>
+> What made me choose him over Daniel Kreuter (whose candidacy was good, I
+> repeat it) is the fact he already showed interest in this subject before
+> the
+> "job offer", has been mentored (even if the mentoring has not been
+> completed
+> for now), and I already had enough occasions to exchange with him in the
+> past
+> to think that he will have the required communication skills and diplomacy
+> to
+> do the job.
+>
+> Now, it doesn't mean he has to be alone, so I hope than magnus will help
+> him,
+> for example to bring an IRC presence at hours where André is not available
+> due
+> to his timezone, and if Daniel is still interested in helping for those
+> tasks,
+> I'm sure André will be glad to receive his help.
+>
+> If you have any questions or remarks, don't hesitate to comment.
+>
+> To ennael and misc : do you want to take part in the boostrapping of
+> André's
+> work ? I think it could be good to avoid any misunderstandings and be sure
+> we
+> set the good direction.
+>
+> Best regards
+>
+> Samuel Verschelde
+>
+
+Congratulation andre999 for the job. If you need my help feel free to ask
+me.
+
+
+
+-- 
+Mit freundlichen Grüßen
+
+Greetings
+
+Daniel Kreuter
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110618/733abdd8/attachment.html>
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005821.html b/zarb-ml/mageia-dev/2011-June/005821.html new file mode 100644 index 000000000..5418ce453 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005821.html @@ -0,0 +1,110 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ Michael Scherer + misc at zarb.org +
+ Sat Jun 18 15:58:42 CEST 2011 +

+
+ +
Le samedi 18 juin 2011 à 13:35 +0200, Samuel Verschelde a écrit :
+> Le samedi 18 juin 2011 13:19:16, Michael Scherer a écrit :
+> > Le samedi 18 juin 2011 à 12:12 +0200, lebarhon a écrit :
+> > 
+> > 1) can you please avoid posting as html to the list ?
+> > 
+> > 2) if you wish to serve as a human gateway really between forum and ml
+> > ( which I didn't ask, I am smart enough to read forum by myself, as I
+> > helped install them among others ),
+> > can you at least be smart and forward only on topic discussion ?
+> 
+> Misc, I agree with the main idea (html and forward only on topic messages), 
+> but not with the way you say it, a bit sharp. 
+
+It was also asked twice by Colin
+( https://mageia.org/pipermail/mageia-dev/2011-June/005593.html ,
+https://mageia.org/pipermail/mageia-dev/2011-June/005560.html ). 
+
+But I guess I could have been a little bit smoother, sorry about that.
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005822.html b/zarb-ml/mageia-dev/2011-June/005822.html new file mode 100644 index 000000000..f9f0653f3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005822.html @@ -0,0 +1,121 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ Michael Scherer + misc at zarb.org +
+ Sat Jun 18 15:59:33 CEST 2011 +

+
+ +
Le samedi 18 juin 2011 à 13:42 +0200, Maarten Vanraes a écrit :
+> Op zaterdag 18 juni 2011 13:35:34 schreef Samuel Verschelde:
+> > Le samedi 18 juin 2011 13:19:16, Michael Scherer a écrit :
+> > > Le samedi 18 juin 2011 à 12:12 +0200, lebarhon a écrit :
+> > > 
+> > > 1) can you please avoid posting as html to the list ?
+> > > 
+> > > 2) if you wish to serve as a human gateway really between forum and ml
+> > > ( which I didn't ask, I am smart enough to read forum by myself, as I
+> > > helped install them among others ),
+> > > can you at least be smart and forward only on topic discussion ?
+> > 
+> > Misc, I agree with the main idea (html and forward only on topic messages),
+> > but not with the way you say it, a bit sharp. By the way, you didn't ask
+> > for this "gateway", but it is, at least a good intention, and personnally
+> > I think it is useful to forward what users say about it in the forum. You
+> > read them, but several people here recognized they don't want to or can't
+> > read the forums.
+> > 
+> > Samuel
+> 
+> i agree, i don't read the forums, i have no problem with people relaying this 
+> on this subject, even though i feel that if they want to say something they 
+> should talk here...
+> 
+> but, misc, iirc, you said that if someone wanted to capture the forums 
+> reactions and take responsibility of being a bridge, they could.
+
+What I said was "gather feedback for their own group", in the first mail
+of this thread. I guess I was not explicit enough, what would be useful
+is a summary. 
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005823.html b/zarb-ml/mageia-dev/2011-June/005823.html new file mode 100644 index 000000000..a2bbfc2e4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005823.html @@ -0,0 +1,119 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Sat Jun 18 16:40:34 CEST 2011 +

+
+ +
Op zaterdag 18 juni 2011 15:59:33 schreef Michael Scherer:
+> Le samedi 18 juin 2011 à 13:42 +0200, Maarten Vanraes a écrit :
+> > Op zaterdag 18 juni 2011 13:35:34 schreef Samuel Verschelde:
+> > > Le samedi 18 juin 2011 13:19:16, Michael Scherer a écrit :
+> > > > Le samedi 18 juin 2011 à 12:12 +0200, lebarhon a écrit :
+> > > > 
+> > > > 1) can you please avoid posting as html to the list ?
+> > > > 
+> > > > 2) if you wish to serve as a human gateway really between forum and
+> > > > ml ( which I didn't ask, I am smart enough to read forum by myself,
+> > > > as I helped install them among others ),
+> > > > can you at least be smart and forward only on topic discussion ?
+> > > 
+> > > Misc, I agree with the main idea (html and forward only on topic
+> > > messages), but not with the way you say it, a bit sharp. By the way,
+> > > you didn't ask for this "gateway", but it is, at least a good
+> > > intention, and personnally I think it is useful to forward what users
+> > > say about it in the forum. You read them, but several people here
+> > > recognized they don't want to or can't read the forums.
+> > > 
+> > > Samuel
+> > 
+> > i agree, i don't read the forums, i have no problem with people relaying
+> > this on this subject, even though i feel that if they want to say
+> > something they should talk here...
+> > 
+> > but, misc, iirc, you said that if someone wanted to capture the forums
+> > reactions and take responsibility of being a bridge, they could.
+> 
+> What I said was "gather feedback for their own group", in the first mail
+> of this thread. I guess I was not explicit enough, what would be useful
+> is a summary.
+
+ah yes, that would be easier.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005824.html b/zarb-ml/mageia-dev/2011-June/005824.html new file mode 100644 index 000000000..011cc2482 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005824.html @@ -0,0 +1,221 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Michael Scherer + misc at zarb.org +
+ Sat Jun 18 18:51:46 CEST 2011 +

+
+ +
Le samedi 18 juin 2011 à 03:38 -0400, andre999 a écrit :
+> Michael Scherer a écrit :
+> 
+> > Proposal 1:
+> > 6 months release cycle ->  12 months life cycle
+> > ( Fedora, Ubuntu, Mandriva<  2010.1&&  Mandriva != 2006.0 )
+> >
+> > Proposal 2:
+> > 9 months release cycle ->  18 months life cycle
+> > ( ~ opensuse and the one we used for Mageia 1 )
+> >
+> > Proposal 3:
+> > 12 months release cycle ->  24 months life cycle
+> > ( Mandriva>  2010.1 )
+> 
+> 
+> First, suggest an amended freeze process (idea from recent report of another project)
+
+you can say the name of the project, even if I suspect it to be Fedora.
+
+> Instead of a freeze on cauldron until everything is ready for the release, we do
+> 1) short freeze on cauldron
+> 2) copy cauldron to pre-release branch, which remains frozen until release
+> 3) immediately unfreeze cauldron.
+> 
+> - we avoid blocking cauldron, while leaving pre-release frozen for bug fixes.
+> - updates can continue on cauldron.  Bugfixes can be applied to newer versions, if present in 
+> cauldron, at the same time as corresponding bugfixes in pre-release.
+> - activities like translation can continue in cauldron, meaning less rush for such updates.
+> - because cauldron is open to changes (virtually) all the time, they don't have to be put off and 
+> perhaps forgotten.
+> - the cauldron cycle is extented by the time of the pre-release freeze.  e.g. In a release cycle of 
+> 6 months and a pre-release freeze of 1 month, the cauldron cycle would be 7 months.
+> This allows more time to iron out the pre-release bugs and more time for cauldron.
+> - with the longer pre-release freeze, it may be appropriate to modify somewhat the policy on what 
+> is accepted during freeze.  (Certain more recent packages or translations, for example.)
+> - note that we would still have to monitor cauldron to avoid freezing partially implemented complex 
+> changes, such as a major update of kde or gnome or perl, etc.  But we have to do that now, anyway.
+
+So you suggest that in order to help packagers focusing on bug fixing,
+that we have them take care of cauldron and the bugfixes for the stable
+release ( ie, twice more the load ).
+
+> 
+> > Proposal 1 :
+> > ---------------
+> My personal preference
+> 
+> > Pros:
+> > - better hardware support
+> > - up to date versions / upstream projects (must have for developers)
+> - coincides with kde/gnome releases
+>
+> - amended freeze process (outlined above) would lengthen both pre-release freeze time and cauldron 
+> development time.
+> A 1-month pre-release freeze would add 1 month to cauldron development time.
+> This would tend to alleviate the rush of the 6-month release cycle.
+
+Let's do some math, shall we ?
+
+If people work the same amount of time, with work divided on 2 products,
+they must share their time, and usually work less than if they focused
+only on one product, unless there is twice the ressources. But I doubt
+this will happen for us, so let's assume that ressources are fixed. 
+
+Let say : 
+- the freeze period is Y weeks, 
+- the time between 2 release is X weeks, 
+- people divide their time evenly on both products. 
+
+That's a simplification, but I will come back on that later. Let's also
+count the time spent as the metrics for the work, even if man/month is a
+wrong unit in software development ( but that's a good enough
+approximation for our case, given the highly distributed and
+decentralized nature of the work of releasing a distribution ).
+
+So when there is the freeze ( at release(n) time - Y weeks ), we will
+have Y weeks of work done on both products ( next release, and cauldron
+), so Y/2 weeks on each. We have X -Y weeks once the release(n) is out
+( before the next freeze for release(n+1) ), and then again Y/2 weeks.
+
+So for the release (n+1), we spend : 
+Y/2 + X - Y + Y/2 
+= 2 * Y/2 - Y + X  
+= Y - Y + X
+= X
+
+So that give X weeks of work. Fascinating, isn't it ?
+Now, of course, we can say "what if people do not divide their work in
+2 ?" 
+
+So let's call :
+- F the time spent on bugfix during the freeze
+- C the time spent on cauldron during the freeze
+
+We can assume that :
+C + F = Y 
+
+So the equation become :
+C + ( X - Y ) + F 
+= C + F - Y + X 
+= X 
+
+So no matter how you divide the time, you still have the same amount of
+time spent overall. 
+
+Now, the real important question is "can we really exchange work done as
+part of C for work done as part of F". 
+
+And so "if I do regular packages updates on cauldron at the begining of
+the cycle, does it count as bugfixing for the release in the end of the
+cycle" ? 
+
+To me, the answer is clearly no. If it was somethig we could exchange,
+we would not have to make a freeze in the first place to make sure that
+only bugfixes are uploaded in cauldron.
+
+So the only way to maximize the time spent on bugfixes is to have F = Y,
+and so C = 0. Ie, do like we do now.
+
+And unless you show that letting people work on cauldron will bring more
+ressources , and more than the one we will lose du to people who do not
+want to work on bugfixes and the release, I doubt this will change.
+
+> > - short life cycle
+> would be alleviated by having periodic long term support releases (lasting at least 2 years).
+
+As said before, the support is decided in another discussion, and depend
+more on the ressources we will have than anything else. 
+
+> 
+> > Proposal 2
+> > ----------------
+
+> > Cons:
+> > - not synchronized with gnome or others that use a 6 month cycle
+> > - potentially release when there isn't much activity (like during Holidays)
+> - release would not be the same month every year
+> e.g. 2011 june ; 2012 mar ; 2012 dec ; 2013 sep ; 2014 june ...
+> so users won't know when to expect a release
+
+I do not expect our users to be farm animals, so they can perfectly cope
+with lack of seasonal hints regarding release cycle. 
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005825.html b/zarb-ml/mageia-dev/2011-June/005825.html new file mode 100644 index 000000000..03df48709 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005825.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Sat Jun 18 22:25:13 CEST 2011 +

+
+ +
On 15 June 2011 22:32, Stew Benedict <stewbintn at gmail.com> wrote:
+> On 06/15/2011 09:22 AM, Stew Benedict wrote:
+>>
+>> On 06/15/2011 08:50 AM, Dexter Morgan wrote:
+>>>
+>>> On Wed, Jun 15, 2011 at 2:20 PM, Thomas Backlund<tmb at mageia.org>  wrote:
+>>>>
+>>>> BTW, should we have a read-only security/update-announce ml that where
+>>>> we
+>>>> mail about all updates ?
+>>>>
+>>> yes seems a must have to push updates descriptions , distributions
+>>> affected, ...
+>>>
+>> That is accounted for in the policy document (last line)
+>>
+> Due to the unbridled enthusiasm for getting started on updates, we now have
+> 4 trial packages :)
+>
+> vde2, mysql, curl, subversion
+>
+> Bugs:
+>
+> https://bugs.mageia.org/show_bug.cgi?id=1678 (vde2)
+> https://bugs.mageia.org/show_bug.cgi?id=1554 (mysql)
+> https://bugs.mageia.org/show_bug.cgi?id=1813 (curl)
+> https://bugs.mageia.org/show_bug.cgi?id=1521 (subversion)
+>
+> Packages need fixes applied, built for mga1 (I believe mysql is already in
+> updates_testing), packager should do some initial testing then re-assign the
+> bug to QA
+>
+> QA process for updates:
+>
+> http://mageia.org/wiki/doku.php?id=qa_updates
+>
+>
+>
+> --
+> Stew Benedict
+>
+>
+>
+
+qa-bugs@ can't be be set as the assignee in bug reports, it should be
+made possible.
+
+The same for sec team, there should be a way to assign/put-in-CC.
+
+-- 
+Ahmad Samir
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005826.html b/zarb-ml/mageia-dev/2011-June/005826.html new file mode 100644 index 000000000..b2dad2c89 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005826.html @@ -0,0 +1,64 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process) + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process)

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Sat Jun 18 22:29:48 CEST 2011 +

+
+ +
So, is there a consensus about this yet? (note that the backports list
+of packages keeps growing in the mean time :)).
+
+-- 
+Ahmad Samir
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005827.html b/zarb-ml/mageia-dev/2011-June/005827.html new file mode 100644 index 000000000..9005e67d5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005827.html @@ -0,0 +1,83 @@ + + + + [Mageia-dev] "Job offer" : mentoring program coordinator + + + + + + + + + +

[Mageia-dev] "Job offer" : mentoring program coordinator

+ magnus + magnus.mud at googlemail.com +
+ Sat Jun 18 22:41:21 CEST 2011 +

+
+ +
Congratulation andre999 for the job from me too.
+
+I think we will grow together to a good three-man band.
+
+The team gets the success.
+For the work and the trouble the mentoring program coordinator is responsible
+:-)
+
+
+Magnus
+
+
+
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110618/f56211be/attachment.html>
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005828.html b/zarb-ml/mageia-dev/2011-June/005828.html new file mode 100644 index 000000000..ca191c26c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005828.html @@ -0,0 +1,196 @@ + + + + [Mageia-dev] "Job offer" : mentoring program coordinator + + + + + + + + + +

[Mageia-dev] "Job offer" : mentoring program coordinator

+ andre999 + andr55 at laposte.net +
+ Sun Jun 19 00:21:58 CEST 2011 +

+
+ +
Samuel Verschelde a écrit :
+>
+> Le dimanche 12 juin 2011 15:27:59, Samuel Verschelde a écrit :
+>> Hello to everyone,
+>>
+>> ...
+>>
+>> During a packagers weekly meeting, misc invited us to read the following
+>> article about mentoring programs in open-source projects:
+>> http://blogs.gnome.org/bolsh/2011/05/31/effective-mentoring-programs/
+>>
+>> I invite those who haven't read it yet, to read it. I'll quote one of the
+>> mentoring best practices that were given: "In bigger projects, keeping
+>> track of who is a mentor, and who is mentoring who, and inviting new
+>> mentors, and ensuring that no-one falls through the cracks when a mentor
+>> gets too busy, is a job of itself."
+>>
+>> I'm looking for someone who could fill that "job".
+>>
+>> Description of the job:
+>>
+>> - keep track of:
+>> -- who's being mentored by who, how well it's going
+>> -- who needs a mentor and hasn't found one yet (this is one of the most
+>> important parts: no volunteer must be forgotten, volunteers are too
+>> precious !)
+>> -- who can mentor more apprentices (and sometimes convince packagers to
+>> become mentors or accept one more apprentice)
+>>
+>> - be available for questions from apprentices or mentors, by mail, and if
+>> possible, to be present on the IRC channel #mageia-mentoring on freenode
+>>
+>> - help mentors with gathering "junior tasks" (bugzilla is a never empty
+>> reserve that can be used for that. Maybe ask the bug triage team to help
+>> identify such tasks. Maybe a "junior task" keyword in bugzilla would do the
+>> trick)
+>> -- small bugs to fix
+>> -- new small packages to import in the distribution
+>> -- backports
+>>
+>> - promote mentoring (empower users into contributers. Working with the
+>> marketing team would be great I think):
+>> -- make the mentoring program known (MLs, forums, web, etc.)
+>> -- look for new apprentices
+>> -- look for new mentors
+>>
+>> Some useful skills:
+>> - be autonomous (ie no need to check that you're doing the work)
+>> - good written english (communication is very important in this job)
+>> - knowledge about packaging is a plus but not mandatory (the key aspects
+>> can be taught to you)
+>> - being or having been a mentor, or having been mentored would be a plus,
+>> but not mandatory
+>>
+>> More information about the job:
+>> - does not require a big amount of work, but real committment to the task
+>> and regularity
+>> - remember that you have a coordination role, not an authoritative role.
+>> The difference in that is that you're not here to give orders but to
+>> facilitate the mentoring program.
+>> - you don't have to be alone to do this job if it's too much for one
+>> person: you can find other helpful people wanting to help you if needed
+>> and rely on the other teams (but finding them *is* part of your job ;) ).
+>> -  this "job offer" concerns everything that revolves around the mentoring
+>> of new packagers, but if it's successful maybe other teams can follow the
+>> same approach (i18n, QA, etc... ).
+>> -  depending on your level of confidence, experience and will, you could be
+>> helped in your work. Maybe someone from the council can supervise and help
+>> you at least at the beginning; or, if no one steps up, I can help you
+>> bootstrap and organize your new "job".
+>>
+>> So, who's in?
+>>
+>> Samuel Verschelde
+>
+> Hello to all,
+>
+> First, thanks to those to offered to help.
+>
+> We had 3 candidates, plus one who offered help whoever will be in charge. 2
+> candidates were retained (Kharec has too many duties already to take the job),
+> who I interviewed on IRC to try to see who would fit best.
+>
+> The 2 candidates were good, which complicated my task because I had to make a
+> choice, but I finally came to a decision : I propose andre999 as a mentoring
+> program coordinator (or facilitator, if you think it fits the job better).
+>
+> What made me choose him over Daniel Kreuter (whose candidacy was good, I
+> repeat it) is the fact he already showed interest in this subject before the
+> "job offer", has been mentored (even if the mentoring has not been completed
+> for now), and I already had enough occasions to exchange with him in the past
+> to think that he will have the required communication skills and diplomacy to
+> do the job.
+>
+> Now, it doesn't mean he has to be alone, so I hope than magnus will help him,
+> for example to bring an IRC presence at hours where André is not available due
+> to his timezone, and if Daniel is still interested in helping for those tasks,
+> I'm sure André will be glad to receive his help.
+>
+> If you have any questions or remarks, don't hesitate to comment.
+>
+> To ennael and misc : do you want to take part in the boostrapping of André's
+> work ? I think it could be good to avoid any misunderstandings and be sure we
+> set the good direction.
+>
+> Best regards
+>
+> Samuel Verschelde
+
+Thanks for the vote of confidence. :)  I'll do everything to assure that it's not misplaced.
+
+I see the mentoring program coordinator as facilitating contributions to the key process of Mageia. 
+  To continue our progress in making Mageia one of the best distros available.
+(Packaging/development is the "nerf de la guerre", as we say in French.  Roughly translates as the 
+"heart of the war".)
+
+I would appreciate any help, particularly on IRC.
+(My availability on IRC is mostly when european contributors are asleep (or falling asleep, as 
+shikamaru can testify).
+
+And also any advice/guidance/insights from ennael & misc, of course.
+
+As an aside, I intend to complete my mentoring process so as to be able to eventually mentor those 
+in the North American time zones.
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005829.html b/zarb-ml/mageia-dev/2011-June/005829.html new file mode 100644 index 000000000..ee95d9bdd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005829.html @@ -0,0 +1,112 @@ + + + + [Mageia-dev] upgrade fontforge + + + + + + + + + +

[Mageia-dev] upgrade fontforge

+ Thomas Spuhler + thomas at btspuhler.com +
+ Sun Jun 19 02:30:53 CEST 2011 +

+
+ +
If nobody opposes I am going to upgrade fontforge to 201122. Lilypond requires 
+it.
+-- 
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005830.html b/zarb-ml/mageia-dev/2011-June/005830.html new file mode 100644 index 000000000..9724f1e66 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005830.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] "Job offer" : mentoring program coordinator + + + + + + + + + +

[Mageia-dev] "Job offer" : mentoring program coordinator

+ andre999 + andr55 at laposte.net +
+ Sun Jun 19 03:44:22 CEST 2011 +

+
+ +
Daniel Kreuter a écrit :
+> On Sat, Jun 18, 2011 at 2:55 PM, Samuel Verschelde <stormi at laposte.net
+> <mailto:stormi at laposte.net>> wrote:
+>
+>     Le dimanche 12 juin 2011 15:27:59, Samuel Verschelde a écrit :
+...
+>     The 2 candidates were good, which complicated my task because I had
+>     to make a
+>     choice, but I finally came to a decision : I propose andre999 as a
+>     mentoring
+>     program coordinator (or facilitator, if you think it fits the job
+>     better).
+...
+>
+>     Samuel Verschelde
+>
+> Congratulation andre999 for the job. If you need my help feel free to
+> ask me.
+
+Thanks Daniel.  As Magnus suggested, I think we could make a good team of three :)
+(With more welcome to join.)
+
+Particularly help with a presence on IRC, and any other input you would like to make.
+I'd like to make/refine and maintain a one-stop page in the wiki to coordinate the mentoring 
+process, so suggestions would be more than welcome.
+
+> --
+> Mit freundlichen Grüßen
+>
+> Greetings
+>
+> Daniel Kreuter
+
+-- 
+André
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005831.html b/zarb-ml/mageia-dev/2011-June/005831.html new file mode 100644 index 000000000..353ffeb60 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005831.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] "Job offer" : mentoring program coordinator + + + + + + + + + +

[Mageia-dev] "Job offer" : mentoring program coordinator

+ andre999 + andr55 at laposte.net +
+ Sun Jun 19 03:44:28 CEST 2011 +

+
+ +
magnus a écrit :
+>
+> Congratulation andre999 for the job from me too.
+>
+> I think we will grow together to a good three-man band.
+
+Thanks Magnus.  I think we could make a good team.
+
+> The team gets the success.
+> For the work and the trouble the mentoring program coordinator is
+> responsible :-)
+
+That's Ok.  If there are any problems, I don't mind being the scapegoat :)
+
+As I said to Daniel, presence on IRC would be particularly helpful, plus any other input you would 
+like to make.
+I'd like to make/refine and maintain a one-stop page in the wiki to coordinate the mentoring 
+process, so suggestions would be more than welcome.
+
+>
+> Magnus
+
+-- 
+André
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005832.html b/zarb-ml/mageia-dev/2011-June/005832.html new file mode 100644 index 000000000..efb139f74 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005832.html @@ -0,0 +1,283 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ andre999 + andr55 at laposte.net +
+ Sun Jun 19 05:49:22 CEST 2011 +

+
+ +
Michael Scherer a écrit :
+>
+> Le samedi 18 juin 2011 à 03:38 -0400, andre999 a écrit :
+>> Michael Scherer a écrit :
+>>
+>>> Proposal 1:
+>>> 6 months release cycle ->   12 months life cycle
+>>> ( Fedora, Ubuntu, Mandriva<   2010.1&&   Mandriva != 2006.0 )
+>>>
+>>> Proposal 2:
+>>> 9 months release cycle ->   18 months life cycle
+>>> ( ~ opensuse and the one we used for Mageia 1 )
+>>>
+>>> Proposal 3:
+>>> 12 months release cycle ->   24 months life cycle
+>>> ( Mandriva>   2010.1 )
+>>
+>>
+>> First, suggest an amended freeze process (idea from recent report of another project)
+>
+> you can say the name of the project, even if I suspect it to be Fedora.
+
+I suspected that it might have been Fedora, if it wasn't a summary of the new mozilla process, but 
+I couldn't remember.  Just the concept intrigued me.  Which I reflected on for a few weeks.
+
+>> Instead of a freeze on cauldron until everything is ready for the release, we do
+>> 1) short freeze on cauldron
+>> 2) copy cauldron to pre-release branch, which remains frozen until release
+>> 3) immediately unfreeze cauldron.
+>>
+>> - we avoid blocking cauldron, while leaving pre-release frozen for bug fixes.
+>> - updates can continue on cauldron.  Bugfixes can be applied to newer versions, if present in
+>> cauldron, at the same time as corresponding bugfixes in pre-release.
+>> - activities like translation can continue in cauldron, meaning less rush for such updates.
+>> - because cauldron is open to changes (virtually) all the time, they don't have to be put off and
+>> perhaps forgotten.
+>> - the cauldron cycle is extented by the time of the pre-release freeze.  e.g. In a release cycle of
+>> 6 months and a pre-release freeze of 1 month, the cauldron cycle would be 7 months.
+>> This allows more time to iron out the pre-release bugs and more time for cauldron.
+>> - with the longer pre-release freeze, it may be appropriate to modify somewhat the policy on what
+>> is accepted during freeze.  (Certain more recent packages or translations, for example.)
+>> - note that we would still have to monitor cauldron to avoid freezing partially implemented complex
+>> changes, such as a major update of kde or gnome or perl, etc.  But we have to do that now, anyway.
+>
+> So you suggest that in order to help packagers focusing on bug fixing,
+> that we have them take care of cauldron and the bugfixes for the stable
+> release ( ie, twice more the load ).
+
+I wouldn't quite put it that way ...
+
+>>> Proposal 1 :
+>>> ---------------
+>> My personal preference
+>>
+>>> Pros:
+>>> - better hardware support
+>>> - up to date versions / upstream projects (must have for developers)
+>> - coincides with kde/gnome releases
+>>
+>> - amended freeze process (outlined above) would lengthen both pre-release freeze time and cauldron
+>> development time.
+>> A 1-month pre-release freeze would add 1 month to cauldron development time.
+>> This would tend to alleviate the rush of the 6-month release cycle.
+>
+> Let's do some math, shall we ?
+
+great :)
+
+> If people work the same amount of time, with work divided on 2 products,
+> they must share their time, and usually work less than if they focused
+> only on one product, unless there is twice the ressources. But I doubt
+> this will happen for us, so let's assume that ressources are fixed.
+
+That was my assumption : resources fixed in terms of time spent.
+And why would that divide a contributor's focus more than now ?  They would just have a choice.
+Now during the freeze, someone that wants to contribute to cauldron, but can't or chooses not to 
+contribute to pre-release bugfix, is not contributing.
+So in practice, we risk to have more time contributed during the freeze.
+
+> Let say :
+> - the freeze period is Y weeks,
+> - the time between 2 release is X weeks,
+> - people divide their time evenly on both products.
+
+That wasn't assumed.  Rather that as much time would be spent on bug fixes, etc. in pre-release. 
+But having a longer freeze period would likely result in better quality, and certainly less rush.
+
+> That's a simplification, but I will come back on that later. Let's also
+> count the time spent as the metrics for the work, even if man/month is a
+> wrong unit in software development ( but that's a good enough
+> approximation for our case, given the highly distributed and
+> decentralized nature of the work of releasing a distribution ).
+>
+> So when there is the freeze ( at release(n) time - Y weeks ), we will
+> have Y weeks of work done on both products ( next release, and cauldron
+> ), so Y/2 weeks on each. We have X -Y weeks once the release(n) is out
+> ( before the next freeze for release(n+1) ), and then again Y/2 weeks.
+>
+> So for the release (n+1), we spend :
+> Y/2 + X - Y + Y/2
+> = 2 * Y/2 - Y + X
+> = Y - Y + X
+> = X
+>
+> So that give X weeks of work. Fascinating, isn't it ?
+
+Not really.  Being my basic assumption :)
+
+> Now, of course, we can say "what if people do not divide their work in
+> 2 ?"
+>
+> So let's call :
+> - F the time spent on bugfix during the freeze
+> - C the time spent on cauldron during the freeze
+>
+> We can assume that :
+> C + F = Y
+>
+> So the equation become :
+> C + ( X - Y ) + F
+> = C + F - Y + X
+> = X
+>
+> So no matter how you divide the time, you still have the same amount of
+> time spent overall.
+
+As I assumed :)
+
+> Now, the real important question is "can we really exchange work done as
+> part of C for work done as part of F".
+>
+> And so "if I do regular packages updates on cauldron at the begining of
+> the cycle, does it count as bugfixing for the release in the end of the
+> cycle" ?
+>
+> To me, the answer is clearly no. If it was somethig we could exchange,
+> we would not have to make a freeze in the first place to make sure that
+> only bugfixes are uploaded in cauldron.
+>
+> So the only way to maximize the time spent on bugfixes is to have F = Y,
+> and so C = 0. Ie, do like we do now.
+
+I really don't follow this line of reasoning.
+The focus on bug fixes starts with the freeze.  So a longer freeze would give more time to focus on 
+bug fixes.
+Sure, there are updates and bug fixes in cauldron before the freeze, as a normal part of any 
+development process.  (Even in the non-libre world.)
+
+> And unless you show that letting people work on cauldron will bring more
+> ressources , and more than the one we will lose du to people who do not
+> want to work on bugfixes and the release, I doubt this will change.
+
+Ok.  Obviously I need to clarify my point of view.
+Firstly, my assumption was that at least as much time would be spent on bug fixing during the 
+longer freeze, but being less rushed, would tend to produce better quality results.  (And less 
+aggravation for ennael)  (That is certainly how it works in the non-libre world.)
+
+I don't see how having the choice between contributing to pre-release or cauldron during the freeze 
+will lead to us loosing _any_ contributors.
+
+As well, since cauldron would be out of freeze virtually all the time, there would be (virtually) 
+no period where contributions to cauldron are blocked.
+Packager time is not an ubiquitous resource.  Some packagers are perl experts, other python, etc. 
+Each packager is more familiar with some packages than others.  Some packagers are excellent 
+developers; others are challenged by basic scripts.  There is a wide range of skills and interests.
+
+If during freeze, a packager has a choice between attempting to help with a bugfix in pre-release 
+for a package with which s/he is not familiar, or contributing to cauldron for something with which 
+s/he is familiar, it would be evidently more efficient to contribute to cauldron.
+
+Similarly, if a packager contributes a bug fix to pre-release, and a newer package already exists 
+in cauldron for which the same bug fix must be applied, it is more efficient to apply the same 
+patch right away, than to wait until freeze is over.  (Personnally I've encountered this sort of 
+situation with similar but different software many times.  Any experienced programmer should 
+understand this point.)
+
+So there are a lot of (admittedly small) synergies which should lead to packager time being more 
+efficiently used.
+Not counting the likelyhood that some packagers would contribute somewhat more time, being able to 
+contribute to cauldron during freeze.
+The major benefit in my mind is the longer freeze period.
+
+How much this would help, I don't know.  But I think it is worth a try.
+(Even if we end up going for a 9-month release cycle, instead of my preferred 6 months.)
+
+>
+>>> - short life cycle
+>> would be alleviated by having periodic long term support releases (lasting at least 2 years).
+>
+> As said before, the support is decided in another discussion, and depend
+> more on the ressources we will have than anything else.
+
+ok :)
+
+>>> Proposal 2
+>>> ----------------
+>
+>>> Cons:
+>>> - not synchronized with gnome or others that use a 6 month cycle
+>>> - potentially release when there isn't much activity (like during Holidays)
+>> - release would not be the same month every year
+>> e.g. 2011 june ; 2012 mar ; 2012 dec ; 2013 sep ; 2014 june ...
+>> so users won't know when to expect a release
+>
+> I do not expect our users to be farm animals, so they can perfectly cope
+> with lack of seasonal hints regarding release cycle.
+
+We may not be farm animals, but I suspect that we are still creatures of habit :)
+In any case, it seems to me that the bigger liability would be being out of sync with the 6-month 
+release cycle of kde, gnome, as well as many other distros.
+
+another 2 cents :)
+
+-- 
+André
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005833.html b/zarb-ml/mageia-dev/2011-June/005833.html new file mode 100644 index 000000000..6c9598490 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005833.html @@ -0,0 +1,132 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ andre999 + andr55 at laposte.net +
+ Sun Jun 19 06:30:20 CEST 2011 +

+
+ +
Ahmad Samir a écrit :
+>
+> On 10 June 2011 13:44, Wolfgang Bornath<molch.b at googlemail.com>  wrote:
+>> 2011/6/10 Michael Scherer<misc at zarb.org>:
+>>>
+>>> We have used backports in the past for that, and I see no reason to
+>>> change that.
+>>>
+>>> If the problem is that backports were too buggy in the past, then we
+>>> should fix backports process, not bypassing them.
+>>>
+>>> And if we start by pushing new version in update, people will soon
+>>> wonder why the new version of X is in updates, while the new version of
+>>> Y is not, just because we didn't have X in release and Y was there.
+>>
+>> Problem I see:
+>> So far (in Mandriva), example:  we have used 2010.0/main/backports to
+>> offer new versions of software which had an older version in 2010/main
+>> but the newer version in 2010.1/main, or as the name says: backporting
+>> a newer version of a software from the current release to a previous
+>> release, as often used for Firefox.
+>
+> Firefox should always go to /updates, not backports, usually it has
+> many sec fixed, so firefox and thunderbird are special cases.
+
+I agree.
+And the same for other software which almost always has security fixes.
+(Of course we should enumerate these exceptions.)
+
+>> For Mageia it means, /backports should hold backports of software
+>> which has an older version in 1/core but a newer version in cauldron.
+>> If we put new software (aka missing packages) in /backports and the
+>> user activates /backports he also runs the risk that existing packages
+>> of his stable installation will be replaced by real backports of newer
+>> versions, backported from Cauldron - which he may not want to do.
+>
+> Then he shouldn't use backports; but the point is if a totally new
+> package, to Mageia 1, that never existed in core, is in backports, the
+> user shouldn't see any regression with regard to that package as his
+> experience with it before using backports is null, it didn't exist.
+
+We should expect that users _selectively_ install from backports.
+That should be documented somewhere for users (if not already).
+It seems almost a case for never activating the backport repositories -- considering that backports 
+can be selected without those repositories activated.
+
+>> I wonder why we do not put these "missing packages" in /testing and
+>> after a while in /core or /non-free or /tainted (wherever they
+>> belong). These packages are software which were supposed to be in
+>> /core or /non-free or /tainted, they were just forgotten|came too
+>> late|whatever for Mageia 1 release freeze.
+>
+> There will always be late packages, always. One example is a new
+> version of foo that was released two days before Mageia's release, it
+> won't be submitted through freeze, but will go to backports.
+>
+> IMHO, backports is way to offer "late" packages to user, whether
+> they're new packages or newer versions of packages in
+> core/nonfree/tainted, instead of the user installing them from 3rd
+> party repos or having to build them himself (not all users are savvy
+> with [re]building src.rpm's).
+
+It's usually not strictly necessary to rebuild the rpm's, but it is certainly much nicer to install 
+rpm's built for Mageia.  Especially for less advanced users.
+And backports is where to put "late" packages.
+
+>> --
+>> wobo
+>>
+>
+>
+
+-- 
+André
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005834.html b/zarb-ml/mageia-dev/2011-June/005834.html new file mode 100644 index 000000000..3c9b1958a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005834.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ lebarhon + lebarhon at free.fr +
+ Sun Jun 19 09:51:02 CEST 2011 +

+
+ +
Le 18/06/2011 13:19, Michael Scherer a écrit :
+> Le samedi 18 juin 2011 à 12:12 +0200, lebarhon a écrit :
+>
+> 1) can you please avoid posting as html to the list ?
+>
+> 2) if you wish to serve as a human gateway really between forum and ml
+> ( which I didn't ask, I am smart enough to read forum by myself, as I
+> helped install them among others ),
+> can you at least be smart and forward only on topic discussion ?
+>
+It was asked by the webteam, so you have to come yourselves to an agreement.
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005835.html b/zarb-ml/mageia-dev/2011-June/005835.html new file mode 100644 index 000000000..85828bd26 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005835.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Sun Jun 19 10:28:11 CEST 2011 +

+
+ +
2011/6/19 lebarhon <lebarhon at free.fr>:
+> Le 18/06/2011 13:19, Michael Scherer a écrit :
+>>
+>> Le samedi 18 juin 2011 à 12:12 +0200, lebarhon a écrit :
+>>
+>> 1) can you please avoid posting as html to the list ?
+>>
+>> 2) if you wish to serve as a human gateway really between forum and ml
+>> ( which I didn't ask, I am smart enough to read forum by myself, as I
+>> helped install them among others ),
+>> can you at least be smart and forward only on topic discussion ?
+>>
+> It was asked by the webteam, so you have to come yourselves to an agreement.
+
+Nobody said anything against your efforts although I don't see any
+reason there (and I haven't seen any discussion in the webteam where
+it was decided to do so), people who read mailing lists are able to
+read forums as well - if they don't want to, that's their decision.
+
+But referring to the issue here I am pretty sure that nobody asked you
+to write in HTML nor to transfer the off-topic banter. I wonder why
+this has to be discussed, it's a matter of course.
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005836.html b/zarb-ml/mageia-dev/2011-June/005836.html new file mode 100644 index 000000000..0d7ca670d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005836.html @@ -0,0 +1,127 @@ + + + + [Mageia-dev] "Job offer" : mentoring program coordinator + + + + + + + + + +

[Mageia-dev] "Job offer" : mentoring program coordinator

+ Daniel Kreuter + daniel.kreuter85 at googlemail.com +
+ Sun Jun 19 11:20:28 CEST 2011 +

+
+ +
On Sun, Jun 19, 2011 at 3:44 AM, andre999 <andr55 at laposte.net> wrote:
+
+> Daniel Kreuter a écrit :
+>
+>> On Sat, Jun 18, 2011 at 2:55 PM, Samuel Verschelde <stormi at laposte.net
+>> <mailto:stormi at laposte.net>> wrote:
+>>
+>>    Le dimanche 12 juin 2011 15:27:59, Samuel Verschelde a écrit :
+>>
+> ...
+>
+>     The 2 candidates were good, which complicated my task because I had
+>>    to make a
+>>    choice, but I finally came to a decision : I propose andre999 as a
+>>    mentoring
+>>    program coordinator (or facilitator, if you think it fits the job
+>>    better).
+>>
+> ...
+>
+>
+>>    Samuel Verschelde
+>>
+>> Congratulation andre999 for the job. If you need my help feel free to
+>> ask me.
+>>
+>
+> Thanks Daniel.  As Magnus suggested, I think we could make a good team of
+> three :)
+> (With more welcome to join.)
+>
+> Particularly help with a presence on IRC, and any other input you would
+> like to make.
+> I'd like to make/refine and maintain a one-stop page in the wiki to
+> coordinate the mentoring process, so suggestions would be more than welcome.
+>
+>  --
+>>
+>> Mit freundlichen Grüßen
+>>
+>> Greetings
+>>
+>> Daniel Kreuter
+>>
+>
+> --
+> André
+>
+
+Thanks for the offer André. One suggestion would be to have a page on wiki
+where newcomers can put their name on if they seek for a mentor. But this
+can wait until the new wiki is online i think. As for now i only found a
+page where we can see our mentors and their apprentices, but no table of
+people who wait for a mentor.
+
+-- 
+Mit freundlichen Grüßen
+
+Greetings
+
+Daniel Kreuter
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110619/a6bd1e24/attachment-0001.html>
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005837.html b/zarb-ml/mageia-dev/2011-June/005837.html new file mode 100644 index 000000000..f9b21ceb9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005837.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] "Job offer" : mentoring program coordinator + + + + + + + + + +

[Mageia-dev] "Job offer" : mentoring program coordinator

+ magnus + magnus.mud at googlemail.com +
+ Sun Jun 19 11:39:43 CEST 2011 +

+
+ +
2011/6/19 Daniel Kreuter <daniel.kreuter85 at googlemail.com>
+
+> One suggestion would be to have a page on wiki where newcomers can put
+> their name on if they seek for a mentor.
+>
+I think a good way to start. Perhaps we can help, especially if a newcomer
+ask a mailing list.
+Ask her/him for his skills and preferences and give her/him some Mageia
+links for mentoring and packaging.
+And then put it into the wiki.
+So Mageia shows a fast response.
+
+
+> But this can wait until the new wiki is online i think.
+>
+ok
+
+
+Magnus
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110619/1b78a170/attachment.html>
+
+ + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005838.html b/zarb-ml/mageia-dev/2011-June/005838.html new file mode 100644 index 000000000..66708f615 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005838.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] "Job offer" : mentoring program coordinator + + + + + + + + + +

[Mageia-dev] "Job offer" : mentoring program coordinator

+ andre999 + andr55 at laposte.net +
+ Sun Jun 19 11:52:32 CEST 2011 +

+
+ +
Daniel Kreuter a écrit :
+>
+> Thanks for the offer André. One suggestion would be to have a page on
+> wiki where newcomers can put their name on if they seek for a mentor.
+> But this can wait until the new wiki is online i think. As for now i
+> only found a page where we can see our mentors and their apprentices,
+> but no table of people who wait for a mentor.
+>
+> --
+> Mit freundlichen Grüßen
+>
+> Greetings
+>
+> Daniel Kreuter
+
+Thanks for the suggestion Daniel.
+I've been looking at the packages_mentoring page (which you referred to above), and was thinking of 
+adding a "So you want to be a Mageia packager" section just before the section listing the mentors.
+With a place to insert their name.
+
+But it might be a better idea to have a separate page for that, with a link to the 
+packages_mentoring page.  Have to think about that.
+It is probably better to reflect a bit before making changes -- no sense in confusing people every 
+time we change our minds.  But I'm not sure that we should necessarily wait for the new wiki.
+
+Regards
+-- 
+André
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005839.html b/zarb-ml/mageia-dev/2011-June/005839.html new file mode 100644 index 000000000..89d7068e2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005839.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] "Job offer" : mentoring program coordinator + + + + + + + + + +

[Mageia-dev] "Job offer" : mentoring program coordinator

+ andre999 + andr55 at laposte.net +
+ Sun Jun 19 12:03:50 CEST 2011 +

+
+ +
magnus a écrit :
+>
+>
+> 2011/6/19 Daniel Kreuter <daniel.kreuter85 at googlemail.com
+> <mailto:daniel.kreuter85 at googlemail.com>>
+>
+>     One suggestion would be to have a page on wiki where newcomers can
+>     put their name on if they seek for a mentor.
+>
+> I think a good way to start. Perhaps we can help, especially if a
+> newcomer ask a mailing list.
+> Ask her/him for his skills and preferences and give her/him some Mageia
+> links for mentoring and packaging.
+> And then put it into the wiki.
+> So Mageia shows a fast response.
+
+Good idea.  Would apply to forums, too.  And IRC.
+
+>     But this can wait until the new wiki is online i think.
+>
+> ok
+>
+> Magnus
+
+We could also give a contact email address for those that wish to become packagers.
+Since many new to Mageia might not be familiar with editing a wiki to insert their name, but at the 
+same time have skills useful for packagers.  (Like previous packaging experience, programming 
+experience, or even just a strong interest in packaging certain applications.)
+
+-- 
+André
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005840.html b/zarb-ml/mageia-dev/2011-June/005840.html new file mode 100644 index 000000000..496f30c1c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005840.html @@ -0,0 +1,290 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ andre999 + andr55 at laposte.net +
+ Sun Jun 19 12:40:29 CEST 2011 +

+
+ +
andre999 a écrit :
+> Michael Scherer a écrit :
+>>
+>> Le samedi 18 juin 2011 à 03:38 -0400, andre999 a écrit :
+>>> Michael Scherer a écrit :
+>>>
+>>>> Proposal 1:
+>>>> 6 months release cycle -> 12 months life cycle
+>>>> ( Fedora, Ubuntu, Mandriva< 2010.1&& Mandriva != 2006.0 )
+>>>>
+>>>> Proposal 2:
+>>>> 9 months release cycle -> 18 months life cycle
+>>>> ( ~ opensuse and the one we used for Mageia 1 )
+>>>>
+>>>> Proposal 3:
+>>>> 12 months release cycle -> 24 months life cycle
+>>>> ( Mandriva> 2010.1 )
+>>>
+>>>
+>>> First, suggest an amended freeze process (idea from recent report of
+>>> another project)
+>>
+>> you can say the name of the project, even if I suspect it to be Fedora.
+>
+> I suspected that it might have been Fedora, if it wasn't a summary of
+> the new mozilla process, but I couldn't remember. Just the concept
+> intrigued me. Which I reflected on for a few weeks.
+>
+>>> Instead of a freeze on cauldron until everything is ready for the
+>>> release, we do
+>>> 1) short freeze on cauldron
+>>> 2) copy cauldron to pre-release branch, which remains frozen until
+>>> release
+>>> 3) immediately unfreeze cauldron.
+>>>
+>>> - we avoid blocking cauldron, while leaving pre-release frozen for
+>>> bug fixes.
+>>> - updates can continue on cauldron. Bugfixes can be applied to newer
+>>> versions, if present in
+>>> cauldron, at the same time as corresponding bugfixes in pre-release.
+>>> - activities like translation can continue in cauldron, meaning less
+>>> rush for such updates.
+>>> - because cauldron is open to changes (virtually) all the time, they
+>>> don't have to be put off and
+>>> perhaps forgotten.
+>>> - the cauldron cycle is extented by the time of the pre-release
+>>> freeze. e.g. In a release cycle of
+>>> 6 months and a pre-release freeze of 1 month, the cauldron cycle
+>>> would be 7 months.
+>>> This allows more time to iron out the pre-release bugs and more time
+>>> for cauldron.
+>>> - with the longer pre-release freeze, it may be appropriate to modify
+>>> somewhat the policy on what
+>>> is accepted during freeze. (Certain more recent packages or
+>>> translations, for example.)
+>>> - note that we would still have to monitor cauldron to avoid freezing
+>>> partially implemented complex
+>>> changes, such as a major update of kde or gnome or perl, etc. But we
+>>> have to do that now, anyway.
+>>
+>> So you suggest that in order to help packagers focusing on bug fixing,
+>> that we have them take care of cauldron and the bugfixes for the stable
+>> release ( ie, twice more the load ).
+>
+> I wouldn't quite put it that way ...
+>
+>>>> Proposal 1 :
+>>>> ---------------
+>>> My personal preference
+>>>
+>>>> Pros:
+>>>> - better hardware support
+>>>> - up to date versions / upstream projects (must have for developers)
+>>> - coincides with kde/gnome releases
+>>>
+>>> - amended freeze process (outlined above) would lengthen both
+>>> pre-release freeze time and cauldron
+>>> development time.
+>>> A 1-month pre-release freeze would add 1 month to cauldron
+>>> development time.
+>>> This would tend to alleviate the rush of the 6-month release cycle.
+>>
+>> Let's do some math, shall we ?
+>
+> great :)
+>
+>> If people work the same amount of time, with work divided on 2 products,
+>> they must share their time, and usually work less than if they focused
+>> only on one product, unless there is twice the ressources. But I doubt
+>> this will happen for us, so let's assume that ressources are fixed.
+>
+> That was my assumption : resources fixed in terms of time spent.
+> And why would that divide a contributor's focus more than now ? They
+> would just have a choice.
+> Now during the freeze, someone that wants to contribute to cauldron, but
+> can't or chooses not to contribute to pre-release bugfix, is not
+> contributing.
+> So in practice, we risk to have more time contributed during the freeze.
+>
+>> Let say :
+>> - the freeze period is Y weeks,
+>> - the time between 2 release is X weeks,
+>> - people divide their time evenly on both products.
+>
+> That wasn't assumed. Rather that as much time would be spent on bug
+> fixes, etc. in pre-release. But having a longer freeze period would
+> likely result in better quality, and certainly less rush.
+>
+>> That's a simplification, but I will come back on that later. Let's also
+>> count the time spent as the metrics for the work, even if man/month is a
+>> wrong unit in software development ( but that's a good enough
+>> approximation for our case, given the highly distributed and
+>> decentralized nature of the work of releasing a distribution ).
+>>
+>> So when there is the freeze ( at release(n) time - Y weeks ), we will
+>> have Y weeks of work done on both products ( next release, and cauldron
+>> ), so Y/2 weeks on each. We have X -Y weeks once the release(n) is out
+>> ( before the next freeze for release(n+1) ), and then again Y/2 weeks.
+>>
+>> So for the release (n+1), we spend :
+>> Y/2 + X - Y + Y/2
+>> = 2 * Y/2 - Y + X
+>> = Y - Y + X
+>> = X
+>>
+>> So that give X weeks of work. Fascinating, isn't it ?
+>
+> Not really. Being my basic assumption :)
+>
+>> Now, of course, we can say "what if people do not divide their work in
+>> 2 ?"
+>>
+>> So let's call :
+>> - F the time spent on bugfix during the freeze
+>> - C the time spent on cauldron during the freeze
+>>
+>> We can assume that :
+>> C + F = Y
+>>
+>> So the equation become :
+>> C + ( X - Y ) + F
+>> = C + F - Y + X
+>> = X
+>>
+>> So no matter how you divide the time, you still have the same amount of
+>> time spent overall.
+>
+> As I assumed :)
+>
+>> Now, the real important question is "can we really exchange work done as
+>> part of C for work done as part of F".
+>>
+>> And so "if I do regular packages updates on cauldron at the begining of
+>> the cycle, does it count as bugfixing for the release in the end of the
+>> cycle" ?
+>>
+>> To me, the answer is clearly no. If it was somethig we could exchange,
+>> we would not have to make a freeze in the first place to make sure that
+>> only bugfixes are uploaded in cauldron.
+>>
+>> So the only way to maximize the time spent on bugfixes is to have F = Y,
+>> and so C = 0. Ie, do like we do now.
+>
+> I really don't follow this line of reasoning.
+> The focus on bug fixes starts with the freeze. So a longer freeze would
+> give more time to focus on bug fixes.
+> Sure, there are updates and bug fixes in cauldron before the freeze, as
+> a normal part of any development process. (Even in the non-libre world.)
+>
+>> And unless you show that letting people work on cauldron will bring more
+>> ressources , and more than the one we will lose du to people who do not
+>> want to work on bugfixes and the release, I doubt this will change.
+>
+> Ok. Obviously I need to clarify my point of view.
+> Firstly, my assumption was that at least as much time would be spent on
+> bug fixing during the longer freeze, but being less rushed, would tend
+> to produce better quality results. (And less aggravation for ennael)
+> (That is certainly how it works in the non-libre world.)
+>
+> I don't see how having the choice between contributing to pre-release or
+> cauldron during the freeze will lead to us loosing _any_ contributors.
+>
+> As well, since cauldron would be out of freeze virtually all the time,
+> there would be (virtually) no period where contributions to cauldron are
+> blocked.
+> Packager time is not an ubiquitous resource. Some packagers are perl
+> experts, other python, etc. Each packager is more familiar with some
+> packages than others. Some packagers are excellent developers; others
+> are challenged by basic scripts. There is a wide range of skills and
+> interests.
+>
+> If during freeze, a packager has a choice between attempting to help
+> with a bugfix in pre-release for a package with which s/he is not
+> familiar, or contributing to cauldron for something with which s/he is
+> familiar, it would be evidently more efficient to contribute to cauldron.
+>
+> Similarly, if a packager contributes a bug fix to pre-release, and a
+> newer package already exists in cauldron for which the same bug fix must
+> be applied, it is more efficient to apply the same patch right away,
+> than to wait until freeze is over. (Personnally I've encountered this
+> sort of situation with similar but different software many times. Any
+> experienced programmer should understand this point.)
+>
+> So there are a lot of (admittedly small) synergies which should lead to
+> packager time being more efficiently used.
+> Not counting the likelyhood that some packagers would contribute
+> somewhat more time, being able to contribute to cauldron during freeze.
+> The major benefit in my mind is the longer freeze period.
+>
+> How much this would help, I don't know. But I think it is worth a try.
+> (Even if we end up going for a 9-month release cycle, instead of my
+> preferred 6 months.)
+>
+
+Another thought about the amended freeze process.
+Have you noticed how packagers sometimes set off an exchange of 10 or more emails in attempts to 
+get a package into the release during the freeze ?
+The packager wants to submit, but they can't because cauldron is frozen.  Maybe if only pre-release 
+were frozen, but cauldron open, they would accept submitting to cauldron after only 1 or 2 
+exchanges.  They would have the at least partial satisfaction of being able to submit their package 
+(instead of waiting, and doing something else, probably elsewhere), and others would have been 
+releaved of the hassle of dealing with their repeated requests.
+I think that would be more motivating for the packager in question, as well as the others involved.
+And packagers would avoid wasting both time and energy.
+
+-- 
+André
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005841.html b/zarb-ml/mageia-dev/2011-June/005841.html new file mode 100644 index 000000000..40ce0ce15 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005841.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Sun Jun 19 12:51:25 CEST 2011 +

+
+ +
andre999 <andr55 at laposte.net> schrieb am 19.06.2011
+> Another thought about the amended freeze process.
+> Have you noticed how packagers sometimes set off an exchange of 10
+> or more emails in attempts to get a package into the release
+> during the freeze ?
+> The packager wants to submit, but they can't because cauldron is
+> frozen.  Maybe if only pre-release were frozen, but cauldron open,
+> they would accept submitting to cauldron after only 1 or 2
+> exchanges.  They would have the at least partial satisfaction of
+> being able to submit their package (instead of waiting, and doing
+> something else, probably elsewhere), and others would have been
+> releaved of the hassle of dealing with their repeated requests. I
+> think that would be more motivating for the packager in question,
+> as well as the others involved. And packagers would avoid wasting
+> both time and energy.
+I don't know. I think most freeze push requests were due to the fact, 
+that packagers wanted to have their baby in the release.
+Because every packager knows, he only has to wait some days to submit 
+it to Cauldron again.
+So I don't think any packager would be any the happier by this 
+solution.
+
+I have to agree with misc. It would only mean having more work.
+
+Oliver
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110619/0de93587/attachment.html>
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005842.html b/zarb-ml/mageia-dev/2011-June/005842.html new file mode 100644 index 000000000..f333f6bbc --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005842.html @@ -0,0 +1,76 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ Michael Scherer + misc at zarb.org +
+ Sun Jun 19 15:00:06 CEST 2011 +

+
+ +
Le samedi 18 juin 2011 à 23:25 +0300, Ahmad Samir a écrit :
+> On 15 June 2011 22:32, Stew Benedict <stewbintn at gmail.com> wrote:
+
+> qa-bugs@ can't be be set as the assignee in bug reports, it should be
+> made possible.
+
+Yes, that requires to create a account for that. Dmorgan knows, I
+don't :/ ( and we should document that once the wiki will be installed
+).
+
+> The same for sec team, there should be a way to assign/put-in-CC.
+That would requires the creation of the secteam as something more formal
+than now, and for now, that's "no".
+So you should better explain the need about assigning or put a group of
+people in CC when you can simply put one person for that.
+
+
+-- 
+Michael Scherer
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005843.html b/zarb-ml/mageia-dev/2011-June/005843.html new file mode 100644 index 000000000..9d5d02644 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005843.html @@ -0,0 +1,66 @@ + + + + [Mageia-dev] Finalizing update process + + + + + + + + + +

[Mageia-dev] Finalizing update process

+ nicolas vigier + boklm at mars-attacks.org +
+ Sun Jun 19 15:09:54 CEST 2011 +

+
+ +
On Sat, 18 Jun 2011, Ahmad Samir wrote:
+
+> 
+> qa-bugs@ can't be be set as the assignee in bug reports, it should be
+> made possible.
+
+It should be possible now (since friday actually).
+
+This bug for instance is assigned to qa-bugs@ :
+https://bugs.mageia.org/show_bug.cgi?id=1554
+
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005844.html b/zarb-ml/mageia-dev/2011-June/005844.html new file mode 100644 index 000000000..9472ea871 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005844.html @@ -0,0 +1,149 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ mammig_linux mammig_linux + mammig.linux at gmail.com +
+ Sun Jun 19 15:23:36 CEST 2011 +

+
+ +
Hello,
+
+The discussion about the "Mageia life cycle" start few days ago on the
+forum of the French user community of Mageia (
+http://www.mageialinux-online.org/forum/topic-10576+cycle-de-vie-de-mageia.php
+: for those who read French )
+
+tTo put all the answers in a nutshell, i will say that users rather
+having a new version if that bring big changes.
+If the goal is to have a "windows like new version" ( with a new
+design, new bugs, new system sounds, "please buy a new printer/scanner
+because the new driver will never exist" or "please buy a new computer
+because yours is too old/not enough memory"... and no fundamental
+changes on the OS ) or something like :
+Mageia(n) = Mageia(n-1) - some bugs + new design + some updates
+then it's useless to have a new version each x month.
+
+Users wants a good, strong, and long life OS.
+Those who like to change the design will be happy if they have
+something like "task-newdesign.RPM"
+those who like news or updates will be happy with update and backports
+repository.
+
+Currently, we just put the suitcase on the floor. ( sorry, bad
+translation of a french idiom ;))
+The website is "temporary", like the wiki and like a lot of things.
+It's hard to find new volunteers... So... We needn't to have the eyes
+bigger than the stomach ( sorry, bad translation of a French idiom
+O:))
+Let's take time for opening the suitcase... having a good multilingual
+web site with an easy management, a "not temporary" wiki, correcting
+bugs, maybe make more test, create the missing and ask packages,
+create stronger teams with more people. Maybe we can think of a new
+way of working ( like the idea of "Proofreading" in i18n teams )...
+
+Currently I help anaselli in his project of "educative Mageia
+version", maybe it should be great to have others version of Mageia (
+like a "server" version for example ).
+
+Greeting,
+mammig
+
+PS : I think it's a good thing to have the opinion of users about
+that, even if they are not english. I will not make a translation of
+each message, I guess a small summary is enough.
+
+2011/6/19 Oliver Burger <oliver.bgr at googlemail.com>:
+> andre999 <andr55 at laposte.net> schrieb am 19.06.2011
+>
+>> Another thought about the amended freeze process.
+>
+>> Have you noticed how packagers sometimes set off an exchange of 10
+>
+>> or more emails in attempts to get a package into the release
+>
+>> during the freeze ?
+>
+>> The packager wants to submit, but they can't because cauldron is
+>
+>> frozen. Maybe if only pre-release were frozen, but cauldron open,
+>
+>> they would accept submitting to cauldron after only 1 or 2
+>
+>> exchanges. They would have the at least partial satisfaction of
+>
+>> being able to submit their package (instead of waiting, and doing
+>
+>> something else, probably elsewhere), and others would have been
+>
+>> releaved of the hassle of dealing with their repeated requests. I
+>
+>> think that would be more motivating for the packager in question,
+>
+>> as well as the others involved. And packagers would avoid wasting
+>
+>> both time and energy.
+>
+> I don't know. I think most freeze push requests were due to the fact, that
+> packagers wanted to have their baby in the release.
+>
+> Because every packager knows, he only has to wait some days to submit it to
+> Cauldron again.
+>
+> So I don't think any packager would be any the happier by this solution.
+>
+> I have to agree with misc. It would only mean having more work.
+>
+> Oliver
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005845.html b/zarb-ml/mageia-dev/2011-June/005845.html new file mode 100644 index 000000000..ce3d60ccf --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005845.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process) + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process)

+ Michael Scherer + misc at zarb.org +
+ Sun Jun 19 15:38:56 CEST 2011 +

+
+ +
Le samedi 18 juin 2011 à 23:29 +0300, Ahmad Samir a écrit :
+> So, is there a consensus about this yet? (note that the backports list
+> of packages keeps growing in the mean time :)).
+
+Well, my own impression was that the consensus is :
+the policy for version 1 is :
+- we can upload a missing package in update provided :
+  - it follow the same path as any update in term of QA, etc
+  - it was asked by someone, with a bug report or something like that,
+that it break update from 2010.1 ( so that part is specifically tested
+).
+  - there is no package in updates or release ( ie, the exception is
+only once )
+
+
+for version 2 and later :
+- new versions goes to backport, unless clearly expressed exceptions
+( bugfixes branchs, annoying upstreams ). The exact list of exception is
+roughly well agreed, minus details ( where the devil hide, obviously ).
+However, we didn't wrote it, nor decided on how to decide.
+
+So we would need :
+- a list of such exception written somewhere
+- a documented way to decide how to be in the exception list, ie a
+criteria list. I have attempted a proposal here :
+https://www.mageia.org/pipermail/mageia-dev/2011-June/005225.html ,
+boklm attempted a slightly different one :
+https://www.mageia.org/pipermail/mageia-dev/2011-June/005373.html
+
+Both are similar in spirit, so the question is just finding clear and
+useful criterias.
+ 
+
+Regarding backport policy, we didn't started to discuss much, but I
+wouldn't except to have it different from Mandriva for now, except what
+does "supported" mean, and the impact on the whole system ( as Christian
+noted, how to fill stuff in bugzilla, or the impact on Requires for a
+packaging policy to avoid mixing version ). 
+
+That's something to keep for later, since that's already hard to follow
+current discussion ( especially with people who do not trim the email
+they answer to, and since  ).
+
+But I will summarize the ideas and send a email after the one about
+release cycle.
+
+-- 
+Michael Scherer
+
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005846.html b/zarb-ml/mageia-dev/2011-June/005846.html new file mode 100644 index 000000000..5bb6a05b9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005846.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] perl 5.14.1 on its way + + + + + + + + + +

[Mageia-dev] perl 5.14.1 on its way

+ Jerome Quelin + jquelin at gmail.com +
+ Sun Jun 19 15:46:09 CEST 2011 +

+
+ +
hi,
+
+i just submitted perl 5.14.1, which should be a smooth upgrade. no need
+to recompile binary modules this time.
+
+jérôme 
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005847.html b/zarb-ml/mageia-dev/2011-June/005847.html new file mode 100644 index 000000000..2b32c4931 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005847.html @@ -0,0 +1,244 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Michael Scherer + misc at zarb.org +
+ Sun Jun 19 16:29:42 CEST 2011 +

+
+ +
Le samedi 18 juin 2011 à 23:49 -0400, andre999 a écrit :
+> Michael Scherer a écrit :
+> >
+> > Le samedi 18 juin 2011 à 03:38 -0400, andre999 a écrit :
+> >> Michael Scherer a écrit :
+
+> > If people work the same amount of time, with work divided on 2 products,
+> > they must share their time, and usually work less than if they focused
+> > only on one product, unless there is twice the ressources. But I doubt
+> > this will happen for us, so let's assume that ressources are fixed.
+> 
+> That was my assumption : resources fixed in terms of time spent.
+> And why would that divide a contributor's focus more than now ? 
+>  They would just have a choice.
+
+So before, the choice is between :
+- not doing anything
+- bugfixing
+
+After your proposal, there is :
+- not doing anything
+- bugfixing
+- uploading new stuff to cauldron 
+
+And you fail to see how it divert focus ?
+
+> Now during the freeze, someone that wants to contribute to cauldron, but can't or chooses not to 
+> contribute to pre-release bugfix, is not contributing.
+> So in practice, we risk to have more time contributed during the freeze.
+
+My own experience tell the contrary, but maybe you should ask to Anne
+her opinion if you do not believe me, or to others people who did
+distribution releases ( and not software releases, which is slightly
+different, mainly because there is less  ).
+
+> > Now, of course, we can say "what if people do not divide their work in
+> > 2 ?"
+> >
+> > So let's call :
+> > - F the time spent on bugfix during the freeze
+> > - C the time spent on cauldron during the freeze
+> >
+> > We can assume that :
+> > C + F = Y
+> >
+> > So the equation become :
+> > C + ( X - Y ) + F
+> > = C + F - Y + X
+> > = X
+> >
+> > So no matter how you divide the time, you still have the same amount of
+> > time spent overall.
+> 
+> As I assumed :)
+
+No.
+"the cauldron cycle is extented by the time of the pre-release freeze.
+e.g. In a release cycle of 6 months and a pre-release freeze of 1 month,
+the cauldron cycle would be 7 months."
+
+The cauldron cycle would be 7 months just on the calendar, but 6 months
+worth of work, as demonstrated. 
+
+"A 1-month pre-release freeze would add 1 month to cauldron development
+time."
+
+That's the same, you do not add real months, just months on the
+calendar.
+
+> > Now, the real important question is "can we really exchange work done as
+> > part of C for work done as part of F".
+> >
+> > And so "if I do regular packages updates on cauldron at the begining of
+> > the cycle, does it count as bugfixing for the release in the end of the
+> > cycle" ?
+> >
+> > To me, the answer is clearly no. If it was somethig we could exchange,
+> > we would not have to make a freeze in the first place to make sure that
+> > only bugfixes are uploaded in cauldron.
+> >
+> > So the only way to maximize the time spent on bugfixes is to have F = Y,
+> > and so C = 0. Ie, do like we do now.
+> 
+> I really don't follow this line of reasoning.
+> The focus on bug fixes starts with the freeze.  So a longer freeze would give more time to focus on 
+> bug fixes.
+
+The focus on bugfixing start with version freeze, since what introduce
+problem is various changes, and new versions of softwares usually bring
+new changes. Then we block all uploads except bug fixes, and then all
+uploads unless very serious bug fixes ( ie, release blocker ). So the
+focus start much before the last freeze, and you are quite unclear.
+
+> > And unless you show that letting people work on cauldron will bring more
+> > ressources , and more than the one we will lose du to people who do not
+> > want to work on bugfixes and the release, I doubt this will change.
+> 
+> Ok.  Obviously I need to clarify my point of view.
+> Firstly, my assumption was that at least as much time would be spent on bug fixing during the 
+> longer freeze, but being less rushed, would tend to produce better quality results.  (And less 
+> aggravation for ennael)  (That is certainly how it works in the non-libre world.)
+
+You do not say much how you extend the freeze to be longer, nor even
+that the freeze appear sooner, reread your mail. Nor what kind of freeze
+would it be.
+
+The only mention of the duration of the freeze is :
+"A 1-month pre-release freeze would add 1 month to cauldron development
+time."
+
+The version freeze started on 20 april
+( https://mageia.org/pipermail/mageia-dev/20110419/004066.html ), which
+is more than 1 month. The release freeze was on 14 may, which is 2
+weeks. 
+
+Given that the version freeze is when we start to ask to people to focus
+on bugfixes and when we prevent packagers from uploading newer versions
+of packages, the proposed 1 month pre-release freeze is unclear and
+unexplained.
+
+
+> I don't see how having the choice between contributing to pre-release or cauldron during the freeze 
+> will lead to us loosing _any_ contributors.
+
+We do not lose contributors, we lose the work of people that prefer to
+work on cauldron by uploading new versions rather than bug fixing, and
+from people that will prefer to test and use cauldron rather than the
+future stable release, because that's easier, there is no deadline, nor
+any obligation, and there is newer stuff. 
+
+
+> If during freeze, a packager has a choice between attempting to help with a bugfix in pre-release 
+> for a package with which s/he is not familiar, or contributing to cauldron for something with which 
+> s/he is familiar, it would be evidently more efficient to contribute to cauldron.
+
+You are placing a wrong dichotomy. The choice is not between "fixing
+something efficiently on cauldron vs fixing un-efficiently on
+pre-release", but between "fixing un-efficiently" vs "not fixing". 
+
+> Similarly, if a packager contributes a bug fix to pre-release, and a newer package already exists 
+> in cauldron for which the same bug fix must be applied, it is more efficient to apply the same 
+> patch right away, than to wait until freeze is over.  (Personnally I've encountered this sort of 
+> situation with similar but different software many times.  Any experienced programmer should 
+> understand this point.)
+
+With the current process, the fix is already applied for next cauldron
+cycle, since the package is the same, there is no branching.
+
+> So there are a lot of (admittedly small) synergies which should lead to packager time being more 
+> efficiently used.
+> Not counting the likelyhood that some packagers would contribute somewhat more time, being able to 
+> contribute to cauldron during freeze.
+> The major benefit in my mind is the longer freeze period.
+
+Which mean that we will have more outdated software if we freeze sooner.
+
+Assuming that the pre-release freeze you are speaking about is what the
+packagers know as "release freeze", this means the version freeze will
+be sooner too. Assuming that what you call "pre-release freeze" is the
+version freeze, then the freeze period would just be shorter.
+ 
+Also, your point seems to forget to take in account that people can
+focus on bugfixs without any freeze of the distribution, yet, they do
+not seems to do so. 
+
+People rushing packages in the last minute as it always happen is the
+prime example of why people prefer cauldron rather than bugfix.
+
+
+> In any case, it seems to me that the bigger liability would be being out of sync with the 6-month 
+> release cycle of kde, gnome, as well as many other distros.
+
+s/many others distros/ubuntu and fedora/.
+
+Opensuse has a cycle of 8 months, Debian is not really time based ( and
+is around 1 and 2 years ), Mandriva is gone on 1 year cycle, Arch,
+Pclinuxos or others popular distributions from distrowatch do not seems
+on a regular cycle. And as someone said, Mint is more released "when
+ready after seeing fix on Ubuntu" than being a 6 months cycle ( even if
+that's very similar ).
+
+-- 
+Michael Scherer
+
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005848.html b/zarb-ml/mageia-dev/2011-June/005848.html new file mode 100644 index 000000000..3a9137034 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005848.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] perl 5.14.1 on its way + + + + + + + + + +

[Mageia-dev] perl 5.14.1 on its way

+ Funda Wang + fundawang at gmail.com +
+ Sun Jun 19 16:41:10 CEST 2011 +

+
+ +
What do you think of a fedora-like perl FSH layout?
+
+2011/6/19 Jerome Quelin <jquelin at gmail.com>:
+> hi,
+>
+> i just submitted perl 5.14.1, which should be a smooth upgrade. no need
+> to recompile binary modules this time.
+>
+> jérôme
+>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005849.html b/zarb-ml/mageia-dev/2011-June/005849.html new file mode 100644 index 000000000..8a10bbaa4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005849.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] perl 5.14.1 on its way + + + + + + + + + +

[Mageia-dev] perl 5.14.1 on its way

+ Michael Scherer + misc at zarb.org +
+ Sun Jun 19 18:18:13 CEST 2011 +

+
+ +
Le dimanche 19 juin 2011 à 15:46 +0200, Jerome Quelin a écrit :
+> hi,
+> 
+> i just submitted perl 5.14.1, which should be a smooth upgrade. no need
+> to recompile binary modules this time.
+
+Some packages seems to have some errors :
+http://check.mageia.org/dependencies.html
+
+"perl found with incorrect range == 2:5.14.1-1.mga2 (needed ==
+2:5.14.0)"
+
+Is this a youri error or a real issue ?
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005850.html b/zarb-ml/mageia-dev/2011-June/005850.html new file mode 100644 index 000000000..cf56c202f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005850.html @@ -0,0 +1,112 @@ + + + + [Mageia-dev] perl 5.14.1 on its way + + + + + + + + + +

[Mageia-dev] perl 5.14.1 on its way

+ Anssi Hannula + anssi.hannula at iki.fi +
+ Sun Jun 19 18:35:44 CEST 2011 +

+
+ +
On 19.06.2011 19:18, Michael Scherer wrote:
+> Le dimanche 19 juin 2011 à 15:46 +0200, Jerome Quelin a écrit :
+>> hi,
+>>
+>> i just submitted perl 5.14.1, which should be a smooth upgrade. no need
+>> to recompile binary modules this time.
+> 
+> Some packages seems to have some errors :
+> http://check.mageia.org/dependencies.html
+> 
+> "perl found with incorrect range == 2:5.14.1-1.mga2 (needed ==
+> 2:5.14.0)"
+> 
+> Is this a youri error or a real issue ?
+
+Applications dynamically linked to perl need to be rebuilt for new perl
+versions as the perl library is in a versioned directory.
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005851.html b/zarb-ml/mageia-dev/2011-June/005851.html new file mode 100644 index 000000000..7d0aa658c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005851.html @@ -0,0 +1,110 @@ + + + + [Mageia-dev] perl 5.14.1 on its way + + + + + + + + + +

[Mageia-dev] perl 5.14.1 on its way

+ Jerome Quelin + jquelin at gmail.com +
+ Sun Jun 19 19:50:32 CEST 2011 +

+
+ +
On 11/06/19 18:18 +0200, Michael Scherer wrote:
+> Le dimanche 19 juin 2011 à 15:46 +0200, Jerome Quelin a écrit :
+> > i just submitted perl 5.14.1, which should be a smooth upgrade. no need
+> > to recompile binary modules this time.
+> 
+> Some packages seems to have some errors :
+> http://check.mageia.org/dependencies.html
+> 
+> "perl found with incorrect range == 2:5.14.1-1.mga2 (needed ==
+> 2:5.14.0)"
+> 
+> Is this a youri error or a real issue ?
+
+nope, it's a real issue. i forgot about those - i need to add a check in
+find-need-rebuild (a script in perl/ svn directory that finds scripts
+with a wrong shebang).
+
+jérôme 
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005852.html b/zarb-ml/mageia-dev/2011-June/005852.html new file mode 100644 index 000000000..a7c47616f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005852.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] perl 5.14.1 on its way + + + + + + + + + +

[Mageia-dev] perl 5.14.1 on its way

+ Jerome Quelin + jquelin at gmail.com +
+ Sun Jun 19 19:51:34 CEST 2011 +

+
+ +
On 11/06/19 22:41 +0800, Funda Wang wrote:
+> What do you think of a fedora-like perl FSH layout?
+
+can you elaborate please? i'm not aware of their layout.
+what is the layout, what needs to be done, what about the existing
+packages, etc.
+
+jérôme 
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005853.html b/zarb-ml/mageia-dev/2011-June/005853.html new file mode 100644 index 000000000..15794661f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005853.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] perl 5.14.1 on its way + + + + + + + + + +

[Mageia-dev] perl 5.14.1 on its way

+ Jerome Quelin + jquelin at gmail.com +
+ Sun Jun 19 20:02:57 CEST 2011 +

+
+ +
On 11/06/19 18:18 +0200, Michael Scherer wrote:
+> "perl found with incorrect range == 2:5.14.1-1.mga2 (needed ==
+> 2:5.14.0)"
+> 
+> Is this a youri error or a real issue ?
+
+how can we find those? afaik, "urpmf --requires :perl" cannot be used
+with a specific version. any help to find those packages is welcome.
+
+jérôme 
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005854.html b/zarb-ml/mageia-dev/2011-June/005854.html new file mode 100644 index 000000000..ae02f00ef --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005854.html @@ -0,0 +1,106 @@ + + + + [Mageia-dev] python-twisted + + + + + + + + + +

[Mageia-dev] python-twisted

+ Cazzaniga Sandro + cazzaniga.sandro at gmail.com +
+ Sun Jun 19 21:22:02 CEST 2011 +

+
+ +
Hi,
+
+Just for info, python-twisted 11.0.0 is now in cauldron. You can test it
+and file bugs reports if it's needed.
+
+Cheers
+-- 
+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
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005855.html b/zarb-ml/mageia-dev/2011-June/005855.html new file mode 100644 index 000000000..d67284ae5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005855.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ lebarhon + lebarhon at free.fr +
+ Sun Jun 19 21:33:44 CEST 2011 +

+
+ +
Le 19/06/2011 10:28, Wolfgang Bornath a écrit :
+> Nobody said anything against your efforts although I don't see any
+> reason there (and I haven't seen any discussion in the webteam where
+> it was decided to do so),
+Who the hell are you to dare say I am a liar !
+
+https://forums.mageia.org/en/viewtopic.php?f=29&t=570 
+<https://forums.mageia.org/en/viewtopic.php?f=29&t=570>
+
+1 -  roadrunner asked if somebody could cross-post between the forum and 
+the ML
+2 - Anne posted in this thread and find nothing to say against it
+3 - So, I volunteered for that
+4 - maat agreed
+5 - I suggested a method
+6 - maat agreed again
+7 - I began what I promised, and you posted behind without saying 
+anything against it.
+
+It was not enough to be fully authorized ....
+>   people who read mailing lists are able to
+> read forums as well - if they don't want to, that's their decision.
+They are able to, but they won't because "our team members still sleep 
+during nights". These are Anne's own words.
+> But referring to the issue here I am pretty sure that nobody asked you
+> to write in HTML nor to transfer the off-topic banter.
+Neither that nor the opposite. I never said I will re-write all the text 
+nor I will read and sort the posts. Nobody prevented me to do that way. 
+I stopped some of the off-topic banger, not each one.
+
+Well, I made a mistake, I was told by misc, it's ok and I don't need a 
+parrot repeating for a second layer.
+I subscribed to this third Mageia ML at this purpose only and didn't 
+read the other posts, so I am going to unsubscribe, this one at least.
+
+
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005856.html b/zarb-ml/mageia-dev/2011-June/005856.html new file mode 100644 index 000000000..c9837f104 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005856.html @@ -0,0 +1,111 @@ + + + + [Mageia-dev] perl 5.14.1 on its way + + + + + + + + + +

[Mageia-dev] perl 5.14.1 on its way

+ Anssi Hannula + anssi.hannula at iki.fi +
+ Sun Jun 19 22:39:33 CEST 2011 +

+
+ +
On 19.06.2011 21:02, Jerome Quelin wrote:
+> On 11/06/19 18:18 +0200, Michael Scherer wrote:
+>> "perl found with incorrect range == 2:5.14.1-1.mga2 (needed ==
+>> 2:5.14.0)"
+>>
+>> Is this a youri error or a real issue ?
+> 
+> how can we find those? afaik, "urpmf --requires :perl" cannot be used
+> with a specific version. any help to find those packages is welcome.
+
+e.g. to find packages depending on 2:5.14.0:
+
+$ urpmf --requires ":perl\[== 2:5.14.0"
+
+or to find all packages having a version-specific require on another
+version than 5.14.1:
+
+$ urpmf --requires ':perl\[== (?!2:5.14.1[-\]])'
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005857.html b/zarb-ml/mageia-dev/2011-June/005857.html new file mode 100644 index 000000000..4e084e62f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005857.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] [RPM] cauldron core/release p-uae-2.3.2-1.gita2b6937.2.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release p-uae-2.3.2-1.gita2b6937.2.mga2

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Sun Jun 19 22:40:10 CEST 2011 +

+
+ +
On 18 June 2011 20:12, Mageia Team <buildsystem-daemon at mageia.org> wrote:
+> [This is in an unofficial branch of UAE (the Ubiquitous Amiga Emulator)
+> with the aim of bringing the features of WinUAE to non-Windows platforms
+> such as Linux, Mac OS X and BeOS.]
+>
+> obgr_seneca <obgr_seneca> 2.3.2-1.gita2b6937.2.mga2:
+> + Revision: 109474
+> - cleaned spec file
+> - removed buildroot tag
+> - imported package p-uae
+
+Should this be in core?
+In mdv such emulators usually ended in PLF...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005858.html b/zarb-ml/mageia-dev/2011-June/005858.html new file mode 100644 index 000000000..8bfaa30e4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005858.html @@ -0,0 +1,118 @@ + + + + [Mageia-dev] [RPM] cauldron core/release p-uae-2.3.2-1.gita2b6937.2.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release p-uae-2.3.2-1.gita2b6937.2.mga2

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Sun Jun 19 22:51:44 CEST 2011 +

+
+ +
Thierry Vignaud <thierry.vignaud at gmail.com> schrieb am 19.06.2011
+> On 18 June 2011 20:12, Mageia Team <buildsystem-daemon at mageia.org> 
+wrote:
+> > [This is in an unofficial branch of UAE (the Ubiquitous Amiga
+> > Emulator) with the aim of bringing the features of WinUAE to
+> > non-Windows platforms such as Linux, Mac OS X and BeOS.]
+> > 
+> > obgr_seneca <obgr_seneca> 2.3.2-1.gita2b6937.2.mga2:
+> > + Revision: 109474
+> > - cleaned spec file
+> > - removed buildroot tag
+> > - imported package p-uae
+> 
+> Should this be in core?
+> In mdv such emulators usually ended in PLF...
+The old e-uae was in contrib_release for years. The emulator itself 
+does not contain any legally critical stuff.
+You need a rom image to use it, that can't be packaged (and isn't) 
+because of legal issues.
+
+I see no problem having p-uae in core.
+
+Oliver
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110619/3c37dc23/attachment-0001.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005859.html b/zarb-ml/mageia-dev/2011-June/005859.html new file mode 100644 index 000000000..ed14d54a8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005859.html @@ -0,0 +1,111 @@ + + + + [Mageia-dev] [RPM] cauldron core/release drakx-installer-binaries-1.50-3.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release drakx-installer-binaries-1.50-3.mga2

+ James Kerr + jim at jkerr82508.free-online.co.uk +
+ Sun Jun 19 23:32:41 CEST 2011 +

+
+ +
On 19/06/11 18:43, Mageia Team wrote:
+> Name        : drakx-installer-binaries     Relocations: (not relocatable)
+> Version     : 1.50                              Vendor: Mageia.Org
+> Release     : 3.mga2                        Build Date: Sun Jun 19 19:40:17 2011
+> Install Date: (not installed)               Build Host: jonund
+> Group       : Development/Other             Source RPM: (none)
+> Size        : 914415                           License: GPL
+> Signature   : (none)
+> Packager    : Mageia Team<http://www.mageia.org>
+> URL         : http://wiki.mandriva.com/Tools/DrakX
+> Summary     : DrakX binaries
+> Description :
+> binaries needed to build Mandriva installer (DrakX)
+>
+
+Are the Mandriva references appropriate?
+
+Jim
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005860.html b/zarb-ml/mageia-dev/2011-June/005860.html new file mode 100644 index 000000000..18ff61b03 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005860.html @@ -0,0 +1,116 @@ + + + + [Mageia-dev] [RPM] cauldron core/release networkmanager-0.8.9997-0.1.1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release networkmanager-0.8.9997-0.1.1.mga2

+ JA Magallón + jamagallon at ono.com +
+ Mon Jun 20 00:18:50 CEST 2011 +

+
+ +
On Wed, 15 Jun 2011 10:02:21 -0300, John Balcaen <mikala at mageia.org> wrote:
+
+> 2011/6/15 JA Magallón <jamagallon at ono.com>:
+> [...]
+> >
+> > This is missing the 'ifcfg-mdv' and 'keyfile' plugins...
+> >
+> in fact only the ifcfg-mdv plugin is really missing.
+> keyfile should be available.
+> 
+
+The plugin file is not there. only ifcfg-rh:
+
+one:~# rpm -ql networkmanager | grep /usr/lib
+/usr/lib64/NetworkManager
+/usr/lib64/NetworkManager/libnm-settings-plugin-ifcfg-rh.so
+/usr/lib64/nm-avahi-autoipd.action
+/usr/lib64/nm-crash-logger
+/usr/lib64/nm-dhcp-client.action
+/usr/lib64/nm-dispatcher.action
+/usr/lib64/pppd/2.4.5/nm-pppd-plugin.so
+
+If you want to say that the functionality should be there because now it
+is integrated instead of a plugin, it is half-working: nm can read
+the names and info about connections, but no wireless device is available
+in applet menu...it does not detect wifi hardware.
+
+Any ideas ?
+
+
+-- 
+J.A. Magallon <jamagallon()ono!com>     \                 Winter is coming...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005861.html b/zarb-ml/mageia-dev/2011-June/005861.html new file mode 100644 index 000000000..e4ffc733f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005861.html @@ -0,0 +1,137 @@ + + + + [Mageia-dev] [RPM] cauldron core/release networkmanager-0.8.9997-0.1.1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release networkmanager-0.8.9997-0.1.1.mga2

+ JA Magallón + jamagallon at ono.com +
+ Mon Jun 20 01:00:20 CEST 2011 +

+
+ +
On Mon, 20 Jun 2011 00:18:50 +0200, JA Magallón <jamagallon at ono.com> wrote:
+
+> On Wed, 15 Jun 2011 10:02:21 -0300, John Balcaen <mikala at mageia.org> wrote:
+> 
+> > 2011/6/15 JA Magallón <jamagallon at ono.com>:
+> > [...]
+> > >
+> > > This is missing the 'ifcfg-mdv' and 'keyfile' plugins...
+> > >
+> > in fact only the ifcfg-mdv plugin is really missing.
+> > keyfile should be available.
+> > 
+> 
+> The plugin file is not there. only ifcfg-rh:
+> 
+> one:~# rpm -ql networkmanager | grep /usr/lib
+> /usr/lib64/NetworkManager
+> /usr/lib64/NetworkManager/libnm-settings-plugin-ifcfg-rh.so
+> /usr/lib64/nm-avahi-autoipd.action
+> /usr/lib64/nm-crash-logger
+> /usr/lib64/nm-dhcp-client.action
+> /usr/lib64/nm-dispatcher.action
+> /usr/lib64/pppd/2.4.5/nm-pppd-plugin.so
+> 
+> If you want to say that the functionality should be there because now it
+> is integrated instead of a plugin, it is half-working: nm can read
+> the names and info about connections, but no wireless device is available
+> in applet menu...it does not detect wifi hardware.
+> 
+> Any ideas ?
+> 
+> 
+
+I get a curious error message:
+
+NetworkManager[31268]: <info> (wlan0): bringing up device.
+NetworkManager[31268]: <debug> [1308523664.980198] [nm-supplicant-manager.c:86] nm_supplicant_manager_iface_get(): (wlan0): creating new supplicant interface
+NetworkManager[31268]: <debug> [1308523664.981554] [nm-supplicant-interface.c:583] interface_add(): (wlan0): adding interface to supplicant
+NetworkManager[31268]: <debug> [1308523664.983624] [nm-device-wifi.c:3655] real_set_enabled(): (wlan0): enable waiting on supplicant state
+NetworkManager[31268]: <debug> [1308523664.984204] [nm-netlink-monitor.c:117] link_msg_handler(): netlink link message: iface idx 3 flags 0x1003
+NetworkManager[31268]: <debug> [1308523664.984705] [nm-supplicant-interface.c:560] interface_add_cb(): (wlan0): failed to activate supplicant: The name fi.w1.wpa_supplicant1 was not provided by any .service files
+NetworkManager[31268]: <info> (wlan0): supplicant interface state: starting -> init
+
+Mmmm, googlin a bit I found this:
+
+http://fossplanet.com/f13/re-wifi-networkmanager-0-8-996-a-113296/
+
+So i short it seems that wpa_supplicant has to be compiled with dbus support for
+new networkmanager. I also see a patch in src.rpm to disable dbus....
+
+-- 
+J.A. Magallon <jamagallon()ono!com>     \                 Winter is coming...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005862.html b/zarb-ml/mageia-dev/2011-June/005862.html new file mode 100644 index 000000000..04350c15d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005862.html @@ -0,0 +1,126 @@ + + + + [Mageia-dev] [RPM] cauldron core/release p-uae-2.3.2-1.gita2b6937.2.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release p-uae-2.3.2-1.gita2b6937.2.mga2

+ Michael Scherer + misc at zarb.org +
+ Mon Jun 20 01:54:28 CEST 2011 +

+
+ +
Le dimanche 19 juin 2011 à 22:40 +0200, Thierry Vignaud a écrit :
+> On 18 June 2011 20:12, Mageia Team <buildsystem-daemon at mageia.org> wrote:
+> > [This is in an unofficial branch of UAE (the Ubiquitous Amiga Emulator)
+> > with the aim of bringing the features of WinUAE to non-Windows platforms
+> > such as Linux, Mac OS X and BeOS.]
+> >
+> > obgr_seneca <obgr_seneca> 2.3.2-1.gita2b6937.2.mga2:
+> > + Revision: 109474
+> > - cleaned spec file
+> > - removed buildroot tag
+> > - imported package p-uae
+> 
+> Should this be in core?
+> In mdv such emulators usually ended in PLF...
+
+Unfortunately, no one ever gave a reason for having them in PLF besides
+"that's because emulators goes to PLF", despites having zsnes and snes9x
+in contribs since years.
+
+Among the potential reasons would be :
+- copyright violation due to proprietary rom/bios ( which need to be
+checked on a case by case basis )
+- copyright due to logo/names/brand ( again, that would be a case by
+case )
+- fear of being attacked due to the bleem! story in 1999
+( http://en.wikipedia.org/wiki/Bleem! ).
+
+The 3rd option would be perfectly suited given the highly "historical"
+nature of the reason.
+
+Nowadays, the only important story I can find would be this one :
+http://mashable.com/2011/05/30/emulators-banned-android-market/ , and
+there isn't much information, besides the supposition this could be a
+TOS violation.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005863.html b/zarb-ml/mageia-dev/2011-June/005863.html new file mode 100644 index 000000000..051085950 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005863.html @@ -0,0 +1,118 @@ + + + + [Mageia-dev] [RPM] cauldron core/release networkmanager-0.8.9997-0.1.1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release networkmanager-0.8.9997-0.1.1.mga2

+ Balcaen John + mikala at mageia.org +
+ Mon Jun 20 02:46:49 CEST 2011 +

+
+ +
Le dimanche 19 juin 2011 19:18:50, JA Magallón a écrit :
+> On Wed, 15 Jun 2011 10:02:21 -0300, John Balcaen <mikala at mageia.org> wrote:
+> 
+> > 2011/6/15 JA Magallón <jamagallon at ono.com>:
+> > [...]
+> > >
+> > > This is missing the 'ifcfg-mdv' and 'keyfile' plugins...
+> > >
+> > in fact only the ifcfg-mdv plugin is really missing.
+> > keyfile should be available.
+> > 
+> 
+> The plugin file is not there. only ifcfg-rh:
+Seems like the plugin is built in now in fact & no more available as a .so 
+file .
+From my log i can read : 
+Jun 19 17:46:12 hatmehyt NetworkManager[7902]: <info> Loaded plugin keyfile: 
+(c) 2007 - 2010 Red Hat, Inc.  To report bugs please use the NetworkManager 
+mailing list.
+
+
+[...]
+> If you want to say that the functionality should be there because now it
+> is integrated instead of a plugin, it is half-working: nm can read
+> the names and info about connections, but no wireless device is available
+> in applet menu...it does not detect wifi hardware.
+> 
+> Any ideas ?
+Currently no :/
+
+-- 
+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-June/005864.html b/zarb-ml/mageia-dev/2011-June/005864.html new file mode 100644 index 000000000..e4f5396b3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005864.html @@ -0,0 +1,323 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ andre999 + andr55 at laposte.net +
+ Mon Jun 20 02:56:04 CEST 2011 +

+
+ +
Michael Scherer a écrit :
+>
+> Le samedi 18 juin 2011 à 23:49 -0400, andre999 a écrit :
+>> Michael Scherer a écrit :
+>>>
+>>> Le samedi 18 juin 2011 à 03:38 -0400, andre999 a écrit :
+>>>> Michael Scherer a écrit :
+>
+>>> If people work the same amount of time, with work divided on 2 products,
+>>> they must share their time, and usually work less than if they focused
+>>> only on one product, unless there is twice the ressources. But I doubt
+>>> this will happen for us, so let's assume that ressources are fixed.
+>>
+>> That was my assumption : resources fixed in terms of time spent.
+>> And why would that divide a contributor's focus more than now ?
+>>   They would just have a choice.
+>
+> So before, the choice is between :
+> - not doing anything
+> - bugfixing
+- or doing something elsewhere.
+>
+> After your proposal, there is :
+> - not doing anything
+> - bugfixing
+> - uploading new stuff to cauldron
+>
+> And you fail to see how it divert focus ?
+
+We have to remember that packager time is not an ubiquitous resource.  If a packager cannot use 
+their time efficiently during freeze, they have incentive to contribute their time elsewhere.  It 
+is just human nature.  Admittedly this is more likely to affect packagers with less broad-based 
+skills, but such packagers do not make insignificant contributions.
+As far as diverting focus, does the existance of many distros, providing much more choice, divert 
+focus ?  Likely to some extent, but not many packagers contribute to 4 to 6 distros and support in 
+the order of 1000 packages.  That's more the exception, for packagers with exceptional skills.
+
+>> Now during the freeze, someone that wants to contribute to cauldron, but can't or chooses not to
+>> contribute to pre-release bugfix, is not contributing.
+>> So in practice, we risk to have more time contributed during the freeze.
+>
+> My own experience tell the contrary, but maybe you should ask to Anne
+> her opinion if you do not believe me, or to others people who did
+> distribution releases ( and not software releases, which is slightly
+> different, mainly because there is less  ).
+
+Until we try it, we don't know how much effect it will have.  To the best of my knowledge 
+Mandrake/Mandriva and certainly Mageia has not tried this approach.  We are both working on 
+conjectures, and we can't know until we (or some other distro with similar resources) tries it.
+I find it difficult to believe that it will have a negative effect.  And I think it would be useful 
+to try it early in the development of Mageia.
+Even experienced programmers, who have to support different versions of the same software, run into 
+cases where it is very convient -- and more efficient -- to do parallel updates for example.  I run 
+into that often enough myself.
+
+>>> Now, of course, we can say "what if people do not divide their work in
+>>> 2 ?"
+>>>
+>>> So let's call :
+>>> - F the time spent on bugfix during the freeze
+>>> - C the time spent on cauldron during the freeze
+>>>
+>>> We can assume that :
+>>> C + F = Y
+>>>
+>>> So the equation become :
+>>> C + ( X - Y ) + F
+>>> = C + F - Y + X
+>>> = X
+>>>
+>>> So no matter how you divide the time, you still have the same amount of
+>>> time spent overall.
+>>
+>> As I assumed :)
+>
+> No.
+> "the cauldron cycle is extented by the time of the pre-release freeze.
+> e.g. In a release cycle of 6 months and a pre-release freeze of 1 month,
+> the cauldron cycle would be 7 months."
+
+Agreed.  I've already said that.
+
+> The cauldron cycle would be 7 months just on the calendar, but 6 months
+> worth of work, as demonstrated.
+>
+> "A 1-month pre-release freeze would add 1 month to cauldron development time."
+>
+> That's the same, you do not add real months, just months on the calendar.
+
+As I said, my basic assumption that the same number of packager hours are contributed.  Certain 
+factors suggest that one could expect somewhat more time contributed, and a number of others that 
+the time would be used more efficiently.  Nothing suggests that less time would be available.
+
+>>> Now, the real important question is "can we really exchange work done as
+>>> part of C for work done as part of F".
+>>>
+>>> And so "if I do regular packages updates on cauldron at the begining of
+>>> the cycle, does it count as bugfixing for the release in the end of the
+>>> cycle" ?
+>>>
+>>> To me, the answer is clearly no. If it was somethig we could exchange,
+>>> we would not have to make a freeze in the first place to make sure that
+>>> only bugfixes are uploaded in cauldron.
+>>>
+>>> So the only way to maximize the time spent on bugfixes is to have F = Y,
+>>> and so C = 0. Ie, do like we do now.
+>>
+>> I really don't follow this line of reasoning.
+>> The focus on bug fixes starts with the freeze.  So a longer freeze would give more time to focus on
+>> bug fixes.
+>
+> The focus on bugfixing start with version freeze, since what introduce
+> problem is various changes, and new versions of softwares usually bring
+> new changes. Then we block all uploads except bug fixes, and then all
+> uploads unless very serious bug fixes ( ie, release blocker ). So the
+> focus start much before the last freeze, and you are quite unclear.
+
+It terms of freeze, I'm referring to the first freeze for the release.  The different stages will 
+happen (more or less) as they do now.
+
+>>> And unless you show that letting people work on cauldron will bring more
+>>> ressources , and more than the one we will lose du to people who do not
+>>> want to work on bugfixes and the release, I doubt this will change.
+>>
+>> Ok.  Obviously I need to clarify my point of view.
+>> Firstly, my assumption was that at least as much time would be spent on bug fixing during the
+>> longer freeze, but being less rushed, would tend to produce better quality results.  (And less
+>> aggravation for ennael)  (That is certainly how it works in the non-libre world.)
+>
+> You do not say much how you extend the freeze to be longer, nor even
+> that the freeze appear sooner, reread your mail. Nor what kind of freeze
+> would it be.
+
+If this scheme were adopted, such details would probably be best decided by those most experienced 
+with the process, above all ennael, and packagers such as yourself.  Offhand, maybe 2 weeks longer 
+would be adequate, to give less rush and compensate for contributions to non-freeze cauldron.
+(See also above.)
+
+> The only mention of the duration of the freeze is :
+> "A 1-month pre-release freeze would add 1 month to cauldron development
+> time."
+>
+> The version freeze started on 20 april
+> ( https://mageia.org/pipermail/mageia-dev/20110419/004066.html ), which
+> is more than 1 month. The release freeze was on 14 may, which is 2
+> weeks.
+>
+> Given that the version freeze is when we start to ask to people to focus
+> on bugfixes and when we prevent packagers from uploading newer versions
+> of packages, the proposed 1 month pre-release freeze is unclear and
+> unexplained.
+
+One month was an arbitrary figure, just to demonstrate the principle.  Obviously from what you say, 
+it would be longer.  (It did seem much much longer.)
+My idea was to have a somewhat (but not excessively) longer freeze period.
+
+>> I don't see how having the choice between contributing to pre-release or cauldron during the freeze
+>> will lead to us loosing _any_ contributors.
+>
+> We do not lose contributors, we lose the work of people that prefer to
+> work on cauldron by uploading new versions rather than bug fixing, and
+> from people that will prefer to test and use cauldron rather than the
+> future stable release, because that's easier, there is no deadline, nor
+> any obligation, and there is newer stuff.
+
+So you fear a lack of commitment by packagers.  That is a different question.
+I think that packagers can be motivated to help.  But maybe those demotivated by their inability to 
+contribute efficiently to pre-release will contribute to cauldron during the freeze ?  That's not a 
+loss.
+
+>> If during freeze, a packager has a choice between attempting to help with a bugfix in pre-release
+>> for a package with which s/he is not familiar, or contributing to cauldron for something with which
+>> s/he is familiar, it would be evidently more efficient to contribute to cauldron.
+>
+> You are placing a wrong dichotomy. The choice is not between "fixing
+> something efficiently on cauldron vs fixing un-efficiently on
+> pre-release", but between "fixing un-efficiently" vs "not fixing".
+
+In my world, those unable to contribute efficiently are much less motivated to contribute.  So this 
+change could have the effect to more motivate less experienced packagers.  Which could be a big 
+plus in the longer term.
+So although your dichotomy would apply to many packagers, particularly those more skilled, 
+definitely not all.
+
+>> Similarly, if a packager contributes a bug fix to pre-release, and a newer package already exists
+>> in cauldron for which the same bug fix must be applied, it is more efficient to apply the same
+>> patch right away, than to wait until freeze is over.  (Personnally I've encountered this sort of
+>> situation with similar but different software many times.  Any experienced programmer should
+>> understand this point.)
+>
+> With the current process, the fix is already applied for next cauldron
+> cycle, since the package is the same, there is no branching.
+
+Suppose that during freeze a packager discovers an important bug fix patch along with a newer 
+version.  The patch must be applied to both the current and newer version, the latter being blocked 
+from going into the freeze.  So the fix must be applied to both.  So why can't the packager put the 
+newer version into cauldron and apply the patch, if they have time ?  It would be a more efficient 
+use of time.
+
+>> So there are a lot of (admittedly small) synergies which should lead to packager time being more
+>> efficiently used.
+>> Not counting the likelyhood that some packagers would contribute somewhat more time, being able to
+>> contribute to cauldron during freeze.
+>> The major benefit in my mind is the longer freeze period.
+>
+> Which mean that we will have more outdated software if we freeze sooner.
+
+But not as outdated (on average during the cycle) as it would be if we go from a 6-month to 9-month 
+release cycle.  I'm suggesting a difference probably in the order of weeks.
+
+> Assuming that the pre-release freeze you are speaking about is what the
+> packagers know as "release freeze", this means the version freeze will
+> be sooner too. Assuming that what you call "pre-release freeze" is the
+> version freeze, then the freeze period would just be shorter.
+
+I was thinking of the first freeze, when there starts to be a lot of focus on bug fixes.  This 
+would allow immediate unfreeze of cauldron.  But maybe it would be better for the second stage.  A 
+lot of packages (if not most) will have a different version for the subsequent release, so bug 
+fixes -- even if the same patch -- would have to be applied separately for the subsequent release, 
+anyway.
+Any packages patched for pre-release could be simply copied back to cauldron, as well.  The process 
+could be even automated.
+
+> Also, your point seems to forget to take in account that people can
+> focus on bugfixs without any freeze of the distribution, yet, they do
+> not seems to do so.
+
+Basically I assumed that.
+
+> People rushing packages in the last minute as it always happen is the
+> prime example of why people prefer cauldron rather than bugfix.
+
+But doesn't blocking cauldron during freeze reinforce this behavior ?
+
+>> In any case, it seems to me that the bigger liability would be being out of sync with the 6-month
+>> release cycle of kde, gnome, as well as many other distros.
+>
+> s/many others distros/ubuntu and fedora/.
+
+OK.  Mostly just the 2 biggest distros.
+
+> Opensuse has a cycle of 8 months, Debian is not really time based ( and
+> is around 1 and 2 years ), Mandriva is gone on 1 year cycle, Arch,
+> Pclinuxos or others popular distributions from distrowatch do not seems
+> on a regular cycle. And as someone said, Mint is more released "when
+> ready after seeing fix on Ubuntu" than being a 6 months cycle ( even if
+> that's very similar ).
+
+I still see short_cauldron_freeze + copy_to_pre-release + unfreeze_cauldron as a better approach.
+Even if we do go for a 9-month release cycle.
+
+It is not as though we would be adopting the parallel development scheme of Mozilla, having a 
+number of parallel branches in development at the same time.  That would require much more work.
+It would only be for the freeze period.
+
+Having cauldron blocked for 6 weeks seems excessive.  Many packagers are left with little to 
+contribute.  And in certain cases, even those focused and efficient on bug fixes, will find it 
+advantageous to be able to make updates to cauldron which are currently blocked.
+
+another 2 cents :)
+
+-- 
+André
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005865.html b/zarb-ml/mageia-dev/2011-June/005865.html new file mode 100644 index 000000000..d3d222469 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005865.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] [RPM] cauldron core/release networkmanager-0.8.9997-0.1.1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release networkmanager-0.8.9997-0.1.1.mga2

+ Balcaen John + mikala at mageia.org +
+ Mon Jun 20 04:10:39 CEST 2011 +

+
+ +
Le dimanche 19 juin 2011 20:00:20, JA Magallón a écrit :
+[...]
+> 
+> So i short it seems that wpa_supplicant has to be compiled with dbus support 
+for
+> new networkmanager. I also see a patch in src.rpm to disable dbus....
+I'll disable the patch & add 2 more patchs from fedora, could you please test 
+the new wpa_supplicant ?
+The package should land in core/updates_testing
+
+
+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-June/005866.html b/zarb-ml/mageia-dev/2011-June/005866.html new file mode 100644 index 000000000..305cb763c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005866.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ Remco Rijnders + remco at webconquest.com +
+ Mon Jun 20 08:38:47 CEST 2011 +

+
+ +
On Sun, Jun 19, 2011 at 09:33:44PM +0200, lebarhon wrote:
+>Le 19/06/2011 10:28, Wolfgang Bornath a écrit :
+>>Nobody said anything against your efforts although I don't see any
+>>reason there (and I haven't seen any discussion in the webteam where
+>>it was decided to do so),
+>Who the hell are you to dare say I am a liar !
+
+Guys, guys...
+
+Can we tone it down a bit please? I am sure that we all are here to 
+participate and help Mageia succeed as a distribution and community. To 
+that end, we should always assume that all parties have a shared interest 
+in this, even when one acts or talks differently from what you'd 
+personally would have done.
+
+At the risk of stealing rda's job, have a look at http://hugs.mageia.org/ 
+:-)
+
+For what it's worth, I did find it useful to read the forum comments on 
+the topic on this list, even though I did not respond to any of it as it 
+is one of the few issues I have no outspoken opinion on ;-)
+
+Let's keep it civil, and at the same time refrain from critisizing each 
+other too much?
+
+Using the royal plural, we thank you all in advance :)
+
+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/20110620/c8601778/attachment.asc>
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005867.html b/zarb-ml/mageia-dev/2011-June/005867.html new file mode 100644 index 000000000..d038de493 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005867.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion - messages from the forum + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion - messages from the forum

+ andre999 + andr55 at laposte.net +
+ Mon Jun 20 09:38:17 CEST 2011 +

+
+ +
Remco Rijnders a écrit :
+> On Sun, Jun 19, 2011 at 09:33:44PM +0200, lebarhon wrote:
+>> Le 19/06/2011 10:28, Wolfgang Bornath a écrit :
+>>> Nobody said anything against your efforts although I don't see any
+>>> reason there (and I haven't seen any discussion in the webteam where
+>>> it was decided to do so),
+>> Who the hell are you to dare say I am a liar !
+>
+> Guys, guys...
+>
+> Can we tone it down a bit please? I am sure that we all are here to
+> participate and help Mageia succeed as a distribution and community. To
+> that end, we should always assume that all parties have a shared
+> interest in this, even when one acts or talks differently from what
+> you'd personally would have done.
+>
+> At the risk of stealing rda's job, have a look at
+> http://hugs.mageia.org/ :-)
+>
+> For what it's worth, I did find it useful to read the forum comments on
+> the topic on this list, even though I did not respond to any of it as it
+> is one of the few issues I have no outspoken opinion on ;-)
+>
+> Let's keep it civil, and at the same time refrain from critisizing each
+> other too much?
+>
+> Using the royal plural, we thank you all in advance :)
+>
+> Cheers,
+>
+> Remco
++1
+
+-- 
+André
+
+ + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005868.html b/zarb-ml/mageia-dev/2011-June/005868.html new file mode 100644 index 000000000..dc25d45fb --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005868.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] [RPM] cauldron core/release valgrind-3.6.1-3.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release valgrind-3.6.1-3.mga2

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Mon Jun 20 11:24:24 CEST 2011 +

+
+ +
On 7 June 2011 16:10, Mageia Team <buildsystem-daemon at mageia.org> wrote:
+> dmorgan <dmorgan> 3.6.1-3.mga1:
+> + Revision: 101519
+> - Provide devel subpackage  ( partial merge of mdv commit 659516)
+
+As always, when one moves files between subpackages or to a new subpackage,
+conflicts tags should be added in order to ensure urpmi will put both packages
+in the same transaction:
+
+Installation failed:
+    file /usr/include/valgrind/memcheck.h from install of
+valgrind-devel-3.6.1-3.mga2.x86_64 conflicts with file from package
+valgrind-3.6.0-2.mga1.x86_64
+    file /usr/lib64/pkgconfig/valgrind.pc from install of
+valgrind-devel-3.6.1-3.mga2.x86_64 conflicts with file from package
+valgrind-3.6.0-2.mga1.x86_64
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005869.html b/zarb-ml/mageia-dev/2011-June/005869.html new file mode 100644 index 000000000..d4d039c83 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005869.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] [RPM] cauldron core/release extremetuxracer-0.5-0.beta.7.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release extremetuxracer-0.5-0.beta.7.mga2

+ Olav Vitters + olav at vitters.nl +
+ Mon Jun 20 11:44:12 CEST 2011 +

+
+ +
On Mon, Jun 20, 2011 at 10:21:23AM +0200, Mageia Team wrote:
+> Summary     : %{Summary}
+
+^^ typo
+
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005870.html b/zarb-ml/mageia-dev/2011-June/005870.html new file mode 100644 index 000000000..0072e7467 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005870.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] [RPM] cauldron core/release extremetuxracer-0.5-0.beta.7.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release extremetuxracer-0.5-0.beta.7.mga2

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Mon Jun 20 11:51:16 CEST 2011 +

+
+ +
On 20 June 2011 11:44, Olav Vitters <olav at vitters.nl> wrote:
+> On Mon, Jun 20, 2011 at 10:21:23AM +0200, Mageia Team wrote:
+>> Summary     : %{Summary}
+>
+> ^^ typo
+
+should have been rejected...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005871.html b/zarb-ml/mageia-dev/2011-June/005871.html new file mode 100644 index 000000000..d460ad243 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005871.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] [RPM] cauldron core/release extremetuxracer-0.5-0.beta.7.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release extremetuxracer-0.5-0.beta.7.mga2

+ José Jorge + jjorge at free.fr +
+ Mon Jun 20 12:01:04 CEST 2011 +

+
+ +
Le lundi 20 juin 2011 11:51:16, Thierry Vignaud a écrit :
+> On 20 June 2011 11:44, Olav Vitters <olav at vitters.nl> wrote:
+> > On Mon, Jun 20, 2011 at 10:21:23AM +0200, Mageia Team wrote:
+> >> Summary     : %{Summary}
+> > 
+> > ^^ typo
+> 
+> should have been rejected...
+
+Sorry, this is my fault. Corrected.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005872.html b/zarb-ml/mageia-dev/2011-June/005872.html new file mode 100644 index 000000000..2233c362b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005872.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] [RPM] cauldron core/release extremetuxracer-0.5-0.beta.7.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release extremetuxracer-0.5-0.beta.7.mga2

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Mon Jun 20 12:17:23 CEST 2011 +

+
+ +
2011/6/20 José Jorge <jjorge at free.fr>:
+>> >> Summary     : %{Summary}
+>> >
+>> > ^^ typo
+>>
+>> should have been rejected...
+>
+> Sorry, this is my fault. Corrected.
+
+Not yet.
+BS must be patched to reject such things
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005873.html b/zarb-ml/mageia-dev/2011-June/005873.html new file mode 100644 index 000000000..204ae1b16 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005873.html @@ -0,0 +1,117 @@ + + + + [Mageia-dev] [RPM] cauldron core/release freedoom-0.7-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release freedoom-0.7-1.mga2

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Mon Jun 20 12:46:32 CEST 2011 +

+
+ +
On Mon, 20 Jun 2011, Mageia Team wrote:
+
+> Name        : freedoom                     Relocations: (not relocatable)
+
+> Summary     : Complete independent Doom game
+> Description :
+> Freedoom is a project to create a complete, free Doom IWAD
+> file. Combined with the GPLed Doom source code, it will create a
+> completely free Doom-based game.
+>
+> To play it, a game engine such as prboom is required.
+>
+> In order to play it with prboom, install prboom and type:
+>
+> $ prboom -iwad /usr/share/games/doom/freedoom.wad
+>
+> zezinho <zezinho> 0.7-1.mga2:
+> + Revision: 110385
+> - added a suggest for prboom qui get a playable game
+> - imported package freedoom
+
+Why not add a real dependency on prboom, a .desktop file and icon(s) so 
+people can play this game by selecting it from the applications menu?
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005874.html b/zarb-ml/mageia-dev/2011-June/005874.html new file mode 100644 index 000000000..c160efd67 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005874.html @@ -0,0 +1,137 @@ + + + + [Mageia-dev] new webkit in cauldron + + + + + + + + + +

[Mageia-dev] new webkit in cauldron

+ Dexter Morgan + dmorganec at gmail.com +
+ Mon Jun 20 13:25:17 CEST 2011 +

+
+ +
hi,
+
+new webkit is on the BS and will land in cauldron soon.
+
+we will need to rebuild packages because of a change of major. I will
+do it but if ppl wants to help you are welcome.
+
+
+$ urpmq --whatrequires lib64webkitgtk1.0_2
+anjuta
+banshee
+cairo-dock-weblets
+claws-mail-fancy-plugin
+eclipse-rcp
+eclipse-swt
+empathy
+epiphany
+epiphany-extensions
+gimp
+gmpc-wikipedia
+gnucash
+google-gadgets-gtk
+gtkpod
+handbrake
+lib64devhelp-2_1
+lib64ggadget-webkitjs0
+lib64peas0
+lib64seed0
+lib64webkitgtk1.0-devel
+lib64webkitgtk1.0_2
+libproxy-webkit
+liferea
+midori
+miro
+perl-Gtk2-WebKit
+pino
+python-webkitgtk
+shotwell
+webkit
+webkit-gtklauncher
+webkit-sharp
+webkit1.0
+yelp
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005875.html b/zarb-ml/mageia-dev/2011-June/005875.html new file mode 100644 index 000000000..902885432 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005875.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] perl 5.14.1 on its way + + + + + + + + + +

[Mageia-dev] perl 5.14.1 on its way

+ Jerome Quelin + jquelin at gmail.com +
+ Mon Jun 20 13:43:48 CEST 2011 +

+
+ +
On 11/06/19 23:39 +0300, Anssi Hannula wrote:
+> or to find all packages having a version-specific require on another
+> version than 5.14.1:
+> 
+> $ urpmf --requires ':perl\[== (?!2:5.14.1[-\]])'
+
+thanks.
+jérôme 
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005876.html b/zarb-ml/mageia-dev/2011-June/005876.html new file mode 100644 index 000000000..9c7b91c9a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005876.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] [RPM] cauldron core/release freedoom-0.7-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release freedoom-0.7-1.mga2

+ José Jorge + lists.jjorge at free.fr +
+ Mon Jun 20 13:49:16 CEST 2011 +

+
+ +
> zezinho <zezinho> 0.7-1.mga2:
+> + Revision: 110385
+> - added a suggest for prboom qui get a playable game
+> - imported package freedoom
+
+> Why not add a real dependency on prboom, a .desktop file and icon(s) so 
+> people can play this game by selecting it from the applications menu?
+
+In fact, it works : the suggest will pull prboom, which will launch with freedoom iwads.
+I did not put a real dependency as some other doom engines can also run freedoom iwad, so people will be able to remove prboom if they don't like it.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005877.html b/zarb-ml/mageia-dev/2011-June/005877.html new file mode 100644 index 000000000..dd914a38d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005877.html @@ -0,0 +1,113 @@ + + + + [Mageia-dev] [RPM] cauldron core/release freedoom-0.7-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release freedoom-0.7-1.mga2

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Mon Jun 20 14:30:30 CEST 2011 +

+
+ +
On Mon, 20 Jun 2011, José Jorge wrote:
+
+>> zezinho <zezinho> 0.7-1.mga2:
+>> + Revision: 110385
+>> - added a suggest for prboom qui get a playable game
+>> - imported package freedoom
+>
+>> Why not add a real dependency on prboom, a .desktop file and icon(s) so
+>> people can play this game by selecting it from the applications menu?
+>
+> In fact, it works : the suggest will pull prboom, which will launch with 
+> freedoom iwads. I did not put a real dependency as some other doom 
+> engines can also run freedoom iwad, so people will be able to remove 
+> prboom if they don't like it.
+
+The problem is that without a compatible game engine this package is not 
+functional. Suggests can be used to add features, but not to get the 
+basics working.
+
+If there are other engines in mageia, use provides + alternatives to allow 
+selecting one of them.
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005878.html b/zarb-ml/mageia-dev/2011-June/005878.html new file mode 100644 index 000000000..07df81968 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005878.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] rpm policy : Spec file cleaning + + + + + + + + + +

[Mageia-dev] rpm policy : Spec file cleaning

+ Dexter Morgan + dmorganec at gmail.com +
+ Mon Jun 20 14:51:02 CEST 2011 +

+
+ +
hello,
+
+A new day a new tip :)
+
+
+If in you specfile the %defattr is only %defattr(-,root,root)  you can
+omit it, rpm will handle it automatically.
+
+Do not worry about  compatibility for old rpms except if you want to
+support distros with a rpm from 2004 ;)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005879.html b/zarb-ml/mageia-dev/2011-June/005879.html new file mode 100644 index 000000000..b8c5391b7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005879.html @@ -0,0 +1,137 @@ + + + + [Mageia-dev] new webkit in cauldron + + + + + + + + + +

[Mageia-dev] new webkit in cauldron

+ Funda Wang + fundawang at gmail.com +
+ Mon Jun 20 16:19:54 CEST 2011 +

+
+ +
some of them need love from webkitgtk3, i think.
+
+2011/6/20 Dexter Morgan <dmorganec at gmail.com>:
+> hi,
+>
+> new webkit is on the BS and will land in cauldron soon.
+>
+> we will need to rebuild packages because of a change of major. I will
+> do it but if ppl wants to help you are welcome.
+>
+>
+> $ urpmq --whatrequires lib64webkitgtk1.0_2
+> anjuta
+> banshee
+> cairo-dock-weblets
+> claws-mail-fancy-plugin
+> eclipse-rcp
+> eclipse-swt
+> empathy
+> epiphany
+> epiphany-extensions
+> gimp
+> gmpc-wikipedia
+> gnucash
+> google-gadgets-gtk
+> gtkpod
+> handbrake
+> lib64devhelp-2_1
+> lib64ggadget-webkitjs0
+> lib64peas0
+> lib64seed0
+> lib64webkitgtk1.0-devel
+> lib64webkitgtk1.0_2
+> libproxy-webkit
+> liferea
+> midori
+> miro
+> perl-Gtk2-WebKit
+> pino
+> python-webkitgtk
+> shotwell
+> webkit
+> webkit-gtklauncher
+> webkit-sharp
+> webkit1.0
+> yelp
+>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005880.html b/zarb-ml/mageia-dev/2011-June/005880.html new file mode 100644 index 000000000..c1605d999 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005880.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] new webkit in cauldron + + + + + + + + + +

[Mageia-dev] new webkit in cauldron

+ Dexter Morgan + dmorganec at gmail.com +
+ Mon Jun 20 16:30:45 CEST 2011 +

+
+ +
On Mon, Jun 20, 2011 at 4:19 PM, Funda Wang <fundawang at gmail.com> wrote:
+> some of them need love from webkitgtk3, i think.
+
+if you can help, you're more than welcome :)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005881.html b/zarb-ml/mageia-dev/2011-June/005881.html new file mode 100644 index 000000000..695066c5b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005881.html @@ -0,0 +1,113 @@ + + + + [Mageia-dev] KDE/kglobalaccel: won't use XF86Launch6-9 keys + + + + + + + + + +

[Mageia-dev] KDE/kglobalaccel: won't use XF86Launch6-9 keys

+ P. Christeas + xrg at linux.gr +
+ Mon Jun 20 16:48:41 CEST 2011 +

+
+ +
Hi, just wanted your hints about a situation that drives me crazy:
+
+I'm using xkb "inet(acer_laptop)" with some modified tables (symbols/inet) so 
+that my Acer 5720 laptop maps its multimedia keys into useful keysyms.
+
+So far, this had worked long. But, a few days ago, when I restarted xorg into 
+Mageia 1.0 (had -rcX before), I have this strange phenomenon:
+
+xev does generate events for _XF86Launch6-9_, XF86LaunchA, KDE senses them, 
+can bind them to accelerators and the mouse cursor responds to them.
+
+But, I can no longer use them to "switch to desktop 1-3". Just as if there is 
+a particular filter that prevents /these/ keysyms for global accelerators. Or 
+is there any other hard-coded mapping that prevails?
+
+Dbus, through qdbusviewer, shows all other actions but them.
+
+Is that a bug, is there any other place to look for hints?
+
+I tried also to test with a new user. Didn't work either.
+
+-- 
+Say NO to spam and viruses. Stop using Microsoft Windows!
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005882.html b/zarb-ml/mageia-dev/2011-June/005882.html new file mode 100644 index 000000000..caf58126c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005882.html @@ -0,0 +1,67 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Barry Jackson + zen25000 at zen.co.uk +
+ Mon Jun 20 17:13:23 CEST 2011 +

+
+ +
Ping.
+
+Can someone please add this to Mageia ? - latest is attached to :-
+
+https://bugs.mageia.org/show_bug.cgi?id=154
+
+Barry.
+
+
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005883.html b/zarb-ml/mageia-dev/2011-June/005883.html new file mode 100644 index 000000000..a7d14c8a5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005883.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] (no subject) + + + + + + + + + +

[Mageia-dev] (no subject)

+ Larry Braden + lbradenjr at verizon.net +
+ Mon Jun 20 19:10:02 CEST 2011 +

+
+ +
+
+Sent from my Samsung smartphone on AT&T
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005884.html b/zarb-ml/mageia-dev/2011-June/005884.html new file mode 100644 index 000000000..af10d18e7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005884.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] Q + + + + + + + + + +

[Mageia-dev] Q

+ Larry Braden + lbradenjr at verizon.net +
+ Mon Jun 20 19:10:02 CEST 2011 +

+
+ +
+
+Sent from my Samsung smartphone on AT&T
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005885.html b/zarb-ml/mageia-dev/2011-June/005885.html new file mode 100644 index 000000000..f5c0a8ab3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005885.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] Q + + + + + + + + + +

[Mageia-dev] Q

+ Cazzaniga Sandro + cazzaniga.sandro at gmail.com +
+ Mon Jun 20 20:17:18 CEST 2011 +

+
+ +
Le 20/06/2011 19:10, Larry Braden a écrit :
+> 
+> 
+> Sent from my Samsung smartphone on AT&T
+
+Stop that!
+
+-- 
+Sandro Cazzaniga - https://lederniercoupdarchet.wordpress.com
+IRC: Kharec (irc.freenode.net)
+Software/Hardware geek
+Conceptor
+Magnum's Coordinator/editor (http://magnum.tuxfamily.org)
+Mageia contributor
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005886.html b/zarb-ml/mageia-dev/2011-June/005886.html new file mode 100644 index 000000000..d2b91427e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005886.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] Mageia 2 - Improving educational programs + + + + + + + + + +

[Mageia-dev] Mageia 2 - Improving educational programs

+ mammig_linux mammig_linux + mammig.linux at gmail.com +
+ Mon Jun 20 21:26:58 CEST 2011 +

+
+ +
hello,
+
+here : http://mageia.org/wiki/doku.php?id=sigedu
+you have the wiki with the lists of "Already packaged" and "To be packaged".
+I take the software of edubuntu and those here (
+http://svnweb.mageia.org/packages/cauldron/task-edu/current/SPECS/task-edu.spec?revision=98765&view=markup
+)
+
+Of course, the educational version of Mageia should be easy to use for
+parents and kids. I know a lot of parents with windows, who use live
+cd of educational linux for their kids.
+
+I will continue my list with the edu.kde.org softwares and then i will
+see the website
+
+see you
+mammig
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005887.html b/zarb-ml/mageia-dev/2011-June/005887.html new file mode 100644 index 000000000..2fd30b9fe --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005887.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] Q + + + + + + + + + +

[Mageia-dev] Q

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Mon Jun 20 22:13:35 CEST 2011 +

+
+ +
Op maandag 20 juni 2011 20:17:18 schreef Cazzaniga Sandro:
+> Le 20/06/2011 19:10, Larry Braden a écrit :
+> > Sent from my Samsung smartphone on AT&T
+> 
+> Stop that!
+
+it's just spam, we can just remove the email from list and identity... don't 
+get so worked up about it...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005888.html b/zarb-ml/mageia-dev/2011-June/005888.html new file mode 100644 index 000000000..9930093ce --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005888.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] glib-compile-schemas? + + + + + + + + + +

[Mageia-dev] glib-compile-schemas?

+ Funda Wang + fundawang at gmail.com +
+ Tue Jun 21 11:00:56 CEST 2011 +

+
+ +
Hello,
+
+Look at this change,
+
+http://svnweb.mageia.org/packages/cauldron/anjuta-extras/current/SPECS/anjuta-extras.spec?view=patch&r1=111189&r2=111198&pathrev=111199
+
+I remembered such a post/postun script is handled by rpm triggers? see:
+
+/var/lib/rpm/filetriggers/glib-compile-schemas.*
+
+Will it need to be handled separately in individual package?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005889.html b/zarb-ml/mageia-dev/2011-June/005889.html new file mode 100644 index 000000000..f434438ad --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005889.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] [RPM] cauldron core/release freedoom-0.7-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release freedoom-0.7-1.mga2

+ José Jorge + jjorge at free.fr +
+ Tue Jun 21 13:39:18 CEST 2011 +

+
+ +
Le lundi 20 juin 2011 14:30:30, Christiaan Welvaart a écrit :
+> The problem is that without a compatible game engine this package is not
+> functional. Suggests can be used to add features, but not to get the
+> basics working.
+> 
+> If there are other engines in mageia, use provides + alternatives to allow
+> selecting one of them.
+> 
+I feel you are right. As for now, no other game engine is there, and a 'urpme 
+prboom' makes freedoom not functional.
+
+Suggests goto provides ;-)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005890.html b/zarb-ml/mageia-dev/2011-June/005890.html new file mode 100644 index 000000000..65945ad6e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005890.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] Can I be of help? + + + + + + + + + +

[Mageia-dev] Can I be of help?

+ Garth Hoyman + gchoyman at gmail.com +
+ Tue Jun 21 18:01:18 CEST 2011 +

+
+ +
I've been on mostly Ubuntu for a couple of years
+Mageia looks like my replacement
+I like the community & that it is on the redhat/fedora side of the street,
+without being in the pocket of a corporation, like Suse/Ubuntu
+
+I can do a few things
+like follow specific instructions [copy n paste] on a terminal
+modify a configuration file [ after saving a copy]
+give detailed feedback for when a procedure breaks down
+I don't mind running a test build on a virtual box
+
+I'm about  to do a proper install of magi 1 on a
+HP DC5000 SFF
+2.3 ghz
+1g ram
+
+Garthhh
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110621/5f823db4/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005891.html b/zarb-ml/mageia-dev/2011-June/005891.html new file mode 100644 index 000000000..70491a1aa --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005891.html @@ -0,0 +1,125 @@ + + + + [Mageia-dev] Can I be of help? + + + + + + + + + +

[Mageia-dev] Can I be of help?

+ Daniel Kreuter + daniel.kreuter85 at googlemail.com +
+ Tue Jun 21 18:04:59 CEST 2011 +

+
+ +
On Tue, Jun 21, 2011 at 6:01 PM, Garth Hoyman <gchoyman at gmail.com> wrote:
+
+> I've been on mostly Ubuntu for a couple of years
+> Mageia looks like my replacement
+> I like the community & that it is on the redhat/fedora side of the street,
+> without being in the pocket of a corporation, like Suse/Ubuntu
+>
+> I can do a few things
+> like follow specific instructions [copy n paste] on a terminal
+> modify a configuration file [ after saving a copy]
+> give detailed feedback for when a procedure breaks down
+> I don't mind running a test build on a virtual box
+>
+> I'm about  to do a proper install of magi 1 on a
+> HP DC5000 SFF
+> 2.3 ghz
+> 1g ram
+>
+> Garthhh
+>
+
+
+Hello Garthhh,
+
+starting with testing in a vm would be a good starting point. If you are
+interested in other parts you can look at our wiki for a specific group and
+ask the team you are interested in on irc or ml.
+-- 
+Mit freundlichen Grüßen
+
+Greetings
+
+Daniel Kreuter
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110621/badada64/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005892.html b/zarb-ml/mageia-dev/2011-June/005892.html new file mode 100644 index 000000000..40310b88c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005892.html @@ -0,0 +1,63 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Florian Hubold + doktor5000 at arcor.de +
+ Tue Jun 21 18:44:21 CEST 2011 +

+
+ +
Am 14.06.2011 17:40, schrieb Angelo Naselli:
+>> I would prefer to find a better way than suggest :/
+>> ( like a meta rpm pulling mgarepo, bm, the policy and rpmlint ).
+> something like task-mageia-devel?
+>
+> Angelo
+Maybe more something like task-mageia-packaging?
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005893.html b/zarb-ml/mageia-dev/2011-June/005893.html new file mode 100644 index 000000000..873b3685c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005893.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] [RPM] cauldron core/release networkmanager-0.8.9997-0.1.1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release networkmanager-0.8.9997-0.1.1.mga2

+ Balcaen John + mikala at mageia.org +
+ Tue Jun 21 19:09:37 CEST 2011 +

+
+ +
Le dimanche 19 juin 2011 23:10:39, Balcaen John a écrit :
+> Le dimanche 19 juin 2011 20:00:20, JA Magallón a écrit :
+> [...]
+> > 
+> > So i short it seems that wpa_supplicant has to be compiled with dbus 
+support 
+> for
+> > new networkmanager. I also see a patch in src.rpm to disable dbus....
+> I'll disable the patch & add 2 more patchs from fedora, could you please 
+test 
+> the new wpa_supplicant ?
+> The package should land in core/updates_testing
+> 
+Ok i was able to reproduce on my laptopt & the last wpa_supplicant in 
+core/release should fix this problem.
+-- 
+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-June/005894.html b/zarb-ml/mageia-dev/2011-June/005894.html new file mode 100644 index 000000000..8f4cc449c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005894.html @@ -0,0 +1,115 @@ + + + + [Mageia-dev] Updates process is now available + + + + + + + + + +

[Mageia-dev] Updates process is now available

+ Damien Lallement + mageia at damsweb.net +
+ Tue Jun 21 18:57:22 CEST 2011 +

+
+ +
Hello all,
+
+security, qa and sysadmin team worked on the qa/updates process to 
+provide updates as soon as possible.
+All is now ready (boklm is finalizing a scrip to move updates from 
+"testing" to "updates"). This script will be uses by security team 
+members and a few QA people to push updates.
+
+You can now read:
+- http://www.mageia.org/wiki/doku.php?id=updates_policy
+- http://www.mageia.org/wiki/doku.php?id=qa_updates
+
+A new ML has been created: qa-bugs at ml.mageia.org. It will receive all 
+the updates requests and will be the main QA contact for bugzilla.
+You can join it if you want to be part of the QA people working on 
+updates (security or not).
+
+A saved search has been added to bugzilla to catch all updates waiting 
+for QA validation: 
+https://bugs.mageia.org/buglist.cgi?cmdtype=runnamed&namedcmd=Updates%20waiting%20for%20QA
+
+For more info, please ask here on on #mageia-dev or #mageia-qa
+Let's go to work on updates!
+-- 
+Damien Lallement
+Treasurer of Mageia.Org
+
+twitter: damsweb - IRC: damsweb/coincoin
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005895.html b/zarb-ml/mageia-dev/2011-June/005895.html new file mode 100644 index 000000000..007d444be --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005895.html @@ -0,0 +1,113 @@ + + + + [Mageia-dev] Updates process is now available + + + + + + + + + +

[Mageia-dev] Updates process is now available

+ Remco Rijnders + remco at webconquest.com +
+ Tue Jun 21 20:19:31 CEST 2011 +

+
+ +
On Tue, Jun 21, 2011 at 06:57:22PM +0200, Damien Lallement wrote:
+>Hello all,
+>
+>security, qa and sysadmin team worked on the qa/updates process to 
+>provide updates as soon as possible.
+>All is now ready (boklm is finalizing a scrip to move updates from 
+>"testing" to "updates"). This script will be uses by security team 
+>members and a few QA people to push updates.
+
+Awesome news!
+
+>A saved search has been added to bugzilla to catch all updates 
+>waiting for QA validation: https://bugs.mageia.org/buglist.cgi?cmdtype=runnamed&namedcmd=Updates%20waiting%20for%20QA
+
+That link isn't working for me :-(
+
+Thanks and regards,
+
+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/20110621/741472bc/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005896.html b/zarb-ml/mageia-dev/2011-June/005896.html new file mode 100644 index 000000000..89d5daf38 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005896.html @@ -0,0 +1,113 @@ + + + + [Mageia-dev] Updates process is now available + + + + + + + + + +

[Mageia-dev] Updates process is now available

+ Dexter Morgan + dmorganec at gmail.com +
+ Tue Jun 21 20:34:47 CEST 2011 +

+
+ +
On Tue, Jun 21, 2011 at 8:19 PM, Remco Rijnders <remco at webconquest.com> wrote:
+> On Tue, Jun 21, 2011 at 06:57:22PM +0200, Damien Lallement wrote:
+>>
+>> Hello all,
+>>
+>> security, qa and sysadmin team worked on the qa/updates process to provide
+>> updates as soon as possible.
+>> All is now ready (boklm is finalizing a scrip to move updates from
+>> "testing" to "updates"). This script will be uses by security team members
+>> and a few QA people to push updates.
+>
+> Awesome news!
+>
+>> A saved search has been added to bugzilla to catch all updates waiting for
+>> QA validation:
+>> https://bugs.mageia.org/buglist.cgi?cmdtype=runnamed&namedcmd=Updates%20waiting%20for%20QA
+>
+> That link isn't working for me :-(
+>
+> Thanks and regards,
+
+
+the URL should be : http://tinyurl.com/3vn23ob     the 'Updates
+waiting for QA'  is available on the available searches in the
+preferences.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005897.html b/zarb-ml/mageia-dev/2011-June/005897.html new file mode 100644 index 000000000..2072e0366 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005897.html @@ -0,0 +1,114 @@ + + + + [Mageia-dev] [RPM] cauldron core/release yelp-3.0.3-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release yelp-3.0.3-1.mga2

+ Dick Gevers + dvgevers at xs4all.nl +
+ Tue Jun 21 21:00:30 CEST 2011 +

+
+ +
On Tue, 21 Jun 2011 00:31:17 +0200 (CEST), Mageia Team wrote about [RPM]
+cauldron core/release yelp-3.0.3-1.mga2:
+
+>jonund Group       : Graphical desktop/GNOME       Source RPM: (none)
+>Size        : 1271166                          License: GPLv2+
+>Signature   : (none)
+>Packager    : Mageia Team <http://www.mageia.org>
+>URL         : http://live.gnome.org/Yelp
+>Summary     : GNOME 2 help browser
+>Description :
+>Help browser for GNOME 2 which supports docbook documents, info and man.
+>
+>dmorgan <dmorgan> 3.0.3-1.mga2:
+>+ Revision: 110795
+
+Methinks it's GNOME 3 ?
+
+HTH
+
+Cheers!
+=Dick Gevers=
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005898.html b/zarb-ml/mageia-dev/2011-June/005898.html new file mode 100644 index 000000000..1e9bd8a28 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005898.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] Updates process is now available + + + + + + + + + +

[Mageia-dev] Updates process is now available

+ Cazzaniga Sandro + cazzaniga.sandro at gmail.com +
+ Tue Jun 21 21:04:58 CEST 2011 +

+
+ +
Le 21/06/2011 20:19, Remco Rijnders a écrit :
+> On Tue, Jun 21, 2011 at 06:57:22PM +0200, Damien Lallement wrote:
+>> Hello all,
+>>
+>> security, qa and sysadmin team worked on the qa/updates process to
+>> provide updates as soon as possible.
+
+Thanks to them and congrats!
+
+-- 
+Sandro Cazzaniga - https://lederniercoupdarchet.wordpress.com
+IRC: Kharec (irc.freenode.net)
+Software/Hardware geek
+Conceptor
+Magnum's Coordinator/editor (http://magnum.tuxfamily.org)
+Mageia contributor
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005899.html b/zarb-ml/mageia-dev/2011-June/005899.html new file mode 100644 index 000000000..11066c77d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005899.html @@ -0,0 +1,117 @@ + + + + [Mageia-dev] [RPM] cauldron core/release yelp-3.0.3-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release yelp-3.0.3-1.mga2

+ Dexter Morgan + dmorganec at gmail.com +
+ Tue Jun 21 22:11:56 CEST 2011 +

+
+ +
On Tue, Jun 21, 2011 at 9:00 PM, Dick Gevers <dvgevers at xs4all.nl> wrote:
+> On Tue, 21 Jun 2011 00:31:17 +0200 (CEST), Mageia Team wrote about [RPM]
+> cauldron core/release yelp-3.0.3-1.mga2:
+>
+>>jonund Group       : Graphical desktop/GNOME       Source RPM: (none)
+>>Size        : 1271166                          License: GPLv2+
+>>Signature   : (none)
+>>Packager    : Mageia Team <http://www.mageia.org>
+>>URL         : http://live.gnome.org/Yelp
+>>Summary     : GNOME 2 help browser
+>>Description :
+>>Help browser for GNOME 2 which supports docbook documents, info and man.
+>>
+>>dmorgan <dmorgan> 3.0.3-1.mga2:
+>>+ Revision: 110795
+>
+> Methinks it's GNOME 3 ?
+>
+> HTH
+>
+> Cheers!
+> =Dick Gevers=
+>
+>
+
+good catch :)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005900.html b/zarb-ml/mageia-dev/2011-June/005900.html new file mode 100644 index 000000000..9ac8d033a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005900.html @@ -0,0 +1,134 @@ + + + + [Mageia-dev] Updates process is now available + + + + + + + + + +

[Mageia-dev] Updates process is now available

+ Michael Scherer + misc at zarb.org +
+ Wed Jun 22 00:23:32 CEST 2011 +

+
+ +
Le mardi 21 juin 2011 à 18:57 +0200, Damien Lallement a écrit :
+> Hello all,
+> 
+> security, qa and sysadmin team worked on the qa/updates process to 
+> provide updates as soon as possible.
+> All is now ready (boklm is finalizing a scrip to move updates from 
+> "testing" to "updates"). This script will be uses by security team 
+> members and a few QA people to push updates.
+> 
+> You can now read:
+> - http://www.mageia.org/wiki/doku.php?id=updates_policy
+> - http://www.mageia.org/wiki/doku.php?id=qa_updates
+
+I have some questions about the page 
+http://www.mageia.org/wiki/doku.php?id=qa_updates
+
+"It's a new package fixing a bug (security or not) or adding a missing
+feature."
+
+Adding a missing feature is not part of a update as we defined it so
+this part seems strange to me, could this one be clarified ?
+
+
+"Don't forget to enable the i586 medias on x86_64 systems" 
+
+I do not understand why is should be needed ( except for nspluginwrapper
+). Is there something to watch for when doing this ?
+
+"Write an validation message"
+
+I do not understand what is the validation message about, could we
+clarify the goal of the message, or add a example ? 
+
+"Rewrite the advisory for the secteam (ask the developper to provide the
+advisory if missing)"
+
+IIRC, the advisory should have been provided by the packager ( according
+to the others page ), so why rewrite it ? Isn't it a left over ?
+Unless what it mean "check that the packager said something that normal
+people will understand" ? 
+Also, on the page, "developer", is "upstream developer", or "packager
+who take care of the update" ?
+
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005901.html b/zarb-ml/mageia-dev/2011-June/005901.html new file mode 100644 index 000000000..789941b76 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005901.html @@ -0,0 +1,70 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ andre999 + andr55 at laposte.net +
+ Wed Jun 22 00:28:58 CEST 2011 +

+
+ +
Florian Hubold a écrit :
+>
+> Am 14.06.2011 17:40, schrieb Angelo Naselli:
+>>> I would prefer to find a better way than suggest :/
+>>> ( like a meta rpm pulling mgarepo, bm, the policy and rpmlint ).
+>> something like task-mageia-devel?
+>>
+>> Angelo
+> Maybe more something like task-mageia-packaging?
+
+That sounds better :)
+
+-- 
+André
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005902.html b/zarb-ml/mageia-dev/2011-June/005902.html new file mode 100644 index 000000000..f62cb50a2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005902.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] glib-compile-schemas? + + + + + + + + + +

[Mageia-dev] glib-compile-schemas?

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Wed Jun 22 06:03:08 CEST 2011 +

+
+ +
On 21 June 2011 11:00, Funda Wang <fundawang at gmail.com> wrote:
+> Hello,
+>
+> Look at this change,
+>
+> http://svnweb.mageia.org/packages/cauldron/anjuta-extras/current/SPECS/anjuta-extras.spec?view=patch&r1=111189&r2=111198&pathrev=111199
+>
+> I remembered such a post/postun script is handled by rpm triggers? see:
+>
+> /var/lib/rpm/filetriggers/glib-compile-schemas.*
+>
+> Will it need to be handled separately in individual package?
+>
+
+I am not sure, I think that change should be reverted; indeed, it's
+already handled by an rpm filetrigger...
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005903.html b/zarb-ml/mageia-dev/2011-June/005903.html new file mode 100644 index 000000000..194784e71 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005903.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] [RPM] cauldron core/release valgrind-3.6.1-3.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release valgrind-3.6.1-3.mga2

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Wed Jun 22 07:40:00 CEST 2011 +

+
+ +
On 20 June 2011 11:24, Thierry Vignaud <thierry.vignaud at gmail.com> wrote:
+> On 7 June 2011 16:10, Mageia Team <buildsystem-daemon at mageia.org> wrote:
+>> dmorgan <dmorgan> 3.6.1-3.mga1:
+>> + Revision: 101519
+>> - Provide devel subpackage  ( partial merge of mdv commit 659516)
+>
+> As always, when one moves files between subpackages or to a new subpackage,
+> conflicts tags should be added in order to ensure urpmi will put both packages
+> in the same transaction:
+>
+> Installation failed:
+>    file /usr/include/valgrind/memcheck.h from install of
+> valgrind-devel-3.6.1-3.mga2.x86_64 conflicts with file from package
+> valgrind-3.6.0-2.mga1.x86_64
+>    file /usr/lib64/pkgconfig/valgrind.pc from install of
+> valgrind-devel-3.6.1-3.mga2.x86_64 conflicts with file from package
+> valgrind-3.6.0-2.mga1.x86_64
+>
+
+Done.
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005904.html b/zarb-ml/mageia-dev/2011-June/005904.html new file mode 100644 index 000000000..72c2344f0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005904.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] glib-compile-schemas? + + + + + + + + + +

[Mageia-dev] glib-compile-schemas?

+ Dexter Morgan + dmorganec at gmail.com +
+ Wed Jun 22 08:47:58 CEST 2011 +

+
+ +
On Wed, Jun 22, 2011 at 6:03 AM, Ahmad Samir <ahmadsamir3891 at gmail.com> wrote:
+> On 21 June 2011 11:00, Funda Wang <fundawang at gmail.com> wrote:
+>> Hello,
+>>
+>> Look at this change,
+>>
+>> http://svnweb.mageia.org/packages/cauldron/anjuta-extras/current/SPECS/anjuta-extras.spec?view=patch&r1=111189&r2=111198&pathrev=111199
+>>
+>> I remembered such a post/postun script is handled by rpm triggers? see:
+>>
+>> /var/lib/rpm/filetriggers/glib-compile-schemas.*
+>>
+>> Will it need to be handled separately in individual package?
+>>
+>
+> I am not sure, I think that change should be reverted; indeed, it's
+> already handled by an rpm filetrigger...
+>
+> --
+> Ahmad Samir
+>
+
+yes this is what i did
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005905.html b/zarb-ml/mageia-dev/2011-June/005905.html new file mode 100644 index 000000000..325f96657 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005905.html @@ -0,0 +1,172 @@ + + + + [Mageia-dev] How can I propose new packages and my involvement, i.e. maintaining them? + + + + + + + + + +

[Mageia-dev] How can I propose new packages and my involvement, i.e. maintaining them?

+ Radu-Cristian FOTESCU + beranger5ca at yahoo.ca +
+ Wed Jun 22 10:42:19 CEST 2011 +

+
+ +
Folks, 
+
+
+It's not clear to me how things are going with mentoring and stuff, but here we go: I have made a few packages for Cauldron, and for the time being I've established a personal tiny repo (32-bit only + SRPMs) with them, so they could be tested and updated.
+
+It all started with https://bugs.mageia.org/show_bug.cgi?id=1659
+
+Now, here's the status:
+/* -------------------------------------------------------------------------- */
+
+HTML description:
+http://mageia.beranger.org/mageia/
+also:
+http://tumblr.com/xz7347svgn
+
+Text description:
+/* -------------------------------------------------------------------------- */
+
+As I am playing with Mageia Cauldron (which will become Mageia 2.0 at some point) and I missed some packages (first things first, a newer calibre), I thought of creating my own packages, based on the fact that two years ago I made at some point an EL5-compatible repo.
+
+As I am writing this, the newest calibre package is to be built and pushed to Mandriva 1 (updates/testing), but as I have tested my build (and patches) for a couple of days under Cauldron, I’ll still keep it here. (It should get obsoleted as long as newer official packages are available.)
+
+The repository is here (32-bit only): mageia.beranger.org/mageia/2/repoview/
+
+It can be installed with:
+
+ urpmi.addmedia Beranger http://mageia.beranger.org/mageia/2/RPMS/i586/
+
+Summary of the contents with versions at the time of the launching:
+
+-- Applications:
+
+* calibre-0.8.6 : complete e-library solution — screenshot (testing fr_FR.UTF8):
+    http://mageia.beranger.org/images/calibre.png
+  Added as a dependency (needed for e-mail capabilities):
+    python-dnspython-1.9.4
+
+* gnaural-1.0.20110606 : a binaural-beat generator
+
+* speedcrunch-0.10.1 : my favorite calculator.
+
+-- Small Games:
+
+* belooted-0.1.4 : the one and only Belote application — screenshot:
+    http://mageia.beranger.org/images/belooted.png
+
+* gnome-hearts-0.3 : obviously, playing the card game of Hearts.
+
+* gnome-mastermind-0.3.1 : a funny Mastermind, usually not present in any distro — screenshot:
+    http://mageia.beranger.org/images/gnome-mastermind.png
+
+* pushover-0.0.3 : the fabulous MS-DOS puzzle, now on Linux! — screenshot:
+    http://mageia.beranger.org/images/pushover.png
+
+* pychess-0.10 : because I like it more than any other Linux chess application.
+
+* pytraffic-2.5.4 : an excellent puzzle based on Rush Hour — screenshot:
+    http://mageia.beranger.org/images/pytraffic.png
+
+* quarry-0.2.0 : multi-purpose GUI for several board games, notably for GNU Go, which should be added as “gnugo —mode gtp” — screenshot:
+    http://mageia.beranger.org/images/quarry-gnugo.png
+
+-- Small Tools:
+
+* gnome-specimen-0.4 : allows you to compare visually several typefaces at once — screenshot:
+    http://mageia.beranger.org/images/gnome-specimen.png
+
+* repoview-0.6.5 — builds web interfaces like the one used for this repo.
+  Added as a dependency:
+    python-kid-0.9.6.
+
+Just for the sake of it, the packages are (hopefully!) signed with an old GPG key (the declared e-mail is no longer valid): 
+    http://mageia.beranger.org/mageia/RPM-GPG-KEY-odiecolon
+/* -------------------------------------------------------------------------- */
+
+Now, is there any chance that:
+
+(i) some if not all of these packages be approved for inclusion in Mageia?
+(ii) myself be accepted as a contributor / package maintainer for Mandriva?
+
+What should I do?
+
+Oh, of course, some people should test these packages, and some other people should inspect the .spec files and patches....
+
+Thanks,
+R-C aka Beranger (with an acute accent on e)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005906.html b/zarb-ml/mageia-dev/2011-June/005906.html new file mode 100644 index 000000000..25bbb0b47 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005906.html @@ -0,0 +1,130 @@ + + + + [Mageia-dev] How can I propose new packages and my involvement, i.e. maintaining them? + + + + + + + + + +

[Mageia-dev] How can I propose new packages and my involvement, i.e. maintaining them?

+ Anne nicolas + ennael at mageia.org +
+ Wed Jun 22 10:51:05 CEST 2011 +

+
+ +
2011/6/22 Radu-Cristian FOTESCU <beranger5ca at yahoo.ca>
+
+> Folks,
+>
+>
+> It's not clear to me how things are going with mentoring and stuff, but
+> here we go: I have made a few packages for Cauldron, and for the time being
+> I've established a personal tiny repo (32-bit only + SRPMs) with them, so
+> they could be tested and updated.
+>
+> It all started with https://bugs.mageia.org/show_bug.cgi?id=1659
+>
+> ...
+> What should I do?
+>
+> Oh, of course, some people should test these packages, and some other
+> people should inspect the .spec files and patches....
+>
+> Thanks,
+> R-C aka Beranger (with an acute accent on e)
+>
+
+Thanks for your proposal, of course any help on packaging side is welcome.
+Here are some wiki page to read about mentoring process:
+http://mageia.org/wiki/doku.php?id=packaging&s[]=mentor#packagers_organization
+http://mageia.org/wiki/doku.php?id=packaging&s[]=mentor#resources
+http://mageia.org/wiki/doku.php?id=packages_mentoring
+and
+http://mageia.org/wiki/doku.php?id=packager_start
+
+You can apply here on -dev ML looking for a mentor
+
+Also we have weekly meeting on IRC you can attend if you are around
+
+Welcome on board (or in hell as you want)
+
+
+
+-- 
+Anne
+http://www.mageia.org
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110622/74d31d1b/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005907.html b/zarb-ml/mageia-dev/2011-June/005907.html new file mode 100644 index 000000000..110b0af66 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005907.html @@ -0,0 +1,116 @@ + + + + [Mageia-dev] How can I propose new packages and my involvement, i.e. maintaining them? + + + + + + + + + +

[Mageia-dev] How can I propose new packages and my involvement, i.e. maintaining them?

+ Radu-Cristian FOTESCU + beranger5ca at yahoo.ca +
+ Wed Jun 22 10:58:27 CEST 2011 +

+
+ +
+>Here are some wiki page to read about mentoring process: 
+>http://mageia.org/wiki/doku.php?id=packaging&s[]=mentor#packagers_organization
+>http://mageia.org/wiki/doku.php?id=packaging&s[]=mentor#resources
+>http://mageia.org/wiki/doku.php?id=packages_mentoring
+>and
+>http://mageia.org/wiki/doku.php?id=packager_start
+
+
+OK, thanks, je vais lire cela.
+
+
+>You can apply here on -dev ML looking for a mentor
+
+
+Can I assume I just did that, or should I state "Hey, I am looking for a mentor!"?
+
+
+> Also we have weekly meeting on IRC you can attend if you are around
+
+
+Uh, I suppose so. I never liked IRC in my whole life.
+
+>Welcome on board (or in hell as you want)
+
+Everything is hell nowadays.
+
+Thx,
+R-C
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005908.html b/zarb-ml/mageia-dev/2011-June/005908.html new file mode 100644 index 000000000..7ee39ec4f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005908.html @@ -0,0 +1,136 @@ + + + + [Mageia-dev] How can I propose new packages and my involvement, i.e. maintaining them? + + + + + + + + + +

[Mageia-dev] How can I propose new packages and my involvement, i.e. maintaining them?

+ Anne nicolas + ennael at mageia.org +
+ Wed Jun 22 11:00:23 CEST 2011 +

+
+ +
2011/6/22 Radu-Cristian FOTESCU <beranger5ca at yahoo.ca>
+
+>
+> >Here are some wiki page to read about mentoring process:
+> >
+> http://mageia.org/wiki/doku.php?id=packaging&s[]=mentor#packagers_organization
+> >http://mageia.org/wiki/doku.php?id=packaging&s[]=mentor#resources
+> >http://mageia.org/wiki/doku.php?id=packages_mentoring
+> >and
+> >http://mageia.org/wiki/doku.php?id=packager_start
+>
+>
+> OK, thanks, je vais lire cela.
+>
+>
+> >You can apply here on -dev ML looking for a mentor
+>
+>
+> Can I assume I just did that, or should I state "Hey, I am looking for a
+> mentor!"?
+>
+
+We can assume it I guess :)
+Just shout it again during tonight's meeting
+
+
+>
+>
+> > Also we have weekly meeting on IRC you can attend if you are around
+>
+>
+> Uh, I suppose so. I never liked IRC in my whole life.
+>
+> >Welcome on board (or in hell as you want)
+>
+> Everything is hell nowadays.
+>
+> Thx,
+> R-C
+>
+>
+
+
+-- 
+Anne
+http://www.mageia.org
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110622/f6b7d303/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005909.html b/zarb-ml/mageia-dev/2011-June/005909.html new file mode 100644 index 000000000..1fbabdb5e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005909.html @@ -0,0 +1,113 @@ + + + + [Mageia-dev] Update of mesa to git version + + + + + + + + + +

[Mageia-dev] Update of mesa to git version

+ Balcaen John + mikala at mageia.org +
+ Wed Jun 22 14:43:15 CEST 2011 +

+
+ +
Le mercredi 22 juin 2011 08:45:44, root at mageia.org a écrit :
+> Revision: 112356
+> Author:   mikala
+> Date:     2011-06-22 13:45:43 +0200 (Wed, 22 Jun 2011)
+> Log Message:
+> -----------
+> Use git tarball (snapshot of 20110620) (which can really help gnome-
+shell...)
+> - Enable gallium drivers (for r300,r600,nouveau,swrast)
+> - Disable for the moment patch202,300,902,903,904,2004 
+> - Disable build of mesa glut
+While playing with gnome-shell i noticed that upgrading mesa to 7.11 & using 
+gallium can help a lot to get a more stable gnome-shell.
+So after some discussion on irc i test locally & commit my changes on the svn 
+for review/changes etc :)
+I also disable the mesa glut build in the same change since (if i'm not wrong) 
+we're supposed to move to freeglut instead.
+
+
+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-June/005910.html b/zarb-ml/mageia-dev/2011-June/005910.html new file mode 100644 index 000000000..5d64e62fc --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005910.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] How can I propose new packages and my involvement, i.e. maintaining them? + + + + + + + + + +

[Mageia-dev] How can I propose new packages and my involvement, i.e. maintaining them?

+ Angelo Naselli + anaselli at linux.it +
+ Wed Jun 22 15:05:34 CEST 2011 +

+
+ +
mercoledì 22 giugno 2011 alle 10:42, Radu-Cristian FOTESCU ha scritto:
+> Now, is there any chance that:
+[...]
+> (ii) myself be accepted as a contributor / package maintainer for Mandriva?
+Mageia i guess :p
+
+Welcome aboard, i do hope you can enjoy our open community :)
+
+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/20110622/9ca947c8/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005911.html b/zarb-ml/mageia-dev/2011-June/005911.html new file mode 100644 index 000000000..06ec71796 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005911.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] How can I propose new packages and my involvement, i.e. maintaining them? + + + + + + + + + +

[Mageia-dev] How can I propose new packages and my involvement, i.e. maintaining them?

+ Radu-Cristian FOTESCU + beranger5ca at yahoo.ca +
+ Wed Jun 22 15:17:56 CEST 2011 +

+
+ +
>> (ii) myself be accepted as a contributor / package maintainer for Mandriva?
+>Mageia i guess :p
+
+
+OMFG. (Although, to be frank, MDV's story is a sad one. Now whatever is important seems to need to be done by Dodonov, and mdv 2011's release is sliding, and sliding, and sliding... so much that there is a risk that Mageia 2 is released and Mandriva 2011 is still not ready!)
+
+
+>Welcome aboard, i do hope you can enjoy our open community :)
+
+Thanks, Angelo!
+
+R-C
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005912.html b/zarb-ml/mageia-dev/2011-June/005912.html new file mode 100644 index 000000000..87ace82e0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005912.html @@ -0,0 +1,123 @@ + + + + [Mageia-dev] How can I propose new packages and my involvement, i.e. maintaining them? + + + + + + + + + +

[Mageia-dev] How can I propose new packages and my involvement, i.e. maintaining them?

+ Daniel Kreuter + daniel.kreuter85 at googlemail.com +
+ Wed Jun 22 15:28:16 CEST 2011 +

+
+ +
On Wed, Jun 22, 2011 at 3:17 PM, Radu-Cristian FOTESCU <beranger5ca at yahoo.ca
+> wrote:
+
+> >> (ii) myself be accepted as a contributor / package maintainer for
+> Mandriva?
+> >Mageia i guess :p
+>
+>
+> OMFG. (Although, to be frank, MDV's story is a sad one. Now whatever is
+> important seems to need to be done by Dodonov, and mdv 2011's release is
+> sliding, and sliding, and sliding... so much that there is a risk that
+> Mageia 2 is released and Mandriva 2011 is still not ready!)
+>
+>
+> >Welcome aboard, i do hope you can enjoy our open community :)
+>
+> Thanks, Angelo!
+>
+> R-C
+>
+>
+Hi,
+
+also from me a welcome on board. If you are looking for a mentor don't
+hesitate. If you aren't able to find one tell me or andre999 and we try to
+help you out with that.
+
+
+
+-- 
+Mit freundlichen Grüßen
+
+Greetings
+
+Daniel Kreuter
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110622/9cf0836e/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005913.html b/zarb-ml/mageia-dev/2011-June/005913.html new file mode 100644 index 000000000..c6a79e8f6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005913.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] gcc compiler error + + + + + + + + + +

[Mageia-dev] gcc compiler error

+ José Jorge + jjorge at free.fr +
+ Wed Jun 22 15:47:44 CEST 2011 +

+
+ +
hi, I have a compiler error in cauldron build system building scourge, which 
+does not happen in my system (Mageia 1 i586).
+
+constants.cpp:749:6: internal compiler error: Segmentation fault
+Please submit a full bug report,
+with preprocessed source if appropriate.
+See <http://bugs.mageia.org/> for instructions.
+I suppose it is a bug in gcc 4.6 . Should I fill a normal bug to mageia?
+
+http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110622075842.philippem.valstar.30809/log/botcmd.1308730266.ecosse.log
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110622/d92d64f3/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005914.html b/zarb-ml/mageia-dev/2011-June/005914.html new file mode 100644 index 000000000..85c6ba2f0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005914.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] gcc compiler error + + + + + + + + + +

[Mageia-dev] gcc compiler error

+ Listes ( José Jorge) + lists.jjorge at free.fr +
+ Wed Jun 22 15:54:26 CEST 2011 +

+
+ +
hi, I have a compiler error in cauldron build system building scourge, which 
+does not happen in my system (Mageia 1 i586).
+
+
+
+constants.cpp:749:6: internal compiler error: Segmentation fault
+Please submit a full bug report,
+with preprocessed source if appropriate.
+See <http://bugs.mageia.org/> for instructions.
+I suppose it is a bug in gcc 4.6 . Should I fill a normal bug to mageia?
+
+
+
+http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110622075842.philippem.valstar.30809/log/botcmd.1308730266.ecosse.log
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110622/b80051a8/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005915.html b/zarb-ml/mageia-dev/2011-June/005915.html new file mode 100644 index 000000000..46560d14b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005915.html @@ -0,0 +1,127 @@ + + + + [Mageia-dev] libproxy vs biarch & libexecdir + + + + + + + + + +

[Mageia-dev] libproxy vs biarch & libexecdir

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Wed Jun 22 17:49:20 CEST 2011 +

+
+ +
hi,
+
+I'm trying to make sense of libproxy packaging. It consists of a regular 
+library and several modules. Currently, the library follows policy but the 
+module packages are named libproxy-foo, so they have the same name on x86 
+and x86-64:
+
+i586		x86-64		description
+==========================================================
+libproxy1	lib64proxy1	main library
+libproxy-gnome	libproxy-gnome	gnome proxy config support
+libproxy-webkit	libproxy-webkit	webkit pacrunner (?)
+etc.
+
+- modules are in /usr/lib(64)/libproxy/%{version}/modules/
+- libproxy-gnome also has a binary /usr/lib(64)/pxgconf (in 0.4.6 for
+   gnome2) or /usr/lib(64)/pxgsettings (in 0.4.7 for gnome3).
+
+This looks wrong because:
+- on a biarch system, it is not possible to have e.g. gnome3 settings
+   support for both archs
+- the helper app (?) pxgsettings is put in libexecdir by upstream, so
+   IMHO it should be in /usr/lib or /usr/libexec, not %{_libdir} which
+   %{_libexecdir} expands to.
+
+The specfile I have locally changes this to:
+
+i586		x86-64				change
+================================================================
+libproxy1	lib64proxy1			same
+libproxy-gnome	lib64proxy-gnome		biarch support
+libproxy-webkit	lib64proxy-webkit		biarch support
+libproxy-gxsettings libproxy-gxsettings		new pkg
+etc.
+
+What should dependencies on these modules look like:
+Requires: %mklibname proxy-gnome  ?
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005916.html b/zarb-ml/mageia-dev/2011-June/005916.html new file mode 100644 index 000000000..9f3c43620 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005916.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] gcc compiler error + + + + + + + + + +

[Mageia-dev] gcc compiler error

+ Funda Wang + fundawang at gmail.com +
+ Wed Jun 22 17:51:58 CEST 2011 +

+
+ +
I think gcc 4.6 hasn't landed yet.
+
+2011/6/22 Listes (José Jorge) <lists.jjorge at free.fr>:
+> hi, I have a compiler error in cauldron build system building scourge, which
+> does not happen in my system (Mageia 1 i586).
+>
+> constants.cpp:749:6: internal compiler error: Segmentation fault
+>
+> Please submit a full bug report,
+>
+> with preprocessed source if appropriate.
+>
+> See <http://bugs.mageia.org/> for instructions.
+>
+> I suppose it is a bug in gcc 4.6 . Should I fill a normal bug to mageia?
+>
+> http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110622075842.philippem.valstar.30809/log/botcmd.1308730266.ecosse.log
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005917.html b/zarb-ml/mageia-dev/2011-June/005917.html new file mode 100644 index 000000000..96eca4f17 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005917.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] libproxy vs biarch & libexecdir + + + + + + + + + +

[Mageia-dev] libproxy vs biarch & libexecdir

+ Funda Wang + fundawang at gmail.com +
+ Wed Jun 22 17:54:26 CEST 2011 +

+
+ +
2011/6/22 Christiaan Welvaart <cjw at daneel.dyndns.org>:
+> - the helper app (?) pxgsettings is put in libexecdir by upstream, so
+>  IMHO it should be in /usr/lib or /usr/libexec, not %{_libdir} which
+>  %{_libexecdir} expands to.
+%_libexecdir expands to %_libdir, for years since mandrake.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005918.html b/zarb-ml/mageia-dev/2011-June/005918.html new file mode 100644 index 000000000..ac14695e6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005918.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] [RPM] cauldron core/release valgrind-3.6.1-3.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release valgrind-3.6.1-3.mga2

+ Florian Hubold + doktor5000 at arcor.de +
+ Wed Jun 22 19:31:43 CEST 2011 +

+
+ +
Am 22.06.2011 07:40, schrieb Ahmad Samir:
+> On 20 June 2011 11:24, Thierry Vignaud<thierry.vignaud at gmail.com>  wrote:
+>> On 7 June 2011 16:10, Mageia Team<buildsystem-daemon at mageia.org>  wrote:
+>>> dmorgan<dmorgan>  3.6.1-3.mga1:
+>>> + Revision: 101519
+>>> - Provide devel subpackage  ( partial merge of mdv commit 659516)
+>> As always, when one moves files between subpackages or to a new subpackage,
+>> conflicts tags should be added in order to ensure urpmi will put both packages
+>> in the same transaction:
+>>
+>> Installation failed:
+>>     file /usr/include/valgrind/memcheck.h from install of
+>> valgrind-devel-3.6.1-3.mga2.x86_64 conflicts with file from package
+>> valgrind-3.6.0-2.mga1.x86_64
+>>     file /usr/lib64/pkgconfig/valgrind.pc from install of
+>> valgrind-devel-3.6.1-3.mga2.x86_64 conflicts with file from package
+>> valgrind-3.6.0-2.mga1.x86_64
+>>
+> Done.
+>
+Minor nitpick: BuildRequires for xulrunner were changed after the split, for 
+firefox5 not.
+Is there any special reason for this? Just wondering ...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005919.html b/zarb-ml/mageia-dev/2011-June/005919.html new file mode 100644 index 000000000..3663bf368 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005919.html @@ -0,0 +1,82 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Florian Hubold + doktor5000 at arcor.de +
+ Wed Jun 22 19:41:14 CEST 2011 +

+
+ +
Am 16.06.2011 17:14, schrieb Sander Lepik:
+> 16.06.2011 17:18, Daniel Kreuter kirjutas:
+>> Ok Mozilla has the RC1 released. Final shall come on Tuesday 21st June so 
+>> yeah we will include that in Mageia 2 I think (as least this one, maybe FF6 
+>> or 7 depending on which version will be available i think)
+> Well, it's quite possible that we have to include that in Mageia 1 as well, 
+> as this will be security update for Firefox 4. If we don't want to patch 
+> every CVE then we have to include it into Mageia 1 as well..
+>
+> -- 
+> Sander
+>
+>
+Would be nice to know, if this is planned?
+
+I have rebuild FF5 here locally for Mageia 1, and the only addons that i lost is
+Linkification, but that is merely due to it's developers who already messed up
+with FF4. They don't offer the proper update on Firefox Addons site.
+
+So, please, what about Firefox 5 for Mageia 1 as an update (backport?)
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005920.html b/zarb-ml/mageia-dev/2011-June/005920.html new file mode 100644 index 000000000..48d5d0652 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005920.html @@ -0,0 +1,143 @@ + + + + [Mageia-dev] Update of mesa to git version + + + + + + + + + +

[Mageia-dev] Update of mesa to git version

+ Philippe DIDIER + philippedidier at laposte.net +
+ Wed Jun 22 19:54:59 CEST 2011 +

+
+ +
>  I also disable the mesa glut build in the same change since (if i'm not wrong)
+>  we're supposed to move to freeglut instead.
+
+
+Thierry Vignaud is certainly the one that is aware about freeglut versus 
+GLUT ! He is the one that may say if you are right or wrong to do so now !
+
+Beware of the fact that freeglut is not a buildrequire nor a require for 
+some rpms (their spec file need to be modified
+and they need to be rebuilt with freeglut instead of mesaglut)
+
+(the list is extracted from 
+https://qa.mandriva.com/show_bug.cgi?id=47090 ... some rpms have not 
+been yet imported)
+
+3ddesktop
+3dfb
+asteroids3D
+asymptote
+bullet-demo
+crack-attack
+cultivation
+enblend
+flightgear
+foobillard
+gl-117
+glean
+glui-demos
+glxinfo
+gpac
+hugin
+jasper
+jasper
+kiki
+libmgl-glut5
+libtiff-progs
+mesa-demos
+ocaml-glmlite
+ocaml-lablgl
+perl-OpenGL
+pfstools
+pymol
+qepcad
+ruby-rbogl
+smalltalk
+stormbaancoureur
+supertuxkart
+tesseracttrainer
+torcs
+torcs-robots-base
+tux_aqfh
+vegastrike
+wiiuse
+yabause-gtk
+yabause-qt
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005921.html b/zarb-ml/mageia-dev/2011-June/005921.html new file mode 100644 index 000000000..ffd2835f5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005921.html @@ -0,0 +1,123 @@ + + + + [Mageia-dev] Update of mesa to git version + + + + + + + + + +

[Mageia-dev] Update of mesa to git version

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Wed Jun 22 20:16:23 CEST 2011 +

+
+ +
On 22 June 2011 19:54, Philippe DIDIER <philippedidier at laposte.net> wrote:
+>>  I also disable the mesa glut build in the same change since (if i'm not
+>> wrong)
+>>  we're supposed to move to freeglut instead.
+>
+>
+> Thierry Vignaud is certainly the one that is aware about freeglut versus
+> GLUT ! He is the one that may say if you are right or wrong to do so now !
+
+Other distros (eg: fedora) have done the switch long time ago.
+Both projects are more or less dead (which is somewhat expected for projects
+implementing an API dead for a decade)
+
+FC has patches for the examples & for killing warnings though.
+
+We would need to test GLUT a little bit
+
+As for gallium, I'm regularly testing r300 from git but I'ven't tested
+neither r600 nor nouveau (though my experience with nouveau on FC
+is that it regress quite a lot and is heavily dependant on the
+kernel/libdrm/mesa triplet).
+
+r300g is alreay the default in incoming mesa-7.11 (I think
+this was already the case on 7.10).
+r600g will be the default in 7.12
+No bugs are accepted on r300c anymore (don't remember for r600c)
+As for nouveau, well we've no alternatives.
+As for swrast, the LLVM gallium driver is said to be faster but
+I'ven't tested it.
+
+> Beware of the fact that freeglut is not a buildrequire nor a require for
+> some rpms (their spec file need to be modified
+> and they need to be rebuilt with freeglut instead of mesaglut)
+
+Indeed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005922.html b/zarb-ml/mageia-dev/2011-June/005922.html new file mode 100644 index 000000000..da9a67b36 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005922.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] [RPM] cauldron core/release valgrind-3.6.1-3.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release valgrind-3.6.1-3.mga2

+ nicolas vigier + boklm at mars-attacks.org +
+ Wed Jun 22 20:18:04 CEST 2011 +

+
+ +
On Wed, 22 Jun 2011, Florian Hubold wrote:
+
+> Am 22.06.2011 07:40, schrieb Ahmad Samir:
+>> On 20 June 2011 11:24, Thierry Vignaud<thierry.vignaud at gmail.com>  wrote:
+>>> On 7 June 2011 16:10, Mageia Team<buildsystem-daemon at mageia.org>  wrote:
+>>>> dmorgan<dmorgan>  3.6.1-3.mga1:
+>>>> + Revision: 101519
+>>>> - Provide devel subpackage  ( partial merge of mdv commit 659516)
+>>> As always, when one moves files between subpackages or to a new subpackage,
+>>> conflicts tags should be added in order to ensure urpmi will put both packages
+>>> in the same transaction:
+>>>
+>>> Installation failed:
+>>>     file /usr/include/valgrind/memcheck.h from install of
+>>> valgrind-devel-3.6.1-3.mga2.x86_64 conflicts with file from package
+>>> valgrind-3.6.0-2.mga1.x86_64
+>>>     file /usr/lib64/pkgconfig/valgrind.pc from install of
+>>> valgrind-devel-3.6.1-3.mga2.x86_64 conflicts with file from package
+>>> valgrind-3.6.0-2.mga1.x86_64
+>>>
+>> Done.
+>>
+> Minor nitpick: BuildRequires for xulrunner were changed after the split, 
+> for firefox5 not.
+> Is there any special reason for this? Just wondering ...
+
+Because the devel files are now in valgrind-devel.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005923.html b/zarb-ml/mageia-dev/2011-June/005923.html new file mode 100644 index 000000000..cdc22c4a6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005923.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] Tonight's meeting + + + + + + + + + +

[Mageia-dev] Tonight's meeting

+ Anne nicolas + ennael at mageia.org +
+ Wed Jun 22 20:20:05 CEST 2011 +

+
+ +
Very late mail but here are the topics for tonight's meeting on #mageia-dev
+at 19h UTC
+
+- quick reminder about current brainstorms: release cycle, specs
+- incoming ARM port
+- review on secteam current work - reminder on QA needs
+- review on mentoring process
+
+Cheers
+
+-- 
+Anne
+http://www.mageia.org
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110622/8dae7a9c/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005924.html b/zarb-ml/mageia-dev/2011-June/005924.html new file mode 100644 index 000000000..37d6ec05d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005924.html @@ -0,0 +1,155 @@ + + + + [Mageia-dev] Update of mesa to git version + + + + + + + + + +

[Mageia-dev] Update of mesa to git version

+ andre999 + andr55 at laposte.net +
+ Wed Jun 22 20:32:22 CEST 2011 +

+
+ +
Philippe DIDIER a écrit :
+>
+>> I also disable the mesa glut build in the same change since (if i'm
+>> not wrong)
+>> we're supposed to move to freeglut instead.
+>
+>
+> Thierry Vignaud is certainly the one that is aware about freeglut versus
+> GLUT ! He is the one that may say if you are right or wrong to do so now !
+>
+> Beware of the fact that freeglut is not a buildrequire nor a require for
+> some rpms (their spec file need to be modified
+> and they need to be rebuilt with freeglut instead of mesaglut)
+>
+> (the list is extracted from
+> https://qa.mandriva.com/show_bug.cgi?id=47090 ... some rpms have not
+> been yet imported)
+>
+> 3ddesktop
+> 3dfb
+> asteroids3D
+> asymptote
+> bullet-demo
+> crack-attack
+> cultivation
+> enblend
+> flightgear
+> foobillard
+> gl-117
+> glean
+> glui-demos
+> glxinfo
+> gpac
+> hugin
+> jasper
+> jasper
+> kiki
+> libmgl-glut5
+> libtiff-progs
+> mesa-demos
+> ocaml-glmlite
+> ocaml-lablgl
+> perl-OpenGL
+> pfstools
+> pymol
+> qepcad
+> ruby-rbogl
+> smalltalk
+> stormbaancoureur
+> supertuxkart
+> tesseracttrainer
+> torcs
+> torcs-robots-base
+> tux_aqfh
+> vegastrike
+> wiiuse
+> yabause-gtk
+> yabause-qt
+
+Just a question ...
+what would happen if freeglut has a provides glut ?
+If neither were installed, wouldn't one be given the option ? (as long as both are available in the 
+repos) (as one sees often enough when installing packages)
+And if both glut and freeglut were installed, and glut were subsequently uninstalled, would 
+packages requiring glut continue to work ?
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005925.html b/zarb-ml/mageia-dev/2011-June/005925.html new file mode 100644 index 000000000..24681dab0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005925.html @@ -0,0 +1,114 @@ + + + + [Mageia-dev] Update of mesa to git version + + + + + + + + + +

[Mageia-dev] Update of mesa to git version

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Wed Jun 22 20:54:26 CEST 2011 +

+
+ +
On Wed, 22 Jun 2011, andre999 wrote:
+
+> Philippe DIDIER a écrit :
+>> 
+>>> I also disable the mesa glut build in the same change since (if i'm
+>>> not wrong)
+>>> we're supposed to move to freeglut instead.
+>> 
+>> 
+>> Thierry Vignaud is certainly the one that is aware about freeglut versus
+>> GLUT ! He is the one that may say if you are right or wrong to do so now !
+>> 
+>> Beware of the fact that freeglut is not a buildrequire nor a require for
+>> some rpms (their spec file need to be modified
+>> and they need to be rebuilt with freeglut instead of mesaglut)
+
+> Just a question ...
+> what would happen if freeglut has a provides glut ?
+> If neither were installed, wouldn't one be given the option ? (as long as 
+> both are available in the repos) (as one sees often enough when installing 
+> packages)
+> And if both glut and freeglut were installed, and glut were subsequently 
+> uninstalled, would packages requiring glut continue to work ?
+
+Freeglut (libfreeglut3) can already replace mesaglut (libmesaglut3).
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005926.html b/zarb-ml/mageia-dev/2011-June/005926.html new file mode 100644 index 000000000..3d3dfc11f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005926.html @@ -0,0 +1,116 @@ + + + + [Mageia-dev] [RPM] cauldron core/release valgrind-3.6.1-3.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release valgrind-3.6.1-3.mga2

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Wed Jun 22 21:45:44 CEST 2011 +

+
+ +
On 22 June 2011 20:18, nicolas vigier <boklm at mars-attacks.org> wrote:
+> On Wed, 22 Jun 2011, Florian Hubold wrote:
+>
+>> Am 22.06.2011 07:40, schrieb Ahmad Samir:
+>>> On 20 June 2011 11:24, Thierry Vignaud<thierry.vignaud at gmail.com>  wrote:
+>>>> On 7 June 2011 16:10, Mageia Team<buildsystem-daemon at mageia.org>  wrote:
+>>>>> dmorgan<dmorgan>  3.6.1-3.mga1:
+>>>>> + Revision: 101519
+>>>>> - Provide devel subpackage  ( partial merge of mdv commit 659516)
+>>>> As always, when one moves files between subpackages or to a new subpackage,
+>>>> conflicts tags should be added in order to ensure urpmi will put both packages
+>>>> in the same transaction:
+>>>>
+>>>> Installation failed:
+>>>>     file /usr/include/valgrind/memcheck.h from install of
+>>>> valgrind-devel-3.6.1-3.mga2.x86_64 conflicts with file from package
+>>>> valgrind-3.6.0-2.mga1.x86_64
+>>>>     file /usr/lib64/pkgconfig/valgrind.pc from install of
+>>>> valgrind-devel-3.6.1-3.mga2.x86_64 conflicts with file from package
+>>>> valgrind-3.6.0-2.mga1.x86_64
+>>>>
+>>> Done.
+>>>
+>> Minor nitpick: BuildRequires for xulrunner were changed after the split,
+>> for firefox5 not.
+>> Is there any special reason for this? Just wondering ...
+>
+> Because the devel files are now in valgrind-devel.
+>
+>
+
+Yeah, there're two types of BR here, just 'valgrind' if the build
+requires only the binary (/usr/bin/valgrind) and valgrind-devel if the
+build requires the valgrind header files; AFAICS for firefox, it
+doesn't require the valgrind headers (i.e. I don't see any checks for
+the headers failing in the build log).
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005927.html b/zarb-ml/mageia-dev/2011-June/005927.html new file mode 100644 index 000000000..d9e957aa3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005927.html @@ -0,0 +1,118 @@ + + + + [Mageia-dev] Update of mesa to git version + + + + + + + + + +

[Mageia-dev] Update of mesa to git version

+ Philippe DIDIER + philippedidier at laposte.net +
+ Wed Jun 22 22:06:07 CEST 2011 +

+
+ +
>/  And if both glut and freeglut were installed,/
+
+Libfreeglut3.rpm and libmesaglut3.rpm can't be installed side by side : 
+they install the same link "glut.so.3" to glut.so.3.9.0 for the first or 
+glut.so.3.7.0 for the second... fortunately libfreeglut3.rpm obsoletes 
+libmesaglut3.rpm
+
+Libfreeglut-devel depends on libfreeglut3 ... there may not be any 
+conflict if libfreeglut3.rpm is choosen
+
+libfreeglut-devel allows to build everything when it is substituted to 
+libmesaglut-devel :
+
+it adds in /usr/include/GL :
+
+1) glut.h which gives a link to freeglut_std.h (which is compatible with 
+GLUT headers and program written for GLUT)
+
+2) freeglut.h which gives a link to freeglut_std.h _and_ to 
+freeglut_ext.h (which adds access to more functions : scroll button, 
+joystick etc..) and allows to build programs needing strictly freeglut 
+(written for it)
+
+
+
+In the spec files of programs needing GLUT now, freeglut-devel must be 
+substituted to mesaglut-devel in BUILDREQUIRES if it is used ! (and 
+libfreeglut3 to libmesglut3 in REQUIRES ...)
+
+
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005928.html b/zarb-ml/mageia-dev/2011-June/005928.html new file mode 100644 index 000000000..1f0c40985 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005928.html @@ -0,0 +1,70 @@ + + + + [Mageia-dev] get-skype package for submission + + + + + + + + + +

[Mageia-dev] get-skype package for submission

+ Angelo Naselli + anaselli at linux.it +
+ Wed Jun 22 22:41:39 CEST 2011 +

+
+ +
> > Maybe more something like task-mageia-packaging?
+> 
+> That sounds better :)
+It depend on what you want to put inside i believe, 
+if only rpm stuff... then yes :)
+
+-- 
+	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/20110622/7207b64b/attachment.asc>
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005929.html b/zarb-ml/mageia-dev/2011-June/005929.html new file mode 100644 index 000000000..7e6ddd6b3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005929.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] [RPM] cauldron tainted/release transcode-1.1.5-5.mga2.tainted + + + + + + + + + +

[Mageia-dev] [RPM] cauldron tainted/release transcode-1.1.5-5.mga2.tainted

+ Dick Gevers + dvgevers at xs4all.nl +
+ Wed Jun 22 22:46:39 CEST 2011 +

+
+ +
On Wed, 22 Jun 2011 22:28:18 +0200 (CEST), Mageia Team wrote about [RPM]
+cauldron tainted/release transcode-1.1.5-5.mga2.tainted:
+
+>Name        : transcode                    Relocations: (not relocatable)
+>Version     : 1.1.5                             Vendor: Mageia.Org
+>Release     : 5.mga2.tainted                Build Date: Wed Jun 22
+
+>This package is in PLF as it could violate some patents.
+
+>obgr_seneca <obgr_seneca> 1.1.5-5.mga2:
+>+ Revision: 112501
+>- added tainted to spec file
+
+Really in plf ? Or only in tainted repo?
+
+Thanks & BFN,
+
+=Dick Gevers=
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005930.html b/zarb-ml/mageia-dev/2011-June/005930.html new file mode 100644 index 000000000..9dd237581 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005930.html @@ -0,0 +1,118 @@ + + + + [Mageia-dev] Minimal patching vs. fixing the whole Universe + + + + + + + + + +

[Mageia-dev] Minimal patching vs. fixing the whole Universe

+ Radu-Cristian FOTESCU + beranger5ca at yahoo.ca +
+ Wed Jun 22 22:47:40 CEST 2011 +

+
+ +
I'm known to be grumpy and difficult, but I also believe in simplicity as a policy, therefore I'd like to ask you something.
+
+By no means I want to question Ahmad's judgment, however I strongly disagree with him on one point. As a _principle_. Otherwise, it's a tiny punctual question, but I'd like to know Mageia's patching _policy_.
+
+See comments 50 and downwards:
+
+https://bugs.mageia.org/show_bug.cgi?id=1659#c50
+
+calibre-python2-env-fix.patch replaces 
+'/usr/bin/env python2'
+with 
+'/usr/bin/env python'
+
+The calibre developer has used '/usr/bin/env python' for ages, but relatively recently he has decided to switch to '/usr/bin/env python2' for fear that some distros would use Python 3 by default.
+
+Ahmad insists that '/usr/bin/python' should be used in Mageia.
+
+As long as '/usr/bin/env python' _works_, I see no point in trying to rewrite other people's work.
+
+I would say that the general principle should be to apply a _minimal_ patching, not to try to rewrite the work of the developers of hundreds of packages!
+
+A distro's job is not to judge the work of the _upstream_ developers as long as this is not a real bug.
+
+"Should" Mageia try to "fix" something that is not actually broken? There might be hundreds of packages with thousands and thousands of questionable decisions taken by the upstream developers -- however, why fixing something that works?
+
+You see, I hate conflicts (although I seem to be a maestro in generating them), but I also need simplicity and clear policies. Also, policies that can be applied. "Perfect" policies that would require the revision of hundreds of packages that actually work are not my cup of tea.
+
+Of course, I am _not_ a Mageia packager and this is not "my" package, but I'd like to know Mageia's policy wrt building packages. Normally, patches are not meant to optimize but to fix breakages. If the packagers are compelled to "improve" upstream's work, this can prove to be catastrophic in complex cases.
+
+
+Thank you,
+R-C aka beranger
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005931.html b/zarb-ml/mageia-dev/2011-June/005931.html new file mode 100644 index 000000000..1489a7a77 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005931.html @@ -0,0 +1,117 @@ + + + + [Mageia-dev] Minimal patching vs. fixing the whole Universe + + + + + + + + + +

[Mageia-dev] Minimal patching vs. fixing the whole Universe

+ John Balcaen + mikala at mageia.org +
+ Wed Jun 22 22:58:36 CEST 2011 +

+
+ +
2011/6/22 Radu-Cristian FOTESCU <beranger5ca at yahoo.ca>:
+> I'm known to be grumpy and difficult, but I also believe in simplicity as a policy, therefore I'd like to ask you something.
+>
+> By no means I want to question Ahmad's judgment, however I strongly disagree with him on one point. As a _principle_. Otherwise, it's a tiny punctual question, but I'd like to know Mageia's patching _policy_.
+>
+> See comments 50 and downwards:
+>
+> https://bugs.mageia.org/show_bug.cgi?id=1659#c50
+>
+> calibre-python2-env-fix.patch replaces
+> '/usr/bin/env python2'
+> with
+> '/usr/bin/env python'
+>
+> The calibre developer has used '/usr/bin/env python' for ages, but relatively recently he has decided to switch to '/usr/bin/env python2' for fear that some distros would use Python 3 by default.
+>
+> Ahmad insists that '/usr/bin/python' should be used in Mageia.
+>
+> As long as '/usr/bin/env python' _works_, I see no point in trying to rewrite other people's work.
+>
+> I would say that the general principle should be to apply a _minimal_ patching, not to try to rewrite the work of the developers of hundreds of packages!
+>
+> A distro's job is not to judge the work of the _upstream_ developers as long as this is not a real bug.
+>
+> "Should" Mageia try to "fix" something that is not actually broken? There might be hundreds of packages with thousands and thousands of questionable decisions taken by the upstream developers -- however, why fixing something that works?
+>
+> You see, I hate conflicts (although I seem to be a maestro in generating them), but I also need simplicity and clear policies. Also, policies that can be applied. "Perfect" policies that would require the revision of hundreds of packages that actually work are not my cup of tea.
+>
+> Of course, I am _not_ a Mageia packager and this is not "my" package, but I'd like to know Mageia's policy wrt building packages. Normally, patches are not meant to optimize but to fix breakages. If the packagers are compelled to "improve" upstream's work, this can prove to be catastrophic in complex cases.
+
+We don't have any python2 symlink or binary on mageia.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005932.html b/zarb-ml/mageia-dev/2011-June/005932.html new file mode 100644 index 000000000..18e9afbbe --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005932.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] Minimal patching vs. fixing the whole Universe + + + + + + + + + +

[Mageia-dev] Minimal patching vs. fixing the whole Universe

+ Radu-Cristian FOTESCU + beranger5ca at yahoo.ca +
+ Wed Jun 22 23:02:47 CEST 2011 +

+
+ +
+
+> We don't have any python2 symlink or binary on mageia.
+
+That was not the question. The question was whether '/usr/bin/env python2' should be patched into '/usr/bin/env python' or into '/usr/bin/python'.
+The more general question was whether all the upstream packages should be "optimized". 
+When the upstream contained  '/usr/bin/env python', nobody thought to "fix" it into '/usr/bin/python'.
+
+R-C aka beranger
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005933.html b/zarb-ml/mageia-dev/2011-June/005933.html new file mode 100644 index 000000000..35005da78 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005933.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] [RPM] cauldron tainted/release transcode-1.1.5-5.mga2.tainted + + + + + + + + + +

[Mageia-dev] [RPM] cauldron tainted/release transcode-1.1.5-5.mga2.tainted

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Wed Jun 22 23:11:13 CEST 2011 +

+
+ +
Dick Gevers <dvgevers at xs4all.nl> schrieb am 22.06.2011
+> On Wed, 22 Jun 2011 22:28:18 +0200 (CEST), Mageia Team wrote about
+> [RPM]
+> 
+> cauldron tainted/release transcode-1.1.5-5.mga2.tainted:
+> >Name        : transcode                    Relocations: (not
+> >relocatable) Version     : 1.1.5                            
+> >Vendor: Mageia.Org Release     : 5.mga2.tainted               
+> >Build Date: Wed Jun 22
+> >
+> >This package is in PLF as it could violate some patents.
+> >
+> >obgr_seneca <obgr_seneca> 1.1.5-5.mga2:
+> >+ Revision: 112501
+> >- added tainted to spec file
+> 
+> Really in plf ? Or only in tainted repo?
+Oups!
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110622/2bcfb48f/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005934.html b/zarb-ml/mageia-dev/2011-June/005934.html new file mode 100644 index 000000000..30a199cb4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005934.html @@ -0,0 +1,131 @@ + + + + [Mageia-dev] Minimal patching vs. fixing the whole Universe + + + + + + + + + +

[Mageia-dev] Minimal patching vs. fixing the whole Universe

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Wed Jun 22 23:14:51 CEST 2011 +

+
+ +
On 22 June 2011 22:47, Radu-Cristian FOTESCU <beranger5ca at yahoo.ca> wrote:
+> I'm known to be grumpy and difficult, but I also believe in simplicity as a policy, therefore I'd like to ask you something.
+>
+> By no means I want to question Ahmad's judgment, however I strongly disagree with him on one point. As a _principle_. Otherwise, it's a tiny punctual question, but I'd like to know Mageia's patching _policy_.
+>
+> See comments 50 and downwards:
+>
+> https://bugs.mageia.org/show_bug.cgi?id=1659#c50
+>
+> calibre-python2-env-fix.patch replaces
+> '/usr/bin/env python2'
+> with
+> '/usr/bin/env python'
+>
+> The calibre developer has used '/usr/bin/env python' for ages, but relatively recently he has decided to switch to '/usr/bin/env python2' for fear that some distros would use Python 3 by default.
+>
+> Ahmad insists that '/usr/bin/python' should be used in Mageia.
+>
+
+Actually, I said that the shebang should be removed altogether. Which
+is what was being done all those years calibre existed in the Mandriva
+repos (the same for Fedora, since they do remove the shebang, as the
+calibre spec was originally imported from Fedora, which I said in the
+report too).
+
+> As long as '/usr/bin/env python' _works_, I see no point in trying to rewrite other people's work.
+>
+> I would say that the general principle should be to apply a _minimal_ patching, not to try to rewrite the work of the developers of hundreds of packages!
+>
+> A distro's job is not to judge the work of the _upstream_ developers as long as this is not a real bug.
+>
+> "Should" Mageia try to "fix" something that is not actually broken? There might be hundreds of packages with thousands and thousands of questionable decisions taken by the upstream developers -- however, why fixing something that works?
+>
+> You see, I hate conflicts (although I seem to be a maestro in generating them), but I also need simplicity and clear policies. Also, policies that can be applied. "Perfect" policies that would require the revision of hundreds of packages that actually work are not my cup of tea.
+>
+> Of course, I am _not_ a Mageia packager and this is not "my" package, but I'd like to know Mageia's policy wrt building packages. Normally, patches are not meant to optimize but to fix breakages. If the packagers are compelled to "improve" upstream's work, this can prove to be catastrophic in complex cases.
+>
+>
+> Thank you,
+> R-C aka beranger
+>
+
+
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005935.html b/zarb-ml/mageia-dev/2011-June/005935.html new file mode 100644 index 000000000..402d73b43 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005935.html @@ -0,0 +1,148 @@ + + + + [Mageia-dev] Minimal patching vs. fixing the whole Universe + + + + + + + + + +

[Mageia-dev] Minimal patching vs. fixing the whole Universe

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Wed Jun 22 23:18:18 CEST 2011 +

+
+ +
On 22 June 2011 23:14, Ahmad Samir <ahmadsamir3891 at gmail.com> wrote:
+> On 22 June 2011 22:47, Radu-Cristian FOTESCU <beranger5ca at yahoo.ca> wrote:
+>> I'm known to be grumpy and difficult, but I also believe in simplicity as a policy, therefore I'd like to ask you something.
+>>
+>> By no means I want to question Ahmad's judgment, however I strongly disagree with him on one point. As a _principle_. Otherwise, it's a tiny punctual question, but I'd like to know Mageia's patching _policy_.
+>>
+>> See comments 50 and downwards:
+>>
+>> https://bugs.mageia.org/show_bug.cgi?id=1659#c50
+>>
+>> calibre-python2-env-fix.patch replaces
+>> '/usr/bin/env python2'
+>> with
+>> '/usr/bin/env python'
+>>
+>> The calibre developer has used '/usr/bin/env python' for ages, but relatively recently he has decided to switch to '/usr/bin/env python2' for fear that some distros would use Python 3 by default.
+>>
+>> Ahmad insists that '/usr/bin/python' should be used in Mageia.
+>>
+>
+> Actually, I said that the shebang should be removed altogether. Which
+> is what was being done all those years calibre existed in the Mandriva
+> repos (the same for Fedora, since they do remove the shebang, as the
+> calibre spec was originally imported from Fedora, which I said in the
+> report too).
+
+Of course, or just /usr/bin/python. The /usr/bin/env way may be useful
+for upstream when creating binary tarballs; but not for us we build
+the package, and we know which version of python exists in the release
+we're pushing it to.
+
+Also, /usr/bin/python2 doesn't exist to begin with, as mikala pointed out.
+
+
+>
+>> As long as '/usr/bin/env python' _works_, I see no point in trying to rewrite other people's work.
+>>
+>> I would say that the general principle should be to apply a _minimal_ patching, not to try to rewrite the work of the developers of hundreds of packages!
+>>
+>> A distro's job is not to judge the work of the _upstream_ developers as long as this is not a real bug.
+>>
+>> "Should" Mageia try to "fix" something that is not actually broken? There might be hundreds of packages with thousands and thousands of questionable decisions taken by the upstream developers -- however, why fixing something that works?
+>>
+>> You see, I hate conflicts (although I seem to be a maestro in generating them), but I also need simplicity and clear policies. Also, policies that can be applied. "Perfect" policies that would require the revision of hundreds of packages that actually work are not my cup of tea.
+>>
+>> Of course, I am _not_ a Mageia packager and this is not "my" package, but I'd like to know Mageia's policy wrt building packages. Normally, patches are not meant to optimize but to fix breakages. If the packagers are compelled to "improve" upstream's work, this can prove to be catastrophic in complex cases.
+>>
+>>
+>> Thank you,
+>> R-C aka beranger
+>>
+>
+>
+>
+> --
+> Ahmad Samir
+>
+
+
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005936.html b/zarb-ml/mageia-dev/2011-June/005936.html new file mode 100644 index 000000000..a4937da36 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005936.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] Minimal patching vs. fixing the whole Universe + + + + + + + + + +

[Mageia-dev] Minimal patching vs. fixing the whole Universe

+ Radu-Cristian FOTESCU + beranger5ca at yahoo.ca +
+ Wed Jun 22 23:27:52 CEST 2011 +

+
+ +
+
+> Actually, I said that the shebang should be removed altogether. Which
+> is what was being done all those years calibre existed in the Mandriva
+> repos (the same for Fedora, since they do remove the shebang, as the
+> calibre spec was originally imported from Fedora, which I said in the
+> report too).
+
+Yes, I noticed in the spec a set of sed lines supposed to remove all the shebangs.
+However, somehow, setup.py adds them back at some point, even replacing python with python2.
+
+As long as, in the end, replacing python2 with python makes the application work, why should _anyone_ care?
+Calibre's developer had his idiosyncrasies, why should the downstream take over his app?
+
+
+R-C aka beranger
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005937.html b/zarb-ml/mageia-dev/2011-June/005937.html new file mode 100644 index 000000000..f4f95440b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005937.html @@ -0,0 +1,121 @@ + + + + [Mageia-dev] Minimal patching vs. fixing the whole Universe + + + + + + + + + +

[Mageia-dev] Minimal patching vs. fixing the whole Universe

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Wed Jun 22 23:34:12 CEST 2011 +

+
+ +
Op woensdag 22 juni 2011 22:47:40 schreef Radu-Cristian FOTESCU:
+> I would say that the general principle should be to apply a _minimal_
+> patching, not to try to rewrite the work of the developers of hundreds of
+> packages!
+> 
+> A distro's job is not to judge the work of the _upstream_ developers as
+> long as this is not a real bug.
+> 
+> "Should" Mageia try to "fix" something that is not actually broken? There
+> might be hundreds of packages with thousands and thousands of questionable
+> decisions taken by the upstream developers -- however, why fixing
+> something that works?
+> 
+> You see, I hate conflicts (although I seem to be a maestro in generating
+> them), but I also need simplicity and clear policies. Also, policies that
+> can be applied. "Perfect" policies that would require the revision of
+> hundreds of packages that actually work are not my cup of tea.
+> 
+> Of course, I am _not_ a Mageia packager and this is not "my" package, but
+> I'd like to know Mageia's policy wrt building packages. Normally, patches
+> are not meant to optimize but to fix breakages. If the packagers are
+> compelled to "improve" upstream's work, this can prove to be catastrophic
+> in complex cases.
+> 
+> 
+> Thank you,
+> R-C aka beranger
+
+
+imho, it's something like: "as long as you're patching it anyway, make it 
+python and possibly add a conflicts with python >= 3.0" or something.
+
+besides, by the time we'll actually have python3, it's likely that the 
+upstream will already have been ported to python3... or the buildsystem would 
+fail anyway...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005938.html b/zarb-ml/mageia-dev/2011-June/005938.html new file mode 100644 index 000000000..ccf5b5fd4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005938.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] Minimal patching vs. fixing the whole Universe + + + + + + + + + +

[Mageia-dev] Minimal patching vs. fixing the whole Universe

+ Radu-Cristian FOTESCU + beranger5ca at yahoo.ca +
+ Wed Jun 22 23:33:39 CEST 2011 +

+
+ +
+
+> Also, /usr/bin/python2 doesn't exist to begin with, as mikala pointed out.
+
+As I "repointed", the question was not that one. As long as calibre has used env with python, not python2, it worked. Now that the developer changed that, the least intrusive way would be to just remove the "2".
+
+I personally don't like a lot of decisions taken by Kovid Goyal, either wrt functionality, or to things hard-coded rather messy, but it is _his_ application.
+
+
+Either way, I would rather like to retire myself from this discussion. Sorry to have started it. Packagers are free to do whatever they feel like.
+
+Cheers,
+R-C aka beranger
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005939.html b/zarb-ml/mageia-dev/2011-June/005939.html new file mode 100644 index 000000000..ddc578158 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005939.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] Minimal patching vs. fixing the whole Universe + + + + + + + + + +

[Mageia-dev] Minimal patching vs. fixing the whole Universe

+ nicolas vigier + boklm at mars-attacks.org +
+ Wed Jun 22 23:34:51 CEST 2011 +

+
+ +
On Wed, 22 Jun 2011, Radu-Cristian FOTESCU wrote:
+
+> 
+> A distro's job is not to judge the work of the _upstream_ developers as long as this is not a real bug.
+
+But it's to integrate software, and apply common policy to all of them.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005940.html b/zarb-ml/mageia-dev/2011-June/005940.html new file mode 100644 index 000000000..88efe688c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005940.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] Minimal patching vs. fixing the whole Universe + + + + + + + + + +

[Mageia-dev] Minimal patching vs. fixing the whole Universe

+ Radu-Cristian FOTESCU + beranger5ca at yahoo.ca +
+ Wed Jun 22 23:39:29 CEST 2011 +

+
+ +
+
+>>  A distro's job is not to judge the work of the _upstream_ developers as 
+> long as this is not a real bug.
+> 
+> But it's to integrate software, and apply common policy to all of them.
+
+
+ok, say a distro has 200 packages that use python, for a total of 20,000 *.py files. 
+now what, the limited resources of a distro should be used to "patch optimally" the first line of all those 20,000 *.py files, just because this would mean to use a common policy?
+_regardless_ of the fact that those files actually run?
+
+this is so crazy in practice that... I don't know what to say. I'm refraining myself from saying things I'd regret.
+
+R-C aka beranger
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005941.html b/zarb-ml/mageia-dev/2011-June/005941.html new file mode 100644 index 000000000..b4caf2009 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005941.html @@ -0,0 +1,120 @@ + + + + [Mageia-dev] Minimal patching vs. fixing the whole Universe + + + + + + + + + +

[Mageia-dev] Minimal patching vs. fixing the whole Universe

+ David W. Hodgins + davidwhodgins at gmail.com +
+ Wed Jun 22 23:51:02 CEST 2011 +

+
+ +
On Wed, 22 Jun 2011 16:47:40 -0400, Radu-Cristian FOTESCU <beranger5ca at yahoo.ca> wrote:
+
+> As long as '/usr/bin/env python' _works_, I see no point in trying to rewrite other people's work.
+
+Excluding the calibre scripts, in /usr/bin of a Mageia 1 kde clean installation ...
+# grep -I python *|grep '#!'|grep env
+ebook-convert:#!/usr/bin/env python
+ebook-device:#!/usr/bin/env python
+ebook-meta:#!/usr/bin/env python
+ebook-viewer:#!/usr/bin/env python
+epub-fix:#!/usr/bin/env python
+fetch-ebook-metadata:#!/usr/bin/env python
+gsettings-schema-convert:#!/usr/bin/env python
+jack_control:#!/usr/bin/env python
+lrf2lrs:#!/usr/bin/env python
+lrfviewer:#!/usr/bin/env python
+lrs2lrf:#!/usr/bin/env python
+markdown-calibre:#!/usr/bin/env python
+pdfmanipulate:#!/usr/bin/env python
+pykdeuic4:#!/usr/bin/env python
+pykdeuic4:header = """#!/usr/bin/env python
+web2disk:#!/usr/bin/env python
+
+In general, I agree with you.  If it isn't broken, don't fix it.
+
+However, in this case, the python2 had to be changed to python.
+
+The environment is not being modified, so it is adding an unneeded process,
+which should be discouraged.
+
+Since you have to change the line anyway, I have to agree with Ahmad, that
+it should be changed to #!/usr/bin/python.
+
+Regards, Dave Hodgins
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005942.html b/zarb-ml/mageia-dev/2011-June/005942.html new file mode 100644 index 000000000..4b9b7d674 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005942.html @@ -0,0 +1,151 @@ + + + + [Mageia-dev] Minimal patching vs. fixing the whole Universe + + + + + + + + + +

[Mageia-dev] Minimal patching vs. fixing the whole Universe

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Jun 23 00:08:35 CEST 2011 +

+
+ +
'Twas brillig, and David W. Hodgins at 22/06/11 22:51 did gyre and gimble:
+> On Wed, 22 Jun 2011 16:47:40 -0400, Radu-Cristian FOTESCU
+> <beranger5ca at yahoo.ca> wrote:
+> 
+>> As long as '/usr/bin/env python' _works_, I see no point in trying to
+>> rewrite other people's work.
+> 
+> Excluding the calibre scripts, in /usr/bin of a Mageia 1 kde clean
+> installation ...
+> # grep -I python *|grep '#!'|grep env
+> ebook-convert:#!/usr/bin/env python
+> ebook-device:#!/usr/bin/env python
+> ebook-meta:#!/usr/bin/env python
+> ebook-viewer:#!/usr/bin/env python
+> epub-fix:#!/usr/bin/env python
+> fetch-ebook-metadata:#!/usr/bin/env python
+> gsettings-schema-convert:#!/usr/bin/env python
+> jack_control:#!/usr/bin/env python
+> lrf2lrs:#!/usr/bin/env python
+> lrfviewer:#!/usr/bin/env python
+> lrs2lrf:#!/usr/bin/env python
+> markdown-calibre:#!/usr/bin/env python
+> pdfmanipulate:#!/usr/bin/env python
+> pykdeuic4:#!/usr/bin/env python
+> pykdeuic4:header = """#!/usr/bin/env python
+> web2disk:#!/usr/bin/env python
+> 
+> In general, I agree with you.  If it isn't broken, don't fix it.
+> 
+> However, in this case, the python2 had to be changed to python.
+> 
+> The environment is not being modified, so it is adding an unneeded process,
+> which should be discouraged.
+> 
+> Since you have to change the line anyway, I have to agree with Ahmad, that
+> it should be changed to #!/usr/bin/python.
+
+
+I think it's relatively unimportant overall, but:
+
+ 1) /usr/bin/python should be marginally faster
+ 2) /usr/bin/python prevents you testing easily with a new python
+version (or just a new build) in a custom prefix).
+
+So 1) is a (very slight) pro for everyone, but 2) is a pretty big con
+for developers playing with python builds.... of course in that case a
+simple "sudo mv /usr/bin/python /usr/bin/python.orig; ln -s
+/path/to/my/custom/build/of/python /usr/bin/python" should allow said
+developer to test fine.
+
+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-June/005943.html b/zarb-ml/mageia-dev/2011-June/005943.html new file mode 100644 index 000000000..2028b29b2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005943.html @@ -0,0 +1,126 @@ + + + + [Mageia-dev] Minimal patching vs. fixing the whole Universe + + + + + + + + + +

[Mageia-dev] Minimal patching vs. fixing the whole Universe

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Thu Jun 23 01:21:22 CEST 2011 +

+
+ +
Op woensdag 22 juni 2011 23:51:02 schreef David W. Hodgins:
+> On Wed, 22 Jun 2011 16:47:40 -0400, Radu-Cristian FOTESCU 
+<beranger5ca at yahoo.ca> wrote:
+> > As long as '/usr/bin/env python' _works_, I see no point in trying to
+> > rewrite other people's work.
+> 
+> Excluding the calibre scripts, in /usr/bin of a Mageia 1 kde clean
+> installation ... # grep -I python *|grep '#!'|grep env
+> ebook-convert:#!/usr/bin/env python
+> ebook-device:#!/usr/bin/env python
+> ebook-meta:#!/usr/bin/env python
+> ebook-viewer:#!/usr/bin/env python
+> epub-fix:#!/usr/bin/env python
+> fetch-ebook-metadata:#!/usr/bin/env python
+> gsettings-schema-convert:#!/usr/bin/env python
+> jack_control:#!/usr/bin/env python
+> lrf2lrs:#!/usr/bin/env python
+> lrfviewer:#!/usr/bin/env python
+> lrs2lrf:#!/usr/bin/env python
+> markdown-calibre:#!/usr/bin/env python
+> pdfmanipulate:#!/usr/bin/env python
+> pykdeuic4:#!/usr/bin/env python
+> pykdeuic4:header = """#!/usr/bin/env python
+> web2disk:#!/usr/bin/env python
+> 
+> In general, I agree with you.  If it isn't broken, don't fix it.
+> 
+> However, in this case, the python2 had to be changed to python.
+> 
+> The environment is not being modified, so it is adding an unneeded process,
+> which should be discouraged.
+> 
+> Since you have to change the line anyway, I have to agree with Ahmad, that
+> it should be changed to #!/usr/bin/python.
+> 
+> Regards, Dave Hodgins
+
+that is exactly my sentiment, and i think this describes a good "policy"
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005944.html b/zarb-ml/mageia-dev/2011-June/005944.html new file mode 100644 index 000000000..07c76a690 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005944.html @@ -0,0 +1,117 @@ + + + + [Mageia-dev] [RPM] cauldron core/release telepathy-glib-0.15.2-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release telepathy-glib-0.15.2-1.mga2

+ John Balcaen + mikala at mageia.org +
+ Thu Jun 23 01:43:03 CEST 2011 +

+
+ +
2011/6/22 Mageia Team <buildsystem-daemon at mageia.org>:
+> Name        : telepathy-glib               Relocations: (not relocatable)
+> Version     : 0.15.2                            Vendor: Mageia.Org
+> Release     : 1.mga2                        Build Date: Wed Jun 22 22:02:17 2011
+> Install Date: (not installed)               Build Host: jonund
+> Group       : Networking/Instant messaging   Source RPM: (none)
+> Size        : 3082790                          License: LGPLv2+
+> Signature   : (none)
+> Packager    : Mageia Team <http://www.mageia.org>
+> URL         : http://telepathy.freedesktop.org/wiki/
+> Summary     : A glib utility library for the telepathy framework
+> Description :
+> telepathy-glib is a glib utility library for the telepathy framework.
+>
+> mikala <mikala> 0.15.2-1.mga2:
+> + Revision: 112483
+> - Update tarball to 0.15.2
+
+I made an error here while updating telepathy-glib.
+Bolkm has been kind enough to remove this file from repository.
+the 0.14.8 should be soon available on mirrors so could you please
+replace the lib(64)telepathy-glib0-0.15.2-1.mga2 from your
+installation by the new package in case you did upgrade during the 4
+hours when this file was available on repository
+
+Regards,
+
+-- 
+Balcaen John
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005945.html b/zarb-ml/mageia-dev/2011-June/005945.html new file mode 100644 index 000000000..f72f1704c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005945.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] Minimal patching vs. fixing the whole Universe + + + + + + + + + +

[Mageia-dev] Minimal patching vs. fixing the whole Universe

+ David W. Hodgins + davidwhodgins at gmail.com +
+ Thu Jun 23 02:00:31 CEST 2011 +

+
+ +
On Wed, 22 Jun 2011 18:08:35 -0400, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+
+>  2) /usr/bin/python prevents you testing easily with a new python
+> version (or just a new build) in a custom prefix).
+
+Running something like "/usr/bin/python2.7 /usr/bin/calibre" ignores the
+shebang, so it's still easy to test with a different python version.
+
+Regards, Dave Hodgins
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005946.html b/zarb-ml/mageia-dev/2011-June/005946.html new file mode 100644 index 000000000..6d50b82bf --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005946.html @@ -0,0 +1,144 @@ + + + + [Mageia-dev] Minimal patching vs. fixing the whole Universe + + + + + + + + + +

[Mageia-dev] Minimal patching vs. fixing the whole Universe

+ Michael Scherer + misc at zarb.org +
+ Thu Jun 23 03:44:31 CEST 2011 +

+
+ +
Le mercredi 22 juin 2011 à 23:08 +0100, Colin Guthrie a écrit :
+> 'Twas brillig, and David W. Hodgins at 22/06/11 22:51 did gyre and gimble:
+> > On Wed, 22 Jun 2011 16:47:40 -0400, Radu-Cristian FOTESCU
+> > <beranger5ca at yahoo.ca> wrote:
+> > 
+> >> As long as '/usr/bin/env python' _works_, I see no point in trying to
+> >> rewrite other people's work.
+> > 
+> > Excluding the calibre scripts, in /usr/bin of a Mageia 1 kde clean
+> > installation ...
+> > # grep -I python *|grep '#!'|grep env
+> > ebook-convert:#!/usr/bin/env python
+> > ebook-device:#!/usr/bin/env python
+> > ebook-meta:#!/usr/bin/env python
+> > ebook-viewer:#!/usr/bin/env python
+> > epub-fix:#!/usr/bin/env python
+> > fetch-ebook-metadata:#!/usr/bin/env python
+> > gsettings-schema-convert:#!/usr/bin/env python
+> > jack_control:#!/usr/bin/env python
+> > lrf2lrs:#!/usr/bin/env python
+> > lrfviewer:#!/usr/bin/env python
+> > lrs2lrf:#!/usr/bin/env python
+> > markdown-calibre:#!/usr/bin/env python
+> > pdfmanipulate:#!/usr/bin/env python
+> > pykdeuic4:#!/usr/bin/env python
+> > pykdeuic4:header = """#!/usr/bin/env python
+> > web2disk:#!/usr/bin/env python
+> > 
+> > In general, I agree with you.  If it isn't broken, don't fix it.
+> > 
+> > However, in this case, the python2 had to be changed to python.
+> > 
+> > The environment is not being modified, so it is adding an unneeded process,
+> > which should be discouraged.
+> > 
+> > Since you have to change the line anyway, I have to agree with Ahmad, that
+> > it should be changed to #!/usr/bin/python.
+> 
+> 
+> I think it's relatively unimportant overall, but:
+> 
+>  1) /usr/bin/python should be marginally faster
+>  2) /usr/bin/python prevents you testing easily with a new python
+> version (or just a new build) in a custom prefix).
+> 
+> So 1) is a (very slight) pro for everyone, but 2) is a pretty big con
+> for developers playing with python builds.... of course in that case a
+> simple "sudo mv /usr/bin/python /usr/bin/python.orig; ln -s
+> /path/to/my/custom/build/of/python /usr/bin/python" should allow said
+> developer to test fine.
+
+If python point to a different version ( like some self compiled python
+2.6, or python 3 ), I fear that using env will silently break lots of
+applications, since the library and modules would likely not be there.
+
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005947.html b/zarb-ml/mageia-dev/2011-June/005947.html new file mode 100644 index 000000000..5314a8461 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005947.html @@ -0,0 +1,113 @@ + + + + [Mageia-dev] Minimal patching vs. fixing the whole Universe + + + + + + + + + +

[Mageia-dev] Minimal patching vs. fixing the whole Universe

+ Michael Scherer + misc at zarb.org +
+ Thu Jun 23 03:51:55 CEST 2011 +

+
+ +
Le mercredi 22 juin 2011 à 14:39 -0700, Radu-Cristian FOTESCU a écrit :
+> 
+> >>  A distro's job is not to judge the work of the _upstream_ developers as 
+> > long as this is not a real bug.
+> > 
+> > But it's to integrate software, and apply common policy to all of them.
+> 
+> 
+> ok, say a distro has 200 packages that use python, for a total of 20,000 *.py files. 
+> now what, the limited resources of a distro should be used to "patch optimally" the first line of all those 20,000 *.py files, just because this would mean to use a common policy?
+> _regardless_ of the fact that those files actually run?
+
+
+Technically, we can use scripts, like we do for stripping the 50 000
+binaries that can be found in */bin/ 
+
+Or like we do to have the same compression on the 85000 man pages,
+instead of patching every Makefile in order to use xz instead of
+nothing, gz, bz2.
+
+And we even manage to have the same C flags for compilation. So
+stripping env should be a big issue, if found desirable.
+
+After all, we already detect python to add a dependency on the
+interpreter in rpm, so the logic is already present.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005948.html b/zarb-ml/mageia-dev/2011-June/005948.html new file mode 100644 index 000000000..a8d772fdd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005948.html @@ -0,0 +1,124 @@ + + + + [Mageia-dev] [RPM] cauldron core/release telepathy-glib-0.15.2-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release telepathy-glib-0.15.2-1.mga2

+ Zé + mmodem00 at gmail.com +
+ Thu Jun 23 03:54:46 CEST 2011 +

+
+ +
2011/6/23 John Balcaen <mikala at mageia.org>:
+> 2011/6/22 Mageia Team <buildsystem-daemon at mageia.org>:
+>> Name        : telepathy-glib               Relocations: (not relocatable)
+>> Version     : 0.15.2                            Vendor: Mageia.Org
+>> Release     : 1.mga2                        Build Date: Wed Jun 22 22:02:17 2011
+>> Install Date: (not installed)               Build Host: jonund
+>> Group       : Networking/Instant messaging   Source RPM: (none)
+>> Size        : 3082790                          License: LGPLv2+
+>> Signature   : (none)
+>> Packager    : Mageia Team <http://www.mageia.org>
+>> URL         : http://telepathy.freedesktop.org/wiki/
+>> Summary     : A glib utility library for the telepathy framework
+>> Description :
+>> telepathy-glib is a glib utility library for the telepathy framework.
+>>
+>> mikala <mikala> 0.15.2-1.mga2:
+>> + Revision: 112483
+>> - Update tarball to 0.15.2
+>
+> I made an error here while updating telepathy-glib.
+> Bolkm has been kind enough to remove this file from repository.
+> the 0.14.8 should be soon available on mirrors so could you please
+> replace the lib(64)telepathy-glib0-0.15.2-1.mga2 from your
+> installation by the new package in case you did upgrade during the 4
+> hours when this file was available on repository
+
+I think would be better to just add epoch, that way nothing would be
+broke and no one would have to remove that version.
+
+> Regards,
+>
+> --
+> Balcaen John
+>
+
+
+
+-- 
+Zé
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005949.html b/zarb-ml/mageia-dev/2011-June/005949.html new file mode 100644 index 000000000..e3acf284c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005949.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] libproxy vs biarch & libexecdir + + + + + + + + + +

[Mageia-dev] libproxy vs biarch & libexecdir

+ Michael Scherer + misc at zarb.org +
+ Thu Jun 23 03:54:57 CEST 2011 +

+
+ +
Le mercredi 22 juin 2011 à 23:54 +0800, Funda Wang a écrit :
+> 2011/6/22 Christiaan Welvaart <cjw at daneel.dyndns.org>:
+> > - the helper app (?) pxgsettings is put in libexecdir by upstream, so
+> >  IMHO it should be in /usr/lib or /usr/libexec, not %{_libdir} which
+> >  %{_libexecdir} expands to.
+> %_libexecdir expands to %_libdir, for years since mandrake.
+
+IIRC, /usr/libexec is not in FHS. While that would not cause a problem,
+it also mean that some specific Fedora stuff, and so this may be
+surprising to people.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005950.html b/zarb-ml/mageia-dev/2011-June/005950.html new file mode 100644 index 000000000..c4c700053 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005950.html @@ -0,0 +1,393 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ andre999 + andr55 at laposte.net +
+ Thu Jun 23 05:04:30 CEST 2011 +

+
+ +
andre999 a écrit :
+> Michael Scherer a écrit :
+>>
+>> Le samedi 18 juin 2011 à 23:49 -0400, andre999 a écrit :
+>>> Michael Scherer a écrit :
+>>>>
+>>>> Le samedi 18 juin 2011 à 03:38 -0400, andre999 a écrit :
+>>>>> Michael Scherer a écrit :
+>>
+>>>> If people work the same amount of time, with work divided on 2
+>>>> products,
+>>>> they must share their time, and usually work less than if they focused
+>>>> only on one product, unless there is twice the ressources. But I doubt
+>>>> this will happen for us, so let's assume that ressources are fixed.
+>>>
+>>> That was my assumption : resources fixed in terms of time spent.
+>>> And why would that divide a contributor's focus more than now ?
+>>> They would just have a choice.
+>>
+>> So before, the choice is between :
+>> - not doing anything
+>> - bugfixing
+> - or doing something elsewhere.
+>>
+>> After your proposal, there is :
+>> - not doing anything
+>> - bugfixing
+>> - uploading new stuff to cauldron
+>>
+>> And you fail to see how it divert focus ?
+>
+> We have to remember that packager time is not an ubiquitous resource. If
+> a packager cannot use their time efficiently during freeze, they have
+> incentive to contribute their time elsewhere. It is just human nature.
+> Admittedly this is more likely to affect packagers with less broad-based
+> skills, but such packagers do not make insignificant contributions.
+> As far as diverting focus, does the existance of many distros, providing
+> much more choice, divert focus ? Likely to some extent, but not many
+> packagers contribute to 4 to 6 distros and support in the order of 1000
+> packages. That's more the exception, for packagers with exceptional skills.
+>
+>>> Now during the freeze, someone that wants to contribute to cauldron,
+>>> but can't or chooses not to
+>>> contribute to pre-release bugfix, is not contributing.
+>>> So in practice, we risk to have more time contributed during the freeze.
+>>
+>> My own experience tell the contrary, but maybe you should ask to Anne
+>> her opinion if you do not believe me, or to others people who did
+>> distribution releases ( and not software releases, which is slightly
+>> different, mainly because there is less ).
+>
+> Until we try it, we don't know how much effect it will have. To the best
+> of my knowledge Mandrake/Mandriva and certainly Mageia has not tried
+> this approach. We are both working on conjectures, and we can't know
+> until we (or some other distro with similar resources) tries it.
+> I find it difficult to believe that it will have a negative effect. And
+> I think it would be useful to try it early in the development of Mageia.
+> Even experienced programmers, who have to support different versions of
+> the same software, run into cases where it is very convient -- and more
+> efficient -- to do parallel updates for example. I run into that often
+> enough myself.
+>
+>>>> Now, of course, we can say "what if people do not divide their work in
+>>>> 2 ?"
+>>>>
+>>>> So let's call :
+>>>> - F the time spent on bugfix during the freeze
+>>>> - C the time spent on cauldron during the freeze
+>>>>
+>>>> We can assume that :
+>>>> C + F = Y
+>>>>
+>>>> So the equation become :
+>>>> C + ( X - Y ) + F
+>>>> = C + F - Y + X
+>>>> = X
+>>>>
+>>>> So no matter how you divide the time, you still have the same amount of
+>>>> time spent overall.
+>>>
+>>> As I assumed :)
+>>
+>> No.
+>> "the cauldron cycle is extented by the time of the pre-release freeze.
+>> e.g. In a release cycle of 6 months and a pre-release freeze of 1 month,
+>> the cauldron cycle would be 7 months."
+>
+> Agreed. I've already said that.
+>
+>> The cauldron cycle would be 7 months just on the calendar, but 6 months
+>> worth of work, as demonstrated.
+>>
+>> "A 1-month pre-release freeze would add 1 month to cauldron
+>> development time."
+>>
+>> That's the same, you do not add real months, just months on the calendar.
+>
+> As I said, my basic assumption that the same number of packager hours
+> are contributed. Certain factors suggest that one could expect somewhat
+> more time contributed, and a number of others that the time would be
+> used more efficiently. Nothing suggests that less time would be available.
+>
+>>>> Now, the real important question is "can we really exchange work
+>>>> done as
+>>>> part of C for work done as part of F".
+>>>>
+>>>> And so "if I do regular packages updates on cauldron at the begining of
+>>>> the cycle, does it count as bugfixing for the release in the end of the
+>>>> cycle" ?
+>>>>
+>>>> To me, the answer is clearly no. If it was somethig we could exchange,
+>>>> we would not have to make a freeze in the first place to make sure that
+>>>> only bugfixes are uploaded in cauldron.
+>>>>
+>>>> So the only way to maximize the time spent on bugfixes is to have F
+>>>> = Y,
+>>>> and so C = 0. Ie, do like we do now.
+>>>
+>>> I really don't follow this line of reasoning.
+>>> The focus on bug fixes starts with the freeze. So a longer freeze
+>>> would give more time to focus on
+>>> bug fixes.
+>>
+>> The focus on bugfixing start with version freeze, since what introduce
+>> problem is various changes, and new versions of softwares usually bring
+>> new changes. Then we block all uploads except bug fixes, and then all
+>> uploads unless very serious bug fixes ( ie, release blocker ). So the
+>> focus start much before the last freeze, and you are quite unclear.
+>
+> It terms of freeze, I'm referring to the first freeze for the release.
+> The different stages will happen (more or less) as they do now.
+>
+>>>> And unless you show that letting people work on cauldron will bring
+>>>> more
+>>>> ressources , and more than the one we will lose du to people who do not
+>>>> want to work on bugfixes and the release, I doubt this will change.
+>>>
+>>> Ok. Obviously I need to clarify my point of view.
+>>> Firstly, my assumption was that at least as much time would be spent
+>>> on bug fixing during the
+>>> longer freeze, but being less rushed, would tend to produce better
+>>> quality results. (And less
+>>> aggravation for ennael) (That is certainly how it works in the
+>>> non-libre world.)
+>>
+>> You do not say much how you extend the freeze to be longer, nor even
+>> that the freeze appear sooner, reread your mail. Nor what kind of freeze
+>> would it be.
+>
+> If this scheme were adopted, such details would probably be best decided
+> by those most experienced with the process, above all ennael, and
+> packagers such as yourself. Offhand, maybe 2 weeks longer would be
+> adequate, to give less rush and compensate for contributions to
+> non-freeze cauldron.
+> (See also above.)
+>
+>> The only mention of the duration of the freeze is :
+>> "A 1-month pre-release freeze would add 1 month to cauldron development
+>> time."
+>>
+>> The version freeze started on 20 april
+>> ( https://mageia.org/pipermail/mageia-dev/20110419/004066.html ), which
+>> is more than 1 month. The release freeze was on 14 may, which is 2
+>> weeks.
+>>
+>> Given that the version freeze is when we start to ask to people to focus
+>> on bugfixes and when we prevent packagers from uploading newer versions
+>> of packages, the proposed 1 month pre-release freeze is unclear and
+>> unexplained.
+>
+> One month was an arbitrary figure, just to demonstrate the principle.
+> Obviously from what you say, it would be longer. (It did seem much much
+> longer.)
+> My idea was to have a somewhat (but not excessively) longer freeze period.
+>
+>>> I don't see how having the choice between contributing to pre-release
+>>> or cauldron during the freeze
+>>> will lead to us loosing _any_ contributors.
+>>
+>> We do not lose contributors, we lose the work of people that prefer to
+>> work on cauldron by uploading new versions rather than bug fixing, and
+>> from people that will prefer to test and use cauldron rather than the
+>> future stable release, because that's easier, there is no deadline, nor
+>> any obligation, and there is newer stuff.
+>
+> So you fear a lack of commitment by packagers. That is a different
+> question.
+> I think that packagers can be motivated to help. But maybe those
+> demotivated by their inability to contribute efficiently to pre-release
+> will contribute to cauldron during the freeze ? That's not a loss.
+>
+>>> If during freeze, a packager has a choice between attempting to help
+>>> with a bugfix in pre-release
+>>> for a package with which s/he is not familiar, or contributing to
+>>> cauldron for something with which
+>>> s/he is familiar, it would be evidently more efficient to contribute
+>>> to cauldron.
+>>
+>> You are placing a wrong dichotomy. The choice is not between "fixing
+>> something efficiently on cauldron vs fixing un-efficiently on
+>> pre-release", but between "fixing un-efficiently" vs "not fixing".
+>
+> In my world, those unable to contribute efficiently are much less
+> motivated to contribute. So this change could have the effect to more
+> motivate less experienced packagers. Which could be a big plus in the
+> longer term.
+> So although your dichotomy would apply to many packagers, particularly
+> those more skilled, definitely not all.
+>
+>>> Similarly, if a packager contributes a bug fix to pre-release, and a
+>>> newer package already exists
+>>> in cauldron for which the same bug fix must be applied, it is more
+>>> efficient to apply the same
+>>> patch right away, than to wait until freeze is over. (Personnally
+>>> I've encountered this sort of
+>>> situation with similar but different software many times. Any
+>>> experienced programmer should
+>>> understand this point.)
+>>
+>> With the current process, the fix is already applied for next cauldron
+>> cycle, since the package is the same, there is no branching.
+>
+> Suppose that during freeze a packager discovers an important bug fix
+> patch along with a newer version. The patch must be applied to both the
+> current and newer version, the latter being blocked from going into the
+> freeze. So the fix must be applied to both. So why can't the packager
+> put the newer version into cauldron and apply the patch, if they have
+> time ? It would be a more efficient use of time.
+>
+>>> So there are a lot of (admittedly small) synergies which should lead
+>>> to packager time being more
+>>> efficiently used.
+>>> Not counting the likelyhood that some packagers would contribute
+>>> somewhat more time, being able to
+>>> contribute to cauldron during freeze.
+>>> The major benefit in my mind is the longer freeze period.
+>>
+>> Which mean that we will have more outdated software if we freeze sooner.
+>
+> But not as outdated (on average during the cycle) as it would be if we
+> go from a 6-month to 9-month release cycle. I'm suggesting a difference
+> probably in the order of weeks.
+>
+>> Assuming that the pre-release freeze you are speaking about is what the
+>> packagers know as "release freeze", this means the version freeze will
+>> be sooner too. Assuming that what you call "pre-release freeze" is the
+>> version freeze, then the freeze period would just be shorter.
+>
+> I was thinking of the first freeze, when there starts to be a lot of
+> focus on bug fixes. This would allow immediate unfreeze of cauldron. But
+> maybe it would be better for the second stage. A lot of packages (if not
+> most) will have a different version for the subsequent release, so bug
+> fixes -- even if the same patch -- would have to be applied separately
+> for the subsequent release, anyway.
+> Any packages patched for pre-release could be simply copied back to
+> cauldron, as well. The process could be even automated.
+>
+>> Also, your point seems to forget to take in account that people can
+>> focus on bugfixs without any freeze of the distribution, yet, they do
+>> not seems to do so.
+>
+> Basically I assumed that.
+>
+>> People rushing packages in the last minute as it always happen is the
+>> prime example of why people prefer cauldron rather than bugfix.
+>
+> But doesn't blocking cauldron during freeze reinforce this behavior ?
+>
+>>> In any case, it seems to me that the bigger liability would be being
+>>> out of sync with the 6-month
+>>> release cycle of kde, gnome, as well as many other distros.
+>>
+>> s/many others distros/ubuntu and fedora/.
+>
+> OK. Mostly just the 2 biggest distros.
+>
+>> Opensuse has a cycle of 8 months, Debian is not really time based ( and
+>> is around 1 and 2 years ), Mandriva is gone on 1 year cycle, Arch,
+>> Pclinuxos or others popular distributions from distrowatch do not seems
+>> on a regular cycle. And as someone said, Mint is more released "when
+>> ready after seeing fix on Ubuntu" than being a 6 months cycle ( even if
+>> that's very similar ).
+>
+> I still see short_cauldron_freeze + copy_to_pre-release +
+> unfreeze_cauldron as a better approach.
+> Even if we do go for a 9-month release cycle.
+>
+> It is not as though we would be adopting the parallel development scheme
+> of Mozilla, having a number of parallel branches in development at the
+> same time. That would require much more work.
+> It would only be for the freeze period.
+>
+> Having cauldron blocked for 6 weeks seems excessive. Many packagers are
+> left with little to contribute. And in certain cases, even those focused
+> and efficient on bug fixes, will find it advantageous to be able to make
+> updates to cauldron which are currently blocked.
+>
+> another 2 cents :)
+>
+
+I'd like to consolidate and clarify my ideas regarding an amended freeze process, taking into 
+account the critiques.
+That is, that for the freeze which leads to the release, that we
+1) freeze cauldron
+2) copy caudron to a pre-release branch, which remains frozen, and will become the release
+3) then unfreeze cauldron.
+
+- this would be the first freeze, when the big focus starts on bug fixes.  The sequence of freeze 
+types would not (necessarily) change.
+- although cauldron would be unfrozen, the idea is to allow small contributions, such as new 
+packages, new versions not accepted into pre-release, etc.
+But not to have major changes which could break cauldron, as the main contributors will be focused, 
+as now, on pre-release, and major breaks in cauldron should be quickly fixed.
+So that cauldron would not be not totally blocked to all non-release contributions during the 
+freeze period (which was about 6 weeks for mga1).
+- It would probably be very useful to have an explicit policy limiting the nature of contributions 
+to cauldron during the pre-release period.  We could even encourage the importing of new packages 
+during this period.
+- Caudron unfrozen would also allow less experienced packagers to contribute to cauldron at times 
+when they are unable to usefully contribute to pre-release.  For instance, such packagers could 
+depend heavily on the advice of others for bug fixes, but could be advanced enough to import new 
+packages or new versions to cauldron on their own.  (idea from comment on mageia1_postmortum wiki 
+page.)
+- This process assumes that the freeze period would be extended (by maybe 2 weeks) to give more 
+time to fix bugs, relieving some of the pressure.  Those less able to efficiently contribute to 
+pre-release could contribute to cauldron, so the extra time would be needed.
+- If this amended process allows us to more easily make the release, and thus keep the release 
+cycle of 6 months, we would have the advantage of keeping in sync with upstream for major projects 
+such as kde and gnome.  But if not enough for keeping the 6-month release cycle, if it helps, let's 
+use it if we go with a longer cycle.
+- In no way is the idea to produce parallel development streams as is now done by mozilla for firefox.
+
+Hopefully this summary helps.
+(BTW, it is still Wednesday in my time zone.)
+On the road to mga2 ... :)
+-- 
+André
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005951.html b/zarb-ml/mageia-dev/2011-June/005951.html new file mode 100644 index 000000000..7833dba94 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005951.html @@ -0,0 +1,106 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ andre999 + andr55 at laposte.net +
+ Thu Jun 23 05:10:01 CEST 2011 +

+
+ +
sorry, I forgot to strip off everything at the beginning
+... so if you could ignore the previous email
+
+andre999 a écrit :
+>
+> I'd like to consolidate and clarify my ideas regarding an amended freeze
+> process, taking into account the critiques.
+> That is, that for the freeze which leads to the release, that we
+> 1) freeze cauldron
+> 2) copy caudron to a pre-release branch, which remains frozen, and will
+> become the release
+> 3) then unfreeze cauldron.
+>
+> - this would be the first freeze, when the big focus starts on bug
+> fixes. The sequence of freeze types would not (necessarily) change.
+> - although cauldron would be unfrozen, the idea is to allow small
+> contributions, such as new packages, new versions not accepted into
+> pre-release, etc.
+> But not to have major changes which could break cauldron, as the main
+> contributors will be focused, as now, on pre-release, and major breaks
+> in cauldron should be quickly fixed.
+> So that cauldron would not be not totally blocked to all non-release
+> contributions during the freeze period (which was about 6 weeks for mga1).
+> - It would probably be very useful to have an explicit policy limiting
+> the nature of contributions to cauldron during the pre-release period.
+> We could even encourage the importing of new packages during this period.
+> - Caudron unfrozen would also allow less experienced packagers to
+> contribute to cauldron at times when they are unable to usefully
+> contribute to pre-release. For instance, such packagers could depend
+> heavily on the advice of others for bug fixes, but could be advanced
+> enough to import new packages or new versions to cauldron on their own.
+> (idea from comment on mageia1_postmortum wiki page.)
+> - This process assumes that the freeze period would be extended (by
+> maybe 2 weeks) to give more time to fix bugs, relieving some of the
+> pressure. Those less able to efficiently contribute to pre-release could
+> contribute to cauldron, so the extra time would be needed.
+> - If this amended process allows us to more easily make the release, and
+> thus keep the release cycle of 6 months, we would have the advantage of
+> keeping in sync with upstream for major projects such as kde and gnome.
+> But if not enough for keeping the 6-month release cycle, if it helps,
+> let's use it if we go with a longer cycle.
+> - In no way is the idea to produce parallel development streams as is
+> now done by mozilla for firefox.
+>
+> Hopefully this summary helps.
+> (BTW, it is still Wednesday in my time zone.)
+> On the road to mga2 ... :)
+
+
+-- 
+André
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005952.html b/zarb-ml/mageia-dev/2011-June/005952.html new file mode 100644 index 000000000..ae2b5d081 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005952.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] [RPM] cauldron core/release telepathy-glib-0.15.2-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release telepathy-glib-0.15.2-1.mga2

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Thu Jun 23 07:26:25 CEST 2011 +

+
+ +
On 23 June 2011 03:54, Zé <mmodem00 at gmail.com> wrote:
+>> I made an error here while updating telepathy-glib.
+>> Bolkm has been kind enough to remove this file from repository.
+>> the 0.14.8 should be soon available on mirrors so could you please
+>> replace the lib(64)telepathy-glib0-0.15.2-1.mga2 from your
+>> installation by the new package in case you did upgrade during the 4
+>> hours when this file was available on repository
+>
+> I think would be better to just add epoch, that way nothing would be
+> broke and no one would have to remove that version.
+
+No, this is Cauldron.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

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

[Mageia-dev] Firefox 5

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Thu Jun 23 07:29:50 CEST 2011 +

+
+ +
On 22 June 2011 19:41, Florian Hubold <doktor5000 at arcor.de> wrote:
+>> Well, it's quite possible that we have to include that in Mageia 1 as
+>> well, as this will be security update for Firefox 4. If we don't want to
+>> patch every CVE then we have to include it into Mageia 1 as well..
+>>
+>>
+> Would be nice to know, if this is planned?
+>
+> I have rebuild FF5 here locally for Mageia 1, and the only addons that i
+> lost is
+> Linkification, but that is merely due to it's developers who already messed
+> up
+> with FF4. They don't offer the proper update on Firefox Addons site.
+>
+> So, please, what about Firefox 5 for Mageia 1 as an update (backport?)
+
+Humm, MGA is stricter than MDV and refuses to backport packages
+directly from cauldron:
+
+mgarepo submit --define section=core/backports -t 1 </dev/null
+Submitting xulrunner at revision 110647
+URL: svn+ssh://svn.mageia.org/svn/packages/cauldron/xulrunner
+error: command failed: ssh pkgsubmit.mageia.org
+/usr/local/bin/submit_package -t 1 --define
+sid=4845bffd-7f94-4c8c-931e-cfb746d01a0d --define
+section=core/backports -r 110647
+svn+ssh://svn.mageia.org/svn/packages/cauldron/xulrunner
+error: svn+ssh://svn.mageia.org/svn/packages/cauldron/xulrunner is not
+allowed for this target
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005954.html b/zarb-ml/mageia-dev/2011-June/005954.html new file mode 100644 index 000000000..fd27ecd81 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005954.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Dexter Morgan + dmorganec at gmail.com +
+ Thu Jun 23 07:58:13 CEST 2011 +

+
+ +
On Thu, Jun 23, 2011 at 7:29 AM, Thierry Vignaud
+<thierry.vignaud at gmail.com> wrote:
+> On 22 June 2011 19:41, Florian Hubold <doktor5000 at arcor.de> wrote:
+>>> Well, it's quite possible that we have to include that in Mageia 1 as
+>>> well, as this will be security update for Firefox 4. If we don't want to
+>>> patch every CVE then we have to include it into Mageia 1 as well..
+>>>
+>>>
+>> Would be nice to know, if this is planned?
+>>
+>> I have rebuild FF5 here locally for Mageia 1, and the only addons that i
+>> lost is
+>> Linkification, but that is merely due to it's developers who already messed
+>> up
+>> with FF4. They don't offer the proper update on Firefox Addons site.
+>>
+>> So, please, what about Firefox 5 for Mageia 1 as an update (backport?)
+>
+> Humm, MGA is stricter than MDV and refuses to backport packages
+> directly from cauldron:
+>
+> mgarepo submit --define section=core/backports -t 1 </dev/null
+> Submitting xulrunner at revision 110647
+> URL: svn+ssh://svn.mageia.org/svn/packages/cauldron/xulrunner
+> error: command failed: ssh pkgsubmit.mageia.org
+> /usr/local/bin/submit_package -t 1 --define
+> sid=4845bffd-7f94-4c8c-931e-cfb746d01a0d --define
+> section=core/backports -r 110647
+> svn+ssh://svn.mageia.org/svn/packages/cauldron/xulrunner
+> error: svn+ssh://svn.mageia.org/svn/packages/cauldron/xulrunner is not
+> allowed for this target
+>
+
+yes it needs to go to backports_testing before iirc
+
+But i think sec team need to speak of FF5 first because i think this
+will be a candidate for updates regarding new firefox upstream policy
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005955.html b/zarb-ml/mageia-dev/2011-June/005955.html new file mode 100644 index 000000000..0c008de48 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005955.html @@ -0,0 +1,83 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Luc Menut + lmenut at free.fr +
+ Thu Jun 23 09:28:50 CEST 2011 +

+
+ +
Le 23/06/2011 07:58, Dexter Morgan a écrit :
+> On Thu, Jun 23, 2011 at 7:29 AM, Thierry Vignaud
+> <thierry.vignaud at gmail.com>  wrote:
+>> On 22 June 2011 19:41, Florian Hubold<doktor5000 at arcor.de>  wrote:
+>>>> Well, it's quite possible that we have to include that in Mageia 1 as
+>>>> well, as this will be security update for Firefox 4. If we don't want to
+>>>> patch every CVE then we have to include it into Mageia 1 as well..
+>>>>
+>>>>
+...
+>
+> But i think sec team need to speak of FF5 first because i think this
+> will be a candidate for updates regarding new firefox upstream policy
+>
+
+Yes, I think Firefox 5 should be an updates.
+Firefox 5 is a security update for Firefox 4 and 4.0.1. There will be no 
+Firefox 4.0.2.
+
+http://www.mozilla.org/security/known-vulnerabilities/  (Firefox 4 and 
+newer)
+http://www.mozilla.org/security/known-vulnerabilities/firefox.html
+http://blogzinet.free.fr/blog/index.php?post/2011/06/21/Mozilla-Firefox-5 
+(sorry, in french)
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005956.html b/zarb-ml/mageia-dev/2011-June/005956.html new file mode 100644 index 000000000..b0eed495e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005956.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] Distrib-coffee + + + + + + + + + +

[Mageia-dev] Distrib-coffee

+ Frank Griffin + ftg at roadrunner.com +
+ Thu Jun 23 11:35:46 CEST 2011 +

+
+ +
...has been offline for about 12 hours
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005957.html b/zarb-ml/mageia-dev/2011-June/005957.html new file mode 100644 index 000000000..15259674a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005957.html @@ -0,0 +1,83 @@ + + + + [Mageia-dev] Distrib-coffee + + + + + + + + + +

[Mageia-dev] Distrib-coffee

+ Frank Griffin + ftg at roadrunner.com +
+ Thu Jun 23 11:38:31 CEST 2011 +

+
+ +
On 06/23/2011 05:35 AM, Frank Griffin wrote:
+> ...has been offline for about 12 hours
+>
+and just came back.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005958.html b/zarb-ml/mageia-dev/2011-June/005958.html new file mode 100644 index 000000000..ec3f23210 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005958.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] ARM port preview for Mageia + + + + + + + + + +

[Mageia-dev] ARM port preview for Mageia

+ Anne nicolas + ennael at mageia.org +
+ Thu Jun 23 12:06:55 CEST 2011 +

+
+ +
Hi there
+
+As annouced previously, ARM port is now available as a preview. You can test
+installing it on proper hardware or use qemu.
+http://blog.mageia.org/en/2011/06/23/arm-port-preview
+
+We will speak a bit more about it soon about policies and integration in
+build system and all our process soon. If you are interested in it please
+just ping here :)
+
+Cheers
+
+-- 
+Anne
+http://www.mageia.org
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110623/7a83d3f8/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005959.html b/zarb-ml/mageia-dev/2011-June/005959.html new file mode 100644 index 000000000..c200b042c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005959.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] libproxy vs biarch & libexecdir + + + + + + + + + +

[Mageia-dev] libproxy vs biarch & libexecdir

+ Stew Benedict + stewbintn at gmail.com +
+ Thu Jun 23 12:44:42 CEST 2011 +

+
+ +
On 06/22/2011 09:54 PM, Michael Scherer wrote:
+> Le mercredi 22 juin 2011 à 23:54 +0800, Funda Wang a écrit :
+>> 2011/6/22 Christiaan Welvaart<cjw at daneel.dyndns.org>:
+>>> - the helper app (?) pxgsettings is put in libexecdir by upstream, so
+>>>   IMHO it should be in /usr/lib or /usr/libexec, not %{_libdir} which
+>>>   %{_libexecdir} expands to.
+>> %_libexecdir expands to %_libdir, for years since mandrake.
+> IIRC, /usr/libexec is not in FHS. While that would not cause a problem,
+> it also mean that some specific Fedora stuff, and so this may be
+> surprising to people.
+>
+Slated to go into FHS-3:
+
+http://bugs.linuxfoundation.org/show_bug.cgi?id=101
+
+-- 
+Stew Benedict
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005960.html b/zarb-ml/mageia-dev/2011-June/005960.html new file mode 100644 index 000000000..5171aaf56 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005960.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Florian Hubold + doktor5000 at arcor.de +
+ Thu Jun 23 19:15:37 CEST 2011 +

+
+ +
Am 23.06.2011 09:28, schrieb Luc Menut:
+> Le 23/06/2011 07:58, Dexter Morgan a écrit :
+>> On Thu, Jun 23, 2011 at 7:29 AM, Thierry Vignaud
+>> <thierry.vignaud at gmail.com>  wrote:
+>>> On 22 June 2011 19:41, Florian Hubold<doktor5000 at arcor.de>  wrote:
+>>>>> Well, it's quite possible that we have to include that in Mageia 1 as
+>>>>> well, as this will be security update for Firefox 4. If we don't want to
+>>>>> patch every CVE then we have to include it into Mageia 1 as well..
+>>>>>
+>>>>>
+> ...
+>>
+>> But i think sec team need to speak of FF5 first because i think this
+>> will be a candidate for updates regarding new firefox upstream policy
+>>
+>
+> Yes, I think Firefox 5 should be an updates.
+> Firefox 5 is a security update for Firefox 4 and 4.0.1. There will be no 
+> Firefox 4.0.2.
+And Firefox 6 will be released in the next two or three months, and will also be
+a security update to Firefox 5. So we definitely need a policy for that.
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005961.html b/zarb-ml/mageia-dev/2011-June/005961.html new file mode 100644 index 000000000..82981e3e0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005961.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] [RPM] cauldron core/release valgrind-3.6.1-3.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release valgrind-3.6.1-3.mga2

+ Florian Hubold + doktor5000 at arcor.de +
+ Thu Jun 23 19:17:59 CEST 2011 +

+
+ +
Am 22.06.2011 21:45, schrieb Ahmad Samir:
+> On 22 June 2011 20:18, nicolas vigier<boklm at mars-attacks.org>  wrote:
+>> On Wed, 22 Jun 2011, Florian Hubold wrote:
+>>
+>>> Am 22.06.2011 07:40, schrieb Ahmad Samir:
+>>>> On 20 June 2011 11:24, Thierry Vignaud<thierry.vignaud at gmail.com>    wrote:
+>>>>> On 7 June 2011 16:10, Mageia Team<buildsystem-daemon at mageia.org>    wrote:
+>>>>>> dmorgan<dmorgan>    3.6.1-3.mga1:
+>>>>>> + Revision: 101519
+>>>>>> - Provide devel subpackage  ( partial merge of mdv commit 659516)
+>>>>> As always, when one moves files between subpackages or to a new subpackage,
+>>>>> conflicts tags should be added in order to ensure urpmi will put both packages
+>>>>> in the same transaction:
+>>>>>
+>>>>> Installation failed:
+>>>>>      file /usr/include/valgrind/memcheck.h from install of
+>>>>> valgrind-devel-3.6.1-3.mga2.x86_64 conflicts with file from package
+>>>>> valgrind-3.6.0-2.mga1.x86_64
+>>>>>      file /usr/lib64/pkgconfig/valgrind.pc from install of
+>>>>> valgrind-devel-3.6.1-3.mga2.x86_64 conflicts with file from package
+>>>>> valgrind-3.6.0-2.mga1.x86_64
+>>>>>
+>>>> Done.
+>>>>
+>>> Minor nitpick: BuildRequires for xulrunner were changed after the split,
+>>> for firefox5 not.
+>>> Is there any special reason for this? Just wondering ...
+>> Because the devel files are now in valgrind-devel.
+Yes, i know about the split, you told me in IRC ;)
+>>
+> Yeah, there're two types of BR here, just 'valgrind' if the build
+> requires only the binary (/usr/bin/valgrind) and valgrind-devel if the
+> build requires the valgrind header files; AFAICS for firefox, it
+> doesn't require the valgrind headers (i.e. I don't see any checks for
+> the headers failing in the build log).
+>
+Alright, just wanted to mention it. Could also have been an oversight ...
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005962.html b/zarb-ml/mageia-dev/2011-June/005962.html new file mode 100644 index 000000000..61c554cbe --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005962.html @@ -0,0 +1,125 @@ + + + + [Mageia-dev] [RPM] cauldron core/release valgrind-3.6.1-3.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release valgrind-3.6.1-3.mga2

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Thu Jun 23 21:06:05 CEST 2011 +

+
+ +
On 23 June 2011 19:17, Florian Hubold <doktor5000 at arcor.de> wrote:
+> Am 22.06.2011 21:45, schrieb Ahmad Samir:
+>>
+>> On 22 June 2011 20:18, nicolas vigier<boklm at mars-attacks.org>  wrote:
+>>>
+>>> On Wed, 22 Jun 2011, Florian Hubold wrote:
+>>>
+>>>> Am 22.06.2011 07:40, schrieb Ahmad Samir:
+>>>>>
+>>>>> On 20 June 2011 11:24, Thierry Vignaud<thierry.vignaud at gmail.com>
+>>>>>  wrote:
+>>>>>>
+>>>>>> On 7 June 2011 16:10, Mageia Team<buildsystem-daemon at mageia.org>
+>>>>>>  wrote:
+>>>>>>>
+>>>>>>> dmorgan<dmorgan>    3.6.1-3.mga1:
+>>>>>>> + Revision: 101519
+>>>>>>> - Provide devel subpackage  ( partial merge of mdv commit 659516)
+>>>>>>
+>>>>>> As always, when one moves files between subpackages or to a new
+>>>>>> subpackage,
+>>>>>> conflicts tags should be added in order to ensure urpmi will put both
+>>>>>> packages
+>>>>>> in the same transaction:
+>>>>>>
+>>>>>> Installation failed:
+>>>>>>     file /usr/include/valgrind/memcheck.h from install of
+>>>>>> valgrind-devel-3.6.1-3.mga2.x86_64 conflicts with file from package
+>>>>>> valgrind-3.6.0-2.mga1.x86_64
+>>>>>>     file /usr/lib64/pkgconfig/valgrind.pc from install of
+>>>>>> valgrind-devel-3.6.1-3.mga2.x86_64 conflicts with file from package
+>>>>>> valgrind-3.6.0-2.mga1.x86_64
+>>>>>>
+>>>>> Done.
+>>>>>
+>>>> Minor nitpick: BuildRequires for xulrunner were changed after the split,
+>>>> for firefox5 not.
+>>>> Is there any special reason for this? Just wondering ...
+>>>
+>>> Because the devel files are now in valgrind-devel.
+>
+> Yes, i know about the split, you told me in IRC ;)
+>>>
+>> Yeah, there're two types of BR here, just 'valgrind' if the build
+>> requires only the binary (/usr/bin/valgrind) and valgrind-devel if the
+>> build requires the valgrind header files; AFAICS for firefox, it
+>> doesn't require the valgrind headers (i.e. I don't see any checks for
+>> the headers failing in the build log).
+>>
+> Alright, just wanted to mention it. Could also have been an oversight ...
+>
+
+Yep, no problem :)
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005963.html b/zarb-ml/mageia-dev/2011-June/005963.html new file mode 100644 index 000000000..c4d83ca45 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005963.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Thu Jun 23 21:52:30 CEST 2011 +

+
+ +
On 23 June 2011 07:58, Dexter Morgan <dmorganec at gmail.com> wrote:
+> On Thu, Jun 23, 2011 at 7:29 AM, Thierry Vignaud
+> <thierry.vignaud at gmail.com> wrote:
+>> On 22 June 2011 19:41, Florian Hubold <doktor5000 at arcor.de> wrote:
+>>>> Well, it's quite possible that we have to include that in Mageia 1 as
+>>>> well, as this will be security update for Firefox 4. If we don't want to
+>>>> patch every CVE then we have to include it into Mageia 1 as well..
+>>>>
+>>>>
+>>> Would be nice to know, if this is planned?
+>>>
+>>> I have rebuild FF5 here locally for Mageia 1, and the only addons that i
+>>> lost is
+>>> Linkification, but that is merely due to it's developers who already messed
+>>> up
+>>> with FF4. They don't offer the proper update on Firefox Addons site.
+>>>
+>>> So, please, what about Firefox 5 for Mageia 1 as an update (backport?)
+>>
+>> Humm, MGA is stricter than MDV and refuses to backport packages
+>> directly from cauldron:
+>>
+>> mgarepo submit --define section=core/backports -t 1 </dev/null
+>> Submitting xulrunner at revision 110647
+>> URL: svn+ssh://svn.mageia.org/svn/packages/cauldron/xulrunner
+>> error: command failed: ssh pkgsubmit.mageia.org
+>> /usr/local/bin/submit_package -t 1 --define
+>> sid=4845bffd-7f94-4c8c-931e-cfb746d01a0d --define
+>> section=core/backports -r 110647
+>> svn+ssh://svn.mageia.org/svn/packages/cauldron/xulrunner
+>> error: svn+ssh://svn.mageia.org/svn/packages/cauldron/xulrunner is not
+>> allowed for this target
+>>
+>
+> yes it needs to go to backports_testing before iirc
+>
+
+Got a link to a thread on -dev ML / irc meeting log / <insert your
+favourite communication method here>, where this was decided?
+
+> But i think sec team need to speak of FF5 first because i think this
+> will be a candidate for updates regarding new firefox upstream policy
+>
+
+
+
+-- 
+Ahmad Samir
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005964.html b/zarb-ml/mageia-dev/2011-June/005964.html new file mode 100644 index 000000000..2a262ccef --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005964.html @@ -0,0 +1,115 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Dexter Morgan + dmorganec at gmail.com +
+ Thu Jun 23 22:12:46 CEST 2011 +

+
+ +
On Thu, Jun 23, 2011 at 9:52 PM, Ahmad Samir <ahmadsamir3891 at gmail.com> wrote:
+> On 23 June 2011 07:58, Dexter Morgan <dmorganec at gmail.com> wrote:
+>> On Thu, Jun 23, 2011 at 7:29 AM, Thierry Vignaud
+>> <thierry.vignaud at gmail.com> wrote:
+>>> On 22 June 2011 19:41, Florian Hubold <doktor5000 at arcor.de> wrote:
+>>>>> Well, it's quite possible that we have to include that in Mageia 1 as
+>>>>> well, as this will be security update for Firefox 4. If we don't want to
+>>>>> patch every CVE then we have to include it into Mageia 1 as well..
+>>>>>
+>>>>>
+>>>> Would be nice to know, if this is planned?
+>>>>
+>>>> I have rebuild FF5 here locally for Mageia 1, and the only addons that i
+>>>> lost is
+>>>> Linkification, but that is merely due to it's developers who already messed
+>>>> up
+>>>> with FF4. They don't offer the proper update on Firefox Addons site.
+>>>>
+>>>> So, please, what about Firefox 5 for Mageia 1 as an update (backport?)
+>>>
+>>> Humm, MGA is stricter than MDV and refuses to backport packages
+>>> directly from cauldron:
+>>>
+>>> mgarepo submit --define section=core/backports -t 1 </dev/null
+>>> Submitting xulrunner at revision 110647
+>>> URL: svn+ssh://svn.mageia.org/svn/packages/cauldron/xulrunner
+>>> error: command failed: ssh pkgsubmit.mageia.org
+>>> /usr/local/bin/submit_package -t 1 --define
+>>> sid=4845bffd-7f94-4c8c-931e-cfb746d01a0d --define
+>>> section=core/backports -r 110647
+>>> svn+ssh://svn.mageia.org/svn/packages/cauldron/xulrunner
+>>> error: svn+ssh://svn.mageia.org/svn/packages/cauldron/xulrunner is not
+>>> allowed for this target
+>>>
+>>
+>> yes it needs to go to backports_testing before iirc
+>>
+>
+> Got a link to a thread on -dev ML / irc meeting log / <insert your
+> favourite communication method here>, where this was decided?
+>
+
+i told iirc so this is something i recall not something i tell it must be done.
+
+i think the most important part of my sentence is the last part but
+maybe you didn't read it ...
+
+>> But i think sec team need to speak of FF5 first because i think this
+>> will be a candidate for updates regarding new firefox upstream policy
+>>
+>
+>
+>
+> --
+> Ahmad Samir
+>
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005965.html b/zarb-ml/mageia-dev/2011-June/005965.html new file mode 100644 index 000000000..dfb9d9211 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005965.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Thu Jun 23 22:44:51 CEST 2011 +

+
+ +
On 23 June 2011 22:12, Dexter Morgan <dmorganec at gmail.com> wrote:
+> On Thu, Jun 23, 2011 at 9:52 PM, Ahmad Samir <ahmadsamir3891 at gmail.com> wrote:
+>>>
+>>> yes it needs to go to backports_testing before iirc
+>>>
+>>
+>> Got a link to a thread on -dev ML / irc meeting log / <insert your
+>> favourite communication method here>, where this was decided?
+>>
+>
+> i told iirc so this is something i recall not something i tell it must be done.
+>
+> i think the most important part of my sentence is the last part but
+> maybe you didn't read it ...
+>
+
+I did read it, however my question wasn't only about firefox, but
+rather about the backports policy in general, since your "yes it needs
+to go to backports_testing before iirc" wasn't about firefox only, was
+it? :)
+
+>>> But i think sec team need to speak of FF5 first because i think this
+>>> will be a candidate for updates regarding new firefox upstream policy
+>>>
+>>
+>>
+>>
+>> --
+>> Ahmad Samir
+>>
+>
+
+
+
+-- 
+Ahmad Samir
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005966.html b/zarb-ml/mageia-dev/2011-June/005966.html new file mode 100644 index 000000000..9e90932c6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005966.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] Update of mesa to git version + + + + + + + + + +

[Mageia-dev] Update of mesa to git version

+ Balcaen John + mikala at mageia.org +
+ Thu Jun 23 23:33:33 CEST 2011 +

+
+ +
Le mercredi 22 juin 2011 15:16:23, Thierry Vignaud a écrit :
+[...]
+> We would need to test GLUT a little bit
+> 
+> As for gallium, I'm regularly testing r300 from git but I'ven't tested
+> neither r600 nor nouveau (though my experience with nouveau on FC
+> is that it regress quite a lot and is heavily dependant on the
+> kernel/libdrm/mesa triplet).
+> 
+> r300g is alreay the default in incoming mesa-7.11 (I think
+> this was already the case on 7.10).
+> r600g will be the default in 7.12
+> No bugs are accepted on r300c anymore (don't remember for r600c)
+> As for nouveau, well we've no alternatives.
+> As for swrast, the LLVM gallium driver is said to be faster but
+> I'ven't tested it.
+> 
+> > Beware of the fact that freeglut is not a buildrequire nor a require for
+> > some rpms (their spec file need to be modified
+> > and they need to be rebuilt with freeglut instead of mesaglut)
+> 
+> Indeed
+Should i push it to cauldron/updates_testing then ?
+& start rebuilding all packages against freeglut in core/release?
+
+
+-- 
+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-June/005967.html b/zarb-ml/mageia-dev/2011-June/005967.html new file mode 100644 index 000000000..3ecda1a7a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005967.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] Update of mesa to git version + + + + + + + + + +

[Mageia-dev] Update of mesa to git version

+ Dexter Morgan + dmorganec at gmail.com +
+ Thu Jun 23 23:38:24 CEST 2011 +

+
+ +
On Thu, Jun 23, 2011 at 11:33 PM, Balcaen John <mikala at mageia.org> wrote:
+> Le mercredi 22 juin 2011 15:16:23, Thierry Vignaud a écrit :
+> [...]
+>> We would need to test GLUT a little bit
+>>
+>> As for gallium, I'm regularly testing r300 from git but I'ven't tested
+>> neither r600 nor nouveau (though my experience with nouveau on FC
+>> is that it regress quite a lot and is heavily dependant on the
+>> kernel/libdrm/mesa triplet).
+>>
+>> r300g is alreay the default in incoming mesa-7.11 (I think
+>> this was already the case on 7.10).
+>> r600g will be the default in 7.12
+>> No bugs are accepted on r300c anymore (don't remember for r600c)
+>> As for nouveau, well we've no alternatives.
+>> As for swrast, the LLVM gallium driver is said to be faster but
+>> I'ven't tested it.
+>>
+>> > Beware of the fact that freeglut is not a buildrequire nor a require for
+>> > some rpms (their spec file need to be modified
+>> > and they need to be rebuilt with freeglut instead of mesaglut)
+>>
+>> Indeed
+> Should i push it to cauldron/updates_testing then ?
+> & start rebuilding all packages against freeglut in core/release?
+
+i think we should put it directly in core/release and upload freeglut
+at the same time
+
+wdyt ?
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005968.html b/zarb-ml/mageia-dev/2011-June/005968.html new file mode 100644 index 000000000..3a46bdf1d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005968.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ David W. Hodgins + davidwhodgins at gmail.com +
+ Thu Jun 23 23:48:50 CEST 2011 +

+
+ +
On Thu, 23 Jun 2011 15:52:30 -0400, Ahmad Samir <ahmadsamir3891 at gmail.com> wrote:
+
+> On 23 June 2011 07:58, Dexter Morgan <dmorganec at gmail.com> wrote:
+
+>> yes it needs to go to backports_testing before iirc
+
+> Got a link to a thread on -dev ML / irc meeting log / <insert your
+> favourite communication method here>, where this was decided?
+
+This mailing list, thread "Release cycles proposals, and discussion",
+messageid BANLkTimrPR-=UgQOnfvAkqPft80LNi9seQ at mail.gmail.com
+
+Where Anne posted ...
+
+> exactly what I had in mind. Having backports can allow choice between
+> "the last version of" and "the stable version with which I'm happy
+> with". But indeed we need more quality in backport rpms that is policy
+> and tests.
+
+In order for the qa team to perform the tests, before they go to the
+backports repository, they have to go to to the testing repository
+first.
+
+Something that works in cauldron may not work when moved to backports,
+if a dependency is missed.  By using backports_testing, we can catch
+that before it hits the average user.
+
+Regards, Dave Hodgins
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005969.html b/zarb-ml/mageia-dev/2011-June/005969.html new file mode 100644 index 000000000..6ddcb56ab --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005969.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Michael Scherer + misc at zarb.org +
+ Fri Jun 24 00:06:17 CEST 2011 +

+
+ +
Le jeudi 23 juin 2011 à 17:48 -0400, David W. Hodgins a écrit :
+> On Thu, 23 Jun 2011 15:52:30 -0400, Ahmad Samir <ahmadsamir3891 at gmail.com> wrote:
+> 
+> > On 23 June 2011 07:58, Dexter Morgan <dmorganec at gmail.com> wrote:
+> 
+> >> yes it needs to go to backports_testing before iirc
+> 
+> > Got a link to a thread on -dev ML / irc meeting log / <insert your
+> > favourite communication method here>, where this was decided?
+> 
+> This mailing list, thread "Release cycles proposals, and discussion",
+> messageid BANLkTimrPR-=UgQOnfvAkqPft80LNi9seQ at mail.gmail.com
+> 
+> Where Anne posted ...
+> 
+> > exactly what I had in mind. Having backports can allow choice between
+> > "the last version of" and "the stable version with which I'm happy
+> > with". But indeed we need more quality in backport rpms that is policy
+> > and tests.
+> 
+> In order for the qa team to perform the tests, before they go to the
+> backports repository, they have to go to to the testing repository
+> first.
+> 
+> Something that works in cauldron may not work when moved to backports,
+> if a dependency is missed.  By using backports_testing, we can catch
+> that before it hits the average user.
+
+I think the question of ahmad was about "backport vs updates".
+And I think firefox is suitable for the list of package exceptions that
+should be backported rather than using a patch ( see
+http://mageia.org/wiki/doku.php?id=updates_policy ).
+
+And so, since I guess everybody assume that ff and chromium can go in
+the list, as they are unsupported upstream _and_ too complex to fix with
+a patch. 
+
+And to answer to am
+-- 
+Michael Scherer
+
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005970.html b/zarb-ml/mageia-dev/2011-June/005970.html new file mode 100644 index 000000000..e8f6e3d2a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005970.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ genomega + genomega at earthlink.net +
+ Thu Jun 23 23:51:14 CEST 2011 +

+
+ +
+
+
+-----Original Message-----
+>From: Ahmad Samir <ahmadsamir3891 at gmail.com>
+>Sent: Jun 23, 2011 3:44 PM
+>To: Mageia development mailing-list <mageia-dev at mageia.org>
+>Subject: Re: [Mageia-dev] Firefox 5
+>
+>On 23 June 2011 22:12, Dexter Morgan <dmorganec at gmail.com> wrote:
+>> On Thu, Jun 23, 2011 at 9:52 PM, Ahmad Samir <ahmadsamir3891 at gmail.com> wrote:
+>>>>
+>>>> yes it needs to go to backports_testing before iirc
+>>>>
+>>>
+>>> Got a link to a thread on -dev ML / irc meeting log / <insert your
+>>> favourite communication method here>, where this was decided?
+>>>
+>>
+>> i told iirc so this is something i recall not something i tell it must be done.
+>>
+>> i think the most important part of my sentence is the last part but
+>> maybe you didn't read it ...
+>>
+>
+>I did read it, however my question wasn't only about firefox, but
+>rather about the backports policy in general, since your "yes it needs
+>to go to backports_testing before iirc" wasn't about firefox only, was
+>it? :)
+>
+>>>> But i think sec team need to speak of FF5 first because i think this
+>>>> will be a candidate for updates regarding new firefox upstream policy
+>>>>
+>>>
+>>>
+>>>
+>>> --
+>>> Ahmad Samir
+>From what I have been reading due to Mozilla's rapid release schedule it appears that some distros are moving to a standalone version of Firefox. A standalone version means that Firefox does not require a separate libxulrunner package.
+
+
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005971.html b/zarb-ml/mageia-dev/2011-June/005971.html new file mode 100644 index 000000000..aaf90954b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005971.html @@ -0,0 +1,134 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Fri Jun 24 00:17:57 CEST 2011 +

+
+ +
On 23 June 2011 23:48, David W. Hodgins <davidwhodgins at gmail.com> wrote:
+> On Thu, 23 Jun 2011 15:52:30 -0400, Ahmad Samir <ahmadsamir3891 at gmail.com>
+> wrote:
+>
+>> On 23 June 2011 07:58, Dexter Morgan <dmorganec at gmail.com> wrote:
+>
+>>> yes it needs to go to backports_testing before iirc
+>
+>> Got a link to a thread on -dev ML / irc meeting log / <insert your
+>> favourite communication method here>, where this was decided?
+>
+> This mailing list, thread "Release cycles proposals, and discussion",
+> messageid BANLkTimrPR-=UgQOnfvAkqPft80LNi9seQ at mail.gmail.com
+>
+> Where Anne posted ...
+>
+>> exactly what I had in mind. Having backports can allow choice between
+>> "the last version of" and "the stable version with which I'm happy
+>> with". But indeed we need more quality in backport rpms that is policy
+>> and tests.
+>
+> In order for the qa team to perform the tests, before they go to the
+> backports repository, they have to go to to the testing repository
+> first.
+>
+
+1) It doesn't say "we're going to use backports_testing", does it?
+guessing != an instated policy
+2) IMHO, QA is too small to handle backports too
+
+> Something that works in cauldron may not work when moved to backports,
+> if a dependency is missed.  By using backports_testing, we can catch
+> that before it hits the average user.
+>
+> Regards, Dave Hodgins
+>
+
+Right so, the plan is:
+- A packager submits to backports_testing and assigns to QA
+- QA tests, the package is good to go
+- The report is assigned to <whoever has privileges to move packages
+from backports_testing to backports>, atm that's sysadm team
+- Package is moved and the report closed
+
+Caveats:
+- QA is too small, and it'll take time/effort to get through the
+backported packages requiring tests, unless you depend on the user
+asking for the backport to have tested the package properly, the user
+will say it works if it works on his box for the arch he's using, he
+won't do both archs, not just because he's lazy, but maybe he has one
+Mageia box for example
+- Sysadm team is already overworked with many other tasks, meaning the
+packages requiring a move will rot for a while in backports_testing.
+
+Now compare that to what's used in e.g. mdv:
+- User asks for a backport
+- Packager submits the backport and closes the report
+
+Do you see the problem I am talking about yet? adding more complexity
+to backporting may result in less backports; the more the hoops, the
+less the backports, the more the users' complaints about
+I-want-the-latest-version-of-foo-yesterday.
+
+The "quality of backports" is a sentence that lacks statistics and
+numbers; in e.g. mdv, how many packages were backported to release
+foo? how many of them worked(tm)? how many of them didn't work and
+required a bit of fixing? how many of them didn't work and won't work
+due to any number of reasons?
+
+I think backports in mdv worked pretty well all those years, not all
+of them worked, but most of them did.
+
+-- 
+Ahmad Samir
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005972.html b/zarb-ml/mageia-dev/2011-June/005972.html new file mode 100644 index 000000000..7cd9d5474 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005972.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Fri Jun 24 00:18:55 CEST 2011 +

+
+ +
On 24 June 2011 00:06, Michael Scherer <misc at zarb.org> wrote:
+> Le jeudi 23 juin 2011 à 17:48 -0400, David W. Hodgins a écrit :
+>> On Thu, 23 Jun 2011 15:52:30 -0400, Ahmad Samir <ahmadsamir3891 at gmail.com> wrote:
+>>
+>> > On 23 June 2011 07:58, Dexter Morgan <dmorganec at gmail.com> wrote:
+>>
+>> >> yes it needs to go to backports_testing before iirc
+>>
+>> > Got a link to a thread on -dev ML / irc meeting log / <insert your
+>> > favourite communication method here>, where this was decided?
+>>
+>> This mailing list, thread "Release cycles proposals, and discussion",
+>> messageid BANLkTimrPR-=UgQOnfvAkqPft80LNi9seQ at mail.gmail.com
+>>
+>> Where Anne posted ...
+>>
+>> > exactly what I had in mind. Having backports can allow choice between
+>> > "the last version of" and "the stable version with which I'm happy
+>> > with". But indeed we need more quality in backport rpms that is policy
+>> > and tests.
+>>
+>> In order for the qa team to perform the tests, before they go to the
+>> backports repository, they have to go to to the testing repository
+>> first.
+>>
+>> Something that works in cauldron may not work when moved to backports,
+>> if a dependency is missed.  By using backports_testing, we can catch
+>> that before it hits the average user.
+>
+> I think the question of ahmad was about "backport vs updates".
+> And I think firefox is suitable for the list of package exceptions that
+> should be backported rather than using a patch ( see
+> http://mageia.org/wiki/doku.php?id=updates_policy ).
+>
+> And so, since I guess everybody assume that ff and chromium can go in
+> the list, as they are unsupported upstream _and_ too complex to fix with
+> a patch.
+>
+> And to answer to am
+> --
+> Michael Scherer
+>
+>
+
+Actually no, I meant the submit to backports privileges vs. only being
+able to submit to backports_testing.
+
+-- 
+Ahmad Samir
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005973.html b/zarb-ml/mageia-dev/2011-June/005973.html new file mode 100644 index 000000000..629ad6424 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005973.html @@ -0,0 +1,66 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ nicolas vigier + boklm at mars-attacks.org +
+ Fri Jun 24 00:22:37 CEST 2011 +

+
+ +
On Fri, 24 Jun 2011, Ahmad Samir wrote:
+
+> - The report is assigned to <whoever has privileges to move packages
+> from backports_testing to backports>, atm that's sysadm team
+
+And soon qa team should be able to do it.
+
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005974.html b/zarb-ml/mageia-dev/2011-June/005974.html new file mode 100644 index 000000000..b38fdd327 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005974.html @@ -0,0 +1,77 @@ + + + + [Mageia-dev] Blowfish bug + + + + + + + + + +

[Mageia-dev] Blowfish bug

+ David W. Hodgins + davidwhodgins at gmail.com +
+ Fri Jun 24 01:23:43 CEST 2011 +

+
+ +
+For anyone who missed
+http://it.slashdot.org/story/11/06/20/2257229/13-Year-Old-Password-Security-Bug-Fixed?utm_source=rss1.0&utm_medium=feed
+
+There is a bug in many implementations of blowfish for hashing
+8 bit characters (for example, in passwords), due to the usage
+of char instead of unsigned char.
+
+It's going to take a while to identify all of the places where
+blowfish has been used with the incorrect code, and fixed.
+
+Regards, Dave Hodgins
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005975.html b/zarb-ml/mageia-dev/2011-June/005975.html new file mode 100644 index 000000000..dccf06fdb --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005975.html @@ -0,0 +1,157 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Michael Scherer + misc at zarb.org +
+ Fri Jun 24 02:04:46 CEST 2011 +

+
+ +
Le vendredi 24 juin 2011 à 01:17 +0300, Ahmad Samir a écrit :
+> On 23 June 2011 23:48, David W. Hodgins <davidwhodgins at gmail.com> wrote:
+> > On Thu, 23 Jun 2011 15:52:30 -0400, Ahmad Samir <ahmadsamir3891 at gmail.com>
+> > wrote:
+> >
+> >> On 23 June 2011 07:58, Dexter Morgan <dmorganec at gmail.com> wrote:
+> >
+> >>> yes it needs to go to backports_testing before iirc
+> >
+> >> Got a link to a thread on -dev ML / irc meeting log / <insert your
+> >> favourite communication method here>, where this was decided?
+> >
+> > This mailing list, thread "Release cycles proposals, and discussion",
+> > messageid BANLkTimrPR-=UgQOnfvAkqPft80LNi9seQ at mail.gmail.com
+> >
+> > Where Anne posted ...
+> >
+> >> exactly what I had in mind. Having backports can allow choice between
+> >> "the last version of" and "the stable version with which I'm happy
+> >> with". But indeed we need more quality in backport rpms that is policy
+> >> and tests.
+> >
+> > In order for the qa team to perform the tests, before they go to the
+> > backports repository, they have to go to to the testing repository
+> > first.
+> >
+> 
+> 1) It doesn't say "we're going to use backports_testing", does it?
+> guessing != an instated policy
+> 2) IMHO, QA is too small to handle backports too
+> 
+> > Something that works in cauldron may not work when moved to backports,
+> > if a dependency is missed.  By using backports_testing, we can catch
+> > that before it hits the average user.
+> >
+> > Regards, Dave Hodgins
+> >
+> 
+> Right so, the plan is:
+> - A packager submits to backports_testing and assigns to QA
+> - QA tests, the package is good to go
+> - The report is assigned to <whoever has privileges to move packages
+> from backports_testing to backports>, atm that's sysadm team
+> - Package is moved and the report closed
+> 
+> Caveats:
+> - QA is too small, and it'll take time/effort to get through the
+> backported packages requiring tests, unless you depend on the user
+> asking for the backport to have tested the package properly, the user
+> will say it works if it works on his box for the arch he's using, he
+> won't do both archs, not just because he's lazy, but maybe he has one
+> Mageia box for example
+> - Sysadm team is already overworked with many other tasks, meaning the
+> packages requiring a move will rot for a while in backports_testing.
+> 
+> Now compare that to what's used in e.g. mdv:
+> - User asks for a backport
+> - Packager submits the backport and closes the report
+> 
+> Do you see the problem I am talking about yet? adding more complexity
+> to backporting may result in less backports; the more the hoops, the
+> less the backports, the more the users' complaints about
+> I-want-the-latest-version-of-foo-yesterday.
+
+Then we should have a way to turn complaint into productive behavior,
+like "asking to people to do QA of package they request the backport
+for".
+
+> The "quality of backports" is a sentence that lacks statistics and
+> numbers; in e.g. mdv, how many packages were backported to release
+> foo? how many of them worked(tm)? how many of them didn't work and
+> required a bit of fixing? how many of them didn't work and won't work
+> due to any number of reasons?
+> 
+> I think backports in mdv worked pretty well all those years, not all
+> of them worked, but most of them did.
+
+And everybody said "do not use backport, they are not supported, and
+they can eat your cat if you use them".
+
+As said in the meeting, I wanted to send a proposal later for that, but
+you shooted first, so let's start.
+
+Your points are valid, and I took them in account in the proposal, who
+is based on previous years feedback, based on Stormi ideas mainly, and
+on your points. 
+
+So I will open 3 separate thread, to answer to the 3 questions I see :
+- what process for backports
+- what policy for backports
+- what about updates of backports
+
+Using 3 mails, I hope to have a more manageable discussion that having a
+big one.
+
+-- 
+Michael Scherer
+
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005976.html b/zarb-ml/mageia-dev/2011-June/005976.html new file mode 100644 index 000000000..932e3c0c3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005976.html @@ -0,0 +1,126 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Michael Scherer + misc at zarb.org +
+ Fri Jun 24 02:09:55 CEST 2011 +

+
+ +
Hi,
+
+as said in the thread of firefox 5, and in the meeting of packager
+sooner this week, this is the first mail about backports ( on 3 ).
+
+So here is the proposal of a process, based on the feedback of people,
+and the idea of some packagers ( mainly stormi ).
+
+
+- Someone request a backport ( by bugzilla, by madb, by a email, by
+taking a packager family in hostage, whatever ). I would prefer use
+bugzilla but this may not be very user friendly, or too heavy.
+
+- a packager decide to do it. Based on the policy ( outlined in another
+mail ), and maybe seeing with the maintainer first about that for non
+trivial applications, the backport can be done, or not. The criterias
+for being backported or not are not important to the process, just
+assume that they exist for now ( and look at next mail ). So based on
+criteria, someone say "it can be backported, so I do it".
+
+- I am not sure on this part, but basically, we have 2 choices :
+  - the packager take the cauldron package and push to backport testing
+  - the packager move the cauldron package in svn to backport, and there
+send it to backport testing. 
+
+Proposal 1 mean less work duplication, but proposal 2 let us do more
+customization.
+
+if the package doesn't build, the packager fix ( or drop the idea if
+this requires too much work )
+
+- the packager send requesting feedback about the backport from the
+people who requested it, and test it as well.
+ 
+- based on feedback ( ie if the package work or if the packager is
+confident ), the packager decide to move it to backport for everybody,
+using some stuff similar to rpmctl ( the tool we used to move package at
+Mandriva ). The tool would also send notifications.
+
+- if the package doesn't work, he either fix, or drop the backport idea.
+If he fix, we go back on testing, if he drop, we remove the rpm ( with a
+automated cleaning of rpm after 1 or 2 months ).
+
+If the packager drop the backport, it should be notified to the
+requester ( hence the use of bugzilla, or a more suitable tool )
+
+This way :
+- packages are not sent untested, thus raising confidence in backports
+- the QA should not be overloaded, and can focus on updates
+- sysadmins are not overloaded 
+- people requesting backport see how QA work, and are involved into the
+distribution as testers, thus creating a much healthier discussion with
+packagers, and creating more incentive to help. And since they request
+the package, they will be motivated to test more than stuff they do not
+use.
+
+WDYT ?
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005977.html b/zarb-ml/mageia-dev/2011-June/005977.html new file mode 100644 index 000000000..9b10f96ef --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005977.html @@ -0,0 +1,190 @@ + + + + [Mageia-dev] Backports policy proposal + + + + + + + + + +

[Mageia-dev] Backports policy proposal

+ Michael Scherer + misc at zarb.org +
+ Fri Jun 24 02:10:14 CEST 2011 +

+
+ +
Hi,
+
+as said, this is the 2nd mail of the 3 mails about handling backports.
+It is about backport policy, ie what we update, and what we don't, with
+a set of criteria, to make sure we fullfill our goals.
+
+I will start by the fact we can all agree that we want to have a
+breakage-free experience. One of the value of the project is the
+quality, and traditionally, the best way to not break something is to
+have minimal changes.
+Yet, people have asked for newer version of packages, and people are ok
+to trade a little bit of change and little bit of risk for new software,
+and we have offered that in the past at Mandriva with some success.
+
+Experience have showed that people care mostly about applications rather
+than low level library and modules. Experience have also show that
+people are not sure about backport, and that we should make sure
+everything work fine so we can have more people that use them.
+
+The Mandriva policy was rather good, and I think we can also all agree
+there is packages that can clearly not be backportable without either
+lots of QA, or without rebuilding lots of stuff :
+- glibc, python, perl, xorg, etc
+
+I would also say that the maintainer can also say that he doesn't want
+the rpm be backported, either because he think that's not ready, or
+because he think it should not be done. I think this will not happen
+often, but for the rare case a problem would arise, the maintainer
+should have the last word.
+
+On the other hand, there is packages that can be backported without
+impacting much :
+- leaf packages ( those that nothing requires ), 
+- packages not present in the distribution ( provided it doesn't
+obsolete or provides stuff that would impact the distribution, like
+backporting a new jvm with a obsolete on the current one ).
+
+So for a start, I would suggest to use the same policy as Mandriva
+( http://wiki.mandriva.com/en/Policies/SoftwareMedia#Backports_policy ).
+
+Ie, only create a backport for rpm  that cannot have a negative impact
+( leaf packages, newer one ), and then revise the policy in one year
+based on request that were refused, to see if we can find something to
+change.
+
+
+I would also propose a few rules :
+
+"a package should have been in cauldron since 1 week before being
+backported", so we can at least ensure there was a minimal test on it,
+Ie, if I package stuff-virtual-manager, I cannot backport it before 1
+week. If we have a package of stuff-virtual-manager since 1 month, and
+that I update a new version, then I can backport. The idea is that a
+newer packages may suffer from more bug than older one.
+
+
+Another rule that we could add is that cauldron should always be newer
+than backports, in order to ensure upgradability. The same goes for n-2
+and n-1 release.
+While this seems innocent, do not forget this will have a impact when we
+do the version freeze.
+
+
+Something that was discussed previously, we should make sure that
+backport can be cherrypicked. If I backport trac, I will need to place
+stricted Requires from subpackages on the main package and so on, in
+order to ensure no mix of rpm. And since we plan to backport only leaf
+packages, this would not affect others packages. However, this will have
+a impact on the next issue, updates.
+
+so :
+- cannot be backported if this is not a leaf package, will be revised
+later
+- cannot be backported if the maintainer say "no", but we assume he say
+"yes" by default
+- cannot be backported if it impact the dependency tree too much
+( Obsoletes, Provides, etc )
+- cannot be backported if the package was just created and is thus
+basically untested in cauldron
+
+- must not prevent upgrade to next release 
+
+- strict requires between backported packages, in order to make sure
+they can be cherrypicked ( ie, someone enable backports, install, remove
+backports )
+
+You can comment ( do not forget to trim the answer , and please keep
+this on topic, that's why I did 3 mails ).
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005978.html b/zarb-ml/mageia-dev/2011-June/005978.html new file mode 100644 index 000000000..9a2e79d93 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005978.html @@ -0,0 +1,195 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ Michael Scherer + misc at zarb.org +
+ Fri Jun 24 02:15:03 CEST 2011 +

+
+ +
Hi,
+
+The last mail from the backport trilogy. And like all good trilogy,
+that's where the suspens is present ( as for the 1 and 2 part, you know
+there is another episode )
+
+This mail is about handling update on the backport repository. Either
+new version, or bugfix, or security upgrade. 
+
+Everybody was focused on "should we do patch, or should we do more
+backport" issue, but the real problem is not really here.
+
+First, we have to decide what kind of update do we want to see, among
+the 3 types :
+- bugfixes
+- security bug fixes, 
+- new version
+
+Then as we want to have working backports, I think we need to do test,
+like we do for normal backports, or updates. This mean someone need to
+test, besides the packagers.
+
+For the first one, we can assume that if there is a bug, someone will
+fill it. Then we can assign it to the one that backported to fix the
+packages, and ask the reporter to test.
+
+
+For the 3rd one, I guess we can use the same as 1st one. If no one ask,
+do nothing. If someone ask, do the same as others backports, and erase
+the previous one.
+
+
+For the 2nd one, it all depend on how we find out about security issues.
+A tool like the one used by debian/ubuntu that check for each package if
+the version is vulnerable or not could help packager to know if a
+backport requires a fix or not, like this is done for the others
+packages. However, this mean that someone will have to check if the bug
+is fixed, and the question is "who" ( and I do not have a answer that I
+find good enough yet ). This could even be more tricky if we consider
+that this can be a version upgrade, and a security fix. Even if we trust
+the upstream to fix the security issue, we still want to have it
+working.
+
+
+But besides this question, there is a more important problem. If we
+think that some packages updates are important enough to be sent to user
+without them asking for explicitly, we cannot let people pick only some
+packages on demand by disabling backports.
+
+Either backports source is enabled in urpmi, and this would mean that
+backports are treated like update from a user point of view, or the
+backports are enabled on demand, meaning that the user is on his own. 
+
+Again, I do not have much ideas. A solution would be to have something
+like portaudit ( http://www.freshports.org/ports-mgmt/portaudit ). So
+people would be warned if the backport is insecure, or could be upgraded
+( even for a new version ). I guess we should however psuh people to run
+the latest backport, whatever the reason, to avoid headaches when bug
+are reported.
+
+Another solution would be to patch urpmi to do a special type of update,
+ie it would only update packages from backports if they come from
+backports. Not really clean, IMHO.
+
+Last solution, declare that cherry picking is not supported, or that
+people are on their own, and explain the reason. However, people have
+been asking this, and recommend this. This would also be against a goal
+of having confidence in the backports.
+
+
+Again, and as said in the title, this is a proposal so feel free to
+comment.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005979.html b/zarb-ml/mageia-dev/2011-June/005979.html new file mode 100644 index 000000000..9b96ff194 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005979.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ David W. Hodgins + davidwhodgins at gmail.com +
+ Fri Jun 24 03:35:08 CEST 2011 +

+
+ +
On Thu, 23 Jun 2011 18:17:57 -0400, Ahmad Samir <ahmadsamir3891 at gmail.com> wrote:
+
+
+> Caveats:
+> - QA is too small, and it'll take time/effort to get through the
+> backported packages requiring tests, unless you depend on the user
+> asking for the backport to have tested the package properly, the user
+> will say it works if it works on his box for the arch he's using, he
+> won't do both archs, not just because he's lazy, but maybe he has one
+> Mageia box for example
+> - Sysadm team is already overworked with many other tasks, meaning the
+> packages requiring a move will rot for a while in backports_testing.
+
+Once QA team members can push the packages from testing to updates or
+backports, the sysadm team won't have to get involved.
+
+> Now compare that to what's used in e.g. mdv:
+> - User asks for a backport
+> - Packager submits the backport and closes the report
+
+Just today, in alt.os.linux.mandriva, there was a user complaining that
+firefox 4 wasn't available.  When it was pointed out that it's been
+in backports for quite a while, the response was that using backports
+"broke" his system.  Hopefully Mageia backports won't get that type
+of reputation.  One way to help with that, is to ensure that all
+backports at least have some qa testing.
+
+I understand your concerns.
+
+My proposal is to use the backports testing, and see if the qa team
+can keep up.  If not, having the package pushed directly from cauldron
+to backports, or release/updates could be opened up later.  Nothing
+is being fixed in stone here.
+
+Regards, Dave Hodgins
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005980.html b/zarb-ml/mageia-dev/2011-June/005980.html new file mode 100644 index 000000000..647b37351 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005980.html @@ -0,0 +1,89 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Fri Jun 24 08:24:42 CEST 2011 +

+
+ +
Op vrijdag 24 juni 2011 02:09:55 schreef Michael Scherer:
+[...]
+> - I am not sure on this part, but basically, we have 2 choices :
+>   - the packager take the cauldron package and push to backport testing
+>   - the packager move the cauldron package in svn to backport, and there
+> send it to backport testing.
+> 
+> Proposal 1 mean less work duplication, but proposal 2 let us do more
+> customization.
+[...]
+> 
+> WDYT ?
+
+I think we should go with option #2, but with an extra command in mgarepo 
+there should be less work.
+
+something like:
+ - "mgarepo switch -d 1 core/backports"
+ - "magrepo switch core/release"
+
+the idea is to move your local repository to the directed position, but if it 
+doesn't exist, that it is to be created. (possibly with a --create option).
+
+mvg,
+
+Maarten
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005981.html b/zarb-ml/mageia-dev/2011-June/005981.html new file mode 100644 index 000000000..051fb3450 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005981.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] Backports policy proposal + + + + + + + + + +

[Mageia-dev] Backports policy proposal

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Fri Jun 24 08:30:15 CEST 2011 +

+
+ +
Op vrijdag 24 juni 2011 02:10:14 schreef Michael Scherer:
+[...]
+> Another rule that we could add is that cauldron should always be newer
+> than backports, in order to ensure upgradability. The same goes for n-2
+> and n-1 release.
+> While this seems innocent, do not forget this will have a impact when we
+> do the version freeze.
+[..]
+
+This seems hard to enforce... i can imagine if you make backport, it has 
+essentially the same version as in cauldron, i can think that there is a few 
+spec file changes that are only for backports, and thus the release becomes 
+newer than the one in cauldron
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005982.html b/zarb-ml/mageia-dev/2011-June/005982.html new file mode 100644 index 000000000..2364f1d68 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005982.html @@ -0,0 +1,161 @@ + + + + [Mageia-dev] Monitoring of new GNOME/upstream releases + + + + + + + + + +

[Mageia-dev] Monitoring of new GNOME/upstream releases

+ Olav Vitters + olav at vitters.nl +
+ Fri Jun 24 11:28:06 CEST 2011 +

+
+ +
Does Mageia monitor upstream releases and how?
+
+This as I noticed that the new Metacity release (2.34.1) is not yet in
+Cauldron.
+
+GNOME has a ftp-release-list mailing list[1]. It sends out notices when new
+modules are released. It has X- headers for easy parsing. Only thing
+that has to be taken into account is that it could take 5min before
+modules can be downloaded (ftp.gnome.org is a mirror, it is not the
+place where releases are done).
+
+If nothing is in place to monitor, I'd like to help out to set something
+up.. though I probably need some guidance.
+-- 
+Regards,
+Olav
+
+[1] http://mail.gnome.org/archives/ftp-release-list/
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005983.html b/zarb-ml/mageia-dev/2011-June/005983.html new file mode 100644 index 000000000..a555de473 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005983.html @@ -0,0 +1,119 @@ + + + + [Mageia-dev] Backports policy proposal + + + + + + + + + +

[Mageia-dev] Backports policy proposal

+ Michael Scherer + misc at zarb.org +
+ Fri Jun 24 11:44:32 CEST 2011 +

+
+ +
Le vendredi 24 juin 2011 à 08:30 +0200, Maarten Vanraes a écrit :
+> Op vrijdag 24 juni 2011 02:10:14 schreef Michael Scherer:
+> [...]
+> > Another rule that we could add is that cauldron should always be newer
+> > than backports, in order to ensure upgradability. The same goes for n-2
+> > and n-1 release.
+> > While this seems innocent, do not forget this will have a impact when we
+> > do the version freeze.
+> [..]
+> 
+> This seems hard to enforce... i can imagine if you make backport, it has 
+> essentially the same version as in cauldron, i can think that there is a few 
+> spec file changes that are only for backports, and thus the release becomes 
+> newer than the one in cauldron
+
+Youri has a module for that ( recency I think ), and we used this in
+PLF.
+
+And if there is changes that would make sense just for backport, one can
+play with release tag to be older, or can just rebuild in cauldron to be
+newer before backporting.
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005984.html b/zarb-ml/mageia-dev/2011-June/005984.html new file mode 100644 index 000000000..94c8d86e0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005984.html @@ -0,0 +1,168 @@ + + + + [Mageia-dev] Monitoring of new GNOME/upstream releases + + + + + + + + + +

[Mageia-dev] Monitoring of new GNOME/upstream releases

+ Michael Scherer + misc at zarb.org +
+ Fri Jun 24 11:46:59 CEST 2011 +

+
+ +
Le vendredi 24 juin 2011 à 11:28 +0200, Olav Vitters a écrit :
+> Does Mageia monitor upstream releases and how?
+> 
+> This as I noticed that the new Metacity release (2.34.1) is not yet in
+> Cauldron.
+> 
+> GNOME has a ftp-release-list mailing list[1]. It sends out notices when new
+> modules are released. It has X- headers for easy parsing. Only thing
+> that has to be taken into account is that it could take 5min before
+> modules can be downloaded (ftp.gnome.org is a mirror, it is not the
+> place where releases are done).
+> 
+> If nothing is in place to monitor, I'd like to help out to set something
+> up.. though I probably need some guidance.
+
+We do have this with check.mageia.org, based on youri.
+
+Now, if you want to create a notification system for that, feel free.
+The software can be found on ouri.zarb.og, the documentation is minimal,
+this is perl. You can however get test result in txt format, html, or
+anything, and thus a tool to send notification ( and more important, a
+tool to configure notification ) can be constructed upon that.
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005985.html b/zarb-ml/mageia-dev/2011-June/005985.html new file mode 100644 index 000000000..af5fa1f3b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005985.html @@ -0,0 +1,157 @@ + + + + [Mageia-dev] Monitoring of new GNOME/upstream releases + + + + + + + + + +

[Mageia-dev] Monitoring of new GNOME/upstream releases

+ Balcaen John + mikala at mageia.org +
+ Fri Jun 24 11:49:35 CEST 2011 +

+
+ +
Le vendredi 24 juin 2011 06:28:06, Olav Vitters a écrit :
+> Does Mageia monitor upstream releases and how?
+> 
+> This as I noticed that the new Metacity release (2.34.1) is not yet in
+> Cauldron.
+> 
+I noticed it yesterday night and i was working on it :)
+
+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-June/005986.html b/zarb-ml/mageia-dev/2011-June/005986.html new file mode 100644 index 000000000..07266501e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005986.html @@ -0,0 +1,183 @@ + + + + [Mageia-dev] Monitoring of new GNOME/upstream releases + + + + + + + + + +

[Mageia-dev] Monitoring of new GNOME/upstream releases

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Fri Jun 24 12:26:34 CEST 2011 +

+
+ +
On Fri, 24 Jun 2011, Olav Vitters wrote:
+
+> Does Mageia monitor upstream releases and how?
+>
+> This as I noticed that the new Metacity release (2.34.1) is not yet in
+> Cauldron.
+>
+> GNOME has a ftp-release-list mailing list[1]. It sends out notices when new
+> modules are released. It has X- headers for easy parsing. Only thing
+> that has to be taken into account is that it could take 5min before
+> modules can be downloaded (ftp.gnome.org is a mirror, it is not the
+> place where releases are done).
+
+We have http://check.mageia.org/updates.html - it's not perfect but what 
+we currently really lack is a maintainer database. This is needed to know 
+where update notices should be sent.
+
+I made a list of gnome packages that should probably be updated (to a 
+3.0.x release). Metacity was not yet on there so I added it:
+
+accerciser
+banshee
+cheese
+epiphany-extensions ?
+evince - in progress
+gconf-editor ?
+gedit
+gnome-games
+gnome-packagekit
+gnome-themes
+gnome-user-docs
+libwnck ?
+metacity (2.34.1)
+mousetweaks
+orca
+totem
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005987.html b/zarb-ml/mageia-dev/2011-June/005987.html new file mode 100644 index 000000000..545a37739 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005987.html @@ -0,0 +1,178 @@ + + + + [Mageia-dev] [RPM] cauldron core/release gnutls-2.12.7-1.mga2 + + + + + + + + + +

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

+ Balcaen John + mikala at mageia.org +
+ Fri Jun 24 12:35:46 CEST 2011 +

+
+ +
Le mardi 21 juin 2011 12:31:26, Mageia Team a écrit :
+> Name        : gnutls                       Relocations: (not relocatable)
+> Version     : 2.12.7                            Vendor: Mageia.Org
+> Release     : 1.mga2                        Build Date: Tue Jun 21 17:26:30 
+2011
+> Install Date: (not installed)               Build Host: ecosse
+> Group       : System/Libraries              Source RPM: (none)
+> Size        : 7163819                          License: GPLv2+ and LGPLv2+
+> 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> 2.12.7-1.mga2:
+> + Revision: 111574
+> - new verison 2.12.7 (nettle based)
+Could you have a look to gnutls & telepathy-gabble / salut ?
+Since the upgrade to 2.12.7 we're facing again this bug 
+https://bugs.freedesktop.org/show_bug.cgi?id=29364
+
+with in the telepathy log this error :
+on_connection_ready: got error: WOCKY_CONNECTOR_ERROR_TLS_SESSION_FAILED (#7): 
+TLS handshake error: -59: GNUTLS_E_INTERNAL_ERROR
+
+Reverting to the gnutls available in mageia 1 fix that.
+
+
+
+-- 
+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-June/005988.html b/zarb-ml/mageia-dev/2011-June/005988.html new file mode 100644 index 000000000..e93746a3b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005988.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Angelo Naselli + anaselli at linux.it +
+ Fri Jun 24 12:51:27 CEST 2011 +

+
+ +
> - I am not sure on this part, but basically, we have 2 choices :
+>   - the packager take the cauldron package and push to backport testing
+>   - the packager move the cauldron package in svn to backport, and there
+> send it to backport testing.
+copy i believe. IIUC we should branch cauldron into stable relases for that
+package, but what happens if the package already exists? I mean
+foo 1.0.0 is in stable, a foo 1.1.0 is required and could be backported
+into stable branch... we have two foo programs with their own story.
+ 
+> WDYT ?
+I like the second option, but in such a way we should provide upgrades from
+a stable with backports, since they follow a good feedback policy before going
+to stable. 
+
+I understand QA and sysadmins are not overloaded, but there's not so much 
+difference between updates and backports then...
+
+
+-- 
+	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/20110624/5dcdf163/attachment.asc>
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005989.html b/zarb-ml/mageia-dev/2011-June/005989.html new file mode 100644 index 000000000..53db3a5c9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005989.html @@ -0,0 +1,129 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ José Jorge + jjorge at free.fr +
+ Fri Jun 24 13:12:53 CEST 2011 +

+
+ +
Le vendredi 24 juin 2011 02:15:03, Michael Scherer a écrit :
+> Last solution, declare that cherry picking is not supported, or that
+> people are on their own, and explain the reason. However, people have
+> been asking this, and recommend this. This would also be against a goal
+> of having confidence in the backports.
+> 
+I have always used backports in a total way : if I want latest software 
+against stability, I take them all. Think about little dependencies that still 
+exist (vlc + ffmpeg, etc).
+
+So I would say Mageia has two update modes :
+
+- end user (security) mode (updates)
+- power user (let's try everything) mode (updates+backports)
+
+Each user  will recognise himself in one of the two modes.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005990.html b/zarb-ml/mageia-dev/2011-June/005990.html new file mode 100644 index 000000000..fbf6e2085 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005990.html @@ -0,0 +1,146 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Fri Jun 24 13:42:45 CEST 2011 +

+
+ +
2011/6/24 José Jorge <jjorge at free.fr>:
+> Le vendredi 24 juin 2011 02:15:03, Michael Scherer a écrit :
+>> Last solution, declare that cherry picking is not supported, or that
+>> people are on their own, and explain the reason. However, people have
+>> been asking this, and recommend this. This would also be against a goal
+>> of having confidence in the backports.
+>>
+> I have always used backports in a total way : if I want latest software
+> against stability, I take them all. Think about little dependencies that still
+> exist (vlc + ffmpeg, etc).
+>
+> So I would say Mageia has two update modes :
+>
+> - end user (security) mode (updates)
+> - power user (let's try everything) mode (updates+backports)
+>
+> Each user  will recognise himself in one of the two modes.
+
+So, where do I find myself in this scenario?
+
+I do not use backports in general, they are disabled.
+A new version of foo is coming in in cauldron and I want to use it in Mageia 1.
+A friendly packager builds a backport of this new version of foo for Mageia 1.
+I enable backports, do "urpmi foo" and I get the version from
+backports including dependencies.
+After that I disable backports.
+
+This is the way backports have been used by many users in Mandriva.
+And (BTW) this is the exact meaning of the word, a version is
+backported from a newer distrib-version or cooker/cauldron to an older
+distrib-version or current stable version.
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005991.html b/zarb-ml/mageia-dev/2011-June/005991.html new file mode 100644 index 000000000..4a7187314 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005991.html @@ -0,0 +1,172 @@ + + + + [Mageia-dev] Monitoring of new GNOME/upstream releases + + + + + + + + + +

[Mageia-dev] Monitoring of new GNOME/upstream releases

+ Olav Vitters + olav at vitters.nl +
+ Fri Jun 24 13:53:22 CEST 2011 +

+
+ +
On Fri, Jun 24, 2011 at 11:46:59AM +0200, Michael Scherer wrote:
+> Now, if you want to create a notification system for that, feel free.
+> The software can be found on ouri.zarb.og, the documentation is minimal,
+> this is perl. You can however get test result in txt format, html, or
+> anything, and thus a tool to send notification ( and more important, a
+> tool to configure notification ) can be constructed upon that.
+
+Thanks for the pointer. Already noticed a few things:
+1. It uses the LATEST-IS files and there was a bug with that and not
+everything has been fixed atm (is fixed for new stuff)
+2. It uses http://fr2.rpmfind.net/linux/gnome.org/sources instead of
+either http://ftp.gnome.org/pub/GNOME/sources (primary mirror) or
+http://download.gnome.org/ (currently just redirects to primary mirror,
+long term goal is having it redirect to closest mirror).
+
+Didn't fully analyse yet, but noticed it uses a database, so think I'll
+need to make two things:
+ - script to process live update messages (ftp-release-list in case of
+   GNOME)
+ - script to notify people (either immediately or when youri runs from
+   cron) + setting in database which ensures the announce only goes out
+   once
+
+I'll try to work on this.
+
+How would the maintainer data be stored btw? Should it be a config file
+that a script generates, LDAP?
+Also: is a maintainer always the same for all branches? e.g. if someone
+maintainers metacity, that person is responsible for Cauldron, stable
+releases, backports, etc (some distributions differ on this)?
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005992.html b/zarb-ml/mageia-dev/2011-June/005992.html new file mode 100644 index 000000000..e4b3dba61 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005992.html @@ -0,0 +1,196 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ Marianne Lombard + marianne at tuxette.fr +
+ Fri Jun 24 15:41:13 CEST 2011 +

+
+ +
Le 24/06/2011 13:42, Wolfgang Bornath a écrit :
+> 2011/6/24 José Jorge<jjorge at free.fr>:
+>> Le vendredi 24 juin 2011 02:15:03, Michael Scherer a écrit :
+>>> Last solution, declare that cherry picking is not supported, or that
+>>> people are on their own, and explain the reason. However, people have
+>>> been asking this, and recommend this. This would also be against a goal
+>>> of having confidence in the backports.
+>>>
+>> I have always used backports in a total way : if I want latest software
+>> against stability, I take them all. Think about little dependencies that still
+>> exist (vlc + ffmpeg, etc).
+>>
+>> So I would say Mageia has two update modes :
+>>
+>> - end user (security) mode (updates)
+>> - power user (let's try everything) mode (updates+backports)
+>>
+>> Each user  will recognise himself in one of the two modes.la
+> So, where do I find myself in this scenario?
+>
+> I do not use backports in general, they are disabled.
+> A new version of foo is coming in in cauldron and I want to use it in Mageia 1.
+> A friendly packager builds a backport of this new version of foo for Mageia 1.
+> I enable backports, do "urpmi foo" and I get the version from
+> backports including dependencies.
+> After that I disable backports.
+>
+> This is the way backports have been used by many users in Mandriva.
+> And (BTW) this is the exact meaning of the word, a version is
+> backported from a newer distrib-version or cooker/cauldron to an older
+> distrib-version or current stable version.
+I use a few backported package on a Mdv install (please, don't lapidate
+me, I have 2 mageia cauldron at home). To easily update them, I have
+made a small and ugly bash script.
+It can propably being optimised, clean, etc. I run it manually times to
+times .
+
+Regards
+
+[jehane at mdvbox]$ cat update-backports.sh
+#!/bin/bash
+
+# Add here your package, for each repository
+# Main backports package
+pkge_main="firefox"
+# Contrib backports package
+pkge_contrib="fusioninventory-agent";
+
+echo "Script for updating package present in non-activated repositery"
+echo "Only for distribution using urpmi"
+echo ""
+echo "List of checked package"
+echo $pkge_main
+echo $pkge_contrib
+echo ""
+
+
+# Must be launch as root
+if [ "$UID" -ne 0 ]; then
+     echo "Need to be root"
+     exit $E_NOTROOT
+fi
+
+# Updating repos
+echo "Updating backports repository"
+urpmi.update "Main Backports"
+urpmi.update "Contrib Backports"
+
+echo "Updating package"
+for package in `echo $pkge_main` ;
+     do urpmi --searchmedi "Main Backports" $package
+     done
+
+for package in `echo $pkge_contrib` ;
+     do urpmi --searchmedia "Contrib Backports" $package
+     done
+
+
+-- 
+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-June/005993.html b/zarb-ml/mageia-dev/2011-June/005993.html new file mode 100644 index 000000000..4f056b3a2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005993.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Buchan Milne + bgmilne at staff.telkomsa.net +
+ Fri Jun 24 16:18:21 CEST 2011 +

+
+ +
On Friday, 24 June 2011 03:35:08 David W. Hodgins wrote:
+
+> Just today, in alt.os.linux.mandriva, there was a user complaining that
+> firefox 4 wasn't available.  When it was pointed out that it's been
+> in backports for quite a while, the response was that using backports
+> "broke" his system.
+
+Where is his bug report?
+
+Would QA by the QA team have avoided the problem?
+
+(And, the idea with Backports was IMHO that it should not be enabled in the 
+configuration, but used on a case-by-case basis - which was easier once 
+rpmdrake allowed it).
+
+> Hopefully Mageia backports won't get that type
+> of reputation.  One way to help with that, is to ensure that all
+> backports at least have some qa testing.
+> 
+> I understand your concerns.
+> 
+> My proposal is to use the backports testing, and see if the qa team
+> can keep up.  If not, having the package pushed directly from cauldron
+> to backports, or release/updates could be opened up later.  Nothing
+> is being fixed in stone here.
+
+In Mandriva, I typically *tested* (minimally) anything I pushed to backports, 
+before I pushed it.
+
+But, I certainly don't think having the QA team involved would have provided 
+much value.
+
+There was one instance for OpenLDAP where a non-OpenLDAP-maintainer pushed the 
+cooker package to backports without testing, which did create a problem for 
+some users :-(.
+
+IMHO, *if* we want to have QA, it should be the onus of users who wanted the 
+backports, and not require any contributor action. E.g. an automatic system 
+based on votes (e.g. require positive feedback from 80% of at least 20 users 
+who have rated a package to promote a package from backports_testing to 
+backports).
+
+Regards,
+Buchan
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005994.html b/zarb-ml/mageia-dev/2011-June/005994.html new file mode 100644 index 000000000..869af4df0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005994.html @@ -0,0 +1,124 @@ + + + + [Mageia-dev] Backports policy proposal + + + + + + + + + +

[Mageia-dev] Backports policy proposal

+ Buchan Milne + bgmilne at staff.telkomsa.net +
+ Fri Jun 24 16:19:45 CEST 2011 +

+
+ +
On Friday, 24 June 2011 08:30:15 Maarten Vanraes wrote:
+> Op vrijdag 24 juni 2011 02:10:14 schreef Michael Scherer:
+> [...]
+> 
+> > Another rule that we could add is that cauldron should always be newer
+> > than backports, in order to ensure upgradability. The same goes for n-2
+> > and n-1 release.
+> > While this seems innocent, do not forget this will have a impact when we
+> > do the version freeze.
+> 
+> [..]
+> 
+> This seems hard to enforce... i can imagine if you make backport, it has
+> essentially the same version as in cauldron, i can think that there is a
+> few spec file changes that are only for backports,
+
+Why should it need spec file changes?
+
+> and thus the release
+> becomes newer than the one in cauldron
+
+If it requires spec file changes, why should cauldron not get a new release 
+that includes the changes?
+
+Sorry, but a number of my packages were regularly backported, and I never 
+needed cooker to be older ...
+
+Regards,
+Buchan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005995.html b/zarb-ml/mageia-dev/2011-June/005995.html new file mode 100644 index 000000000..04cf78d14 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005995.html @@ -0,0 +1,115 @@ + + + + [Mageia-dev] Backports policy proposal + + + + + + + + + +

[Mageia-dev] Backports policy proposal

+ Anssi Hannula + anssi.hannula at iki.fi +
+ Fri Jun 24 16:33:49 CEST 2011 +

+
+ +
On 24.06.2011 03:10, Michael Scherer wrote:
+> Another rule that we could add is that cauldron should always be newer
+> than backports, in order to ensure upgradability. The same goes for n-2
+> and n-1 release.
+> While this seems innocent, do not forget this will have a impact when we
+> do the version freeze.
+
+So this will prevent backporting anything to mga1 if it is not in mga2
+release/updates ?
+
+Also, I don't see the advantage in preventing backports during freeze.
+The backports are re-allowed soon anyway, and the upgradeability goes
+away anyway.
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

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

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

+ Balcaen John + mikala at mageia.org +
+ Fri Jun 24 16:37:23 CEST 2011 +

+
+ +
Le vendredi 24 juin 2011 07:35:46, Balcaen John a écrit :
+> Le mardi 21 juin 2011 12:31:26, Mageia Team a écrit :
+> > Name        : gnutls                       Relocations: (not relocatable)
+> > Version     : 2.12.7                            Vendor: Mageia.Org
+> > Release     : 1.mga2                        Build Date: Tue Jun 21 
+17:26:30 
+> 2011
+> > Install Date: (not installed)               Build Host: ecosse
+> > Group       : System/Libraries              Source RPM: (none)
+> > Size        : 7163819                          License: GPLv2+ and LGPLv2+
+> > 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> 2.12.7-1.mga2:
+> > + Revision: 111574
+> > - new verison 2.12.7 (nettle based)
+> Could you have a look to gnutls & telepathy-gabble / salut ?
+> Since the upgrade to 2.12.7 we're facing again this bug 
+> https://bugs.freedesktop.org/show_bug.cgi?id=29364
+> 
+> with in the telepathy log this error :
+> on_connection_ready: got error: WOCKY_CONNECTOR_ERROR_TLS_SESSION_FAILED 
+(#7): 
+> TLS handshake error: -59: GNUTLS_E_INTERNAL_ERROR
+> 
+After a second look it seems related to the use of libnettle.
+Reverting to libcrypt (adding --with-libgcrypt switch to configure) fix it.
+I also use a patch from fedora to skip dsa test  ( cf 
+http://pkgs.fedoraproject.org/gitweb/?p=gnutls.git;a=blob;f=gnutls-2.12.7-dsa-
+skiptests.patch;h=64fa2245c104356cefc0ad784777feff7e972dc6;hb=9aec8097dd3829afcbd75ed8a83176248cef6b43 
+) to allow the build .
+
+ 
+-- 
+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-June/005997.html b/zarb-ml/mageia-dev/2011-June/005997.html new file mode 100644 index 000000000..18a7d4d51 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005997.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ andre999 + andr55 at laposte.net +
+ Fri Jun 24 21:16:41 CEST 2011 +

+
+ +
Michael Scherer a écrit :
+>
+> ...
+>
+> - Someone request a backport ...
+>
+> - a packager decide to do it. ...
+>
+> - I am not sure on this part, but basically, we have 2 choices :
+>    - the packager take the cauldron package and push to backport testing
+>    - the packager move the cauldron package in svn to backport, and there
+> send it to backport testing.
+>
+> Proposal 1 mean less work duplication, but proposal 2 let us do more
+> customization.
+>
+> ...
+>
+> This way :
+> - packages are not sent untested, thus raising confidence in backports
+> - the QA should not be overloaded, and can focus on updates
+> - sysadmins are not overloaded
+> - people requesting backport see how QA work, and are involved into the
+> distribution as testers, thus creating a much healthier discussion with
+> packagers, and creating more incentive to help. And since they request
+> the package, they will be motivated to test more than stuff they do not
+> use.
+>
+> WDYT ?
+
+Overall I think that it is an excellent approach, for the reasons given.
+I don't yet understand the difference between proposal 1 and 2, so for the moment I don't have a 
+preference.
+
+Even though bugzilla might seem a bit cumbersome for requesting backports, otherwise I think that 
+it is an excellent tool for this purpose.
+We could perhaps have some sort of shortcut for filing backport requests.
+
+-- 
+André
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005998.html b/zarb-ml/mageia-dev/2011-June/005998.html new file mode 100644 index 000000000..7e78d2eca --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005998.html @@ -0,0 +1,165 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Fri Jun 24 21:39:51 CEST 2011 +

+
+ +
On 24 June 2011 02:09, Michael Scherer <misc at zarb.org> wrote:
+> Hi,
+>
+> as said in the thread of firefox 5, and in the meeting of packager
+> sooner this week, this is the first mail about backports ( on 3 ).
+>
+> So here is the proposal of a process, based on the feedback of people,
+> and the idea of some packagers ( mainly stormi ).
+>
+>
+> - Someone request a backport ( by bugzilla, by madb, by a email, by
+> taking a packager family in hostage, whatever ). I would prefer use
+> bugzilla but this may not be very user friendly, or too heavy.
+>
+
+How would the packager get notified of backports requests via madb?
+
+Would you elaborate on how bugzilla is heavy for a backports request?
+
+> - a packager decide to do it. Based on the policy ( outlined in another
+> mail ), and maybe seeing with the maintainer first about that for non
+> trivial applications, the backport can be done, or not. The criterias
+> for being backported or not are not important to the process, just
+> assume that they exist for now ( and look at next mail ). So based on
+> criteria, someone say "it can be backported, so I do it".
+>
+
+[...]
+
+> - I am not sure on this part, but basically, we have 2 choices :
+>  - the packager take the cauldron package and push to backport testing
+>  - the packager move the cauldron package in svn to backport, and there
+> send it to backport testing.
+>
+> Proposal 1 mean less work duplication, but proposal 2 let us do more
+> customization.
+>
+
+Option 1 doesn't only mean not duplicating work, but also that the the
+spec in backports svn isn't ever out-dated; the only reason I see a
+package being in stable distro SVN is if it's in /release|updates, not
+backports...
+
+> if the package doesn't build, the packager fix ( or drop the idea if
+> this requires too much work )
+>
+> - the packager send requesting feedback about the backport from the
+> people who requested it, and test it as well.
+>
+
+Probably off-topic, but how will that work with madb? i.e. how will
+the maintainer get the feedback?
+
+> - based on feedback ( ie if the package work or if the packager is
+> confident ), the packager decide to move it to backport for everybody,
+> using some stuff similar to rpmctl ( the tool we used to move package at
+> Mandriva ). The tool would also send notifications.
+>
+
+The packager decides to move it and he has the necessary privileges to
+do so? or will he have to request someone from another team to move
+it?
+
+> - if the package doesn't work, he either fix, or drop the backport idea.
+> If he fix, we go back on testing, if he drop, we remove the rpm ( with a
+> automated cleaning of rpm after 1 or 2 months ).
+>
+
+[..]
+
+> If the packager drop the backport, it should be notified to the
+> requester ( hence the use of bugzilla, or a more suitable tool )
+>
+
+Agreed.
+
+> This way :
+> - packages are not sent untested, thus raising confidence in backports
+
+How many times did backports breaks a user's whole installation? we
+always say that backports should mainly be cherry picked, but not
+enabled all the time... so how does installing a new version of e.g.
+wine break the user's system when he can easily back out that rpm?
+
+> - the QA should not be overloaded, and can focus on updates
+> - sysadmins are not overloaded
+> - people requesting backport see how QA work, and are involved into the
+> distribution as testers, thus creating a much healthier discussion with
+> packagers, and creating more incentive to help. And since they request
+> the package, they will be motivated to test more than stuff they do not
+> use.
+>
+> WDYT ?
+>
+> --
+> Michael Scherer
+>
+>
+
+
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/005999.html b/zarb-ml/mageia-dev/2011-June/005999.html new file mode 100644 index 000000000..b2732a20e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005999.html @@ -0,0 +1,132 @@ + + + + [Mageia-dev] Backports policy proposal + + + + + + + + + +

[Mageia-dev] Backports policy proposal

+ andre999 + andr55 at laposte.net +
+ Fri Jun 24 22:20:19 CEST 2011 +

+
+ +
Michael Scherer a écrit :
+>
+> so :
+> - cannot be backported if this is not a leaf package, will be revised later
+> - cannot be backported if the maintainer say "no", but we assume he say "yes" by default
+> - cannot be backported if it impact the dependency tree too much ( Obsoletes, Provides, etc )
+> - cannot be backported if the package was just created and is thus basically untested in cauldron
+
+What about corner cases where a potential backport is incompatible with changes introduced in 
+cauldron ?  Should we leave such packages to third parties ?  (I would tend to say yes.)
+
+> - must not prevent upgrade to next release
+
+I can see where a backport could be a more recent version than in cauldron for the moment.  Since 
+that could make the newer version available to users somewhat sooner.  Although by release, 
+cauldron should have at least as recent a version.  Or should we prohibit this ?
+(I'm thinking of cases where more recent versions are expected for cauldron before release.)
+
+> - strict requires between backported packages, in order to make sure they can be cherrypicked ( ie, someone enable backports, install, remove backports )
+
+It would be best if one can select individual backports without activating the backports 
+repositories, as is now the case.
+So only the brave (wanting all backports) need activate the backports repositories.
+
+Agree with everything, except as noted.
+
+It might be useful to list major packages that should never be backported.
+I like the idea of tagging backports in the package name, as well as in the package database.
+(I'd like the database to retain all the source repositories of installed packages.)
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006000.html b/zarb-ml/mageia-dev/2011-June/006000.html new file mode 100644 index 000000000..a29c8f000 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006000.html @@ -0,0 +1,186 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ andre999 + andr55 at laposte.net +
+ Fri Jun 24 22:40:46 CEST 2011 +

+
+ +
Michael Scherer a écrit :
+>
+> Hi,
+>
+> The last mail from the backport trilogy. And like all good trilogy,
+> that's where the suspens is present ( as for the 1 and 2 part, you know
+> there is another episode )
+>
+> This mail is about handling update on the backport repository. Either
+> new version, or bugfix, or security upgrade.
+>
+> Everybody was focused on "should we do patch, or should we do more
+> backport" issue, but the real problem is not really here.
+>
+> First, we have to decide what kind of update do we want to see, among
+> the 3 types :
+> - bugfixes
+> - security bug fixes,
+> - new version
+>
+> Then as we want to have working backports, I think we need to do test,
+> like we do for normal backports, or updates. This mean someone need to
+> test, besides the packagers.
+>
+> For the first one, we can assume that if there is a bug, someone will
+> fill it. Then we can assign it to the one that backported to fix the
+> packages, and ask the reporter to test.
+>
+>
+> For the 3rd one, I guess we can use the same as 1st one. If no one ask,
+> do nothing. If someone ask, do the same as others backports, and erase
+> the previous one.
+>
+>
+> For the 2nd one, it all depend on how we find out about security issues.
+> A tool like the one used by debian/ubuntu that check for each package if
+> the version is vulnerable or not could help packager to know if a
+> backport requires a fix or not, like this is done for the others
+> packages. However, this mean that someone will have to check if the bug
+> is fixed, and the question is "who" ( and I do not have a answer that I
+> find good enough yet ). This could even be more tricky if we consider
+> that this can be a version upgrade, and a security fix. Even if we trust
+> the upstream to fix the security issue, we still want to have it
+> working.
+>
+>
+> But besides this question, there is a more important problem. If we
+> think that some packages updates are important enough to be sent to user
+> without them asking for explicitly, we cannot let people pick only some
+> packages on demand by disabling backports.
+>
+> Either backports source is enabled in urpmi, and this would mean that
+> backports are treated like update from a user point of view, or the
+> backports are enabled on demand, meaning that the user is on his own.
+>
+> Again, I do not have much ideas. A solution would be to have something
+> like portaudit ( http://www.freshports.org/ports-mgmt/portaudit ). So
+> people would be warned if the backport is insecure, or could be upgraded
+> ( even for a new version ). I guess we should however psuh people to run
+> the latest backport, whatever the reason, to avoid headaches when bug
+> are reported.
+>
+> Another solution would be to patch urpmi to do a special type of update,
+> ie it would only update packages from backports if they come from
+> backports. Not really clean, IMHO.
+>
+> Last solution, declare that cherry picking is not supported, or that
+> people are on their own, and explain the reason. However, people have
+> been asking this, and recommend this. This would also be against a goal
+> of having confidence in the backports.
+>
+>
+> Again, and as said in the title, this is a proposal so feel free to
+> comment.
+>
+
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006001.html b/zarb-ml/mageia-dev/2011-June/006001.html new file mode 100644 index 000000000..e9a4cc432 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006001.html @@ -0,0 +1,111 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ andre999 + andr55 at laposte.net +
+ Fri Jun 24 22:55:45 CEST 2011 +

+
+ +
ignore previous message -- I pushed the wrong button
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006002.html b/zarb-ml/mageia-dev/2011-June/006002.html new file mode 100644 index 000000000..14e8c4e6c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006002.html @@ -0,0 +1,162 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ andre999 + andr55 at laposte.net +
+ Sat Jun 25 00:13:42 CEST 2011 +

+
+ +
Michael Scherer a écrit :
+>
+> This mail is about handling update on the backport repository. Either
+> new version, or bugfix, or security upgrade.
+>
+> Everybody was focused on "should we do patch, or should we do more
+> backport" issue, but the real problem is not really here.
+>
+> First, we have to decide what kind of update do we want to see, among
+> the 3 types :
+> - bugfixes
+> - security bug fixes,
+> - new version
+
+For bugfixes and new versions, that are not known to have security implications, let's treat them 
+essentially as new backports.
+If the bug were locally reported, the reporter would be involved in the testing.
+Such updates would be installed as any other backport.
+However I would favour notifying those who have installed previous versions of these backports, of 
+the availability of newer versions.
+Maybe even having a backports updates category.  (But not to be installed automatically by default.)
+
+For security issues, I'm not sure that it is important how we find out.
+As far as responsibility, I think the main responibility should be by the packager, but it could be 
+useful for the security team to monitor it, to find an alternate packager if necessary.
+(Presumably from those who have tested or installed the package.)
+(I don't know who monitors security issues now, I just assume the security team.)
+
+However I think that such packages should be tested as normally for backports, and then treated as 
+security updates, to be automatically applied.
+This is because those who have installed the backport in question have decided to accept a higher 
+degree of risk.  However a security issue can be a much greater risk, and is something that is 
+normally resolved automatically.  So by installing a security bug fix automatically for a backport, 
+we are essentially maintaining the level of risk already assumed by the user.
+
+
+In summary :
+
+In terms of testing, I see all backport updates as following the same process as for the initial 
+backports.  (As outlined by misc in another thread.)
+
+For non-security updates, I see essentially the same installation process as for initial backports.
+Adding some form of notification to those who have installed a previous version of the backport in 
+question.
+
+For security updates, I see automatic installation as with any security update.
+
+The treatment of these updates would depend on what is installed on the user's system, and not what 
+repositories are selected.
+
+In terms of monitoring security issues, why not use the same as for other packages ?
+
+my 2 cents :)
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006003.html b/zarb-ml/mageia-dev/2011-June/006003.html new file mode 100644 index 000000000..ef8bc94d1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006003.html @@ -0,0 +1,179 @@ + + + + [Mageia-dev] Monitoring of new GNOME/upstream releases + + + + + + + + + +

[Mageia-dev] Monitoring of new GNOME/upstream releases

+ Michael Scherer + misc at zarb.org +
+ Sat Jun 25 10:35:13 CEST 2011 +

+
+ +
Le vendredi 24 juin 2011 à 13:53 +0200, Olav Vitters a écrit :
+> On Fri, Jun 24, 2011 at 11:46:59AM +0200, Michael Scherer wrote:
+> > Now, if you want to create a notification system for that, feel free.
+> > The software can be found on ouri.zarb.og, the documentation is minimal,
+> > this is perl. You can however get test result in txt format, html, or
+> > anything, and thus a tool to send notification ( and more important, a
+> > tool to configure notification ) can be constructed upon that.
+> 
+> Thanks for the pointer. Already noticed a few things:
+> 1. It uses the LATEST-IS files and there was a bug with that and not
+> everything has been fixed atm (is fixed for new stuff)
+
+The original setup do use others sources ( others distro, freshmeat, etc
+), so I guess this bug would not affect us too much.
+
+But if I understood well, this is fixed so it would be ok in the long
+term ?
+
+> 2. It uses http://fr2.rpmfind.net/linux/gnome.org/sources instead of
+> either http://ftp.gnome.org/pub/GNOME/sources (primary mirror) or
+> http://download.gnome.org/ (currently just redirects to primary mirror,
+> long term goal is having it redirect to closest mirror).
+
+I guess that can be fixed quite quick. 
+
+> Didn't fully analyse yet, but noticed it uses a database, so think I'll
+> need to make two things:
+>  - script to process live update messages (ftp-release-list in case of
+>    GNOME)
+>  - script to notify people (either immediately or when youri runs from
+>    cron) + setting in database which ensures the announce only goes out
+>    once
+> 
+> I'll try to work on this.
+> 
+> How would the maintainer data be stored btw? Should it be a config file
+> that a script generates, LDAP?
+
+It would be in a web software, with a json export. But the software is
+not finished yet, Pascal Terjan said he would look at it. See
+http://gitorious.org/mageia-maintainers-database-r2
+
+> Also: is a maintainer always the same for all branches? e.g. if someone
+> maintainers metacity, that person is responsible for Cauldron, stable
+> releases, backports, etc (some distributions differ on this)?
+
+So far, yes. We discussed the concept of having more than one maintainer
+however per package.
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006004.html b/zarb-ml/mageia-dev/2011-June/006004.html new file mode 100644 index 000000000..b9251925a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006004.html @@ -0,0 +1,120 @@ + + + + [Mageia-dev] Backports policy proposal + + + + + + + + + +

[Mageia-dev] Backports policy proposal

+ Angelo Naselli + anaselli at linux.it +
+ Sat Jun 25 15:05:52 CEST 2011 +

+
+ +
In data venerdì 24 giugno 2011 02:10:14, Michael Scherer ha scritto:
+> - cannot be backported if the package was just created and is thus
+> basically untested in cauldron
+Well even if i could agree with that, i cannot see how can we ensure that
+a 2-3 weeks presence in cauldron means that the package has been
+tested by someone... we can only suppose to...
+
+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/20110625/ea28822f/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006005.html b/zarb-ml/mageia-dev/2011-June/006005.html new file mode 100644 index 000000000..21b3c161b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006005.html @@ -0,0 +1,122 @@ + + + + [Mageia-dev] Backports policy proposal + + + + + + + + + +

[Mageia-dev] Backports policy proposal

+ Angelo Naselli + anaselli at linux.it +
+ Sat Jun 25 15:07:23 CEST 2011 +

+
+ +
In data venerdì 24 giugno 2011 08:30:15, Maarten Vanraes ha scritto:
+> Op vrijdag 24 juni 2011 02:10:14 schreef Michael Scherer:
+> [...]
+> 
+> > Another rule that we could add is that cauldron should always be newer
+> > than backports, in order to ensure upgradability. The same goes for n-2
+> > and n-1 release.
+> > While this seems innocent, do not forget this will have a impact when we
+> > do the version freeze.
+> 
+> [..]
+> 
+> This seems hard to enforce... i can imagine if you make backport, it has
+> essentially the same version as in cauldron, i can think that there is a
+> few spec file changes that are only for backports, and thus the release
+> becomes newer than the one in cauldron
+I'm confused :/
+%mkrel was born to avoid that.... am i worng?
+
+-- 
+	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/20110625/ed6c9779/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006006.html b/zarb-ml/mageia-dev/2011-June/006006.html new file mode 100644 index 000000000..da2d9ba33 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006006.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] Backports policy proposal + + + + + + + + + +

[Mageia-dev] Backports policy proposal

+ Angelo Naselli + anaselli at linux.it +
+ Sat Jun 25 15:08:58 CEST 2011 +

+
+ +
In data venerdì 24 giugno 2011 16:19:45, Buchan Milne ha scritto:
+> Sorry, but a number of my packages were regularly backported, and I never 
+> needed cooker to be older ...
++1, i just had problem when the pacakges where backported into 2010.1 and
+that broke the upgrade to mageia 1...
+-- 
+	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/20110625/b64c10a5/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006007.html b/zarb-ml/mageia-dev/2011-June/006007.html new file mode 100644 index 000000000..2cc420c2c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006007.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] Backports policy proposal + + + + + + + + + +

[Mageia-dev] Backports policy proposal

+ Balcaen John + mikala at mageia.org +
+ Sat Jun 25 15:27:01 CEST 2011 +

+
+ +
Le samedi 25 juin 2011 10:08:58, Angelo Naselli a écrit :
+> In data venerdì 24 giugno 2011 16:19:45, Buchan Milne ha scritto:
+> > Sorry, but a number of my packages were regularly backported, and I never 
+> > needed cooker to be older ...
+> +1, i just had problem when the pacakges where backported into 2010.1 and
+> that broke the upgrade to mageia 1...
+
+Well here it just mean we probably failed to check backports package :/
+
+-- 
+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-June/006008.html b/zarb-ml/mageia-dev/2011-June/006008.html new file mode 100644 index 000000000..f7c1ecf6b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006008.html @@ -0,0 +1,115 @@ + + + + [Mageia-dev] Backports policy proposal + + + + + + + + + +

[Mageia-dev] Backports policy proposal

+ Angelo Naselli + anaselli at linux.it +
+ Sat Jun 25 15:52:52 CEST 2011 +

+
+ +
In data sabato 25 giugno 2011 15:27:01, Balcaen John ha scritto:
+> Le samedi 25 juin 2011 10:08:58, Angelo Naselli a écrit :
+> > In data venerdì 24 giugno 2011 16:19:45, Buchan Milne ha scritto:
+> > > Sorry, but a number of my packages were regularly backported, and I
+> > > never needed cooker to be older ...
+> > 
+> > +1, i just had problem when the pacakges where backported into 2010.1 and
+> > that broke the upgrade to mageia 1...
+> 
+> Well here it just mean we probably failed to check backports package :/
+Well indeed i've realized later, i should have been carefull in backporting 
+2010.1... but 2010.1 is not mageia 1 and mag2 should upgrade mga1...
+even if i have some doubt after mageia 9 (mga9->mga10) ...
+
+
+-- 
+	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/20110625/59f35135/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006009.html b/zarb-ml/mageia-dev/2011-June/006009.html new file mode 100644 index 000000000..1e55bfa47 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006009.html @@ -0,0 +1,135 @@ + + + + [Mageia-dev] No sound with Soundblaster in Mageia 1 + + + + + + + + + +

[Mageia-dev] No sound with Soundblaster in Mageia 1

+ Marcello Anni + marcello.anni at alice.it +
+ Sat Jun 25 18:07:00 CEST 2011 +

+
+ +
hi all,
+
+can anyone take a look at this bug? it is the first bug filled by one of our 
+italian community users, i proposed him to fill and i don't want to  make a 
+poor showing : )
+
+https://bugs.mageia.org/show_bug.cgi?id=1902
+
+
+cheers,
+Marcello
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006010.html b/zarb-ml/mageia-dev/2011-June/006010.html new file mode 100644 index 000000000..4add0cbfa --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006010.html @@ -0,0 +1,168 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Samuel Verschelde + stormi at laposte.net +
+ Sat Jun 25 19:33:15 CEST 2011 +

+
+ +
Le vendredi 24 juin 2011 21:39:51, Ahmad Samir a écrit :
+> On 24 June 2011 02:09, Michael Scherer <misc at zarb.org> wrote:
+> > Hi,
+> > 
+> > as said in the thread of firefox 5, and in the meeting of packager
+> > sooner this week, this is the first mail about backports ( on 3 ).
+> > 
+> > So here is the proposal of a process, based on the feedback of people,
+> > and the idea of some packagers ( mainly stormi ).
+> > 
+> > 
+> > - Someone request a backport ( by bugzilla, by madb, by a email, by
+> > taking a packager family in hostage, whatever ). I would prefer use
+> > bugzilla but this may not be very user friendly, or too heavy.
+> 
+> How would the packager get notified of backports requests via madb?
+
+There are several options :
+- option 1 : maintainers prefer to have all backports requests in bugzilla. 
+Madb will then create backports requests via XML-RPC, with the original 
+reporter in CC maybe, and regularly watch bug report status. This will be 
+extra work on madb's side and force those users (who maybe don't know how to 
+use bugzilla) to use 1 tool for the request and a different tool for testing 
+reports, but why not.
+- option 2 : maintainers are OK to use bugzilla for bugs and madb for package 
+requests => madb will query the maintainers database and notify the 
+maintainer(s) by mail. It could, like bugzilla, send notifications to a ML too, 
+and provide a simple yet sufficient tracking system (status, comments).
+
+> 
+> Would you elaborate on how bugzilla is heavy for a backports request?
+
+Heavy I don't know, but I think that we can give users a better tool to 
+request backports, see what backports already have been requested, etc.
+
+> 
+> > - a packager decide to do it. Based on the policy ( outlined in another
+> > mail ), and maybe seeing with the maintainer first about that for non
+> > trivial applications, the backport can be done, or not. The criterias
+> > for being backported or not are not important to the process, just
+> > assume that they exist for now ( and look at next mail ). So based on
+> > criteria, someone say "it can be backported, so I do it".
+> 
+> [...]
+> 
+> > - I am not sure on this part, but basically, we have 2 choices :
+> >  - the packager take the cauldron package and push to backport testing
+> >  - the packager move the cauldron package in svn to backport, and there
+> > send it to backport testing.
+> > 
+> > Proposal 1 mean less work duplication, but proposal 2 let us do more
+> > customization.
+> 
+> Option 1 doesn't only mean not duplicating work, but also that the the
+> spec in backports svn isn't ever out-dated; the only reason I see a
+> package being in stable distro SVN is if it's in /release|updates, not
+> backports...
+
+I'm not sure I understand your point. What do you mean with out-dated specs in 
+backports ? 
+I favor option 2 (with all needed useful shortcuts in mgarepo and BS to make 
+it simple for packagers) because it allows to cope with the following 
+situation :
+- foo is in version 1.2.2 in release|updates
+- foo is in version 2.0alpha in cauldron, full of bugs but hopefully ready for 
+the next stable release
+- the latest release in the 1.x branch, 1.3.0, brings many features requested 
+by some users, we want to provide it as a backport : with option 1 we can't, 
+with option 2 we can. 
+
+or : 
+- foo is in version 1.2.2 in release|updates
+- foo is in version 2.0alpha in cauldron, full of bugs but hopefully ready for 
+the next stable release
+- we had backported version 1.2.6 before switching to 2.0alpha in cauldron
+- the backported version 1.2.6 has a big bug we hadn't spotted during tests 
+and we want to fix in the backport : with option 1 we can't, with option 2 we 
+can.
+
+So, for me, this is definitely option 2.
+
+However, I think it must be made a painless as possible to packagers :
+- in the common case, allow to submit directly from cauldron to the backports 
+media, but let the BS detect that and automatically do the SVN copy part.
+- for the situations I described above, work with the backport branch 
+similarly as we work on updates (technically speaking : SVN, BS...). 
+
+
+> 
+> > if the package doesn't build, the packager fix ( or drop the idea if
+> > this requires too much work )
+> > 
+> > - the packager send requesting feedback about the backport from the
+> > people who requested it, and test it as well.
+> 
+> Probably off-topic, but how will that work with madb? i.e. how will
+> the maintainer get the feedback?
+
+I partially answered above : either via bugzilla, or via a simple tracking 
+system included in madb for that need. It will depend on the chosen process, 
+we'll try to adapt the tool to the situation.
+
+
+Best regards
+
+Samuel Verschelde
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006011.html b/zarb-ml/mageia-dev/2011-June/006011.html new file mode 100644 index 000000000..132b11632 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006011.html @@ -0,0 +1,77 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Sat Jun 25 19:54:03 CEST 2011 +

+
+ +
Op zaterdag 25 juni 2011 19:33:15 schreef Samuel Verschelde:
+[...]
+> However, I think it must be made a painless as possible to packagers :
+> - in the common case, allow to submit directly from cauldron to the
+> backports media, but let the BS detect that and automatically do the SVN
+> copy part. 
+> - for the situations I described above, work with the backport
+> branch similarly as we work on updates (technically speaking : SVN,
+> BS...).
+[...]
+
+i would prefer to keep things separate, an mgarepo switch command or even a 
+mgarepo backport shortcut, then current branch/revision/whatever could be made 
+into backports or something...
+and from then on, you can submit like "normal"
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006012.html b/zarb-ml/mageia-dev/2011-June/006012.html new file mode 100644 index 000000000..a2c110b28 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006012.html @@ -0,0 +1,117 @@ + + + + [Mageia-dev] Backports policy proposal + + + + + + + + + +

[Mageia-dev] Backports policy proposal

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Sat Jun 25 20:55:27 CEST 2011 +

+
+ +
On 25 June 2011 15:52, Angelo Naselli <anaselli at linux.it> wrote:
+> In data sabato 25 giugno 2011 15:27:01, Balcaen John ha scritto:
+>> Le samedi 25 juin 2011 10:08:58, Angelo Naselli a écrit :
+>> > In data venerdì 24 giugno 2011 16:19:45, Buchan Milne ha scritto:
+>> > > Sorry, but a number of my packages were regularly backported, and I
+>> > > never needed cooker to be older ...
+>> >
+>> > +1, i just had problem when the pacakges where backported into 2010.1 and
+>> > that broke the upgrade to mageia 1...
+>>
+>> Well here it just mean we probably failed to check backports package :/
+> Well indeed i've realized later, i should have been carefull in backporting
+> 2010.1... but 2010.1 is not mageia 1 and mag2 should upgrade mga1...
+> even if i have some doubt after mageia 9 (mga9->mga10) ...
+>
+>
+
+mga10 is higher than mga9:
+$ rpmdev-vercmp mga9 mga10
+mga9 < mga10
+
+> --
+>        Angelo
+>
+
+
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006013.html b/zarb-ml/mageia-dev/2011-June/006013.html new file mode 100644 index 000000000..13c507503 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006013.html @@ -0,0 +1,205 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Sat Jun 25 21:22:20 CEST 2011 +

+
+ +
On 25 June 2011 19:33, Samuel Verschelde <stormi at laposte.net> wrote:
+> Le vendredi 24 juin 2011 21:39:51, Ahmad Samir a écrit :
+>> On 24 June 2011 02:09, Michael Scherer <misc at zarb.org> wrote:
+>> > Hi,
+>> >
+>> > as said in the thread of firefox 5, and in the meeting of packager
+>> > sooner this week, this is the first mail about backports ( on 3 ).
+>> >
+>> > So here is the proposal of a process, based on the feedback of people,
+>> > and the idea of some packagers ( mainly stormi ).
+>> >
+>> >
+>> > - Someone request a backport ( by bugzilla, by madb, by a email, by
+>> > taking a packager family in hostage, whatever ). I would prefer use
+>> > bugzilla but this may not be very user friendly, or too heavy.
+>>
+>> How would the packager get notified of backports requests via madb?
+>
+> There are several options :
+> - option 1 : maintainers prefer to have all backports requests in bugzilla.
+> Madb will then create backports requests via XML-RPC, with the original
+> reporter in CC maybe, and regularly watch bug report status. This will be
+> extra work on madb's side and force those users (who maybe don't know how to
+> use bugzilla) to use 1 tool for the request and a different tool for testing
+> reports, but why not.
+> - option 2 : maintainers are OK to use bugzilla for bugs and madb for package
+> requests => madb will query the maintainers database and notify the
+> maintainer(s) by mail. It could, like bugzilla, send notifications to a ML too,
+> and provide a simple yet sufficient tracking system (status, comments).
+>
+
+[...]
+
+>>
+>> Would you elaborate on how bugzilla is heavy for a backports request?
+>
+> Heavy I don't know, but I think that we can give users a better tool to
+> request backports, see what backports already have been requested, etc.
+>
+
+Yes, but what's wrong with bugzilla and better in the other tool?
+
+>>
+>> > - a packager decide to do it. Based on the policy ( outlined in another
+>> > mail ), and maybe seeing with the maintainer first about that for non
+>> > trivial applications, the backport can be done, or not. The criterias
+>> > for being backported or not are not important to the process, just
+>> > assume that they exist for now ( and look at next mail ). So based on
+>> > criteria, someone say "it can be backported, so I do it".
+>>
+>> [...]
+>>
+>> > - I am not sure on this part, but basically, we have 2 choices :
+>> >  - the packager take the cauldron package and push to backport testing
+>> >  - the packager move the cauldron package in svn to backport, and there
+>> > send it to backport testing.
+>> >
+>> > Proposal 1 mean less work duplication, but proposal 2 let us do more
+>> > customization.
+>>
+>> Option 1 doesn't only mean not duplicating work, but also that the the
+>> spec in backports svn isn't ever out-dated; the only reason I see a
+>> package being in stable distro SVN is if it's in /release|updates, not
+>> backports...
+>
+> I'm not sure I understand your point. What do you mean with out-dated specs in
+> backports ?
+
+The cauldron one got some changes/patches, the one in backports didn't
+get them => outdated.
+
+> I favor option 2 (with all needed useful shortcuts in mgarepo and BS to make
+> it simple for packagers) because it allows to cope with the following
+> situation :
+> - foo is in version 1.2.2 in release|updates
+> - foo is in version 2.0alpha in cauldron, full of bugs but hopefully ready for
+> the next stable release
+> - the latest release in the 1.x branch, 1.3.0, brings many features requested
+> by some users, we want to provide it as a backport : with option 1 we can't,
+> with option 2 we can.
+>
+> or :
+> - foo is in version 1.2.2 in release|updates
+> - foo is in version 2.0alpha in cauldron, full of bugs but hopefully ready for
+> the next stable release
+> - we had backported version 1.2.6 before switching to 2.0alpha in cauldron
+> - the backported version 1.2.6 has a big bug we hadn't spotted during tests
+> and we want to fix in the backport : with option 1 we can't, with option 2 we
+> can.
+>
+> So, for me, this is definitely option 2.
+>
+
+Good point, but now we're not really talking about backports any more,
+I think; we're talking about having a second "updates" repo but with
+version bumps allowed, which sort of negates the backports repos
+criteria that was used in mdv all those years.... I can't help but
+think that in some cases that will be promising support that we can't
+afford to give to begin with.
+
+The whole "backports isn't officially supported" was/is a sort of CYA*
+motto, like the "the beverage you're about to drink is hot" on
+Starbucks coffee cups (if the customer doesn't already know coffee is
+served hot, then there's something fundamentally wrong somewhere in
+his head), it's just there so that when someone sues, they have a way
+out, that's all it is.
+
+I've seen backported packages get repushed with fixes when needed,
+that's support AFAICT.
+
+* CYA == cover your ass.
+
+> However, I think it must be made a painless as possible to packagers :
+> - in the common case, allow to submit directly from cauldron to the backports
+> media, but let the BS detect that and automatically do the SVN copy part.
+> - for the situations I described above, work with the backport branch
+> similarly as we work on updates (technically speaking : SVN, BS...).
+>
+>
+>>
+>> > if the package doesn't build, the packager fix ( or drop the idea if
+>> > this requires too much work )
+>> >
+>> > - the packager send requesting feedback about the backport from the
+>> > people who requested it, and test it as well.
+>>
+>> Probably off-topic, but how will that work with madb? i.e. how will
+>> the maintainer get the feedback?
+>
+> I partially answered above : either via bugzilla, or via a simple tracking
+> system included in madb for that need. It will depend on the chosen process,
+> we'll try to adapt the tool to the situation.
+>
+>
+> Best regards
+>
+> Samuel Verschelde
+>
+
+
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006014.html b/zarb-ml/mageia-dev/2011-June/006014.html new file mode 100644 index 000000000..8b5247339 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006014.html @@ -0,0 +1,199 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Samuel Verschelde + stormi at laposte.net +
+ Sat Jun 25 22:15:37 CEST 2011 +

+
+ +
Le samedi 25 juin 2011 21:22:20, Ahmad Samir a écrit :
+> On 25 June 2011 19:33, Samuel Verschelde <stormi at laposte.net> wrote:
+> > Le vendredi 24 juin 2011 21:39:51, Ahmad Samir a écrit :
+> >> On 24 June 2011 02:09, Michael Scherer <misc at zarb.org> wrote:
+> >> > - Someone request a backport ( by bugzilla, by madb, by a email, by
+> >> > taking a packager family in hostage, whatever ). I would prefer use
+> >> > bugzilla but this may not be very user friendly, or too heavy.
+> >> 
+> >> How would the packager get notified of backports requests via madb?
+> > 
+> > There are several options :
+> > - option 1 : maintainers prefer to have all backports requests in
+> > bugzilla. Madb will then create backports requests via XML-RPC, with the
+> > original reporter in CC maybe, and regularly watch bug report status.
+> > This will be extra work on madb's side and force those users (who maybe
+> > don't know how to use bugzilla) to use 1 tool for the request and a
+> > different tool for testing reports, but why not.
+> > - option 2 : maintainers are OK to use bugzilla for bugs and madb for
+> > package requests => madb will query the maintainers database and notify
+> > the maintainer(s) by mail. It could, like bugzilla, send notifications
+> > to a ML too, and provide a simple yet sufficient tracking system
+> > (status, comments).
+> 
+> [...]
+> 
+> >> Would you elaborate on how bugzilla is heavy for a backports request?
+> > 
+> > Heavy I don't know, but I think that we can give users a better tool to
+> > request backports, see what backports already have been requested, etc.
+> 
+> Yes, but what's wrong with bugzilla and better in the other tool?
+
+Bugzilla is an issue tracker, and is centered on that concept. I think that a 
+simple "request backport" button in a package database browsing application 
+can be easier and more efficient, in that the "need" will be more easily 
+transmitted from the user to the packager. The backports requests we get today  
+(and got back in mandriva) don't represent the majority of needs. I'd like to 
+see what happens if users have a dead simple way to request them.
+
+Plus, as we want to transform "requester" into "tester", the more requests we 
+can get, the more users we have a chance to turn into testers... And maybe 
+more 
+
+I'm almost sure madb will have such a "request backport" button. It was 
+planned in the original specs. There's still to decide what this button does : 
+option 1 or option 2 above, or even (but not my choice) a redirect to a 
+prefilled form in bugzilla.
+
+There's one point that for me favors the use of a dedicated tool : the fact 
+that several users can request the same backport. Madb will be store existing 
+requests and associate new requesters to them if needed. This way :
+- we will have means to see the most demanded backports
+- there will be only one (if any) associated bugzilla request, and once madb 
+detects that the backport is available for testing, it will notify all 
+associated users, and once available for good too.
+I think it's easier this way than asking to users to "check if there's already 
+a backport request for this program and add yourself in CC to the bug report 
+if there's one, otherwise create a new backport request".
+
+> 
+> >> > - a packager decide to do it. Based on the policy ( outlined in
+> >> > another mail ), and maybe seeing with the maintainer first about that
+> >> > for non trivial applications, the backport can be done, or not. The
+> >> > criterias for being backported or not are not important to the
+> >> > process, just assume that they exist for now ( and look at next mail
+> >> > ). So based on criteria, someone say "it can be backported, so I do
+> >> > it".
+> >> 
+> >> [...]
+> >> 
+> >> > - I am not sure on this part, but basically, we have 2 choices :
+> >> >  - the packager take the cauldron package and push to backport testing
+> >> >  - the packager move the cauldron package in svn to backport, and
+> >> > there send it to backport testing.
+> >> > 
+> >> > Proposal 1 mean less work duplication, but proposal 2 let us do more
+> >> > customization.
+> >> 
+> >> Option 1 doesn't only mean not duplicating work, but also that the the
+> >> spec in backports svn isn't ever out-dated; the only reason I see a
+> >> package being in stable distro SVN is if it's in /release|updates, not
+> >> backports...
+> > 
+> > I'm not sure I understand your point. What do you mean with out-dated
+> > specs in backports ?
+> 
+> The cauldron one got some changes/patches, the one in backports didn't
+> get them => outdated.
+
+I see. You mean that once the backport has its own branch, updating it from 
+cauldron becomes difficult because each branch lives its own life.
+
+My proposal that the BS allows a direct jump from cauldron to backport, taking 
+care by itself of the SVN copying part can solve this problem I think.
+
+> 
+> > I favor option 2 (with all needed useful shortcuts in mgarepo and BS to
+> > make it simple for packagers) because it allows to cope with the
+> > following situation :
+> > - foo is in version 1.2.2 in release|updates
+> > - foo is in version 2.0alpha in cauldron, full of bugs but hopefully
+> > ready for the next stable release
+> > - the latest release in the 1.x branch, 1.3.0, brings many features
+> > requested by some users, we want to provide it as a backport : with
+> > option 1 we can't, with option 2 we can.
+> > 
+> > or :
+> > - foo is in version 1.2.2 in release|updates
+> > - foo is in version 2.0alpha in cauldron, full of bugs but hopefully
+> > ready for the next stable release
+> > - we had backported version 1.2.6 before switching to 2.0alpha in
+> > cauldron - the backported version 1.2.6 has a big bug we hadn't spotted
+> > during tests and we want to fix in the backport : with option 1 we
+> > can't, with option 2 we can.
+> > 
+> > So, for me, this is definitely option 2.
+> 
+> Good point, but now we're not really talking about backports any more,
+> I think; we're talking about having a second "updates" repo but with
+> version bumps allowed, which sort of negates the backports repos
+> criteria that was used in mdv all those years.... 
+
+I'm not sure. See misc's backport policy proposal : it's very close to 
+Mandriva's. 
+
+> I can't help but
+> think that in some cases that will be promising support that we can't
+> afford to give to begin with.
+
+I'd like us to try our best then, but remember that we're also trying to use 
+backport and software requests as a catalyst to get more testers and maybe 
+even more packagers. 
+Maybe even (let's dream :)) we will become known as a distribution where it's 
+easy to get newer versions of software and attract more users, which we will 
+try to turn into contributers in the end and then just rule the world :P
+
+Samuel
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006015.html b/zarb-ml/mageia-dev/2011-June/006015.html new file mode 100644 index 000000000..db90879ff --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006015.html @@ -0,0 +1,231 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Sat Jun 25 22:53:03 CEST 2011 +

+
+ +
On 25 June 2011 22:15, Samuel Verschelde <stormi at laposte.net> wrote:
+> Le samedi 25 juin 2011 21:22:20, Ahmad Samir a écrit :
+>> On 25 June 2011 19:33, Samuel Verschelde <stormi at laposte.net> wrote:
+>> > Le vendredi 24 juin 2011 21:39:51, Ahmad Samir a écrit :
+>> >> On 24 June 2011 02:09, Michael Scherer <misc at zarb.org> wrote:
+>> >> > - Someone request a backport ( by bugzilla, by madb, by a email, by
+>> >> > taking a packager family in hostage, whatever ). I would prefer use
+>> >> > bugzilla but this may not be very user friendly, or too heavy.
+>> >>
+>> >> How would the packager get notified of backports requests via madb?
+>> >
+>> > There are several options :
+>> > - option 1 : maintainers prefer to have all backports requests in
+>> > bugzilla. Madb will then create backports requests via XML-RPC, with the
+>> > original reporter in CC maybe, and regularly watch bug report status.
+>> > This will be extra work on madb's side and force those users (who maybe
+>> > don't know how to use bugzilla) to use 1 tool for the request and a
+>> > different tool for testing reports, but why not.
+>> > - option 2 : maintainers are OK to use bugzilla for bugs and madb for
+>> > package requests => madb will query the maintainers database and notify
+>> > the maintainer(s) by mail. It could, like bugzilla, send notifications
+>> > to a ML too, and provide a simple yet sufficient tracking system
+>> > (status, comments).
+>>
+>> [...]
+>>
+>> >> Would you elaborate on how bugzilla is heavy for a backports request?
+>> >
+>> > Heavy I don't know, but I think that we can give users a better tool to
+>> > request backports, see what backports already have been requested, etc.
+>>
+>> Yes, but what's wrong with bugzilla and better in the other tool?
+>
+> Bugzilla is an issue tracker, and is centered on that concept. I think that a
+> simple "request backport" button in a package database browsing application
+> can be easier and more efficient, in that the "need" will be more easily
+> transmitted from the user to the packager. The backports requests we get today
+> (and got back in mandriva) don't represent the majority of needs. I'd like to
+> see what happens if users have a dead simple way to request them.
+>
+
+You want to interface for users, so that they don't have to deal with
+a 1minute-to-fill bug report to request a backport... that's your
+prerogative, I don' have a problem with that as long as it works.
+
+> Plus, as we want to transform "requester" into "tester", the more requests we
+> can get, the more users we have a chance to turn into testers... And maybe
+> more
+>
+
+"Tester" will have to use bugzilla, as that's the designated tool to
+contact devs/packagers... so maybe it's a good chance users become
+familiar with bugzilla?
+
+> I'm almost sure madb will have such a "request backport" button. It was
+> planned in the original specs. There's still to decide what this button does :
+> option 1 or option 2 above, or even (but not my choice) a redirect to a
+> prefilled form in bugzilla.
+>
+> There's one point that for me favors the use of a dedicated tool : the fact
+> that several users can request the same backport. Madb will be store existing
+> requests and associate new requesters to them if needed. This way :
+> - we will have means to see the most demanded backports
+> - there will be only one (if any) associated bugzilla request, and once madb
+> detects that the backport is available for testing, it will notify all
+> associated users, and once available for good too.
+> I think it's easier this way than asking to users to "check if there's already
+> a backport request for this program and add yourself in CC to the bug report
+> if there's one, otherwise create a new backport request".
+>
+
+FWIW, such kind of duplicate reports is easy to spot and marking one
+bug as a dupe of another adds the user to CC automatically.
+
+Again, I am not with or against using madb, simply because I've not
+seen in action and can't judge it.
+
+>>
+>> >> > - a packager decide to do it. Based on the policy ( outlined in
+>> >> > another mail ), and maybe seeing with the maintainer first about that
+>> >> > for non trivial applications, the backport can be done, or not. The
+>> >> > criterias for being backported or not are not important to the
+>> >> > process, just assume that they exist for now ( and look at next mail
+>> >> > ). So based on criteria, someone say "it can be backported, so I do
+>> >> > it".
+>> >>
+>> >> [...]
+>> >>
+>> >> > - I am not sure on this part, but basically, we have 2 choices :
+>> >> >  - the packager take the cauldron package and push to backport testing
+>> >> >  - the packager move the cauldron package in svn to backport, and
+>> >> > there send it to backport testing.
+>> >> >
+>> >> > Proposal 1 mean less work duplication, but proposal 2 let us do more
+>> >> > customization.
+>> >>
+>> >> Option 1 doesn't only mean not duplicating work, but also that the the
+>> >> spec in backports svn isn't ever out-dated; the only reason I see a
+>> >> package being in stable distro SVN is if it's in /release|updates, not
+>> >> backports...
+>> >
+>> > I'm not sure I understand your point. What do you mean with out-dated
+>> > specs in backports ?
+>>
+>> The cauldron one got some changes/patches, the one in backports didn't
+>> get them => outdated.
+>
+> I see. You mean that once the backport has its own branch, updating it from
+> cauldron becomes difficult because each branch lives its own life.
+>
+> My proposal that the BS allows a direct jump from cauldron to backport, taking
+> care by itself of the SVN copying part can solve this problem I think.
+>
+>>
+>> > I favor option 2 (with all needed useful shortcuts in mgarepo and BS to
+>> > make it simple for packagers) because it allows to cope with the
+>> > following situation :
+>> > - foo is in version 1.2.2 in release|updates
+>> > - foo is in version 2.0alpha in cauldron, full of bugs but hopefully
+>> > ready for the next stable release
+>> > - the latest release in the 1.x branch, 1.3.0, brings many features
+>> > requested by some users, we want to provide it as a backport : with
+>> > option 1 we can't, with option 2 we can.
+>> >
+>> > or :
+>> > - foo is in version 1.2.2 in release|updates
+>> > - foo is in version 2.0alpha in cauldron, full of bugs but hopefully
+>> > ready for the next stable release
+>> > - we had backported version 1.2.6 before switching to 2.0alpha in
+>> > cauldron - the backported version 1.2.6 has a big bug we hadn't spotted
+>> > during tests and we want to fix in the backport : with option 1 we
+>> > can't, with option 2 we can.
+>> >
+>> > So, for me, this is definitely option 2.
+>>
+>> Good point, but now we're not really talking about backports any more,
+>> I think; we're talking about having a second "updates" repo but with
+>> version bumps allowed, which sort of negates the backports repos
+>> criteria that was used in mdv all those years....
+>
+> I'm not sure. See misc's backport policy proposal : it's very close to
+> Mandriva's.
+>
+>> I can't help but
+>> think that in some cases that will be promising support that we can't
+>> afford to give to begin with.
+>
+> I'd like us to try our best then, but remember that we're also trying to use
+> backport and software requests as a catalyst to get more testers and maybe
+> even more packagers.
+> Maybe even (let's dream :)) we will become known as a distribution where it's
+> easy to get newer versions of software and attract more users, which we will
+> try to turn into contributers in the end and then just rule the world :P
+>
+> Samuel
+>
+
+IIUC, the whole idea behind backports, is having an easy way for
+packagers to offer new versions of desktop application packages for
+users, emphasis on "easy"; based on the cauldron (cooker back in the
+day) SVN, the packager submits a new package to backports. That worked
+most of the times. I've seen anyone giving numbers/statistics on how
+many backports actually didn't work for the users.
+
+So, yes, I am all for improving the process, but without complicating
+it too much.
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006016.html b/zarb-ml/mageia-dev/2011-June/006016.html new file mode 100644 index 000000000..49b4e3b42 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006016.html @@ -0,0 +1,116 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Sat Jun 25 23:15:30 CEST 2011 +

+
+ +
2011/6/25 Ahmad Samir <ahmadsamir3891 at gmail.com>:
+> On 25 June 2011 22:15, Samuel Verschelde <stormi at laposte.net> wrote:
+>> Le samedi 25 juin 2011 21:22:20, Ahmad Samir a écrit :
+>>> On 25 June 2011 19:33, Samuel Verschelde <stormi at laposte.net> wrote:
+>>> > Le vendredi 24 juin 2011 21:39:51, Ahmad Samir a écrit :
+>>> >> On 24 June 2011 02:09, Michael Scherer <misc at zarb.org> wrote:
+>>> >> > - Someone request a backport ( by bugzilla, by madb, by a email, by
+>>> >> > taking a packager family in hostage, whatever ). I would prefer use
+>>> >> > bugzilla but this may not be very user friendly, or too heavy.
+>>> >>
+>>> >> How would the packager get notified of backports requests via madb?
+>>> >
+>>> > There are several options :
+>>> > - option 1 : maintainers prefer to have all backports requests in
+>>> > bugzilla. Madb will then create backports requests via XML-RPC, with the
+>>> > original reporter in CC maybe, and regularly watch bug report status.
+>>> > This will be extra work on madb's side and force those users (who maybe
+>>> > don't know how to use bugzilla) to use 1 tool for the request and a
+>>> > different tool for testing reports, but why not.
+>>> > - option 2 : maintainers are OK to use bugzilla for bugs and madb for
+>>> > package requests => madb will query the maintainers database and notify
+>>> > the maintainer(s) by mail. It could, like bugzilla, send notifications
+>>> > to a ML too, and provide a simple yet sufficient tracking system
+>>> > (status, comments).
+>>>
+>>> [...]
+>>>
+>>> >> Would you elaborate on how bugzilla is heavy for a backports request?
+>>> >
+>>> > Heavy I don't know, but I think that we can give users a better tool to
+>>> > request backports, see what backports already have been requested, etc.
+>>>
+>>> Yes, but what's wrong with bugzilla and better in the other tool?
+>>
+>> Bugzilla is an issue tracker, and is centered on that concept. I think that a
+>> simple "request backport" button in a package database browsing application
+>> can be easier and more efficient, in that the "need" will be more easily
+>> transmitted from the user to the packager. The backports requests we get today
+>> (and got back in mandriva) don't represent the majority of needs. I'd like to
+>> see what happens if users have a dead simple way to request them.
+>>
+>
+> You want to interface for users, so that they don't have to deal with
+> a 1minute-to-fill bug report to request a backport... that's your
+> prerogative, I don' have a problem with that as long as it works.
+
+The "Request Backport Button" could be a solution for non-english
+speakers. They can not use Bugzilla because they can not write in
+English to make their request understood, but they can find the
+package name in a database and understand the function of a button
+which reads "Backport".
+
+-- 
+wobo
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006017.html b/zarb-ml/mageia-dev/2011-June/006017.html new file mode 100644 index 000000000..b51348c5a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006017.html @@ -0,0 +1,76 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Dexter Morgan + dmorganec at gmail.com +
+ Sat Jun 25 23:26:01 CEST 2011 +

+
+ +
On Sat, Jun 25, 2011 at 11:15 PM, Wolfgang Bornath
+<molch.b at googlemail.com> wrote:
+> The "Request Backport Button" could be a solution for non-english
+> speakers. They can not use Bugzilla because they can not write in
+> English to make their request understood, but they can find the
+> package name in a database and understand the function of a button
+> which reads "Backport".
+>
+> --
+> wobo
+>
+
+well used i think this can be really good.
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006018.html b/zarb-ml/mageia-dev/2011-June/006018.html new file mode 100644 index 000000000..82607167b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006018.html @@ -0,0 +1,122 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Michael Scherer + misc at zarb.org +
+ Sun Jun 26 00:16:59 CEST 2011 +

+
+ +
Le vendredi 24 juin 2011 à 22:39 +0300, Ahmad Samir a écrit :
+> On 24 June 2011 02:09, Michael Scherer <misc at zarb.org> wrote:
+> > Hi,
+> >
+> > as said in the thread of firefox 5, and in the meeting of packager
+> > sooner this week, this is the first mail about backports ( on 3 ).
+> >
+> > So here is the proposal of a process, based on the feedback of people,
+> > and the idea of some packagers ( mainly stormi ).
+> >
+> >
+> > - Someone request a backport ( by bugzilla, by madb, by a email, by
+> > taking a packager family in hostage, whatever ). I would prefer use
+> > bugzilla but this may not be very user friendly, or too heavy.
+> >
+> 
+> Would you elaborate on how bugzilla is heavy for a backports request?
+
+It requires a more formal process, requires to fill a proper bug ( thus
+either requesting more experience, or more work from triaging ). 
+
+While bugzilla would work, I think we could have a more streamlined and
+direct way of requesting backport. Maybe a custom template in bugzilla
+would do the trick.
+
+> > - based on feedback ( ie if the package work or if the packager is
+> > confident ), the packager decide to move it to backport for everybody,
+> > using some stuff similar to rpmctl ( the tool we used to move package at
+> > Mandriva ). The tool would also send notifications.
+> >
+> 
+> The packager decides to move it and he has the necessary privileges to
+> do so? or will he have to request someone from another team to move
+> it?
+
+The packager decide to move.
+
+> > This way :
+> > - packages are not sent untested, thus raising confidence in backports
+> 
+> How many times did backports breaks a user's whole installation? 
+
+Not often. But the issue is not if the system is broken beyond repair,
+as it didn't happen, and would surely not happen with the proposed
+policy. But even if system work, people will perceive backport has being
+unreliable if some of them do not work. 
+
+
+> we
+> always say that backports should mainly be cherry picked, but not
+> enabled all the time... so how does installing a new version of e.g.
+> wine break the user's system when he can easily back out that rpm?
+
+I a not sure that most people realize they can revert. Maybe a easier
+interface to do that could be offered ( along maybe with a tool that
+send feedback on why it did downgrade it ? ).
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006019.html b/zarb-ml/mageia-dev/2011-June/006019.html new file mode 100644 index 000000000..6e63718b1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006019.html @@ -0,0 +1,122 @@ + + + + [Mageia-dev] Backports policy proposal + + + + + + + + + +

[Mageia-dev] Backports policy proposal

+ Michael Scherer + misc at zarb.org +
+ Sun Jun 26 00:34:41 CEST 2011 +

+
+ +
Le vendredi 24 juin 2011 à 17:33 +0300, Anssi Hannula a écrit :
+> On 24.06.2011 03:10, Michael Scherer wrote:
+> > Another rule that we could add is that cauldron should always be newer
+> > than backports, in order to ensure upgradability. The same goes for n-2
+> > and n-1 release.
+> > While this seems innocent, do not forget this will have a impact when we
+> > do the version freeze.
+> 
+> So this will prevent backporting anything to mga1 if it is not in mga2
+> release/updates ?
+
+That's a good question but yes, I would consider such policy.
+Ie, do backport only for the latest supported release.
+
+> Also, I don't see the advantage in preventing backports during freeze.
+> The backports are re-allowed soon anyway, and the upgradeability goes
+> away anyway.
+
+Then if people use mgaonline, it will fail, and then, people will start
+to say "we cannot upgrade distribution" and sooner or later, mgaonline
+will have the same bad reputation that backports had.
+
+
+So either we want mgaonline to be rock solid ( and I think that would be
+a benefit, and that if we managed to do it for mandriva, we can continue
+), or we want to offer backports that will disrupt it, and thus have "if
+you use backport, upgrade will not be supported", which is yet another
+reason for people to not use it.
+
+I do not see how we could win on both, except by limiting backporting to
+make sure system are still upgradable.
+
+Another solution would be some smart upgrader that do enable backports
+for upgrade, without taking everything. And until we see a working piece
+of code doing that, this will not be a solution.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006020.html b/zarb-ml/mageia-dev/2011-June/006020.html new file mode 100644 index 000000000..48d86b123 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006020.html @@ -0,0 +1,139 @@ + + + + [Mageia-dev] Backports policy proposal + + + + + + + + + +

[Mageia-dev] Backports policy proposal

+ Michael Scherer + misc at zarb.org +
+ Sun Jun 26 00:41:44 CEST 2011 +

+
+ +
Le vendredi 24 juin 2011 à 16:20 -0400, andre999 a écrit :
+> Michael Scherer a écrit :
+> >
+> > so :
+> > - cannot be backported if this is not a leaf package, will be revised later
+> > - cannot be backported if the maintainer say "no", but we assume he say "yes" by default
+> > - cannot be backported if it impact the dependency tree too much ( Obsoletes, Provides, etc )
+> > - cannot be backported if the package was just created and is thus basically untested in cauldron
+> 
+> What about corner cases where a potential backport is incompatible with changes introduced in 
+> cauldron ?  Should we leave such packages to third parties ?  (I would tend to say yes.)
+
+Give a more precise example.
+
+> > - must not prevent upgrade to next release
+> 
+> I can see where a backport could be a more recent version than in cauldron for the moment.  Since 
+> that could make the newer version available to users somewhat sooner.  Although by release, 
+> cauldron should have at least as recent a version.  Or should we prohibit this ?
+> (I'm thinking of cases where more recent versions are expected for cauldron before release.)
+
+If we decide to use the spec from cauldron on stable ( as it seems to be
+the sanest way of doing it ), the only way to have a newer version in
+stable than in cauldron would be to have the build broken on cauldron.
+
+If we tolerate this, and if no one fix ( because the person that did the
+upgrade only care about stable release ), we have a broken build.
+
+So forcing the build to be correct on cauldron would be a stronger
+incentive to fix. It seems more desirable to prevent a backport if the
+price to pay is to have a potentially broken cauldron package.
+
+
+> > - strict requires between backported packages, in order to make sure they can be cherrypicked ( ie, someone enable backports, install, remove backports )
+> 
+> It would be best if one can select individual backports without activating the backports 
+> repositories, as is now the case.
+> So only the brave (wanting all backports) need activate the backports repositories.
+> 
+> Agree with everything, except as noted.
+> 
+> It might be useful to list major packages that should never be backported.
+> I like the idea of tagging backports in the package name, as well as in the package database.
+
+We cannot tag in the packages database. Yum do it with a separate sqlite
+file, afaik.
+
+And tagging in the package name would be quite tricky to do if we need
+to play with %mkrel and release.
+
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006021.html b/zarb-ml/mageia-dev/2011-June/006021.html new file mode 100644 index 000000000..fe771ff35 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006021.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] Backports policy proposal + + + + + + + + + +

[Mageia-dev] Backports policy proposal

+ Michael Scherer + misc at zarb.org +
+ Sun Jun 26 00:43:22 CEST 2011 +

+
+ +
Le samedi 25 juin 2011 à 15:05 +0200, Angelo Naselli a écrit :
+> In data venerdì 24 giugno 2011 02:10:14, Michael Scherer ha scritto:
+> > - cannot be backported if the package was just created and is thus
+> > basically untested in cauldron
+> Well even if i could agree with that, i cannot see how can we ensure that
+> a 2-3 weeks presence in cauldron means that the package has been
+> tested by someone... we can only suppose to...
+
+a 0 week presence basically mean no test, so it can only improve the
+chance of being tested. 
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006022.html b/zarb-ml/mageia-dev/2011-June/006022.html new file mode 100644 index 000000000..e0e900272 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006022.html @@ -0,0 +1,169 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ Michael Scherer + misc at zarb.org +
+ Sun Jun 26 01:04:38 CEST 2011 +

+
+ +
Le vendredi 24 juin 2011 à 18:13 -0400, andre999 a écrit :
+> Michael Scherer a écrit :
+> >
+> > This mail is about handling update on the backport repository. Either
+> > new version, or bugfix, or security upgrade.
+> >
+> > Everybody was focused on "should we do patch, or should we do more
+> > backport" issue, but the real problem is not really here.
+> >
+> > First, we have to decide what kind of update do we want to see, among
+> > the 3 types :
+> > - bugfixes
+> > - security bug fixes,
+> > - new version
+> 
+> For bugfixes and new versions, that are not known to have security implications, let's treat them 
+> essentially as new backports.
+> If the bug were locally reported, the reporter would be involved in the testing.
+> Such updates would be installed as any other backport.
+> However I would favour notifying those who have installed previous versions of these backports, of 
+> the availability of newer versions.
+
+The question is "how". 
+
+> Maybe even having a backports updates category.  (But not to be installed automatically by default.)
+> 
+> For security issues, I'm not sure that it is important how we find out.
+> As far as responsibility, I think the main responibility should be by the packager, but it could be 
+> useful for the security team to monitor it, to find an alternate packager if necessary.
+> (Presumably from those who have tested or installed the package.)
+> (I don't know who monitors security issues now, I just assume the security team.)
+> 
+> However I think that such packages should be tested as normally for backports, and then treated as 
+> security updates, to be automatically applied.
+
+If we place it in a repository that is enabled by default, we will
+basically do a version upgrade for every people that have it enabled.
+
+If this is updates, this would violate our own policy.
+
+If we place in backports, it is not enabled by default.
+
+> This is because those who have installed the backport in question have decided to accept a higher 
+> degree of risk.  However a security issue can be a much greater risk, and is something that is 
+> normally resolved automatically.  So by installing a security bug fix automatically for a backport, 
+> we are essentially maintaining the level of risk already assumed by the user.
+
+So that basically mean "unsupported".
+
+There is even more tricky problems :
+Let's take a software that release soon, release often. Let's say a voip
+software.
+
+Someone install version 1.0 from release. So far, so good, but he hear
+that 1.1 is out, and he install it from backport ( after requesting ).
+He is satisfied, then the developers of our voip software decide to
+create a version 2.0, with a completely new interface but the ui is yet
+unfinished and untranslated, so our user cannot use it. Yet, someone
+request a backport, and let's assume we do it.
+
+With our current scheme, our user will not be affected and he doesn't
+want to upgrade. So he keep the version 1.1.
+
+A security issue is discovered, in 1.X and 2.X. 
+
+1.0-2 is sent to release update, with security fix.
+2.1 is sent to backport, as the packager follow the list.
+
+What should be done for the user :
+Force upgrade to the next major release ? 
+Ask him to revert to release update ? 
+Tell him "this is not supported" ?
+
+Or maybe we should not have upgraded to 2.0 if we knew that current user
+would refuse it ?
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006023.html b/zarb-ml/mageia-dev/2011-June/006023.html new file mode 100644 index 000000000..6b7a3adca --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006023.html @@ -0,0 +1,127 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ Radu-Cristian FOTESCU + beranger5ca at yahoo.ca +
+ Sun Jun 26 09:09:23 CEST 2011 +

+
+ +
+>Someone install version 1.0 from release. So far, so good, but he hear
+>that 1.1 is out, and he install it from backport ( after requesting ).
+>He is satisfied, then the developers of our voip software decide to
+>create a version 2.0, with a completely new interface but the ui is yet
+>unfinished and untranslated, so our user cannot use it. Yet, someone
+>request a backport, and let's assume we do it.
+>
+>With our current scheme, our user will not be affected and he doesn't
+>want to upgrade. So he keep the version 1.1.
+>
+>A security issue is discovered, in 1.X and 2.X. 
+>
+>1.0-2 is sent to release update, with security fix.
+>2.1 is sent to backport, as the packager follow the list.
+>
+>What should be done for the user :
+>Force upgrade to the next major release ? 
+>Ask him to revert to release update ? 
+>Tell him "this is not supported" ?
+>
+>Or maybe we should not have upgraded to 2.0 if we knew that current user
+>would refuse it ?
+
+
+
+This is exactly why I am against backports. If I am not wrong, Fedora would have pushed 1.1, and therefore 1.1-2 into the regular updates, and 2.0 and therefore 2.1 would rather qualify for the next release of the distro. 
+
+
+Of course, another possibility would be to have in backports (or in the regular updates) both mypackage-1.1-2 and mypackage2-2.1-1. Major updates (such as from 1.x to 2.x) would probably ask for changing the base name of the package, so that different versions could coexist in the repo.
+
+I really believe that Linux distro maintainers are too narrow-minded. Maybe version 1.1.x of a package brings very few changes against 1.0.x. At the same time, version 1.0.20 of some other package might bring disruptive changes as compared to 1.0.19. It all depends of the upstream developer! So this should be a case-by-case analysis of what can be updated and what must be backported -- because I see that Mandriva's tradition of backporting is going to last in Mageia too.
+
+Think of Firefox 5.0. It's rather a 4.0.2. So f* with the version number, check rather the importance of the actual changes in the software!
+
+Cheers,
+R-C aka beranger
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006024.html b/zarb-ml/mageia-dev/2011-June/006024.html new file mode 100644 index 000000000..5e1ca497f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006024.html @@ -0,0 +1,114 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Sun Jun 26 09:56:12 CEST 2011 +

+
+ +
A short reality check from userside:
+
+If foo-1.0 is in Mageia 1 and foo-1.1 is released upstream
+ - foo-1.1 will likely be integrated in Cauldron very soon after
+ - users will request to have foo-1.1 in Mageia 1
+ - if Mageia will not provide it then there will soon be local
+repositories where local packagers will do a "backport" for their
+friends.
+
+This may not be what Mageia backport policy will allow but we can not
+avoid people doing and using this, no matter how many warning signs we
+will publish. This has to be taken into account here.
+
+When a policy is found it has to be communicated very well, especially
+if that policy means that the user can not have foo-1.1 in his stable
+Mageia 1.
+
+This is important because former Mandriva users were used to get
+almost all new versions backported, if not officially then in 3rd
+party repos like MIB or MUD.
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006025.html b/zarb-ml/mageia-dev/2011-June/006025.html new file mode 100644 index 000000000..6ad907d08 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006025.html @@ -0,0 +1,133 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ Sander Lepik + sander.lepik at eesti.ee +
+ Sun Jun 26 10:49:07 CEST 2011 +

+
+ +
24.06.2011 03:15, Michael Scherer kirjutas:
+> Hi,
+>
+> [ ... ]
+>
+> Last solution, declare that cherry picking is not supported, or that
+> people are on their own, and explain the reason. However, people have
+> been asking this, and recommend this. This would also be against a goal
+> of having confidence in the backports.
+>
+>
+> Again, and as said in the title, this is a proposal so feel free to
+> comment.
+>
+Reading comments here and knowing that our QA team is in trouble already - i don't see how 
+would QA handle backports. I can also see that there might come time when backports are 
+unpatched and thus unsecure.
+
+So i would say we can't support backports and when user installs package from backports it's 
+his/her problem to deal with it when there will be security holes or other problems. And 
+this should be very clear to everyone.
+
+I know we lack packages in mga1, so maybe we can push a little more to get those missing 
+packages working well but when most stuff is in mga2 we should continue with backports as 
+they are. We don't have QA nor packagers to keep all backports rock solid.
+
+--
+Sander
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006026.html b/zarb-ml/mageia-dev/2011-June/006026.html new file mode 100644 index 000000000..3710dbcd1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006026.html @@ -0,0 +1,79 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Sun Jun 26 10:57:57 CEST 2011 +

+
+ +
Op zondag 26 juni 2011 00:16:59 schreef Michael Scherer:
+[...]
+> > we
+> > always say that backports should mainly be cherry picked, but not
+> > enabled all the time... so how does installing a new version of e.g.
+> > wine break the user's system when he can easily back out that rpm?
+> 
+> I a not sure that most people realize they can revert. Maybe a easier
+> interface to do that could be offered ( along maybe with a tool that
+> send feedback on why it did downgrade it ? ).
+
+that's not a bad idea, what is the best way to revert? is that with --old-
+package ?
+
+what if the package has been removed on mirrors? (ie: due to more recent 
+updates)
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006027.html b/zarb-ml/mageia-dev/2011-June/006027.html new file mode 100644 index 000000000..138c8cc1a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006027.html @@ -0,0 +1,147 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ atilla ontas + tarakbumba at gmail.com +
+ Sun Jun 26 10:58:04 CEST 2011 +

+
+ +
2011/6/26 Wolfgang Bornath <molch.b at googlemail.com>:
+> A short reality check from userside:
+>
+> If foo-1.0 is in Mageia 1 and foo-1.1 is released upstream
+>  - foo-1.1 will likely be integrated in Cauldron very soon after
+>  - users will request to have foo-1.1 in Mageia 1
+>  - if Mageia will not provide it then there will soon be local
+> repositories where local packagers will do a "backport" for their
+> friends.
+>
+> This may not be what Mageia backport policy will allow but we can not
+> avoid people doing and using this, no matter how many warning signs we
+> will publish. This has to be taken into account here.
+>
+> When a policy is found it has to be communicated very well, especially
+> if that policy means that the user can not have foo-1.1 in his stable
+> Mageia 1.
+>
+> This is important because former Mandriva users were used to get
+> almost all new versions backported, if not officially then in 3rd
+> party repos like MIB or MUD.
+>
+> --
+> wobo
+>
+Hi. I'm following this threat from the very beginning. While reading,
+i feel i'm reading a Mandriva Cooker mailing list posts. As a
+community distro, why Mageia developers still think like a Mandriva
+employee? Why backports and why so many policies, like a commercial
+enterprise distro? I mean, Mageia do not have paid developers to work
+on packages all the time. Also Mageia do not have so many packagers
+like Fedora or Ubuntu, So, why make so many things so hard?
+
+As wobo mentioned, people like latest and greatest software. I think,
+except a few users will use unofficial 3rd party repos to get latest
+software. While i was maintaining MVT (Mandriva Turkiye) repository,
+our users asked for GNOME 2.32 while Mandriva have GNOME 2.30 on
+official release.
+
+Personally i always hate the backports structure and policy. It
+confuses minds. Why Mageia need a backports repo, i really do not
+understand. Stability and bug free releases are of course a must. But
+it needs developers dedicated to work, almost paid developers. If a
+software do not related with core system, like vlc, it should included
+updates repo. Let upstream fix bugs and security issues. If a packager
+catchs a bug he should send a patch to upstream and wait for a new
+release. Otherwise, it is not packaging it is coding, which many
+potential packgers will avoid to contribute.
+
+Look at Debian and Arch Linux who haven't any paid developers but
+community distros. Stable Debian releases provide software from a
+century ago for the sake of stability. Arch provides latest software
+including core system and occaionally have breakages. I think Mageia
+should be between two of them. Release latest software in updates for
+non core system and libs, keep core system stable. Remove this
+backports thingy.
+
+My 2 cents...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006028.html b/zarb-ml/mageia-dev/2011-June/006028.html new file mode 100644 index 000000000..60e73824a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006028.html @@ -0,0 +1,78 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Radu-Cristian FOTESCU + beranger5ca at yahoo.ca +
+ Sun Jun 26 11:08:52 CEST 2011 +

+
+ +
+
+>>  I a not sure that most people realize they can revert. Maybe a easier
+>>  interface to do that could be offered ( along maybe with a tool that
+>>  send feedback on why it did downgrade it ? ).
+> 
+> that's not a bad idea, what is the best way to revert? is that with --old-
+> package ?
+
+Maybe I'm stupid, but rpmdrake does not have any option to downgrade a package. To my knowledge, the only GUI in this world that has such an option (in a menu) is Synaptic, but Synaptic itself ceases to be the default GUI package manager in *buntu 11.11.
+
+And man urpmi does not assist the user into downgrading a package. Frankly, I don't know how to protect a package from being updated, the way I can do it with yum (or the way I can hold a package with dpkg, aptitude or dselect). Of course, I am not that familiar with Mageia (or Mandriva), or rather I treated Mageia (and Mandriva) as "distros where I should use the GUI tools or the default options of the CLI tools and not bother much" -- otherwise, why using mga/mdv and not something else?
+
+R-C aka beranger
+
+ + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006029.html b/zarb-ml/mageia-dev/2011-June/006029.html new file mode 100644 index 000000000..6ecf61a2d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006029.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Michael Scherer + misc at zarb.org +
+ Sun Jun 26 11:35:53 CEST 2011 +

+
+ +
Le dimanche 26 juin 2011 à 10:57 +0200, Maarten Vanraes a écrit :
+> Op zondag 26 juni 2011 00:16:59 schreef Michael Scherer:
+> [...]
+> > > we
+> > > always say that backports should mainly be cherry picked, but not
+> > > enabled all the time... so how does installing a new version of e.g.
+> > > wine break the user's system when he can easily back out that rpm?
+> > 
+> > I a not sure that most people realize they can revert. Maybe a easier
+> > interface to do that could be offered ( along maybe with a tool that
+> > send feedback on why it did downgrade it ? ).
+> 
+> that's not a bad idea, what is the best way to revert? is that with --old-
+> package ?
+
+urpme package; urpmi package
+
+> what if the package has been removed on mirrors? (ie: due to more recent 
+> updates)
+
+Let me complete my proposal : 'revert to the version in release'.
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006030.html b/zarb-ml/mageia-dev/2011-June/006030.html new file mode 100644 index 000000000..2caeab814 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006030.html @@ -0,0 +1,126 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ Michael Scherer + misc at zarb.org +
+ Sun Jun 26 11:38:46 CEST 2011 +

+
+ +
Le dimanche 26 juin 2011 à 11:49 +0300, Sander Lepik a écrit :
+> 24.06.2011 03:15, Michael Scherer kirjutas:
+> > Hi,
+> >
+> > [ ... ]
+> >
+> > Last solution, declare that cherry picking is not supported, or that
+> > people are on their own, and explain the reason. However, people have
+> > been asking this, and recommend this. This would also be against a goal
+> > of having confidence in the backports.
+> >
+> >
+> > Again, and as said in the title, this is a proposal so feel free to
+> > comment.
+> >
+> Reading comments here and knowing that our QA team is in trouble already - i don't see how 
+> would QA handle backports. I can also see that there might come time when backports are 
+> unpatched and thus unsecure.
+
+At what point is QA team mentioned in the process ( which is in another
+thread ) ?
+
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006031.html b/zarb-ml/mageia-dev/2011-June/006031.html new file mode 100644 index 000000000..8d2df2fee --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006031.html @@ -0,0 +1,143 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ Daniel Kreuter + daniel.kreuter85 at googlemail.com +
+ Sun Jun 26 11:43:12 CEST 2011 +

+
+ +
On Sun, Jun 26, 2011 at 10:58 AM, atilla ontas <tarakbumba at gmail.com> wrote:
+
+> Hi. I'm following this threat from the very beginning. While reading,
+> i feel i'm reading a Mandriva Cooker mailing list posts. As a
+> community distro, why Mageia developers still think like a Mandriva
+> employee? Why backports and why so many policies, like a commercial
+> enterprise distro? I mean, Mageia do not have paid developers to work
+> on packages all the time. Also Mageia do not have so many packagers
+> like Fedora or Ubuntu, So, why make so many things so hard?
+>
+> As wobo mentioned, people like latest and greatest software. I think,
+> except a few users will use unofficial 3rd party repos to get latest
+> software. While i was maintaining MVT (Mandriva Turkiye) repository,
+> our users asked for GNOME 2.32 while Mandriva have GNOME 2.30 on
+> official release.
+>
+> Personally i always hate the backports structure and policy. It
+> confuses minds. Why Mageia need a backports repo, i really do not
+> understand. Stability and bug free releases are of course a must. But
+> it needs developers dedicated to work, almost paid developers. If a
+> software do not related with core system, like vlc, it should included
+> updates repo. Let upstream fix bugs and security issues. If a packager
+> catchs a bug he should send a patch to upstream and wait for a new
+> release. Otherwise, it is not packaging it is coding, which many
+> potential packgers will avoid to contribute.
+>
+>
++1 I also see no usage of backports. I'm someone quite new to
+Mandriva/Mageia so I wouldn't know what backports are for (Ubuntu has
+nothing like this, Fedora too) so why backport?
+
+
+> Look at Debian and Arch Linux who haven't any paid developers but
+> community distros. Stable Debian releases provide software from a
+> century ago for the sake of stability. Arch provides latest software
+> including core system and occaionally have breakages. I think Mageia
+> should be between two of them. Release latest software in updates for
+> non core system and libs, keep core system stable. Remove this
+> backports thingy.
+>
+> My 2 cents...
+>
+This approach looks quite good, but the new software should be tested quite
+good so the system will not break. Sure core system won't break with this
+approach but what about the other software?
+
+
+-- 
+Mit freundlichen Grüßen
+
+Greetings
+
+Daniel Kreuter
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110626/d5eb4c0e/attachment-0001.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006032.html b/zarb-ml/mageia-dev/2011-June/006032.html new file mode 100644 index 000000000..467d7651b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006032.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ André Salaün + andresalaun at free.fr +
+ Sun Jun 26 11:59:42 CEST 2011 +

+
+ +
Le Sun, 26 Jun 2011 02:08:52 -0700 (PDT)
+Radu-Cristian FOTESCU <beranger5ca at yahoo.ca> a écrit:
+
+> 
+> 
+> >>  I a not sure that most people realize they can revert. Maybe a easier
+> >>  interface to do that could be offered ( along maybe with a tool that
+> >>  send feedback on why it did downgrade it ? ).
+> > 
+> > that's not a bad idea, what is the best way to revert? is that with --old-
+> > package ?
+> 
+> Maybe I'm stupid, but rpmdrake does not have any option to downgrade a package. To my knowledge, the only GUI in this world that has such an option (in a menu) is Synaptic, but Synaptic itself ceases to be the default GUI package manager in *buntu 11.11.
+
+No I don't think, smart and smart-gui can do that.
+Furthermore, if you break drakrpm and/or urpmi (using unofficlal
+sources or testing) it can run because based on python.
+For me it is a good complement to urpmi (whith urpmisync  like in
+Mandriva)... when it works (I had o lot of problems in Mandriva  
+2010.1 2010.2 with urpmi synchronisation)
+
+> And man urpmi does not assist the user into downgrading a package. Frankly, I don't know how to protect a package from being updated, the way I can do it with yum (or the way I can hold a package with dpkg, aptitude or dselect). Of course, I am not that familiar with Mageia (or Mandriva), or rather I treated Mageia (and Mandriva) as "distros where I should use the GUI tools or the default options of the CLI tools and not bother much" -- otherwise, why using mga/mdv and not something else?
+> 
+> R-C aka beranger
+
+
+-- 
+A.Salaün
+Ne lâchez rien.
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006033.html b/zarb-ml/mageia-dev/2011-June/006033.html new file mode 100644 index 000000000..6d57d8713 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006033.html @@ -0,0 +1,72 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Sander Lepik + sander.lepik at eesti.ee +
+ Sun Jun 26 12:10:14 CEST 2011 +

+
+ +
26.06.2011 12:35, Michael Scherer kirjutas:
+> urpme package; urpmi package
+>
+That's not so easy if something depends on that package. How hard is it to implement rpm's 
+"--oldpackage" to urpmi? I really don't know but i hope it's nothing too hard.
+
+--
+Sander
+
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006034.html b/zarb-ml/mageia-dev/2011-June/006034.html new file mode 100644 index 000000000..442b64ad7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006034.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ atilla ontas + tarakbumba at gmail.com +
+ Sun Jun 26 12:40:04 CEST 2011 +

+
+ +
2011/6/26 Daniel Kreuter <daniel.kreuter85 at googlemail.com>:
+> On Sun, Jun 26, 2011 at 10:58 AM, atilla ontas <tarakbumba at gmail.com> wrote:
+>>
+>> Look at Debian and Arch Linux who haven't any paid developers but
+>> community distros. Stable Debian releases provide software from a
+>> century ago for the sake of stability. Arch provides latest software
+>> including core system and occaionally have breakages. I think Mageia
+>> should be between two of them. Release latest software in updates for
+>> non core system and libs, keep core system stable. Remove this
+>> backports thingy.
+>>
+>> My 2 cents...
+>
+> This approach looks quite good, but the new software should be tested quite
+> good so the system will not break. Sure core system won't break with this
+> approach but what about the other software?
+>
+>
+>
+>
+I don't mean no need to test. Of course they should be placed in
+testing repo first.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006035.html b/zarb-ml/mageia-dev/2011-June/006035.html new file mode 100644 index 000000000..b7abcd9b2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006035.html @@ -0,0 +1,76 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Sun Jun 26 12:52:46 CEST 2011 +

+
+ +
Op zondag 26 juni 2011 12:10:14 schreef Sander Lepik:
+> 26.06.2011 12:35, Michael Scherer kirjutas:
+> > urpme package; urpmi package
+> 
+> That's not so easy if something depends on that package. How hard is it to
+> implement rpm's "--oldpackage" to urpmi? I really don't know but i hope
+> it's nothing too hard.
+
+that is exactly what i meant, sometimes these can be big dependencies, and 
+i've used once or twice --oldpackage in rpm
+
+i guess some extra work could be wanted to have this in urpmi and possibly 
+rpmdrake
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006036.html b/zarb-ml/mageia-dev/2011-June/006036.html new file mode 100644 index 000000000..290f88ef9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006036.html @@ -0,0 +1,223 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ Michael Scherer + misc at zarb.org +
+ Sun Jun 26 12:57:49 CEST 2011 +

+
+ +
Le dimanche 26 juin 2011 à 11:58 +0300, atilla ontas a écrit :
+> 2011/6/26 Wolfgang Bornath <molch.b at googlemail.com>:
+> > A short reality check from userside:
+> >
+> > If foo-1.0 is in Mageia 1 and foo-1.1 is released upstream
+> >  - foo-1.1 will likely be integrated in Cauldron very soon after
+> >  - users will request to have foo-1.1 in Mageia 1
+> >  - if Mageia will not provide it then there will soon be local
+> > repositories where local packagers will do a "backport" for their
+> > friends.
+> >
+> > This may not be what Mageia backport policy will allow but we can not
+> > avoid people doing and using this, no matter how many warning signs we
+> > will publish. This has to be taken into account here.
+> >
+> > When a policy is found it has to be communicated very well, especially
+> > if that policy means that the user can not have foo-1.1 in his stable
+> > Mageia 1.
+> >
+> > This is important because former Mandriva users were used to get
+> > almost all new versions backported, if not officially then in 3rd
+> > party repos like MIB or MUD.
+> >
+> > --
+> > wobo
+> >
+> Hi. I'm following this threat from the very beginning. While reading,
+> i feel i'm reading a Mandriva Cooker mailing list posts. As a
+> community distro, why Mageia developers still think like a Mandriva
+> employee? Why backports and why so many policies, like a commercial
+> enterprise distro? I mean, Mageia do not have paid developers to work
+> on packages all the time. Also Mageia do not have so many packagers
+> like Fedora or Ubuntu, So, why make so many things so hard?
+
+If you adequate "commercial distro == policy", then I think you missed
+some steps. Just look at the number of packaging policy on Debian and
+Fedora.
+
+For debian start at http://www.debian.org/doc/debian-policy/ ( and
+various sub policy : http://www.debian.org/doc/packaging-manuals/ , not
+to count others that you can find on subteam such as
+http://pkg-haskell.alioth.debian.org/haskell-policy/ ).
+
+For Fedora, just look at :
+http://fedoraproject.org/wiki/Category:Packaging_guidelines
+
+
+We have open processes and not free-for-all because :
+- we can be sure that everybody do the same thing and know what can be
+done or not, ie, work like a community. 
+
+- we can direct newcomers to the our standard, as telling "you will
+discover by yourself" would be quite unfriendly to them. This is
+therefor required for and by growth.
+
+- a goal of a distribution is to have a coherent set of packages ( other
+wise, we , and to have that, we need to have a coherent set of rules, so
+they can inter-operate.
+
+- we want to set proper expectations. Expectations of those that use the
+system, because they have the guarantee of stability, or of having newer
+rpms. Expectation of the packager, because he know what can be done and
+would fail. 
+
+> As wobo mentioned, people like latest and greatest software. I think,
+> except a few users will use unofficial 3rd party repos to get latest
+> software. While i was maintaining MVT (Mandriva Turkiye) repository,
+> our users asked for GNOME 2.32 while Mandriva have GNOME 2.30 on
+> official release.
+
+And others people mentioned that people want also stable software and do
+not want changes. But as I said, what people want is not as important
+than what we can do, and so the decision is in the end of those that do
+the work rather than what people want, because if no one does the work,
+nothing happen.
+
+> Personally i always hate the backports structure and policy. It
+> confuses minds. Why Mageia need a backports repo, i really do not
+> understand. Stability and bug free releases are of course a must. But
+> it needs developers dedicated to work, almost paid developers. If a
+> software do not related with core system, like vlc, it should included
+> updates repo. Let upstream fix bugs and security issues. 
+
+So what you suggest is do like arch ?
+And when upstream is unable to reproduce the issue ( because he doesn't
+run the same distribution than the users that report ), what should be
+done ?
+
+> If a packager
+> catchs a bug he should send a patch to upstream and wait for a new
+> release. Otherwise, it is not packaging it is coding, which many
+> potential packgers will avoid to contribute.
+
+Sending a patch is coding. In fact, the more complex part is not to send
+a email with the file attached, it is to write the patch. 
+
+And once you have the patch, it is trivial to apply it to the rpm. 
+
+So the alternative is either we try to fixng for the bug ( which several
+packagers are perfectly able to do ), or we wait until it is fixed
+( which is usually unsatisfying for the users as some of them will see
+this as "the packager refused to listen to me and fix the bug" ).
+
+> Look at Debian and Arch Linux who haven't any paid developers but
+> community distros. Stable Debian releases provide software from a
+> century ago for the sake of stability. 
+
+Do not exaggerate. Software in Debian were perfectly fine when they were
+out, ( usually 1 to 2 year ago ), and now, they are "from a century
+ago" ? 
+
+And as lebahron noted in another thread, several people want stable
+release. Look at the time people kept windows xp.
+
+> Arch provides latest software
+> including core system and occaionally have breakages. I think Mageia
+> should be between two of them. Release latest software in updates for
+> non core system and libs, keep core system stable. Remove this
+> backports thingy.
+
+Sure, can you first start to define what is "non core" ( especially in
+the light of all SRPMS we currently have ) ? Bear in mind the various
+requires between all the required components.
+
+Usually, I recommend to people to look at various *BSD, as they provides
+exactly that, a core system with pkgsrc. The core is well defined, and
+everything below is updated with compiled ports. 
+
+But this requires to use a totally different workflow regarding kernel,
+glibc, coreutils etc, so people would have to convince kernel developers
+and glibc one first before anything. And I think the distribution that
+try to mimic this ( mimic because, unlike a bsd project, they do not
+take care of the libc and kernel part ) would be either Slackware or
+Arch. 
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006037.html b/zarb-ml/mageia-dev/2011-June/006037.html new file mode 100644 index 000000000..9f89122ed --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006037.html @@ -0,0 +1,117 @@ + + + + [Mageia-dev] [RPM] cauldron core/release scourge-data-0.21.1-2.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release scourge-data-0.21.1-2.mga2

+ Pascal Terjan + pterjan at gmail.com +
+ Sun Jun 26 13:06:25 CEST 2011 +

+
+ +
On Wed, Jun 22, 2011 at 10:24, Mageia Team
+<buildsystem-daemon at mageia.org> wrote:
+> Name        : scourge-data                 Relocations: (not relocatable)
+> Version     : 0.21.1                            Vendor: Mageia.Org
+> Release     : 2.mga2                        Build Date: Wed Jun 22 10:14:40 2011
+> Install Date: (not installed)               Build Host: ecosse
+> Group       : Games/Adventure               Source RPM: (none)
+> Size        : 127698329                        License: GPLv2+
+> Signature   : (none)
+> Packager    : Mageia Team <http://www.mageia.org>
+> URL         : http://scourgeweb.org/
+> Summary     : Data files for Scourge roguelike game
+> Description :
+> Data files for Scourge roguelike game.
+>
+> zezinho <zezinho> 0.21.1-2.mga2:
+> + Revision: 111772
+> - imported package scourge-data
+
+This package requires scourge, which is not in the repository
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006038.html b/zarb-ml/mageia-dev/2011-June/006038.html new file mode 100644 index 000000000..dead2bc61 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006038.html @@ -0,0 +1,122 @@ + + + + [Mageia-dev] [RPM] cauldron core/release scourge-data-0.21.1-2.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release scourge-data-0.21.1-2.mga2

+ Dexter Morgan + dmorganec at gmail.com +
+ Sun Jun 26 13:17:27 CEST 2011 +

+
+ +
On Sun, Jun 26, 2011 at 1:06 PM, Pascal Terjan <pterjan at gmail.com> wrote:
+> On Wed, Jun 22, 2011 at 10:24, Mageia Team
+> <buildsystem-daemon at mageia.org> wrote:
+>> Name        : scourge-data                 Relocations: (not relocatable)
+>> Version     : 0.21.1                            Vendor: Mageia.Org
+>> Release     : 2.mga2                        Build Date: Wed Jun 22 10:14:40 2011
+>> Install Date: (not installed)               Build Host: ecosse
+>> Group       : Games/Adventure               Source RPM: (none)
+>> Size        : 127698329                        License: GPLv2+
+>> Signature   : (none)
+>> Packager    : Mageia Team <http://www.mageia.org>
+>> URL         : http://scourgeweb.org/
+>> Summary     : Data files for Scourge roguelike game
+>> Description :
+>> Data files for Scourge roguelike game.
+>>
+>> zezinho <zezinho> 0.21.1-2.mga2:
+>> + Revision: 111772
+>> - imported package scourge-data
+>
+> This package requires scourge, which is not in the repository
+>
+yes but it doesn't buidld see :
+
+http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110625200829.dmorgan.valstar.19853/log/scourge-0.21.1-2.mga2/build.0.20110625200903.log
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006039.html b/zarb-ml/mageia-dev/2011-June/006039.html new file mode 100644 index 000000000..e5880192c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006039.html @@ -0,0 +1,134 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ Michael Scherer + misc at zarb.org +
+ Sun Jun 26 13:29:05 CEST 2011 +

+
+ +
Le dimanche 26 juin 2011 à 11:43 +0200, Daniel Kreuter a écrit :
+> On Sun, Jun 26, 2011 at 10:58 AM, atilla ontas <tarakbumba at gmail.com> wrote:
+> 
+> > Hi. I'm following this threat from the very beginning. While reading,
+> > i feel i'm reading a Mandriva Cooker mailing list posts. As a
+> > community distro, why Mageia developers still think like a Mandriva
+> > employee? Why backports and why so many policies, like a commercial
+> > enterprise distro? I mean, Mageia do not have paid developers to work
+> > on packages all the time. Also Mageia do not have so many packagers
+> > like Fedora or Ubuntu, So, why make so many things so hard?
+> >
+> > As wobo mentioned, people like latest and greatest software. I think,
+> > except a few users will use unofficial 3rd party repos to get latest
+> > software. While i was maintaining MVT (Mandriva Turkiye) repository,
+> > our users asked for GNOME 2.32 while Mandriva have GNOME 2.30 on
+> > official release.
+> >
+> > Personally i always hate the backports structure and policy. It
+> > confuses minds. Why Mageia need a backports repo, i really do not
+> > understand. Stability and bug free releases are of course a must. But
+> > it needs developers dedicated to work, almost paid developers. If a
+> > software do not related with core system, like vlc, it should included
+> > updates repo. Let upstream fix bugs and security issues. If a packager
+> > catchs a bug he should send a patch to upstream and wait for a new
+> > release. Otherwise, it is not packaging it is coding, which many
+> > potential packgers will avoid to contribute.
+> >
+> >
+> +1 I also see no usage of backports. I'm someone quite new to
+> Mandriva/Mageia so I wouldn't know what backports are for (Ubuntu has
+> nothing like this, Fedora too) so why backport?
+
+It was already explained why in another thread, and this was also
+answered in the various thread about mirror layout, on the Mandriva page
+about it on the wiki, on the mailling list at that time, and on various
+others documentation sources. 
+
+I really do not have the luxury to explain from scratch everything, so
+please look at the archive of the ml.
+
+And speaking of Ubuntu, there is :
+https://help.ubuntu.com/community/UbuntuBackports
+
+( or http://wiki.debian.org/Backports for Debian, or the proposal ( that
+stalled, as said in another thread ) for Fedora :
+https://fedorahosted.org/fesco/ticket/515 , due to
+http://fedoraproject.org/wiki/Stable_release_updates_vision )
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006040.html b/zarb-ml/mageia-dev/2011-June/006040.html new file mode 100644 index 000000000..928cbc865 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006040.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Michael Scherer + misc at zarb.org +
+ Sun Jun 26 13:38:16 CEST 2011 +

+
+ +
Le dimanche 26 juin 2011 à 13:10 +0300, Sander Lepik a écrit :
+> 26.06.2011 12:35, Michael Scherer kirjutas:
+> > urpme package; urpmi package
+> >
+> That's not so easy if something depends on that package. How hard is it to implement rpm's 
+> "--oldpackage" to urpmi? I really don't know but i hope it's nothing too hard.
+
+See the thread about policy, and the part about "only packages that
+nothing requires should be backported".
+
+Regarding the rollback ( because, that's how it is called ), there is a
+lot of conference dedicated on this topic, the latest one being that
+http://www.slideshare.net/johngt/improving-rollback-in-linux-via-dsl-approach-distributing , just before the one I gave about mageia at FOSDEM.
+
+You can also take a look at the mancoosi research project, read the
+discussion over that at cooker@ ( somewhere around
+http://lists.mandriva.com/cooker/2010-11/msg00401.php ), and read the
+rest of the thread where it was already proposed :
+http://www.mageia.org/pipermail/mageia-dev/20101008/001021.html ( point
+4 ).
+
+
+-- 
+Michael Scherer
+
+
+
+ + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006041.html b/zarb-ml/mageia-dev/2011-June/006041.html new file mode 100644 index 000000000..150a43cbe --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006041.html @@ -0,0 +1,139 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Sun Jun 26 14:49:37 CEST 2011 +

+
+ +
2011/6/26 Michael Scherer <misc at zarb.org>:
+> Le dimanche 26 juin 2011 à 11:58 +0300, atilla ontas a écrit :
+>> 2011/6/26 Wolfgang Bornath <molch.b at googlemail.com>:
+>> > A short reality check from userside:
+>> >
+>> > If foo-1.0 is in Mageia 1 and foo-1.1 is released upstream
+>> >  - foo-1.1 will likely be integrated in Cauldron very soon after
+>> >  - users will request to have foo-1.1 in Mageia 1
+>> >  - if Mageia will not provide it then there will soon be local
+>> > repositories where local packagers will do a "backport" for their
+>> > friends.
+>> >
+>> > This may not be what Mageia backport policy will allow but we can not
+>> > avoid people doing and using this, no matter how many warning signs we
+>> > will publish. This has to be taken into account here.
+>> >
+>> > When a policy is found it has to be communicated very well, especially
+>> > if that policy means that the user can not have foo-1.1 in his stable
+>> > Mageia 1.
+>> >
+>> > This is important because former Mandriva users were used to get
+>> > almost all new versions backported, if not officially then in 3rd
+>> > party repos like MIB or MUD.
+>> >
+>> > --
+>> > wobo
+>> >
+>
+>> As wobo mentioned, people like latest and greatest software. I think,
+>> except a few users will use unofficial 3rd party repos to get latest
+>> software. While i was maintaining MVT (Mandriva Turkiye) repository,
+>> our users asked for GNOME 2.32 while Mandriva have GNOME 2.30 on
+>> official release.
+>
+> And others people mentioned that people want also stable software and do
+> not want changes. But as I said, what people want is not as important
+> than what we can do, and so the decision is in the end of those that do
+> the work rather than what people want, because if no one does the work,
+> nothing happen.
+
+Well, in principle this is correct, not in this case as I have
+explained as a very common example. You can decide whatever you want,
+if a user wants a certain package and his friend will pack it for him
+and puts it up on a server, publishing the existence - then you will
+see what happens. You know by experience how popular such 3rd-party
+repos can become (see MIB, MUD), just because somebody had a different
+view than the official view.
+In short: no matter what is more important or not, you have to find a
+compromise between the (understandable) search for optimal workflow,
+security on one side and the real world of the users on the other. I
+think, the key here is non-technical communication of the
+circumstances, like "why we can't have foo 1.2 as backport from
+Cauldron to Mageia 1".
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006042.html b/zarb-ml/mageia-dev/2011-June/006042.html new file mode 100644 index 000000000..b3e91ea61 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006042.html @@ -0,0 +1,158 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ Michael Scherer + misc at zarb.org +
+ Sun Jun 26 16:05:21 CEST 2011 +

+
+ +
Le dimanche 26 juin 2011 à 14:49 +0200, Wolfgang Bornath a écrit :
+> 2011/6/26 Michael Scherer <misc at zarb.org>:
+> > Le dimanche 26 juin 2011 à 11:58 +0300, atilla ontas a écrit :
+> >> 2011/6/26 Wolfgang Bornath <molch.b at googlemail.com>:
+> >> > A short reality check from userside:
+> >> >
+> >> > If foo-1.0 is in Mageia 1 and foo-1.1 is released upstream
+> >> >  - foo-1.1 will likely be integrated in Cauldron very soon after
+> >> >  - users will request to have foo-1.1 in Mageia 1
+> >> >  - if Mageia will not provide it then there will soon be local
+> >> > repositories where local packagers will do a "backport" for their
+> >> > friends.
+> >> >
+> >> > This may not be what Mageia backport policy will allow but we can not
+> >> > avoid people doing and using this, no matter how many warning signs we
+> >> > will publish. This has to be taken into account here.
+> >> >
+> >> > When a policy is found it has to be communicated very well, especially
+> >> > if that policy means that the user can not have foo-1.1 in his stable
+> >> > Mageia 1.
+> >> >
+> >> > This is important because former Mandriva users were used to get
+> >> > almost all new versions backported, if not officially then in 3rd
+> >> > party repos like MIB or MUD.
+> >> >
+> >> > --
+> >> > wobo
+> >> >
+> >
+> >> As wobo mentioned, people like latest and greatest software. I think,
+> >> except a few users will use unofficial 3rd party repos to get latest
+> >> software. While i was maintaining MVT (Mandriva Turkiye) repository,
+> >> our users asked for GNOME 2.32 while Mandriva have GNOME 2.30 on
+> >> official release.
+> >
+> > And others people mentioned that people want also stable software and do
+> > not want changes. But as I said, what people want is not as important
+> > than what we can do, and so the decision is in the end of those that do
+> > the work rather than what people want, because if no one does the work,
+> > nothing happen.
+> 
+> Well, in principle this is correct, not in this case as I have
+> explained as a very common example. You can decide whatever you want,
+> if a user wants a certain package and his friend will pack it for him
+> and puts it up on a server, publishing the existence - then you will
+> see what happens. You know by experience how popular such 3rd-party
+> repos can become (see MIB, MUD), just because somebody had a different
+> view than the official view.
+
+Then someone did it the job. Maybe not correctly from a technical point
+of view, with all the problem this can create ( lack of audit and
+reproductability, as I seen while trying to understand MIB stuff, non
+integration with the rest of the distribution, since this requires to
+type command line etc, breakage of stuff like upgrade of version ), but
+still did the work. 
+
+Of course, most of the time, that's not sustainable, but who really care
+about that...
+
+> In short: no matter what is more important or not, you have to find a
+> compromise between the (understandable) search for optimal workflow,
+> security on one side and the real world of the users on the other. 
+
+Can people please stop saying that "users" are living in the real world,
+as this logically imply that others ( ie, "us", for whatever that mean )
+are not ?
+
+Optimal workflow is solving a real problem for ressources, with impact
+on the distribution. Security is a real problem too. That's not because
+some people do not see a problem that it doesn't existe or that it is a
+fake one.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006043.html b/zarb-ml/mageia-dev/2011-June/006043.html new file mode 100644 index 000000000..42ca4a4f5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006043.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Sun Jun 26 16:17:55 CEST 2011 +

+
+ +
2011/6/26 Michael Scherer <misc at zarb.org>:
+>
+> Can people please stop saying that "users" are living in the real world,
+> as this logically imply that others ( ie, "us", for whatever that mean )
+> are not ?
+
+LOL! I did not expect that you take the single word over the expression.
+When I set you, me, whoever, in difference to "the real world" it is
+meant as the technical discussion "under the hood" vs the practical
+daily usage of the system by a non-technical user. A difference which
+is real.
+
+Hopefully this is clearer now.
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006044.html b/zarb-ml/mageia-dev/2011-June/006044.html new file mode 100644 index 000000000..0dfc141a0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006044.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] [RPM] cauldron core/release scourge-data-0.21.1-2.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release scourge-data-0.21.1-2.mga2

+ José Jorge + jjorge at free.fr +
+ Sun Jun 26 16:34:03 CEST 2011 +

+
+ +
Le dimanche 26 juin 2011 13:17:27, Dexter Morgan a écrit :
+> > This package requires scourge, which is not in the repository
+> 
+> yes but it doesn't buidld see :
+> 
+> http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/201106252
+> 00829.dmorgan.valstar.19853/log/scourge-0.21.1-2.mga2/build.0.2011062520090
+> 3.log
+
+It build on i586, not in x86_64. I asked for help here, and made a bug report 
+https://bugs.mageia.org/show_bug.cgi?id=1901
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006045.html b/zarb-ml/mageia-dev/2011-June/006045.html new file mode 100644 index 000000000..80974c137 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006045.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] Backports policy proposal + + + + + + + + + +

[Mageia-dev] Backports policy proposal

+ Anssi Hannula + anssi.hannula at iki.fi +
+ Sun Jun 26 17:00:06 CEST 2011 +

+
+ +
On 26.06.2011 01:34, Michael Scherer wrote:
+> Le vendredi 24 juin 2011 à 17:33 +0300, Anssi Hannula a écrit :
+>> On 24.06.2011 03:10, Michael Scherer wrote:
+>>> Another rule that we could add is that cauldron should always be newer
+>>> than backports, in order to ensure upgradability. The same goes for n-2
+>>> and n-1 release.
+>>> While this seems innocent, do not forget this will have a impact when we
+>>> do the version freeze.
+>>
+>> So this will prevent backporting anything to mga1 if it is not in mga2
+>> release/updates ?
+> 
+> That's a good question but yes, I would consider such policy.
+> Ie, do backport only for the latest supported release.
+
+This will essentially prevent backporting anything to mga1 after mga2
+release. :/
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006046.html b/zarb-ml/mageia-dev/2011-June/006046.html new file mode 100644 index 000000000..7068cf9ac --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006046.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] Backports policy proposal + + + + + + + + + +

[Mageia-dev] Backports policy proposal

+ Angelo Naselli + anaselli at linux.it +
+ Sun Jun 26 17:14:58 CEST 2011 +

+
+ +
In data domenica 26 giugno 2011 00:43:22, Michael Scherer ha scritto:
+> Le samedi 25 juin 2011 à 15:05 +0200, Angelo Naselli a écrit :
+> > In data venerdì 24 giugno 2011 02:10:14, Michael Scherer ha scritto:
+> > > - cannot be backported if the package was just created and is thus
+> > > basically untested in cauldron
+> > 
+> > Well even if i could agree with that, i cannot see how can we ensure that
+> > a 2-3 weeks presence in cauldron means that the package has been
+> > tested by someone... we can only suppose to...
+> 
+> a 0 week presence basically mean no test, so it can only improve the
+> chance of being tested.
+Agree, but the same chance as we put in backport_testing - or what name is- 
+first.
+
+-- 
+	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/20110626/04ccf5c3/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006047.html b/zarb-ml/mageia-dev/2011-June/006047.html new file mode 100644 index 000000000..d69493bb0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006047.html @@ -0,0 +1,117 @@ + + + + [Mageia-dev] Backports policy proposal + + + + + + + + + +

[Mageia-dev] Backports policy proposal

+ Michael Scherer + misc at zarb.org +
+ Sun Jun 26 17:33:50 CEST 2011 +

+
+ +
Le dimanche 26 juin 2011 à 18:00 +0300, Anssi Hannula a écrit :
+> On 26.06.2011 01:34, Michael Scherer wrote:
+> > Le vendredi 24 juin 2011 à 17:33 +0300, Anssi Hannula a écrit :
+> >> On 24.06.2011 03:10, Michael Scherer wrote:
+> >>> Another rule that we could add is that cauldron should always be newer
+> >>> than backports, in order to ensure upgradability. The same goes for n-2
+> >>> and n-1 release.
+> >>> While this seems innocent, do not forget this will have a impact when we
+> >>> do the version freeze.
+> >>
+> >> So this will prevent backporting anything to mga1 if it is not in mga2
+> >> release/updates ?
+> > 
+> > That's a good question but yes, I would consider such policy.
+> > Ie, do backport only for the latest supported release.
+> 
+> This will essentially prevent backporting anything to mga1 after mga2
+> release. :/
+
+Yes, that's explicitly the problem.
+
+Now, maybe we could say "if you use backports on version N after the
+release of N+1, then mgaonline will no longer work". Provided we find a
+user friendly way to warn users, we can maybe find something.
+
+But again, it is either the backports or the upgrade. And people do have
+expressed to have both :
+- "reinstalling at every release is hard and annoying, why not do like
+Ubuntu and Debian ?"
+- "We want newer software, why not provides newer version ?"
+
+So we either need a way to solve the dilemma, or at least, a way to
+clearly explain the impact to people.
+
+I think I may have a idea that would solve this issue and the one of
+update, but I need to think a little bit before proposing it
+( especially since I suffer from common cold, maybe my idea is
+completely rubbish ).
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006048.html b/zarb-ml/mageia-dev/2011-June/006048.html new file mode 100644 index 000000000..04568ebb1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006048.html @@ -0,0 +1,121 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ Angelo Naselli + anaselli at linux.it +
+ Sun Jun 26 18:51:39 CEST 2011 +

+
+ +
> Well, in principle this is correct, not in this case as I have
+> explained as a very common example. You can decide whatever you want,
+> if a user wants a certain package and his friend will pack it for him
+> and puts it up on a server, publishing the existence - then you will
+> see what happens. You know by experience how popular such 3rd-party
+> repos can become (see MIB, MUD), just because somebody had a different
+> view than the official view.
+> In short: no matter what is more important or not, you have to find a
+> compromise between the (understandable) search for optimal workflow,
+> security on one side and the real world of the users on the other. I
+> think, the key here is non-technical communication of the
+> circumstances, like "why we can't have foo 1.2 as backport from
+> Cauldron to Mageia 1".
+Well I'm one who backports what he needs, doesn't mean all, just what needs.
+I always enable backports, and i know often how to go on if a backport was
+broken. That's not a point though. 
+I can't see why people that want last release of all must trust 3rd-party
+repos and do not mageia(or mandriva) backport one... it's really hard to me.
+
+I think we can, as said by someone, release all as updates, but we can also 
+consider to have a tested and reliable backport repository (call as you wish
+maybe "next" or "after" :) ) but the real concept to me is that we should
+have the availability to get new sw or version of a sw in a repository that 
+could be different than updates, *could* because case by case we could
+consider to add them in updates and in any case that should be reliable,
+no breakages, no regressions.
+
+We talked about patches, and sometime we could patch sw, but sometime
+it's hard, and updates with an upgrade of such a sw should be the best 
+thing to do. 
+
+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/20110626/2742f31c/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006049.html b/zarb-ml/mageia-dev/2011-June/006049.html new file mode 100644 index 000000000..86dfcfd48 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006049.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] autologin + consolekit + + + + + + + + + +

[Mageia-dev] autologin + consolekit

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Sun Jun 26 19:09:43 CEST 2011 +

+
+ +
'Twas brillig, and Colin Guthrie at 14/06/11 09:07 did gyre and gimble:
+> 'Twas brillig, and Colin Guthrie at 12/06/11 23:45 did gyre and gimble:
+>> Hi,
+>>
+>> The autologin package is broken due to the fact that it doesn't connect
+>> to consolekit and thus the user who is automatically logged in doesn't
+>> get any permissions etc.
+>>
+>> I've fixed this by changing the autologin pam.d definition to include
+>> "login" rather than "system-auth".
+>>
+>> login adds the optional session module for pam_ck_connector.
+>>
+>> But I'm not sure whether this makes sense, or whether we should just add
+>> the ck_connector to the autologin pam.d definition itself.
+>>
+>> There may be other login systems that have similar problems (e.g. the
+>> autologin features of gdm or slim etc) but I've not tested.
+>>
+>> Any thoughts.
+> 
+> Does anyone know what the right way to fix the above is?
+> 
+> I'd like to issue an update when appropriate to take care of this.
+
+Ping!!
+
+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-June/006050.html b/zarb-ml/mageia-dev/2011-June/006050.html new file mode 100644 index 000000000..dc8b1e038 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006050.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] [114150] downgrade to Version: 1 + + + + + + + + + +

[Mageia-dev] [114150] downgrade to Version: 1

+ Dexter Morgan + dmorganec at gmail.com +
+ Sun Jun 26 21:26:01 CEST 2011 +

+
+ +
On Sun, Jun 26, 2011 at 9:15 PM,  <root at mageia.org> wrote:
+> Revision 114150 Author spuhler Date 2011-06-26 21:14:59 +0200 (Sun, 26 Jun
+> 2011)
+>
+> Log Message
+>
+> downgrade to Version: 1
+> add subrel 1 for mga 1 updates
+
+why do you add subrel in cauldron ?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006051.html b/zarb-ml/mageia-dev/2011-June/006051.html new file mode 100644 index 000000000..fa85026e1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006051.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] [114173] added define subrel 1 to submit to Mageia1 updates + + + + + + + + + +

[Mageia-dev] [114173] added define subrel 1 to submit to Mageia1 updates

+ Dexter Morgan + dmorganec at gmail.com +
+ Sun Jun 26 21:37:29 CEST 2011 +

+
+ +
On Sun, Jun 26, 2011 at 9:34 PM,  <root at mageia.org> wrote:
+> Revision 114173 Author spuhler Date 2011-06-26 21:34:20 +0200 (Sun, 26 Jun
+> 2011)
+>
+> Log Message
+>
+> added define subrel 1 to submit to Mageia1 updates
+
+
+Please modify in the update/1 tree for updates not in the cauldron one
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006052.html b/zarb-ml/mageia-dev/2011-June/006052.html new file mode 100644 index 000000000..71246e267 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006052.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] Updates process is now available + + + + + + + + + +

[Mageia-dev] Updates process is now available

+ Thomas Spuhler + thomas at btspuhler.com +
+ Sun Jun 26 21:39:12 CEST 2011 +

+
+ +
On Tuesday, June 21, 2011 09:57:22 am Damien Lallement wrote:
+> Hello all,
+> 
+> security, qa and sysadmin team worked on the qa/updates process to
+> provide updates as soon as possible.
+> All is now ready (boklm is finalizing a scrip to move updates from
+> "testing" to "updates"). This script will be uses by security team
+> members and a few QA people to push updates.
+> 
+> You can now read:
+> - http://www.mageia.org/wiki/doku.php?id=updates_policy
+> - http://www.mageia.org/wiki/doku.php?id=qa_updates
+> 
+> A new ML has been created: qa-bugs at ml.mageia.org. It will receive all
+> the updates requests and will be the main QA contact for bugzilla.
+> You can join it if you want to be part of the QA people working on
+> updates (security or not).
+> 
+> A saved search has been added to bugzilla to catch all updates waiting
+> for QA validation:
+> https://bugs.mageia.org/buglist.cgi?cmdtype=runnamed&namedcmd=Updates%20wai
+> ting%20for%20QA
+> 
+> For more info, please ask here on on #mageia-dev or #mageia-qa
+> Let's go to work on updates!
+
+This seems not to be working for me. I am getting an error:
+
+error: command failed: ssh pkgsubmit.mageia.org /usr/local/bin/submit_package 
+-t 1 --define sid=9ed21bb1-462a-4c5b-9fa3-78e433ccc363 --define 
+section=core/updates_testing -r 114150 
+svn+ssh://svn.mageia.org/svn/packages/cauldron/kolab-webadmin
+error: svn+ssh://svn.mageia.org/svn/packages/cauldron/kolab-webadmin is not 
+allowed for this target
+
+(BTW on the web page it shows as -define section = instead of --define section)
+
+-- 
+Thomas
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006053.html b/zarb-ml/mageia-dev/2011-June/006053.html new file mode 100644 index 000000000..1516ec74a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006053.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] Updates process is now available + + + + + + + + + +

[Mageia-dev] Updates process is now available

+ Dexter Morgan + dmorganec at gmail.com +
+ Sun Jun 26 21:48:46 CEST 2011 +

+
+ +
On Sun, Jun 26, 2011 at 9:39 PM, Thomas Spuhler <thomas at btspuhler.com> wrote:
+> On Tuesday, June 21, 2011 09:57:22 am Damien Lallement wrote:
+>> Hello all,
+>>
+>> security, qa and sysadmin team worked on the qa/updates process to
+>> provide updates as soon as possible.
+>> All is now ready (boklm is finalizing a scrip to move updates from
+>> "testing" to "updates"). This script will be uses by security team
+>> members and a few QA people to push updates.
+>>
+>> You can now read:
+>> - http://www.mageia.org/wiki/doku.php?id=updates_policy
+>> - http://www.mageia.org/wiki/doku.php?id=qa_updates
+>>
+>> A new ML has been created: qa-bugs at ml.mageia.org. It will receive all
+>> the updates requests and will be the main QA contact for bugzilla.
+>> You can join it if you want to be part of the QA people working on
+>> updates (security or not).
+>>
+>> A saved search has been added to bugzilla to catch all updates waiting
+>> for QA validation:
+>> https://bugs.mageia.org/buglist.cgi?cmdtype=runnamed&namedcmd=Updates%20wai
+>> ting%20for%20QA
+>>
+>> For more info, please ask here on on #mageia-dev or #mageia-qa
+>> Let's go to work on updates!
+>
+> This seems not to be working for me. I am getting an error:
+>
+> error: command failed: ssh pkgsubmit.mageia.org /usr/local/bin/submit_package
+> -t 1 --define sid=9ed21bb1-462a-4c5b-9fa3-78e433ccc363 --define
+> section=core/updates_testing -r 114150
+> svn+ssh://svn.mageia.org/svn/packages/cauldron/kolab-webadmin
+> error: svn+ssh://svn.mageia.org/svn/packages/cauldron/kolab-webadmin is not
+> allowed for this target
+>
+> (BTW on the web page it shows as -define section = instead of --define section)
+>
+> --
+> Thomas
+>
+
+because you need to modify on the update branch of the SVN
+
+mgarepo -d 1 kolab-webadmin
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006054.html b/zarb-ml/mageia-dev/2011-June/006054.html new file mode 100644 index 000000000..c1764772c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006054.html @@ -0,0 +1,64 @@ + + + + [Mageia-dev] Updates process is now available + + + + + + + + + +

[Mageia-dev] Updates process is now available

+ Samuel Verschelde + stormi at laposte.net +
+ Sun Jun 26 22:38:45 CEST 2011 +

+
+ +
Le dimanche 26 juin 2011 21:39:12, Thomas Spuhler a écrit :
+> (BTW on the web page it shows as -define section = instead of --define
+> section)
+
+Fixed now, this wiki automatically turns -- into a long -
+
+Samuel
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006055.html b/zarb-ml/mageia-dev/2011-June/006055.html new file mode 100644 index 000000000..c6b4d1ff7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006055.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] [114173] added define subrel 1 to submit to Mageia1 updates + + + + + + + + + +

[Mageia-dev] [114173] added define subrel 1 to submit to Mageia1 updates

+ Thomas Spuhler + thomas at btspuhler.com +
+ Mon Jun 27 00:59:09 CEST 2011 +

+
+ +
On Sunday, June 26, 2011 12:37:29 pm Dexter Morgan wrote:
+> On Sun, Jun 26, 2011 at 9:34 PM,  <root at mageia.org> wrote:
+> > Revision 114173 Author spuhler Date 2011-06-26 21:34:20 +0200 (Sun, 26
+> > Jun 2011)
+> > 
+> > Log Message
+> > 
+> > added define subrel 1 to submit to Mageia1 updates
+> 
+> Please modify in the update/1 tree for updates not in the cauldron one
+
+Did I do better now?
+
+-- 
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006056.html b/zarb-ml/mageia-dev/2011-June/006056.html new file mode 100644 index 000000000..86554e8fd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006056.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] [114173] added define subrel 1 to submit to Mageia1 updates + + + + + + + + + +

[Mageia-dev] [114173] added define subrel 1 to submit to Mageia1 updates

+ Dexter Morgan + dmorganec at gmail.com +
+ Mon Jun 27 01:24:26 CEST 2011 +

+
+ +
On Mon, Jun 27, 2011 at 12:59 AM, Thomas Spuhler <thomas at btspuhler.com> wrote:
+> On Sunday, June 26, 2011 12:37:29 pm Dexter Morgan wrote:
+>> On Sun, Jun 26, 2011 at 9:34 PM,  <root at mageia.org> wrote:
+>> > Revision 114173 Author spuhler Date 2011-06-26 21:34:20 +0200 (Sun, 26
+>> > Jun 2011)
+>> >
+>> > Log Message
+>> >
+>> > added define subrel 1 to submit to Mageia1 updates
+>>
+>> Please modify in the update/1 tree for updates not in the cauldron one
+>
+> Did I do better now?
+>
+> --
+> Thomas
+>
+
+now this is perfect :) ( btw have you removed subrel from the cauldron tree ? )
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006057.html b/zarb-ml/mageia-dev/2011-June/006057.html new file mode 100644 index 000000000..2a8fe3c10 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006057.html @@ -0,0 +1,110 @@ + + + + [Mageia-dev] [114173] added define subrel 1 to submit to Mageia1 updates + + + + + + + + + +

[Mageia-dev] [114173] added define subrel 1 to submit to Mageia1 updates

+ Thomas Spuhler + thomas at btspuhler.com +
+ Mon Jun 27 01:49:01 CEST 2011 +

+
+ +
On Sunday, June 26, 2011 04:24:26 pm Dexter Morgan wrote:
+> On Mon, Jun 27, 2011 at 12:59 AM, Thomas Spuhler <thomas at btspuhler.com> 
+wrote:
+> > On Sunday, June 26, 2011 12:37:29 pm Dexter Morgan wrote:
+> >> On Sun, Jun 26, 2011 at 9:34 PM,  <root at mageia.org> wrote:
+> >> > Revision 114173 Author spuhler Date 2011-06-26 21:34:20 +0200 (Sun, 26
+> >> > Jun 2011)
+> >> > 
+> >> > Log Message
+> >> > 
+> >> > added define subrel 1 to submit to Mageia1 updates
+> >> 
+> >> Please modify in the update/1 tree for updates not in the cauldron one
+> > 
+> > Did I do better now?
+> > 
+> > --
+> > Thomas
+> 
+> now this is perfect :) ( btw have you removed subrel from the cauldron tree
+> ? )
+
+yep
+
+-- 
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006058.html b/zarb-ml/mageia-dev/2011-June/006058.html new file mode 100644 index 000000000..b50bf9205 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006058.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] Updates going to Release? + + + + + + + + + +

[Mageia-dev] Updates going to Release?

+ David W. Hodgins + davidwhodgins at gmail.com +
+ Mon Jun 27 03:11:28 CEST 2011 +

+
+ +
On my Mageia 1 install ...
+
+urpmi --auto-select --resume --noclean
+To satisfy dependencies, the following packages are going to be installed:
+    Package                        Version      Release       Arch
+(medium "Core Release")
+   libxine1                       1.1.19       5.mga1        i586
+(medium "Tainted Release")
+   libvlc-devel                   1.1.9        4.mga1.taint> i586
+
+I thought updates, and new programs would go to
+Core Updates, and Tainted updates, not Release.
+
+That way the release synthesis.hdlist.cz wouldn't get changed.
+
+Regards, Dave Hodgins
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006059.html b/zarb-ml/mageia-dev/2011-June/006059.html new file mode 100644 index 000000000..1a15ce74e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006059.html @@ -0,0 +1,112 @@ + + + + [Mageia-dev] Updates going to Release? + + + + + + + + + +

[Mageia-dev] Updates going to Release?

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Mon Jun 27 03:41:00 CEST 2011 +

+
+ +
On 27 June 2011 03:11, David W. Hodgins <davidwhodgins at gmail.com> wrote:
+> On my Mageia 1 install ...
+>
+> urpmi --auto-select --resume --noclean
+> To satisfy dependencies, the following packages are going to be installed:
+>   Package                        Version      Release       Arch
+> (medium "Core Release")
+>  libxine1                       1.1.19       5.mga1        i586
+> (medium "Tainted Release")
+>  libvlc-devel                   1.1.9        4.mga1.taint> i586
+>
+> I thought updates, and new programs would go to
+> Core Updates, and Tainted updates, not Release.
+>
+> That way the release synthesis.hdlist.cz wouldn't get changed.
+>
+> Regards, Dave Hodgins
+>
+
+vlc-1.1.9-4.mga1.tainted existed in the tainted/release repo before
+Mageia 1 was ever released, so it's not an update.
+
+Tainted packages have a higher EVR than core ones
+(vlc-1.1.9-4.mga1.i586 vs. vlc-1.1.9-4.mga1.tainted.i586), hence urpmi
+proposed to replace vlc from core by vlc from tainted.
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006060.html b/zarb-ml/mageia-dev/2011-June/006060.html new file mode 100644 index 000000000..2e07fb99c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006060.html @@ -0,0 +1,118 @@ + + + + [Mageia-dev] Updates going to Release? + + + + + + + + + +

[Mageia-dev] Updates going to Release?

+ David W. Hodgins + davidwhodgins at gmail.com +
+ Mon Jun 27 04:41:19 CEST 2011 +

+
+ +
On Sun, 26 Jun 2011 21:41:00 -0400, Ahmad Samir <ahmadsamir3891 at gmail.com> wrote:
+
+> On 27 June 2011 03:11, David W. Hodgins <davidwhodgins at gmail.com> wrote:
+>> On my Mageia 1 install ...
+>>
+>> urpmi --auto-select --resume --noclean
+>> To satisfy dependencies, the following packages are going to be installed:
+>>   Package                        Version      Release       Arch
+>> (medium "Core Release")
+>>  libxine1                       1.1.19       5.mga1        i586
+>> (medium "Tainted Release")
+>>  libvlc-devel                   1.1.9        4.mga1.taint> i586
+
+> vlc-1.1.9-4.mga1.tainted existed in the tainted/release repo before
+> Mageia 1 was ever released, so it's not an update.
+
+Ok, got it.  I had installed vlc before enabling tainted.
+
+> Tainted packages have a higher EVR than core ones
+> (vlc-1.1.9-4.mga1.i586 vs. vlc-1.1.9-4.mga1.tainted.i586), hence urpmi
+> proposed to replace vlc from core by vlc from tainted.
+
+With libxine1, though it's strange. The log shows I ran
+urpmi: called with: -a --fuzzy xine-
+which installed libxine1-1.1.19-4.mga1.tainted.i586.
+
+When I ran the auto-select it installed
+libxine1-1.1.19-5.mga1.i586 from Core, replacing the tainted version.
+
+That makes sense as 19-5 is greater than 19-4.  I don't understand
+is why the first urpmi command didn't select the 19-5 version, while
+the update did.
+
+Also why they aren't both 19-5.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006061.html b/zarb-ml/mageia-dev/2011-June/006061.html new file mode 100644 index 000000000..905384d36 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006061.html @@ -0,0 +1,134 @@ + + + + [Mageia-dev] Updates going to Release? + + + + + + + + + +

[Mageia-dev] Updates going to Release?

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Mon Jun 27 07:51:55 CEST 2011 +

+
+ +
On 27 June 2011 04:41, David W. Hodgins <davidwhodgins at gmail.com> wrote:
+> On Sun, 26 Jun 2011 21:41:00 -0400, Ahmad Samir <ahmadsamir3891 at gmail.com>
+> wrote:
+>
+>> On 27 June 2011 03:11, David W. Hodgins <davidwhodgins at gmail.com> wrote:
+>>>
+>>> On my Mageia 1 install ...
+>>>
+>>> urpmi --auto-select --resume --noclean
+>>> To satisfy dependencies, the following packages are going to be
+>>> installed:
+>>>  Package                        Version      Release       Arch
+>>> (medium "Core Release")
+>>>  libxine1                       1.1.19       5.mga1        i586
+>>> (medium "Tainted Release")
+>>>  libvlc-devel                   1.1.9        4.mga1.taint> i586
+>
+>> vlc-1.1.9-4.mga1.tainted existed in the tainted/release repo before
+>> Mageia 1 was ever released, so it's not an update.
+>
+> Ok, got it.  I had installed vlc before enabling tainted.
+>
+>> Tainted packages have a higher EVR than core ones
+>> (vlc-1.1.9-4.mga1.i586 vs. vlc-1.1.9-4.mga1.tainted.i586), hence urpmi
+>> proposed to replace vlc from core by vlc from tainted.
+>
+> With libxine1, though it's strange. The log shows I ran
+> urpmi: called with: -a --fuzzy xine-
+> which installed libxine1-1.1.19-4.mga1.tainted.i586.
+>
+> When I ran the auto-select it installed
+> libxine1-1.1.19-5.mga1.i586 from Core, replacing the tainted version.
+>
+> That makes sense as 19-5 is greater than 19-4.  I don't understand
+> is why the first urpmi command didn't select the 19-5 version, while
+> the update did.
+
+Indeed, ideally the release of both of core and tainted are kept in
+sync, this is a glitch, i.e. someone submitted to core/release and
+forgot to submit to tainted/release, or he submitted to tainted but
+the build failed... etc. Please open a bug report about that one.
+
+>
+> Also why they aren't both 19-5.
+>
+
+
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006062.html b/zarb-ml/mageia-dev/2011-June/006062.html new file mode 100644 index 000000000..9922fa3c7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006062.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] [114362] - update version + + + + + + + + + +

[Mageia-dev] [114362] - update version

+ Jani Välimaa + jani.valimaa at gmail.com +
+ Mon Jun 27 11:45:13 CEST 2011 +

+
+ +
2011/6/27  <root at mageia.org>:
+> Revision 114362 Author kharec Date 2011-06-27 09:44:45 +0200 (Mon, 27 Jun
+> @@ -84,5 +84,5 @@
+>  %lang(pl) %_mandir/pl/man1/gramps.1.*
+>  %lang(sv) %_mandir/sv/man1/gramps.1.*
+>  %{_iconsdir}/hicolor/*/apps/%{name}.png
+> +%_mandir/cs/man1/gramps.1.xz
+>
+
+IIRC '%find_lang --with-man' handles localized man pages.
+
+There's no need to set %lang(xx) manually to files (as it is done by
+all other man pages in this package) or add localized man files to
+file list at all..
+
+-- 
+Jani Välimaa
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006063.html b/zarb-ml/mageia-dev/2011-June/006063.html new file mode 100644 index 000000000..27e7676d1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006063.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] How is the obsoleted binaries be removed? + + + + + + + + + +

[Mageia-dev] How is the obsoleted binaries be removed?

+ Funda Wang + fundawang at gmail.com +
+ Mon Jun 27 18:00:38 CEST 2011 +

+
+ +
Hello,
+
+How is the obsoleted binaries be removed currently in Mageia? Does the
+maintainer need to call for this? If yes, please remove
+lib{,64}devhelp-2_1 from cauldron.
+
+Thanks.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006064.html b/zarb-ml/mageia-dev/2011-June/006064.html new file mode 100644 index 000000000..4f786aec0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006064.html @@ -0,0 +1,111 @@ + + + + [Mageia-dev] Looking for a mentor in packaging... + + + + + + + + + +

[Mageia-dev] Looking for a mentor in packaging...

+ Thomas Lottmann + skipercooker at gmail.com +
+ Mon Jun 27 19:28:42 CEST 2011 +

+
+ +
Hello everyone,
+
+I am starting to have a little bit more time currently and I would like 
+to start packaging for Mageia, essentially software that worth it and 
+that I use. As Mageia is now a community project, I guess I need to 
+start involving myself to encourage the efforts that are in. So I might 
+accept to maintain unmaintained packages as well.
+
+I will read and reread in the following days the sheets for packaging in 
+Mageia, but I think a little help from a kind person wouldn't be bad, as 
+I have already attempted packaging for Mandriva Linux in the past, but 
+with a lot of difficulties. In this way, I would like to understand how 
+the Mageia system works.
+
+Would someone lend me a hand?
+
+Thank you,
+
+Thomas aka Skiper.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006065.html b/zarb-ml/mageia-dev/2011-June/006065.html new file mode 100644 index 000000000..92fb2b762 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006065.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] Looking for a mentor in packaging... + + + + + + + + + +

[Mageia-dev] Looking for a mentor in packaging...

+ magnus + magnus.mud at googlemail.com +
+ Mon Jun 27 19:35:40 CEST 2011 +

+
+ +
2011/6/27 Thomas Lottmann <skipercooker at gmail.com>
+
+>
+> Thanks for your proposal, of course any help on packaging side is welcome.
+Here are some wiki page to read about mentoring process:
+http://mageia.org/wiki/doku.php?id=packaging&s[]=mentor#packagers_organization
+http://mageia.org/wiki/doku.php?id=packaging&s[]=mentor#resources
+http://mageia.org/wiki/doku.php?id=packages_mentoring
+and
+http://mageia.org/wiki/doku.php?id=packager_start
+
+You can apply here on -dev ML looking for a mentor
+
+Also there is a weekly meeting on IRC you can attend if you are around
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110627/f177f30e/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006066.html b/zarb-ml/mageia-dev/2011-June/006066.html new file mode 100644 index 000000000..4cb983767 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006066.html @@ -0,0 +1,116 @@ + + + + [Mageia-dev] Looking for a mentor in packaging... + + + + + + + + + +

[Mageia-dev] Looking for a mentor in packaging...

+ Thomas Lottmann + skipercooker at gmail.com +
+ Mon Jun 27 20:06:49 CEST 2011 +

+
+ +
Le 27/06/2011 19:35, magnus a écrit :
+>
+>
+> 2011/6/27 Thomas Lottmann <skipercooker at gmail.com
+> <mailto:skipercooker at gmail.com>>
+>
+>
+> Thanks for your proposal, of course any help on packaging side is welcome.
+> Here are some wiki page to read about mentoring process:
+> http://mageia.org/wiki/doku.php?id=packaging&s[]=mentor#packagers_organization
+> <http://mageia.org/wiki/doku.php?id=packaging&s[]=mentor#packagers_organization>
+> http://mageia.org/wiki/doku.php?id=packaging&s[]=mentor#resources
+> <http://mageia.org/wiki/doku.php?id=packaging&s[]=mentor#resources>
+> http://mageia.org/wiki/doku.php?id=packages_mentoring
+> and
+> http://mageia.org/wiki/doku.php?id=packager_start
+>
+> You can apply here on -dev ML looking for a mentor
+>
+> Also there is a weekly meeting on IRC you can attend if you are around
+>
+
+Thank you for your quick answer. I will read these pages anytime soon 
+and start trying on my side at first.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006067.html b/zarb-ml/mageia-dev/2011-June/006067.html new file mode 100644 index 000000000..694189b22 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006067.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] Looking for a mentor in packaging... + + + + + + + + + +

[Mageia-dev] Looking for a mentor in packaging...

+ magnus + magnus.mud at googlemail.com +
+ Mon Jun 27 20:14:22 CEST 2011 +

+
+ +
2011/6/27 Thomas Lottmann <skipercooker at gmail.com>
+
+> Thank you for your quick answer. I will read these pages anytime soon and
+> start trying on my side at first.
+>
+de riens
+
+Mageia is building a mentoring program/team  with andre999 as "mentoring
+program coodinator" helped by Daniel Kreuter.
+So things are growing.
+Welcome and a good start.
+
+Magnus
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110627/425f75af/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006068.html b/zarb-ml/mageia-dev/2011-June/006068.html new file mode 100644 index 000000000..157c1c8bf --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006068.html @@ -0,0 +1,129 @@ + + + + [Mageia-dev] Looking for a mentor in packaging... + + + + + + + + + +

[Mageia-dev] Looking for a mentor in packaging...

+ Daniel Kreuter + daniel.kreuter85 at googlemail.com +
+ Mon Jun 27 20:18:29 CEST 2011 +

+
+ +
On Mon, Jun 27, 2011 at 8:14 PM, magnus <magnus.mud at googlemail.com> wrote:
+
+>
+>
+> 2011/6/27 Thomas Lottmann <skipercooker at gmail.com>
+>
+>> Thank you for your quick answer. I will read these pages anytime soon and
+>> start trying on my side at first.
+>>
+> de riens
+>
+> Mageia is building a mentoring program/team  with andre999 as "mentoring
+> program coodinator" helped by Daniel Kreuter.
+> So things are growing.
+> Welcome and a good start.
+>
+> Magnus
+>
+>
+>
+Hello Thomas,
+
+nice that you like to join the packager team. You can also ask on irc if
+someone is able to mentor you (on #mageia-dev or #mageia-mentoring).
+
+We will soon have a page on wiki where people can put his name on for
+seeking a mentor, too.
+
+-- 
+Mit freundlichen Grüßen
+
+Greetings
+
+Daniel Kreuter
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110627/0f6d1d2d/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006069.html b/zarb-ml/mageia-dev/2011-June/006069.html new file mode 100644 index 000000000..8210dba22 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006069.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] Looking for a mentor in packaging... + + + + + + + + + +

[Mageia-dev] Looking for a mentor in packaging...

+ Radu-Cristian FOTESCU + beranger5ca at yahoo.ca +
+ Mon Jun 27 20:40:27 CEST 2011 +

+
+ +
+
+We will soon have a page on wiki where people can put his name on for seeking a mentor, too.
+>Oh, is it not this one?http://mageia.org/wiki/doku.php?id=packaging#list_of_registered_people
+It thought it was a list for people wanting to become packagers (although some people already are mga packagers), so I've added my name there too.
+
+I too said I need mentoring / I want to take care of some packages in mga.
+In the meantime, I am on my own: http://mageia.beranger.org/mageia/
+
+Cheers,
+R-C aka beranger
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110627/99b6d2c4/attachment-0001.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006070.html b/zarb-ml/mageia-dev/2011-June/006070.html new file mode 100644 index 000000000..5e390c024 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006070.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Mon Jun 27 21:17:22 CEST 2011 +

+
+ +
'Twas brillig, and Michael Scherer at 25/06/11 23:16 did gyre and gimble:
+>> we
+>> always say that backports should mainly be cherry picked, but not
+>> enabled all the time... so how does installing a new version of e.g.
+>> wine break the user's system when he can easily back out that rpm?
+> 
+> I a not sure that most people realize they can revert. Maybe a easier
+> interface to do that could be offered ( along maybe with a tool that
+> send feedback on why it did downgrade it ? ).
+
+I've seen various ppa-purge commands being dished out for custom PPAs on
+Ubuntu. It looks like quite a nice idea, but only really applies for
+individual use archives (e.g. help us test the development version of
+$foo), not a general purpose one like "backports".
+
+That said, a GUI which detected that certain packages have come from
+backports and offers and easy mechanism to "switch" back to the older
+one from release or updates would, IMO, be a plus.
+
+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-June/006071.html b/zarb-ml/mageia-dev/2011-June/006071.html new file mode 100644 index 000000000..9211cf80e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006071.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ John + john at neodoc.biz +
+ Mon Jun 27 23:55:59 CEST 2011 +

+
+ +
On Mon, 27 Jun 2011 20:17:22 +0100
+Colin Guthrie wrote:
+
+> 'Twas brillig, and Michael Scherer at 25/06/11 23:16 did gyre and gimble:
+> >> we
+> >> always say that backports should mainly be cherry picked, but not
+> >> enabled all the time... so how does installing a new version of e.g.
+> >> wine break the user's system when he can easily back out that rpm?
+> > 
+> > I a not sure that most people realize they can revert. Maybe a easier
+> > interface to do that could be offered ( along maybe with a tool that
+> > send feedback on why it did downgrade it ? ).
+> 
+> I've seen various ppa-purge commands being dished out for custom PPAs on
+> Ubuntu. It looks like quite a nice idea, but only really applies for
+> individual use archives (e.g. help us test the development version of
+> $foo), not a general purpose one like "backports".
+> 
+> That said, a GUI which detected that certain packages have come from
+> backports and offers and easy mechanism to "switch" back to the older
+> one from release or updates would, IMO, be a plus.
+
+Rpms from Tainted have 'tainted' in the filename - why not do the same for
+backports? Surely that would make their identification a little simpler?
+
+John NZ
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006072.html b/zarb-ml/mageia-dev/2011-June/006072.html new file mode 100644 index 000000000..f25fc2199 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006072.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Michael Scherer + misc at zarb.org +
+ Tue Jun 28 00:31:41 CEST 2011 +

+
+ +
Le mardi 28 juin 2011 à 09:55 +1200, John a écrit :
+> On Mon, 27 Jun 2011 20:17:22 +0100
+> Colin Guthrie wrote:
+
+> > That said, a GUI which detected that certain packages have come from
+> > backports and offers and easy mechanism to "switch" back to the older
+> > one from release or updates would, IMO, be a plus.
+> 
+> Rpms from Tainted have 'tainted' in the filename - why not do the same for
+> backports? Surely that would make their identification a little simpler?
+
+Detection is not that hard. If the release is superior to the one in
+release/update, this is a backport. That's trivial from a conception
+point of view.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006073.html b/zarb-ml/mageia-dev/2011-June/006073.html new file mode 100644 index 000000000..4cb03d430 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006073.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] autologin + consolekit + + + + + + + + + +

[Mageia-dev] autologin + consolekit

+ andre999 + andr55 at laposte.net +
+ Tue Jun 28 03:42:26 CEST 2011 +

+
+ +
Colin Guthrie a écrit :
+>
+> 'Twas brillig, and Colin Guthrie at 14/06/11 09:07 did gyre and gimble:
+>> 'Twas brillig, and Colin Guthrie at 12/06/11 23:45 did gyre and gimble:
+>>> Hi,
+>>>
+>>> The autologin package is broken due to the fact that it doesn't connect
+>>> to consolekit and thus the user who is automatically logged in doesn't
+>>> get any permissions etc.
+>>>
+>>> I've fixed this by changing the autologin pam.d definition to include
+>>> "login" rather than "system-auth".
+>>>
+>>> login adds the optional session module for pam_ck_connector.
+>>>
+>>> But I'm not sure whether this makes sense, or whether we should just add
+>>> the ck_connector to the autologin pam.d definition itself.
+>>>
+>>> There may be other login systems that have similar problems (e.g. the
+>>> autologin features of gdm or slim etc) but I've not tested.
+>>>
+>>> Any thoughts.
+>>
+>> Does anyone know what the right way to fix the above is?
+>>
+>> I'd like to issue an update when appropriate to take care of this.
+>
+> Ping!!
+>
+> Col
+
+A while back when I was playing with an alternate version of an application which 
+required authentification, I added the application name to some pam-related file, and it 
+worked.
+I forget the details.  I just did something parallel to what other some applications did.
+That seems to be what you're doing ?
+I'm far from being an expert.
+Hope that helps.
+
+-- 
+André
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006074.html b/zarb-ml/mageia-dev/2011-June/006074.html new file mode 100644 index 000000000..4d7726bdf --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006074.html @@ -0,0 +1,136 @@ + + + + [Mageia-dev] Backports policy proposal + + + + + + + + + +

[Mageia-dev] Backports policy proposal

+ andre999 + andr55 at laposte.net +
+ Tue Jun 28 03:42:48 CEST 2011 +

+
+ +
Michael Scherer a écrit :
+>
+> Le vendredi 24 juin 2011 à 16:20 -0400, andre999 a écrit :
+>> Michael Scherer a écrit :
+
+[...]
+
+>>> - cannot be backported if the package was just created and is thus basically untested in cauldron
+>>
+>> What about corner cases where a potential backport is incompatible with changes introduced in
+>> cauldron ?  Should we leave such packages to third parties ?  (I would tend to say yes.)
+>
+> Give a more precise example.
+
+Suppose leaf package fooa depends on foob.  foob is part of the current release.
+Cauldron replaces foob with fooc.  fooa is incompatible with fooc.
+fooa is requested by some users, and future versions of fooa are intended to be 
+compatible with fooc.
+In this case, even though it wouldn't be testable in cauldron, it could be tested in 
+backports-testing, and I think it could be a good idea to allow it.
+Even if fooc compatibility wouldn't be available for the next Mageia release, a user 
+could avoid updating for a release in order to keep using fooa.
+However, if there were no intention to make fooa compatible with fooc, maybe it should 
+be denied.
+
+>>> - must not prevent upgrade to next release
+>>
+>> I can see where a backport could be a more recent version than in cauldron for the moment.  Since
+>> that could make the newer version available to users somewhat sooner.  Although by release,
+>> cauldron should have at least as recent a version.  Or should we prohibit this ?
+>> (I'm thinking of cases where more recent versions are expected for cauldron before release.)
+>
+> If we decide to use the spec from cauldron on stable ( as it seems to be
+> the sanest way of doing it ), the only way to have a newer version in
+> stable than in cauldron would be to have the build broken on cauldron.
+>
+> If we tolerate this, and if no one fix ( because the person that did the
+> upgrade only care about stable release ), we have a broken build.
+>
+> So forcing the build to be correct on cauldron would be a stronger
+> incentive to fix. It seems more desirable to prevent a backport if the
+> price to pay is to have a potentially broken cauldron package.
+
+Good point.  Possibly a little more work for the moment, for greater stability.
+But the example in the previous case above gives an exception -- which might be 
+reasonable to allow.
+
+[...]
+
+>> I like the idea of tagging backports in the package name, as well as in the package database.
+>
+> We cannot tag in the packages database. Yum do it with a separate sqlite
+> file, afaik.
+
+I would like to see the source repository info available for every installed package.
+Maybe even stored somewhere in the .rpm file, also.
+Is concerns for upstream compatibility for rpm or urpm* the a reason why we can't add 
+new fields to the packages database ?
+(Although a parallel sqlite file would work.)
+
+> And tagging in the package name would be quite tricky to do if we need
+> to play with %mkrel and release.
+
+Right.  I thought about this afterwards.
+
+
+-- 
+André
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006075.html b/zarb-ml/mageia-dev/2011-June/006075.html new file mode 100644 index 000000000..786a02731 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006075.html @@ -0,0 +1,135 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ andre999 + andr55 at laposte.net +
+ Tue Jun 28 03:43:49 CEST 2011 +

+
+ +
Samuel Verschelde a écrit :
+>
+> Le vendredi 24 juin 2011 21:39:51, Ahmad Samir a écrit :
+>> On 24 June 2011 02:09, Michael Scherer<misc at zarb.org>  wrote:
+
+...
+
+>>> - I am not sure on this part, but basically, we have 2 choices :
+>>>   - the packager take the cauldron package and push to backport testing
+>>>   - the packager move the cauldron package in svn to backport, and there
+>>> send it to backport testing.
+>>>
+>>> Proposal 1 mean less work duplication, but proposal 2 let us do more
+>>> customization.
+>>
+>> Option 1 doesn't only mean not duplicating work, but also that the the
+>> spec in backports svn isn't ever out-dated; the only reason I see a
+>> package being in stable distro SVN is if it's in /release|updates, not
+>> backports...
+>
+> I'm not sure I understand your point. What do you mean with out-dated specs in
+> backports ?
+> I favor option 2 (with all needed useful shortcuts in mgarepo and BS to make
+> it simple for packagers) because it allows to cope with the following
+> situation :
+> - foo is in version 1.2.2 in release|updates
+> - foo is in version 2.0alpha in cauldron, full of bugs but hopefully ready for
+> the next stable release
+> - the latest release in the 1.x branch, 1.3.0, brings many features requested
+> by some users, we want to provide it as a backport : with option 1 we can't,
+> with option 2 we can.
+>
+> or :
+> - foo is in version 1.2.2 in release|updates
+> - foo is in version 2.0alpha in cauldron, full of bugs but hopefully ready for
+> the next stable release
+> - we had backported version 1.2.6 before switching to 2.0alpha in cauldron
+> - the backported version 1.2.6 has a big bug we hadn't spotted during tests
+> and we want to fix in the backport : with option 1 we can't, with option 2 we
+> can.
+>
+> So, for me, this is definitely option 2.
+
+Given this explanation, I would definitely go for option 2 as well.
+
+> However, I think it must be made a painless as possible to packagers :
+> - in the common case, allow to submit directly from cauldron to the backports
+> media, but let the BS detect that and automatically do the SVN copy part.
+> - for the situations I described above, work with the backport branch
+> similarly as we work on updates (technically speaking : SVN, BS...).
+
+Sound good to me.
+
+>>> if the package doesn't build, the packager fix ( or drop the idea if
+>>> this requires too much work )
+>>>
+>>> - the packager send requesting feedback about the backport from the
+>>> people who requested it, and test it as well.
+>>
+>> Probably off-topic, but how will that work with madb? i.e. how will
+>> the maintainer get the feedback?
+>
+> I partially answered above : either via bugzilla, or via a simple tracking
+> system included in madb for that need. It will depend on the chosen process,
+> we'll try to adapt the tool to the situation.
+
+I tend to like the idea of using bugzilla with a streamlined template, to avoid 
+unnecessary duplication of code to be maintained.
+But if madb can track things better, and it can be readily developed, that sounds good.
+As for packagers, it shouldn't make much difference if the tools are done right.
+
+> Best regards
+>
+> Samuel Verschelde
+
+Regards
+
+-- 
+André
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006076.html b/zarb-ml/mageia-dev/2011-June/006076.html new file mode 100644 index 000000000..c45a5fcc5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006076.html @@ -0,0 +1,173 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ andre999 + andr55 at laposte.net +
+ Tue Jun 28 03:44:24 CEST 2011 +

+
+ +
Michael Scherer a écrit :
+
+>> However I would favour notifying those who have installed previous versions of these backports, of
+>> the availability of newer versions.
+>
+> The question is "how".
+
+Good question :)
+We could send emails to those who have contributed to the backport issue (bugzilla or 
+madb), including the requester and packager.  The latter may not be the same as packaged 
+the previous backport.
+We could also add a mechanism in rpmdrake and/or urpmi which gives a user the choice of 
+opting in to notification when they install a backport.
+
+>> For security issues, I'm not sure that it is important how we find out.
+>> As far as responsibility, I think the main responibility should be by the packager, but it could be
+>> useful for the security team to monitor it, to find an alternate packager if necessary.
+>> (Presumably from those who have tested or installed the package.)
+>> (I don't know who monitors security issues now, I just assume the security team.)
+>>
+>> However I think that such packages should be tested as normally for backports, and then treated as
+>> security updates, to be automatically applied.
+>
+> If we place it in a repository that is enabled by default, we will
+> basically do a version upgrade for every people that have it enabled.
+>
+> If this is updates, this would violate our own policy.
+>
+> If we place in backports, it is not enabled by default.
+
+I have a response to that below.
+
+>> This is because those who have installed the backport in question have decided to accept a higher
+>> degree of risk.  However a security issue can be a much greater risk, and is something that is
+>> normally resolved automatically.  So by installing a security bug fix automatically for a backport,
+>> we are essentially maintaining the level of risk already assumed by the user.
+>
+> So that basically mean "unsupported".
+
+The intent is to support for security issues.
+
+> There is even more tricky problems :
+> Let's take a software that release soon, release often. Let's say a voip
+> software.
+>
+> Someone install version 1.0 from release. So far, so good, but he hear
+> that 1.1 is out, and he install it from backport ( after requesting ).
+> He is satisfied, then the developers of our voip software decide to
+> create a version 2.0, with a completely new interface but the ui is yet
+> unfinished and untranslated, so our user cannot use it. Yet, someone
+> request a backport, and let's assume we do it.
+>
+> With our current scheme, our user will not be affected and he doesn't
+> want to upgrade. So he keep the version 1.1.
+>
+> A security issue is discovered, in 1.X and 2.X.
+>
+> 1.0-2 is sent to release update, with security fix.
+> 2.1 is sent to backport, as the packager follow the list.
+>
+> What should be done for the user :
+> Force upgrade to the next major release ?
+> Ask him to revert to release update ?
+> Tell him "this is not supported" ?
+>
+> Or maybe we should not have upgraded to 2.0 if we knew that current user
+> would refuse it ?
+
+All these points you raise are interesting.  After reflexion, I think this will work :
+
+1) A condition of backports is that the backport packager commits to packaging any 
+security updates that arise.  (s/he could designate an alternate.)
+(I would expect that most backports would not be very vulnerable, but of course any 
+dealing with Internet access or arbitrary 3-party files are more likely to be.)
+
+2) Backports would not be removed from repos when a newer backport arrives, except those 
+affected by security updates.
+This allows reverting to previous backports if a user finds a problem with a backport on 
+their system.
+
+3) Security fixes must be created for all affected backports.
+This means that if 4 backports exist for an application, and all 4 are affected by the 
+security problem, we have to make 4 security fixes.  If only 2 of 4 are affected, those 
+2 would require security fixes.
+
+4) Security fixes would be applied automatically by the security update mechanism.
+Only the corresponding update repo need be activated for this to happen.
+However, security fixes from backports would only be applied to specific backports.
+So for version 1.0 in release, and versions 1.1 , 1.2 and 1.3 in backports,
+with a security fix 1.0-1 for release,
+we would also create fixes 1.1-1 , 1.2-1 , and 1.3-1
+to be applied to backports 1.1 , 1.2 and 1,3 respectively (assuming all are affected).
+
+These security fixes for backports could be in the backport repo if properly tracked by 
+the security update mechanism.
+This means that there has to be a modification of the security update mechanism to 
+ensure that the updates to backports are only applied to the appropriate backport.
+
+
+Does this sound workable ?
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006077.html b/zarb-ml/mageia-dev/2011-June/006077.html new file mode 100644 index 000000000..3db47f7d0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006077.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ andre999 + andr55 at laposte.net +
+ Tue Jun 28 03:44:53 CEST 2011 +

+
+ +
Sander Lepik a écrit :
+>
+> 24.06.2011 03:15, Michael Scherer kirjutas:
+
+[ ... ]
+
+> Reading comments here and knowing that our QA team is in trouble already
+> - i don't see how would QA handle backports. I can also see that there
+> might come time when backports are unpatched and thus unsecure.
+
+The idea is to use the packager and backport requesters to test the backports, in place 
+of the QA team.  This is considered adequate since backports would be "leaf" packages 
+(on which no other package is dependant), and so the packages need only be tested to 
+ensure that they work.
+Of course for security issues, we have to be a little more careful.
+
+> --
+> Sander
+>
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006078.html b/zarb-ml/mageia-dev/2011-June/006078.html new file mode 100644 index 000000000..965d520bb --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006078.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] KDE 4.7? + + + + + + + + + +

[Mageia-dev] KDE 4.7?

+ Funda Wang + fundawang at gmail.com +
+ Tue Jun 28 07:40:43 CEST 2011 +

+
+ +
Hello,
+
+Is it the time we go with kde 4.7 (rc currently) within cauldron?
+
+Regards.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006079.html b/zarb-ml/mageia-dev/2011-June/006079.html new file mode 100644 index 000000000..c02d2fccd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006079.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] KDE 4.7? + + + + + + + + + +

[Mageia-dev] KDE 4.7?

+ Dexter Morgan + dmorganec at gmail.com +
+ Tue Jun 28 08:18:14 CEST 2011 +

+
+ +
On Tue, Jun 28, 2011 at 7:40 AM, Funda Wang <fundawang at gmail.com> wrote:
+> Hello,
+>
+> Is it the time we go with kde 4.7 (rc currently) within cauldron?
+>
+> Regards.
+>
+
+mikala is currenlty packaging it. Should land in cauldron in the next few days
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006080.html b/zarb-ml/mageia-dev/2011-June/006080.html new file mode 100644 index 000000000..63c6ab9a5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006080.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] schroot build problem with new libboost + + + + + + + + + +

[Mageia-dev] schroot build problem with new libboost

+ philippe makowski + makowski.mageia at gmail.com +
+ Tue Jun 28 09:18:52 CEST 2011 +

+
+ +
Hi,
+
+can someone help me to solve the build problem here :
+http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110628070637.philippem.valstar.17988/
+
+what is strange is that Fedora 16 build is ok with same libboost
+version as our in Cauldron
+
+thanks
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006081.html b/zarb-ml/mageia-dev/2011-June/006081.html new file mode 100644 index 000000000..366748317 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006081.html @@ -0,0 +1,111 @@ + + + + [Mageia-dev] schroot build problem with new libboost + + + + + + + + + +

[Mageia-dev] schroot build problem with new libboost

+ Funda Wang + fundawang at gmail.com +
+ Tue Jun 28 09:23:30 CEST 2011 +

+
+ +
<quote>
+/usr/bin/ld: cannot find -lboost_program_options
+</quote>
+
+That is the problem here, it is looking for libboost_program_options,
+but we only have libboost_program_options-mt.
+
+2011/6/28 philippe makowski <makowski.mageia at gmail.com>:
+> Hi,
+>
+> can someone help me to solve the build problem here :
+> http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110628070637.philippem.valstar.17988/
+>
+> what is strange is that Fedora 16 build is ok with same libboost
+> version as our in Cauldron
+>
+> thanks
+>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006082.html b/zarb-ml/mageia-dev/2011-June/006082.html new file mode 100644 index 000000000..2ca47615d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006082.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Angelo Naselli + anaselli at linux.it +
+ Tue Jun 28 09:25:28 CEST 2011 +

+
+ +
domenica 26 giugno 2011 alle 13:38, Michael Scherer ha scritto:
+> See the thread about policy, and the part about "only packages that
+> nothing requires should be backported".
+I can't see very well the leaf story... I mean any packages
+require something at least to build. Scripts need interpreters, so
+i'd expect interpreters cannot be backported, but we can find a
+script based package (using perl, ruby or python...) needing some other
+script based one, the same could happen for programs. Now what can
+we backport there?
+A and B are leaves (?) but B uses A so i can revert A for a problem,
+now are we sure A on stable works with B on backports?
+  
+Morever we could not backport new major libraries, they would not conflicts
+with stable though, but sure they could affect some packages built in backports
+after that should not work without new major.....
+
+I'm confused :/
+
+IMO we should improve the QA (or what else) and testing to allow a safe
+installation and proving that will be upgraded to the next mageia release, 
+then if we call it backports, upgrades, updates or... that's
+another and maybe less important thing.
+
+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/20110628/39966419/attachment.asc>
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006083.html b/zarb-ml/mageia-dev/2011-June/006083.html new file mode 100644 index 000000000..c15eac801 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006083.html @@ -0,0 +1,124 @@ + + + + [Mageia-dev] schroot build problem with new libboost + + + + + + + + + +

[Mageia-dev] schroot build problem with new libboost

+ David W. Hodgins + davidwhodgins at gmail.com +
+ Tue Jun 28 09:43:53 CEST 2011 +

+
+ +
On Tue, 28 Jun 2011 03:23:30 -0400, Funda Wang <fundawang at gmail.com> wrote:
+
+> <quote>
+> /usr/bin/ld: cannot find -lboost_program_options
+> </quote>
+>
+> That is the problem here, it is looking for libboost_program_options,
+> but we only have libboost_program_options-mt.
+>
+> 2011/6/28 philippe makowski <makowski.mageia at gmail.com>:
+>> Hi,
+>>
+>> can someone help me to solve the build problem here :
+>> http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110628070637.philippem.valstar.17988/
+>>
+>> what is strange is that Fedora 16 build is ok with same libboost
+>> version as our in Cauldron
+>>
+>> thanks
+configure:8603: x86_64-mageia-linux-gnu-gcc -E  conftest.c
+conftest.c:15:28: fatal error: ac_nonexistent.h: No such file or directory
+
+When debugging make errors, I always look at the first error, which seems
+to be
+configure:8603: x86_64-mageia-linux-gnu-gcc -E  conftest.c
+conftest.c:15:28: fatal error: ac_nonexistent.h: No such file or directory
+
+urpmf conftest.c
+libwxgtku2.8-devel:/usr/share/doc/libwxgtku2.8-devel/samples/config/conftest.cpp
+libwxgtk2.8-devel:/usr/share/doc/libwxgtk2.8-devel/samples/config/conftest.cpp
+
+Regards, Dave Hodgins
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006084.html b/zarb-ml/mageia-dev/2011-June/006084.html new file mode 100644 index 000000000..1df25354f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006084.html @@ -0,0 +1,120 @@ + + + + [Mageia-dev] autologin + consolekit + + + + + + + + + +

[Mageia-dev] autologin + consolekit

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Jun 28 10:20:12 CEST 2011 +

+
+ +
'Twas brillig, and andre999 at 28/06/11 02:42 did gyre and gimble:
+> Colin Guthrie a écrit :
+>>
+>> 'Twas brillig, and Colin Guthrie at 14/06/11 09:07 did gyre and gimble:
+>>> 'Twas brillig, and Colin Guthrie at 12/06/11 23:45 did gyre and gimble:
+>>>> Hi,
+>>>>
+>>>> The autologin package is broken due to the fact that it doesn't connect
+>>>> to consolekit and thus the user who is automatically logged in doesn't
+>>>> get any permissions etc.
+>>>>
+>>>> I've fixed this by changing the autologin pam.d definition to include
+>>>> "login" rather than "system-auth".
+>>>>
+>>>> login adds the optional session module for pam_ck_connector.
+>>>>
+>>>> But I'm not sure whether this makes sense, or whether we should just
+>>>> add
+>>>> the ck_connector to the autologin pam.d definition itself.
+>>>>
+>>>> There may be other login systems that have similar problems (e.g. the
+>>>> autologin features of gdm or slim etc) but I've not tested.
+>>>>
+>>>> Any thoughts.
+>>>
+>>> Does anyone know what the right way to fix the above is?
+>>>
+>>> I'd like to issue an update when appropriate to take care of this.
+>>
+>> Ping!!
+>>
+>> Col
+> 
+> A while back when I was playing with an alternate version of an
+> application which required authentification, I added the application
+> name to some pam-related file, and it worked.
+> I forget the details.  I just did something parallel to what other some
+> applications did.
+> That seems to be what you're doing ?
+> I'm far from being an expert.
+> Hope that helps.
+
+Thanks for the input. It's not a problem getting it working as I have
+this working fine. My question is rather one of "which solution is best?"
+
+Either adding the pam_ck_connector to individual files or simply
+including "login" over "system-auth" or even changing system-auth to
+include pam_ck_connector rather than login.
+
+Something isn't quite right here but I don't know what.
+
+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-June/006085.html b/zarb-ml/mageia-dev/2011-June/006085.html new file mode 100644 index 000000000..ae640047f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006085.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] schroot build problem with new libboost + + + + + + + + + +

[Mageia-dev] schroot build problem with new libboost

+ philippe makowski + makowski.mageia at gmail.com +
+ Tue Jun 28 11:13:17 CEST 2011 +

+
+ +
2011/6/28 Funda Wang <fundawang at gmail.com>:
+> <quote>
+> /usr/bin/ld: cannot find -lboost_program_options
+> </quote>
+>
+> That is the problem here, it is looking for libboost_program_options,
+> but we only have libboost_program_options-mt.
+>
+and why ?
+under mga1 we have libboost_program_options.so.1.44.0
+and under Cauldron libboost_program_options-mt.so.1.46.1
+
+why not libboost_program_options.so.1.46.1 ?
+
+Fedora have both , why don't we have both ?
+
+how to solve this ? (sorry it is out of my skills)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006086.html b/zarb-ml/mageia-dev/2011-June/006086.html new file mode 100644 index 000000000..9947b15f4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006086.html @@ -0,0 +1,122 @@ + + + + [Mageia-dev] schroot build problem with new libboost + + + + + + + + + +

[Mageia-dev] schroot build problem with new libboost

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Tue Jun 28 11:35:04 CEST 2011 +

+
+ +
On 28 June 2011 11:13, philippe makowski <makowski.mageia at gmail.com> wrote:
+> 2011/6/28 Funda Wang <fundawang at gmail.com>:
+>> <quote>
+>> /usr/bin/ld: cannot find -lboost_program_options
+>> </quote>
+>>
+>> That is the problem here, it is looking for libboost_program_options,
+>> but we only have libboost_program_options-mt.
+>>
+> and why ?
+> under mga1 we have libboost_program_options.so.1.44.0
+> and under Cauldron libboost_program_options-mt.so.1.46.1
+>
+> why not libboost_program_options.so.1.46.1 ?
+>
+> Fedora have both , why don't we have both ?
+>
+
+[...]
+
+> how to solve this ? (sorry it is out of my skills)
+>
+
+For some reason that particular configure check
+(boost::program_options::validation_error) doesn't check
+multi-threaded libboost_program_options-mt.so, the other ones do.
+
+I've committed a fix, hopefully it'll work.
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006087.html b/zarb-ml/mageia-dev/2011-June/006087.html new file mode 100644 index 000000000..4154e2d62 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006087.html @@ -0,0 +1,124 @@ + + + + [Mageia-dev] Backports policy proposal + + + + + + + + + +

[Mageia-dev] Backports policy proposal

+ Michael Scherer + misc at zarb.org +
+ Tue Jun 28 11:46:53 CEST 2011 +

+
+ +
Le lundi 27 juin 2011 à 21:42 -0400, andre999 a écrit :
+> Michael Scherer a écrit :
+> >
+> > Le vendredi 24 juin 2011 à 16:20 -0400, andre999 a écrit :
+> >> Michael Scherer a écrit :
+> 
+> [...]
+> 
+> >>> - cannot be backported if the package was just created and is thus basically untested in cauldron
+> >>
+> >> What about corner cases where a potential backport is incompatible with changes introduced in
+> >> cauldron ?  Should we leave such packages to third parties ?  (I would tend to say yes.)
+> >
+> > Give a more precise example.
+> 
+> Suppose leaf package fooa depends on foob.  foob is part of the current release.
+> Cauldron replaces foob with fooc.  fooa is incompatible with fooc.
+
+Then why do we replace foob by it in the first place if this break
+fooa ?
+
+> fooa is requested by some users, and future versions of fooa are intended to be 
+> compatible with fooc.
+> In this case, even though it wouldn't be testable in cauldron, it could be tested in 
+> backports-testing, and I think it could be a good idea to allow it.
+>
+> Even if fooc compatibility wouldn't be available for the next Mageia release, a user 
+> could avoid updating for a release in order to keep using fooa.
+> However, if there were no intention to make fooa compatible with fooc, maybe it should 
+> be denied.
+
+The example is bogus. If we have fooa in the distro and we upload fooc
+that break it, then we have to fix the breakage as a priority. Usually,
+that would be having foob and fooc as parallel installablable.
+
+Anyway, the question is "how often does it" happens ? Because "it may
+happen" is not a justification" if in practice, it never happen. And not
+having a backport is not the end of the world so unless the problem is
+quite frequent ( and so far, this one is far from being frequent ,
+especially since it is based on a wrong supposition in the first part ),
+I do not think this would be blocking.
+
+> >> I like the idea of tagging backports in the package name, as well as in the package database.
+> >
+> > We cannot tag in the packages database. Yum do it with a separate sqlite
+> > file, afaik.
+> 
+> I would like to see the source repository info available for every installed package.
+> Maybe even stored somewhere in the .rpm file, also.
+> Is concerns for upstream compatibility for rpm or urpm* the a reason why we can't add 
+> new fields to the packages database ?
+> (Although a parallel sqlite file would work.)
+
+Compatibility would be indeed a concern. But if we move packages between
+repository without rebuilding for QA reasons, this would also be
+meaningless.
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006088.html b/zarb-ml/mageia-dev/2011-June/006088.html new file mode 100644 index 000000000..ff7d53a3c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006088.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] schroot build problem with new libboost + + + + + + + + + +

[Mageia-dev] schroot build problem with new libboost

+ philippe makowski + makowski.mageia at gmail.com +
+ Tue Jun 28 13:38:37 CEST 2011 +

+
+ +
2011/6/28 Ahmad Samir <ahmadsamir3891 at gmail.com>:
+> I've committed a fix, hopefully it'll work.
+>
+thanks
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006089.html b/zarb-ml/mageia-dev/2011-June/006089.html new file mode 100644 index 000000000..a23305159 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006089.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] KDE 4.7? + + + + + + + + + +

[Mageia-dev] KDE 4.7?

+ Balcaen John + mikala at mageia.org +
+ Tue Jun 28 13:52:41 CEST 2011 +

+
+ +
Le mardi 28 juin 2011 02:40:43, Funda Wang a écrit :
+> Hello,
+> 
+> Is it the time we go with kde 4.7 (rc currently) within cauldron?
+It's almost ready in fact.
+I'm just working on kdebindings4 split & if you're following commits (either 
+on irc or on the mailing list) you might see that almost everything is already 
+on the svn :)
+
+
+
+-- 
+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-June/006090.html b/zarb-ml/mageia-dev/2011-June/006090.html new file mode 100644 index 000000000..d1abe8d1b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006090.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] Backports policy proposal + + + + + + + + + +

[Mageia-dev] Backports policy proposal

+ Samuel Verschelde + stormi at laposte.net +
+ Tue Jun 28 14:43:35 CEST 2011 +

+
+ +
+Le vendredi 24 juin 2011 02:10:14, Michael Scherer a écrit :
+> I would also propose a few rules :
+> 
+> "a package should have been in cauldron since 1 week before being
+> backported", so we can at least ensure there was a minimal test on it,
+> Ie, if I package stuff-virtual-manager, I cannot backport it before 1
+> week. If we have a package of stuff-virtual-manager since 1 month, and
+> that I update a new version, then I can backport. The idea is that a
+> newer packages may suffer from more bug than older one.
+
+Could this apply only to "-backport" media and not "-backport_testing " media 
+? I would find good to be able to send a package very quickly to 
+backports_testing so that I can start to be tested as soon as possible. A 
+whole week for that would be a long time, considering that after that you have 
+to add more time so that the backport can be tested.
+
+By the way I think a packager usually knows the risks there is to send a 
+package too quickly to the backports and that we don't necessarily need to 
+enforce such a strict "1 week" rule. Especially when sending to 
+backports_testing first.
+
+ 
+> - cannot be backported if this is not a leaf package, will be revised
+> later
+
+I would like to be less strict, by replacing "leaf package" by "leaf group of 
+packages, tighly tied together by strict requires".
+
+Examples : 
+- A requires newer B and C, and no other package requires B and C (quite 
+common with games where data are split into separate packages) => you can 
+backport A, B, C. To me this situation should be possible.
+- A requires newer B, but D depends on B too => you can't backport A and B 
+alone, but if the maintainers consider it acceptable to enforce upgrade of D 
+when someone wants to upgrade A or upgrade of A when someone wants to upgrade 
+D (could be related pieces of software), then you can backport A, B and D (and 
+make sure to set the good requires). To me this situation would be nice to 
+have as an available option.
+
+Best regards
+
+Samuel Verschelde
+
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006091.html b/zarb-ml/mageia-dev/2011-June/006091.html new file mode 100644 index 000000000..55c4c4478 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006091.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Samuel Verschelde + stormi at laposte.net +
+ Tue Jun 28 14:47:31 CEST 2011 +

+
+ +
+Le vendredi 24 juin 2011 02:09:55, Michael Scherer a écrit :
+> - a packager decide to do it. Based on the policy ( outlined in another
+> mail ), and maybe seeing with the maintainer first about that for non
+> trivial applications, the backport can be done, or not. The criterias
+> for being backported or not are not important to the process, just
+> assume that they exist for now ( and look at next mail ). So based on
+> criteria, someone say "it can be backported, so I do it".
+> 
+> - I am not sure on this part, but basically, we have 2 choices :
+>   - the packager take the cauldron package and push to backport testing
+>   - the packager move the cauldron package in svn to backport, and there
+> send it to backport testing.
+> 
+> Proposal 1 mean less work duplication, but proposal 2 let us do more
+> customization.
+> 
+
+If we want to be able to set stricted requires between backports to allow safe 
+cherry-picking, is it OK to do it in cauldron without any side effects ? Or 
+should we change the spec file only in the backport branch of the package 
+(which then would mean option 2) ?
+
+Best regards
+
+Samuel Verschelde
+
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006092.html b/zarb-ml/mageia-dev/2011-June/006092.html new file mode 100644 index 000000000..b6e3cd90c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006092.html @@ -0,0 +1,106 @@ + + + + [Mageia-dev] Mageia Advisories Database + + + + + + + + + +

[Mageia-dev] Mageia Advisories Database

+ nicolas vigier + boklm at mars-attacks.org +
+ Tue Jun 28 15:20:33 CEST 2011 +

+
+ +
Hello,
+
+In order to send updates advisories, and have a web page listing all
+previous advisories, we need to create a database to store them.
+
+So I think it should have the following info for each advisory :
+
+ - advisory ID: something like MGA-[NUMBER] ?
+ - advisory date
+ - affected source packages
+ - affected distribution versions
+ - CVE numbers
+ - list of binary packages with sha1sum
+ - Mageia Bug #
+ - Reference URLs
+ - advisory text
+
+Anything else ?
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006093.html b/zarb-ml/mageia-dev/2011-June/006093.html new file mode 100644 index 000000000..6a062c3dc --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006093.html @@ -0,0 +1,119 @@ + + + + [Mageia-dev] Mageia Advisories Database + + + + + + + + + +

[Mageia-dev] Mageia Advisories Database

+ Samuel Verschelde + stormi at laposte.net +
+ Tue Jun 28 15:34:40 CEST 2011 +

+
+ +
+Le mardi 28 juin 2011 15:20:33, nicolas vigier a écrit :
+> Hello,
+> 
+> In order to send updates advisories, and have a web page listing all
+> previous advisories, we need to create a database to store them.
+> 
+> So I think it should have the following info for each advisory :
+> 
+>  - advisory ID: something like MGA-[NUMBER] ?
+>  - advisory date
+>  - affected source packages
+>  - affected distribution versions
+>  - CVE numbers
+>  - list of binary packages with sha1sum
+>  - Mageia Bug #
+>  - Reference URLs
+>  - advisory text
+> 
+> Anything else ?
+
+Is it for security bugs only or any update ? And will it be the central place 
+where update messages are stored ?
+
+If possible, I'd like to be able to query such a database containing an update 
+message for each update, and more information if needed, to able to display 
+them for package updates in Mageia App Db.
+
+Best regards
+
+Samuel
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006094.html b/zarb-ml/mageia-dev/2011-June/006094.html new file mode 100644 index 000000000..8649f8f61 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006094.html @@ -0,0 +1,130 @@ + + + + [Mageia-dev] Mageia Advisories Database + + + + + + + + + +

[Mageia-dev] Mageia Advisories Database

+ Romain d'Alverny + rdalverny at gmail.com +
+ Tue Jun 28 15:50:05 CEST 2011 +

+
+ +
Hi,
+
+On Tue, Jun 28, 2011 at 15:34, Samuel Verschelde <stormi at laposte.net> wrote:
+> Le mardi 28 juin 2011 15:20:33, nicolas vigier a écrit :
+>> In order to send updates advisories, and have a web page listing all
+>> previous advisories, we need to create a database to store them.
+>>
+>> So I think it should have the following info for each advisory :
+>>
+>>  - advisory ID: something like MGA-[NUMBER] ?
+>>  - advisory date
+>>  - affected source packages
+>>  - affected distribution versions
+>>  - CVE numbers
+>>  - list of binary packages with sha1sum
+>>  - Mageia Bug #
+>>  - Reference URLs
+>>  - advisory text
+>>
+>> Anything else ?
+
+If using SQL, make sure to normalize the db schema a bit (that is, for
+instance, an advisory table, with a distributions table, and a
+relationship). MDV security advisory web app had a single table, with
+new columns added each time a new release was published and that was
+really not good, neither safe to maintain.
+
+In this perspective, there could be the following tables:
+ - advisories (id, date, text, list of URLs, list of bug #)
+ - distributions (id, name)
+ - source packages (id, name, version)
+ - CVE numbers
+
+Not sure about the rest; depends on the data details and what type of
+queries would be expected:
+ - do we only query after the advisory id or do we plan to have stats
+per distribution, source package?
+ - what screens do you expect?
+ - are there several CVE numbers for a single advisory?
+ - is there a link from source packages and binary packages?
+
+Romain
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006095.html b/zarb-ml/mageia-dev/2011-June/006095.html new file mode 100644 index 000000000..55c5fe5dd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006095.html @@ -0,0 +1,132 @@ + + + + [Mageia-dev] Mageia Advisories Database + + + + + + + + + +

[Mageia-dev] Mageia Advisories Database

+ nicolas vigier + boklm at mars-attacks.org +
+ Tue Jun 28 16:02:13 CEST 2011 +

+
+ +
On Tue, 28 Jun 2011, Samuel Verschelde wrote:
+
+> 
+> Le mardi 28 juin 2011 15:20:33, nicolas vigier a écrit :
+> > Hello,
+> > 
+> > In order to send updates advisories, and have a web page listing all
+> > previous advisories, we need to create a database to store them.
+> > 
+> > So I think it should have the following info for each advisory :
+> > 
+> >  - advisory ID: something like MGA-[NUMBER] ?
+> >  - advisory date
+> >  - affected source packages
+> >  - affected distribution versions
+> >  - CVE numbers
+> >  - list of binary packages with sha1sum
+> >  - Mageia Bug #
+> >  - Reference URLs
+> >  - advisory text
+     - bugfix type: normal / security
+> > 
+> > Anything else ?
+> 
+> Is it for security bugs only or any update ? And will it be the central place 
+> where update messages are stored ?
+
+For both security and non-security updates, I forgot to add this info in
+the list.
+
+This database will be used for :
+ - sending an email to updates-announce mailing list
+ - generate the descriptions file used by rpmdrake to show infos about
+   new updates
+ - a web page to list all updates
+
+> If possible, I'd like to be able to query such a database containing an update 
+> message for each update, and more information if needed, to able to display 
+> them for package updates in Mageia App Db.
+
+I think we can provide this as json.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006096.html b/zarb-ml/mageia-dev/2011-June/006096.html new file mode 100644 index 000000000..7b7385312 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006096.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] Mageia Advisories Database + + + + + + + + + +

[Mageia-dev] Mageia Advisories Database

+ Stew Benedict + stewbintn at gmail.com +
+ Tue Jun 28 16:06:19 CEST 2011 +

+
+ +
On 06/28/2011 09:50 AM, Romain d'Alverny wrote:
+> If using SQL, make sure to normalize the db schema a bit (that is, for
+>   - are there several CVE numbers for a single advisory?
+Yes, there could be
+
+
+-- 
+Stew Benedict
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006097.html b/zarb-ml/mageia-dev/2011-June/006097.html new file mode 100644 index 000000000..c9aeaf638 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006097.html @@ -0,0 +1,114 @@ + + + + [Mageia-dev] Mageia Advisories Database + + + + + + + + + +

[Mageia-dev] Mageia Advisories Database

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Tue Jun 28 16:23:17 CEST 2011 +

+
+ +
On Tue, 28 Jun 2011, nicolas vigier wrote:
+
+> In order to send updates advisories, and have a web page listing all
+> previous advisories, we need to create a database to store them.
+>
+> So I think it should have the following info for each advisory :
+>
+> - advisory ID: something like MGA-[NUMBER] ?
+> - advisory date
+> - affected source packages
+> - affected distribution versions
+> - CVE numbers
+> - list of binary packages with sha1sum
+> - Mageia Bug #
+> - Reference URLs
+> - advisory text
+>
+> Anything else ?
+
+- severity
+- whether this is a security issue or a non-security bugfix
+(could be 1 field)
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006098.html b/zarb-ml/mageia-dev/2011-June/006098.html new file mode 100644 index 000000000..759db638a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006098.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] KDE 4.7? + + + + + + + + + +

[Mageia-dev] KDE 4.7?

+ Funda Wang + fundawang at gmail.com +
+ Tue Jun 28 16:27:24 CEST 2011 +

+
+ +
I would say we need to add a lot of conflicts and obsoletes for upgrading.
+
+2011/6/28 Balcaen John <mikala at mageia.org>:
+> Le mardi 28 juin 2011 02:40:43, Funda Wang a écrit :
+>> Hello,
+>>
+>> Is it the time we go with kde 4.7 (rc currently) within cauldron?
+> It's almost ready in fact.
+> I'm just working on kdebindings4 split & if you're following commits (either
+> on irc or on the mailing list) you might see that almost everything is already
+> on the svn :)
+>
+>
+>
+> --
+> 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-June/006099.html b/zarb-ml/mageia-dev/2011-June/006099.html new file mode 100644 index 000000000..e64cb769f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006099.html @@ -0,0 +1,85 @@ + + + + [Mageia-dev] KDE 4.7? + + + + + + + + + +

[Mageia-dev] KDE 4.7?

+ Dexter Morgan + dmorganec at gmail.com +
+ Tue Jun 28 16:28:40 CEST 2011 +

+
+ +
On Tue, Jun 28, 2011 at 4:27 PM, Funda Wang <fundawang at gmail.com> wrote:
+> I would say we need to add a lot of conflicts and obsoletes for upgrading.
+
+mikala worked on it already from what he told me.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006100.html b/zarb-ml/mageia-dev/2011-June/006100.html new file mode 100644 index 000000000..f41d8b1c8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006100.html @@ -0,0 +1,147 @@ + + + + [Mageia-dev] Mageia Advisories Database + + + + + + + + + +

[Mageia-dev] Mageia Advisories Database

+ nicolas vigier + boklm at mars-attacks.org +
+ Tue Jun 28 16:49:46 CEST 2011 +

+
+ +
On Tue, 28 Jun 2011, Romain d'Alverny wrote:
+
+> Hi,
+> 
+> On Tue, Jun 28, 2011 at 15:34, Samuel Verschelde <stormi at laposte.net> wrote:
+> > Le mardi 28 juin 2011 15:20:33, nicolas vigier a écrit :
+> >> In order to send updates advisories, and have a web page listing all
+> >> previous advisories, we need to create a database to store them.
+> >>
+> >> So I think it should have the following info for each advisory :
+> >>
+> >>  - advisory ID: something like MGA-[NUMBER] ?
+> >>  - advisory date
+> >>  - affected source packages
+> >>  - affected distribution versions
+> >>  - CVE numbers
+> >>  - list of binary packages with sha1sum
+> >>  - Mageia Bug #
+> >>  - Reference URLs
+> >>  - advisory text
+> >>
+> >> Anything else ?
+> 
+> If using SQL, make sure to normalize the db schema a bit (that is, for
+> instance, an advisory table, with a distributions table, and a
+> relationship). MDV security advisory web app had a single table, with
+> new columns added each time a new release was published and that was
+> really not good, neither safe to maintain.
+> 
+> In this perspective, there could be the following tables:
+>  - advisories (id, date, text, list of URLs, list of bug #)
+>  - distributions (id, name)
+>  - source packages (id, name, version)
+>  - CVE numbers
+
+I am thinking about the following tables :
+
+ - advisories : id, published, publish-date, update-date, text, severity
+ - source-packages : packagename, filename, sha1, distribution, repository, version, advisory-id
+ - binary-packages : packagename, filename, sha1, source-package-id
+ - cve-numbers : cve-number, advisory-id
+ - bugzilla-numbers : bugzilla-number, advisory-id
+ - reference-urls : url, advisory-id
+
+> 
+> Not sure about the rest; depends on the data details and what type of
+> queries would be expected:
+>  - do we only query after the advisory id or do we plan to have stats
+> per distribution, source package?
+
+We can query by advisory id, source package, cve number, bugzilla
+number. And we can do stats.
+
+>  - what screens do you expect?
+>  - are there several CVE numbers for a single advisory?
+
+Yes. We can have several CVE numbers, source packages, bugzilla numbers,
+URLs, distributions, for one advisory.
+
+>  - is there a link from source packages and binary packages?
+
+Yes.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006101.html b/zarb-ml/mageia-dev/2011-June/006101.html new file mode 100644 index 000000000..f832f7a7d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006101.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] Looking for a mentor in packaging... + + + + + + + + + +

[Mageia-dev] Looking for a mentor in packaging...

+ Samuel Verschelde + stormi at laposte.net +
+ Tue Jun 28 16:57:13 CEST 2011 +

+
+ +
+Le lundi 27 juin 2011 20:40:27, Radu-Cristian FOTESCU a écrit :
+> We will soon have a page on wiki where people can put his name on for
+> seeking a mentor, too.
+> 
+> >Oh, is it not this
+> >one?http://mageia.org/wiki/doku.php?id=packaging#list_of_registered_peopl
+> >e
+> 
+> It thought it was a list for people wanting to become packagers (although
+> some people already are mga packagers), so I've added my name there too.
+
+It's not dedicated to this but rather a means to see who can work on what, if 
+I remember correctly (and also who can be a mentor), since we have no 
+maintainer database yet.
+
+> 
+> I too said I need mentoring / I want to take care of some packages in mga.
+> In the meantime, I am on my own: http://mageia.beranger.org/mageia/
+
+I hope we can find you a mentor as soon as possible. If any mentor is available 
+for beranger, please tell ! Otherwise, please give some time to the new 
+mentoring coordination small team so that they can try to improve the process 
+and find a mentor for you.
+
+Best regards
+
+Samuel
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006102.html b/zarb-ml/mageia-dev/2011-June/006102.html new file mode 100644 index 000000000..af7e78376 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006102.html @@ -0,0 +1,129 @@ + + + + [Mageia-dev] Mageia Advisories Database + + + + + + + + + +

[Mageia-dev] Mageia Advisories Database

+ Samuel Verschelde + stormi at laposte.net +
+ Tue Jun 28 16:59:18 CEST 2011 +

+
+ +
+Le mardi 28 juin 2011 16:02:13, nicolas vigier a écrit :
+> On Tue, 28 Jun 2011, Samuel Verschelde wrote:
+> > Le mardi 28 juin 2011 15:20:33, nicolas vigier a écrit :
+> > > Hello,
+> > > 
+> > > In order to send updates advisories, and have a web page listing all
+> > > previous advisories, we need to create a database to store them.
+> > > 
+> > > So I think it should have the following info for each advisory :
+> > >  - advisory ID: something like MGA-[NUMBER] ?
+> > >  - advisory date
+> > >  - affected source packages
+> > >  - affected distribution versions
+> > >  - CVE numbers
+> > >  - list of binary packages with sha1sum
+> > >  - Mageia Bug #
+> > >  - Reference URLs
+> > >  - advisory text
+> 
+>      - bugfix type: normal / security
+> 
+> > > Anything else ?
+> > 
+> > Is it for security bugs only or any update ? And will it be the central
+> > place where update messages are stored ?
+> 
+> For both security and non-security updates, I forgot to add this info in
+> the list.
+> 
+> This database will be used for :
+>  - sending an email to updates-announce mailing list
+>  - generate the descriptions file used by rpmdrake to show infos about
+>    new updates
+>  - a web page to list all updates
+> 
+> > If possible, I'd like to be able to query such a database containing an
+> > update message for each update, and more information if needed, to able
+> > to display them for package updates in Mageia App Db.
+> 
+> I think we can provide this as json.
+
+That would be great.
+
+Samuel
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006103.html b/zarb-ml/mageia-dev/2011-June/006103.html new file mode 100644 index 000000000..add71de87 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006103.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Michael Scherer + misc at zarb.org +
+ Tue Jun 28 17:06:54 CEST 2011 +

+
+ +
Le mardi 28 juin 2011 à 09:25 +0200, Angelo Naselli a écrit :
+> domenica 26 giugno 2011 alle 13:38, Michael Scherer ha scritto:
+> > See the thread about policy, and the part about "only packages that
+> > nothing requires should be backported".
+> I can't see very well the leaf story... I mean any packages
+> require something at least to build. Scripts need interpreters, so
+> i'd expect interpreters cannot be backported, but we can find a
+> script based package (using perl, ruby or python...) needing some other
+> script based one, the same could happen for programs. Now what can
+> we backport there?
+> A and B are leaves (?) but B uses A so i can revert A for a problem,
+> now are we sure A on stable works with B on backports?
+
+if B use A, that mean that A is not a leave package, since something
+requires it.
+
+
+> Morever we could not backport new major libraries, they would not conflicts
+> with stable though, but sure they could affect some packages built in backports
+> after that should not work without new major.....
+
+Yes. 
+
+There is a moment where we need to answer "do we want to backport all
+cauldron on stable", which is basically what we incrementally do with
+cauldron", or do we just backport a subset of application where we can
+do enough QA because changes are small enough ?
+
+> I'm confused :/
+> 
+> IMO we should improve the QA (or what else) and testing to allow a safe
+> installation and proving that will be upgraded to the next mageia release, 
+> then if we call it backports, upgrades, updates or... that's
+> another and maybe less important thing.
+
+Proving is easy. The package in release must have a higher EVR than
+those on backports. But if we let people do cherry picking, this is much
+harder.
+-- 
+Michael Scherer
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006104.html b/zarb-ml/mageia-dev/2011-June/006104.html new file mode 100644 index 000000000..5b41d2d55 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006104.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] KDE 4.7? + + + + + + + + + +

[Mageia-dev] KDE 4.7?

+ Balcaen John + mikala at mageia.org +
+ Tue Jun 28 17:20:18 CEST 2011 +

+
+ +
Le mardi 28 juin 2011 11:27:24, Funda Wang a écrit :
+> I would say we need to add a lot of conflicts and obsoletes for upgrading.
+I'm already on it so please don't start changing everything until i finished.
+
+-- 
+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-June/006105.html b/zarb-ml/mageia-dev/2011-June/006105.html new file mode 100644 index 000000000..1248dba5a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006105.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] KDE 4.7? + + + + + + + + + +

[Mageia-dev] KDE 4.7?

+ Funda Wang + fundawang at gmail.com +
+ Tue Jun 28 17:24:41 CEST 2011 +

+
+ +
OK, and don't forget those -devel sub packages, as I've already found
+several of them.
+
+2011/6/28 Balcaen John <mikala at mageia.org>:
+> Le mardi 28 juin 2011 11:27:24, Funda Wang a écrit :
+>> I would say we need to add a lot of conflicts and obsoletes for upgrading.
+> I'm already on it so please don't start changing everything until i finished.
+>
+> --
+> 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-June/006106.html b/zarb-ml/mageia-dev/2011-June/006106.html new file mode 100644 index 000000000..20b2df463 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006106.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] KDE 4.7? + + + + + + + + + +

[Mageia-dev] KDE 4.7?

+ Balcaen John + mikala at mageia.org +
+ Tue Jun 28 17:26:30 CEST 2011 +

+
+ +
Le mardi 28 juin 2011 12:20:18, Balcaen John a écrit :
+> Le mardi 28 juin 2011 11:27:24, Funda Wang a écrit :
+> > I would say we need to add a lot of conflicts and obsoletes for upgrading.
+> I'm already on it so please don't start changing everything until i 
+finished.
+
+Since you started without waiting for an answer could you please at least 
+wrote a correct changelog
+(like for example fixing the requires on lib on -devel package for kate since 
+it's not just about adding a conflict  & please note that fix for example was 
+already on my next commit ....)
+
+
+
+-- 
+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-June/006107.html b/zarb-ml/mageia-dev/2011-June/006107.html new file mode 100644 index 000000000..d2530dc2b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006107.html @@ -0,0 +1,115 @@ + + + + [Mageia-dev] Mageia Advisories Database + + + + + + + + + +

[Mageia-dev] Mageia Advisories Database

+ nicolas vigier + boklm at mars-attacks.org +
+ Tue Jun 28 17:32:46 CEST 2011 +

+
+ +
On Tue, 28 Jun 2011, Christiaan Welvaart wrote:
+
+> On Tue, 28 Jun 2011, nicolas vigier wrote:
+>
+>> In order to send updates advisories, and have a web page listing all
+>> previous advisories, we need to create a database to store them.
+>>
+>> So I think it should have the following info for each advisory :
+>>
+>> - advisory ID: something like MGA-[NUMBER] ?
+>> - advisory date
+>> - affected source packages
+>> - affected distribution versions
+>> - CVE numbers
+>> - list of binary packages with sha1sum
+>> - Mageia Bug #
+>> - Reference URLs
+>> - advisory text
+>>
+>> Anything else ?
+>
+> - severity
+> - whether this is a security issue or a non-security bugfix
+> (could be 1 field)
+
+What kind of severity classification should we use ?
+
+Something like redhat, with Critical, Important, Moderate, Low ?
+
+Or something more simple with only Critical and Normal ?
+
+Or no classification ?
+
+http://www.redhat.com/f/pdf/rhel4/SecurityClassification.pdf
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006108.html b/zarb-ml/mageia-dev/2011-June/006108.html new file mode 100644 index 000000000..82a9c2fdd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006108.html @@ -0,0 +1,120 @@ + + + + [Mageia-dev] Mageia Advisories Database + + + + + + + + + +

[Mageia-dev] Mageia Advisories Database

+ Michael Scherer + misc at zarb.org +
+ Tue Jun 28 17:33:07 CEST 2011 +

+
+ +
Le mardi 28 juin 2011 à 16:23 +0200, Christiaan Welvaart a écrit :
+> On Tue, 28 Jun 2011, nicolas vigier wrote:
+> 
+> > In order to send updates advisories, and have a web page listing all
+> > previous advisories, we need to create a database to store them.
+> >
+> > So I think it should have the following info for each advisory :
+> >
+> > - advisory ID: something like MGA-[NUMBER] ?
+> > - advisory date
+> > - affected source packages
+> > - affected distribution versions
+> > - CVE numbers
+> > - list of binary packages with sha1sum
+Is there people that really check them ?
+( since there is already gpg and checksum in rpm that can be checked
+automatically, I do not see the point in having this when it requires
+another manual check )
+
+> > - Mageia Bug #
+> > - Reference URLs
+> > - advisory text
+> >
+> > Anything else ?
+> 
+> - severity
+Adding severity would requires us to have precise rules about it, and
+would not mean much, and likely lots of bike shedding about it.
+
+And also, what is the use precisely ?
+
+> - whether this is a security issue or a non-security bugfix
+What if there is more than 1 fix ( like a firefox upgrade ) ?
+And what's the use ?
+
+I would recommend looking at CVRF and OSVDB, but that's only for
+security issues.
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006109.html b/zarb-ml/mageia-dev/2011-June/006109.html new file mode 100644 index 000000000..c53380036 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006109.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] KDE 4.7? + + + + + + + + + +

[Mageia-dev] KDE 4.7?

+ Balcaen John + mikala at mageia.org +
+ Tue Jun 28 17:57:41 CEST 2011 +

+
+ +
Le mardi 28 juin 2011 12:24:41, Funda Wang a écrit :
+> OK, and don't forget those -devel sub packages, as I've already found
+> several of them.
+> 
+Sure it was planned for the end of kdebindings packaging.
+
+-- 
+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-June/006110.html b/zarb-ml/mageia-dev/2011-June/006110.html new file mode 100644 index 000000000..6bf83bd39 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006110.html @@ -0,0 +1,121 @@ + + + + [Mageia-dev] Mageia Advisories Database + + + + + + + + + +

[Mageia-dev] Mageia Advisories Database

+ nicolas vigier + boklm at mars-attacks.org +
+ Tue Jun 28 17:58:20 CEST 2011 +

+
+ +
On Tue, 28 Jun 2011, Michael Scherer wrote:
+
+> Le mardi 28 juin 2011 à 16:23 +0200, Christiaan Welvaart a écrit :
+> > On Tue, 28 Jun 2011, nicolas vigier wrote:
+> > 
+> > > In order to send updates advisories, and have a web page listing all
+> > > previous advisories, we need to create a database to store them.
+> > >
+> > > So I think it should have the following info for each advisory :
+> > >
+> > > - advisory ID: something like MGA-[NUMBER] ?
+> > > - advisory date
+> > > - affected source packages
+> > > - affected distribution versions
+> > > - CVE numbers
+> > > - list of binary packages with sha1sum
+> Is there people that really check them ?
+> ( since there is already gpg and checksum in rpm that can be checked
+> automatically, I do not see the point in having this when it requires
+> another manual check )
+
+Most other distributions include this in their advisories. But yes, it's
+not very useful, so we can probably remove the sha1.
+
+> 
+> > > - Mageia Bug #
+> > > - Reference URLs
+> > > - advisory text
+> > >
+> > > Anything else ?
+> > 
+> > - severity
+> Adding severity would requires us to have precise rules about it, and
+> would not mean much, and likely lots of bike shedding about it.
+> 
+> And also, what is the use precisely ?
+> 
+> > - whether this is a security issue or a non-security bugfix
+> What if there is more than 1 fix ( like a firefox upgrade ) ?
+
+If at least one of them is security, then it's a security update.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006111.html b/zarb-ml/mageia-dev/2011-June/006111.html new file mode 100644 index 000000000..d9bb59b2c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006111.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ andre999 + andr55 at laposte.net +
+ Wed Jun 29 00:23:15 CEST 2011 +

+
+ +
Angelo Naselli a écrit :
+> domenica 26 giugno 2011 alle 13:38, Michael Scherer ha scritto:
+>> See the thread about policy, and the part about "only packages that
+>> nothing requires should be backported".
+> I can't see very well the leaf story... I mean any packages
+> require something at least to build. Scripts need interpreters, so
+> i'd expect interpreters cannot be backported, but we can find a
+> script based package (using perl, ruby or python...) needing some other
+> script based one, the same could happen for programs. Now what can
+> we backport there?
+> A and B are leaves (?) but B uses A so i can revert A for a problem,
+> now are we sure A on stable works with B on backports?
+>
+> Morever we could not backport new major libraries, they would not conflicts
+> with stable though, but sure they could affect some packages built in backports
+> after that should not work without new major.....
+>
+> I'm confused :/
+>
+> IMO we should improve the QA (or what else) and testing to allow a safe
+> installation and proving that will be upgraded to the next mageia release,
+> then if we call it backports, upgrades, updates or... that's
+> another and maybe less important thing.
+>
+> Angelo
+
+A leaf package is a package that is not required by any other package.
+But leaf packages will always require something else.
+If B requires A, then A is not a leaf package, even though B could be.
+When backporting B, we test to make sure that it works with release A.
+Obviously it restricts what can be backported, but the trade-off is that backports will 
+(almost always) work, and they won't break anything.
+
+-- 
+André
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006112.html b/zarb-ml/mageia-dev/2011-June/006112.html new file mode 100644 index 000000000..cb49a5e3e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006112.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] Looking for a mentor in packaging... + + + + + + + + + +

[Mageia-dev] Looking for a mentor in packaging...

+ Radu-Cristian FOTESCU + beranger5ca at yahoo.ca +
+ Wed Jun 29 01:17:17 CEST 2011 +

+
+ +
+>> I too said I need mentoring / I want to take care of some packages in mga.
+>> In the meantime, I am on my own: http://mageia.beranger.org/mageia/
+>
+>I hope we can find you a mentor as soon as possible. If any mentor is available 
+>for beranger, please tell ! Otherwise, please give some time to the new 
+>mentoring coordination small team so that they can try to improve the process 
+>and find a mentor for you.
+
+
+I know people is now busy with bringing KDE 4.6.90 to Cauldron, and mentors are a scarce resource, yet I'd like to say that I added a few more packages in my unofficial repo (y compris calibre updated to 0.8.7):
+
+OCR-related new packages:
+
+* cuneiform-linux, at 1.1.0, a rather good multilanguage OCR (the officially-available tesseract is also a good one, but it lacks a GUI)
+* cuneiform-qt, a simple yet very practical GUI for the previous package
+* yagf, another GUI for the same OCR
+* kbookocr 2.0, a hard-to-find (on distros other than ALT Linux) GUI for the same OCR, able to also use PDF and DJVU for input files, offering an interface with the scanner, and an integration with the default word processor (LibreOffice Writer)
+
+All these OCR GUIs are showing up in the Office KDE menu, not in Graphics, like XSane.
+Screenshots: 
+http://mageia.beranger.org/images/cuneiform-qt.png
+http://mageia.beranger.org/images/yagf.png
+http://mageia.beranger.org/images/kbookocr.png
+
+While testing cuneiform-linux with all these GUIs, I’ve already filed a bug with the upstream:
+https://bugs.launchpad.net/cuneiform-linux/+bug/803156
+
+Best regards,
+R-C aka beranger
+
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006113.html b/zarb-ml/mageia-dev/2011-June/006113.html new file mode 100644 index 000000000..8fe4f7cc7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006113.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] KDE SC 4.7 RC1 landing on cauldron + + + + + + + + + +

[Mageia-dev] KDE SC 4.7 RC1 landing on cauldron

+ John Balcaen + mikala at mageia.org +
+ Wed Jun 29 09:59:20 CEST 2011 +

+
+ +
Hello,
+
+I'm going to push today KDE SC 4.7 RC1 on cauldron.
+Most of packages are ready except in fact some kdebindings related one, but
+i'm quite busy so i'll (or someone else funda maybe  ) fix it later.
+
+Please note that KDEPIM SC 4.7 is now back in train so you might expect some
+problem :
+- it  is know akonadi based (so i guess Radu is going to check for another MUA
+ )
+- the migration can takes a lof of times ( here it takes 5 minutes for 2 DIMAP
+accounts however i had to wait 30 minutes before getting all my mails really
+available)
+- it's slower than kmail 1.x
+- it seems that kdepim translation are not included in current kde-l10n
+tarball
+
+Regarding the rest of KDE SC, we're following the « splitted » tarball process
+so for example some packages has been splitted of several packages : kate from
+kdesk & kdelibs, kde-wallpappers for kdebase-workspace etc etc
+
+
+Good luck
+
+-- 
+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-June/006114.html b/zarb-ml/mageia-dev/2011-June/006114.html new file mode 100644 index 000000000..71fcbed08 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006114.html @@ -0,0 +1,81 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Angelo Naselli + anaselli at linux.it +
+ Wed Jun 29 10:56:27 CEST 2011 +

+
+ +
mercoledì 29 giugno 2011 alle 00:23, andre999 ha scritto:
+> A leaf package is a package that is not required by any other package.
+> But leaf packages will always require something else.
+> If B requires A, then A is not a leaf package, even though B could be.
+> When backporting B, we test to make sure that it works with release A.
+> Obviously it restricts what can be backported, but the trade-off is that backports will 
+> (almost always) work, and they won't break anything.
+
+Well my point is i often backport something for my job (for the most
+commoncpp2 now, ucommon in future), and since they are libraries i can fall
+in errors. I always tested before backporting though, and i haven't had any problems
+upgrading, but that's me and i could have been lucky.
+
+If we can accept some exceptions from time to time, but proved (bug open, testing
+and updates/backports etc) i can think to have mageia not only at home or in a virtual
+box. Otherwise i can't see the need of backports, for me of course.
+
+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/20110629/3ac985d8/attachment.asc>
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006115.html b/zarb-ml/mageia-dev/2011-June/006115.html new file mode 100644 index 000000000..3411ec350 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006115.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Wed Jun 29 11:03:06 CEST 2011 +

+
+ +
2011/6/29 Angelo Naselli <anaselli at linux.it>:
+> mercoledì 29 giugno 2011 alle 00:23, andre999 ha scritto:
+>> A leaf package is a package that is not required by any other package.
+>> But leaf packages will always require something else.
+>> If B requires A, then A is not a leaf package, even though B could be.
+>> When backporting B, we test to make sure that it works with release A.
+>> Obviously it restricts what can be backported, but the trade-off is that backports will
+>> (almost always) work, and they won't break anything.
+>
+> Well my point is i often backport something for my job (for the most
+> commoncpp2 now, ucommon in future), and since they are libraries i can fall
+> in errors. I always tested before backporting though, and i haven't had any problems
+> upgrading, but that's me and i could have been lucky.
+>
+> If we can accept some exceptions from time to time, but proved (bug open, testing
+> and updates/backports etc) i can think to have mageia not only at home or in a virtual
+> box. Otherwise i can't see the need of backports, for me of course.
+
+As this is being discussed we have a nice practical example in the forum:
+https://forums.mageia.org/en/viewtopic.php?f=8&t=667
+
+A guy is using Mageia 1 which provides lyx 1.6. He already has several
+documents done with lyx 2.0, so he needs lyx 2.0 in Mageia.
+
+Now lyx 2.0 is in Cauldron. Say the guy does not want to use Cauldron
+because of the risk of instability. This is a perfect use case for a
+backport of lyx 2.0 for Mageia 1. How would we go about that according
+to policy?
+
+-- 
+wobo
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006116.html b/zarb-ml/mageia-dev/2011-June/006116.html new file mode 100644 index 000000000..01d0e4aa8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006116.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] KDE SC 4.7 RC1 landing on cauldron + + + + + + + + + +

[Mageia-dev] KDE SC 4.7 RC1 landing on cauldron

+ Angelo Naselli + anaselli at linux.it +
+ Wed Jun 29 11:04:23 CEST 2011 +

+
+ +
mercoledì 29 giugno 2011 alle 09:59, John Balcaen ha scritto:
+> - the migration can takes a lof of times ( here it takes 5 minutes for 2 DIMAP
+> accounts however i had to wait 30 minutes before getting all my mails really
+> available)
+do you mean 30 minutes only for migrations... or to get imap mail also?
+I mean at last, the mail download time is not 30 minutes... i hope :)
+
+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/20110629/355955e7/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006117.html b/zarb-ml/mageia-dev/2011-June/006117.html new file mode 100644 index 000000000..fa6edb163 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006117.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] Some links in /etc + + + + + + + + + +

[Mageia-dev] Some links in /etc

+ Cazzaniga Sandro + cazzaniga.sandro at gmail.com +
+ Wed Jun 29 11:32:56 CEST 2011 +

+
+ +
Hi,
+
+can someone tell me the utility of the following links:
+
+- /etc/mandriva-release (-> mageia-release)
+- /etc/mandrakelinux-release (-> mageia-release)
+- /etc/mandrake-release (-> mageia-release)
+- /etc/redhat-release (-> mageia-release)
+
+Thanks.
+-- 
+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
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006118.html b/zarb-ml/mageia-dev/2011-June/006118.html new file mode 100644 index 000000000..ea6d1883b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006118.html @@ -0,0 +1,122 @@ + + + + [Mageia-dev] Some links in /etc + + + + + + + + + +

[Mageia-dev] Some links in /etc

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Wed Jun 29 11:50:24 CEST 2011 +

+
+ +
'Twas brillig, and Cazzaniga Sandro at 29/06/11 10:32 did gyre and gimble:
+> Hi,
+> 
+> can someone tell me the utility of the following links:
+> 
+> - /etc/mandriva-release (-> mageia-release)
+> - /etc/mandrakelinux-release (-> mageia-release)
+> - /etc/mandrake-release (-> mageia-release)
+> - /etc/redhat-release (-> mageia-release)
+> 
+
+These are various files that has built up as a tradition over the years.
+Several external systems (e.g. generic installers etc) check for this
+/etc/*-release file to determine which distro they are on in order to
+customise certain things to fit in.
+
+These files are provided such that external systems can do their thing
+in a manner that makes sense.
+
+I'm not sure if some of the older files (i.e.mandrake*) could just be
+dropped without too many problems, but I suspect this to be the case
+
+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-June/006119.html b/zarb-ml/mageia-dev/2011-June/006119.html new file mode 100644 index 000000000..b91fa2c9f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006119.html @@ -0,0 +1,140 @@ + + + + [Mageia-dev] [115573] SILENT: new file ./SOURCES/gnome-video-effects-0.3. 0-fix-noarch-build.patch + + + + + + + + + +

[Mageia-dev] [115573] SILENT: new file ./SOURCES/gnome-video-effects-0.3. 0-fix-noarch-build.patch

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Wed Jun 29 11:51:24 CEST 2011 +

+
+ +
hi,
+
+On Wed, 29 Jun 2011, root at mageia.org wrote:
+
+> Revision: 115573
+> Author:   wally
+> Date:     2011-06-29 07:17:59 +0200 (Wed, 29 Jun 2011)
+> Log Message:
+> -----------
+> SILENT: new file ./SOURCES/gnome-video-effects-0.3.0-fix-noarch-build.patch
+>
+> Added Paths:
+> -----------
+>    cauldron/gnome-video-effects/current/SOURCES/gnome-video-effects-0.3.0-fix-noarch-build.patch
+>
+> Added: cauldron/gnome-video-effects/current/SOURCES/gnome-video-effects-0.3.0-fix-noarch-build.patch
+> ===================================================================
+> --- cauldron/gnome-video-effects/current/SOURCES/gnome-video-effects-0.3.0-fix-noarch-build.patch	                        (rev 0)
+> +++ cauldron/gnome-video-effects/current/SOURCES/gnome-video-effects-0.3.0-fix-noarch-build.patch	2011-06-29 05:17:59 UTC (rev 115573)
+> @@ -0,0 +1,23 @@
+> +--- ./config.sub.archfix	2008-04-01 19:46:41.000000000 +0200
+> ++++ ./config.sub	2011-04-28 16:43:03.000000000 +0200
+> +@@ -352,7 +352,7 @@ case $basic_machine in
+> + 	| mt-* \
+> + 	| msp430-* \
+> + 	| nios-* | nios2-* \
+> +-	| none-* | np1-* | ns16k-* | ns32k-* \
+> ++	| noarch-* | none-* | np1-* | ns16k-* | ns32k-* \
+> + 	| orion-* \
+> + 	| pdp10-* | pdp11-* | pj-* | pjl-* | pn-* | power-* \
+> + 	| powerpc-* | powerpc64-* | powerpc64le-* | powerpcle-* | ppcbe-* \
+> +@@ -768,6 +768,9 @@ case $basic_machine in
+> + 		basic_machine=i960-intel
+> + 		os=-nindy
+> + 		;;
+> ++	noarch)
+> ++		basic_machine=noarch
+> ++		;;
+> + 	mon960)
+> + 		basic_machine=i960-intel
+> + 		os=-mon960
+> +
+> +
+
+You patched a copy of a standard automake file here while only original 
+source files are supposed to be patched. If you want to fix %configure for 
+noarch packages this way, patch automake itself. Running autoreconf -fi 
+(which you removed from the specfile) should then install the fixed 
+config.sub.
+
+I'm not sure if patching config.sub is the best way to solve the problem 
+(for noarch packages, %configure2_5x passes noarch-mageia-linux-gnu to 
+./configure but that target is rejected). It happens in other packages as 
+well and this doesn't look like a new problem, but I don't know of any 
+existing solution.
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006120.html b/zarb-ml/mageia-dev/2011-June/006120.html new file mode 100644 index 000000000..30011e5ce --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006120.html @@ -0,0 +1,155 @@ + + + + [Mageia-dev] [115573] SILENT: new file ./SOURCES/gnome-video-effects-0.3. 0-fix-noarch-build.patch + + + + + + + + + +

[Mageia-dev] [115573] SILENT: new file ./SOURCES/gnome-video-effects-0.3. 0-fix-noarch-build.patch

+ Jani Välimaa + jani.valimaa at gmail.com +
+ Wed Jun 29 13:04:45 CEST 2011 +

+
+ +
2011/6/29 Christiaan Welvaart <cjw at daneel.dyndns.org>:
+> hi,
+>
+> On Wed, 29 Jun 2011, root at mageia.org wrote:
+>
+>> Revision: 115573
+>> Author:   wally
+>> Date:     2011-06-29 07:17:59 +0200 (Wed, 29 Jun 2011)
+>> Log Message:
+>> -----------
+>> SILENT: new file
+>> ./SOURCES/gnome-video-effects-0.3.0-fix-noarch-build.patch
+>>
+>> Added Paths:
+>> -----------
+>>
+>> cauldron/gnome-video-effects/current/SOURCES/gnome-video-effects-0.3.0-fix-noarch-build.patch
+>>
+>> Added:
+>> cauldron/gnome-video-effects/current/SOURCES/gnome-video-effects-0.3.0-fix-noarch-build.patch
+>> ===================================================================
+>> ---
+>> cauldron/gnome-video-effects/current/SOURCES/gnome-video-effects-0.3.0-fix-noarch-build.patch
+>>                               (rev 0)
+>> +++
+>> cauldron/gnome-video-effects/current/SOURCES/gnome-video-effects-0.3.0-fix-noarch-build.patch
+>>       2011-06-29 05:17:59 UTC (rev 115573)
+>> @@ -0,0 +1,23 @@
+>> +--- ./config.sub.archfix       2008-04-01 19:46:41.000000000 +0200
+>> ++++ ./config.sub       2011-04-28 16:43:03.000000000 +0200
+>> +@@ -352,7 +352,7 @@ case $basic_machine in
+>> +       | mt-* \
+>> +       | msp430-* \
+>> +       | nios-* | nios2-* \
+>> +-      | none-* | np1-* | ns16k-* | ns32k-* \
+>> ++      | noarch-* | none-* | np1-* | ns16k-* | ns32k-* \
+>> +       | orion-* \
+>> +       | pdp10-* | pdp11-* | pj-* | pjl-* | pn-* | power-* \
+>> +       | powerpc-* | powerpc64-* | powerpc64le-* | powerpcle-* | ppcbe-*
+>> \
+>> +@@ -768,6 +768,9 @@ case $basic_machine in
+>> +               basic_machine=i960-intel
+>> +               os=-nindy
+>> +               ;;
+>> ++      noarch)
+>> ++              basic_machine=noarch
+>> ++              ;;
+>> +       mon960)
+>> +               basic_machine=i960-intel
+>> +               os=-mon960
+>> +
+>> +
+>
+> You patched a copy of a standard automake file here while only original
+> source files are supposed to be patched. If you want to fix %configure for
+> noarch packages this way, patch automake itself. Running autoreconf -fi
+> (which you removed from the specfile) should then install the fixed
+> config.sub.
+>
+> I'm not sure if patching config.sub is the best way to solve the problem
+> (for noarch packages, %configure2_5x passes noarch-mageia-linux-gnu to
+> ./configure but that target is rejected). It happens in other packages as
+> well and this doesn't look like a new problem, but I don't know of any
+> existing solution.
+>
+
+Oh,
+
+okay, it's not the best possible workaround. I'll revert changes and
+use the 'original' workaround (without hardcoded %_build_vendor)..
+
+-- 
+Jani Välimaa
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006121.html b/zarb-ml/mageia-dev/2011-June/006121.html new file mode 100644 index 000000000..c356afb8f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006121.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] KDE SC 4.7 RC1 landing on cauldron + + + + + + + + + +

[Mageia-dev] KDE SC 4.7 RC1 landing on cauldron

+ Funda Wang + fundawang at gmail.com +
+ Wed Jun 29 13:18:08 CEST 2011 +

+
+ +
One sugggestion, libkdeedu shouldn't obsoletes whole kdeedu4. kdeedu4
+should still exist as a meta package. The same for kdegraphics4.
+
+2011/6/29 John Balcaen <mikala at mageia.org>:
+> Hello,
+>
+> I'm going to push today KDE SC 4.7 RC1 on cauldron.
+> Most of packages are ready except in fact some kdebindings related one, but
+> i'm quite busy so i'll (or someone else funda maybe  ) fix it later.
+>
+> Please note that KDEPIM SC 4.7 is now back in train so you might expect some
+> problem :
+> - it  is know akonadi based (so i guess Radu is going to check for another MUA
+>  )
+> - the migration can takes a lof of times ( here it takes 5 minutes for 2 DIMAP
+> accounts however i had to wait 30 minutes before getting all my mails really
+> available)
+> - it's slower than kmail 1.x
+> - it seems that kdepim translation are not included in current kde-l10n
+> tarball
+>
+> Regarding the rest of KDE SC, we're following the « splitted » tarball process
+> so for example some packages has been splitted of several packages : kate from
+> kdesk & kdelibs, kde-wallpappers for kdebase-workspace etc etc
+>
+>
+> Good luck
+>
+> --
+> 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-June/006122.html b/zarb-ml/mageia-dev/2011-June/006122.html new file mode 100644 index 000000000..4ba60aaf9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006122.html @@ -0,0 +1,83 @@ + + + + [Mageia-dev] KDE SC 4.7 RC1 landing on cauldron + + + + + + + + + +

[Mageia-dev] KDE SC 4.7 RC1 landing on cauldron

+ John Balcaen + mikala at mageia.org +
+ Wed Jun 29 13:23:17 CEST 2011 +

+
+ +
2011/6/29 Angelo Naselli <anaselli at linux.it>:
+> mercoledì 29 giugno 2011 alle 09:59, John Balcaen ha scritto:
+>> - the migration can takes a lof of times ( here it takes 5 minutes for 2 DIMAP
+>> accounts however i had to wait 30 minutes before getting all my mails really
+>> available)
+> do you mean 30 minutes only for migrations... or to get imap mail also?
+> I mean at last, the mail download time is not 30 minutes... i hope :)
+I supposed it's for the end of migration not for d
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006123.html b/zarb-ml/mageia-dev/2011-June/006123.html new file mode 100644 index 000000000..1bbda3ff6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006123.html @@ -0,0 +1,85 @@ + + + + [Mageia-dev] KDE SC 4.7 RC1 landing on cauldron + + + + + + + + + +

[Mageia-dev] KDE SC 4.7 RC1 landing on cauldron

+ John Balcaen + mikala at mageia.org +
+ Wed Jun 29 13:23:35 CEST 2011 +

+
+ +
2011/6/29 Funda Wang <fundawang at gmail.com>:
+> One sugggestion, libkdeedu shouldn't obsoletes whole kdeedu4. kdeedu4
+> should still exist as a meta package.
+Well we do have (Angelo ?) a metapackage for edu applications so i'm
+not sure we should keep one more empty package.
+
+>The same for kdegraphics4.
+
+Here i'm agree :)
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006124.html b/zarb-ml/mageia-dev/2011-June/006124.html new file mode 100644 index 000000000..387cd1588 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006124.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] KDE SC 4.7 RC1 landing on cauldron + + + + + + + + + +

[Mageia-dev] KDE SC 4.7 RC1 landing on cauldron

+ John Balcaen + mikala at mageia.org +
+ Wed Jun 29 13:28:34 CEST 2011 +

+
+ +
2011/6/29 John Balcaen <mikala at mageia.org>:
+> 2011/6/29 Funda Wang <fundawang at gmail.com>:
+>> One sugggestion, libkdeedu shouldn't obsoletes whole kdeedu4. kdeedu4
+>> should still exist as a meta package.
+> Well we do have (Angelo ?) a metapackage for edu applications so i'm
+> not sure we should keep one more empty package.
+>
+>>The same for kdegraphics4.
+>
+> Here i'm agree :)
+Could you create this one please ?
+Also there's still some missing packages from the older kdebindings
+packages if you want to have a look (i won't have the time to do it
+today :/ )
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006125.html b/zarb-ml/mageia-dev/2011-June/006125.html new file mode 100644 index 000000000..447fd6316 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006125.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] [115561] add versioned requires for common package + + + + + + + + + +

[Mageia-dev] [115561] add versioned requires for common package

+ John Balcaen + mikala at mageia.org +
+ Wed Jun 29 13:44:20 CEST 2011 +

+
+ +
2011/6/29  <root at mageia.org>:
+> Revision 115561 Author fwang Date 2011-06-29 06:48:40 +0200 (Wed, 29 Jun
+[...]
+> Modified: cauldron/libkipi/current/SPECS/libkipi.spec
+> ===================================================================
+> --- cauldron/libkipi/current/SPECS/libkipi.spec	2011-06-29 04:47:46 UTC (rev
+> 115560)
+> +++ cauldron/libkipi/current/SPECS/libkipi.spec	2011-06-29 04:48:40 UTC (rev
+> 115561)
+> @@ -39,7 +39,7 @@
+>  %package -n %{libkipi}
+>  Summary: libkipi library
+>  Group: System/Libraries
+> -Requires: kipi-common
+> +Requires: kipi-common = %{epoch}:%{version}
+[...]
+Should we really have a library requiring an other package ? (via an
+explicit Requires i mean)
+(maybe we should move this requires to somewhere else ? )
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006126.html b/zarb-ml/mageia-dev/2011-June/006126.html new file mode 100644 index 000000000..d0ab554b3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006126.html @@ -0,0 +1,89 @@ + + + + [Mageia-dev] KDE SC 4.7 RC1 landing on cauldron + + + + + + + + + +

[Mageia-dev] KDE SC 4.7 RC1 landing on cauldron

+ John Balcaen + mikala at mageia.org +
+ Wed Jun 29 13:49:15 CEST 2011 +

+
+ +
2011/6/29 John Balcaen <mikala at mageia.org>:
+> 2011/6/29 Angelo Naselli <anaselli at linux.it>:
+>> mercoledì 29 giugno 2011 alle 09:59, John Balcaen ha scritto:
+>>> - the migration can takes a lof of times ( here it takes 5 minutes for 2 DIMAP
+>>> accounts however i had to wait 30 minutes before getting all my mails really
+>>> available)
+>> do you mean 30 minutes only for migrations... or to get imap mail also?
+>> I mean at last, the mail download time is not 30 minutes... i hope :)
+> I supposed it's for the end of migration not for d
+>
+Hum i hit my keyboard too fast :)
+So yes the migration was about 30 minutes.
+Regarding mail fetching... it is far from perfect :/
+At least it's not crashing like it was crashing during the first 4.6 beta/alpha.
+But we'll have probably to reports some bugs upstream
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006127.html b/zarb-ml/mageia-dev/2011-June/006127.html new file mode 100644 index 000000000..caf142957 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006127.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Michael Scherer + misc at zarb.org +
+ Wed Jun 29 15:37:33 CEST 2011 +

+
+ +
Le mercredi 29 juin 2011 à 10:56 +0200, Angelo Naselli a écrit :
+> mercoledì 29 giugno 2011 alle 00:23, andre999 ha scritto:
+> > A leaf package is a package that is not required by any other package.
+> > But leaf packages will always require something else.
+> > If B requires A, then A is not a leaf package, even though B could be.
+> > When backporting B, we test to make sure that it works with release A.
+> > Obviously it restricts what can be backported, but the trade-off is that backports will 
+> > (almost always) work, and they won't break anything.
+> 
+> Well my point is i often backport something for my job (for the most
+> commoncpp2 now, ucommon in future), and since they are libraries i can fall
+> in errors. I always tested before backporting though, and i haven't had any problems
+> upgrading, but that's me and i could have been lucky.
+>
+> If we can accept some exceptions from time to time, but proved (bug open, testing
+> and updates/backports etc) i can think to have mageia not only at home or in a virtual
+> box. Otherwise i can't see the need of backports, for me of course.
+
+If we start to add exception while we do not even have started to agree
+on the general case, we are never gonna go anywhere :)
+
+I have the impression that everybody want to be able at the same time to
+backport anything, and yet expect to have the same level of support and
+quality, and without using any more ressources. 
+
+Technically, anything could be backported with proper tests. After all,
+that's roughly the process we use for cauldron ( ie, take a new version
+of software, compile it on the distribution, and build later others
+software against that ).
+
+Every software have someone interested, from low level like kernel
+( backported on kernel-linus, asked by people as seen on MIB ), or gcc
+( gcc 4.6 being my main motivation for keeping a cooker installation )
+to higher level like gajim or midori. The only thing that no one would
+be interested is stuff that do not move ( at, linpng, etc ), ie
+everything were there is no new features, and working fine. And even,
+people could want to have a new feature, such as systemd, etc.
+
+So in the end, if we want to satisfy everybody, the answer is to have no
+policy forbidding anything and just say "do proper amount of QA". That's
+fine by me ( especially since I do not use backports ), but we have to
+agree on that.
+
+-- 
+Michael Scherer
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006128.html b/zarb-ml/mageia-dev/2011-June/006128.html new file mode 100644 index 000000000..a53cce9d9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006128.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] Meeting tonight + + + + + + + + + +

[Mageia-dev] Meeting tonight

+ Michael Scherer + misc at zarb.org +
+ Wed Jun 29 15:51:46 CEST 2011 +

+
+ +
Hi,
+
+as usual, meeting tonight.
+
+As I was rather busy fighting against microorganisms during the previous
+days, I didn't really prepared anything nor did my part of the job :/,
+besides answering to ml.
+
+So :
+- summary of specs (ennael)
+- next step for arm (misc,rtp) 
+
+( I was planning to send a email later about that last point, but didn't
+finish, so this will be a quick summary of the longer summary )
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006129.html b/zarb-ml/mageia-dev/2011-June/006129.html new file mode 100644 index 000000000..fcebc708e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006129.html @@ -0,0 +1,112 @@ + + + + [Mageia-dev] [RPM] cauldron core/release kate-4.6.90-2.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release kate-4.6.90-2.mga2

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Wed Jun 29 16:06:29 CEST 2011 +

+
+ +
On 29 June 2011 11:14, Mageia Team <buildsystem-daemon at mageia.org> wrote:
+> Name        : kate                         Relocations: (not relocatable)
+> Version     : 4.6.90                            Vendor: Mageia.Org
+> Release     : 2.mga2                        Build Date: Wed Jun 29 11:02:19 2011
+> Install Date: (not installed)               Build Host: ecosse
+> Group       : Graphical desktop/KDE         Source RPM: (none)
+> Size        : 2009792                          License: GPLv2
+> Signature   : (none)
+> Packager    : Mageia Team <http://www.mageia.org>
+> Summary     : Advanced text editor
+> Description :
+> A fast and advanced text editor with nice plugins for KDE 4.
+>
+> mikala <mikala> 2:4.6.90-2.mga2:
+> + Revision: 115701
+> - Add conflicts against kdesdk4
+> - Fix License
+> - Add conflicts against kdelibs4-core
+> - Clean spec
+> - Add more requires on the -devel package
+> - imported package kate
+>
+>  + fwang <fwang>
+>    - add group for ktexteditor
+>    - bump epoch for libkatepartinterfaces
+>    - add conflicts on older packages
+
+FWIW, I think katepart should be split in its own sub-package, and
+kwrite should require it, (otherwise kwrite would require the full
+kate package to work).
+
+Also konqueror should suggest katepart, for the embedded text editor part.
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006130.html b/zarb-ml/mageia-dev/2011-June/006130.html new file mode 100644 index 000000000..87912fab4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006130.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] [RPM] cauldron core/release kate-4.6.90-2.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release kate-4.6.90-2.mga2

+ John Balcaen + mikala at mageia.org +
+ Wed Jun 29 16:08:43 CEST 2011 +

+
+ +
2011/6/29 Ahmad Samir <ahmadsamir3891 at gmail.com>:
+> On 29 June 2011 11:14, Mageia Team <buildsystem-daemon at mageia.org> wrote:
+>> Name        : kate                         Relocations: (not relocatable)
+>> Version     : 4.6.90                            Vendor: Mageia.Org
+[...]
+>
+> FWIW, I think katepart should be split in its own sub-package, and
+> kwrite should require it, (otherwise kwrite would require the full
+> kate package to work).
+>
+> Also konqueror should suggest katepart, for the embedded text editor part.
+>
+Sure,
+Could you do the split & needed changes , i'm moving & won't be
+available to work on this today :/
+
+
+-- 
+--
+Balcaen John
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006131.html b/zarb-ml/mageia-dev/2011-June/006131.html new file mode 100644 index 000000000..2cdf544f5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006131.html @@ -0,0 +1,131 @@ + + + + [Mageia-dev] [RPM] cauldron core/release kshutdown-2.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release kshutdown-2.0-1.mga2

+ Samuel Verschelde + samuel.verschelde at pmsipilot.com +
+ Wed Jun 29 16:13:31 CEST 2011 +

+
+ +
Le mardi 14 juin 2011 14:29:12, Mageia Team a écrit :
+> Name        : kshutdown                    Relocations: (not relocatable)
+> Version     : 2.0                               Vendor: Mageia.Org
+> Release     : 1.mga2                        Build Date: Tue Jun 14 14:24:17
+> 2011 Install Date: (not installed)               Build Host: ecosse
+> Group       : Graphical desktop/KDE         Source RPM: (none)
+> Size        : 524179                           License: GPLv2+
+> Signature   : (none)
+> Packager    : Mageia Team <http://www.mageia.org>
+> URL         : http://kshutdown.sourceforge.net/
+> Summary     : Advanced shut down utility for KDE
+> Description :
+> KShutDown is an advanced shut down utility for KDE.
+> Features:
+> - Shut Down (logout and halt the system)
+> - Reboot (logout and reboot the system)
+> - Lock Screen (lock the screen using a screen saver)
+> - Logout (end the session and logout the user)
+> - Extras (user commands)
+> - Wizard
+> - Time and delay options
+> - Command line support
+> - System tray
+> - Sounds
+> - Kiosk support
+> - And more...
+> 
+> mikala <mikala> 2.0-1.mga2:
+> + Revision: 106086
+> - Follow kde spec layout
+> - clean spec
+> - imported package kshutdown
+
+In the spec there are 2 summaries, one being the translated summary to french 
+:
+
+Summary:  Advanced shut down utility for KDE
+Summary(fr):  KShutDown est un outils avancé de gestion de l'extinction
+
+Neither sophie nor I see the english summary :
+
+http://sophie.zarb.org/rpms/57c5f5903d796046db7f05f30f77e6b5
+
+[sam at localhost ~]$ rpm -q --qf '%{SUMMARY}' -p kshutdown-2.0-1.mga2.i586.rpm 
+KShutDown est un outils avancé de gestion de l'extinction
+
+
+Is that normal or must we remove the translated summary ?
+
+Best regards
+
+Samuel Verschelde
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006132.html b/zarb-ml/mageia-dev/2011-June/006132.html new file mode 100644 index 000000000..25c86ea55 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006132.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] KDE SC 4.7 RC1 landing on cauldron + + + + + + + + + +

[Mageia-dev] KDE SC 4.7 RC1 landing on cauldron

+ John Balcaen + mikala at mageia.org +
+ Wed Jun 29 16:22:36 CEST 2011 +

+
+ +
2011/6/29 John Balcaen <mikala at mageia.org>:
+> Hello,
+>
+> I'm going to push today KDE SC 4.7 RC1 on cauldron.
+[...]
+
+Ok KDE SC 4.7 RC1 has been pushed on BS &  should land soon on your
+favorite mirror.
+Please note that there's still missing packages from the « old »
+kdebindings4 packages :
+qyoto,qtruby,korundum, kross-interpreters,kimono,smokekde
+So if someone can pick them to finish the transition  since i'll be
+quite busy for the end of the week.
+Thanks for your help.
+Maybe also some package need more splitting like for kate (thks ahmad ).
+Some others might need to require by another package (i'm thinking
+about the svgpart package for example or the kdegraphics-strigi* et
+kdegraphics-thumbnailers)
+
+It's also probably the good moment to switch to digikam2.
+Also there's some requirements to fix cf
+http://check.mageia.org/dependencies.html (kdegraphics, edu & others )
+
+
+
+Regards,
+
+
+--
+Balcaen John
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006133.html b/zarb-ml/mageia-dev/2011-June/006133.html new file mode 100644 index 000000000..ec6f15d22 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006133.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] [115962] + + + + + + + + + +

[Mageia-dev] [115962]

+ John Balcaen + mikala at mageia.org +
+ Wed Jun 29 16:27:21 CEST 2011 +

+
+ +
2011/6/29  <root at mageia.org>:
+> Revision 115962 Author ze Date 2011-06-29 15:57:57 +0200 (Wed, 29 Jun 2011)
+>
+> Log Message
+>
+> - no need to buildrequire and use kde-macros
+> - use rpm native macros and not variables
+>
+[...]
+We were using kde4-macros especially because attica is maintained &
+requires by KDE, so it's easier to follow it (like a urpmf --requires
+kde4-macros Core_Release_SRPMS )
+
+
+
+
+-- 
+--
+Balcaen John
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006134.html b/zarb-ml/mageia-dev/2011-June/006134.html new file mode 100644 index 000000000..426ec300c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006134.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] [RPM] cauldron core/release kshutdown-2.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release kshutdown-2.0-1.mga2

+ John Balcaen + mikala at mageia.org +
+ Wed Jun 29 16:38:37 CEST 2011 +

+
+ +
2011/6/29 Samuel Verschelde <samuel.verschelde at pmsipilot.com>:
+[...]
+>
+> In the spec there are 2 summaries, one being the translated summary to french
+> :
+>
+> Summary:  Advanced shut down utility for KDE
+> Summary(fr):  KShutDown est un outils avancé de gestion de l'extinction
+>
+> Neither sophie nor I see the english summary :
+>
+> http://sophie.zarb.org/rpms/57c5f5903d796046db7f05f30f77e6b5
+>
+> [sam at localhost ~]$ rpm -q --qf '%{SUMMARY}' -p kshutdown-2.0-1.mga2.i586.rpm
+> KShutDown est un outils avancé de gestion de l'extinction
+>
+>
+> Is that normal or must we remove the translated summary ?
+>
+I did not remove it initially because urpmq was working with it & it
+seems used in opensuse too (translated summary)
+
+
+eg: urpmq -S kshutdown
+kshutdown : Advanced shut down utility for KDE ( 2.0-1.mga2 )
+
+
+
+-- 
+--
+Balcaen John
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006135.html b/zarb-ml/mageia-dev/2011-June/006135.html new file mode 100644 index 000000000..479c9cea7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006135.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] KDE SC 4.7 RC1 landing on cauldron + + + + + + + + + +

[Mageia-dev] KDE SC 4.7 RC1 landing on cauldron

+ John Balcaen + mikala at mageia.org +
+ Wed Jun 29 17:28:09 CEST 2011 +

+
+ +
2011/6/29 John Balcaen <mikala at mageia.org>:
+> [...]
+> Please note that there's still missing packages from the « old »
+> kdebindings4 packages :
+> qyoto,qtruby,korundum, kross-interpreters,kimono,smokekde
+Hum there's also perl-kde4 :)
+
+thks,
+
+
+
+
+--
+Balcaen John
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006136.html b/zarb-ml/mageia-dev/2011-June/006136.html new file mode 100644 index 000000000..c39162aad --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006136.html @@ -0,0 +1,77 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Angelo Naselli + anaselli at linux.it +
+ Wed Jun 29 17:28:30 CEST 2011 +

+
+ +
mercoledì 29 giugno 2011 alle 15:37, Michael Scherer ha scritto:
+> If we start to add exception while we do not even have started to agree
+> on the general case, we are never gonna go anywhere :)
+Yes sorry, that was not my intention :)
+I do believe we're an open community and as in every open community
+we, and I first, don't impose just talk and decide. So every decision
+will be taken is fine for me.
+
+Said that what i meant was, if someone open a backport request, and
+there are people who can take care about, that should not close by
+default if does not respect all the policies, and that's for the same
+reason of openness... 
+ 
+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/20110629/07ebaf24/attachment.asc>
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006137.html b/zarb-ml/mageia-dev/2011-June/006137.html new file mode 100644 index 000000000..f7c13295b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006137.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] [RPM] cauldron core/release kate-4.6.90-2.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release kate-4.6.90-2.mga2

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Wed Jun 29 17:32:05 CEST 2011 +

+
+ +
On 29 June 2011 16:08, John Balcaen <mikala at mageia.org> wrote:
+> 2011/6/29 Ahmad Samir <ahmadsamir3891 at gmail.com>:
+>> On 29 June 2011 11:14, Mageia Team <buildsystem-daemon at mageia.org> wrote:
+>>> Name        : kate                         Relocations: (not relocatable)
+>>> Version     : 4.6.90                            Vendor: Mageia.Org
+> [...]
+>>
+>> FWIW, I think katepart should be split in its own sub-package, and
+>> kwrite should require it, (otherwise kwrite would require the full
+>> kate package to work).
+>>
+>> Also konqueror should suggest katepart, for the embedded text editor part.
+>>
+> Sure,
+> Could you do the split & needed changes , i'm moving & won't be
+> available to work on this today :/
+>
+>
+
+Done.
+
+> --
+> --
+> Balcaen John
+>
+
+
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006138.html b/zarb-ml/mageia-dev/2011-June/006138.html new file mode 100644 index 000000000..956cdf5e2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006138.html @@ -0,0 +1,78 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Wed Jun 29 19:13:56 CEST 2011 +

+
+ +
Op woensdag 29 juni 2011 17:28:30 schreef Angelo Naselli:
+> mercoledì 29 giugno 2011 alle 15:37, Michael Scherer ha scritto:
+> > If we start to add exception while we do not even have started to agree
+> > on the general case, we are never gonna go anywhere :)
+> 
+> Yes sorry, that was not my intention :)
+> I do believe we're an open community and as in every open community
+> we, and I first, don't impose just talk and decide. So every decision
+> will be taken is fine for me.
+> 
+> Said that what i meant was, if someone open a backport request, and
+> there are people who can take care about, that should not close by
+> default if does not respect all the policies, and that's for the same
+> reason of openness...
+> 
+> Angelo
+
+actually, perhaps we should implement a strict policy, and if people wish to 
+deviate, i have an urpmi-proxy program, that has local overrides, in general, 
+it requests stuff from an external mirror, and you can also have a local 
+repository, and if you use the proxy, it can sort of backport whatever you 
+want if you rebuild it yourself in your local repos.
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006139.html b/zarb-ml/mageia-dev/2011-June/006139.html new file mode 100644 index 000000000..a0d33e61f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006139.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] How is the obsoleted binaries be removed? + + + + + + + + + +

[Mageia-dev] How is the obsoleted binaries be removed?

+ Zé + mmodem00 at gmail.com +
+ Wed Jun 29 19:42:10 CEST 2011 +

+
+ +
2011/6/27 Funda Wang <fundawang at gmail.com>:
+> Hello,
+>
+> How is the obsoleted binaries be removed currently in Mageia? Does the
+> maintainer need to call for this? If yes, please remove
+> lib{,64}devhelp-2_1 from cauldron.
+>
+> Thanks.
+>
+whats current problem?
+
+You can obsolete it through BS, add an entry in the spec about it.
+
+
+-- 
+Zé
+
+ + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006140.html b/zarb-ml/mageia-dev/2011-June/006140.html new file mode 100644 index 000000000..8d9842bf4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006140.html @@ -0,0 +1,110 @@ + + + + [Mageia-dev] [RPM] cauldron core/release kshutdown-2.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release kshutdown-2.0-1.mga2

+ Dick Gevers + dvgevers at xs4all.nl +
+ Wed Jun 29 21:18:48 CEST 2011 +

+
+ +
On Wed, 29 Jun 2011 11:38:37 -0300, John Balcaen wrote about Re:
+[Mageia-dev] [RPM] cauldron core/release kshutdown-2.0-1.mga2:
+
+>2011/6/29 Samuel Verschelde <samuel.verschelde at pmsipilot.com>:
+>[...]
+>>
+>> In the spec there are 2 summaries, one being the translated summary to
+>> french :
+>>
+>> Summary:  Advanced shut down utility for KDE
+>> Summary(fr):  KShutDown est un outils avancé de gestion de l'extinction
+>>
+>> Neither sophie nor I see the english summary :
+>>
+>> http://sophie.zarb.org/rpms/57c5f5903d796046db7f05f30f77e6b5
+>>
+>> [sam at localhost ~]$ rpm -q --qf '%{SUMMARY}' -p
+>> kshutdown-2.0-1.mga2.i586.rpm KShutDown est un outils avancé de gestion
+>> de l'extinction
+>>
+>>
+>> Is that normal or must we remove the translated summary ?
+>>
+>I did not remove it initially because urpmq was working with it & it
+>seems used in opensuse too (translated summary)
+>
+>
+>eg: urpmq -S kshutdown
+>kshutdown : Advanced shut down utility for KDE ( 2.0-1.mga2 )
+
+Please compare:
+https://bugs.mageia.org/show_bug.cgi?id=95
+https://qa.mandriva.com/show_bug.cgi?id=32870 and
+https://qa.mandriva.com/show_bug.cgi?id=63229
+
+Thanks & BFN,
+=Dick Gevers=
+
+
+
+ + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006141.html b/zarb-ml/mageia-dev/2011-June/006141.html new file mode 100644 index 000000000..ca1ee6771 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006141.html @@ -0,0 +1,116 @@ + + + + [Mageia-dev] Backports policy proposal + + + + + + + + + +

[Mageia-dev] Backports policy proposal

+ andre999 + andr55 at laposte.net +
+ Wed Jun 29 21:19:00 CEST 2011 +

+
+ +
Michael Scherer a écrit :
+> Le lundi 27 juin 2011 à 21:42 -0400, andre999 a écrit :
+>> Michael Scherer a écrit :
+>>>
+>>> Le vendredi 24 juin 2011 à 16:20 -0400, andre999 a écrit :
+>>>> Michael Scherer a écrit :
+>>
+>> [...]
+>>
+>>>>> - cannot be backported if the package was just created and is thus basically untested in cauldron
+>>>>
+>>>> What about corner cases where a potential backport is incompatible with changes introduced in
+>>>> cauldron ?  Should we leave such packages to third parties ?  (I would tend to say yes.)
+>>>
+>>> Give a more precise example.
+>>
+>> Suppose leaf package fooa depends on foob.  foob is part of the current release.
+>> Cauldron replaces foob with fooc.  fooa is incompatible with fooc.
+>
+> Then why do we replace foob by it in the first place if this break fooa ?
+
+(see below)
+
+>> fooa is requested by some users, and future versions of fooa are intended to be
+>> compatible with fooc.
+>> In this case, even though it wouldn't be testable in cauldron, it could be tested in
+>> backports-testing, and I think it could be a good idea to allow it.
+>>
+>> Even if fooc compatibility wouldn't be available for the next Mageia release, a user
+>> could avoid updating for a release in order to keep using fooa.
+>> However, if there were no intention to make fooa compatible with fooc, maybe it should
+>> be denied.
+>
+> The example is bogus. If we have fooa in the distro and we upload fooc
+> that break it, then we have to fix the breakage as a priority. Usually,
+> that would be having foob and fooc as parallel installablable.
+
+The idea is that fooa is not in release, but is compatible with release, and not with 
+cauldron.  (More details below.)
+
+> Anyway, the question is "how often does it" happens ? Because "it may
+> happen" is not a justification" if in practice, it never happen. And not
+> having a backport is not the end of the world so unless the problem is
+> quite frequent ( and so far, this one is far from being frequent ,
+> especially since it is based on a wrong supposition in the first part ),
+> I do not think this would be blocking.
+
+Often enough there will be changes in cauldron to newer packages not entirely compatible 
+with the older ones they are replacing.  And other existing packages are dependant on 
+them, so they have to be fixed in cauldron.
+Backport requests could be compatible with release but not cauldron.  I wouldn't expect 
+that to be frequent, but such requests have already happened.
+In some cases the updates for compatibility from upstream could just be late in coming.
+
+The question is, should we allow such backports under certain circumstances ?
+I'm not necessarily saying yes.
+Maybe we should say not for now, to be reviewed later ?
+
+-- 
+André
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006142.html b/zarb-ml/mageia-dev/2011-June/006142.html new file mode 100644 index 000000000..b8bfd1b54 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006142.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ andre999 + andr55 at laposte.net +
+ Wed Jun 29 21:19:42 CEST 2011 +

+
+ +
Michael Scherer a écrit :
+> Le mercredi 29 juin 2011 à 10:56 +0200, Angelo Naselli a écrit :
+>> mercoledì 29 giugno 2011 alle 00:23, andre999 ha scritto:
+>>> A leaf package is a package that is not required by any other package.
+>>> But leaf packages will always require something else.
+>>> If B requires A, then A is not a leaf package, even though B could be.
+>>> When backporting B, we test to make sure that it works with release A.
+>>> Obviously it restricts what can be backported, but the trade-off is that backports will
+>>> (almost always) work, and they won't break anything.
+>>
+>> Well my point is i often backport something for my job (for the most
+>> commoncpp2 now, ucommon in future), and since they are libraries i can fall
+>> in errors. I always tested before backporting though, and i haven't had any problems
+>> upgrading, but that's me and i could have been lucky.
+>>
+>> If we can accept some exceptions from time to time, but proved (bug open, testing
+>> and updates/backports etc) i can think to have mageia not only at home or in a virtual
+>> box. Otherwise i can't see the need of backports, for me of course.
+>
+> If we start to add exception while we do not even have started to agree
+> on the general case, we are never gonna go anywhere :)
+>
+> I have the impression that everybody want to be able at the same time to
+> backport anything, and yet expect to have the same level of support and
+> quality, and without using any more ressources.
+>
+> Technically, anything could be backported with proper tests. After all,
+> that's roughly the process we use for cauldron ( ie, take a new version
+> of software, compile it on the distribution, and build later others
+> software against that ).
+>
+> Every software have someone interested, from low level like kernel
+> ( backported on kernel-linus, asked by people as seen on MIB ), or gcc
+> ( gcc 4.6 being my main motivation for keeping a cooker installation )
+> to higher level like gajim or midori. The only thing that no one would
+> be interested is stuff that do not move ( at, linpng, etc ), ie
+> everything were there is no new features, and working fine. And even,
+> people could want to have a new feature, such as systemd, etc.
+>
+> So in the end, if we want to satisfy everybody, the answer is to have no
+> policy forbidding anything and just say "do proper amount of QA". That's
+> fine by me ( especially since I do not use backports ), but we have to
+> agree on that.
+
+I see this as an argument for having simple, clean basic rules (the "general case"), on 
+which we can have well-defined exceptions, some (or all) of which may require 
+case-by-case approval.
+
+So let's accept the initial proposal as the base rules.
+Then define some well-defined exceptions, for use cases that fall outside these base 
+rules.  And whether each particular exception should require case-by-case approval.
+
+-- 
+André
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006143.html b/zarb-ml/mageia-dev/2011-June/006143.html new file mode 100644 index 000000000..1ead05ae0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006143.html @@ -0,0 +1,79 @@ + + + + [Mageia-dev] How is the obsoleted binaries be removed? + + + + + + + + + +

[Mageia-dev] How is the obsoleted binaries be removed?

+ Dexter Morgan + dmorganec at gmail.com +
+ Wed Jun 29 22:45:57 CEST 2011 +

+
+ +
On Wed, Jun 29, 2011 at 7:42 PM, Zé <mmodem00 at gmail.com> wrote:
+> 2011/6/27 Funda Wang <fundawang at gmail.com>:
+>> Hello,
+>>
+>> How is the obsoleted binaries be removed currently in Mageia? Does the
+>> maintainer need to call for this? If yes, please remove
+>> lib{,64}devhelp-2_1 from cauldron.
+>>
+>> Thanks.
+>>
+> whats current problem?
+>
+> You can obsolete it through BS, add an entry in the spec about it.
+>
+
+our policy is to not obsolete libs.
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006144.html b/zarb-ml/mageia-dev/2011-June/006144.html new file mode 100644 index 000000000..17f3d55d4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006144.html @@ -0,0 +1,79 @@ + + + + [Mageia-dev] How is the obsoleted binaries be removed? + + + + + + + + + +

[Mageia-dev] How is the obsoleted binaries be removed?

+ Dexter Morgan + dmorganec at gmail.com +
+ Wed Jun 29 22:46:17 CEST 2011 +

+
+ +
On Mon, Jun 27, 2011 at 6:00 PM, Funda Wang <fundawang at gmail.com> wrote:
+> Hello,
+>
+> How is the obsoleted binaries be removed currently in Mageia? Does the
+> maintainer need to call for this? If yes, please remove
+> lib{,64}devhelp-2_1 from cauldron.
+>
+> Thanks.
+>
+
+hi,
+
+i will look if this have been done, if no i will remove them
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006145.html b/zarb-ml/mageia-dev/2011-June/006145.html new file mode 100644 index 000000000..e8eb0d5df --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006145.html @@ -0,0 +1,201 @@ + + + + [Mageia-dev] proposal regarding (packager) mentoring program coordinator + + + + + + + + + +

[Mageia-dev] proposal regarding (packager) mentoring program coordinator

+ andre999 + andr55 at laposte.net +
+ Wed Jun 29 23:27:08 CEST 2011 +

+
+ +
proposal regarding mentoring program coordinator
+
+In various parts of the proposal I assume that users with a Mageia account can 
+receive email redirected to them from pseudo at mageia.org, to the address they 
+give on the Mageia account.  (pseudo being their mageia account name.)
+(Stormi : it should work for all packagers, but not for new users I think)
+(Which explains why it doesn't work for my account, as I'm not yet officially a 
+packager.) (but it would be good to activate that for everyone.)
+
+That way, just knowing their pseudo will be enough to know a contact email 
+address.  This also means one less field to enter in the various tables used for 
+packagers and others on Mageia.
+
+1) Reorganize the packages_mentoring wiki page as the central point for coordination
+1a) regroup 1st 3 sections into intro
+     elaborate current content somewhat (max 1-2 paragraphes)
+
+1b) add section 2 : "so you want to be a Mageia packager"
+     brief intro, with examples of useful experiences
+     importance of Mageia account, mailing list subscriptions, forums
+     documentation to read (packaging, etc)
+     how to contact a potential mentor
+     (asking on irc, leaving name below, asking on mailing list)
+     table of those wanting a mentor (with lines)
+     - includes fields for pseudo/name, time zone, interests/skills/comments
+         (including language(s) if not English)
+     - date of registration (to see how long waiting)
+     - could add mentor assigned, date training started (Ubuntu has this)
+
+1c) elaborate "mentoring team" section (which becomes 3rd section)
+     starts with "registored mentors" subsection
+     make into table (with lines)
+     currently name (pseudo) ; email ; what can do (how many, focus)
+
+     add fields for :
+     -time zone
+     -langages spoken (useful for apprentices a little challenged in English)
+     -focus/interest (in place of "what can do")
+     -can take more apprentices (yes/no/maybe)
+     -preferred means of contact with apprentices (initial ; during mentoring)
+     (email, IRC, leave name in list, via coordinator ; email, IRC)
+     (could be included with focus/interest = focus/interests/comments)
+
+     if pseudo at mageia.org is automatically redirected, could drop email field
+
+1d) mentoring team / mentoring in progress subsection
+     make into table (with lines)
+     keep current organisation :
+         - subsection by mentor id
+           - one line per apprentice = pseudo + free-form comments.
+
+1e) The mentoring coordinator team is responsible for maintaining all sections 
+of this page.
+If they wish :
+- Would-be apprentices can add their own name to apprentice table
+- mentors can continue to update their mentor tables.
+
+In maintaining the page, the team should have regular contact with mentors on 
+availability to take new apprentices and the status of current apprentices.
+
+2) Mentoring coordinating team
+An informal group which works with the coordinator, to accomplish required tasks.
+For the moment we have myself (andre999), Daniel Kreuter and magnus.
+
+
+3) The mentoring coordinator team will monitoring IRC, mailing lists and forums, 
+for those interested in becoming a packager.
+Those considering becoming packagers will often be hesitant, and we need to 
+encourage them.  So let's try to maintain contact with those who show an interest.
+(It looks like we are already off to a good start.)
+
+We would like to have an email address for the team, which would direct messages 
+to all team members.
+It could be mentoring at mageia.org or similar (suggested by Daniel).
+Maybe a restricted mailing list ?
+That way anyone with an interest, so finding someone with an interest, will have 
+a way of letting everyone in the team know at once.
+
+When the wiki mentoring page is updated, we can direct them there.  (It will 
+have links to all the documentation.)
+If they already have a Mageia account (which is their pseudo), we could also 
+inscribe them in the (yet to be created) table for potential packagers on the 
+mentoring page.
+
+The mentoring team will monitor IRC.  Others noting interest could refer them to 
+the packages_mentoring page or to the mentoring team.  If not interested in 
+mentoring them, that is.
+
+The team will also monitor the mailing lists and forums, for anyone showing an 
+interest in contributing.
+Includes those in other languages.
+I intend to monitor MLO (in French), for example.
+It is useful look at external forums that talk about Mageia.  (We frequently 
+find references in the lists.)  Our positive responses can draw new users and 
+contributors.  Some of which will eventually become packagers.
+We have already been doing some of that.
+
+Note that if someone shows an interest in getting involved with Mageia, we don't 
+have to focus only on packaging.  We need all sorts of contributions, and it 
+would be useful to packagers to have other experiences, such as bug triaging and 
+QA.  So far, it seems everyone it the team is taking such an approach.
+
+4) Miscelaneous suggestions
+- Currently apprentices are promoted to full packagers by their mentor, once the 
+mentor is satisfied with the competence of the apprentice.
+It has been suggested that apprentices become full packagers by vote.
+Since this is a skill position, this would be presumably be a vote by mentors or 
+packagers.  Something to consider.
+
+- standard email with important info and links to send to potential apprentices. 
+  (This info is to be put in the potential packager section of the wiki page, so 
+maybe we just send a link to that page.)
+
+- Make list of new package requests, which are simple enough for apprentices to 
+train with.
+
+- Gather feedback on mentoring process, from mentors and apprentices
+
+- Encourage new full packagers to in turn become mentors, using their experience 
+in the mentoring process.
+
+
+Note that many of these ideas come from Daniel, magnus, Stormi and many others. 
+  Any suggestions are welcome.
+----
+
+We will start implementing the wiki page changes right away, but any input is 
+still very welcome.
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006146.html b/zarb-ml/mageia-dev/2011-June/006146.html new file mode 100644 index 000000000..95dcde203 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006146.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] How is the obsoleted binaries be removed? + + + + + + + + + +

[Mageia-dev] How is the obsoleted binaries be removed?

+ Funda Wang + fundawang at gmail.com +
+ Thu Jun 30 01:11:36 CEST 2011 +

+
+ +
2011/6/30 Dexter Morgan <dmorganec at gmail.com>:
+> On Wed, Jun 29, 2011 at 7:42 PM, Zé <mmodem00 at gmail.com> wrote:
+>> 2011/6/27 Funda Wang <fundawang at gmail.com>:
+>>> Hello,
+>>>
+>>> How is the obsoleted binaries be removed currently in Mageia? Does the
+>>> maintainer need to call for this? If yes, please remove
+>>> lib{,64}devhelp-2_1 from cauldron.
+>>>
+>>> Thanks.
+>>>
+>> whats current problem?
+>>
+>> You can obsolete it through BS, add an entry in the spec about it.
+>>
+>
+> our policy is to not obsolete libs.
+Then the repository will contain a lot of orphan libs.
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006147.html b/zarb-ml/mageia-dev/2011-June/006147.html new file mode 100644 index 000000000..cd2af1e1c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006147.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] proposal regarding (packager) mentoring program coordinator + + + + + + + + + +

[Mageia-dev] proposal regarding (packager) mentoring program coordinator

+ andre999 + andr55 at laposte.net +
+ Thu Jun 30 06:06:55 CEST 2011 +

+
+ +
andre999 a écrit :
+> proposal regarding mentoring program coordinator
+>
+
+[...]
+
+> Note that many of these ideas come from Daniel, magnus, Stormi and many
+> others. Any suggestions are welcome.
+> ----
+>
+> We will start implementing the wiki page changes right away, but any
+> input is still very welcome.
+>
+
+I've done some table conversion, much more to come :)
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006148.html b/zarb-ml/mageia-dev/2011-June/006148.html new file mode 100644 index 000000000..a3ccf6c76 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006148.html @@ -0,0 +1,73 @@ + + + + [Mageia-dev] libperl not found + + + + + + + + + +

[Mageia-dev] libperl not found

+ Thomas Spuhler + thomas at btspuhler.com +
+ Thu Jun 30 06:47:27 CEST 2011 +

+
+ +
It seems libperl.so is hiding
+It is wehre it should be but cyrus-imap cannot find it.
+-- 
+Thomas
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006149.html b/zarb-ml/mageia-dev/2011-June/006149.html new file mode 100644 index 000000000..dd7d40152 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006149.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] libperl not found + + + + + + + + + +

[Mageia-dev] libperl not found

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Thu Jun 30 06:54:58 CEST 2011 +

+
+ +
On 30 June 2011 06:47, Thomas Spuhler <thomas at btspuhler.com> wrote:
+> It seems libperl.so is hiding
+> It is wehre it should be but cyrus-imap cannot find it.
+> --
+> Thomas
+>
+
+Logs, error messages?
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006150.html b/zarb-ml/mageia-dev/2011-June/006150.html new file mode 100644 index 000000000..985b4f304 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006150.html @@ -0,0 +1,81 @@ + + + + [Mageia-dev] libperl not found + + + + + + + + + +

[Mageia-dev] libperl not found

+ Cazzaniga Sandro + cazzaniga.sandro at gmail.com +
+ Thu Jun 30 09:16:47 CEST 2011 +

+
+ +
Le 30/06/2011 06:54, Ahmad Samir a écrit :
+> It seems libperl.so is hiding
+>> It is wehre it should be but cyrus-imap cannot find it.
+Maybe we have to check cyrus-imap instead of libperl.so, so.
+
+-- 
+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
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006151.html b/zarb-ml/mageia-dev/2011-June/006151.html new file mode 100644 index 000000000..7186be981 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006151.html @@ -0,0 +1,150 @@ + + + + [Mageia-dev] [116308] + + + + + + + + + +

[Mageia-dev] [116308]

+ Dexter Morgan + dmorganec at gmail.com +
+ Thu Jun 30 09:50:44 CEST 2011 +

+
+ +
On Thu, Jun 30, 2011 at 8:38 AM,  <root at mageia.org> wrote:
+> Revision 116308 Author ze Date 2011-06-30 08:38:32 +0200 (Thu, 30 Jun 2011)
+>
+> Log Message
+>
+> - add missing files
+> - fix minor errors
+> - list dirs so that can be removed in uninstall
+>
+> Modified Paths
+>
+> cauldron/kdenetwork4/current/SPECS/kdenetwork4.spec
+>
+> Modified: cauldron/kdenetwork4/current/SPECS/kdenetwork4.spec
+> ===================================================================
+> --- cauldron/kdenetwork4/current/SPECS/kdenetwork4.spec	2011-06-30 06:13:28
+> UTC (rev 116307)
+> +++ cauldron/kdenetwork4/current/SPECS/kdenetwork4.spec	2011-06-30 06:38:32
+> UTC (rev 116308)
+> @@ -95,15 +95,11 @@
+>
+>  %files -n kde4-filesharing
+>  %defattr(-,root,root)
+> -%_kde_libdir/kde4/fileshare_propsdlgplugin.so
+> -%_kde_libdir/kde4/kcm_fileshare.so
+> -%_kde_libdir/kde4/kcm_kcmsambaconf.so
+> -%_kde_services/fileshare.desktop
+> -%_kde_services/fileshare_propsdlgplugin.desktop
+> -%_kde_services/kcmsambaconf.desktop
+> +%_kde_libdir/kde4/sambausershareplugin.so
+> +%_kde_services/sambausershareplugin.desktop
+>  %_kde_services/ServiceMenus/smb2rdc.desktop
+> -%_kde_iconsdir/*/*/apps/kcmsambaconf.*
+>
+> +
+>  #---------------------------------------------
+>  %package -n kdnssd
+>  Summary:   DNS-SD Service Discovery Monitor
+> @@ -124,7 +120,7 @@
+>  %_kde_services/zeroconf.protocol
+>
+>  #---------------------------------------------
+> -%define libkgetcore %mklibname kgetcore %{%major}
+> +%define libkgetcore %mklibname kgetcore %{major}
+>
+>  %package -n %libkgetcore
+>  Summary:	Runtime library for KGET
+> @@ -135,7 +131,7 @@
+>
+>  %files -n %libkgetcore
+>  %defattr(-,root,root)
+> -%_kde_libdir/libkgetcore.so.%{%major}*
+> +%_kde_libdir/libkgetcore.so.%{major}*
+>
+>  #---------------------------------------------
+>  %package -n kget
+> @@ -159,23 +155,28 @@
+>  %defattr(-,root,root)
+>  %_kde_bindir/kget
+>  %_kde_appsdir/kget
+> +%_kde_applicationsdir/kget.desktop
+>  %_kde_libdir/kde4/krunner_kget.so
+>  %_kde_libdir/kde4/kget_*
+>  %_kde_libdir/kde4/plasma_engine_kget.so
+>  %_kde_libdir/kde4/kcm_kget_checksumsearchfactory.so
+>  %_kde_libdir/kde4/kcm_kget_metalinkfactory.so
+>  %_kde_services/plasma-engine-kget.desktop
+> -%_kde_datadir/applications/kde4/kget.desktop
+>  %_kde_services/ServiceMenus/kget_download.desktop
+>  %_kde_datadir/config.kcfg/kget*
+>  %_kde_services/kget_*
+>  %_kde_datadir/kde4/servicetypes/kget_*
+> +%dir %_kde_appsdir/dolphinpart/kpartplugins/
+>  %_kde_appsdir/dolphinpart/kpartplugins/kget_plug_in.rc
+>  %_kde_appsdir/dolphinpart/kpartplugins/kget_plug_in.desktop
+> +%dir %_kde_appsdir/khtml/kpartplugins/
+
+Dirs must be owned by only one  rpm. Do you think clever to own those
+ones by kdenetwork4 ? i don't think.
+
+I will revert and fix a better way
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006152.html b/zarb-ml/mageia-dev/2011-June/006152.html new file mode 100644 index 000000000..33992ed79 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006152.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] How is the obsoleted binaries be removed? + + + + + + + + + +

[Mageia-dev] How is the obsoleted binaries be removed?

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Jun 30 10:41:26 CEST 2011 +

+
+ +
'Twas brillig, and Funda Wang at 30/06/11 00:11 did gyre and gimble:
+> 2011/6/30 Dexter Morgan <dmorganec at gmail.com>:
+>> On Wed, Jun 29, 2011 at 7:42 PM, Zé <mmodem00 at gmail.com> wrote:
+>>> 2011/6/27 Funda Wang <fundawang at gmail.com>:
+>>>> Hello,
+>>>>
+>>>> How is the obsoleted binaries be removed currently in Mageia? Does the
+>>>> maintainer need to call for this? If yes, please remove
+>>>> lib{,64}devhelp-2_1 from cauldron.
+>>>>
+>>>> Thanks.
+>>>>
+>>> whats current problem?
+>>>
+>>> You can obsolete it through BS, add an entry in the spec about it.
+>>>
+>>
+>> our policy is to not obsolete libs.
+> Then the repository will contain a lot of orphan libs.
+
+I think Dexter was just replying to Ze rather than yourself Funda.
+Meaning we don't obsolete libs in the spec file (as was true in mdv), so
+removing old libs no longer used internally is still a manual
+(rpmctl-type) task.
+
+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-June/006153.html b/zarb-ml/mageia-dev/2011-June/006153.html new file mode 100644 index 000000000..d53ad80bf --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006153.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] How is the obsoleted binaries be removed? + + + + + + + + + +

[Mageia-dev] How is the obsoleted binaries be removed?

+ Michael Scherer + misc at zarb.org +
+ Thu Jun 30 11:08:06 CEST 2011 +

+
+ +
Le jeudi 30 juin 2011 à 09:41 +0100, Colin Guthrie a écrit :
+> 'Twas brillig, and Funda Wang at 30/06/11 00:11 did gyre and gimble:
+> > 2011/6/30 Dexter Morgan <dmorganec at gmail.com>:
+> >> On Wed, Jun 29, 2011 at 7:42 PM, Zé <mmodem00 at gmail.com> wrote:
+> >>> 2011/6/27 Funda Wang <fundawang at gmail.com>:
+> >>>> Hello,
+> >>>>
+> >>>> How is the obsoleted binaries be removed currently in Mageia? Does the
+> >>>> maintainer need to call for this? If yes, please remove
+> >>>> lib{,64}devhelp-2_1 from cauldron.
+> >>>>
+> >>>> Thanks.
+> >>>>
+> >>> whats current problem?
+> >>>
+> >>> You can obsolete it through BS, add an entry in the spec about it.
+> >>>
+> >>
+> >> our policy is to not obsolete libs.
+> > Then the repository will contain a lot of orphan libs.
+> 
+> I think Dexter was just replying to Ze rather than yourself Funda.
+> Meaning we don't obsolete libs in the spec file (as was true in mdv), so
+> removing old libs no longer used internally is still a manual
+> (rpmctl-type) task.
+
+I do not know if I proposed that already, but what about moving rpms
+without source rpms after 2 weeks ( or 1 month ) ?
+
+( and later remove the file after 1 month ). This let us the time to
+rebuild everything, and provides automated cleaning ?
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006154.html b/zarb-ml/mageia-dev/2011-June/006154.html new file mode 100644 index 000000000..71f1f41e4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006154.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] How is the obsoleted binaries be removed? + + + + + + + + + +

[Mageia-dev] How is the obsoleted binaries be removed?

+ Dexter Morgan + dmorganec at gmail.com +
+ Thu Jun 30 11:19:05 CEST 2011 +

+
+ +
On Thu, Jun 30, 2011 at 11:08 AM, Michael Scherer <misc at zarb.org> wrote:
+> Le jeudi 30 juin 2011 à 09:41 +0100, Colin Guthrie a écrit :
+>> 'Twas brillig, and Funda Wang at 30/06/11 00:11 did gyre and gimble:
+>> > 2011/6/30 Dexter Morgan <dmorganec at gmail.com>:
+>> >> On Wed, Jun 29, 2011 at 7:42 PM, Zé <mmodem00 at gmail.com> wrote:
+>> >>> 2011/6/27 Funda Wang <fundawang at gmail.com>:
+>> >>>> Hello,
+>> >>>>
+>> >>>> How is the obsoleted binaries be removed currently in Mageia? Does the
+>> >>>> maintainer need to call for this? If yes, please remove
+>> >>>> lib{,64}devhelp-2_1 from cauldron.
+>> >>>>
+>> >>>> Thanks.
+>> >>>>
+>> >>> whats current problem?
+>> >>>
+>> >>> You can obsolete it through BS, add an entry in the spec about it.
+>> >>>
+>> >>
+>> >> our policy is to not obsolete libs.
+>> > Then the repository will contain a lot of orphan libs.
+>>
+>> I think Dexter was just replying to Ze rather than yourself Funda.
+>> Meaning we don't obsolete libs in the spec file (as was true in mdv), so
+>> removing old libs no longer used internally is still a manual
+>> (rpmctl-type) task.
+>
+> I do not know if I proposed that already, but what about moving rpms
+> without source rpms after 2 weeks ( or 1 month ) ?
+>
+> ( and later remove the file after 1 month ). This let us the time to
+> rebuild everything, and provides automated cleaning ?
+>
+> --
+> Michael Scherer
+>
+>
+
+i agree with this and as they are on old/ we still can revive some if
+needed ( like a rebuild not done, ... )
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006155.html b/zarb-ml/mageia-dev/2011-June/006155.html new file mode 100644 index 000000000..7837e3a19 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006155.html @@ -0,0 +1,74 @@ + + + + [Mageia-dev] [116351] + + + + + + + + + +

[Mageia-dev] [116351]

+ Dexter Morgan + dmorganec at gmail.com +
+ Thu Jun 30 11:32:08 CEST 2011 +

+
+ +
On Thu, Jun 30, 2011 at 11:24 AM,  <root at mageia.org> wrote:
+> Revision 116351 Author ze Date 2011-06-30 11:24:58 +0200 (Thu, 30 Jun 2011)
+>
+> Log Message
+>
+> - set default files attibutes
+
+No this is useless, please remove them
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006156.html b/zarb-ml/mageia-dev/2011-June/006156.html new file mode 100644 index 000000000..3e3ea8d2e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006156.html @@ -0,0 +1,117 @@ + + + + [Mageia-dev] How is the obsoleted binaries be removed? + + + + + + + + + +

[Mageia-dev] How is the obsoleted binaries be removed?

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Jun 30 12:35:28 CEST 2011 +

+
+ +
'Twas brillig, and Michael Scherer at 30/06/11 10:08 did gyre and gimble:
+> Le jeudi 30 juin 2011 à 09:41 +0100, Colin Guthrie a écrit :
+>> 'Twas brillig, and Funda Wang at 30/06/11 00:11 did gyre and gimble:
+>>> 2011/6/30 Dexter Morgan <dmorganec at gmail.com>:
+>>>> On Wed, Jun 29, 2011 at 7:42 PM, Zé <mmodem00 at gmail.com> wrote:
+>>>>> 2011/6/27 Funda Wang <fundawang at gmail.com>:
+>>>>>> Hello,
+>>>>>>
+>>>>>> How is the obsoleted binaries be removed currently in Mageia? Does the
+>>>>>> maintainer need to call for this? If yes, please remove
+>>>>>> lib{,64}devhelp-2_1 from cauldron.
+>>>>>>
+>>>>>> Thanks.
+>>>>>>
+>>>>> whats current problem?
+>>>>>
+>>>>> You can obsolete it through BS, add an entry in the spec about it.
+>>>>>
+>>>>
+>>>> our policy is to not obsolete libs.
+>>> Then the repository will contain a lot of orphan libs.
+>>
+>> I think Dexter was just replying to Ze rather than yourself Funda.
+>> Meaning we don't obsolete libs in the spec file (as was true in mdv), so
+>> removing old libs no longer used internally is still a manual
+>> (rpmctl-type) task.
+> 
+> I do not know if I proposed that already, but what about moving rpms
+> without source rpms after 2 weeks ( or 1 month ) ?
+> 
+> ( and later remove the file after 1 month ). This let us the time to
+> rebuild everything, and provides automated cleaning ?
+
+I agree in principle, but I would say:
+
+ 1. Move rpms with no src.rpm after 2 weeks when there are no
+(unobsoleted) rpms that depend on it.
+ 2. If other rpms do depend on it, send an automated mail to cauldron to
+tell people to rebuild them against the newer lib.
+
+Other than that small caveat... yeah it seems like a nice idea!
+
+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-June/006157.html b/zarb-ml/mageia-dev/2011-June/006157.html new file mode 100644 index 000000000..c15a98778 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006157.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] [RPM] cauldron core/release libkdeedu-4.6.90-4.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release libkdeedu-4.6.90-4.mga2

+ Balcaen John + mikala at mageia.org +
+ Thu Jun 30 12:56:20 CEST 2011 +

+
+ +
On Thursday 30 June 2011 04:45:15 Mageia Team wrote:
+> Name        : libkdeedu                    Relocations: (not relocatable)
+> Version     : 4.6.90                            Vendor: Mageia.Org
+> Release     : 4.mga2                        Build Date: Thu Jun 30 04:40:17
+> 2011 Install Date: (not installed)               Build Host: ecosse
+> Group       : Graphical desktop/KDE         Source RPM: (none)
+> Size        : 204136                           License: GPLv2
+> Signature   : (none)
+> Packager    : Mageia Team <http://www.mageia.org>
+> URL         : http://edu.kde.org
+> Summary     : Free Educational Software based on the KDE technologies
+> Description :
+> Runtime library for KDE Education Application
+> 
+> fwang <fwang> 4.6.90-4.mga2:
+> + Revision: 116239
+> - do not obsolete old packages
+
+I do understand that you don't wont to obsolete kdeedu,but without the 
+obsolete kdeedu-core & kdeedu-devel would have been stick for ever on the 
+mirror until a sysadmin intervention.
+
+-- 
+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-June/006158.html b/zarb-ml/mageia-dev/2011-June/006158.html new file mode 100644 index 000000000..1439e7f56 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006158.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] [RPM] cauldron core/release libkdeedu-4.6.90-4.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release libkdeedu-4.6.90-4.mga2

+ Funda Wang + fundawang at gmail.com +
+ Thu Jun 30 13:01:36 CEST 2011 +

+
+ +
2011/6/30 Balcaen John <mikala at mageia.org>:
+> On Thursday 30 June 2011 04:45:15 Mageia Team wrote:
+>> Name        : libkdeedu                    Relocations: (not relocatable)
+>> Version     : 4.6.90                            Vendor: Mageia.Org
+>> Release     : 4.mga2                        Build Date: Thu Jun 30 04:40:17
+>> 2011 Install Date: (not installed)               Build Host: ecosse
+>> Group       : Graphical desktop/KDE         Source RPM: (none)
+>> Size        : 204136                           License: GPLv2
+>> Signature   : (none)
+>> Packager    : Mageia Team <http://www.mageia.org>
+>> URL         : http://edu.kde.org
+>> Summary     : Free Educational Software based on the KDE technologies
+>> Description :
+>> Runtime library for KDE Education Application
+>>
+>> fwang <fwang> 4.6.90-4.mga2:
+>> + Revision: 116239
+>> - do not obsolete old packages
+>
+> I do understand that you don't wont to obsolete kdeedu,but without the
+> obsolete kdeedu-core & kdeedu-devel would have been stick for ever on the
+> mirror until a sysadmin intervention.
+Agree. But such a task shouldn't be pushed into packaging, and we have
+already push needed conflicts so that it won't affect users.
+
+>
+> --
+> 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-June/006159.html b/zarb-ml/mageia-dev/2011-June/006159.html new file mode 100644 index 000000000..d77c66d87 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006159.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] [RPM] cauldron core/release libkdeedu-4.6.90-4.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release libkdeedu-4.6.90-4.mga2

+ Dexter Morgan + dmorganec at gmail.com +
+ Thu Jun 30 13:11:23 CEST 2011 +

+
+ +
On Thu, Jun 30, 2011 at 1:01 PM, Funda Wang <fundawang at gmail.com> wrote:
+> 2011/6/30 Balcaen John <mikala at mageia.org>:
+>> On Thursday 30 June 2011 04:45:15 Mageia Team wrote:
+>>> Name        : libkdeedu                    Relocations: (not relocatable)
+>>> Version     : 4.6.90                            Vendor: Mageia.Org
+>>> Release     : 4.mga2                        Build Date: Thu Jun 30 04:40:17
+>>> 2011 Install Date: (not installed)               Build Host: ecosse
+>>> Group       : Graphical desktop/KDE         Source RPM: (none)
+>>> Size        : 204136                           License: GPLv2
+>>> Signature   : (none)
+>>> Packager    : Mageia Team <http://www.mageia.org>
+>>> URL         : http://edu.kde.org
+>>> Summary     : Free Educational Software based on the KDE technologies
+>>> Description :
+>>> Runtime library for KDE Education Application
+>>>
+>>> fwang <fwang> 4.6.90-4.mga2:
+>>> + Revision: 116239
+>>> - do not obsolete old packages
+>>
+>> I do understand that you don't wont to obsolete kdeedu,but without the
+>> obsolete kdeedu-core & kdeedu-devel would have been stick for ever on the
+>> mirror until a sysadmin intervention.
+> Agree. But such a task shouldn't be pushed into packaging, and we have
+> already push needed conflicts so that it won't affect users.
+
+
+
+don't forget to tell to your lovely sysadmin team the packages you
+want to be removed ;)
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006160.html b/zarb-ml/mageia-dev/2011-June/006160.html new file mode 100644 index 000000000..5e95a2bae --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006160.html @@ -0,0 +1,71 @@ + + + + [Mageia-dev] updates-announce mailing list + + + + + + + + + +

[Mageia-dev] updates-announce mailing list

+ nicolas vigier + boklm at mars-attacks.org +
+ Thu Jun 30 14:33:12 CEST 2011 +

+
+ +
Hello,
+
+People who want to receive notifications of updates on the stable release
+can subscribe to the updates-announce mailing list :
+https://ml.mageia.org/wwsympa-wrapper.fcgi/info/updates-announce
+
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006161.html b/zarb-ml/mageia-dev/2011-June/006161.html new file mode 100644 index 000000000..7fc79c34e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006161.html @@ -0,0 +1,75 @@ + + + + [Mageia-dev] updates-announce mailing list + + + + + + + + + +

[Mageia-dev] updates-announce mailing list

+ Manuel Hiebel + manuel+ml at hiebel.eu +
+ Thu Jun 30 15:33:04 CEST 2011 +

+
+ +
Le jeudi 30 juin 2011 à 14:33 +0200, nicolas vigier a écrit :
+> Hello,
+> 
+> People who want to receive notifications of updates on the stable release
+> can subscribe to the updates-announce mailing list :
+> https://ml.mageia.org/wwsympa-wrapper.fcgi/info/updates-announce
+> 
+Is there a simple web page planned? like
+http://www.mandriva.com/fr/support/security/advisories/?dis=2010.1
+
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006162.html b/zarb-ml/mageia-dev/2011-June/006162.html new file mode 100644 index 000000000..d73e57ebf --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006162.html @@ -0,0 +1,81 @@ + + + + [Mageia-dev] updates-announce mailing list + + + + + + + + + +

[Mageia-dev] updates-announce mailing list

+ nicolas vigier + boklm at mars-attacks.org +
+ Thu Jun 30 15:38:23 CEST 2011 +

+
+ +
On Thu, 30 Jun 2011, Manuel Hiebel wrote:
+
+> Le jeudi 30 juin 2011 à 14:33 +0200, nicolas vigier a écrit :
+> > Hello,
+> > 
+> > People who want to receive notifications of updates on the stable release
+> > can subscribe to the updates-announce mailing list :
+> > https://ml.mageia.org/wwsympa-wrapper.fcgi/info/updates-announce
+> > 
+> Is there a simple web page planned? like
+> http://www.mandriva.com/fr/support/security/advisories/?dis=2010.1
+
+Yes. It is not done yet, but it is planned.
+
+https://www.mageia.org/pipermail/mageia-dev/2011-June/006092.html
+
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006163.html b/zarb-ml/mageia-dev/2011-June/006163.html new file mode 100644 index 000000000..89455ca6f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006163.html @@ -0,0 +1,205 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ Samuel Verschelde + stormi at laposte.net +
+ Thu Jun 30 15:59:21 CEST 2011 +

+
+ +
+Le vendredi 24 juin 2011 02:15:03, Michael Scherer a écrit :
+> Hi,
+> 
+> The last mail from the backport trilogy. And like all good trilogy,
+> that's where the suspens is present ( as for the 1 and 2 part, you know
+> there is another episode )
+> 
+> This mail is about handling update on the backport repository. Either
+> new version, or bugfix, or security upgrade.
+> 
+> Everybody was focused on "should we do patch, or should we do more
+> backport" issue, but the real problem is not really here.
+> 
+> First, we have to decide what kind of update do we want to see, among
+> the 3 types :
+> - bugfixes
+> - security bug fixes,
+> - new version
+
+As I said in another thread, I think that for backports we can allow ourselves 
+to rely more heavily on the upstream projects than we do for stable updates.
+
+- we try to provide the new upstream stable versions when asked for and 
+conform to the policy
+- we guarantee support for packaging bugs (those are "our" bugs)
+- for bugs :
+-- they are fixed in a new upstream stable version : we provide it.
+-- they are not : we don't fix them. We're providing the latest from upstream, 
+those bugs have to be fixed upstream.
+-- complex cases : fix available upstream but in a development branch and no 
+release soon, or new version non backportable for technical or policy reasons 
+=> we patch
+-- of course nothing prevents diligent packagers from going farther and 
+putting more energy in bug fixing when upstream is failing, but it's not what 
+we promise to do for all backports.
+- security bugs : I see 2 options. The easier for us is to treat them like the 
+other bugs : rely on upstream fixes. Maybe this gives an acceptable level of 
+risk. The other solution is a "full" security process similar to the one we 
+have for stable updates. I would start with the first one and see later if we 
+can switch to the second one.
+
+For comparison, the level of support for stable updates is :
+- we try to bring as little changes to the package as possible, with the ideal 
+situation being not having to issue updates at all,
+- we guarantee support for packaging bugs (those are "our" bugs)
+- for bugs :
+-- they are fixed upstream : we backport patches from upstream newer releases, 
+or provide upstream new stable bugfix-only releases. Occasionnally a non bugfix-
+only new version can be provided, with a sufficient amount of QA and if the new 
+version doesn't change users habits too much.
+-- they are not fixed upstream : we try to fix it ourselves or get patches from 
+other distributions
+- security bugs : fully supported, even more than standard bugs, and without 
+waiting for users to report security bugs.
+
+As we have to explain what the differences in terms of support between updates 
+and backports is, to ourselves but also to users, here is how I would describe 
+it :
+- "updates : report bugs to us first."
+- "backports : ask for a newer stable version if a bug has been fixed there, or 
+report bugs to both the software's developers and us"
+
+
+> 
+> Then as we want to have working backports, I think we need to do test,
+> like we do for normal backports, or updates. This mean someone need to
+> test, besides the packagers.
+> 
+> For the first one, we can assume that if there is a bug, someone will
+> fill it. Then we can assign it to the one that backported to fix the
+> packages, and ask the reporter to test.
+
+Agreed.
+
+> 
+> 
+> For the 3rd one, I guess we can use the same as 1st one. If no one ask,
+> do nothing. If someone ask, do the same as others backports, and erase
+> the previous one.
+
+Agreed.
+
+> 
+> 
+> For the 2nd one, it all depend on how we find out about security issues.
+> A tool like the one used by debian/ubuntu that check for each package if
+> the version is vulnerable or not could help packager to know if a
+> backport requires a fix or not, like this is done for the others
+> packages. 
+
+That could help indeed, such a tool could automatically create a bug report in 
+bugzilla via XML-RPC for example. Useful for stable updates also of course.
+
+> However, this mean that someone will have to check if the bug
+> is fixed, and the question is "who" ( and I do not have a answer that I
+> find good enough yet ). This could even be more tricky if we consider
+> that this can be a version upgrade, and a security fix. Even if we trust
+> the upstream to fix the security issue, we still want to have it
+> working.
+
+That's a good question, given that priority will be given to stable updates 
+testing rather than backports. With a big security team I would say "the 
+security team", but for now I would trust the upstream here.
+
+> 
+> But besides this question, there is a more important problem. If we
+> think that some packages updates are important enough to be sent to user
+> without them asking for explicitly, we cannot let people pick only some
+> packages on demand by disabling backports.
+> 
+> Either backports source is enabled in urpmi, and this would mean that
+> backports are treated like update from a user point of view, or the
+> backports are enabled on demand, meaning that the user is on his own.
+> 
+> Again, I do not have much ideas. A solution would be to have something
+> like portaudit ( http://www.freshports.org/ports-mgmt/portaudit ). So
+> people would be warned if the backport is insecure, or could be upgraded
+> ( even for a new version ). I guess we should however psuh people to run
+> the latest backport, whatever the reason, to avoid headaches when bug
+> are reported.
+> 
+> Another solution would be to patch urpmi to do a special type of update,
+> ie it would only update packages from backports if they come from
+> backports. Not really clean, IMHO.
+
+I don't find this solution that dirty. Let urpmi store a list of package names 
+to be updated from backports. By default it would add every installed backport 
+in it but the user could modify the list at will.
+And if we don't want to modify urpmi's behaviour concerning package update, 
+then we can patch MageiaUpdate.
+
+> 
+> Last solution, declare that cherry picking is not supported, or that
+> people are on their own, and explain the reason. However, people have
+> been asking this, and recommend this. This would also be against a goal
+> of having confidence in the backports.
+
+You already know that would find it a bad solution, given that there other 
+options open to us.
+
+Best regards
+
+Samuel Verschelde
+
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006164.html b/zarb-ml/mageia-dev/2011-June/006164.html new file mode 100644 index 000000000..8bbf76c79 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006164.html @@ -0,0 +1,77 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ Samuel Verschelde + stormi at laposte.net +
+ Thu Jun 30 16:32:00 CEST 2011 +

+
+ +
+Le mardi 28 juin 2011 03:44:24, andre999 a écrit :
+> 
+> 2) Backports would not be removed from repos when a newer backport arrives,
+> except those affected by security updates.
+> This allows reverting to previous backports if a user finds a problem with
+> a backport on their system.
+
+I'd prefer that we don't keep multiple backports versions in the repositories, 
+for the sake of simplicity. Users who ask for the latest must accept that 
+sometimes the latest is not the greatest. Plus, we have the backports_testing 
+repos so that users can test and spot bugs before the old backport is replaced 
+with the new one. 
+
+I want stable : don't use backports.
+I want the latest : use backports.
+I want an intermediate version : no, sorry, your need is too specific. You can 
+still compile it.
+
+Samuel
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006165.html b/zarb-ml/mageia-dev/2011-June/006165.html new file mode 100644 index 000000000..7a92ccfda --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006165.html @@ -0,0 +1,77 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ Samuel Verschelde + stormi at laposte.net +
+ Thu Jun 30 16:34:10 CEST 2011 +

+
+ +
+Le jeudi 30 juin 2011 15:59:21, Samuel Verschelde a écrit :
+> Le vendredi 24 juin 2011 02:15:03, Michael Scherer a écrit :
+> > However, this mean that someone will have to check if the bug
+> > is fixed, and the question is "who" ( and I do not have a answer that I
+> > find good enough yet ). This could even be more tricky if we consider
+> > that this can be a version upgrade, and a security fix. Even if we trust
+> > the upstream to fix the security issue, we still want to have it
+> > working.
+> 
+> That's a good question, given that priority will be given to stable updates
+> testing rather than backports. With a big security team I would say "the
+> security team", but for now I would trust the upstream here.
+
+Or rather, "the packager who backported the software, with the help of the 
+security team and/or QA team if needed".
+
+Samuel
+
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006166.html b/zarb-ml/mageia-dev/2011-June/006166.html new file mode 100644 index 000000000..9fb4794e7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006166.html @@ -0,0 +1,82 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ nicolas vigier + boklm at mars-attacks.org +
+ Thu Jun 30 16:43:40 CEST 2011 +

+
+ +
On Thu, 30 Jun 2011, Samuel Verschelde wrote:
+
+> 
+> Le mardi 28 juin 2011 03:44:24, andre999 a écrit :
+> > 
+> > 2) Backports would not be removed from repos when a newer backport arrives,
+> > except those affected by security updates.
+> > This allows reverting to previous backports if a user finds a problem with
+> > a backport on their system.
+> 
+> I'd prefer that we don't keep multiple backports versions in the repositories, 
+> for the sake of simplicity. Users who ask for the latest must accept that 
+> sometimes the latest is not the greatest. Plus, we have the backports_testing 
+> repos so that users can test and spot bugs before the old backport is replaced 
+> with the new one. 
+> 
+> I want stable : don't use backports.
+> I want the latest : use backports.
+> I want an intermediate version : no, sorry, your need is too specific. You can 
+> still compile it.
+
+I think we can still keep the old versions on the repository. urpmi will
+install the last one, but allow advanced users to use rpm manually to
+install an older version if needed. However I don't think we should make
+updates on older versions.
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006167.html b/zarb-ml/mageia-dev/2011-June/006167.html new file mode 100644 index 000000000..c5e0c672f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006167.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ Olivier + omejean at yahoo.fr +
+ Thu Jun 30 18:58:08 CEST 2011 +

+
+ +
> Le mardi 28 juin 2011 03:44:24, andre999 a écrit :
+> > 2) Backports would not be removed from repos when a newer backport
+> > arrives, except those affected by security updates.
+> > This allows reverting to previous backports if a user finds a problem
+> > with a backport on their system.
+> 
+> I'd prefer that we don't keep multiple backports versions in the
+> repositories, for the sake of simplicity. Users who ask for the latest
+> must accept that sometimes the latest is not the greatest. Plus, we have
+> the backports_testing repos so that users can test and spot bugs before
+> the old backport is replaced with the new one.
+> 
+> I want stable : don't use backports.
+> I want the latest : use backports.
+> I want an intermediate version : no, sorry, your need is too specific. You
+> can still compile it.
+> 
+> Samuel
+Le mardi 28 juin 2011 03:44:24, andre999 a écrit :
+> 
+> 2) Backports would not be removed from repos when a newer backport arrives,
+> except those affected by security updates.
+> This allows reverting to previous backports if a user finds a problem with
+> a backport on their system.
+
+I'd prefer that we don't keep multiple backports versions in the repositories, 
+for the sake of simplicity. Users who ask for the latest must accept that 
+sometimes the latest is not the greatest. Plus, we have the backports_testing 
+repos so that users can test and spot bugs before the old backport is replaced 
+with the new one. 
+
+I want stable : don't use backports.
+I want the latest : use backports.
+I want an intermediate version : no, sorry, your need is too specific. You can 
+still compile it.
+
+Samuel
+
+Well sometimes latest version comes with bug corrections so it may be 
+considered as more stable than the previous version.
+
+Olivier
+
+
+
+ + + +
+

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

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

+ Vincent + vincent.hervieux at gmail.com +
+ Thu Jun 30 22:32:45 CEST 2011 +

+
+ +
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
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110630/544fd436/attachment.html>
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: ZoneMinder-1.24.4-src.patch
+Type: text/x-patch
+Size: 1180 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20110630/544fd436/attachment.bin>
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: ZoneMinder.spec
+Type: text/x-rpm-spec
+Size: 5405 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20110630/544fd436/attachment-0001.bin>
+
+ + + + + + + +
+

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

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

+ magnus + magnus.mud at googlemail.com +
+ Thu Jun 30 22:58:58 CEST 2011 +

+
+ +
2011/6/30 Vincent <vincent.hervieux at gmail.com>
+
+> 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
+>
+> Thanks for your proposal, of course any help on packaging side is welcome.
+Here are some wiki page to read about mentoring process:
+http://mageia.org/wiki/doku.php?id=packaging&s[]=mentor#packagers_organization
+http://mageia.org/wiki/doku.php?id=packaging&s[]=mentor#resources
+http://mageia.org/wiki/doku.php?id=packages_mentoring
+and
+http://mageia.org/wiki/doku.php?id=packager_start
+
+You can apply here on -dev ML looking for a mentor
+
+Also we have weekly meeting on IRC you can attend if you are around
+
+Welcome on board (or in hell as you want)
+
+At the moment we are organizing a mentoring team.
+Please have some patience.
+
+Regards
+
+Magnus
+
+
+> Vincent
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110630/c30d9597/attachment-0001.html>
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006170.html b/zarb-ml/mageia-dev/2011-June/006170.html new file mode 100644 index 000000000..92d4ab0d4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006170.html @@ -0,0 +1,62 @@ + + + + [Mageia-dev] [RFC] Update to Gnome 3.1 + + + + + + + + + +

[Mageia-dev] [RFC] Update to Gnome 3.1

+ Dexter Morgan + dmorganec at gmail.com +
+ Thu Jun 30 23:07:01 CEST 2011 +

+
+ +
Hello,
+
+i would like us to update to gnome 3.1 ( which will give gnome 3.2 ).
+
+Is there someone against ?
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006171.html b/zarb-ml/mageia-dev/2011-June/006171.html new file mode 100644 index 000000000..f3d63c750 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006171.html @@ -0,0 +1,85 @@ + + + + [Mageia-dev] [115962] + + + + + + + + + +

[Mageia-dev] [115962]

+ Zé + mmodem00 at gmail.com +
+ Thu Jun 30 23:09:15 CEST 2011 +

+
+ +
2011/6/29 John Balcaen <mikala at mageia.org>:
+> 2011/6/29  <root at mageia.org>:
+>> Revision 115962 Author ze Date 2011-06-29 15:57:57 +0200 (Wed, 29 Jun 2011)
+>>
+>> Log Message
+>>
+>> - no need to buildrequire and use kde-macros
+>> - use rpm native macros and not variables
+>>
+> [...]
+> We were using kde4-macros especially because attica is maintained &
+> requires by KDE, so it's easier to follow it (like a urpmf --requires
+> kde4-macros Core_Release_SRPMS )
+
+Since attica only needs qt4 theres no need to use kde-macros, thats
+why you also have qt cmake macros like %cmake_qt4
+
+
+> --
+> --
+> Balcaen John
+>
+
+
+
+-- 
+Zé
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006172.html b/zarb-ml/mageia-dev/2011-June/006172.html new file mode 100644 index 000000000..15012f0de --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006172.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] [115561] add versioned requires for common package + + + + + + + + + +

[Mageia-dev] [115561] add versioned requires for common package

+ Zé + mmodem00 at gmail.com +
+ Thu Jun 30 23:13:25 CEST 2011 +

+
+ +
2011/6/29 John Balcaen <mikala at mageia.org>:
+> 2011/6/29  <root at mageia.org>:
+>> Revision 115561 Author fwang Date 2011-06-29 06:48:40 +0200 (Wed, 29 Jun
+> [...]
+>> Modified: cauldron/libkipi/current/SPECS/libkipi.spec
+>> ===================================================================
+>> --- cauldron/libkipi/current/SPECS/libkipi.spec       2011-06-29 04:47:46 UTC (rev
+>> 115560)
+>> +++ cauldron/libkipi/current/SPECS/libkipi.spec       2011-06-29 04:48:40 UTC (rev
+>> 115561)
+>> @@ -39,7 +39,7 @@
+>>  %package -n %{libkipi}
+>>  Summary: libkipi library
+>>  Group: System/Libraries
+>> -Requires: kipi-common
+>> +Requires: kipi-common = %{epoch}:%{version}
+> [...]
+> Should we really have a library requiring an other package ? (via an
+> explicit Requires i mean)
+> (maybe we should move this requires to somewhere else ? )
+>
+
+I remember we did agreed on this, that a lib package having explicite
+requires is not a good idea, but since the require already existed
+there i just set versioning
+
+But as you now know this is being fixed :)
+
+-- 
+Zé
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/006173.html b/zarb-ml/mageia-dev/2011-June/006173.html new file mode 100644 index 000000000..d4213fc0a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006173.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] [115962] + + + + + + + + + +

[Mageia-dev] [115962]

+ Balcaen John + mikala at mageia.org +
+ Thu Jun 30 23:24:08 CEST 2011 +

+
+ +
On Thursday 30 June 2011 22:09:15 Zé wrote:
+> 2011/6/29 John Balcaen <mikala at mageia.org>:
+> > 2011/6/29  <root at mageia.org>:
+> >> Revision 115962 Author ze Date 2011-06-29 15:57:57 +0200 (Wed, 29 Jun
+> >> 2011)
+> >> 
+> >> Log Message
+> >> 
+> >> - no need to buildrequire and use kde-macros
+> >> - use rpm native macros and not variables
+> > 
+> > [...]
+> > We were using kde4-macros especially because attica is maintained &
+> > requires by KDE, so it's easier to follow it (like a urpmf --requires
+> > kde4-macros Core_Release_SRPMS )
+> 
+> Since attica only needs qt4 theres no need to use kde-macros, thats
+> why you also have qt cmake macros like %cmake_qt4
+I know that it's just using qt4 but we're using kde4 macros as convention here 
+following our kde's spec layout.
+
+-- 
+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-June/006174.html b/zarb-ml/mageia-dev/2011-June/006174.html new file mode 100644 index 000000000..99885d5f8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006174.html @@ -0,0 +1,121 @@ + + + + [Mageia-dev] Update of backport, policy proposal + + + + + + + + + +

[Mageia-dev] Update of backport, policy proposal

+ andre999 + andr55 at laposte.net +
+ Thu Jun 30 23:55:42 CEST 2011 +

+
+ +
Samuel Verschelde a écrit :
+>
+> Le mardi 28 juin 2011 03:44:24, andre999 a écrit :
+>>
+>> 2) Backports would not be removed from repos when a newer backport arrives,
+>> except those affected by security updates.
+>> This allows reverting to previous backports if a user finds a problem with
+>> a backport on their system.
+>
+> I'd prefer that we don't keep multiple backports versions in the repositories,
+> for the sake of simplicity. Users who ask for the latest must accept that
+> sometimes the latest is not the greatest. Plus, we have the backports_testing
+> repos so that users can test and spot bugs before the old backport is replaced
+> with the new one.
+>
+> I want stable : don't use backports.
+> I want the latest : use backports.
+> I want an intermediate version : no, sorry, your need is too specific. You can
+> still compile it.
+
+I'm trying to consider the needs of a typical backport user, who needs to revert 
+to a previous version of a backport already installed, due to problems with a 
+newer backport.
+A problem which will often affect only some users installing the particular 
+backport.
+
+They won't activate the backport repository.  So when installing backports, they 
+will only see a list of backports (at least via rpmdrake).
+They are not necessarily familiar with compiling (unlike most of us).
+
+Suppose for a package release A we have issued backports B and C.
+If B causes problems on a particular system, the user reverts to A.
+No problem.
+If a user has installed B, which worked well for them,
+  and subsequently installes C which has problems,
+  they would like to revert to B.
+(Reverting to A could cause a loss of data as well as functionality.)
+
+So why tell the user that they can't revert to a backport version that already 
+worked for them ?
+
+I would suggest a message such as :
+"users installing backports should install the latest version for the package 
+unless they need to revert to a previous version due to problems"
+(To appear only when they have chosen to install backports.)
+
+I realise that this complicates the presentation, and maybe another solution 
+could be found.
+(For example, saving all backports packages installed on a system, so that they 
+can be reinstalled.)
+(A case-by-case analysis of new backports could show which previous backports 
+could be safely removed, for minor changes such as simple bug fixes.)
+
+Or maybe make these backports only visible with urpmi, so that users of the 
+graphic interfaces won't see them.  (As someone else suggested.)
+This would of course require the graphic interfaces to avoid displaying these 
+older backports, but would provide the other advantages of keeping the backports.
+
+Keeping previous backports would facilitate producing security updates for all 
+backports actually installed on various user's systems.
+This adds some complexity for security updates, in exchange for greater security.
+
+> Samuel
+
+-- 
+André
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-June/author.html b/zarb-ml/mageia-dev/2011-June/author.html new file mode 100644 index 000000000..7634e024a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/author.html @@ -0,0 +1,4932 @@ + + + + The Mageia-dev June 2011 Archive by author + + + + + +

June 2011 Archives by author

+ +

Starting: Wed Jun 8 14:10:50 CEST 2011
+ Ending: Thu Jun 30 23:55:42 CEST 2011
+ Messages: 977

+

+

+ Last message date: + Thu Jun 30 23:55:42 CEST 2011
+ Archived on: Thu Jun 30 23:57:20 CEST 2011 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/zarb-ml/mageia-dev/2011-June/date.html b/zarb-ml/mageia-dev/2011-June/date.html new file mode 100644 index 000000000..8bd96a9c6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/date.html @@ -0,0 +1,4932 @@ + + + + The Mageia-dev June 2011 Archive by date + + + + + +

June 2011 Archives by date

+ +

Starting: Wed Jun 8 14:10:50 CEST 2011
+ Ending: Thu Jun 30 23:55:42 CEST 2011
+ Messages: 977

+

+

+ Last message date: + Thu Jun 30 23:55:42 CEST 2011
+ Archived on: Thu Jun 30 23:57:20 CEST 2011 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/zarb-ml/mageia-dev/2011-June/index.html b/zarb-ml/mageia-dev/2011-June/index.html new file mode 120000 index 000000000..db4b46f72 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/zarb-ml/mageia-dev/2011-June/subject.html b/zarb-ml/mageia-dev/2011-June/subject.html new file mode 100644 index 000000000..829561cd3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/subject.html @@ -0,0 +1,4932 @@ + + + + The Mageia-dev June 2011 Archive by subject + + + + + +

June 2011 Archives by subject

+ +

Starting: Wed Jun 8 14:10:50 CEST 2011
+ Ending: Thu Jun 30 23:55:42 CEST 2011
+ Messages: 977

+

+

+ Last message date: + Thu Jun 30 23:55:42 CEST 2011
+ Archived on: Thu Jun 30 23:57:20 CEST 2011 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/zarb-ml/mageia-dev/2011-June/thread.html b/zarb-ml/mageia-dev/2011-June/thread.html new file mode 100644 index 000000000..f0ef2b0f1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/thread.html @@ -0,0 +1,6519 @@ + + + + The Mageia-dev June 2011 Archive by thread + + + + + +

June 2011 Archives by thread

+ +

Starting: Wed Jun 8 14:10:50 CEST 2011
+ Ending: Thu Jun 30 23:55:42 CEST 2011
+ Messages: 977

+

+

+ Last message date: + Thu Jun 30 23:55:42 CEST 2011
+ Archived on: Thu Jun 30 23:57:20 CEST 2011 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + -- cgit v1.2.1