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/2012-January/010849.html | 68 + zarb-ml/mageia-dev/2012-January/010850.html | 94 + zarb-ml/mageia-dev/2012-January/010851.html | 118 + zarb-ml/mageia-dev/2012-January/010852.html | 79 + zarb-ml/mageia-dev/2012-January/010853.html | 72 + zarb-ml/mageia-dev/2012-January/010854.html | 67 + zarb-ml/mageia-dev/2012-January/010855.html | 77 + zarb-ml/mageia-dev/2012-January/010856.html | 69 + zarb-ml/mageia-dev/2012-January/010857.html | 68 + zarb-ml/mageia-dev/2012-January/010858.html | 93 + zarb-ml/mageia-dev/2012-January/010859.html | 75 + zarb-ml/mageia-dev/2012-January/010860.html | 78 + zarb-ml/mageia-dev/2012-January/010861.html | 88 + zarb-ml/mageia-dev/2012-January/010862.html | 67 + zarb-ml/mageia-dev/2012-January/010863.html | 77 + zarb-ml/mageia-dev/2012-January/010864.html | 76 + zarb-ml/mageia-dev/2012-January/010865.html | 79 + zarb-ml/mageia-dev/2012-January/010866.html | 95 + zarb-ml/mageia-dev/2012-January/010867.html | 77 + zarb-ml/mageia-dev/2012-January/010868.html | 78 + zarb-ml/mageia-dev/2012-January/010869.html | 78 + zarb-ml/mageia-dev/2012-January/010870.html | 72 + zarb-ml/mageia-dev/2012-January/010871.html | 77 + zarb-ml/mageia-dev/2012-January/010872.html | 71 + zarb-ml/mageia-dev/2012-January/010873.html | 90 + zarb-ml/mageia-dev/2012-January/010874.html | 86 + zarb-ml/mageia-dev/2012-January/010875.html | 100 + zarb-ml/mageia-dev/2012-January/010876.html | 61 + zarb-ml/mageia-dev/2012-January/010877.html | 72 + zarb-ml/mageia-dev/2012-January/010878.html | 68 + zarb-ml/mageia-dev/2012-January/010879.html | 77 + zarb-ml/mageia-dev/2012-January/010880.html | 76 + zarb-ml/mageia-dev/2012-January/010881.html | 105 + zarb-ml/mageia-dev/2012-January/010882.html | 101 + zarb-ml/mageia-dev/2012-January/010883.html | 101 + zarb-ml/mageia-dev/2012-January/010884.html | 106 + zarb-ml/mageia-dev/2012-January/010885.html | 144 + zarb-ml/mageia-dev/2012-January/010886.html | 114 + zarb-ml/mageia-dev/2012-January/010887.html | 69 + zarb-ml/mageia-dev/2012-January/010888.html | 93 + zarb-ml/mageia-dev/2012-January/010889.html | 102 + zarb-ml/mageia-dev/2012-January/010890.html | 133 + zarb-ml/mageia-dev/2012-January/010891.html | 124 + zarb-ml/mageia-dev/2012-January/010892.html | 228 ++ zarb-ml/mageia-dev/2012-January/010893.html | 91 + zarb-ml/mageia-dev/2012-January/010894.html | 114 + zarb-ml/mageia-dev/2012-January/010895.html | 110 + zarb-ml/mageia-dev/2012-January/010896.html | 101 + zarb-ml/mageia-dev/2012-January/010897.html | 117 + zarb-ml/mageia-dev/2012-January/010898.html | 109 + zarb-ml/mageia-dev/2012-January/010899.html | 87 + zarb-ml/mageia-dev/2012-January/010900.html | 96 + zarb-ml/mageia-dev/2012-January/010901.html | 90 + zarb-ml/mageia-dev/2012-January/010902.html | 92 + zarb-ml/mageia-dev/2012-January/010903.html | 93 + zarb-ml/mageia-dev/2012-January/010904.html | 148 + zarb-ml/mageia-dev/2012-January/010905.html | 120 + zarb-ml/mageia-dev/2012-January/010906.html | 101 + zarb-ml/mageia-dev/2012-January/010907.html | 131 + zarb-ml/mageia-dev/2012-January/010908.html | 104 + zarb-ml/mageia-dev/2012-January/010909.html | 112 + zarb-ml/mageia-dev/2012-January/010910.html | 113 + zarb-ml/mageia-dev/2012-January/010911.html | 134 + zarb-ml/mageia-dev/2012-January/010912.html | 143 + zarb-ml/mageia-dev/2012-January/010913.html | 132 + zarb-ml/mageia-dev/2012-January/010914.html | 96 + zarb-ml/mageia-dev/2012-January/010915.html | 126 + zarb-ml/mageia-dev/2012-January/010916.html | 86 + zarb-ml/mageia-dev/2012-January/010917.html | 90 + zarb-ml/mageia-dev/2012-January/010918.html | 124 + zarb-ml/mageia-dev/2012-January/010919.html | 76 + zarb-ml/mageia-dev/2012-January/010920.html | 86 + zarb-ml/mageia-dev/2012-January/010921.html | 83 + zarb-ml/mageia-dev/2012-January/010922.html | 103 + zarb-ml/mageia-dev/2012-January/010923.html | 120 + zarb-ml/mageia-dev/2012-January/010924.html | 112 + zarb-ml/mageia-dev/2012-January/010925.html | 122 + zarb-ml/mageia-dev/2012-January/010926.html | 112 + zarb-ml/mageia-dev/2012-January/010927.html | 119 + zarb-ml/mageia-dev/2012-January/010928.html | 68 + zarb-ml/mageia-dev/2012-January/010929.html | 119 + zarb-ml/mageia-dev/2012-January/010930.html | 124 + zarb-ml/mageia-dev/2012-January/010931.html | 119 + zarb-ml/mageia-dev/2012-January/010932.html | 144 + zarb-ml/mageia-dev/2012-January/010933.html | 122 + zarb-ml/mageia-dev/2012-January/010934.html | 119 + zarb-ml/mageia-dev/2012-January/010935.html | 124 + zarb-ml/mageia-dev/2012-January/010936.html | 129 + zarb-ml/mageia-dev/2012-January/010937.html | 119 + zarb-ml/mageia-dev/2012-January/010938.html | 110 + zarb-ml/mageia-dev/2012-January/010939.html | 102 + zarb-ml/mageia-dev/2012-January/010940.html | 109 + zarb-ml/mageia-dev/2012-January/010941.html | 85 + zarb-ml/mageia-dev/2012-January/010942.html | 121 + zarb-ml/mageia-dev/2012-January/010943.html | 98 + zarb-ml/mageia-dev/2012-January/010944.html | 99 + zarb-ml/mageia-dev/2012-January/010945.html | 121 + zarb-ml/mageia-dev/2012-January/010946.html | 130 + zarb-ml/mageia-dev/2012-January/010947.html | 95 + zarb-ml/mageia-dev/2012-January/010948.html | 86 + zarb-ml/mageia-dev/2012-January/010949.html | 148 + zarb-ml/mageia-dev/2012-January/010950.html | 168 + zarb-ml/mageia-dev/2012-January/010951.html | 107 + zarb-ml/mageia-dev/2012-January/010952.html | 107 + zarb-ml/mageia-dev/2012-January/010953.html | 120 + zarb-ml/mageia-dev/2012-January/010954.html | 137 + zarb-ml/mageia-dev/2012-January/010955.html | 90 + zarb-ml/mageia-dev/2012-January/010956.html | 156 + zarb-ml/mageia-dev/2012-January/010957.html | 117 + zarb-ml/mageia-dev/2012-January/010958.html | 131 + zarb-ml/mageia-dev/2012-January/010959.html | 116 + zarb-ml/mageia-dev/2012-January/010960.html | 137 + zarb-ml/mageia-dev/2012-January/010961.html | 110 + zarb-ml/mageia-dev/2012-January/010962.html | 123 + zarb-ml/mageia-dev/2012-January/010963.html | 122 + zarb-ml/mageia-dev/2012-January/010964.html | 118 + zarb-ml/mageia-dev/2012-January/010965.html | 145 + zarb-ml/mageia-dev/2012-January/010966.html | 107 + zarb-ml/mageia-dev/2012-January/010967.html | 102 + zarb-ml/mageia-dev/2012-January/010968.html | 111 + zarb-ml/mageia-dev/2012-January/010969.html | 129 + zarb-ml/mageia-dev/2012-January/010970.html | 211 + zarb-ml/mageia-dev/2012-January/010971.html | 245 ++ zarb-ml/mageia-dev/2012-January/010972.html | 125 + zarb-ml/mageia-dev/2012-January/010973.html | 104 + zarb-ml/mageia-dev/2012-January/010974.html | 117 + zarb-ml/mageia-dev/2012-January/010975.html | 107 + zarb-ml/mageia-dev/2012-January/010976.html | 114 + zarb-ml/mageia-dev/2012-January/010977.html | 120 + zarb-ml/mageia-dev/2012-January/010978.html | 106 + zarb-ml/mageia-dev/2012-January/010979.html | 97 + zarb-ml/mageia-dev/2012-January/010980.html | 147 + zarb-ml/mageia-dev/2012-January/010981.html | 118 + zarb-ml/mageia-dev/2012-January/010982.html | 91 + zarb-ml/mageia-dev/2012-January/010983.html | 175 + zarb-ml/mageia-dev/2012-January/010984.html | 112 + zarb-ml/mageia-dev/2012-January/010985.html | 104 + zarb-ml/mageia-dev/2012-January/010986.html | 126 + zarb-ml/mageia-dev/2012-January/010987.html | 104 + zarb-ml/mageia-dev/2012-January/010988.html | 105 + zarb-ml/mageia-dev/2012-January/010989.html | 160 + zarb-ml/mageia-dev/2012-January/010990.html | 141 + zarb-ml/mageia-dev/2012-January/010991.html | 189 + zarb-ml/mageia-dev/2012-January/010992.html | 137 + zarb-ml/mageia-dev/2012-January/010993.html | 111 + zarb-ml/mageia-dev/2012-January/010994.html | 97 + zarb-ml/mageia-dev/2012-January/010995.html | 321 ++ zarb-ml/mageia-dev/2012-January/010996.html | 90 + zarb-ml/mageia-dev/2012-January/010997.html | 111 + zarb-ml/mageia-dev/2012-January/010998.html | 118 + zarb-ml/mageia-dev/2012-January/010999.html | 95 + zarb-ml/mageia-dev/2012-January/011000.html | 96 + zarb-ml/mageia-dev/2012-January/011001.html | 127 + zarb-ml/mageia-dev/2012-January/011002.html | 119 + zarb-ml/mageia-dev/2012-January/011003.html | 115 + zarb-ml/mageia-dev/2012-January/011004.html | 132 + zarb-ml/mageia-dev/2012-January/011005.html | 138 + zarb-ml/mageia-dev/2012-January/011006.html | 94 + zarb-ml/mageia-dev/2012-January/011007.html | 96 + zarb-ml/mageia-dev/2012-January/011008.html | 101 + zarb-ml/mageia-dev/2012-January/011009.html | 90 + zarb-ml/mageia-dev/2012-January/011010.html | 88 + zarb-ml/mageia-dev/2012-January/011011.html | 458 +++ zarb-ml/mageia-dev/2012-January/011012.html | 213 + zarb-ml/mageia-dev/2012-January/011013.html | 89 + zarb-ml/mageia-dev/2012-January/011014.html | 166 + zarb-ml/mageia-dev/2012-January/011015.html | 113 + zarb-ml/mageia-dev/2012-January/011016.html | 188 + zarb-ml/mageia-dev/2012-January/011017.html | 169 + zarb-ml/mageia-dev/2012-January/011018.html | 177 + zarb-ml/mageia-dev/2012-January/011019.html | 112 + zarb-ml/mageia-dev/2012-January/011020.html | 97 + zarb-ml/mageia-dev/2012-January/011021.html | 127 + zarb-ml/mageia-dev/2012-January/011022.html | 120 + zarb-ml/mageia-dev/2012-January/011023.html | 117 + zarb-ml/mageia-dev/2012-January/011024.html | 97 + zarb-ml/mageia-dev/2012-January/011025.html | 104 + zarb-ml/mageia-dev/2012-January/011026.html | 111 + zarb-ml/mageia-dev/2012-January/011027.html | 110 + zarb-ml/mageia-dev/2012-January/011028.html | 154 + zarb-ml/mageia-dev/2012-January/011029.html | 217 + zarb-ml/mageia-dev/2012-January/011030.html | 277 ++ zarb-ml/mageia-dev/2012-January/011031.html | 157 + zarb-ml/mageia-dev/2012-January/011032.html | 101 + zarb-ml/mageia-dev/2012-January/011033.html | 131 + zarb-ml/mageia-dev/2012-January/011034.html | 135 + zarb-ml/mageia-dev/2012-January/011035.html | 109 + zarb-ml/mageia-dev/2012-January/011036.html | 127 + zarb-ml/mageia-dev/2012-January/011037.html | 108 + zarb-ml/mageia-dev/2012-January/011038.html | 142 + zarb-ml/mageia-dev/2012-January/011039.html | 91 + zarb-ml/mageia-dev/2012-January/011040.html | 96 + zarb-ml/mageia-dev/2012-January/011041.html | 123 + zarb-ml/mageia-dev/2012-January/011042.html | 155 + zarb-ml/mageia-dev/2012-January/011043.html | 181 + zarb-ml/mageia-dev/2012-January/011044.html | 134 + zarb-ml/mageia-dev/2012-January/011045.html | 152 + zarb-ml/mageia-dev/2012-January/011046.html | 98 + zarb-ml/mageia-dev/2012-January/011047.html | 126 + zarb-ml/mageia-dev/2012-January/011048.html | 134 + zarb-ml/mageia-dev/2012-January/011049.html | 121 + zarb-ml/mageia-dev/2012-January/011050.html | 83 + zarb-ml/mageia-dev/2012-January/011051.html | 87 + zarb-ml/mageia-dev/2012-January/011052.html | 140 + zarb-ml/mageia-dev/2012-January/011053.html | 138 + zarb-ml/mageia-dev/2012-January/011054.html | 140 + zarb-ml/mageia-dev/2012-January/011055.html | 119 + zarb-ml/mageia-dev/2012-January/011056.html | 126 + zarb-ml/mageia-dev/2012-January/011057.html | 188 + zarb-ml/mageia-dev/2012-January/011058.html | 118 + zarb-ml/mageia-dev/2012-January/011059.html | 118 + zarb-ml/mageia-dev/2012-January/011060.html | 103 + zarb-ml/mageia-dev/2012-January/011061.html | 106 + zarb-ml/mageia-dev/2012-January/011062.html | 109 + zarb-ml/mageia-dev/2012-January/011063.html | 105 + zarb-ml/mageia-dev/2012-January/011064.html | 113 + zarb-ml/mageia-dev/2012-January/011065.html | 120 + zarb-ml/mageia-dev/2012-January/011066.html | 100 + zarb-ml/mageia-dev/2012-January/011067.html | 134 + zarb-ml/mageia-dev/2012-January/011068.html | 146 + zarb-ml/mageia-dev/2012-January/011069.html | 156 + zarb-ml/mageia-dev/2012-January/011070.html | 114 + zarb-ml/mageia-dev/2012-January/011071.html | 146 + zarb-ml/mageia-dev/2012-January/011072.html | 102 + zarb-ml/mageia-dev/2012-January/011073.html | 119 + zarb-ml/mageia-dev/2012-January/011074.html | 86 + zarb-ml/mageia-dev/2012-January/011075.html | 97 + zarb-ml/mageia-dev/2012-January/011076.html | 100 + zarb-ml/mageia-dev/2012-January/011077.html | 142 + zarb-ml/mageia-dev/2012-January/011078.html | 121 + zarb-ml/mageia-dev/2012-January/011079.html | 112 + zarb-ml/mageia-dev/2012-January/011080.html | 132 + zarb-ml/mageia-dev/2012-January/011081.html | 116 + zarb-ml/mageia-dev/2012-January/011082.html | 126 + zarb-ml/mageia-dev/2012-January/011083.html | 125 + zarb-ml/mageia-dev/2012-January/011084.html | 106 + zarb-ml/mageia-dev/2012-January/011085.html | 132 + zarb-ml/mageia-dev/2012-January/011086.html | 128 + zarb-ml/mageia-dev/2012-January/011087.html | 84 + zarb-ml/mageia-dev/2012-January/011088.html | 113 + zarb-ml/mageia-dev/2012-January/011089.html | 98 + zarb-ml/mageia-dev/2012-January/011090.html | 99 + zarb-ml/mageia-dev/2012-January/011091.html | 109 + zarb-ml/mageia-dev/2012-January/011092.html | 226 + zarb-ml/mageia-dev/2012-January/011093.html | 82 + zarb-ml/mageia-dev/2012-January/011094.html | 91 + zarb-ml/mageia-dev/2012-January/011095.html | 105 + zarb-ml/mageia-dev/2012-January/011096.html | 100 + zarb-ml/mageia-dev/2012-January/011097.html | 108 + zarb-ml/mageia-dev/2012-January/011098.html | 143 + zarb-ml/mageia-dev/2012-January/011099.html | 104 + zarb-ml/mageia-dev/2012-January/011100.html | 110 + zarb-ml/mageia-dev/2012-January/011101.html | 80 + zarb-ml/mageia-dev/2012-January/011102.html | 143 + zarb-ml/mageia-dev/2012-January/011103.html | 101 + zarb-ml/mageia-dev/2012-January/011104.html | 104 + zarb-ml/mageia-dev/2012-January/011105.html | 94 + zarb-ml/mageia-dev/2012-January/011106.html | 95 + zarb-ml/mageia-dev/2012-January/011107.html | 104 + zarb-ml/mageia-dev/2012-January/011108.html | 98 + zarb-ml/mageia-dev/2012-January/011109.html | 144 + zarb-ml/mageia-dev/2012-January/011110.html | 110 + zarb-ml/mageia-dev/2012-January/011111.html | 101 + zarb-ml/mageia-dev/2012-January/011112.html | 111 + zarb-ml/mageia-dev/2012-January/011113.html | 197 + zarb-ml/mageia-dev/2012-January/011114.html | 103 + zarb-ml/mageia-dev/2012-January/011115.html | 123 + zarb-ml/mageia-dev/2012-January/011116.html | 110 + zarb-ml/mageia-dev/2012-January/011117.html | 113 + zarb-ml/mageia-dev/2012-January/011118.html | 90 + zarb-ml/mageia-dev/2012-January/011119.html | 96 + zarb-ml/mageia-dev/2012-January/011120.html | 107 + zarb-ml/mageia-dev/2012-January/011121.html | 126 + zarb-ml/mageia-dev/2012-January/011122.html | 116 + zarb-ml/mageia-dev/2012-January/011123.html | 93 + zarb-ml/mageia-dev/2012-January/011124.html | 99 + zarb-ml/mageia-dev/2012-January/011125.html | 120 + zarb-ml/mageia-dev/2012-January/011126.html | 119 + zarb-ml/mageia-dev/2012-January/011127.html | 203 + zarb-ml/mageia-dev/2012-January/011128.html | 119 + zarb-ml/mageia-dev/2012-January/011129.html | 195 + zarb-ml/mageia-dev/2012-January/011130.html | 126 + zarb-ml/mageia-dev/2012-January/011131.html | 133 + zarb-ml/mageia-dev/2012-January/011132.html | 114 + zarb-ml/mageia-dev/2012-January/011133.html | 80 + zarb-ml/mageia-dev/2012-January/011134.html | 101 + zarb-ml/mageia-dev/2012-January/011135.html | 105 + zarb-ml/mageia-dev/2012-January/011136.html | 102 + zarb-ml/mageia-dev/2012-January/011137.html | 120 + zarb-ml/mageia-dev/2012-January/011138.html | 128 + zarb-ml/mageia-dev/2012-January/011139.html | 131 + zarb-ml/mageia-dev/2012-January/011140.html | 116 + zarb-ml/mageia-dev/2012-January/011141.html | 122 + zarb-ml/mageia-dev/2012-January/011142.html | 157 + zarb-ml/mageia-dev/2012-January/011143.html | 123 + zarb-ml/mageia-dev/2012-January/011144.html | 219 + zarb-ml/mageia-dev/2012-January/011145.html | 228 ++ zarb-ml/mageia-dev/2012-January/011146.html | 73 + zarb-ml/mageia-dev/2012-January/011147.html | 168 + zarb-ml/mageia-dev/2012-January/011148.html | 182 + zarb-ml/mageia-dev/2012-January/011149.html | 179 + zarb-ml/mageia-dev/2012-January/011150.html | 194 + zarb-ml/mageia-dev/2012-January/011151.html | 180 + zarb-ml/mageia-dev/2012-January/011152.html | 192 + zarb-ml/mageia-dev/2012-January/011153.html | 177 + zarb-ml/mageia-dev/2012-January/011154.html | 201 + zarb-ml/mageia-dev/2012-January/011155.html | 167 + zarb-ml/mageia-dev/2012-January/011156.html | 175 + zarb-ml/mageia-dev/2012-January/011157.html | 183 + zarb-ml/mageia-dev/2012-January/011158.html | 174 + zarb-ml/mageia-dev/2012-January/011159.html | 119 + zarb-ml/mageia-dev/2012-January/011160.html | 86 + zarb-ml/mageia-dev/2012-January/011161.html | 91 + zarb-ml/mageia-dev/2012-January/011162.html | 128 + zarb-ml/mageia-dev/2012-January/011163.html | 168 + zarb-ml/mageia-dev/2012-January/011164.html | 192 + zarb-ml/mageia-dev/2012-January/011165.html | 122 + zarb-ml/mageia-dev/2012-January/011166.html | 136 + zarb-ml/mageia-dev/2012-January/011167.html | 88 + zarb-ml/mageia-dev/2012-January/011168.html | 155 + zarb-ml/mageia-dev/2012-January/011169.html | 163 + zarb-ml/mageia-dev/2012-January/011170.html | 166 + zarb-ml/mageia-dev/2012-January/011171.html | 171 + zarb-ml/mageia-dev/2012-January/011172.html | 104 + zarb-ml/mageia-dev/2012-January/011173.html | 161 + zarb-ml/mageia-dev/2012-January/011174.html | 121 + zarb-ml/mageia-dev/2012-January/011175.html | 186 + zarb-ml/mageia-dev/2012-January/011176.html | 178 + zarb-ml/mageia-dev/2012-January/011177.html | 166 + zarb-ml/mageia-dev/2012-January/011178.html | 168 + zarb-ml/mageia-dev/2012-January/011179.html | 174 + zarb-ml/mageia-dev/2012-January/011180.html | 105 + zarb-ml/mageia-dev/2012-January/011181.html | 236 ++ zarb-ml/mageia-dev/2012-January/011182.html | 175 + zarb-ml/mageia-dev/2012-January/011183.html | 157 + zarb-ml/mageia-dev/2012-January/011184.html | 188 + zarb-ml/mageia-dev/2012-January/011185.html | 257 ++ zarb-ml/mageia-dev/2012-January/011186.html | 171 + zarb-ml/mageia-dev/2012-January/011187.html | 173 + zarb-ml/mageia-dev/2012-January/011188.html | 180 + zarb-ml/mageia-dev/2012-January/011189.html | 172 + zarb-ml/mageia-dev/2012-January/011190.html | 160 + zarb-ml/mageia-dev/2012-January/011191.html | 197 + zarb-ml/mageia-dev/2012-January/011192.html | 97 + zarb-ml/mageia-dev/2012-January/011193.html | 208 + zarb-ml/mageia-dev/2012-January/011194.html | 175 + zarb-ml/mageia-dev/2012-January/011195.html | 232 ++ zarb-ml/mageia-dev/2012-January/011196.html | 210 + zarb-ml/mageia-dev/2012-January/011197.html | 264 ++ zarb-ml/mageia-dev/2012-January/011198.html | 187 + zarb-ml/mageia-dev/2012-January/011199.html | 165 + zarb-ml/mageia-dev/2012-January/011200.html | 155 + zarb-ml/mageia-dev/2012-January/011201.html | 306 ++ zarb-ml/mageia-dev/2012-January/011202.html | 207 + zarb-ml/mageia-dev/2012-January/011203.html | 184 + zarb-ml/mageia-dev/2012-January/011204.html | 165 + zarb-ml/mageia-dev/2012-January/011205.html | 87 + zarb-ml/mageia-dev/2012-January/011206.html | 119 + zarb-ml/mageia-dev/2012-January/011207.html | 88 + zarb-ml/mageia-dev/2012-January/011208.html | 172 + zarb-ml/mageia-dev/2012-January/011209.html | 176 + zarb-ml/mageia-dev/2012-January/011210.html | 161 + zarb-ml/mageia-dev/2012-January/011211.html | 151 + zarb-ml/mageia-dev/2012-January/011212.html | 166 + zarb-ml/mageia-dev/2012-January/011213.html | 194 + zarb-ml/mageia-dev/2012-January/011214.html | 164 + zarb-ml/mageia-dev/2012-January/011215.html | 170 + zarb-ml/mageia-dev/2012-January/011216.html | 162 + zarb-ml/mageia-dev/2012-January/011217.html | 131 + zarb-ml/mageia-dev/2012-January/011218.html | 98 + zarb-ml/mageia-dev/2012-January/011219.html | 153 + zarb-ml/mageia-dev/2012-January/011220.html | 168 + zarb-ml/mageia-dev/2012-January/011221.html | 103 + zarb-ml/mageia-dev/2012-January/011222.html | 161 + zarb-ml/mageia-dev/2012-January/011223.html | 124 + zarb-ml/mageia-dev/2012-January/011224.html | 108 + zarb-ml/mageia-dev/2012-January/011225.html | 183 + zarb-ml/mageia-dev/2012-January/011226.html | 155 + zarb-ml/mageia-dev/2012-January/011227.html | 74 + zarb-ml/mageia-dev/2012-January/011228.html | 236 ++ zarb-ml/mageia-dev/2012-January/011229.html | 172 + zarb-ml/mageia-dev/2012-January/011230.html | 156 + zarb-ml/mageia-dev/2012-January/011231.html | 181 + zarb-ml/mageia-dev/2012-January/011232.html | 146 + zarb-ml/mageia-dev/2012-January/011233.html | 156 + zarb-ml/mageia-dev/2012-January/011234.html | 106 + zarb-ml/mageia-dev/2012-January/011235.html | 104 + zarb-ml/mageia-dev/2012-January/011236.html | 98 + zarb-ml/mageia-dev/2012-January/011237.html | 97 + zarb-ml/mageia-dev/2012-January/011238.html | 113 + zarb-ml/mageia-dev/2012-January/011239.html | 136 + zarb-ml/mageia-dev/2012-January/011240.html | 144 + zarb-ml/mageia-dev/2012-January/011241.html | 127 + zarb-ml/mageia-dev/2012-January/011242.html | 103 + zarb-ml/mageia-dev/2012-January/011243.html | 104 + zarb-ml/mageia-dev/2012-January/011244.html | 135 + zarb-ml/mageia-dev/2012-January/011245.html | 108 + zarb-ml/mageia-dev/2012-January/011246.html | 218 + zarb-ml/mageia-dev/2012-January/011247.html | 107 + zarb-ml/mageia-dev/2012-January/011248.html | 106 + zarb-ml/mageia-dev/2012-January/011249.html | 100 + zarb-ml/mageia-dev/2012-January/011250.html | 150 + zarb-ml/mageia-dev/2012-January/011251.html | 97 + zarb-ml/mageia-dev/2012-January/011252.html | 94 + zarb-ml/mageia-dev/2012-January/011253.html | 153 + zarb-ml/mageia-dev/2012-January/011254.html | 87 + zarb-ml/mageia-dev/2012-January/011255.html | 83 + zarb-ml/mageia-dev/2012-January/011256.html | 97 + zarb-ml/mageia-dev/2012-January/011257.html | 67 + zarb-ml/mageia-dev/2012-January/011258.html | 126 + zarb-ml/mageia-dev/2012-January/011259.html | 95 + zarb-ml/mageia-dev/2012-January/011260.html | 234 ++ zarb-ml/mageia-dev/2012-January/011261.html | 88 + zarb-ml/mageia-dev/2012-January/011262.html | 79 + zarb-ml/mageia-dev/2012-January/011263.html | 135 + zarb-ml/mageia-dev/2012-January/011264.html | 66 + zarb-ml/mageia-dev/2012-January/011265.html | 107 + zarb-ml/mageia-dev/2012-January/011266.html | 131 + zarb-ml/mageia-dev/2012-January/011267.html | 120 + zarb-ml/mageia-dev/2012-January/011268.html | 117 + zarb-ml/mageia-dev/2012-January/011269.html | 119 + zarb-ml/mageia-dev/2012-January/011270.html | 79 + zarb-ml/mageia-dev/2012-January/011271.html | 112 + zarb-ml/mageia-dev/2012-January/011272.html | 82 + zarb-ml/mageia-dev/2012-January/011273.html | 118 + zarb-ml/mageia-dev/2012-January/011274.html | 148 + zarb-ml/mageia-dev/2012-January/011275.html | 127 + zarb-ml/mageia-dev/2012-January/011276.html | 150 + zarb-ml/mageia-dev/2012-January/011277.html | 93 + zarb-ml/mageia-dev/2012-January/011278.html | 126 + zarb-ml/mageia-dev/2012-January/011279.html | 162 + zarb-ml/mageia-dev/2012-January/011280.html | 158 + zarb-ml/mageia-dev/2012-January/011281.html | 192 + zarb-ml/mageia-dev/2012-January/011282.html | 110 + zarb-ml/mageia-dev/2012-January/011283.html | 132 + zarb-ml/mageia-dev/2012-January/011284.html | 129 + zarb-ml/mageia-dev/2012-January/011285.html | 68 + zarb-ml/mageia-dev/2012-January/011286.html | 111 + zarb-ml/mageia-dev/2012-January/011287.html | 157 + zarb-ml/mageia-dev/2012-January/011288.html | 100 + zarb-ml/mageia-dev/2012-January/011289.html | 82 + zarb-ml/mageia-dev/2012-January/011290.html | 126 + zarb-ml/mageia-dev/2012-January/011291.html | 108 + zarb-ml/mageia-dev/2012-January/011292.html | 97 + zarb-ml/mageia-dev/2012-January/011293.html | 109 + zarb-ml/mageia-dev/2012-January/011294.html | 106 + zarb-ml/mageia-dev/2012-January/011295.html | 77 + zarb-ml/mageia-dev/2012-January/011296.html | 141 + zarb-ml/mageia-dev/2012-January/011297.html | 109 + zarb-ml/mageia-dev/2012-January/011298.html | 98 + zarb-ml/mageia-dev/2012-January/011299.html | 161 + zarb-ml/mageia-dev/2012-January/011300.html | 124 + zarb-ml/mageia-dev/2012-January/011301.html | 100 + zarb-ml/mageia-dev/2012-January/011302.html | 77 + zarb-ml/mageia-dev/2012-January/011303.html | 89 + zarb-ml/mageia-dev/2012-January/011304.html | 109 + zarb-ml/mageia-dev/2012-January/011305.html | 72 + zarb-ml/mageia-dev/2012-January/011306.html | 104 + zarb-ml/mageia-dev/2012-January/011307.html | 100 + zarb-ml/mageia-dev/2012-January/011308.html | 80 + zarb-ml/mageia-dev/2012-January/011309.html | 73 + zarb-ml/mageia-dev/2012-January/011310.html | 87 + zarb-ml/mageia-dev/2012-January/011311.html | 105 + zarb-ml/mageia-dev/2012-January/011312.html | 77 + zarb-ml/mageia-dev/2012-January/011313.html | 99 + zarb-ml/mageia-dev/2012-January/011314.html | 81 + zarb-ml/mageia-dev/2012-January/011315.html | 111 + zarb-ml/mageia-dev/2012-January/011316.html | 108 + zarb-ml/mageia-dev/2012-January/011317.html | 113 + zarb-ml/mageia-dev/2012-January/011318.html | 127 + zarb-ml/mageia-dev/2012-January/011319.html | 76 + zarb-ml/mageia-dev/2012-January/011320.html | 131 + zarb-ml/mageia-dev/2012-January/011321.html | 102 + zarb-ml/mageia-dev/2012-January/011322.html | 116 + zarb-ml/mageia-dev/2012-January/011323.html | 139 + zarb-ml/mageia-dev/2012-January/011324.html | 125 + zarb-ml/mageia-dev/2012-January/011325.html | 115 + zarb-ml/mageia-dev/2012-January/011326.html | 79 + zarb-ml/mageia-dev/2012-January/011327.html | 78 + zarb-ml/mageia-dev/2012-January/011328.html | 109 + zarb-ml/mageia-dev/2012-January/011329.html | 135 + zarb-ml/mageia-dev/2012-January/011330.html | 162 + zarb-ml/mageia-dev/2012-January/011331.html | 164 + zarb-ml/mageia-dev/2012-January/011332.html | 107 + zarb-ml/mageia-dev/2012-January/011333.html | 126 + zarb-ml/mageia-dev/2012-January/011334.html | 178 + zarb-ml/mageia-dev/2012-January/011335.html | 206 + zarb-ml/mageia-dev/2012-January/011336.html | 135 + zarb-ml/mageia-dev/2012-January/011337.html | 147 + zarb-ml/mageia-dev/2012-January/011338.html | 125 + zarb-ml/mageia-dev/2012-January/011339.html | 217 + zarb-ml/mageia-dev/2012-January/011340.html | 103 + zarb-ml/mageia-dev/2012-January/011341.html | 91 + zarb-ml/mageia-dev/2012-January/011342.html | 83 + zarb-ml/mageia-dev/2012-January/011343.html | 104 + zarb-ml/mageia-dev/2012-January/011344.html | 93 + zarb-ml/mageia-dev/2012-January/011345.html | 101 + zarb-ml/mageia-dev/2012-January/011346.html | 84 + zarb-ml/mageia-dev/2012-January/011347.html | 126 + zarb-ml/mageia-dev/2012-January/011348.html | 127 + zarb-ml/mageia-dev/2012-January/011349.html | 89 + zarb-ml/mageia-dev/2012-January/011350.html | 103 + zarb-ml/mageia-dev/2012-January/011351.html | 163 + zarb-ml/mageia-dev/2012-January/011352.html | 206 + zarb-ml/mageia-dev/2012-January/011353.html | 115 + zarb-ml/mageia-dev/2012-January/011354.html | 100 + zarb-ml/mageia-dev/2012-January/011355.html | 97 + zarb-ml/mageia-dev/2012-January/011356.html | 104 + zarb-ml/mageia-dev/2012-January/011357.html | 117 + zarb-ml/mageia-dev/2012-January/011358.html | 120 + zarb-ml/mageia-dev/2012-January/011359.html | 94 + zarb-ml/mageia-dev/2012-January/011360.html | 88 + zarb-ml/mageia-dev/2012-January/011361.html | 100 + zarb-ml/mageia-dev/2012-January/011362.html | 185 + zarb-ml/mageia-dev/2012-January/011363.html | 90 + zarb-ml/mageia-dev/2012-January/011364.html | 94 + zarb-ml/mageia-dev/2012-January/011365.html | 91 + zarb-ml/mageia-dev/2012-January/011366.html | 101 + zarb-ml/mageia-dev/2012-January/011367.html | 84 + zarb-ml/mageia-dev/2012-January/011368.html | 131 + zarb-ml/mageia-dev/2012-January/011369.html | 82 + zarb-ml/mageia-dev/2012-January/011370.html | 112 + zarb-ml/mageia-dev/2012-January/011371.html | 90 + zarb-ml/mageia-dev/2012-January/011372.html | 136 + zarb-ml/mageia-dev/2012-January/011373.html | 113 + zarb-ml/mageia-dev/2012-January/011374.html | 88 + zarb-ml/mageia-dev/2012-January/011375.html | 66 + zarb-ml/mageia-dev/2012-January/011376.html | 95 + zarb-ml/mageia-dev/2012-January/011377.html | 81 + zarb-ml/mageia-dev/2012-January/011378.html | 83 + zarb-ml/mageia-dev/2012-January/011379.html | 116 + zarb-ml/mageia-dev/2012-January/011380.html | 88 + zarb-ml/mageia-dev/2012-January/011381.html | 92 + zarb-ml/mageia-dev/2012-January/011382.html | 91 + zarb-ml/mageia-dev/2012-January/011383.html | 94 + zarb-ml/mageia-dev/2012-January/011384.html | 93 + zarb-ml/mageia-dev/2012-January/011385.html | 91 + zarb-ml/mageia-dev/2012-January/011386.html | 84 + zarb-ml/mageia-dev/2012-January/011387.html | 104 + zarb-ml/mageia-dev/2012-January/011388.html | 90 + zarb-ml/mageia-dev/2012-January/011389.html | 93 + zarb-ml/mageia-dev/2012-January/011390.html | 107 + zarb-ml/mageia-dev/2012-January/011391.html | 139 + zarb-ml/mageia-dev/2012-January/011392.html | 175 + zarb-ml/mageia-dev/2012-January/011393.html | 96 + zarb-ml/mageia-dev/2012-January/011394.html | 121 + zarb-ml/mageia-dev/2012-January/011395.html | 82 + zarb-ml/mageia-dev/2012-January/011396.html | 84 + zarb-ml/mageia-dev/2012-January/011397.html | 91 + zarb-ml/mageia-dev/2012-January/011398.html | 102 + zarb-ml/mageia-dev/2012-January/011399.html | 96 + zarb-ml/mageia-dev/2012-January/011400.html | 98 + zarb-ml/mageia-dev/2012-January/011401.html | 93 + zarb-ml/mageia-dev/2012-January/011402.html | 74 + zarb-ml/mageia-dev/2012-January/011403.html | 98 + zarb-ml/mageia-dev/2012-January/011404.html | 137 + zarb-ml/mageia-dev/2012-January/011405.html | 84 + zarb-ml/mageia-dev/2012-January/011406.html | 101 + zarb-ml/mageia-dev/2012-January/011407.html | 81 + zarb-ml/mageia-dev/2012-January/011408.html | 88 + zarb-ml/mageia-dev/2012-January/011409.html | 91 + zarb-ml/mageia-dev/2012-January/011410.html | 81 + zarb-ml/mageia-dev/2012-January/011411.html | 96 + zarb-ml/mageia-dev/2012-January/011412.html | 104 + zarb-ml/mageia-dev/2012-January/011413.html | 107 + zarb-ml/mageia-dev/2012-January/011414.html | 122 + zarb-ml/mageia-dev/2012-January/011415.html | 101 + zarb-ml/mageia-dev/2012-January/011416.html | 108 + zarb-ml/mageia-dev/2012-January/011417.html | 97 + zarb-ml/mageia-dev/2012-January/011418.html | 76 + zarb-ml/mageia-dev/2012-January/011419.html | 123 + zarb-ml/mageia-dev/2012-January/011420.html | 126 + zarb-ml/mageia-dev/2012-January/011421.html | 130 + zarb-ml/mageia-dev/2012-January/011422.html | 76 + zarb-ml/mageia-dev/2012-January/011423.html | 82 + zarb-ml/mageia-dev/2012-January/011424.html | 95 + zarb-ml/mageia-dev/2012-January/011425.html | 102 + zarb-ml/mageia-dev/2012-January/011426.html | 98 + zarb-ml/mageia-dev/2012-January/011427.html | 95 + zarb-ml/mageia-dev/2012-January/011428.html | 109 + zarb-ml/mageia-dev/2012-January/011429.html | 97 + zarb-ml/mageia-dev/2012-January/011430.html | 91 + zarb-ml/mageia-dev/2012-January/011431.html | 99 + zarb-ml/mageia-dev/2012-January/011432.html | 93 + zarb-ml/mageia-dev/2012-January/011433.html | 99 + zarb-ml/mageia-dev/2012-January/011434.html | 109 + zarb-ml/mageia-dev/2012-January/011435.html | 114 + zarb-ml/mageia-dev/2012-January/011436.html | 98 + zarb-ml/mageia-dev/2012-January/011437.html | 124 + zarb-ml/mageia-dev/2012-January/011438.html | 110 + zarb-ml/mageia-dev/2012-January/011439.html | 94 + zarb-ml/mageia-dev/2012-January/011440.html | 102 + zarb-ml/mageia-dev/2012-January/011441.html | 98 + zarb-ml/mageia-dev/2012-January/011442.html | 121 + zarb-ml/mageia-dev/2012-January/011443.html | 98 + zarb-ml/mageia-dev/2012-January/011444.html | 97 + zarb-ml/mageia-dev/2012-January/011445.html | 89 + zarb-ml/mageia-dev/2012-January/011446.html | 137 + zarb-ml/mageia-dev/2012-January/011447.html | 103 + zarb-ml/mageia-dev/2012-January/011448.html | 77 + zarb-ml/mageia-dev/2012-January/011449.html | 86 + zarb-ml/mageia-dev/2012-January/011450.html | 108 + zarb-ml/mageia-dev/2012-January/011451.html | 88 + zarb-ml/mageia-dev/2012-January/011452.html | 96 + zarb-ml/mageia-dev/2012-January/011453.html | 118 + zarb-ml/mageia-dev/2012-January/011454.html | 93 + zarb-ml/mageia-dev/2012-January/011455.html | 113 + zarb-ml/mageia-dev/2012-January/011456.html | 121 + zarb-ml/mageia-dev/2012-January/011457.html | 97 + zarb-ml/mageia-dev/2012-January/011458.html | 103 + zarb-ml/mageia-dev/2012-January/011459.html | 89 + zarb-ml/mageia-dev/2012-January/011460.html | 111 + zarb-ml/mageia-dev/2012-January/011461.html | 103 + zarb-ml/mageia-dev/2012-January/011462.html | 87 + zarb-ml/mageia-dev/2012-January/011463.html | 124 + zarb-ml/mageia-dev/2012-January/011464.html | 98 + zarb-ml/mageia-dev/2012-January/011465.html | 97 + zarb-ml/mageia-dev/2012-January/011466.html | 111 + zarb-ml/mageia-dev/2012-January/011467.html | 91 + zarb-ml/mageia-dev/2012-January/011468.html | 82 + zarb-ml/mageia-dev/2012-January/011469.html | 84 + zarb-ml/mageia-dev/2012-January/011470.html | 86 + zarb-ml/mageia-dev/2012-January/011471.html | 105 + zarb-ml/mageia-dev/2012-January/011472.html | 100 + zarb-ml/mageia-dev/2012-January/011473.html | 96 + zarb-ml/mageia-dev/2012-January/011474.html | 81 + zarb-ml/mageia-dev/2012-January/011475.html | 89 + zarb-ml/mageia-dev/2012-January/011476.html | 100 + zarb-ml/mageia-dev/2012-January/011477.html | 95 + zarb-ml/mageia-dev/2012-January/011478.html | 97 + zarb-ml/mageia-dev/2012-January/011479.html | 134 + zarb-ml/mageia-dev/2012-January/011480.html | 117 + zarb-ml/mageia-dev/2012-January/011481.html | 82 + zarb-ml/mageia-dev/2012-January/011482.html | 107 + zarb-ml/mageia-dev/2012-January/011483.html | 176 + zarb-ml/mageia-dev/2012-January/011484.html | 93 + zarb-ml/mageia-dev/2012-January/011485.html | 118 + zarb-ml/mageia-dev/2012-January/011486.html | 97 + zarb-ml/mageia-dev/2012-January/011487.html | 112 + zarb-ml/mageia-dev/2012-January/011488.html | 100 + zarb-ml/mageia-dev/2012-January/011489.html | 100 + zarb-ml/mageia-dev/2012-January/011490.html | 95 + zarb-ml/mageia-dev/2012-January/011491.html | 101 + zarb-ml/mageia-dev/2012-January/011492.html | 101 + zarb-ml/mageia-dev/2012-January/011493.html | 117 + zarb-ml/mageia-dev/2012-January/011494.html | 86 + zarb-ml/mageia-dev/2012-January/011495.html | 99 + zarb-ml/mageia-dev/2012-January/011496.html | 93 + zarb-ml/mageia-dev/2012-January/011497.html | 93 + zarb-ml/mageia-dev/2012-January/011498.html | 90 + zarb-ml/mageia-dev/2012-January/011499.html | 95 + zarb-ml/mageia-dev/2012-January/011500.html | 106 + zarb-ml/mageia-dev/2012-January/011501.html | 101 + zarb-ml/mageia-dev/2012-January/011502.html | 97 + zarb-ml/mageia-dev/2012-January/011503.html | 130 + zarb-ml/mageia-dev/2012-January/011504.html | 86 + zarb-ml/mageia-dev/2012-January/011505.html | 124 + zarb-ml/mageia-dev/2012-January/011506.html | 111 + zarb-ml/mageia-dev/2012-January/011507.html | 81 + zarb-ml/mageia-dev/2012-January/011508.html | 88 + zarb-ml/mageia-dev/2012-January/011509.html | 97 + zarb-ml/mageia-dev/2012-January/011510.html | 108 + zarb-ml/mageia-dev/2012-January/011511.html | 89 + zarb-ml/mageia-dev/2012-January/011512.html | 82 + zarb-ml/mageia-dev/2012-January/011513.html | 98 + zarb-ml/mageia-dev/2012-January/011514.html | 95 + zarb-ml/mageia-dev/2012-January/011515.html | 123 + zarb-ml/mageia-dev/2012-January/011516.html | 108 + zarb-ml/mageia-dev/2012-January/011517.html | 106 + zarb-ml/mageia-dev/2012-January/011518.html | 94 + zarb-ml/mageia-dev/2012-January/011519.html | 129 + zarb-ml/mageia-dev/2012-January/011520.html | 95 + zarb-ml/mageia-dev/2012-January/011521.html | 93 + zarb-ml/mageia-dev/2012-January/011522.html | 91 + zarb-ml/mageia-dev/2012-January/011523.html | 109 + zarb-ml/mageia-dev/2012-January/011524.html | 112 + zarb-ml/mageia-dev/2012-January/011525.html | 100 + zarb-ml/mageia-dev/2012-January/011526.html | 164 + zarb-ml/mageia-dev/2012-January/011527.html | 146 + zarb-ml/mageia-dev/2012-January/011528.html | 130 + zarb-ml/mageia-dev/2012-January/011529.html | 125 + zarb-ml/mageia-dev/2012-January/011530.html | 119 + zarb-ml/mageia-dev/2012-January/011531.html | 146 + zarb-ml/mageia-dev/2012-January/011532.html | 97 + zarb-ml/mageia-dev/2012-January/011533.html | 137 + zarb-ml/mageia-dev/2012-January/011534.html | 105 + zarb-ml/mageia-dev/2012-January/011535.html | 112 + zarb-ml/mageia-dev/2012-January/011536.html | 111 + zarb-ml/mageia-dev/2012-January/011537.html | 89 + zarb-ml/mageia-dev/2012-January/011538.html | 153 + zarb-ml/mageia-dev/2012-January/011539.html | 85 + zarb-ml/mageia-dev/2012-January/011540.html | 103 + zarb-ml/mageia-dev/2012-January/011541.html | 91 + zarb-ml/mageia-dev/2012-January/011542.html | 98 + zarb-ml/mageia-dev/2012-January/011543.html | 85 + zarb-ml/mageia-dev/2012-January/011544.html | 78 + zarb-ml/mageia-dev/2012-January/011545.html | 93 + zarb-ml/mageia-dev/2012-January/011546.html | 83 + zarb-ml/mageia-dev/2012-January/011547.html | 91 + zarb-ml/mageia-dev/2012-January/011548.html | 86 + zarb-ml/mageia-dev/2012-January/011549.html | 100 + zarb-ml/mageia-dev/2012-January/011550.html | 100 + zarb-ml/mageia-dev/2012-January/011551.html | 110 + zarb-ml/mageia-dev/2012-January/011552.html | 106 + zarb-ml/mageia-dev/2012-January/011553.html | 102 + zarb-ml/mageia-dev/2012-January/011554.html | 110 + zarb-ml/mageia-dev/2012-January/011555.html | 84 + zarb-ml/mageia-dev/2012-January/011556.html | 86 + zarb-ml/mageia-dev/2012-January/011557.html | 81 + zarb-ml/mageia-dev/2012-January/011558.html | 90 + zarb-ml/mageia-dev/2012-January/011559.html | 103 + zarb-ml/mageia-dev/2012-January/011560.html | 81 + zarb-ml/mageia-dev/2012-January/011561.html | 94 + zarb-ml/mageia-dev/2012-January/011562.html | 74 + zarb-ml/mageia-dev/2012-January/011563.html | 112 + zarb-ml/mageia-dev/2012-January/011564.html | 92 + zarb-ml/mageia-dev/2012-January/011565.html | 82 + zarb-ml/mageia-dev/2012-January/011566.html | 88 + zarb-ml/mageia-dev/2012-January/011567.html | 120 + zarb-ml/mageia-dev/2012-January/011568.html | 84 + zarb-ml/mageia-dev/2012-January/011569.html | 88 + zarb-ml/mageia-dev/2012-January/011570.html | 91 + zarb-ml/mageia-dev/2012-January/011571.html | 93 + zarb-ml/mageia-dev/2012-January/011572.html | 122 + zarb-ml/mageia-dev/2012-January/011573.html | 86 + zarb-ml/mageia-dev/2012-January/011574.html | 84 + zarb-ml/mageia-dev/2012-January/011575.html | 136 + zarb-ml/mageia-dev/2012-January/011576.html | 90 + zarb-ml/mageia-dev/2012-January/011577.html | 79 + zarb-ml/mageia-dev/2012-January/011578.html | 101 + zarb-ml/mageia-dev/2012-January/011579.html | 82 + zarb-ml/mageia-dev/2012-January/011580.html | 97 + zarb-ml/mageia-dev/2012-January/011581.html | 135 + zarb-ml/mageia-dev/2012-January/011582.html | 93 + zarb-ml/mageia-dev/2012-January/011583.html | 127 + zarb-ml/mageia-dev/2012-January/011584.html | 91 + zarb-ml/mageia-dev/2012-January/011585.html | 91 + zarb-ml/mageia-dev/2012-January/011586.html | 102 + zarb-ml/mageia-dev/2012-January/011587.html | 95 + zarb-ml/mageia-dev/2012-January/011588.html | 92 + zarb-ml/mageia-dev/2012-January/011589.html | 109 + zarb-ml/mageia-dev/2012-January/011590.html | 106 + zarb-ml/mageia-dev/2012-January/011591.html | 91 + zarb-ml/mageia-dev/2012-January/011592.html | 123 + zarb-ml/mageia-dev/2012-January/011593.html | 95 + zarb-ml/mageia-dev/2012-January/011594.html | 82 + zarb-ml/mageia-dev/2012-January/011595.html | 84 + zarb-ml/mageia-dev/2012-January/011596.html | 101 + zarb-ml/mageia-dev/2012-January/011597.html | 84 + zarb-ml/mageia-dev/2012-January/011598.html | 106 + zarb-ml/mageia-dev/2012-January/011599.html | 64 + zarb-ml/mageia-dev/2012-January/011600.html | 67 + zarb-ml/mageia-dev/2012-January/011601.html | 75 + zarb-ml/mageia-dev/2012-January/011602.html | 95 + zarb-ml/mageia-dev/2012-January/011603.html | 79 + zarb-ml/mageia-dev/2012-January/011604.html | 83 + zarb-ml/mageia-dev/2012-January/011605.html | 81 + zarb-ml/mageia-dev/2012-January/011606.html | 71 + zarb-ml/mageia-dev/2012-January/011607.html | 78 + zarb-ml/mageia-dev/2012-January/011608.html | 88 + zarb-ml/mageia-dev/2012-January/011609.html | 85 + zarb-ml/mageia-dev/2012-January/011610.html | 66 + zarb-ml/mageia-dev/2012-January/011611.html | 90 + zarb-ml/mageia-dev/2012-January/011612.html | 78 + zarb-ml/mageia-dev/2012-January/011613.html | 95 + zarb-ml/mageia-dev/2012-January/011614.html | 78 + zarb-ml/mageia-dev/2012-January/011615.html | 81 + zarb-ml/mageia-dev/2012-January/011616.html | 102 + zarb-ml/mageia-dev/2012-January/011617.html | 75 + zarb-ml/mageia-dev/2012-January/011618.html | 79 + zarb-ml/mageia-dev/2012-January/011619.html | 85 + zarb-ml/mageia-dev/2012-January/011620.html | 86 + zarb-ml/mageia-dev/2012-January/011621.html | 67 + zarb-ml/mageia-dev/2012-January/011622.html | 89 + zarb-ml/mageia-dev/2012-January/011623.html | 107 + zarb-ml/mageia-dev/2012-January/011624.html | 110 + zarb-ml/mageia-dev/2012-January/011625.html | 88 + zarb-ml/mageia-dev/2012-January/011626.html | 86 + zarb-ml/mageia-dev/2012-January/011627.html | 79 + zarb-ml/mageia-dev/2012-January/011628.html | 91 + zarb-ml/mageia-dev/2012-January/011629.html | 98 + zarb-ml/mageia-dev/2012-January/011630.html | 81 + zarb-ml/mageia-dev/2012-January/011631.html | 77 + zarb-ml/mageia-dev/2012-January/011632.html | 95 + zarb-ml/mageia-dev/2012-January/011633.html | 72 + zarb-ml/mageia-dev/2012-January/011634.html | 78 + zarb-ml/mageia-dev/2012-January/011635.html | 99 + zarb-ml/mageia-dev/2012-January/011636.html | 75 + zarb-ml/mageia-dev/2012-January/011637.html | 81 + zarb-ml/mageia-dev/2012-January/011638.html | 90 + zarb-ml/mageia-dev/2012-January/011639.html | 77 + zarb-ml/mageia-dev/2012-January/011640.html | 88 + zarb-ml/mageia-dev/2012-January/011641.html | 79 + zarb-ml/mageia-dev/2012-January/011642.html | 83 + zarb-ml/mageia-dev/2012-January/011643.html | 75 + zarb-ml/mageia-dev/2012-January/011644.html | 81 + zarb-ml/mageia-dev/2012-January/011645.html | 122 + zarb-ml/mageia-dev/2012-January/011646.html | 90 + zarb-ml/mageia-dev/2012-January/011647.html | 78 + zarb-ml/mageia-dev/2012-January/011648.html | 93 + zarb-ml/mageia-dev/2012-January/011649.html | 92 + zarb-ml/mageia-dev/2012-January/011650.html | 114 + zarb-ml/mageia-dev/2012-January/011651.html | 68 + zarb-ml/mageia-dev/2012-January/011652.html | 86 + zarb-ml/mageia-dev/2012-January/011653.html | 96 + zarb-ml/mageia-dev/2012-January/011654.html | 69 + zarb-ml/mageia-dev/2012-January/011655.html | 70 + zarb-ml/mageia-dev/2012-January/011656.html | 80 + zarb-ml/mageia-dev/2012-January/011657.html | 94 + zarb-ml/mageia-dev/2012-January/011658.html | 92 + zarb-ml/mageia-dev/2012-January/011659.html | 262 ++ zarb-ml/mageia-dev/2012-January/011660.html | 78 + zarb-ml/mageia-dev/2012-January/011661.html | 87 + zarb-ml/mageia-dev/2012-January/011662.html | 84 + zarb-ml/mageia-dev/2012-January/011663.html | 81 + zarb-ml/mageia-dev/2012-January/011664.html | 71 + zarb-ml/mageia-dev/2012-January/011665.html | 94 + zarb-ml/mageia-dev/2012-January/011666.html | 99 + zarb-ml/mageia-dev/2012-January/011667.html | 87 + zarb-ml/mageia-dev/2012-January/011668.html | 91 + zarb-ml/mageia-dev/2012-January/011669.html | 80 + zarb-ml/mageia-dev/2012-January/011670.html | 70 + zarb-ml/mageia-dev/2012-January/011671.html | 96 + zarb-ml/mageia-dev/2012-January/011672.html | 91 + zarb-ml/mageia-dev/2012-January/011673.html | 116 + zarb-ml/mageia-dev/2012-January/011674.html | 126 + zarb-ml/mageia-dev/2012-January/011675.html | 62 + zarb-ml/mageia-dev/2012-January/011676.html | 77 + zarb-ml/mageia-dev/2012-January/011677.html | 108 + zarb-ml/mageia-dev/2012-January/011678.html | 117 + zarb-ml/mageia-dev/2012-January/011679.html | 68 + zarb-ml/mageia-dev/2012-January/011680.html | 63 + zarb-ml/mageia-dev/2012-January/011681.html | 71 + zarb-ml/mageia-dev/2012-January/author.html | 4212 +++++++++++++++++++ zarb-ml/mageia-dev/2012-January/date.html | 4212 +++++++++++++++++++ zarb-ml/mageia-dev/2012-January/index.html | 1 + zarb-ml/mageia-dev/2012-January/subject.html | 4212 +++++++++++++++++++ zarb-ml/mageia-dev/2012-January/thread.html | 5661 ++++++++++++++++++++++++++ 838 files changed, 113631 insertions(+) create mode 100644 zarb-ml/mageia-dev/2012-January/010849.html create mode 100644 zarb-ml/mageia-dev/2012-January/010850.html create mode 100644 zarb-ml/mageia-dev/2012-January/010851.html create mode 100644 zarb-ml/mageia-dev/2012-January/010852.html create mode 100644 zarb-ml/mageia-dev/2012-January/010853.html create mode 100644 zarb-ml/mageia-dev/2012-January/010854.html create mode 100644 zarb-ml/mageia-dev/2012-January/010855.html create mode 100644 zarb-ml/mageia-dev/2012-January/010856.html create mode 100644 zarb-ml/mageia-dev/2012-January/010857.html create mode 100644 zarb-ml/mageia-dev/2012-January/010858.html create mode 100644 zarb-ml/mageia-dev/2012-January/010859.html create mode 100644 zarb-ml/mageia-dev/2012-January/010860.html create mode 100644 zarb-ml/mageia-dev/2012-January/010861.html create mode 100644 zarb-ml/mageia-dev/2012-January/010862.html create mode 100644 zarb-ml/mageia-dev/2012-January/010863.html create mode 100644 zarb-ml/mageia-dev/2012-January/010864.html create mode 100644 zarb-ml/mageia-dev/2012-January/010865.html create mode 100644 zarb-ml/mageia-dev/2012-January/010866.html create mode 100644 zarb-ml/mageia-dev/2012-January/010867.html create mode 100644 zarb-ml/mageia-dev/2012-January/010868.html create mode 100644 zarb-ml/mageia-dev/2012-January/010869.html create mode 100644 zarb-ml/mageia-dev/2012-January/010870.html create mode 100644 zarb-ml/mageia-dev/2012-January/010871.html create mode 100644 zarb-ml/mageia-dev/2012-January/010872.html create mode 100644 zarb-ml/mageia-dev/2012-January/010873.html create mode 100644 zarb-ml/mageia-dev/2012-January/010874.html create mode 100644 zarb-ml/mageia-dev/2012-January/010875.html create mode 100644 zarb-ml/mageia-dev/2012-January/010876.html create mode 100644 zarb-ml/mageia-dev/2012-January/010877.html create mode 100644 zarb-ml/mageia-dev/2012-January/010878.html create mode 100644 zarb-ml/mageia-dev/2012-January/010879.html create mode 100644 zarb-ml/mageia-dev/2012-January/010880.html create mode 100644 zarb-ml/mageia-dev/2012-January/010881.html create mode 100644 zarb-ml/mageia-dev/2012-January/010882.html create mode 100644 zarb-ml/mageia-dev/2012-January/010883.html create mode 100644 zarb-ml/mageia-dev/2012-January/010884.html create mode 100644 zarb-ml/mageia-dev/2012-January/010885.html create mode 100644 zarb-ml/mageia-dev/2012-January/010886.html create mode 100644 zarb-ml/mageia-dev/2012-January/010887.html create mode 100644 zarb-ml/mageia-dev/2012-January/010888.html create mode 100644 zarb-ml/mageia-dev/2012-January/010889.html create mode 100644 zarb-ml/mageia-dev/2012-January/010890.html create mode 100644 zarb-ml/mageia-dev/2012-January/010891.html create mode 100644 zarb-ml/mageia-dev/2012-January/010892.html create mode 100644 zarb-ml/mageia-dev/2012-January/010893.html create mode 100644 zarb-ml/mageia-dev/2012-January/010894.html create mode 100644 zarb-ml/mageia-dev/2012-January/010895.html create mode 100644 zarb-ml/mageia-dev/2012-January/010896.html create mode 100644 zarb-ml/mageia-dev/2012-January/010897.html create mode 100644 zarb-ml/mageia-dev/2012-January/010898.html create mode 100644 zarb-ml/mageia-dev/2012-January/010899.html create mode 100644 zarb-ml/mageia-dev/2012-January/010900.html create mode 100644 zarb-ml/mageia-dev/2012-January/010901.html create mode 100644 zarb-ml/mageia-dev/2012-January/010902.html create mode 100644 zarb-ml/mageia-dev/2012-January/010903.html create mode 100644 zarb-ml/mageia-dev/2012-January/010904.html create mode 100644 zarb-ml/mageia-dev/2012-January/010905.html create mode 100644 zarb-ml/mageia-dev/2012-January/010906.html create mode 100644 zarb-ml/mageia-dev/2012-January/010907.html create mode 100644 zarb-ml/mageia-dev/2012-January/010908.html create mode 100644 zarb-ml/mageia-dev/2012-January/010909.html create mode 100644 zarb-ml/mageia-dev/2012-January/010910.html create mode 100644 zarb-ml/mageia-dev/2012-January/010911.html create mode 100644 zarb-ml/mageia-dev/2012-January/010912.html create mode 100644 zarb-ml/mageia-dev/2012-January/010913.html create mode 100644 zarb-ml/mageia-dev/2012-January/010914.html create mode 100644 zarb-ml/mageia-dev/2012-January/010915.html create mode 100644 zarb-ml/mageia-dev/2012-January/010916.html create mode 100644 zarb-ml/mageia-dev/2012-January/010917.html create mode 100644 zarb-ml/mageia-dev/2012-January/010918.html create mode 100644 zarb-ml/mageia-dev/2012-January/010919.html create mode 100644 zarb-ml/mageia-dev/2012-January/010920.html create mode 100644 zarb-ml/mageia-dev/2012-January/010921.html create mode 100644 zarb-ml/mageia-dev/2012-January/010922.html create mode 100644 zarb-ml/mageia-dev/2012-January/010923.html create mode 100644 zarb-ml/mageia-dev/2012-January/010924.html create mode 100644 zarb-ml/mageia-dev/2012-January/010925.html create mode 100644 zarb-ml/mageia-dev/2012-January/010926.html create mode 100644 zarb-ml/mageia-dev/2012-January/010927.html create mode 100644 zarb-ml/mageia-dev/2012-January/010928.html create mode 100644 zarb-ml/mageia-dev/2012-January/010929.html create mode 100644 zarb-ml/mageia-dev/2012-January/010930.html create mode 100644 zarb-ml/mageia-dev/2012-January/010931.html create mode 100644 zarb-ml/mageia-dev/2012-January/010932.html create mode 100644 zarb-ml/mageia-dev/2012-January/010933.html create mode 100644 zarb-ml/mageia-dev/2012-January/010934.html create mode 100644 zarb-ml/mageia-dev/2012-January/010935.html create mode 100644 zarb-ml/mageia-dev/2012-January/010936.html create mode 100644 zarb-ml/mageia-dev/2012-January/010937.html create mode 100644 zarb-ml/mageia-dev/2012-January/010938.html create mode 100644 zarb-ml/mageia-dev/2012-January/010939.html create mode 100644 zarb-ml/mageia-dev/2012-January/010940.html create mode 100644 zarb-ml/mageia-dev/2012-January/010941.html create mode 100644 zarb-ml/mageia-dev/2012-January/010942.html create mode 100644 zarb-ml/mageia-dev/2012-January/010943.html create mode 100644 zarb-ml/mageia-dev/2012-January/010944.html create mode 100644 zarb-ml/mageia-dev/2012-January/010945.html create mode 100644 zarb-ml/mageia-dev/2012-January/010946.html create mode 100644 zarb-ml/mageia-dev/2012-January/010947.html create mode 100644 zarb-ml/mageia-dev/2012-January/010948.html create mode 100644 zarb-ml/mageia-dev/2012-January/010949.html create mode 100644 zarb-ml/mageia-dev/2012-January/010950.html create mode 100644 zarb-ml/mageia-dev/2012-January/010951.html create mode 100644 zarb-ml/mageia-dev/2012-January/010952.html create mode 100644 zarb-ml/mageia-dev/2012-January/010953.html create mode 100644 zarb-ml/mageia-dev/2012-January/010954.html create mode 100644 zarb-ml/mageia-dev/2012-January/010955.html create mode 100644 zarb-ml/mageia-dev/2012-January/010956.html create mode 100644 zarb-ml/mageia-dev/2012-January/010957.html create mode 100644 zarb-ml/mageia-dev/2012-January/010958.html create mode 100644 zarb-ml/mageia-dev/2012-January/010959.html create mode 100644 zarb-ml/mageia-dev/2012-January/010960.html create mode 100644 zarb-ml/mageia-dev/2012-January/010961.html create mode 100644 zarb-ml/mageia-dev/2012-January/010962.html create mode 100644 zarb-ml/mageia-dev/2012-January/010963.html create mode 100644 zarb-ml/mageia-dev/2012-January/010964.html create mode 100644 zarb-ml/mageia-dev/2012-January/010965.html create mode 100644 zarb-ml/mageia-dev/2012-January/010966.html create mode 100644 zarb-ml/mageia-dev/2012-January/010967.html create mode 100644 zarb-ml/mageia-dev/2012-January/010968.html create mode 100644 zarb-ml/mageia-dev/2012-January/010969.html create mode 100644 zarb-ml/mageia-dev/2012-January/010970.html create mode 100644 zarb-ml/mageia-dev/2012-January/010971.html create mode 100644 zarb-ml/mageia-dev/2012-January/010972.html create mode 100644 zarb-ml/mageia-dev/2012-January/010973.html create mode 100644 zarb-ml/mageia-dev/2012-January/010974.html create mode 100644 zarb-ml/mageia-dev/2012-January/010975.html create mode 100644 zarb-ml/mageia-dev/2012-January/010976.html create mode 100644 zarb-ml/mageia-dev/2012-January/010977.html create mode 100644 zarb-ml/mageia-dev/2012-January/010978.html create mode 100644 zarb-ml/mageia-dev/2012-January/010979.html create mode 100644 zarb-ml/mageia-dev/2012-January/010980.html create mode 100644 zarb-ml/mageia-dev/2012-January/010981.html create mode 100644 zarb-ml/mageia-dev/2012-January/010982.html create mode 100644 zarb-ml/mageia-dev/2012-January/010983.html create mode 100644 zarb-ml/mageia-dev/2012-January/010984.html create mode 100644 zarb-ml/mageia-dev/2012-January/010985.html create mode 100644 zarb-ml/mageia-dev/2012-January/010986.html create mode 100644 zarb-ml/mageia-dev/2012-January/010987.html create mode 100644 zarb-ml/mageia-dev/2012-January/010988.html create mode 100644 zarb-ml/mageia-dev/2012-January/010989.html create mode 100644 zarb-ml/mageia-dev/2012-January/010990.html create mode 100644 zarb-ml/mageia-dev/2012-January/010991.html create mode 100644 zarb-ml/mageia-dev/2012-January/010992.html create mode 100644 zarb-ml/mageia-dev/2012-January/010993.html create mode 100644 zarb-ml/mageia-dev/2012-January/010994.html create mode 100644 zarb-ml/mageia-dev/2012-January/010995.html create mode 100644 zarb-ml/mageia-dev/2012-January/010996.html create mode 100644 zarb-ml/mageia-dev/2012-January/010997.html create mode 100644 zarb-ml/mageia-dev/2012-January/010998.html create mode 100644 zarb-ml/mageia-dev/2012-January/010999.html create mode 100644 zarb-ml/mageia-dev/2012-January/011000.html create mode 100644 zarb-ml/mageia-dev/2012-January/011001.html create mode 100644 zarb-ml/mageia-dev/2012-January/011002.html create mode 100644 zarb-ml/mageia-dev/2012-January/011003.html create mode 100644 zarb-ml/mageia-dev/2012-January/011004.html create mode 100644 zarb-ml/mageia-dev/2012-January/011005.html create mode 100644 zarb-ml/mageia-dev/2012-January/011006.html create mode 100644 zarb-ml/mageia-dev/2012-January/011007.html create mode 100644 zarb-ml/mageia-dev/2012-January/011008.html create mode 100644 zarb-ml/mageia-dev/2012-January/011009.html create mode 100644 zarb-ml/mageia-dev/2012-January/011010.html create mode 100644 zarb-ml/mageia-dev/2012-January/011011.html create mode 100644 zarb-ml/mageia-dev/2012-January/011012.html create mode 100644 zarb-ml/mageia-dev/2012-January/011013.html create mode 100644 zarb-ml/mageia-dev/2012-January/011014.html create mode 100644 zarb-ml/mageia-dev/2012-January/011015.html create mode 100644 zarb-ml/mageia-dev/2012-January/011016.html create mode 100644 zarb-ml/mageia-dev/2012-January/011017.html create mode 100644 zarb-ml/mageia-dev/2012-January/011018.html create mode 100644 zarb-ml/mageia-dev/2012-January/011019.html create mode 100644 zarb-ml/mageia-dev/2012-January/011020.html create mode 100644 zarb-ml/mageia-dev/2012-January/011021.html create mode 100644 zarb-ml/mageia-dev/2012-January/011022.html create mode 100644 zarb-ml/mageia-dev/2012-January/011023.html create mode 100644 zarb-ml/mageia-dev/2012-January/011024.html create mode 100644 zarb-ml/mageia-dev/2012-January/011025.html create mode 100644 zarb-ml/mageia-dev/2012-January/011026.html create mode 100644 zarb-ml/mageia-dev/2012-January/011027.html create mode 100644 zarb-ml/mageia-dev/2012-January/011028.html create mode 100644 zarb-ml/mageia-dev/2012-January/011029.html create mode 100644 zarb-ml/mageia-dev/2012-January/011030.html create mode 100644 zarb-ml/mageia-dev/2012-January/011031.html create mode 100644 zarb-ml/mageia-dev/2012-January/011032.html create mode 100644 zarb-ml/mageia-dev/2012-January/011033.html create mode 100644 zarb-ml/mageia-dev/2012-January/011034.html create mode 100644 zarb-ml/mageia-dev/2012-January/011035.html create mode 100644 zarb-ml/mageia-dev/2012-January/011036.html create mode 100644 zarb-ml/mageia-dev/2012-January/011037.html create mode 100644 zarb-ml/mageia-dev/2012-January/011038.html create mode 100644 zarb-ml/mageia-dev/2012-January/011039.html create mode 100644 zarb-ml/mageia-dev/2012-January/011040.html create mode 100644 zarb-ml/mageia-dev/2012-January/011041.html create mode 100644 zarb-ml/mageia-dev/2012-January/011042.html create mode 100644 zarb-ml/mageia-dev/2012-January/011043.html create mode 100644 zarb-ml/mageia-dev/2012-January/011044.html create mode 100644 zarb-ml/mageia-dev/2012-January/011045.html create mode 100644 zarb-ml/mageia-dev/2012-January/011046.html create mode 100644 zarb-ml/mageia-dev/2012-January/011047.html create mode 100644 zarb-ml/mageia-dev/2012-January/011048.html create mode 100644 zarb-ml/mageia-dev/2012-January/011049.html create mode 100644 zarb-ml/mageia-dev/2012-January/011050.html create mode 100644 zarb-ml/mageia-dev/2012-January/011051.html create mode 100644 zarb-ml/mageia-dev/2012-January/011052.html create mode 100644 zarb-ml/mageia-dev/2012-January/011053.html create mode 100644 zarb-ml/mageia-dev/2012-January/011054.html create mode 100644 zarb-ml/mageia-dev/2012-January/011055.html create mode 100644 zarb-ml/mageia-dev/2012-January/011056.html create mode 100644 zarb-ml/mageia-dev/2012-January/011057.html create mode 100644 zarb-ml/mageia-dev/2012-January/011058.html create mode 100644 zarb-ml/mageia-dev/2012-January/011059.html create mode 100644 zarb-ml/mageia-dev/2012-January/011060.html create mode 100644 zarb-ml/mageia-dev/2012-January/011061.html create mode 100644 zarb-ml/mageia-dev/2012-January/011062.html create mode 100644 zarb-ml/mageia-dev/2012-January/011063.html create mode 100644 zarb-ml/mageia-dev/2012-January/011064.html create mode 100644 zarb-ml/mageia-dev/2012-January/011065.html create mode 100644 zarb-ml/mageia-dev/2012-January/011066.html create mode 100644 zarb-ml/mageia-dev/2012-January/011067.html create mode 100644 zarb-ml/mageia-dev/2012-January/011068.html create mode 100644 zarb-ml/mageia-dev/2012-January/011069.html create mode 100644 zarb-ml/mageia-dev/2012-January/011070.html create mode 100644 zarb-ml/mageia-dev/2012-January/011071.html create mode 100644 zarb-ml/mageia-dev/2012-January/011072.html create mode 100644 zarb-ml/mageia-dev/2012-January/011073.html create mode 100644 zarb-ml/mageia-dev/2012-January/011074.html create mode 100644 zarb-ml/mageia-dev/2012-January/011075.html create mode 100644 zarb-ml/mageia-dev/2012-January/011076.html create mode 100644 zarb-ml/mageia-dev/2012-January/011077.html create mode 100644 zarb-ml/mageia-dev/2012-January/011078.html create mode 100644 zarb-ml/mageia-dev/2012-January/011079.html create mode 100644 zarb-ml/mageia-dev/2012-January/011080.html create mode 100644 zarb-ml/mageia-dev/2012-January/011081.html create mode 100644 zarb-ml/mageia-dev/2012-January/011082.html create mode 100644 zarb-ml/mageia-dev/2012-January/011083.html create mode 100644 zarb-ml/mageia-dev/2012-January/011084.html create mode 100644 zarb-ml/mageia-dev/2012-January/011085.html create mode 100644 zarb-ml/mageia-dev/2012-January/011086.html create mode 100644 zarb-ml/mageia-dev/2012-January/011087.html create mode 100644 zarb-ml/mageia-dev/2012-January/011088.html create mode 100644 zarb-ml/mageia-dev/2012-January/011089.html create mode 100644 zarb-ml/mageia-dev/2012-January/011090.html create mode 100644 zarb-ml/mageia-dev/2012-January/011091.html create mode 100644 zarb-ml/mageia-dev/2012-January/011092.html create mode 100644 zarb-ml/mageia-dev/2012-January/011093.html create mode 100644 zarb-ml/mageia-dev/2012-January/011094.html create mode 100644 zarb-ml/mageia-dev/2012-January/011095.html create mode 100644 zarb-ml/mageia-dev/2012-January/011096.html create mode 100644 zarb-ml/mageia-dev/2012-January/011097.html create mode 100644 zarb-ml/mageia-dev/2012-January/011098.html create mode 100644 zarb-ml/mageia-dev/2012-January/011099.html create mode 100644 zarb-ml/mageia-dev/2012-January/011100.html create mode 100644 zarb-ml/mageia-dev/2012-January/011101.html create mode 100644 zarb-ml/mageia-dev/2012-January/011102.html create mode 100644 zarb-ml/mageia-dev/2012-January/011103.html create mode 100644 zarb-ml/mageia-dev/2012-January/011104.html create mode 100644 zarb-ml/mageia-dev/2012-January/011105.html create mode 100644 zarb-ml/mageia-dev/2012-January/011106.html create mode 100644 zarb-ml/mageia-dev/2012-January/011107.html create mode 100644 zarb-ml/mageia-dev/2012-January/011108.html create mode 100644 zarb-ml/mageia-dev/2012-January/011109.html create mode 100644 zarb-ml/mageia-dev/2012-January/011110.html create mode 100644 zarb-ml/mageia-dev/2012-January/011111.html create mode 100644 zarb-ml/mageia-dev/2012-January/011112.html create mode 100644 zarb-ml/mageia-dev/2012-January/011113.html create mode 100644 zarb-ml/mageia-dev/2012-January/011114.html create mode 100644 zarb-ml/mageia-dev/2012-January/011115.html create mode 100644 zarb-ml/mageia-dev/2012-January/011116.html create mode 100644 zarb-ml/mageia-dev/2012-January/011117.html create mode 100644 zarb-ml/mageia-dev/2012-January/011118.html create mode 100644 zarb-ml/mageia-dev/2012-January/011119.html create mode 100644 zarb-ml/mageia-dev/2012-January/011120.html create mode 100644 zarb-ml/mageia-dev/2012-January/011121.html create mode 100644 zarb-ml/mageia-dev/2012-January/011122.html create mode 100644 zarb-ml/mageia-dev/2012-January/011123.html create mode 100644 zarb-ml/mageia-dev/2012-January/011124.html create mode 100644 zarb-ml/mageia-dev/2012-January/011125.html create mode 100644 zarb-ml/mageia-dev/2012-January/011126.html create mode 100644 zarb-ml/mageia-dev/2012-January/011127.html create mode 100644 zarb-ml/mageia-dev/2012-January/011128.html create mode 100644 zarb-ml/mageia-dev/2012-January/011129.html create mode 100644 zarb-ml/mageia-dev/2012-January/011130.html create mode 100644 zarb-ml/mageia-dev/2012-January/011131.html create mode 100644 zarb-ml/mageia-dev/2012-January/011132.html create mode 100644 zarb-ml/mageia-dev/2012-January/011133.html create mode 100644 zarb-ml/mageia-dev/2012-January/011134.html create mode 100644 zarb-ml/mageia-dev/2012-January/011135.html create mode 100644 zarb-ml/mageia-dev/2012-January/011136.html create mode 100644 zarb-ml/mageia-dev/2012-January/011137.html create mode 100644 zarb-ml/mageia-dev/2012-January/011138.html create mode 100644 zarb-ml/mageia-dev/2012-January/011139.html create mode 100644 zarb-ml/mageia-dev/2012-January/011140.html create mode 100644 zarb-ml/mageia-dev/2012-January/011141.html create mode 100644 zarb-ml/mageia-dev/2012-January/011142.html create mode 100644 zarb-ml/mageia-dev/2012-January/011143.html create mode 100644 zarb-ml/mageia-dev/2012-January/011144.html create mode 100644 zarb-ml/mageia-dev/2012-January/011145.html create mode 100644 zarb-ml/mageia-dev/2012-January/011146.html create mode 100644 zarb-ml/mageia-dev/2012-January/011147.html create mode 100644 zarb-ml/mageia-dev/2012-January/011148.html create mode 100644 zarb-ml/mageia-dev/2012-January/011149.html create mode 100644 zarb-ml/mageia-dev/2012-January/011150.html create mode 100644 zarb-ml/mageia-dev/2012-January/011151.html create mode 100644 zarb-ml/mageia-dev/2012-January/011152.html create mode 100644 zarb-ml/mageia-dev/2012-January/011153.html create mode 100644 zarb-ml/mageia-dev/2012-January/011154.html create mode 100644 zarb-ml/mageia-dev/2012-January/011155.html create mode 100644 zarb-ml/mageia-dev/2012-January/011156.html create mode 100644 zarb-ml/mageia-dev/2012-January/011157.html create mode 100644 zarb-ml/mageia-dev/2012-January/011158.html create mode 100644 zarb-ml/mageia-dev/2012-January/011159.html create mode 100644 zarb-ml/mageia-dev/2012-January/011160.html create mode 100644 zarb-ml/mageia-dev/2012-January/011161.html create mode 100644 zarb-ml/mageia-dev/2012-January/011162.html create mode 100644 zarb-ml/mageia-dev/2012-January/011163.html create mode 100644 zarb-ml/mageia-dev/2012-January/011164.html create mode 100644 zarb-ml/mageia-dev/2012-January/011165.html create mode 100644 zarb-ml/mageia-dev/2012-January/011166.html create mode 100644 zarb-ml/mageia-dev/2012-January/011167.html create mode 100644 zarb-ml/mageia-dev/2012-January/011168.html create mode 100644 zarb-ml/mageia-dev/2012-January/011169.html create mode 100644 zarb-ml/mageia-dev/2012-January/011170.html create mode 100644 zarb-ml/mageia-dev/2012-January/011171.html create mode 100644 zarb-ml/mageia-dev/2012-January/011172.html create mode 100644 zarb-ml/mageia-dev/2012-January/011173.html create mode 100644 zarb-ml/mageia-dev/2012-January/011174.html create mode 100644 zarb-ml/mageia-dev/2012-January/011175.html create mode 100644 zarb-ml/mageia-dev/2012-January/011176.html create mode 100644 zarb-ml/mageia-dev/2012-January/011177.html create mode 100644 zarb-ml/mageia-dev/2012-January/011178.html create mode 100644 zarb-ml/mageia-dev/2012-January/011179.html create mode 100644 zarb-ml/mageia-dev/2012-January/011180.html create mode 100644 zarb-ml/mageia-dev/2012-January/011181.html create mode 100644 zarb-ml/mageia-dev/2012-January/011182.html create mode 100644 zarb-ml/mageia-dev/2012-January/011183.html create mode 100644 zarb-ml/mageia-dev/2012-January/011184.html create mode 100644 zarb-ml/mageia-dev/2012-January/011185.html create mode 100644 zarb-ml/mageia-dev/2012-January/011186.html create mode 100644 zarb-ml/mageia-dev/2012-January/011187.html create mode 100644 zarb-ml/mageia-dev/2012-January/011188.html create mode 100644 zarb-ml/mageia-dev/2012-January/011189.html create mode 100644 zarb-ml/mageia-dev/2012-January/011190.html create mode 100644 zarb-ml/mageia-dev/2012-January/011191.html create mode 100644 zarb-ml/mageia-dev/2012-January/011192.html create mode 100644 zarb-ml/mageia-dev/2012-January/011193.html create mode 100644 zarb-ml/mageia-dev/2012-January/011194.html create mode 100644 zarb-ml/mageia-dev/2012-January/011195.html create mode 100644 zarb-ml/mageia-dev/2012-January/011196.html create mode 100644 zarb-ml/mageia-dev/2012-January/011197.html create mode 100644 zarb-ml/mageia-dev/2012-January/011198.html create mode 100644 zarb-ml/mageia-dev/2012-January/011199.html create mode 100644 zarb-ml/mageia-dev/2012-January/011200.html create mode 100644 zarb-ml/mageia-dev/2012-January/011201.html create mode 100644 zarb-ml/mageia-dev/2012-January/011202.html create mode 100644 zarb-ml/mageia-dev/2012-January/011203.html create mode 100644 zarb-ml/mageia-dev/2012-January/011204.html create mode 100644 zarb-ml/mageia-dev/2012-January/011205.html create mode 100644 zarb-ml/mageia-dev/2012-January/011206.html create mode 100644 zarb-ml/mageia-dev/2012-January/011207.html create mode 100644 zarb-ml/mageia-dev/2012-January/011208.html create mode 100644 zarb-ml/mageia-dev/2012-January/011209.html create mode 100644 zarb-ml/mageia-dev/2012-January/011210.html create mode 100644 zarb-ml/mageia-dev/2012-January/011211.html create mode 100644 zarb-ml/mageia-dev/2012-January/011212.html create mode 100644 zarb-ml/mageia-dev/2012-January/011213.html create mode 100644 zarb-ml/mageia-dev/2012-January/011214.html create mode 100644 zarb-ml/mageia-dev/2012-January/011215.html create mode 100644 zarb-ml/mageia-dev/2012-January/011216.html create mode 100644 zarb-ml/mageia-dev/2012-January/011217.html create mode 100644 zarb-ml/mageia-dev/2012-January/011218.html create mode 100644 zarb-ml/mageia-dev/2012-January/011219.html create mode 100644 zarb-ml/mageia-dev/2012-January/011220.html create mode 100644 zarb-ml/mageia-dev/2012-January/011221.html create mode 100644 zarb-ml/mageia-dev/2012-January/011222.html create mode 100644 zarb-ml/mageia-dev/2012-January/011223.html create mode 100644 zarb-ml/mageia-dev/2012-January/011224.html create mode 100644 zarb-ml/mageia-dev/2012-January/011225.html create mode 100644 zarb-ml/mageia-dev/2012-January/011226.html create mode 100644 zarb-ml/mageia-dev/2012-January/011227.html create mode 100644 zarb-ml/mageia-dev/2012-January/011228.html create mode 100644 zarb-ml/mageia-dev/2012-January/011229.html create mode 100644 zarb-ml/mageia-dev/2012-January/011230.html create mode 100644 zarb-ml/mageia-dev/2012-January/011231.html create mode 100644 zarb-ml/mageia-dev/2012-January/011232.html create mode 100644 zarb-ml/mageia-dev/2012-January/011233.html create mode 100644 zarb-ml/mageia-dev/2012-January/011234.html create mode 100644 zarb-ml/mageia-dev/2012-January/011235.html create mode 100644 zarb-ml/mageia-dev/2012-January/011236.html create mode 100644 zarb-ml/mageia-dev/2012-January/011237.html create mode 100644 zarb-ml/mageia-dev/2012-January/011238.html create mode 100644 zarb-ml/mageia-dev/2012-January/011239.html create mode 100644 zarb-ml/mageia-dev/2012-January/011240.html create mode 100644 zarb-ml/mageia-dev/2012-January/011241.html create mode 100644 zarb-ml/mageia-dev/2012-January/011242.html create mode 100644 zarb-ml/mageia-dev/2012-January/011243.html create mode 100644 zarb-ml/mageia-dev/2012-January/011244.html create mode 100644 zarb-ml/mageia-dev/2012-January/011245.html create mode 100644 zarb-ml/mageia-dev/2012-January/011246.html create mode 100644 zarb-ml/mageia-dev/2012-January/011247.html create mode 100644 zarb-ml/mageia-dev/2012-January/011248.html create mode 100644 zarb-ml/mageia-dev/2012-January/011249.html create mode 100644 zarb-ml/mageia-dev/2012-January/011250.html create mode 100644 zarb-ml/mageia-dev/2012-January/011251.html create mode 100644 zarb-ml/mageia-dev/2012-January/011252.html create mode 100644 zarb-ml/mageia-dev/2012-January/011253.html create mode 100644 zarb-ml/mageia-dev/2012-January/011254.html create mode 100644 zarb-ml/mageia-dev/2012-January/011255.html create mode 100644 zarb-ml/mageia-dev/2012-January/011256.html create mode 100644 zarb-ml/mageia-dev/2012-January/011257.html create mode 100644 zarb-ml/mageia-dev/2012-January/011258.html create mode 100644 zarb-ml/mageia-dev/2012-January/011259.html create mode 100644 zarb-ml/mageia-dev/2012-January/011260.html create mode 100644 zarb-ml/mageia-dev/2012-January/011261.html create mode 100644 zarb-ml/mageia-dev/2012-January/011262.html create mode 100644 zarb-ml/mageia-dev/2012-January/011263.html create mode 100644 zarb-ml/mageia-dev/2012-January/011264.html create mode 100644 zarb-ml/mageia-dev/2012-January/011265.html create mode 100644 zarb-ml/mageia-dev/2012-January/011266.html create mode 100644 zarb-ml/mageia-dev/2012-January/011267.html create mode 100644 zarb-ml/mageia-dev/2012-January/011268.html create mode 100644 zarb-ml/mageia-dev/2012-January/011269.html create mode 100644 zarb-ml/mageia-dev/2012-January/011270.html create mode 100644 zarb-ml/mageia-dev/2012-January/011271.html create mode 100644 zarb-ml/mageia-dev/2012-January/011272.html create mode 100644 zarb-ml/mageia-dev/2012-January/011273.html create mode 100644 zarb-ml/mageia-dev/2012-January/011274.html create mode 100644 zarb-ml/mageia-dev/2012-January/011275.html create mode 100644 zarb-ml/mageia-dev/2012-January/011276.html create mode 100644 zarb-ml/mageia-dev/2012-January/011277.html create mode 100644 zarb-ml/mageia-dev/2012-January/011278.html create mode 100644 zarb-ml/mageia-dev/2012-January/011279.html create mode 100644 zarb-ml/mageia-dev/2012-January/011280.html create mode 100644 zarb-ml/mageia-dev/2012-January/011281.html create mode 100644 zarb-ml/mageia-dev/2012-January/011282.html create mode 100644 zarb-ml/mageia-dev/2012-January/011283.html create mode 100644 zarb-ml/mageia-dev/2012-January/011284.html create mode 100644 zarb-ml/mageia-dev/2012-January/011285.html create mode 100644 zarb-ml/mageia-dev/2012-January/011286.html create mode 100644 zarb-ml/mageia-dev/2012-January/011287.html create mode 100644 zarb-ml/mageia-dev/2012-January/011288.html create mode 100644 zarb-ml/mageia-dev/2012-January/011289.html create mode 100644 zarb-ml/mageia-dev/2012-January/011290.html create mode 100644 zarb-ml/mageia-dev/2012-January/011291.html create mode 100644 zarb-ml/mageia-dev/2012-January/011292.html create mode 100644 zarb-ml/mageia-dev/2012-January/011293.html create mode 100644 zarb-ml/mageia-dev/2012-January/011294.html create mode 100644 zarb-ml/mageia-dev/2012-January/011295.html create mode 100644 zarb-ml/mageia-dev/2012-January/011296.html create mode 100644 zarb-ml/mageia-dev/2012-January/011297.html create mode 100644 zarb-ml/mageia-dev/2012-January/011298.html create mode 100644 zarb-ml/mageia-dev/2012-January/011299.html create mode 100644 zarb-ml/mageia-dev/2012-January/011300.html create mode 100644 zarb-ml/mageia-dev/2012-January/011301.html create mode 100644 zarb-ml/mageia-dev/2012-January/011302.html create mode 100644 zarb-ml/mageia-dev/2012-January/011303.html create mode 100644 zarb-ml/mageia-dev/2012-January/011304.html create mode 100644 zarb-ml/mageia-dev/2012-January/011305.html create mode 100644 zarb-ml/mageia-dev/2012-January/011306.html create mode 100644 zarb-ml/mageia-dev/2012-January/011307.html create mode 100644 zarb-ml/mageia-dev/2012-January/011308.html create mode 100644 zarb-ml/mageia-dev/2012-January/011309.html create mode 100644 zarb-ml/mageia-dev/2012-January/011310.html create mode 100644 zarb-ml/mageia-dev/2012-January/011311.html create mode 100644 zarb-ml/mageia-dev/2012-January/011312.html create mode 100644 zarb-ml/mageia-dev/2012-January/011313.html create mode 100644 zarb-ml/mageia-dev/2012-January/011314.html create mode 100644 zarb-ml/mageia-dev/2012-January/011315.html create mode 100644 zarb-ml/mageia-dev/2012-January/011316.html create mode 100644 zarb-ml/mageia-dev/2012-January/011317.html create mode 100644 zarb-ml/mageia-dev/2012-January/011318.html create mode 100644 zarb-ml/mageia-dev/2012-January/011319.html create mode 100644 zarb-ml/mageia-dev/2012-January/011320.html create mode 100644 zarb-ml/mageia-dev/2012-January/011321.html create mode 100644 zarb-ml/mageia-dev/2012-January/011322.html create mode 100644 zarb-ml/mageia-dev/2012-January/011323.html create mode 100644 zarb-ml/mageia-dev/2012-January/011324.html create mode 100644 zarb-ml/mageia-dev/2012-January/011325.html create mode 100644 zarb-ml/mageia-dev/2012-January/011326.html create mode 100644 zarb-ml/mageia-dev/2012-January/011327.html create mode 100644 zarb-ml/mageia-dev/2012-January/011328.html create mode 100644 zarb-ml/mageia-dev/2012-January/011329.html create mode 100644 zarb-ml/mageia-dev/2012-January/011330.html create mode 100644 zarb-ml/mageia-dev/2012-January/011331.html create mode 100644 zarb-ml/mageia-dev/2012-January/011332.html create mode 100644 zarb-ml/mageia-dev/2012-January/011333.html create mode 100644 zarb-ml/mageia-dev/2012-January/011334.html create mode 100644 zarb-ml/mageia-dev/2012-January/011335.html create mode 100644 zarb-ml/mageia-dev/2012-January/011336.html create mode 100644 zarb-ml/mageia-dev/2012-January/011337.html create mode 100644 zarb-ml/mageia-dev/2012-January/011338.html create mode 100644 zarb-ml/mageia-dev/2012-January/011339.html create mode 100644 zarb-ml/mageia-dev/2012-January/011340.html create mode 100644 zarb-ml/mageia-dev/2012-January/011341.html create mode 100644 zarb-ml/mageia-dev/2012-January/011342.html create mode 100644 zarb-ml/mageia-dev/2012-January/011343.html create mode 100644 zarb-ml/mageia-dev/2012-January/011344.html create mode 100644 zarb-ml/mageia-dev/2012-January/011345.html create mode 100644 zarb-ml/mageia-dev/2012-January/011346.html create mode 100644 zarb-ml/mageia-dev/2012-January/011347.html create mode 100644 zarb-ml/mageia-dev/2012-January/011348.html create mode 100644 zarb-ml/mageia-dev/2012-January/011349.html create mode 100644 zarb-ml/mageia-dev/2012-January/011350.html create mode 100644 zarb-ml/mageia-dev/2012-January/011351.html create mode 100644 zarb-ml/mageia-dev/2012-January/011352.html create mode 100644 zarb-ml/mageia-dev/2012-January/011353.html create mode 100644 zarb-ml/mageia-dev/2012-January/011354.html create mode 100644 zarb-ml/mageia-dev/2012-January/011355.html create mode 100644 zarb-ml/mageia-dev/2012-January/011356.html create mode 100644 zarb-ml/mageia-dev/2012-January/011357.html create mode 100644 zarb-ml/mageia-dev/2012-January/011358.html create mode 100644 zarb-ml/mageia-dev/2012-January/011359.html create mode 100644 zarb-ml/mageia-dev/2012-January/011360.html create mode 100644 zarb-ml/mageia-dev/2012-January/011361.html create mode 100644 zarb-ml/mageia-dev/2012-January/011362.html create mode 100644 zarb-ml/mageia-dev/2012-January/011363.html create mode 100644 zarb-ml/mageia-dev/2012-January/011364.html create mode 100644 zarb-ml/mageia-dev/2012-January/011365.html create mode 100644 zarb-ml/mageia-dev/2012-January/011366.html create mode 100644 zarb-ml/mageia-dev/2012-January/011367.html create mode 100644 zarb-ml/mageia-dev/2012-January/011368.html create mode 100644 zarb-ml/mageia-dev/2012-January/011369.html create mode 100644 zarb-ml/mageia-dev/2012-January/011370.html create mode 100644 zarb-ml/mageia-dev/2012-January/011371.html create mode 100644 zarb-ml/mageia-dev/2012-January/011372.html create mode 100644 zarb-ml/mageia-dev/2012-January/011373.html create mode 100644 zarb-ml/mageia-dev/2012-January/011374.html create mode 100644 zarb-ml/mageia-dev/2012-January/011375.html create mode 100644 zarb-ml/mageia-dev/2012-January/011376.html create mode 100644 zarb-ml/mageia-dev/2012-January/011377.html create mode 100644 zarb-ml/mageia-dev/2012-January/011378.html create mode 100644 zarb-ml/mageia-dev/2012-January/011379.html create mode 100644 zarb-ml/mageia-dev/2012-January/011380.html create mode 100644 zarb-ml/mageia-dev/2012-January/011381.html create mode 100644 zarb-ml/mageia-dev/2012-January/011382.html create mode 100644 zarb-ml/mageia-dev/2012-January/011383.html create mode 100644 zarb-ml/mageia-dev/2012-January/011384.html create mode 100644 zarb-ml/mageia-dev/2012-January/011385.html create mode 100644 zarb-ml/mageia-dev/2012-January/011386.html create mode 100644 zarb-ml/mageia-dev/2012-January/011387.html create mode 100644 zarb-ml/mageia-dev/2012-January/011388.html create mode 100644 zarb-ml/mageia-dev/2012-January/011389.html create mode 100644 zarb-ml/mageia-dev/2012-January/011390.html create mode 100644 zarb-ml/mageia-dev/2012-January/011391.html create mode 100644 zarb-ml/mageia-dev/2012-January/011392.html create mode 100644 zarb-ml/mageia-dev/2012-January/011393.html create mode 100644 zarb-ml/mageia-dev/2012-January/011394.html create mode 100644 zarb-ml/mageia-dev/2012-January/011395.html create mode 100644 zarb-ml/mageia-dev/2012-January/011396.html create mode 100644 zarb-ml/mageia-dev/2012-January/011397.html create mode 100644 zarb-ml/mageia-dev/2012-January/011398.html create mode 100644 zarb-ml/mageia-dev/2012-January/011399.html create mode 100644 zarb-ml/mageia-dev/2012-January/011400.html create mode 100644 zarb-ml/mageia-dev/2012-January/011401.html create mode 100644 zarb-ml/mageia-dev/2012-January/011402.html create mode 100644 zarb-ml/mageia-dev/2012-January/011403.html create mode 100644 zarb-ml/mageia-dev/2012-January/011404.html create mode 100644 zarb-ml/mageia-dev/2012-January/011405.html create mode 100644 zarb-ml/mageia-dev/2012-January/011406.html create mode 100644 zarb-ml/mageia-dev/2012-January/011407.html create mode 100644 zarb-ml/mageia-dev/2012-January/011408.html create mode 100644 zarb-ml/mageia-dev/2012-January/011409.html create mode 100644 zarb-ml/mageia-dev/2012-January/011410.html create mode 100644 zarb-ml/mageia-dev/2012-January/011411.html create mode 100644 zarb-ml/mageia-dev/2012-January/011412.html create mode 100644 zarb-ml/mageia-dev/2012-January/011413.html create mode 100644 zarb-ml/mageia-dev/2012-January/011414.html create mode 100644 zarb-ml/mageia-dev/2012-January/011415.html create mode 100644 zarb-ml/mageia-dev/2012-January/011416.html create mode 100644 zarb-ml/mageia-dev/2012-January/011417.html create mode 100644 zarb-ml/mageia-dev/2012-January/011418.html create mode 100644 zarb-ml/mageia-dev/2012-January/011419.html create mode 100644 zarb-ml/mageia-dev/2012-January/011420.html create mode 100644 zarb-ml/mageia-dev/2012-January/011421.html create mode 100644 zarb-ml/mageia-dev/2012-January/011422.html create mode 100644 zarb-ml/mageia-dev/2012-January/011423.html create mode 100644 zarb-ml/mageia-dev/2012-January/011424.html create mode 100644 zarb-ml/mageia-dev/2012-January/011425.html create mode 100644 zarb-ml/mageia-dev/2012-January/011426.html create mode 100644 zarb-ml/mageia-dev/2012-January/011427.html create mode 100644 zarb-ml/mageia-dev/2012-January/011428.html create mode 100644 zarb-ml/mageia-dev/2012-January/011429.html create mode 100644 zarb-ml/mageia-dev/2012-January/011430.html create mode 100644 zarb-ml/mageia-dev/2012-January/011431.html create mode 100644 zarb-ml/mageia-dev/2012-January/011432.html create mode 100644 zarb-ml/mageia-dev/2012-January/011433.html create mode 100644 zarb-ml/mageia-dev/2012-January/011434.html create mode 100644 zarb-ml/mageia-dev/2012-January/011435.html create mode 100644 zarb-ml/mageia-dev/2012-January/011436.html create mode 100644 zarb-ml/mageia-dev/2012-January/011437.html create mode 100644 zarb-ml/mageia-dev/2012-January/011438.html create mode 100644 zarb-ml/mageia-dev/2012-January/011439.html create mode 100644 zarb-ml/mageia-dev/2012-January/011440.html create mode 100644 zarb-ml/mageia-dev/2012-January/011441.html create mode 100644 zarb-ml/mageia-dev/2012-January/011442.html create mode 100644 zarb-ml/mageia-dev/2012-January/011443.html create mode 100644 zarb-ml/mageia-dev/2012-January/011444.html create mode 100644 zarb-ml/mageia-dev/2012-January/011445.html create mode 100644 zarb-ml/mageia-dev/2012-January/011446.html create mode 100644 zarb-ml/mageia-dev/2012-January/011447.html create mode 100644 zarb-ml/mageia-dev/2012-January/011448.html create mode 100644 zarb-ml/mageia-dev/2012-January/011449.html create mode 100644 zarb-ml/mageia-dev/2012-January/011450.html create mode 100644 zarb-ml/mageia-dev/2012-January/011451.html create mode 100644 zarb-ml/mageia-dev/2012-January/011452.html create mode 100644 zarb-ml/mageia-dev/2012-January/011453.html create mode 100644 zarb-ml/mageia-dev/2012-January/011454.html create mode 100644 zarb-ml/mageia-dev/2012-January/011455.html create mode 100644 zarb-ml/mageia-dev/2012-January/011456.html create mode 100644 zarb-ml/mageia-dev/2012-January/011457.html create mode 100644 zarb-ml/mageia-dev/2012-January/011458.html create mode 100644 zarb-ml/mageia-dev/2012-January/011459.html create mode 100644 zarb-ml/mageia-dev/2012-January/011460.html create mode 100644 zarb-ml/mageia-dev/2012-January/011461.html create mode 100644 zarb-ml/mageia-dev/2012-January/011462.html create mode 100644 zarb-ml/mageia-dev/2012-January/011463.html create mode 100644 zarb-ml/mageia-dev/2012-January/011464.html create mode 100644 zarb-ml/mageia-dev/2012-January/011465.html create mode 100644 zarb-ml/mageia-dev/2012-January/011466.html create mode 100644 zarb-ml/mageia-dev/2012-January/011467.html create mode 100644 zarb-ml/mageia-dev/2012-January/011468.html create mode 100644 zarb-ml/mageia-dev/2012-January/011469.html create mode 100644 zarb-ml/mageia-dev/2012-January/011470.html create mode 100644 zarb-ml/mageia-dev/2012-January/011471.html create mode 100644 zarb-ml/mageia-dev/2012-January/011472.html create mode 100644 zarb-ml/mageia-dev/2012-January/011473.html create mode 100644 zarb-ml/mageia-dev/2012-January/011474.html create mode 100644 zarb-ml/mageia-dev/2012-January/011475.html create mode 100644 zarb-ml/mageia-dev/2012-January/011476.html create mode 100644 zarb-ml/mageia-dev/2012-January/011477.html create mode 100644 zarb-ml/mageia-dev/2012-January/011478.html create mode 100644 zarb-ml/mageia-dev/2012-January/011479.html create mode 100644 zarb-ml/mageia-dev/2012-January/011480.html create mode 100644 zarb-ml/mageia-dev/2012-January/011481.html create mode 100644 zarb-ml/mageia-dev/2012-January/011482.html create mode 100644 zarb-ml/mageia-dev/2012-January/011483.html create mode 100644 zarb-ml/mageia-dev/2012-January/011484.html create mode 100644 zarb-ml/mageia-dev/2012-January/011485.html create mode 100644 zarb-ml/mageia-dev/2012-January/011486.html create mode 100644 zarb-ml/mageia-dev/2012-January/011487.html create mode 100644 zarb-ml/mageia-dev/2012-January/011488.html create mode 100644 zarb-ml/mageia-dev/2012-January/011489.html create mode 100644 zarb-ml/mageia-dev/2012-January/011490.html create mode 100644 zarb-ml/mageia-dev/2012-January/011491.html create mode 100644 zarb-ml/mageia-dev/2012-January/011492.html create mode 100644 zarb-ml/mageia-dev/2012-January/011493.html create mode 100644 zarb-ml/mageia-dev/2012-January/011494.html create mode 100644 zarb-ml/mageia-dev/2012-January/011495.html create mode 100644 zarb-ml/mageia-dev/2012-January/011496.html create mode 100644 zarb-ml/mageia-dev/2012-January/011497.html create mode 100644 zarb-ml/mageia-dev/2012-January/011498.html create mode 100644 zarb-ml/mageia-dev/2012-January/011499.html create mode 100644 zarb-ml/mageia-dev/2012-January/011500.html create mode 100644 zarb-ml/mageia-dev/2012-January/011501.html create mode 100644 zarb-ml/mageia-dev/2012-January/011502.html create mode 100644 zarb-ml/mageia-dev/2012-January/011503.html create mode 100644 zarb-ml/mageia-dev/2012-January/011504.html create mode 100644 zarb-ml/mageia-dev/2012-January/011505.html create mode 100644 zarb-ml/mageia-dev/2012-January/011506.html create mode 100644 zarb-ml/mageia-dev/2012-January/011507.html create mode 100644 zarb-ml/mageia-dev/2012-January/011508.html create mode 100644 zarb-ml/mageia-dev/2012-January/011509.html create mode 100644 zarb-ml/mageia-dev/2012-January/011510.html create mode 100644 zarb-ml/mageia-dev/2012-January/011511.html create mode 100644 zarb-ml/mageia-dev/2012-January/011512.html create mode 100644 zarb-ml/mageia-dev/2012-January/011513.html create mode 100644 zarb-ml/mageia-dev/2012-January/011514.html create mode 100644 zarb-ml/mageia-dev/2012-January/011515.html create mode 100644 zarb-ml/mageia-dev/2012-January/011516.html create mode 100644 zarb-ml/mageia-dev/2012-January/011517.html create mode 100644 zarb-ml/mageia-dev/2012-January/011518.html create mode 100644 zarb-ml/mageia-dev/2012-January/011519.html create mode 100644 zarb-ml/mageia-dev/2012-January/011520.html create mode 100644 zarb-ml/mageia-dev/2012-January/011521.html create mode 100644 zarb-ml/mageia-dev/2012-January/011522.html create mode 100644 zarb-ml/mageia-dev/2012-January/011523.html create mode 100644 zarb-ml/mageia-dev/2012-January/011524.html create mode 100644 zarb-ml/mageia-dev/2012-January/011525.html create mode 100644 zarb-ml/mageia-dev/2012-January/011526.html create mode 100644 zarb-ml/mageia-dev/2012-January/011527.html create mode 100644 zarb-ml/mageia-dev/2012-January/011528.html create mode 100644 zarb-ml/mageia-dev/2012-January/011529.html create mode 100644 zarb-ml/mageia-dev/2012-January/011530.html create mode 100644 zarb-ml/mageia-dev/2012-January/011531.html create mode 100644 zarb-ml/mageia-dev/2012-January/011532.html create mode 100644 zarb-ml/mageia-dev/2012-January/011533.html create mode 100644 zarb-ml/mageia-dev/2012-January/011534.html create mode 100644 zarb-ml/mageia-dev/2012-January/011535.html create mode 100644 zarb-ml/mageia-dev/2012-January/011536.html create mode 100644 zarb-ml/mageia-dev/2012-January/011537.html create mode 100644 zarb-ml/mageia-dev/2012-January/011538.html create mode 100644 zarb-ml/mageia-dev/2012-January/011539.html create mode 100644 zarb-ml/mageia-dev/2012-January/011540.html create mode 100644 zarb-ml/mageia-dev/2012-January/011541.html create mode 100644 zarb-ml/mageia-dev/2012-January/011542.html create mode 100644 zarb-ml/mageia-dev/2012-January/011543.html create mode 100644 zarb-ml/mageia-dev/2012-January/011544.html create mode 100644 zarb-ml/mageia-dev/2012-January/011545.html create mode 100644 zarb-ml/mageia-dev/2012-January/011546.html create mode 100644 zarb-ml/mageia-dev/2012-January/011547.html create mode 100644 zarb-ml/mageia-dev/2012-January/011548.html create mode 100644 zarb-ml/mageia-dev/2012-January/011549.html create mode 100644 zarb-ml/mageia-dev/2012-January/011550.html create mode 100644 zarb-ml/mageia-dev/2012-January/011551.html create mode 100644 zarb-ml/mageia-dev/2012-January/011552.html create mode 100644 zarb-ml/mageia-dev/2012-January/011553.html create mode 100644 zarb-ml/mageia-dev/2012-January/011554.html create mode 100644 zarb-ml/mageia-dev/2012-January/011555.html create mode 100644 zarb-ml/mageia-dev/2012-January/011556.html create mode 100644 zarb-ml/mageia-dev/2012-January/011557.html create mode 100644 zarb-ml/mageia-dev/2012-January/011558.html create mode 100644 zarb-ml/mageia-dev/2012-January/011559.html create mode 100644 zarb-ml/mageia-dev/2012-January/011560.html create mode 100644 zarb-ml/mageia-dev/2012-January/011561.html create mode 100644 zarb-ml/mageia-dev/2012-January/011562.html create mode 100644 zarb-ml/mageia-dev/2012-January/011563.html create mode 100644 zarb-ml/mageia-dev/2012-January/011564.html create mode 100644 zarb-ml/mageia-dev/2012-January/011565.html create mode 100644 zarb-ml/mageia-dev/2012-January/011566.html create mode 100644 zarb-ml/mageia-dev/2012-January/011567.html create mode 100644 zarb-ml/mageia-dev/2012-January/011568.html create mode 100644 zarb-ml/mageia-dev/2012-January/011569.html create mode 100644 zarb-ml/mageia-dev/2012-January/011570.html create mode 100644 zarb-ml/mageia-dev/2012-January/011571.html create mode 100644 zarb-ml/mageia-dev/2012-January/011572.html create mode 100644 zarb-ml/mageia-dev/2012-January/011573.html create mode 100644 zarb-ml/mageia-dev/2012-January/011574.html create mode 100644 zarb-ml/mageia-dev/2012-January/011575.html create mode 100644 zarb-ml/mageia-dev/2012-January/011576.html create mode 100644 zarb-ml/mageia-dev/2012-January/011577.html create mode 100644 zarb-ml/mageia-dev/2012-January/011578.html create mode 100644 zarb-ml/mageia-dev/2012-January/011579.html create mode 100644 zarb-ml/mageia-dev/2012-January/011580.html create mode 100644 zarb-ml/mageia-dev/2012-January/011581.html create mode 100644 zarb-ml/mageia-dev/2012-January/011582.html create mode 100644 zarb-ml/mageia-dev/2012-January/011583.html create mode 100644 zarb-ml/mageia-dev/2012-January/011584.html create mode 100644 zarb-ml/mageia-dev/2012-January/011585.html create mode 100644 zarb-ml/mageia-dev/2012-January/011586.html create mode 100644 zarb-ml/mageia-dev/2012-January/011587.html create mode 100644 zarb-ml/mageia-dev/2012-January/011588.html create mode 100644 zarb-ml/mageia-dev/2012-January/011589.html create mode 100644 zarb-ml/mageia-dev/2012-January/011590.html create mode 100644 zarb-ml/mageia-dev/2012-January/011591.html create mode 100644 zarb-ml/mageia-dev/2012-January/011592.html create mode 100644 zarb-ml/mageia-dev/2012-January/011593.html create mode 100644 zarb-ml/mageia-dev/2012-January/011594.html create mode 100644 zarb-ml/mageia-dev/2012-January/011595.html create mode 100644 zarb-ml/mageia-dev/2012-January/011596.html create mode 100644 zarb-ml/mageia-dev/2012-January/011597.html create mode 100644 zarb-ml/mageia-dev/2012-January/011598.html create mode 100644 zarb-ml/mageia-dev/2012-January/011599.html create mode 100644 zarb-ml/mageia-dev/2012-January/011600.html create mode 100644 zarb-ml/mageia-dev/2012-January/011601.html create mode 100644 zarb-ml/mageia-dev/2012-January/011602.html create mode 100644 zarb-ml/mageia-dev/2012-January/011603.html create mode 100644 zarb-ml/mageia-dev/2012-January/011604.html create mode 100644 zarb-ml/mageia-dev/2012-January/011605.html create mode 100644 zarb-ml/mageia-dev/2012-January/011606.html create mode 100644 zarb-ml/mageia-dev/2012-January/011607.html create mode 100644 zarb-ml/mageia-dev/2012-January/011608.html create mode 100644 zarb-ml/mageia-dev/2012-January/011609.html create mode 100644 zarb-ml/mageia-dev/2012-January/011610.html create mode 100644 zarb-ml/mageia-dev/2012-January/011611.html create mode 100644 zarb-ml/mageia-dev/2012-January/011612.html create mode 100644 zarb-ml/mageia-dev/2012-January/011613.html create mode 100644 zarb-ml/mageia-dev/2012-January/011614.html create mode 100644 zarb-ml/mageia-dev/2012-January/011615.html create mode 100644 zarb-ml/mageia-dev/2012-January/011616.html create mode 100644 zarb-ml/mageia-dev/2012-January/011617.html create mode 100644 zarb-ml/mageia-dev/2012-January/011618.html create mode 100644 zarb-ml/mageia-dev/2012-January/011619.html create mode 100644 zarb-ml/mageia-dev/2012-January/011620.html create mode 100644 zarb-ml/mageia-dev/2012-January/011621.html create mode 100644 zarb-ml/mageia-dev/2012-January/011622.html create mode 100644 zarb-ml/mageia-dev/2012-January/011623.html create mode 100644 zarb-ml/mageia-dev/2012-January/011624.html create mode 100644 zarb-ml/mageia-dev/2012-January/011625.html create mode 100644 zarb-ml/mageia-dev/2012-January/011626.html create mode 100644 zarb-ml/mageia-dev/2012-January/011627.html create mode 100644 zarb-ml/mageia-dev/2012-January/011628.html create mode 100644 zarb-ml/mageia-dev/2012-January/011629.html create mode 100644 zarb-ml/mageia-dev/2012-January/011630.html create mode 100644 zarb-ml/mageia-dev/2012-January/011631.html create mode 100644 zarb-ml/mageia-dev/2012-January/011632.html create mode 100644 zarb-ml/mageia-dev/2012-January/011633.html create mode 100644 zarb-ml/mageia-dev/2012-January/011634.html create mode 100644 zarb-ml/mageia-dev/2012-January/011635.html create mode 100644 zarb-ml/mageia-dev/2012-January/011636.html create mode 100644 zarb-ml/mageia-dev/2012-January/011637.html create mode 100644 zarb-ml/mageia-dev/2012-January/011638.html create mode 100644 zarb-ml/mageia-dev/2012-January/011639.html create mode 100644 zarb-ml/mageia-dev/2012-January/011640.html create mode 100644 zarb-ml/mageia-dev/2012-January/011641.html create mode 100644 zarb-ml/mageia-dev/2012-January/011642.html create mode 100644 zarb-ml/mageia-dev/2012-January/011643.html create mode 100644 zarb-ml/mageia-dev/2012-January/011644.html create mode 100644 zarb-ml/mageia-dev/2012-January/011645.html create mode 100644 zarb-ml/mageia-dev/2012-January/011646.html create mode 100644 zarb-ml/mageia-dev/2012-January/011647.html create mode 100644 zarb-ml/mageia-dev/2012-January/011648.html create mode 100644 zarb-ml/mageia-dev/2012-January/011649.html create mode 100644 zarb-ml/mageia-dev/2012-January/011650.html create mode 100644 zarb-ml/mageia-dev/2012-January/011651.html create mode 100644 zarb-ml/mageia-dev/2012-January/011652.html create mode 100644 zarb-ml/mageia-dev/2012-January/011653.html create mode 100644 zarb-ml/mageia-dev/2012-January/011654.html create mode 100644 zarb-ml/mageia-dev/2012-January/011655.html create mode 100644 zarb-ml/mageia-dev/2012-January/011656.html create mode 100644 zarb-ml/mageia-dev/2012-January/011657.html create mode 100644 zarb-ml/mageia-dev/2012-January/011658.html create mode 100644 zarb-ml/mageia-dev/2012-January/011659.html create mode 100644 zarb-ml/mageia-dev/2012-January/011660.html create mode 100644 zarb-ml/mageia-dev/2012-January/011661.html create mode 100644 zarb-ml/mageia-dev/2012-January/011662.html create mode 100644 zarb-ml/mageia-dev/2012-January/011663.html create mode 100644 zarb-ml/mageia-dev/2012-January/011664.html create mode 100644 zarb-ml/mageia-dev/2012-January/011665.html create mode 100644 zarb-ml/mageia-dev/2012-January/011666.html create mode 100644 zarb-ml/mageia-dev/2012-January/011667.html create mode 100644 zarb-ml/mageia-dev/2012-January/011668.html create mode 100644 zarb-ml/mageia-dev/2012-January/011669.html create mode 100644 zarb-ml/mageia-dev/2012-January/011670.html create mode 100644 zarb-ml/mageia-dev/2012-January/011671.html create mode 100644 zarb-ml/mageia-dev/2012-January/011672.html create mode 100644 zarb-ml/mageia-dev/2012-January/011673.html create mode 100644 zarb-ml/mageia-dev/2012-January/011674.html create mode 100644 zarb-ml/mageia-dev/2012-January/011675.html create mode 100644 zarb-ml/mageia-dev/2012-January/011676.html create mode 100644 zarb-ml/mageia-dev/2012-January/011677.html create mode 100644 zarb-ml/mageia-dev/2012-January/011678.html create mode 100644 zarb-ml/mageia-dev/2012-January/011679.html create mode 100644 zarb-ml/mageia-dev/2012-January/011680.html create mode 100644 zarb-ml/mageia-dev/2012-January/011681.html create mode 100644 zarb-ml/mageia-dev/2012-January/author.html create mode 100644 zarb-ml/mageia-dev/2012-January/date.html create mode 120000 zarb-ml/mageia-dev/2012-January/index.html create mode 100644 zarb-ml/mageia-dev/2012-January/subject.html create mode 100644 zarb-ml/mageia-dev/2012-January/thread.html (limited to 'zarb-ml/mageia-dev/2012-January') diff --git a/zarb-ml/mageia-dev/2012-January/010849.html b/zarb-ml/mageia-dev/2012-January/010849.html new file mode 100644 index 000000000..2738a8e8d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010849.html @@ -0,0 +1,68 @@ + + + + [Mageia-dev] mentors + apprentices + + + + + + + + + +

[Mageia-dev] mentors + apprentices

+ Josh King + josh at linuxpunks.com +
+ Sun Jan 1 03:11:30 CET 2012 +

+
+ +
On 12/31/2011 02:29 AM, andre999 wrote:
+> Florian Hubold a écrit :
+>> According to
+>> https://wiki.mageia.org/en/Becoming_a_Mageia_Packager#Mentoring_team
+>> he is already mentored by guillomovitch, or is that incorrect?
+>>
+> sorry I overlooked that, from many months back -- he didn't start due to
+> health problems, which are over now
+>
+So should I begin working with guillomovitch, or someone else? Sorry for 
+the sort of OT post just wanted to make sure.
+
+Josh
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010850.html b/zarb-ml/mageia-dev/2012-January/010850.html new file mode 100644 index 000000000..7ee499261 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010850.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] packaging savoir-vivre + + + + + + + + + +

[Mageia-dev] packaging savoir-vivre

+ Maarten Vanraes + alien at rmail.be +
+ Sun Jan 1 03:29:07 CET 2012 +

+
+ +
Op zaterdag 31 december 2011 18:42:22 schreef nicolas vigier:
+> On Wed, 28 Dec 2011, Maarten Vanraes wrote:
+> > imho the best solution is that everyone checks if there's a maintainer
+> > for it and asks maintainer first...
+> > 
+> > i mean, it's all nice that it's in the spec file, but i think people who
+> > bump, rarely look inside spec file... (not saying any names)
+> 
+> So you think people who don't take the time to look at spec file before
+> submiting something will want to take the time to ask maintainer ?
+> 
+> It's a good idea to ask maintainer before making important or possibly
+> controversial changes, but for simple or obvious changes it's not really
+> needed. In that case, if for some reason a package should not be
+> submited, it's a good idea to add a comment in the spec file. It's also
+> a good idea to check the diff between current and pristine before
+> submiting a package.
+
+and also a good idea to check if a package has a maintainer and at the very 
+least notify him/her.
+
+- if (s)he makes mistakes, that's already useful
+- but what's more, you could indeed be making some changes, which could be 
+ignored.
+
+i don't know about you, but if there's a problem i have the fix for for a 
+package that's maintained by others, i think it's good form to notify them 
+with the patch so that they can do it; if they don't, you still can.
+
+unless it's really urgent that you fix this now... i don't see the need/reason 
+to just bypass the maintainer completely. (unless you have an understanding 
+with said maintainer; then, it's a different thing)
+
+the changes you make to his/her package, (s)he has to maintain and get bugfixes 
+for...
+
+imho this is no more than just common politeness...
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010851.html b/zarb-ml/mageia-dev/2012-January/010851.html new file mode 100644 index 000000000..b61076727 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010851.html @@ -0,0 +1,118 @@ + + + + [Mageia-dev] mentors + apprentices + + + + + + + + + +

[Mageia-dev] mentors + apprentices

+ andre999 + andre999mga at laposte.net +
+ Sun Jan 1 03:32:44 CET 2012 +

+
+ +
Hi everyone,
+
+Happy new year, and I hope that everyone has made a resolution to help Mageia 
+to be a better distro.
+So qualified packagers, if you haven't already, would you like to mentor one of 
+our eager apprentice candidates ?
+
+Since my last notice, we have another apprentice candidate, giving a total of 5 
+looking for a mentor.
+
+am2605 (Andrew Myers), who has been waiting now for a month.
+He is a longtime Fedora, a web developer, interested in packaging related to 
+Gnome, Java, Eclipse among others, teaching himself Mageia packaging basics.
+
+cddesjar (Christopher Desjardins),
+who has basic .deb and .rpm packaging experience, including doing texworks and 
+jags on Mageia for himself.  Would like to maintain these and R-base.
+
+dotmil (Josh King),
+who has professional experience with web apps and infrastructure and systems 
+level apps, and would like to work on similar packages for Mageia.  Open to 
+helping where needed.  Previous .deb packaging experience.
+
+luigiwalser (David Walser),
+who was a Mandrake packager (before the current build system), currently 
+working as a Linux instructor and sysadmin, interested in importing some 
+packages to Mageia that he uses.
+
+dglent (Dimitrios Glentadakis),
+who has experience packaging in his personal repos (mageia-gr.org and 
+previously mandrivalinux.gr) with applications he uses, which he would like to 
+package for Mageia repos.
+
+You can find more details at:
+https://wiki.mageia.org/en/Becoming_a_Mageia_Packager#Packager_apprentice_candidates
+
+Mentors, let me know who you take on, and I'll update the tables for you.
+
+Thanks :-)
+
+----
+
+Anyone else looking for a mentor, let me know so I can add your name as an 
+apprentice candidate -- or you can do it yourself.
+https://wiki.mageia.org/en/Becoming_a_Mageia_Packager#Packager_apprentice_candidates 
+
+
+See also the previous sections, on becoming a Mageia packager :
+https://wiki.mageia.org/mw-en/index.php?title=Becoming_a_Mageia_Packager&action=submit#What_is_needed_to_become_a_Mageia_packager
+
+To find a mentor, it helps to also post to this list (mageia-dev), or hang out 
+on IRC at freenode #mageia-mentoring.
+
+Regards :-)
+
+-- 
+André
+(Packager mentoring program coordinator)
+
+
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010852.html b/zarb-ml/mageia-dev/2012-January/010852.html new file mode 100644 index 000000000..eb7b9f7fb --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010852.html @@ -0,0 +1,79 @@ + + + + [Mageia-dev] rebuilding other's packages + + + + + + + + + +

[Mageia-dev] rebuilding other's packages

+ andre999 + andre999mga at laposte.net +
+ Sun Jan 1 04:23:00 CET 2012 +

+
+ +
Olav Vitters a écrit :
+> FWIW, I love when people rebuild my packages. And no need to inform.
+>    
+
+Me too :)
+Although it is a good courtesy to inform the maintainer.
+> Maybe we could enhance the buildsystem to BCC the maintainer in case:
+> 1. there is a maintainer
+> 2. submitter isn't the maintainer
+>
+> Though can understand you want to know up front, this at least ensures
+> there is some visibility. Agree? (RFE in order...)
+>
+>    
++1
+
+-- 
+André
+
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010853.html b/zarb-ml/mageia-dev/2012-January/010853.html new file mode 100644 index 000000000..082137506 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010853.html @@ -0,0 +1,72 @@ + + + + [Mageia-dev] mentors + apprentices + + + + + + + + + +

[Mageia-dev] mentors + apprentices

+ David Walser + luigiwalser at yahoo.com +
+ Sun Jan 1 10:01:09 CET 2012 +

+
+ +
andre999 wrote:
+> Hi everyone,
+> 
+> Happy new year, and I hope that everyone has made a resolution to help Mageia 
+> to be a better distro.
+> So qualified packagers, if you haven't already, would you like to mentor one of 
+> our eager apprentice candidates ?
+> 
+> luigiwalser (David Walser),
+> who was a Mandrake packager (before the current build system), currently 
+> working as a Linux instructor and sysadmin, interested in importing some 
+> packages to Mageia that he uses.
+
+dmorgan has adopted me :D
+
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010854.html b/zarb-ml/mageia-dev/2012-January/010854.html new file mode 100644 index 000000000..4a472c2a1 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010854.html @@ -0,0 +1,67 @@ + + + + [Mageia-dev] mentors + apprentices + + + + + + + + + +

[Mageia-dev] mentors + apprentices

+ John Balcaen + mikala at mageia.org +
+ Sun Jan 1 14:42:55 CET 2012 +

+
+ +
2012/1/1 David Walser <luigiwalser at yahoo.com>:
+[...]
+> dmorgan has adopted me :D
+Prepare yourself to eat a lof of thoses java's stuff :p
+
+
+
+-- 
+Balcaen John
+Jabber-id: mikala at jabber.littleboboy.net
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010855.html b/zarb-ml/mageia-dev/2012-January/010855.html new file mode 100644 index 000000000..b32e98b5b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010855.html @@ -0,0 +1,77 @@ + + + + [Mageia-dev] Wrong submission of antico-0.2-0.git.1.%{1}.mga2 + + + + + + + + + +

[Mageia-dev] Wrong submission of antico-0.2-0.git.1.%{1}.mga2

+ Matteo + pasotti.matteo at gmail.com +
+ Sun Jan 1 15:00:43 CET 2012 +

+
+ +
-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
+Can someone remove this job/package? Who can I ask in these cases?
+Regards
+- -- 
+Matteo
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.11 (GNU/Linux)
+Comment: Using GnuPG with Mageia - http://enigmail.mozdev.org/
+
+iQEcBAEBAgAGBQJPAGcIAAoJED3LowjDDWbNpK8H/1t6ELuQ6xpI/wJdcr4bYhtg
+3XvMScg79n94COeqZ0cpbO4hZtX2QaZlT7iRgSJVnbyZ+ySWnYqlLHzV8EmCmrrV
+4QkYgSMDJ2X0VEQ8I6xPOIBD8JA2jIEinDY37T3KdYq6XnlcXDyEP+t6KX/Nl0Pd
+nSciXhINyCVTgly1D/DqQofqhg8pe8VQFywqbProi4RgPVsXOxSOx+sFZNwXN8Cr
+SaJiPVql6k+jdrtEROTL6a/kRP/pbbtra9ZkTFGMLX85tnxZ0tci4BlbSlMTzKgD
+VqpVcDVKvelZjCmpDPb+NeTQFmNeGO3oDEhktmsOyy4CygHj1rCzwnQUL3Gja5U=
+=0XO0
+-----END PGP SIGNATURE-----
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010856.html b/zarb-ml/mageia-dev/2012-January/010856.html new file mode 100644 index 000000000..9cfebda61 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010856.html @@ -0,0 +1,69 @@ + + + + [Mageia-dev] mentors + apprentices + + + + + + + + + +

[Mageia-dev] mentors + apprentices

+ Manuel Hiebel + manuel at hiebel.eu +
+ Sun Jan 1 16:04:27 CET 2012 +

+
+ +
Le dimanche 01 janvier 2012 à 10:42 -0300, John Balcaen a écrit :
+> 2012/1/1 David Walser <luigiwalser at yahoo.com>:
+> [...]
+> > dmorgan has adopted me :D
+> Prepare yourself to eat a lof of thoses java's stuff :p
+>
+And if you don't like java's stuff, we have easyfix bugs
+https://bugs.mageia.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=Junior_job_no_new_packages&sharer_id=446
+https://bugs.mageia.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=patches&sharer_id=81
+
+(By the way, anyone can take any bug that is not with the assigned
+status, so 1350, as only 123 are in this state)
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010857.html b/zarb-ml/mageia-dev/2012-January/010857.html new file mode 100644 index 000000000..dfb60b03c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010857.html @@ -0,0 +1,68 @@ + + + + [Mageia-dev] Wrong submission of antico-0.2-0.git.1.%{1}.mga2 + + + + + + + + + +

[Mageia-dev] Wrong submission of antico-0.2-0.git.1.%{1}.mga2

+ Balcaen John + mikala at mageia.org +
+ Sun Jan 1 16:32:12 CET 2012 +

+
+ +
On Sunday 01 January 2012 15:00:43 Matteo wrote :
+> 
+> Can someone remove this job/package? Who can I ask in these cases?
+It should be rejected by rpmlint on upload for unexpanded macro.
+
+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/2012-January/010858.html b/zarb-ml/mageia-dev/2012-January/010858.html new file mode 100644 index 000000000..4f2e712f7 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010858.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] dracut problem + + + + + + + + + +

[Mageia-dev] dracut problem

+ Thibaut FRANCOIS + thibautf at gmail.com +
+ Sun Jan 1 16:50:39 CET 2012 +

+
+ +
Well, I don't know because after try to configure the display with drakex
+and a reboot, the display is now right.
+I try this argument if the problem occurs again.
+
+Thanks and happy new year :)
+
+Thibaut
+
+2011/12/29 Colin Guthrie <mageia at colin.guthr.ie>
+
+> 'Twas brillig, and Thibaut FRANCOIS at 29/12/11 14:36 did gyre and gimble:
+> > Thanks Colin, that fixes it for me. I have again a problem with the last
+> > kernel and nvidia module, but with the kernel 3.1.4 it's ok.
+>
+> Does the "nokmsboot" argument not help here?
+>
+> Col
+>
+> --
+>
+> Colin Guthrie
+> colin(at)mageia.org
+> http://colin.guthr.ie/
+>
+> Day Job:
+>  Tribalogic Limited http://www.tribalogic.net/
+> Open Source:
+>  Mageia Contributor http://www.mageia.org/
+>  PulseAudio Hacker http://www.pulseaudio.org/
+>  Trac Hacker http://trac.edgewall.org/
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20120101/ae0c3a6e/attachment.html>
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010859.html b/zarb-ml/mageia-dev/2012-January/010859.html new file mode 100644 index 000000000..e657d283a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010859.html @@ -0,0 +1,75 @@ + + + + [Mageia-dev] rpmlint + + + + + + + + + +

[Mageia-dev] rpmlint

+ Pascal Terjan + pterjan at gmail.com +
+ Sun Jan 1 16:58:43 CET 2012 +

+
+ +
On Sat, Dec 31, 2011 at 14:28, Olivier Blin <mageia at blino.org> wrote:
+> Florian Hubold <doktor5000 at arcor.de> writes:
+>
+>> Am 31.12.2011 14:26, schrieb Johnny A. Solbu:
+>>> On Saturday 31 December 2011 11:34, Matteo wrote:
+>>>>> Install rpmlint-mageia-policy.
+>>>> Yeap, my fault (I rebuilt my vm and I missed this package).
+>>> Is it an idea to have rpmlint-mageia-policy added as a suggested package in rpmlint?
+>>> Then packagers who forget to install it when (re)installing rpmlint will get a small notice that they are missing this pakcage.
+>>>
+>> IIRC misc is against that, especially in the form of suggests.
+>
+> Then we could add it as a require in rpmbuild, if misc wants to keep
+> our rpmlint package untouched.
+
+It would make sense to me.
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010860.html b/zarb-ml/mageia-dev/2012-January/010860.html new file mode 100644 index 000000000..5828eaa22 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010860.html @@ -0,0 +1,78 @@ + + + + [Mageia-dev] rpmlint + + + + + + + + + +

[Mageia-dev] rpmlint

+ Pascal Terjan + pterjan at gmail.com +
+ Sun Jan 1 16:59:50 CET 2012 +

+
+ +
On Sun, Jan 1, 2012 at 15:58, Pascal Terjan <pterjan at gmail.com> wrote:
+> On Sat, Dec 31, 2011 at 14:28, Olivier Blin <mageia at blino.org> wrote:
+>> Florian Hubold <doktor5000 at arcor.de> writes:
+>>
+>>> Am 31.12.2011 14:26, schrieb Johnny A. Solbu:
+>>>> On Saturday 31 December 2011 11:34, Matteo wrote:
+>>>>>> Install rpmlint-mageia-policy.
+>>>>> Yeap, my fault (I rebuilt my vm and I missed this package).
+>>>> Is it an idea to have rpmlint-mageia-policy added as a suggested package in rpmlint?
+>>>> Then packagers who forget to install it when (re)installing rpmlint will get a small notice that they are missing this pakcage.
+>>>>
+>>> IIRC misc is against that, especially in the form of suggests.
+>>
+>> Then we could add it as a require in rpmbuild, if misc wants to keep
+>> our rpmlint package untouched.
+>
+> It would make sense to me.
+
+Actually, what about rpm-mageia-setup-build ?
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010861.html b/zarb-ml/mageia-dev/2012-January/010861.html new file mode 100644 index 000000000..ca361d37f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010861.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] [packages-commits] [188982] fixed desktop file patch + + + + + + + + + +

[Mageia-dev] [packages-commits] [188982] fixed desktop file patch

+ Angelo Naselli + anaselli at linux.it +
+ Sun Jan 1 18:14:23 CET 2012 +

+
+ +
> > > Install rpmlint-mageia-policy.
+> > 
+> > It should probably be suggested by rpmlint, we want Mageia policy
+> > applied by default.
+> > 
+> > Michael, any objection?
+> 
+> I guess it should be removed upstream, since no one use this check
+> anymore ( ie, fedora policy is against, mandriva policy is against, our
+> is against ). I will check with suse, but I think they also don't
+> compress patchs.
+> 
+> So it make sense to silence it directly there, instead of filtering
+> everywhere.
+I think you're right about patch compression, but i think you should
+also answer to the subject concerning rpmlint-mageia-policy installation
+(required, sugested etc...)
+
+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/20120101/deb92cbc/attachment.asc>
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010862.html b/zarb-ml/mageia-dev/2012-January/010862.html new file mode 100644 index 000000000..b9f44049d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010862.html @@ -0,0 +1,67 @@ + + + + [Mageia-dev] Wrong submission of antico-0.2-0.git.1.%{1}.mga2 + + + + + + + + + +

[Mageia-dev] Wrong submission of antico-0.2-0.git.1.%{1}.mga2

+ Florian Hubold + doktor5000 at arcor.de +
+ Sun Jan 1 19:07:20 CET 2012 +

+
+ +
Am 01.01.2012 16:32, schrieb Balcaen John:
+> On Sunday 01 January 2012 15:00:43 Matteo wrote :
+>> Can someone remove this job/package? Who can I ask in these cases?
+> It should be rejected by rpmlint on upload for unexpanded macro.
+>
+> Regards,
+>
+Not rejected, but failure:
+http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20120101135744.matteo.valstar.18171/
+AFAICS it fails when copying the src.rpm around
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010863.html b/zarb-ml/mageia-dev/2012-January/010863.html new file mode 100644 index 000000000..73df6069d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010863.html @@ -0,0 +1,77 @@ + + + + [Mageia-dev] Wrong submission of antico-0.2-0.git.1.%{1}.mga2 + + + + + + + + + +

[Mageia-dev] Wrong submission of antico-0.2-0.git.1.%{1}.mga2

+ Balcaen John + mikala at mageia.org +
+ Sun Jan 1 19:16:58 CET 2012 +

+
+ +
On Sunday 01 January 2012 19:07:20 Florian Hubold wrote :
+> Am 01.01.2012 16:32, schrieb Balcaen John:
+> > On Sunday 01 January 2012 15:00:43 Matteo wrote :
+> >> Can someone remove this job/package? Who can I ask in these cases?
+> > 
+> > It should be rejected by rpmlint on upload for unexpanded macro.
+> > 
+> > Regards,
+> 
+> Not rejected, but failure:
+> http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/2012010113
+> 5744.matteo.valstar.18171/ AFAICS it fails when copying the src.rpm around
+
+If the build was a success (everything can happens :p ), it would has been 
+rejected by rpmlint during upload for unexpanded macro.
+
+
+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/2012-January/010864.html b/zarb-ml/mageia-dev/2012-January/010864.html new file mode 100644 index 000000000..2901f5dbf --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010864.html @@ -0,0 +1,76 @@ + + + + [Mageia-dev] Help with wally package on the BS + + + + + + + + + +

[Mageia-dev] Help with wally package on the BS

+ Juan Luis Baptiste + juancho at mageia.org +
+ Sun Jan 1 22:46:55 CET 2012 +

+
+ +
Hi,
+
+I'm having some trouble getting a new package called wally built on
+the BS. Locally it builds fine but on the cluster it doesn't find the
+generated files by the application:
+
+http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20120101164304.juancho.valstar.24149/log/botcmd.1325436242.jonund.log
+
+I started using KDE macros (hence the kde4-macros BR) but removed all
+of them trying to fix the problem, I dunno what to do now.
+
+Any hints ?
+
+Thanks,
+
+-- 
+Juancho
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010865.html b/zarb-ml/mageia-dev/2012-January/010865.html new file mode 100644 index 000000000..10d4bf7f2 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010865.html @@ -0,0 +1,79 @@ + + + + [Mageia-dev] Help with wally package on the BS + + + + + + + + + +

[Mageia-dev] Help with wally package on the BS

+ Anssi Hannula + anssi at mageia.org +
+ Sun Jan 1 23:13:47 CET 2012 +

+
+ +
On 01.01.2012 23:46, Juan Luis Baptiste wrote:
+> Hi,
+> 
+> I'm having some trouble getting a new package called wally built on
+> the BS. Locally it builds fine but on the cluster it doesn't find the
+> generated files by the application:
+> 
+> http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20120101164304.juancho.valstar.24149/log/botcmd.1325436242.jonund.log
+> 
+> I started using KDE macros (hence the kde4-macros BR) but removed all
+> of them trying to fix the problem, I dunno what to do now.
+> 
+> Any hints ?
+
+Missing buildrequire => KDE stuff not built.
+
+(just a guess based on the above log)
+
+-- 
+Anssi Hannula
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010866.html b/zarb-ml/mageia-dev/2012-January/010866.html new file mode 100644 index 000000000..dca8bf9b8 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010866.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] Help with wally package on the BS + + + + + + + + + +

[Mageia-dev] Help with wally package on the BS

+ Balcaen John + mikala at mageia.org +
+ Mon Jan 2 01:38:39 CET 2012 +

+
+ +
On Sunday 01 January 2012 16:46:55 Juan Luis Baptiste wrote :
+> Hi,
+> 
+> I'm having some trouble getting a new package called wally built on
+> the BS. Locally it builds fine but on the cluster it doesn't find the
+> generated files by the application:
+> 
+> http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/2012010116
+> 4304.juancho.valstar.24149/log/botcmd.1325436242.jonund.log
+> 
+> I started using KDE macros (hence the kde4-macros BR) but removed all
+> of them trying to fix the problem, I dunno what to do now.
+> 
+> Any hints ?
+Wrong files list :
+    File not found by glob: 
+/home/iurt/rpm/BUILDROOT/wally-2.4.4-1.mga2.x86_64/usr/lib64/kde4/*
+    File not found: 
+/home/iurt/rpm/BUILDROOT/wally-2.4.4-1.mga2.x86_64/usr/share/icons/oxygen/16x16/apps/wallyplugin.png
+    File not found: 
+/home/iurt/rpm/BUILDROOT/wally-2.4.4-1.mga2.x86_64/usr/share/kde4/services/plasma-
+wallpaper-wallyplugin.desktop
+
+If you want to install the kde part (wallyplugin subpackage)  you need to have 
+kdelibs4-devel as BR (which is going to install the wallyplugins.png , plasma-
+wallpaper-wallyplugin.desktop & plasma_wallpaper_wallyplugin.so)
+Of course if you add this you'll should also use kde4_macros for this part of 
+the spec.
+
+Of course if you want to get ride of kde's dependency you just need to have to 
+fix the file list.
+
+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/2012-January/010867.html b/zarb-ml/mageia-dev/2012-January/010867.html new file mode 100644 index 000000000..0fa5b7e1f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010867.html @@ -0,0 +1,77 @@ + + + + [Mageia-dev] Help with wally package on the BS + + + + + + + + + +

[Mageia-dev] Help with wally package on the BS

+ Juan Luis Baptiste + juancho at mageia.org +
+ Mon Jan 2 02:27:51 CET 2012 +

+
+ +
On Sun, Jan 1, 2012 at 7:38 PM, Balcaen John <mikala at mageia.org> wrote:
+> If you want to install the kde part (wallyplugin subpackage)  you need to have
+> kdelibs4-devel as BR (which is going to install the wallyplugins.png , plasma-
+> wallpaper-wallyplugin.desktop & plasma_wallpaper_wallyplugin.so)
+> Of course if you add this you'll should also use kde4_macros for this part of
+> the spec.
+>
+
+Thanks, that was the problem !!
+
+But I still don't get why kdelibs4-devel is required ? I mean why
+those files can't install without it ? as I see it, the list of files
+is fine on the spec, it is the same as in the error... can you care to
+explain a little ? :)
+
+
+-- 
+Juancho
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010868.html b/zarb-ml/mageia-dev/2012-January/010868.html new file mode 100644 index 000000000..246280fd1 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010868.html @@ -0,0 +1,78 @@ + + + + [Mageia-dev] Help with wally package on the BS + + + + + + + + + +

[Mageia-dev] Help with wally package on the BS

+ John Balcaen + mikala at mageia.org +
+ Mon Jan 2 03:01:17 CET 2012 +

+
+ +
Le dimanche 1 janvier 2012, Juan Luis Baptiste <juancho at mageia.org> a
+écrit :
+
+> Thanks, that was the problem !!
+>
+> But I still don't get why kdelibs4-devel is required ? I mean why
+> those files can't install without it ? as I see it, the list of files
+> is fine on the spec, it is the same as in the error... can you care to
+> explain a little ? :)
+Simply because there is a kde4 plugin, so CmakeList check the kde4 prefix
+but also links against kdelibs.Simply check the CmakeList to have more
+detail .
+
+-- 
+Balcaen John
+Jabber-id: mikala at jabber.littleboboy.net
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20120101/91bca2a8/attachment.html>
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010869.html b/zarb-ml/mageia-dev/2012-January/010869.html new file mode 100644 index 000000000..553ae117c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010869.html @@ -0,0 +1,78 @@ + + + + [Mageia-dev] Help with wally package on the BS + + + + + + + + + +

[Mageia-dev] Help with wally package on the BS

+ Juan Luis Baptiste + juancho at mageia.org +
+ Mon Jan 2 04:15:40 CET 2012 +

+
+ +
On Jan 1, 2012 9:01 PM, "John Balcaen" <mikala at mageia.org> wrot
+> >
+> > But I still don't get why kdelibs4-devel is required ? I mean why
+> > those files can't install without it ? as I see it, the list of files
+> > is fine on the spec, it is the same as in the error... can you care to
+> > explain a little ? :)
+> Simply because there is a kde4 plugin, so CmakeList check the kde4 prefix
+but also links against kdelibs.Simply check the CmakeList to have more
+detail .
+
+Ahh ok, I'll have that in mind next time  :)
+
+
+Cheers,
+
+Juancho
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20120101/45024cc2/attachment.html>
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010870.html b/zarb-ml/mageia-dev/2012-January/010870.html new file mode 100644 index 000000000..3567ea92e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010870.html @@ -0,0 +1,72 @@ + + + + [Mageia-dev] GNOME 2 panel applets + + + + + + + + + +

[Mageia-dev] GNOME 2 panel applets

+ Olav Vitters + olav at vitters.nl +
+ Mon Jan 2 10:12:08 CET 2012 +

+
+ +
In https://bugs.mageia.org/show_bug.cgi?id=1133, the reporter is asking
+to add dockbarx, a panel applet for GNOME 2.
+
+Being involved with GNOME, in my opinion this is a WONTFIX. There is no
+GNOME 2 in Mageia, and GNOME 3 fallback mode might go away, plus the
+panel API changed slightly (because it uses dbus now instead of bonobo).
+
+No clue if dockbarx works with fallback mode btw.
+
+What do others think?
+-- 
+Regards,
+Olav
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010871.html b/zarb-ml/mageia-dev/2012-January/010871.html new file mode 100644 index 000000000..65611531c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010871.html @@ -0,0 +1,77 @@ + + + + [Mageia-dev] GNOME 2 panel applets + + + + + + + + + +

[Mageia-dev] GNOME 2 panel applets

+ Balcaen John + mikala at mageia.org +
+ Mon Jan 2 10:53:54 CET 2012 +

+
+ +
On Monday 02 January 2012 10:12:08 Olav Vitters wrote :
+> In https://bugs.mageia.org/show_bug.cgi?id=1133, the reporter is asking
+> to add dockbarx, a panel applet for GNOME 2.
+> 
+> Being involved with GNOME, in my opinion this is a WONTFIX. There is no
+> GNOME 2 in Mageia, and GNOME 3 fallback mode might go away, plus the
+> panel API changed slightly (because it uses dbus now instead of bonobo).
+> 
+> No clue if dockbarx works with fallback mode btw.
+> 
+> What do others think?
+WONTFIX is a good 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/2012-January/010872.html b/zarb-ml/mageia-dev/2012-January/010872.html new file mode 100644 index 000000000..ef9eca9cf --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010872.html @@ -0,0 +1,71 @@ + + + + [Mageia-dev] GNOME 2 panel applets + + + + + + + + + +

[Mageia-dev] GNOME 2 panel applets

+ Kamil Rytarowski + n54 at gmx.com +
+ Mon Jan 2 11:37:55 CET 2012 +

+
+ +
W dniu 02.01.2012 10:12, Olav Vitters pisze:
+> In https://bugs.mageia.org/show_bug.cgi?id=1133, the reporter is asking
+> to add dockbarx, a panel applet for GNOME 2.
+>
+> Being involved with GNOME, in my opinion this is a WONTFIX. There is no
+> GNOME 2 in Mageia, and GNOME 3 fallback mode might go away, plus the
+> panel API changed slightly (because it uses dbus now instead of bonobo).
+>
+> No clue if dockbarx works with fallback mode btw.
+>
+> What do others think?
+If deskbar is not imported, then other Gnome2 only stuff shouldn't too.
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010873.html b/zarb-ml/mageia-dev/2012-January/010873.html new file mode 100644 index 000000000..9f842e670 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010873.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] [packages-commits] [188982] fixed desktop file patch + + + + + + + + + +

[Mageia-dev] [packages-commits] [188982] fixed desktop file patch

+ Michael Scherer + misc at zarb.org +
+ Mon Jan 2 11:40:47 CET 2012 +

+
+ +
Le dimanche 01 janvier 2012 à 18:14 +0100, Angelo Naselli a écrit :
+> > > > Install rpmlint-mageia-policy.
+> > > 
+> > > It should probably be suggested by rpmlint, we want Mageia policy
+> > > applied by default.
+> > > 
+> > > Michael, any objection?
+> > 
+> > I guess it should be removed upstream, since no one use this check
+> > anymore ( ie, fedora policy is against, mandriva policy is against, our
+> > is against ). I will check with suse, but I think they also don't
+> > compress patchs.
+> > 
+> > So it make sense to silence it directly there, instead of filtering
+> > everywhere.
+> I think you're right about patch compression, but i think you should
+> also answer to the subject concerning rpmlint-mageia-policy installation
+> (required, sugested etc...)
+
+I answered several time by the past, but I guess I can repeat myself
+once again :
+- no suggest , they are unspecified, and causing problem ( like not
+working for people that disable them, and bloating installation for
+everybody else , and just giving no useful information for people to
+decide to install or not )
+
+- no requires from rpmlint on policy, since people have been asking to
+be able to use different policy ( and since rpmlint is already required
+by policy, that would make a loop and I would like to avoid that ).
+
+-- 
+Michael Scherer
+
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010874.html b/zarb-ml/mageia-dev/2012-January/010874.html new file mode 100644 index 000000000..0a4291543 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010874.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] GNOME 2 panel applets + + + + + + + + + +

[Mageia-dev] GNOME 2 panel applets

+ andre999 + andre999mga at laposte.net +
+ Mon Jan 2 12:05:34 CET 2012 +

+
+ +
Olav Vitters a écrit :
+> Inhttps://bugs.mageia.org/show_bug.cgi?id=1133, the reporter is asking
+> to add dockbarx, a panel applet for GNOME 2.
+>
+> Being involved with GNOME, in my opinion this is a WONTFIX. There is no
+> GNOME 2 in Mageia, and GNOME 3 fallback mode might go away, plus the
+> panel API changed slightly (because it uses dbus now instead of bonobo).
+>
+> No clue if dockbarx works with fallback mode btw.
+>    
+
+Some users report that it does, both in gnome-panel and standalone mode.
+> What do others think?
+>    
+
+My first reaction was, being a Gnome user myself, that if everything is 
+as stated, I tend to agree.
+But following the links, as well as working under gnome-shell, and 
+having a stand-alone mode, it works with compiz (which will appeal to 
+some users), and there are ports under development for gtk3 and xfce.
+It seems to be a sort of configurable icon-based menu system.
+There is no feature list as such, nor proposed new features, so it is a 
+little uncertain what are it's limitations.
+But why not ?
+
+-- 
+André
+
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010875.html b/zarb-ml/mageia-dev/2012-January/010875.html new file mode 100644 index 000000000..a3b16466c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010875.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] GNOME 2 panel applets + + + + + + + + + +

[Mageia-dev] GNOME 2 panel applets

+ Olav Vitters + olav at vitters.nl +
+ Mon Jan 2 15:26:22 CET 2012 +

+
+ +
On Mon, Jan 02, 2012 at 06:05:34AM -0500, andre999 wrote:
+> Olav Vitters a écrit :
+> >Inhttps://bugs.mageia.org/show_bug.cgi?id=1133, the reporter is asking
+> >to add dockbarx, a panel applet for GNOME 2.
+> >
+> >Being involved with GNOME, in my opinion this is a WONTFIX. There is no
+> >GNOME 2 in Mageia, and GNOME 3 fallback mode might go away, plus the
+> >panel API changed slightly (because it uses dbus now instead of bonobo).
+> >
+> >No clue if dockbarx works with fallback mode btw.
+> 
+> Some users report that it does, both in gnome-panel and standalone mode.
+> >What do others think?
+
+I don't really understand your post, could you clarify a bit?
+
+> My first reaction was, being a Gnome user myself, that if everything
+> is as stated, I tend to agree.
+> But following the links, as well as working under gnome-shell, and
+> having a stand-alone mode, it works with compiz (which will appeal
+> to some users), and there are ports under development for gtk3 and
+> xfce.
+
+What works with compiz? GNOME shell does not. You mean dockbarx? It is
+an applet, right? How would it be able to work with GNOME shell? What do
+you mean with stand-alone mode?
+
+> It seems to be a sort of configurable icon-based menu system.
+> There is no feature list as such, nor proposed new features, so it
+> is a little uncertain what are it's limitations.
+> But why not ?
+
+Why not: if GNOME 2: will not work. If GNOME 3 API: fallback mode will
+likely be removed. So you're adding something wile you might not have it
+for long.
+
+Just asking for input btw. If others think it is a good idea, then I'll
+just not close the bug.
+
+-- 
+Regards,
+Olav
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010876.html b/zarb-ml/mageia-dev/2012-January/010876.html new file mode 100644 index 000000000..5335e5f99 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010876.html @@ -0,0 +1,61 @@ + + + + [Mageia-dev] Happy New Year ! + + + + + + + + + +

[Mageia-dev] Happy New Year !

+ Bertaux Xavier + bertauxx at yahoo.fr +
+ Mon Jan 2 16:11:49 CET 2012 +

+
+ +
Happy New Year, my best wishes for everyone!
+
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010877.html b/zarb-ml/mageia-dev/2012-January/010877.html new file mode 100644 index 000000000..180e80a35 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010877.html @@ -0,0 +1,72 @@ + + + + [Mageia-dev] [packages-commits] [188982] fixed desktop file patch + + + + + + + + + +

[Mageia-dev] [packages-commits] [188982] fixed desktop file patch

+ Maarten Vanraes + alien at rmail.be +
+ Mon Jan 2 17:17:24 CET 2012 +

+
+ +
Op maandag 02 januari 2012 11:40:47 schreef Michael Scherer:
+[...]
+> - no suggest , they are unspecified, and causing problem ( like not
+> working for people that disable them, and bloating installation for
+> everybody else , and just giving no useful information for people to
+> decide to install or not )
+
+i guess you have a point here
+
+> - no requires from rpmlint on policy, since people have been asking to
+> be able to use different policy ( and since rpmlint is already required
+> by policy, that would make a loop and I would like to avoid that ).
+
+agreed
+
+so i guess you're not against that task rpm package?
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010878.html b/zarb-ml/mageia-dev/2012-January/010878.html new file mode 100644 index 000000000..26bc5189f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010878.html @@ -0,0 +1,68 @@ + + + + [Mageia-dev] Emails + + + + + + + + + +

[Mageia-dev] Emails

+ Pascal Terjan + pterjan at gmail.com +
+ Mon Jan 2 17:34:05 CET 2012 +

+
+ +
Sorry, sent it initially to the wrong mailing list.
+
+Following a little change last night:
+- Packager field of rpms is now "login <login>" (for example pterjan <pterjan>)
+- Mails on changelog email are from login <buildsystem-daemon at mageia.org
+- You should receive an email when a package you submitted fails to build
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010879.html b/zarb-ml/mageia-dev/2012-January/010879.html new file mode 100644 index 000000000..624188710 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010879.html @@ -0,0 +1,77 @@ + + + + [Mageia-dev] Emails + + + + + + + + + +

[Mageia-dev] Emails

+ Balcaen John + mikala at mageia.org +
+ Mon Jan 2 17:39:15 CET 2012 +

+
+ +
Le lundi 2 janvier 2012 13:34:05, Pascal Terjan a écrit :
+> Sorry, sent it initially to the wrong mailing list.
+> 
+> Following a little change last night:
+> - Packager field of rpms is now "login <login>" (for example pterjan
+> <pterjan>) - Mails on changelog email are from login
+> <buildsystem-daemon at mageia.org - You should receive an email when a
+> package you submitted fails to build
+Only when it failed to build or also when it was rejected by the BS ?
+
+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/2012-January/010880.html b/zarb-ml/mageia-dev/2012-January/010880.html new file mode 100644 index 000000000..bec4a0e01 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010880.html @@ -0,0 +1,76 @@ + + + + [Mageia-dev] Emails + + + + + + + + + +

[Mageia-dev] Emails

+ Pascal Terjan + pterjan at gmail.com +
+ Mon Jan 2 17:57:42 CET 2012 +

+
+ +
On Mon, Jan 2, 2012 at 16:39, Balcaen John <mikala at mageia.org> wrote:
+> Le lundi 2 janvier 2012 13:34:05, Pascal Terjan a écrit :
+>> Sorry, sent it initially to the wrong mailing list.
+>>
+>> Following a little change last night:
+>> - Packager field of rpms is now "login <login>" (for example pterjan
+>> <pterjan>) - Mails on changelog email are from login
+>> <buildsystem-daemon at mageia.org - You should receive an email when a
+>> package you submitted fails to build
+> Only when it failed to build or also when it was rejected by the BS ?
+
+Iurt only sends on build failure
+I think youri should send it on reject but I did not check if it works
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010881.html b/zarb-ml/mageia-dev/2012-January/010881.html new file mode 100644 index 000000000..0aa3baa19 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010881.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help + + + + + + + + + +

[Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help

+ Marja van Waes + marja11 at xs4all.nl +
+ Mon Jan 2 19:41:15 CET 2012 +

+
+ +
Hi everyone,
+
+Can someone please help to fix bug 1956?
+
+You don't need to be a regular forum visitor.
+
+We need someone to find and implement a probably existing MOD,  needed 
+to keep forum posts history when unlimited edit time is enabled
+
+ From wobo's comment #32:
+
+Capabilities needed:
+Well, one could say that anybody who
+  - knows how to run phpBB as admin and
+  - has seen a line of php
+  - knows how to edit code (respecting tags and such)
+  - knows how to cut&paste
+should be able to install an existing MOD (if I'm not mistaken there is one or
+more).
+
+I know next to nothing about php coding. But I've been running a phpBB forum
+for a couple of years and successfully implemented some MODs in phpBB2 and
+phpBB3. With no help (except the phpBB-forum in case of problems).
+
+In practice you have a detailed installation README for each MOD. Like
+  - open file /foo/bar/doo.php
+  - Find the line which starts with '......'
+  - After that add
+  - "........."
+And more such step-by-step guidance
+
+It's easy most times but getting tricky the more the installed phpBB3 differs
+from the standard software.
+
+Implementing a MOD which does not already exist (aka writing a MOD) is a whole
+different story, of course. So the first step should be searching an existing
+MOD with the wanted functionality.
+
+Regards and happy new year :)
+Marja
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010882.html b/zarb-ml/mageia-dev/2012-January/010882.html new file mode 100644 index 000000000..df4c9846f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010882.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] Significant decrease of installed packages for a minimal installation + + + + + + + + + +

[Mageia-dev] Significant decrease of installed packages for a minimal installation

+ Païou + paiiou at free.fr +
+ Mon Jan 2 21:00:48 CET 2012 +

+
+ +
Hello, all
+
+I just did a minimal installation of Mageia 1 (with updates)
+(custom desktop, in the next window I uncheck all package groups,
+ in the next window I check with X).
+Everything is going very well.
+
+And I have the pleasant surprise that, thanks to the updates, 
+the number of installed packages from 732 to 636.
+That's what I wanted for a long time.
+
+I compared the lists of packages and found that kdm is replaced by slim.
+Being a naturally curious, I would like to know what causes this substitution, 
+and in general, causing the decrease of packages.bassies
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010883.html b/zarb-ml/mageia-dev/2012-January/010883.html new file mode 100644 index 000000000..ca2a3b5a6 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010883.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help + + + + + + + + + +

[Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help

+ Michael Scherer + misc at zarb.org +
+ Mon Jan 2 21:40:31 CET 2012 +

+
+ +
Le lundi 02 janvier 2012 à 19:41 +0100, Marja van Waes a écrit :
+> Hi everyone,
+> 
+> Can someone please help to fix bug 1956?
+> 
+> You don't need to be a regular forum visitor.
+> 
+> We need someone to find and implement a probably existing MOD,  needed 
+> to keep forum posts history when unlimited edit time is enabled
+> 
+>  From wobo's comment #32:
+> 
+> Capabilities needed:
+> Well, one could say that anybody who
+>   - knows how to run phpBB as admin and
+>   - has seen a line of php
+>   - knows how to edit code (respecting tags and such)
+>   - knows how to cut&paste
+> should be able to install an existing MOD (if I'm not mistaken there is one or
+> more).
+> 
+> I know next to nothing about php coding. But I've been running a phpBB forum
+> for a couple of years and successfully implemented some MODs in phpBB2 and
+> phpBB3. With no help (except the phpBB-forum in case of problems).
+> 
+> In practice you have a detailed installation README for each MOD. Like
+>   - open file /foo/bar/doo.php
+>   - Find the line which starts with '......'
+>   - After that add
+>   - "........."
+> And more such step-by-step guidance
+
+My eyes start to bleed dues to such "guidances".
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010884.html b/zarb-ml/mageia-dev/2012-January/010884.html new file mode 100644 index 000000000..32067a22f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010884.html @@ -0,0 +1,106 @@ + + + + [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help + + + + + + + + + +

[Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help

+ Maarten Vanraes + alien at rmail.be +
+ Mon Jan 2 22:17:26 CET 2012 +

+
+ +
Op maandag 02 januari 2012 21:40:31 schreef Michael Scherer:
+> Le lundi 02 janvier 2012 à 19:41 +0100, Marja van Waes a écrit :
+> > Hi everyone,
+> > 
+> > Can someone please help to fix bug 1956?
+> > 
+> > You don't need to be a regular forum visitor.
+> > 
+> > We need someone to find and implement a probably existing MOD,  needed
+> > to keep forum posts history when unlimited edit time is enabled
+> > 
+> >  From wobo's comment #32:
+> > Capabilities needed:
+> > Well, one could say that anybody who
+> > 
+> >   - knows how to run phpBB as admin and
+> >   - has seen a line of php
+> >   - knows how to edit code (respecting tags and such)
+> >   - knows how to cut&paste
+> > 
+> > should be able to install an existing MOD (if I'm not mistaken there is
+> > one or more).
+> > 
+> > I know next to nothing about php coding. But I've been running a phpBB
+> > forum for a couple of years and successfully implemented some MODs in
+> > phpBB2 and phpBB3. With no help (except the phpBB-forum in case of
+> > problems).
+> > 
+> > In practice you have a detailed installation README for each MOD. Like
+> > 
+> >   - open file /foo/bar/doo.php
+> >   - Find the line which starts with '......'
+> >   - After that add
+> >   - "........."
+> > 
+> > And more such step-by-step guidance
+> 
+> My eyes start to bleed dues to such "guidances".
+
+i'm sure misc means to say that we should have all our changes in 
+packages/puppet config so that we can update without issues. and with file 
+edits, that's a whole different thing.
+
+ + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010885.html b/zarb-ml/mageia-dev/2012-January/010885.html new file mode 100644 index 000000000..dfc013fd5 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010885.html @@ -0,0 +1,144 @@ + + + + [Mageia-dev] GNOME 2 panel applets + + + + + + + + + +

[Mageia-dev] GNOME 2 panel applets

+ andre999 + andre999mga at laposte.net +
+ Mon Jan 2 23:15:34 CET 2012 +

+
+ +
Olav Vitters a écrit :
+> On Mon, Jan 02, 2012 at 06:05:34AM -0500, andre999 wrote:
+>    
+>> Olav Vitters a écrit :
+>>      
+>>> Inhttps://bugs.mageia.org/show_bug.cgi?id=1133, the reporter is asking
+>>> to add dockbarx, a panel applet for GNOME 2.
+>>>
+>>> Being involved with GNOME, in my opinion this is a WONTFIX. There is no
+>>> GNOME 2 in Mageia, and GNOME 3 fallback mode might go away, plus the
+>>> panel API changed slightly (because it uses dbus now instead of bonobo).
+>>>
+>>> No clue if dockbarx works with fallback mode btw.
+>>>        
+>> Some users report that it does, both in gnome-panel and standalone mode.
+>>      
+>>> What do others think?
+>>>        
+> I don't really understand your post, could you clarify a bit?
+>    
+
+OK
+I followed the link in the bug report, to various other links.
+According to the developers, the dockbarx works as an applet in 
+gnome-panel, as well as a stand-alone mode, not requiring gnome-panel.  
+They have images on their site of various themes available, some in 
+standalone mode, super-imposed on the gnome-panel.
+As well, the developers are porting dockbarx to gtk3 and xfce.
+
+There are various links to user comments.  Some of these links confirm 
+variously that dockbarx works under gnome-classic, in both gnome-panel 
+and stand-alone mode.
+Note that most of the feedback was from ubuntu users, which from the 
+comments seems to be on Gnome3.
+>> My first reaction was, being a Gnome user myself, that if everything
+>> is as stated, I tend to agree.
+>> But following the links, as well as working under gnome-shell, and
+>> having a stand-alone mode, it works with compiz (which will appeal
+>> to some users), and there are ports under development for gtk3 and
+>> xfce.
+>>      
+> What works with compiz? GNOME shell does not. You mean dockbarx?
+Right
+
+>   It is
+> an applet, right? How would it be able to work with GNOME shell? What do
+> you mean with stand-alone mode?
+>    
+
+As noted above and in my initial comment (which obviously wasn't clear), 
+there is a stand-alone mode which does not require Gnome panel
+
+>> It seems to be a sort of configurable icon-based menu system.
+>> There is no feature list as such, nor proposed new features, so it
+>> is a little uncertain what are it's limitations.
+>> But why not ?
+>>      
+> Why not: if GNOME 2: will not work. If GNOME 3 API: fallback mode will
+> likely be removed. So you're adding something wile you might not have it
+> for long.
+>    
+
+Firstly, the fallback mode will be around for a little while.
+And the developers are working on ports to gtk3 and xfce, so assuming 
+that that continues, dockbarx won't be dependant on fallback mode.
+However, projects don't always continue, even although it was started in 
+2009, and under development in November.
+BTW, the developers do mention that dockbarx will require some changes 
+to work directly under the Gnome 3 api.
+Also, I understand that this is not immediately evident, as they don't 
+have a feature list on their site, nor a development milestone.  Their 
+site could use a little more coherence.
+
+I'm not necessarily saying that we should import it.
+Only that it is not restricted to Gnome 2.  In the short term with 
+fallback mode, and according to the long-term goals of the developers.
+If everyone else thinks that we should say wontfix for now, I don't have 
+a problem with that.
+> Just asking for input btw. If others think it is a good idea, then I'll
+> just not close the bug.
+>
+>    
+Regards :)
+
+-- 
+André
+
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010886.html b/zarb-ml/mageia-dev/2012-January/010886.html new file mode 100644 index 000000000..851f56b84 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010886.html @@ -0,0 +1,114 @@ + + + + [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help + + + + + + + + + +

[Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help

+ Michael Scherer + misc at zarb.org +
+ Tue Jan 3 00:46:39 CET 2012 +

+
+ +
Le lundi 02 janvier 2012 à 22:17 +0100, Maarten Vanraes a écrit :
+> Op maandag 02 januari 2012 21:40:31 schreef Michael Scherer:
+> > Le lundi 02 janvier 2012 à 19:41 +0100, Marja van Waes a écrit :
+> > > Hi everyone,
+> > > 
+> > > Can someone please help to fix bug 1956?
+> > > 
+> > > You don't need to be a regular forum visitor.
+> > > 
+> > > We need someone to find and implement a probably existing MOD,  needed
+> > > to keep forum posts history when unlimited edit time is enabled
+> > > 
+> > >  From wobo's comment #32:
+> > > Capabilities needed:
+> > > Well, one could say that anybody who
+> > > 
+> > >   - knows how to run phpBB as admin and
+> > >   - has seen a line of php
+> > >   - knows how to edit code (respecting tags and such)
+> > >   - knows how to cut&paste
+> > > 
+> > > should be able to install an existing MOD (if I'm not mistaken there is
+> > > one or more).
+> > > 
+> > > I know next to nothing about php coding. But I've been running a phpBB
+> > > forum for a couple of years and successfully implemented some MODs in
+> > > phpBB2 and phpBB3. With no help (except the phpBB-forum in case of
+> > > problems).
+> > > 
+> > > In practice you have a detailed installation README for each MOD. Like
+> > > 
+> > >   - open file /foo/bar/doo.php
+> > >   - Find the line which starts with '......'
+> > >   - After that add
+> > >   - "........."
+> > > 
+> > > And more such step-by-step guidance
+> > 
+> > My eyes start to bleed dues to such "guidances".
+> 
+> i'm sure misc means to say that we should have all our changes in 
+> packages/puppet config so that we can update without issues. and with file 
+> edits, that's a whole different thing.
+
+I was more thinking of proper patchs or better, proper modules, with
+files to deploy in a well know directory .
+
+Something that do not remind me of Alien 4 movie.
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010887.html b/zarb-ml/mageia-dev/2012-January/010887.html new file mode 100644 index 000000000..1ed08d952 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010887.html @@ -0,0 +1,69 @@ + + + + [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help + + + + + + + + + +

[Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help

+ Maarten Vanraes + alien at rmail.be +
+ Tue Jan 3 02:26:31 CET 2012 +

+
+ +
Op dinsdag 03 januari 2012 00:46:39 schreef Michael Scherer:
+[...]
+> Something that do not remind me of Alien 4 movie.
+
+hey now! no insulting :-) that's a great movie! a bit of a mess at times, but 
+a great movie!
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010888.html b/zarb-ml/mageia-dev/2012-January/010888.html new file mode 100644 index 000000000..149aa2c43 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010888.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] Updated ISO's + + + + + + + + + +

[Mageia-dev] Updated ISO's

+ Josh King + josh at linuxpunks.com +
+ Tue Jan 3 04:20:44 CET 2012 +

+
+ +
Is there someplace updated iso's since the Alpha 2 release can be found? 
+I thought I had seen these someplace, but I could be mistaken and can't 
+seem to find them now. Thanks.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010889.html b/zarb-ml/mageia-dev/2012-January/010889.html new file mode 100644 index 000000000..42ae0d4cc --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010889.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] Updated ISO's + + + + + + + + + +

[Mageia-dev] Updated ISO's

+ Juan Luis Baptiste + juancho at mageia.org +
+ Tue Jan 3 04:50:06 CET 2012 +

+
+ +
On Mon, Jan 2, 2012 at 10:20 PM, Josh King <josh at linuxpunks.com> wrote:
+> Is there someplace updated iso's since the Alpha 2 release can be found? I
+> thought I had seen these someplace, but I could be mistaken and can't seem
+> to find them now. Thanks.
+>
+
+AFAIK no, if you want updated iso's you will have to wait until alpha
+3[1] on Jan 12.
+
+[1]https://wiki.mageia.org/en/Mageia_2_development
+
+-- 
+Juancho
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010890.html b/zarb-ml/mageia-dev/2012-January/010890.html new file mode 100644 index 000000000..5a8803928 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010890.html @@ -0,0 +1,133 @@ + + + + [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help + + + + + + + + + +

[Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Tue Jan 3 10:09:19 CET 2012 +

+
+ +
2012/1/3 Michael Scherer <misc at zarb.org>:
+> Le lundi 02 janvier 2012 à 22:17 +0100, Maarten Vanraes a écrit :
+>> Op maandag 02 januari 2012 21:40:31 schreef Michael Scherer:
+>> > Le lundi 02 janvier 2012 à 19:41 +0100, Marja van Waes a écrit :
+>> > > Hi everyone,
+>> > >
+>> > > Can someone please help to fix bug 1956?
+>> > >
+>> > > You don't need to be a regular forum visitor.
+>> > >
+>> > > We need someone to find and implement a probably existing MOD,  needed
+>> > > to keep forum posts history when unlimited edit time is enabled
+>> > >
+>> > >  From wobo's comment #32:
+>> > > Capabilities needed:
+>> > > Well, one could say that anybody who
+>> > >
+>> > >   - knows how to run phpBB as admin and
+>> > >   - has seen a line of php
+>> > >   - knows how to edit code (respecting tags and such)
+>> > >   - knows how to cut&paste
+>> > >
+>> > > should be able to install an existing MOD (if I'm not mistaken there is
+>> > > one or more).
+>> > >
+>> > > I know next to nothing about php coding. But I've been running a phpBB
+>> > > forum for a couple of years and successfully implemented some MODs in
+>> > > phpBB2 and phpBB3. With no help (except the phpBB-forum in case of
+>> > > problems).
+>> > >
+>> > > In practice you have a detailed installation README for each MOD. Like
+>> > >
+>> > >   - open file /foo/bar/doo.php
+>> > >   - Find the line which starts with '......'
+>> > >   - After that add
+>> > >   - "........."
+>> > >
+>> > > And more such step-by-step guidance
+>> >
+>> > My eyes start to bleed dues to such "guidances".
+>>
+>> i'm sure misc means to say that we should have all our changes in
+>> packages/puppet config so that we can update without issues. and with file
+>> edits, that's a whole different thing.
+>
+> I was more thinking of proper patchs or better, proper modules, with
+> files to deploy in a well know directory .
+
+I only gave a part of an example. MODs are made as enhancement to the
+standard software. The easiest MOD is like Michael wrote: "a module
+with files to deploy in a well known directory". But in most cases
+they consist of files to copy into various directories of the program
+tree and changes to existing files of the software. There are other
+MODs which can be implemented automatically - which is far worse IMHO.
+This is where a modded phpBB3 could turn into a nightmare to maintain
+- believe me, I've been there :(
+
+Of course no developper of a MOD could know what somebody has already
+done to the standard files, so it's not possible do use only patches.
+And it could be (and that happens quite often) that a MOD is not
+compatible to your already "modificated" forum software (destroys
+other modifications or whatever).
+
+IMHO the best way in this case here would be a mod written for our
+setup, all changes well defined to make it maintainable in a proper
+way. Saying this I beg to think again whether the issue  justifies all
+the time and work.
+
+-- 
+wobo
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010891.html b/zarb-ml/mageia-dev/2012-January/010891.html new file mode 100644 index 000000000..4e981ac8d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010891.html @@ -0,0 +1,124 @@ + + + + [Mageia-dev] RFC: Opening Backports (once again...) + + + + + + + + + +

[Mageia-dev] RFC: Opening Backports (once again...)

+ Buchan Milne + bgmilne at zarb.org +
+ Tue Jan 3 10:27:12 CET 2012 +

+
+ +
On Sunday, 11 December 2011 19:43:35 Florian Hubold wrote:
+\
+> 
+> Whatever the decision is, maybe we could tie this to some conditions:
+> Only allow backports if there are near-zero security/critical bugs for the
+> stable release or if there are no open bugs for the package in question?
+
+Well, my first question is, *who* is *responsible* for security updates? This 
+is not specified in the updates policy (the role assigned to build the 
+security update is named 'Maintainer (or any interested packager)', but who is 
+responsible for checking that we have all applicable updates? In Mandriva, it 
+was the responsibility of the security team (with cooperation from the 
+maintainer in some cases).
+
+At some stage we also need to look at providing vulnerability data in a 
+suitable format that supports automated validation (e.g. OVAL?), and a site 
+able to browse advisories.
+
+> Just some random crazy idea ...
+> 
+> IMHO we should focus on security and bugfixes for the stable release,
+> and there are currently too many security bugs open, some for a
+> really long time, where nothing is happening for months, yet we still
+> talk and concern about opening backports.
+
+FYI: the reason I have been slow on updates for Mageia is that I still have 
+systems running Mandriva, precisely because the bacports situation has not 
+been finalised, and I don't want to submit all missing packages in Mageia 1 to 
+updates. Once backports is open, I can drop some Mandriva packages, and spend 
+more time contributing to Mageia.
+
+So, you can't necessarily say that backports steals time from updates ...
+
+Regards,
+Buchan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010892.html b/zarb-ml/mageia-dev/2012-January/010892.html new file mode 100644 index 000000000..2ebbfb856 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010892.html @@ -0,0 +1,228 @@ + + + + [Mageia-dev] RFC: Opening Backports (once again...) + + + + + + + + + +

[Mageia-dev] RFC: Opening Backports (once again...)

+ Buchan Milne + bgmilne at zarb.org +
+ Tue Jan 3 10:45:13 CET 2012 +

+
+ +
On Saturday, 10 December 2011 13:32:12 Michael Scherer wrote:
+> Le mardi 06 décembre 2011 à 00:56 +0200, Thomas Backlund a écrit :
+> > Now,
+> > 
+> > here comes the question about backports once again.
+> > 
+> > We are now 6+ months into Mageia 1, and we are nowhere closer to opening
+> > backports that we were at Mageia 1 release time.
+> > 
+> > Because of that there are 3rdparty repos popping up everywhere...,
+> > something we hoped to avoid atleast partly when starting this project.
+> 
+> Well, the backport issue ( ie :
+> - no garantee of keep the distribution upgradable
+
+Backports will probably provide a better probability of upgradability than 
+3rd-party repos.
+
+> - no security  )
+
+No means to provide a security updates that has followed a QA process in the 
+event package version Z no longer builds on distribution with version X in 
+release and version Y in backports.
+
+But, note that without backports, users who wanted version Y would either:
+-Switch to a distro that has version Y (worse) - I would guess 20%
+-Switch to using cauldron, and start contributing (better) - I would guess 5% 
+or less
+-Use Cauldron package on stable release (worse) - I would guess about 30%
+-Build package from source (worse) - I would guess about 20%
+-Rebuild cauldron package on stable release (same) - I wold guess about 10%
+-Keep version X (better) and eventually become upset about age of software 
+(worse) - I would guess about 15%
+
+So, only one outcome would be better, one would be the same, and the other 3 
+outcomes would be worse, and probably be the majority of outcomes.
+
+In the case where there is no problem with providing the update, backports is 
+superiour, and would provide a better outcome in every case.
+
+Do we have any idea on how many packages this ever affected in Mandriva?
+
+> have also not been fixed, so that's rather unfair to
+
+... ?
+
+> > So here is a suggestion to get some value to our endusers:
+> > 
+> > we add a backports branch on svn
+> > 
+> > So packages for backports would use:
+> > 
+> > svn.mageia.org/packages/backports/1/<package>/{current,pristine,releases}
+> > 
+> > and allow that to be used for backports.
+> > 
+> > Using a separate branch is also a cleaner way of providing
+> > backports, and makes it easy to separate changes needed only
+> > for Cauldron (or backports).
+
+I thought the whole point of Backports was to provide a streamlined way to 
+provide newer versions of packages that already exist in Cauldron, with 
+minimal effort, to stable releases. This increases the incentive for users on 
+stable releases to contribute to Cauldron in some way, and doesn't increase 
+the burden on the maintainer significantly. There should be no need to have 
+distribution release-specific content in any of the packages.
+
+In the rare case a package can't be provided like this, maybe it isn't a good 
+candidate for backports?
+
+> Then in practice, that mean having a 2nd/3rd distribution ( because
+> there is a separate 2nd svn branch, and a 3rd one for later ) and so
+> that's a big no for me. Having 2+ branchs is just asking for trouble
+> when they are not in sync ( and since keeping everything in sync
+> properly with svn is a pain if there is a divergence, this will not be
+> done ).
+> 
+> Worst, if we do like in mdv and propose 2 way of backporting ( submit
+> from cauldron, submit from a branch ), this will create a mess of having
+> some packages from cauldron, some from the branch, and people having no
+> way from knowing where does a package come from. This also make the
+> system harder to maintain and to follow, and rather impossible to script
+> properly.
+> 
+> So that's also to be avoided.
+> 
+> Having a separate branch where people can write also remove the only
+> incentive I have seen for backports, ie, wider testing of our packages,
+> because they may not really the same as in cauldron.
+> 
+> 
+> So here is what I propose :
+> 
+> - have X branchs, but do not let anyone commit on it, besides a system
+> user. When a package is submitted to cauldron, it is also copied to this
+> branch, ie, we make sure current is in sync. The same goes for version
+> N-1 being copied from N once a backported rpm have been submitted to be
+> used by people. Once a distribution is no longer supported, we close the
+> branch, and disable the sync.
+> 
+> - backports are only submitted from the branch, with separate
+> markrelease, tags, whatever. This let us have proper audit of backports,
+> and who did what.
+> 
+> - packagers still need to commit and submit on cauldron before any
+> backports. So we miss no fixes or anything by mistake. We also make sure
+> that cauldron is always the highest version possible, thus permitting at
+> least some form of upgrade. ( either stable to stable, provided
+> backports are used, or stable to cauldron ). And we also ensure that
+> backports are done first on the most recent stable version, for the same
+> reason ( ensure some form of upgrade path, as asked several time by
+> users ).
+
+So, we have two copies of identical packages, that are always in sync, and can 
+never diverge.
+
+What is the point then? Just to allow build system rules not to be violated 
+(by using a branch)?
+
+> And we can still use %ifdef if a need arise for a different spec between
+> distribution versions. While that make spec less readable, that's more
+> readable than having forked specs 2 or 3 times.
+> 
+> This requires :
+> 
+> - 1 youri action to copy the package to current backport branch ( can be
+> done based on the markrelease action and the others )
+> 
+> - 1 svn configuration to prevent people from writing directly there ( or
+> just say to not do it, and burn people who do it )
+> 
+> 
+> - youri config to let people submit from backports to backports_testing.
+
+What does this all achieve that would not be achieved by allowing submission 
+from cauldron to backports_testing ?
+
+Regards,
+Buchan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010893.html b/zarb-ml/mageia-dev/2012-January/010893.html new file mode 100644 index 000000000..3ce18efa5 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010893.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help + + + + + + + + + +

[Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help

+ AL13N + alien at rmail.be +
+ Tue Jan 3 12:08:52 CET 2012 +

+
+ +
> 2012/1/3 Michael Scherer <misc at zarb.org>:
+[...]
+>> I was more thinking of proper patchs or better, proper modules, with
+>> files to deploy in a well know directory .
+>
+> I only gave a part of an example. MODs are made as enhancement to the
+> standard software. The easiest MOD is like Michael wrote: "a module
+> with files to deploy in a well known directory". But in most cases
+> they consist of files to copy into various directories of the program
+> tree and changes to existing files of the software. There are other
+> MODs which can be implemented automatically - which is far worse IMHO.
+> This is where a modded phpBB3 could turn into a nightmare to maintain
+> - believe me, I've been there :(
+
+/o\
+
+> Of course no developper of a MOD could know what somebody has already
+> done to the standard files, so it's not possible do use only patches.
+> And it could be (and that happens quite often) that a MOD is not
+> compatible to your already "modificated" forum software (destroys
+> other modifications or whatever).
+>
+> IMHO the best way in this case here would be a mod written for our
+> setup, all changes well defined to make it maintainable in a proper
+> way. Saying this I beg to think again whether the issue  justifies all
+> the time and work.
+
++1
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010894.html b/zarb-ml/mageia-dev/2012-January/010894.html new file mode 100644 index 000000000..b06162398 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010894.html @@ -0,0 +1,114 @@ + + + + [Mageia-dev] RFC: Opening Backports (once again...) + + + + + + + + + +

[Mageia-dev] RFC: Opening Backports (once again...)

+ AL13N + alien at rmail.be +
+ Tue Jan 3 12:18:23 CET 2012 +

+
+ +
[...]
+> At some stage we also need to look at providing vulnerability data in a
+> suitable format that supports automated validation (e.g. OVAL?), and a
+> site
+> able to browse advisories.
+
+If this means less work, and is relatively easy to do by package
+maintainers, then, this looks like quite a good idea.
+
+>> Just some random crazy idea ...
+>>
+>> IMHO we should focus on security and bugfixes for the stable release,
+>> and there are currently too many security bugs open, some for a
+>> really long time, where nothing is happening for months, yet we still
+>> talk and concern about opening backports.
+>
+> FYI: the reason I have been slow on updates for Mageia is that I still
+> have
+> systems running Mandriva, precisely because the bacports situation has not
+> been finalised, and I don't want to submit all missing packages in Mageia
+> 1 to
+> updates. Once backports is open, I can drop some Mandriva packages, and
+> spend
+> more time contributing to Mageia.
+>
+> So, you can't necessarily say that backports steals time from updates ...
+
+interesting point of view...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010895.html b/zarb-ml/mageia-dev/2012-January/010895.html new file mode 100644 index 000000000..6792841c8 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010895.html @@ -0,0 +1,110 @@ + + + + [Mageia-dev] RFC: Opening Backports (once again...) + + + + + + + + + +

[Mageia-dev] RFC: Opening Backports (once again...)

+ Angelo Naselli + anaselli at linux.it +
+ Tue Jan 3 14:26:15 CET 2012 +

+
+ +
martedì 3 gennaio 2012 alle 10:45, Buchan Milne ha scritto:
+> -Build package from source (worse) - I would guess about 20%
+> -Rebuild cauldron package on stable release (same) - I wold guess about 10%
+IMO you're very optimistic here :) 
+I think this is true for expert users, so the ones who started developing
+in mageia, or some who would like to start contributing and his status
+is pending waiting mentors...
+Non expert users will probably switch to other distros... increasing your
+first percentage.
+But we should think also about the percentage of users that would like
+the backports, that should be interesting, i mean if the 3% want backports
+loosing that percentage could be not very interesting... and we could try
+to be better in 2... am i wrong?
+
+
+Angelo (who is in favour to open bp)
+-------------- 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/20120103/c628f25c/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010896.html b/zarb-ml/mageia-dev/2012-January/010896.html new file mode 100644 index 000000000..07d60c7db --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010896.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release omniorb-4.1.6-1.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release omniorb-4.1.6-1.mga2

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Jan 3 15:13:16 CET 2012 +

+
+ +
On 3 January 2012 14:12, barjac <buildsystem-daemon at mageia.org> wrote:
+> Description :
+> omniORB is an Object Request Broker (ORB) from AT&T which implements
+> specification 2.3 of the Common Object Request Broker Architecture (CORBA).
+>
+> Warning:
+> Before release 4.0.0, it contains OmnyORBpy, now it is a separate package.
+
+This warning has nothing to do in %description and will look ugly in rpmdrake...
+
+> barjac <barjac> 4.1.6-1.mga2:
+> + Revision: 189858
+> - New version, removed static, cleaned, removed old patches, added format security patch
+> - imported package omniorb
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010897.html b/zarb-ml/mageia-dev/2012-January/010897.html new file mode 100644 index 000000000..0bb76c133 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010897.html @@ -0,0 +1,117 @@ + + + + [Mageia-dev] External monitor resolution probing broken since this morning + + + + + + + + + +

[Mageia-dev] External monitor resolution probing broken since this morning

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Tue Jan 3 15:39:40 CET 2012 +

+
+ +
Since this morning, I can't get resolutions higher than 1024*768 on my 
+external monitor (VGA1), whereas I usuallu have 1920*1200:
+
+Screen 0: minimum 320 x 200, current 2048 x 768, maximum 8192 x 8192
+LVDS1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 
+261mm x 163mm
+    1280x800       60.1 +
+    1024x768       60.0*
+    800x600        60.3     56.2
+    640x480        59.9
+VGA1 connected 1024x768+1024+0 (normal left inverted right x axis y 
+axis) 0mm x 0mm
+    1024x768       60.0*
+    800x600        60.3     56.2
+    848x480        60.0
+    640x480        59.9
+HDMI1 disconnected (normal left inverted right x axis y axis)
+DP1 disconnected (normal left inverted right x axis y axis)
+DP2 disconnected (normal left inverted right x axis y axis)
+
+The only X-related change is xinput 1.5.3 -> 1.5.4 this morning, but 
+reverting didn't change anything. I didn't found any blatant error in 
+dmesg, nor in xorg logs.
+
+Any idea ?
+-- 
+BOFH excuse #296:
+
+The hardware bus needs a new token.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010898.html b/zarb-ml/mageia-dev/2012-January/010898.html new file mode 100644 index 000000000..fd097b162 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010898.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] Significant decrease of installed packages for a minimal installation + + + + + + + + + +

[Mageia-dev] Significant decrease of installed packages for a minimal installation

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Tue Jan 3 15:40:56 CET 2012 +

+
+ +
2012/1/2 Païou <paiiou at free.fr>:
+> Hello, all
+>
+> I just did a minimal installation of Mageia 1 (with updates)
+> (custom desktop, in the next window I uncheck all package groups,
+>  in the next window I check with X).
+> Everything is going very well.
+>
+> And I have the pleasant surprise that, thanks to the updates,
+> the number of installed packages from 732 to 636.
+> That's what I wanted for a long time.
+>
+> I compared the lists of packages and found that kdm is replaced by slim.
+> Being a naturally curious, I would like to know what causes this substitution,
+> and in general, causing the decrease of packages.bassies
+
+Can't confirm this. I just did the same on a netbook.
+Custom desktop, unchecked all groups, minimal installation with X
+Ran updates, uninstalled orphans.
+
+Result: 756 packages, kdm installed, slim not installed.
+As kdm takes some dependencies with it, this change to slim is significant.
+
+Leaves the question: why do we see a different result? A small
+difference in the package number is surely caused by different
+hardware configuration, but not a difference of 100 packages. Also
+hardware configuration can not cause the difference concerning
+kdm/slim.
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010899.html b/zarb-ml/mageia-dev/2012-January/010899.html new file mode 100644 index 000000000..85cd6cb90 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010899.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] Significant decrease of installed packages for a minimal installation + + + + + + + + + +

[Mageia-dev] Significant decrease of installed packages for a minimal installation

+ zezinho + lists.jjorge at free.fr +
+ Tue Jan 3 15:47:21 CET 2012 +

+
+ +
Le mardi 3 janvier 2012 15:40:56, Wolfgang Bornath a écrit :
+> 2012/1/2 Païou <paiiou at free.fr>:
+> > I just did a minimal installation of Mageia 1 (with updates)
+> Can't confirm this. I just did the same on a netbook.
+> Custom desktop, unchecked all groups, minimal installation with X
+> Ran updates, uninstalled orphans.
+
+It seems you did not use the updates for the first install. So the KDM was 
+installed, and updating does not remove it.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010900.html b/zarb-ml/mageia-dev/2012-January/010900.html new file mode 100644 index 000000000..d57924f2b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010900.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] Significant decrease of installed packages for a minimal installation + + + + + + + + + +

[Mageia-dev] Significant decrease of installed packages for a minimal installation

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Tue Jan 3 15:59:31 CET 2012 +

+
+ +
2012/1/3 zezinho <lists.jjorge at free.fr>:
+> Le mardi 3 janvier 2012 15:40:56, Wolfgang Bornath a écrit :
+>> 2012/1/2 Païou <paiiou at free.fr>:
+>> > I just did a minimal installation of Mageia 1 (with updates)
+>> Can't confirm this. I just did the same on a netbook.
+>> Custom desktop, unchecked all groups, minimal installation with X
+>> Ran updates, uninstalled orphans.
+>
+> It seems you did not use the updates for the first install. So the KDM was
+> installed, and updating does not remove it.
+
+I can only run updates AFTER installation (or at the end of
+installation, if that works), no?
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010901.html b/zarb-ml/mageia-dev/2012-January/010901.html new file mode 100644 index 000000000..bc3df6f28 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010901.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] Significant decrease of installed packages for a minimal installation + + + + + + + + + +

[Mageia-dev] Significant decrease of installed packages for a minimal installation

+ Païou + paiiou at free.fr +
+ Tue Jan 3 16:05:07 CET 2012 +

+
+ +
+I get this reduction in installed packages only if I add a mirror
+ with the update, at the time of installation.
+
+If I do the updates later, I have the same result as you.
+
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010902.html b/zarb-ml/mageia-dev/2012-January/010902.html new file mode 100644 index 000000000..14a5b8754 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010902.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] Significant decrease of installed packages for a minimal installation + + + + + + + + + +

[Mageia-dev] Significant decrease of installed packages for a minimal installation

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Tue Jan 3 16:09:33 CET 2012 +

+
+ +
2012/1/3 Païou <paiiou at free.fr>:
+>
+> I get this reduction in installed packages only if I add a mirror
+>  with the update, at the time of installation.
+>
+> If I do the updates later, I have the same result as you.
+
+Ah, ok, will try a net installation then, thx
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010903.html b/zarb-ml/mageia-dev/2012-January/010903.html new file mode 100644 index 000000000..a47f3d9e8 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010903.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release portaudio-19-18.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release portaudio-19-18.mga2

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Jan 3 16:48:54 CET 2012 +

+
+ +
On 3 January 2012 16:11, zezinho <buildsystem-daemon at mageia.org> wrote:
+> zezinho <zezinho> 19-18.mga2:
+> + Revision: 189952
+> - bump release to rebuild
+
+"rebuild" is enough.
+What is missing is "rebuild for ?_WHAT_?"
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010904.html b/zarb-ml/mageia-dev/2012-January/010904.html new file mode 100644 index 000000000..c8855ae84 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010904.html @@ -0,0 +1,148 @@ + + + + [Mageia-dev] [packages-commits] [189967] - version upgrade + + + + + + + + + +

[Mageia-dev] [packages-commits] [189967] - version upgrade

+ Jani Välimaa + jani.valimaa at gmail.com +
+ Tue Jan 3 17:18:12 CET 2012 +

+
+ +
2012/1/3  <root at mageia.org>:
+> Revision 189967 Author matteo Date 2012-01-03 16:46:56 +0100 (Tue, 03 Jan
+> 2012)
+>
+> Log Message
+>
+> - version upgrade
+> - used macros instead of command names
+>
+> Modified Paths
+>
+> cauldron/x86info/current/SPECS/x86info.spec
+>
+> Modified: cauldron/x86info/current/SPECS/x86info.spec
+> ===================================================================
+> --- cauldron/x86info/current/SPECS/x86info.spec	2012-01-03 15:45:07 UTC (rev
+> 189966)
+> +++ cauldron/x86info/current/SPECS/x86info.spec	2012-01-03 15:46:56 UTC (rev
+> 189967)
+> @@ -1,5 +1,5 @@
+>  %define	name	x86info
+> -%define	version	1.29
+> +%define	version	1.30
+>  %define realver	%{version}
+>  #define cvsdate	20050420
+>
+> @@ -11,7 +11,7 @@
+>  Group:		System/Kernel and hardware
+>  BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot
+>  URL:		http://www.codemonkey.org.uk/projects/x86info/
+> -Source0:	%{name}-%{realver}%{?cvsdate:-%{cvsdate}}.tar.bz2
+> +Source0:	%{name}-%{realver}%{?cvsdate:-%{cvsdate}}.tgz
+>  Patch0:		x86info-1.17-intel-flags.patch
+>  Patch1:		x86info-1.17-intel-caches.patch
+>  Patch2:		x86info-1.17-cpuid-with-ecx-input.patch
+> @@ -33,17 +33,18 @@
+>  %setup -q -n %{name}-%{realver}
+>
+>  %build
+> -make CFLAGS="%{optflags}"
+> +#make CFLAGS="%{optflags}"
+> +%make
+>
+>  %install
+> -rm -rf %{buildroot}
+> -install -d %{buildroot}%{_bindir}
+> -install -d %{buildroot}%{_mandir}/man1
+> -install -m755 %{name} %{buildroot}%{_bindir}/
+> -install -m755 %{name}.1 %{buildroot}%{_mandir}/man1/
+> +%__rm -rf %{buildroot}
+> +%__install -d %{buildroot}%{_bindir}
+> +%__install -d %{buildroot}%{_mandir}/man1
+> +%__install -m755 %{name} %{buildroot}%{_bindir}/
+> +%__install -m755 %{name}.1 %{buildroot}%{_mandir}/man1/
+>
+
+I think this is pretty much opposite what everyone else is doing. IMHO
+this also makes .spec harder to read.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010905.html b/zarb-ml/mageia-dev/2012-January/010905.html new file mode 100644 index 000000000..c8b116785 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010905.html @@ -0,0 +1,120 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release x86info-1.30-2.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release x86info-1.30-2.mga2

+ Jani Välimaa + jani.valimaa at gmail.com +
+ Tue Jan 3 17:22:10 CET 2012 +

+
+ +
2012/1/3 matteo <buildsystem-daemon at mageia.org>:
+> Name        : x86info                      Relocations: (not relocatable)
+> Version     : 1.30                              Vendor: Mageia.Org
+> Release     : 2.mga2                        Build Date: Tue Jan  3 17:08:12 2012
+> Install Date: (not installed)               Build Host: jonund
+> Group       : System/Kernel and hardware    Source RPM: (none)
+> Size        : 106444                           License: GPLv2
+> Signature   : (none)
+> Packager    : matteo <matteo>
+> URL         : http://www.codemonkey.org.uk/projects/x86info/
+> Summary     : Show x86 CPU information
+> Description :
+> Unlike other 'cpuinfo' tools which just parse /proc/cpuinfo, x86info probes
+> the CPU registers to find out a lot more information. It can discover the
+> contents of model-specific registers, discover CPU silicon revisions, and
+> lots more.
+>
+> matteo <matteo> 1.30-2.mga2:
+> + Revision: 189980
+> - fixed license
+> - fixed missing make cflags
+> - bumped release
+
+There's no need to mention "release bumping" in changelog. It's obvious change.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010906.html b/zarb-ml/mageia-dev/2012-January/010906.html new file mode 100644 index 000000000..528238a7b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010906.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] Significant decrease of installed packages for a minimal installation + + + + + + + + + +

[Mageia-dev] Significant decrease of installed packages for a minimal installation

+ Païou + paiiou at free.fr +
+ Tue Jan 3 17:24:30 CET 2012 +

+
+ +
zezinho <lists.jjorge at ...> writes:
+
+> 
+> Le mardi 3 janvier 2012 15:40:56, Wolfgang Bornath a écrit :
+> > 2012/1/2 Païou <paiiou at ...>:
+> > > I just did a minimal installation of Mageia 1 (with updates)
+> > Can't confirm this. I just did the same on a netbook.
+> > Custom desktop, unchecked all groups, minimal installation with X
+> > Ran updates, uninstalled orphans.
+> 
+> It seems you did not use the updates for the first install. So the KDM was 
+> installed, and updating does not remove it.
+> 
+> 
+
+What interests me is to know what changes to allow the economy to
+packages.
+It would be interesting to also change cauldron in that direction.
+
+Maybe you have the response.
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010907.html b/zarb-ml/mageia-dev/2012-January/010907.html new file mode 100644 index 000000000..2943ba2cf --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010907.html @@ -0,0 +1,131 @@ + + + + [Mageia-dev] [packages-commits] [189967] - version upgrade + + + + + + + + + +

[Mageia-dev] [packages-commits] [189967] - version upgrade

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Tue Jan 3 17:30:40 CET 2012 +

+
+ +
Le 03/01/2012 17:18, Jani Välimaa a écrit :
+>> @@ -11,7 +11,7 @@
+>>   Group:		System/Kernel and hardware
+>>   BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot
+>>   URL:		http://www.codemonkey.org.uk/projects/x86info/
+>> -Source0:	%{name}-%{realver}%{?cvsdate:-%{cvsdate}}.tar.bz2
+>> +Source0:	%{name}-%{realver}%{?cvsdate:-%{cvsdate}}.tgz
+>>   Patch0:		x86info-1.17-intel-flags.patch
+>>   Patch1:		x86info-1.17-intel-caches.patch
+>>   Patch2:		x86info-1.17-cpuid-with-ecx-input.patch
+>> @@ -33,17 +33,18 @@
+>>   %setup -q -n %{name}-%{realver}
+>>
+>>   %build
+>> -make CFLAGS="%{optflags}"
+>> +#make CFLAGS="%{optflags}"
+>> +%make
+>>
+>>   %install
+>> -rm -rf %{buildroot}
+>> -install -d %{buildroot}%{_bindir}
+>> -install -d %{buildroot}%{_mandir}/man1
+>> -install -m755 %{name} %{buildroot}%{_bindir}/
+>> -install -m755 %{name}.1 %{buildroot}%{_mandir}/man1/
+>> +%__rm -rf %{buildroot}
+>> +%__install -d %{buildroot}%{_bindir}
+>> +%__install -d %{buildroot}%{_mandir}/man1
+>> +%__install -m755 %{name} %{buildroot}%{_bindir}/
+>> +%__install -m755 %{name}.1 %{buildroot}%{_mandir}/man1/
+>>
+>
+> I think this is pretty much opposite what everyone else is doing. IMHO
+> this also makes .spec harder to read.
+Morevoer, it mixes pure cosmetics changes, as some of those macros just 
+expand to the command itself, as install vs %__install, with behaviour 
+changes, as other macros expand to the command with additional 
+arguments, as make vs %make, which is actually make -j.
+
+-- 
+BOFH excuse #62:
+
+need to wrap system in aluminum foil to fix problem
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010908.html b/zarb-ml/mageia-dev/2012-January/010908.html new file mode 100644 index 000000000..1bbcb949d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010908.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] Significant decrease of installed packages for a minimal installation + + + + + + + + + +

[Mageia-dev] Significant decrease of installed packages for a minimal installation

+ Balcaen John + mikala at mageia.org +
+ Tue Jan 3 17:47:49 CET 2012 +

+
+ +
Le mardi 3 janvier 2012 13:24:30, Païou a écrit :
+> zezinho <lists.jjorge at ...> writes:
+> > Le mardi 3 janvier 2012 15:40:56, Wolfgang Bornath a écrit :
+> > > 2012/1/2 Païou <paiiou at ...>:
+> > > > I just did a minimal installation of Mageia 1 (with updates)
+> > > 
+> > > Can't confirm this. I just did the same on a netbook.
+> > > Custom desktop, unchecked all groups, minimal installation with X
+> > > Ran updates, uninstalled orphans.
+> > 
+> > It seems you did not use the updates for the first install. So the KDM
+> > was installed, and updating does not remove it.
+> 
+> What interests me is to know what changes to allow the economy to
+> packages.
+> It would be interesting to also change cauldron in that direction.
+> 
+> Maybe you have the response.
+the result of the -debug during installation might help to understand why slim 
+is preferred over kdm, but i guess kdm was installed initially simply because 
+a dm was needed & slim not available on the iso.
+
+--
+Balcaen John
+Jabber-ID: mikala at jabber.littleboboy.net
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010909.html b/zarb-ml/mageia-dev/2012-January/010909.html new file mode 100644 index 000000000..d4475d517 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010909.html @@ -0,0 +1,112 @@ + + + + [Mageia-dev] Significant decrease of installed packages for a minimal installation + + + + + + + + + +

[Mageia-dev] Significant decrease of installed packages for a minimal installation

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Tue Jan 3 18:01:51 CET 2012 +

+
+ +
2012/1/3 Balcaen John <mikala at mageia.org>:
+> Le mardi 3 janvier 2012 13:24:30, Païou a écrit :
+>> zezinho <lists.jjorge at ...> writes:
+>> > Le mardi 3 janvier 2012 15:40:56, Wolfgang Bornath a écrit :
+>> > > 2012/1/2 Païou <paiiou at ...>:
+>> > > > I just did a minimal installation of Mageia 1 (with updates)
+>> > >
+>> > > Can't confirm this. I just did the same on a netbook.
+>> > > Custom desktop, unchecked all groups, minimal installation with X
+>> > > Ran updates, uninstalled orphans.
+>> >
+>> > It seems you did not use the updates for the first install. So the KDM
+>> > was installed, and updating does not remove it.
+>>
+>> What interests me is to know what changes to allow the economy to
+>> packages.
+>> It would be interesting to also change cauldron in that direction.
+>>
+>> Maybe you have the response.
+> the result of the -debug during installation might help to understand why slim
+> is preferred over kdm, but i guess kdm was installed initially simply because
+> a dm was needed & slim not available on the iso.
+
+Yes, must be.
+In my second try I added a ftp server as additional source (somewhere
+in the beginning of the installation), now slim was installed instead
+of kdm. Number of packages now matches with Païou's results. After
+adding wifi dkms (including the kernel-devel and others), vlc,
+chromium-browser (+flash-player plugin) and mc I ended up with a nice
+little machine for being on the road (1.1Gb, 758 packages). Mission
+accomplished :)
+
+--
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010910.html b/zarb-ml/mageia-dev/2012-January/010910.html new file mode 100644 index 000000000..a57e854fc --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010910.html @@ -0,0 +1,113 @@ + + + + [Mageia-dev] External monitor resolution probing broken since this morning + + + + + + + + + +

[Mageia-dev] External monitor resolution probing broken since this morning

+ Anssi Hannula + anssi at mageia.org +
+ Tue Jan 3 18:17:15 CET 2012 +

+
+ +
On 03.01.2012 16:39, Guillaume Rousse wrote:
+> Since this morning, I can't get resolutions higher than 1024*768 on my
+> external monitor (VGA1), whereas I usuallu have 1920*1200:
+> 
+> Screen 0: minimum 320 x 200, current 2048 x 768, maximum 8192 x 8192
+> LVDS1 connected 1024x768+0+0 (normal left inverted right x axis y axis)
+> 261mm x 163mm
+>    1280x800       60.1 +
+>    1024x768       60.0*
+>    800x600        60.3     56.2
+>    640x480        59.9
+> VGA1 connected 1024x768+1024+0 (normal left inverted right x axis y
+> axis) 0mm x 0mm
+>    1024x768       60.0*
+>    800x600        60.3     56.2
+>    848x480        60.0
+>    640x480        59.9
+> HDMI1 disconnected (normal left inverted right x axis y axis)
+> DP1 disconnected (normal left inverted right x axis y axis)
+> DP2 disconnected (normal left inverted right x axis y axis)
+> 
+> The only X-related change is xinput 1.5.3 -> 1.5.4 this morning, but
+> reverting didn't change anything. I didn't found any blatant error in
+> dmesg, nor in xorg logs.
+> 
+> Any idea ?
+
+Does the Xorg.0.log contain a modelist and/or raw EDID data?
+
+If so, do those look correct? (you can use e.g. monitor-parse-edid or
+just paste here)
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010911.html b/zarb-ml/mageia-dev/2012-January/010911.html new file mode 100644 index 000000000..0e5c9edd0 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010911.html @@ -0,0 +1,134 @@ + + + + [Mageia-dev] [soft-commits] [2237] disable nvidia173 and nvidia96xx as they do not support X. org server 1.11) + + + + + + + + + +

[Mageia-dev] [soft-commits] [2237] disable nvidia173 and nvidia96xx as they do not support X. org server 1.11)

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Jan 3 18:17:11 CET 2012 +

+
+ +
On 2 December 2011 19:35,  <root at mageia.org> wrote:
+> Revision 2237 Author anssi Date 2011-12-02 19:35:53 +0100 (Fri, 02 Dec 2011)
+>
+> Log Message
+>
+> disable nvidia173 and nvidia96xx as they do not support X.org server 1.11)
+
+Err... you only altered some of the nvidia96xx entries:
+
+$ grep nvidia96xx ../ldetect-lst/lst//Cards+  -B3
+
+NAME NVIDIA GeForce 2 MX to GeForce 4
+DRIVER nouveau
+#DRIVER2 nvidia96xx (not compatible with X.org server 1.11)
+--
+NAME NVIDIA GeForce 6100 to GeForce 360
+DRIVER nouveau
+DRIVER2 nvidia-current
+DRIVER2_NO_SSE nvidia96xx
+--
+NAME NVIDIA GeForce 400 series and later
+DRIVER nouveau
+DRIVER2 nvidia-current
+DRIVER2_NO_SSE nvidia96xx
+
+> Modified: ldetect-lst/trunk/lst/Cards+
+> ===================================================================
+> --- ldetect-lst/trunk/lst/Cards+	2011-12-02 16:46:06 UTC (rev 2236)
+> +++ ldetect-lst/trunk/lst/Cards+	2011-12-02 18:35:53 UTC (rev 2237)
+> @@ -260,11 +260,11 @@
+>
+>  NAME NVIDIA GeForce 2 MX to GeForce 4
+>  DRIVER nouveau
+> -DRIVER2 nvidia96xx
+> +#DRIVER2 nvidia96xx (not compatible with X.org server 1.11)
+>
+>  NAME NVIDIA GeForce FX series
+>  DRIVER nouveau
+> -DRIVER2 nvidia173
+> +#DRIVER2 nvidia173 (not compatible with X.org server 1.11)
+>
+>  NAME NVIDIA GeForce 6100 to GeForce 360
+>  DRIVER nouveau
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010912.html b/zarb-ml/mageia-dev/2012-January/010912.html new file mode 100644 index 000000000..229521d43 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010912.html @@ -0,0 +1,143 @@ + + + + [Mageia-dev] [soft-commits] [2237] disable nvidia173 and nvidia96xx as they do not support X. org server 1.11) + + + + + + + + + +

[Mageia-dev] [soft-commits] [2237] disable nvidia173 and nvidia96xx as they do not support X. org server 1.11)

+ Anssi Hannula + anssi at mageia.org +
+ Tue Jan 3 18:21:34 CET 2012 +

+
+ +
On 03.01.2012 19:17, Thierry Vignaud wrote:
+> On 2 December 2011 19:35,  <root at mageia.org> wrote:
+>> Revision 2237 Author anssi Date 2011-12-02 19:35:53 +0100 (Fri, 02 Dec 2011)
+>>
+>> Log Message
+>>
+>> disable nvidia173 and nvidia96xx as they do not support X.org server 1.11)
+> 
+> Err... you only altered some of the nvidia96xx entries:
+> 
+> $ grep nvidia96xx ../ldetect-lst/lst//Cards+  -B3
+> 
+> NAME NVIDIA GeForce 2 MX to GeForce 4
+> DRIVER nouveau
+> #DRIVER2 nvidia96xx (not compatible with X.org server 1.11)
+> --
+> NAME NVIDIA GeForce 6100 to GeForce 360
+> DRIVER nouveau
+> DRIVER2 nvidia-current
+> DRIVER2_NO_SSE nvidia96xx
+> --
+> NAME NVIDIA GeForce 400 series and later
+> DRIVER nouveau
+> DRIVER2 nvidia-current
+> DRIVER2_NO_SSE nvidia96xx
+
+Hmm, I guess we should make drakx-kbd-mouse-x11 not suggest nvidia173 or
+nvidia-current on non-SSE then, or add a new flag DRIVER2_NEEDS_SSE...
+
+>> Modified: ldetect-lst/trunk/lst/Cards+
+>> ===================================================================
+>> --- ldetect-lst/trunk/lst/Cards+	2011-12-02 16:46:06 UTC (rev 2236)
+>> +++ ldetect-lst/trunk/lst/Cards+	2011-12-02 18:35:53 UTC (rev 2237)
+>> @@ -260,11 +260,11 @@
+>>
+>>  NAME NVIDIA GeForce 2 MX to GeForce 4
+>>  DRIVER nouveau
+>> -DRIVER2 nvidia96xx
+>> +#DRIVER2 nvidia96xx (not compatible with X.org server 1.11)
+>>
+>>  NAME NVIDIA GeForce FX series
+>>  DRIVER nouveau
+>> -DRIVER2 nvidia173
+>> +#DRIVER2 nvidia173 (not compatible with X.org server 1.11)
+>>
+>>  NAME NVIDIA GeForce 6100 to GeForce 360
+>>  DRIVER nouveau
+> 
+
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010913.html b/zarb-ml/mageia-dev/2012-January/010913.html new file mode 100644 index 000000000..c0ab2e66c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010913.html @@ -0,0 +1,132 @@ + + + + [Mageia-dev] [soft-commits] [2237] disable nvidia173 and nvidia96xx as they do not support X. org server 1.11) + + + + + + + + + +

[Mageia-dev] [soft-commits] [2237] disable nvidia173 and nvidia96xx as they do not support X. org server 1.11)

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Jan 3 18:50:08 CET 2012 +

+
+ +
On 3 January 2012 18:21, Anssi Hannula <anssi at mageia.org> wrote:
+>>> disable nvidia173 and nvidia96xx as they do not support X.org server 1.11)
+>>
+>> Err... you only altered some of the nvidia96xx entries:
+>>
+>> $ grep nvidia96xx ../ldetect-lst/lst//Cards+  -B3
+>>
+>> NAME NVIDIA GeForce 2 MX to GeForce 4
+>> DRIVER nouveau
+>> #DRIVER2 nvidia96xx (not compatible with X.org server 1.11)
+>> --
+>> NAME NVIDIA GeForce 6100 to GeForce 360
+>> DRIVER nouveau
+>> DRIVER2 nvidia-current
+>> DRIVER2_NO_SSE nvidia96xx
+>> --
+>> NAME NVIDIA GeForce 400 series and later
+>> DRIVER nouveau
+>> DRIVER2 nvidia-current
+>> DRIVER2_NO_SSE nvidia96xx
+>
+> Hmm, I guess we should make drakx-kbd-mouse-x11 not suggest nvidia173 or
+> nvidia-current on non-SSE then, or add a new flag DRIVER2_NEEDS_SSE...
+
+Fine with a new flag.
+See this untested patch
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: sse.diff
+Type: application/octet-stream
+Size: 1610 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20120103/d64e6985/attachment.obj>
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: sse.diff
+Type: application/octet-stream
+Size: 1610 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20120103/d64e6985/attachment-0001.obj>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010914.html b/zarb-ml/mageia-dev/2012-January/010914.html new file mode 100644 index 000000000..4a60c060c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010914.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] Significant decrease of installed packages for a minimal installation + + + + + + + + + +

[Mageia-dev] Significant decrease of installed packages for a minimal installation

+ Maarten Vanraes + alien at rmail.be +
+ Tue Jan 3 20:42:44 CET 2012 +

+
+ +
Op dinsdag 03 januari 2012 15:59:31 schreef Wolfgang Bornath:
+> 2012/1/3 zezinho <lists.jjorge at free.fr>:
+> > Le mardi 3 janvier 2012 15:40:56, Wolfgang Bornath a écrit :
+> >> 2012/1/2 Païou <paiiou at free.fr>:
+> >> > I just did a minimal installation of Mageia 1 (with updates)
+> >> 
+> >> Can't confirm this. I just did the same on a netbook.
+> >> Custom desktop, unchecked all groups, minimal installation with X
+> >> Ran updates, uninstalled orphans.
+> > 
+> > It seems you did not use the updates for the first install. So the KDM
+> > was installed, and updating does not remove it.
+> 
+> I can only run updates AFTER installation (or at the end of
+> installation, if that works), no?
+
+maybe on installation he added in the media window the mirrorlisted entries?
+
+and thus the updates are being used when installing?
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010915.html b/zarb-ml/mageia-dev/2012-January/010915.html new file mode 100644 index 000000000..0d0f93324 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010915.html @@ -0,0 +1,126 @@ + + + + [Mageia-dev] ANN: gcc-4.6.2 landing on Cauldron + + + + + + + + + +

[Mageia-dev] ANN: gcc-4.6.2 landing on Cauldron

+ Kamil Rytarowski + n54 at gmx.com +
+ Tue Jan 3 21:22:27 CET 2012 +

+
+ +
I'm quoting the whole message just to remind it to others.
+
+W dniu 05.12.2011 15:26, Thomas Backlund pisze:
+> Hi,
+>
+> so... the long wait is over....
+>
+> I've submitted gcc-4.6.2-1.mga2 to core/release now.
+>
+> As soon as it's available on the primary mirror I'll invalidate the 
+> cauldron chroots on the BS to make sure the new gcc is used.
+>
+> Ater that I'll submit a new glibc and kernel so they are built with
+> the new toolchain.
+>
+> So, we now have glibc & the toolchain upgraded:
+> - glibc is at 2.14.1 (available in cauldron since 2011-10-24)
+> - binutils 2.22 (available in cauldron since 2011-11-28)
+> - gcc-4.6.2 (available later today (2011-12-05)
+>
+> Now, in order to provide a very good Mageia 2, every package should
+> be rebuilt with the new toolchain/glibc in order to make sure they
+> still build _and_ work correctly (and flush out any bugs in the
+> toolchain)
+>
+> Now this rebuild should be done preferably in BR order when possible,
+> to rule out bad interaction between packages and be preferably be
+> fully done by alpha3 or beta1 at the latest so we have time to fix
+> it properly for Mageia 2.
+Are we also talking about non-C++ or even plain-text only packages? Does 
+every package means *really every*?
+>
+> -- 
+> Thomas
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010916.html b/zarb-ml/mageia-dev/2012-January/010916.html new file mode 100644 index 000000000..68a0320a3 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010916.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release portaudio-19-18.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release portaudio-19-18.mga2

+ zezinho + lists.jjorge at free.fr +
+ Tue Jan 3 21:23:54 CET 2012 +

+
+ +
Le mardi 3 janvier 2012 16:48:54, Thierry Vignaud a écrit :
+> > - bump release to rebuild
+> "rebuild" is enough.
+> What is missing is "rebuild for ?_WHAT_?"
+
+Ok, I will put it next time. It is "rebuild for new libc"
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010917.html b/zarb-ml/mageia-dev/2012-January/010917.html new file mode 100644 index 000000000..eb2fb6c5e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010917.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release portaudio-19-18.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release portaudio-19-18.mga2

+ Kamil Rytarowski + n54 at gmx.com +
+ Tue Jan 3 21:25:54 CET 2012 +

+
+ +
W dniu 03.01.2012 21:23, zezinho pisze:
+> Le mardi 3 janvier 2012 16:48:54, Thierry Vignaud a écrit :
+>>> - bump release to rebuild
+>> "rebuild" is enough.
+>> What is missing is "rebuild for ?_WHAT_?"
+> Ok, I will put it next time. It is "rebuild for new libc"
+You can reedit the svn:log entry
+
+svn pe --revprop -r<revision>  svn:log svn+ssh://svn.mageia.org/svn/packages --editor-cmd nano
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010918.html b/zarb-ml/mageia-dev/2012-January/010918.html new file mode 100644 index 000000000..b70b83a0b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010918.html @@ -0,0 +1,124 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2

+ Anssi Hannula + anssi at mageia.org +
+ Tue Jan 3 22:05:12 CET 2012 +

+
+ +
On 02.01.2012 12:21, guillomovitch wrote:
+> Name        : dsniff                       Relocations: (not relocatable)
+> Version     : 2.4                               Vendor: Mageia.Org
+> Release     : 0.b1.1.mga2                   Build Date: Mon Jan  2 11:18:17 2012
+> Install Date: (not installed)               Build Host: ecosse
+> Group       : Monitoring                    Source RPM: (none)
+> Size        : 210074                           License: BSD
+> Signature   : (none)
+> Packager    : guillomovitch <guillomovitch>
+> URL         : http://www.monkey.org/~dugsong/dsniff/
+> Summary     : Network audit tools
+> Description :
+> Tools to audit network and to demonstrate the insecurity of cleartext
+> network protocols. Please do not abuse this software.
+> 
+> guillomovitch <guillomovitch> 2.4-0.b1.1.mga2:
+> + Revision: 189630
+> - drop epoch, we don't care about updating from mdv anymore
+
+We don't?
+
+Previous upgraders like me still have dsniff-2.4-0.b2.14mdv2010.1 on
+their MGA1 / cauldron systmes, which won't get upgraded to the MGA
+package without epoch.
+IMHO the epoch should be added.
+
+
+Also, not your fault but it seems genhdlist didn't handle the removal of
+epoch without altering rpm file name well, hdlists still show the epoch,
+causing urpmi to try upgrading to the now epoch-less version, causing
+the transaction to be rejected by rpm.
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010919.html b/zarb-ml/mageia-dev/2012-January/010919.html new file mode 100644 index 000000000..d6bf9c9bd --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010919.html @@ -0,0 +1,76 @@ + + + + [Mageia-dev] Emails + + + + + + + + + +

[Mageia-dev] Emails

+ Florian Hubold + doktor5000 at arcor.de +
+ Tue Jan 3 22:41:12 CET 2012 +

+
+ +
Am 02.01.2012 17:57, schrieb Pascal Terjan:
+> On Mon, Jan 2, 2012 at 16:39, Balcaen John <mikala at mageia.org> wrote:
+>> Le lundi 2 janvier 2012 13:34:05, Pascal Terjan a écrit :
+>>> Sorry, sent it initially to the wrong mailing list.
+>>>
+>>> Following a little change last night:
+>>> - Packager field of rpms is now "login <login>" (for example pterjan
+>>> <pterjan>) - Mails on changelog email are from login
+>>> <buildsystem-daemon at mageia.org - You should receive an email when a
+>>> package you submitted fails to build
+>> Only when it failed to build or also when it was rejected by the BS ?
+> Iurt only sends on build failure
+> I think youri should send it on reject but I did not check if it works
+>
+Still awesome change, thanks :)
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010920.html b/zarb-ml/mageia-dev/2012-January/010920.html new file mode 100644 index 000000000..952c64572 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010920.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release portaudio-19-18.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release portaudio-19-18.mga2

+ zezinho + lists.jjorge at free.fr +
+ Tue Jan 3 23:39:18 CET 2012 +

+
+ +
Le mardi 3 janvier 2012 21:25:54, Kamil Rytarowski a écrit :
+> You can reedit the svn:log entry
+> 
+> svn pe --revprop -r<revision>  svn:log
+> svn+ssh://svn.mageia.org/svn/packages --editor-cmd nano
+
+Learned! Thanks...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010921.html b/zarb-ml/mageia-dev/2012-January/010921.html new file mode 100644 index 000000000..3b5c63ac1 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010921.html @@ -0,0 +1,83 @@ + + + + [Mageia-dev] Emails + + + + + + + + + +

[Mageia-dev] Emails

+ Anssi Hannula + anssi at mageia.org +
+ Wed Jan 4 00:05:05 CET 2012 +

+
+ +
On 03.01.2012 23:41, Florian Hubold wrote:
+> Am 02.01.2012 17:57, schrieb Pascal Terjan:
+>> On Mon, Jan 2, 2012 at 16:39, Balcaen John <mikala at mageia.org> wrote:
+>>> Le lundi 2 janvier 2012 13:34:05, Pascal Terjan a écrit :
+>>>> Sorry, sent it initially to the wrong mailing list.
+>>>>
+>>>> Following a little change last night:
+>>>> - Packager field of rpms is now "login <login>" (for example pterjan
+>>>> <pterjan>) - Mails on changelog email are from login
+>>>> <buildsystem-daemon at mageia.org - You should receive an email when a
+>>>> package you submitted fails to build
+>>> Only when it failed to build or also when it was rejected by the BS ?
+>> Iurt only sends on build failure
+>> I think youri should send it on reject but I did not check if it works
+>>
+> Still awesome change, thanks :)
+> 
+
+Seems emi sends youri-submit failures (rejections), and it seems to work
+as well.
+
+-- 
+Anssi Hannula
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010922.html b/zarb-ml/mageia-dev/2012-January/010922.html new file mode 100644 index 000000000..d097d609a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010922.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release portaudio-19-18.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release portaudio-19-18.mga2

+ Florian Hubold + doktor5000 at arcor.de +
+ Wed Jan 4 00:07:36 CET 2012 +

+
+ +
Am 03.01.2012 23:39, schrieb zezinho:
+> Le mardi 3 janvier 2012 21:25:54, Kamil Rytarowski a écrit :
+>> You can reedit the svn:log entry
+>>
+>> svn pe --revprop -r<revision>  svn:log
+>> svn+ssh://svn.mageia.org/svn/packages --editor-cmd nano
+> Learned! Thanks...
+>
+Given that all packagers need a working ssh setup
+(check https://wiki.mageia.org/en/Packagers_ssh#How_it_works )
+you can omit the 
+
+    svn+ssh://svn.mageia.org/svn/packages
+
+part, and set EDITOR environment var in
+~/.bashrc to your favorite editor, and then for
+better reusability via bash recursive search (ctrl+r)
+maybe just use
+
+
+    svn pe --revprop svn:log -r<revision>
+
+inside a local checkout so that when you reuse it,
+less keystrokes required to launch this for another revision.
+HTH
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010923.html b/zarb-ml/mageia-dev/2012-January/010923.html new file mode 100644 index 000000000..d87e2367b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010923.html @@ -0,0 +1,120 @@ + + + + [Mageia-dev] comments in rpm changelog (was: gamin-0.1.10-8.mga2) + + + + + + + + + +

[Mageia-dev] comments in rpm changelog (was: gamin-0.1.10-8.mga2)

+ Anssi Hannula + anssi at mageia.org +
+ Wed Jan 4 00:26:27 CET 2012 +

+
+ +
On 04.01.2012 00:56, anssi wrote:
+> anssi <anssi> 0.1.10-8.mga2:
+> + Revision: 190205
+> - fix intermittent gam_server deadlock causing e.g. KDE applications to
+>   no longer start (fix-deadlock.patch, submitted upstream as gnome
+
+$ svn propget --revprop svn:log -r 190205
+svn+ssh://svn.mageia.org/svn/packages
+- fix intermittent gam_server deadlock causing e.g. KDE applications to
+  no longer start (fix-deadlock.patch, submitted upstream as gnome
+  #667230)
+
+Isn't this wrong, i.e. the #667230) shouldn't be removed as a "comment"?
+
+Or has it always been there, just only affecting lines whose first
+non-whitespace character is '#'?
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010924.html b/zarb-ml/mageia-dev/2012-January/010924.html new file mode 100644 index 000000000..e4fd031a8 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010924.html @@ -0,0 +1,112 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release gamin-0.1.10-8.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release gamin-0.1.10-8.mga2

+ Olav Vitters + olav at vitters.nl +
+ Wed Jan 4 00:36:51 CET 2012 +

+
+ +
On Tue, Jan 03, 2012 at 11:56:14PM +0100, anssi wrote:
+> + Revision: 190205
+> - fix intermittent gam_server deadlock causing e.g. KDE applications to
+>   no longer start (fix-deadlock.patch, submitted upstream as gnome
+
+Which upstream bug is that?
+
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010925.html b/zarb-ml/mageia-dev/2012-January/010925.html new file mode 100644 index 000000000..341d1d30b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010925.html @@ -0,0 +1,122 @@ + + + + [Mageia-dev] comments in rpm changelog + + + + + + + + + +

[Mageia-dev] comments in rpm changelog

+ Florian Hubold + doktor5000 at arcor.de +
+ Wed Jan 4 00:41:59 CET 2012 +

+
+ +
Am 04.01.2012 00:26, schrieb Anssi Hannula:
+> On 04.01.2012 00:56, anssi wrote:
+>> anssi <anssi> 0.1.10-8.mga2:
+>> + Revision: 190205
+>> - fix intermittent gam_server deadlock causing e.g. KDE applications to
+>>   no longer start (fix-deadlock.patch, submitted upstream as gnome
+> $ svn propget --revprop svn:log -r 190205
+> svn+ssh://svn.mageia.org/svn/packages
+> - fix intermittent gam_server deadlock causing e.g. KDE applications to
+>   no longer start (fix-deadlock.patch, submitted upstream as gnome
+>   #667230)
+>
+> Isn't this wrong, i.e. the #667230) shouldn't be removed as a "comment"?
+>
+> Or has it always been there, just only affecting lines whose first
+> non-whitespace character is '#'?
+>
+Latter seems the case, all other #bug mentions (which
+in all cases i've seen so far have something before the #)
+seem to not be stripped.
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010926.html b/zarb-ml/mageia-dev/2012-January/010926.html new file mode 100644 index 000000000..35917e273 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010926.html @@ -0,0 +1,112 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release gamin-0.1.10-8.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release gamin-0.1.10-8.mga2

+ Florian Hubold + doktor5000 at arcor.de +
+ Wed Jan 4 00:43:17 CET 2012 +

+
+ +
Am 04.01.2012 00:36, schrieb Olav Vitters:
+> On Tue, Jan 03, 2012 at 11:56:14PM +0100, anssi wrote:
+>> + Revision: 190205
+>> - fix intermittent gam_server deadlock causing e.g. KDE applications to
+>>   no longer start (fix-deadlock.patch, submitted upstream as gnome
+> Which upstream bug is that?
+>
+667230. See the other mail
+"comments in rpm changelog (was: gamin-0.1.10-8.mga2)"
+
+;)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010927.html b/zarb-ml/mageia-dev/2012-January/010927.html new file mode 100644 index 000000000..b889c275a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010927.html @@ -0,0 +1,119 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release gamin-0.1.10-8.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release gamin-0.1.10-8.mga2

+ Olav Vitters + olav at vitters.nl +
+ Wed Jan 4 00:59:04 CET 2012 +

+
+ +
On Wed, Jan 04, 2012 at 12:43:17AM +0100, Florian Hubold wrote:
+> Am 04.01.2012 00:36, schrieb Olav Vitters:
+> > On Tue, Jan 03, 2012 at 11:56:14PM +0100, anssi wrote:
+> >> + Revision: 190205
+> >> - fix intermittent gam_server deadlock causing e.g. KDE applications to
+> >>   no longer start (fix-deadlock.patch, submitted upstream as gnome
+> > Which upstream bug is that?
+> >
+> 667230. See the other mail
+> "comments in rpm changelog (was: gamin-0.1.10-8.mga2)"
+> 
+> ;)
+
+read other mailing lists before hitting reply?!? :P
+
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010928.html b/zarb-ml/mageia-dev/2012-January/010928.html new file mode 100644 index 000000000..09a59cff1 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010928.html @@ -0,0 +1,68 @@ + + + + [Mageia-dev] GNOME 2 panel applets + + + + + + + + + +

[Mageia-dev] GNOME 2 panel applets

+ Olav Vitters + olav at vitters.nl +
+ Wed Jan 4 01:02:45 CET 2012 +

+
+ +
On Mon, Jan 02, 2012 at 05:15:34PM -0500, andre999 wrote:
+> I followed the link in the bug report, to various other links.
+
+Cool! Thanks for the detailed answer. Not really a GNOME 2 specific
+project then, so seems fine.
+
+Reporter went on to suggest MATE :P  (IMO, crazy)
+
+-- 
+Regards,
+Olav
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010929.html b/zarb-ml/mageia-dev/2012-January/010929.html new file mode 100644 index 000000000..d88729d6d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010929.html @@ -0,0 +1,119 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2

+ Pascal Terjan + pterjan at gmail.com +
+ Wed Jan 4 01:32:22 CET 2012 +

+
+ +
On Tue, Jan 3, 2012 at 21:05, Anssi Hannula <anssi at mageia.org> wrote:
+> On 02.01.2012 12:21, guillomovitch wrote:
+>> Name        : dsniff                       Relocations: (not relocatable)
+>> Version     : 2.4                               Vendor: Mageia.Org
+>> Release     : 0.b1.1.mga2                   Build Date: Mon Jan  2 11:18:17 2012
+>> Install Date: (not installed)               Build Host: ecosse
+>> Group       : Monitoring                    Source RPM: (none)
+>> Size        : 210074                           License: BSD
+>> Signature   : (none)
+>> Packager    : guillomovitch <guillomovitch>
+>> URL         : http://www.monkey.org/~dugsong/dsniff/
+>> Summary     : Network audit tools
+>> Description :
+>> Tools to audit network and to demonstrate the insecurity of cleartext
+>> network protocols. Please do not abuse this software.
+>>
+>> guillomovitch <guillomovitch> 2.4-0.b1.1.mga2:
+>> + Revision: 189630
+>> - drop epoch, we don't care about updating from mdv anymore
+>
+> We don't?
+>
+> Previous upgraders like me still have dsniff-2.4-0.b2.14mdv2010.1 on
+> their MGA1 / cauldron systmes, which won't get upgraded to the MGA
+> package without epoch.
+> IMHO the epoch should be added.
+>
+>
+> Also, not your fault but it seems genhdlist didn't handle the removal of
+> epoch without altering rpm file name well, hdlists still show the epoch,
+> causing urpmi to try upgrading to the now epoch-less version, causing
+> the transaction to be rejected by rpm.
+
+Yes genhdlist2 only considers the filename to decide if a package was
+added/removed, and keeps the header if filename didn't change
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010930.html b/zarb-ml/mageia-dev/2012-January/010930.html new file mode 100644 index 000000000..3c23e2479 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010930.html @@ -0,0 +1,124 @@ + + + + [Mageia-dev] comments in rpm changelog + + + + + + + + + +

[Mageia-dev] comments in rpm changelog

+ Anssi Hannula + anssi at mageia.org +
+ Wed Jan 4 01:50:29 CET 2012 +

+
+ +
On 04.01.2012 01:41, Florian Hubold wrote:
+> Am 04.01.2012 00:26, schrieb Anssi Hannula:
+>> On 04.01.2012 00:56, anssi wrote:
+>>> anssi <anssi> 0.1.10-8.mga2:
+>>> + Revision: 190205
+>>> - fix intermittent gam_server deadlock causing e.g. KDE applications to
+>>>   no longer start (fix-deadlock.patch, submitted upstream as gnome
+>> $ svn propget --revprop svn:log -r 190205
+>> svn+ssh://svn.mageia.org/svn/packages
+>> - fix intermittent gam_server deadlock causing e.g. KDE applications to
+>>   no longer start (fix-deadlock.patch, submitted upstream as gnome
+>>   #667230)
+>>
+>> Isn't this wrong, i.e. the #667230) shouldn't be removed as a "comment"?
+>>
+>> Or has it always been there, just only affecting lines whose first
+>> non-whitespace character is '#'?
+>>
+> Latter seems the case, all other #bug mentions (which
+> in all cases i've seen so far have something before the #)
+> seem to not be stripped.
+
+Indeed the above holds true at least on rpm-4.8.1 of mga1, I didn't test
+further back, though.
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010931.html b/zarb-ml/mageia-dev/2012-January/010931.html new file mode 100644 index 000000000..4218cc70e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010931.html @@ -0,0 +1,119 @@ + + + + [Mageia-dev] [packages-commits] [190229] new version 2.5.0 + + + + + + + + + +

[Mageia-dev] [packages-commits] [190229] new version 2.5.0

+ John Balcaen + mikala at mageia.org +
+ Wed Jan 4 03:06:05 CET 2012 +

+
+ +
2012/1/3  <root at mageia.org>:
+> Revision 190229 Author fwang Date 2012-01-04 02:11:16 +0100 (Wed, 04 Jan
+> 2012)
+>
+> Log Message
+>
+> new version 2.5.0
+>
+> Modified Paths
+>
+> cauldron/digikam/current/SOURCES/sha1.lst
+> cauldron/digikam/current/SPECS/digikam.spec
+[...]
+Just in case digikam won't build until
+https://bugs.kde.org/show_bug.cgi?id=287772 is fixed, maybe you can
+help here ?
+
+
+-- 
+Balcaen John
+Jabber-id: mikala at jabber.littleboboy.net
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010932.html b/zarb-ml/mageia-dev/2012-January/010932.html new file mode 100644 index 000000000..6329d899c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010932.html @@ -0,0 +1,144 @@ + + + + [Mageia-dev] [soft-commits] [2237] disable nvidia173 and nvidia96xx as they do not support X. org server 1.11) + + + + + + + + + +

[Mageia-dev] [soft-commits] [2237] disable nvidia173 and nvidia96xx as they do not support X. org server 1.11)

+ blind Pete + 0123peter at gmail.com +
+ Wed Jan 4 03:52:13 CET 2012 +

+
+ +
on Wed, 4 Jan 2012 04:17
+in the Usenet newsgroup gmane.linux.mageia.devel
+Thierry Vignaud wrote:
+
+> On 2 December 2011 19:35,  <root-
+odJJhXpcy38dnm+yROfE0A at public.gmane.org> wrote:
+>> Revision 2237 Author anssi Date 2011-12-02 19:35:53 +0100 (Fri, 02 
+Dec 2011)
+>>
+>> Log Message
+>>
+>> disable nvidia173 and nvidia96xx as they do not support X.org server 
+1.11)
+> 
+> Err... you only altered some of the nvidia96xx entries:
+> 
+> $ grep nvidia96xx ../ldetect-lst/lst//Cards+  -B3
+> 
+> NAME NVIDIA GeForce 2 MX to GeForce 4
+> DRIVER nouveau
+> #DRIVER2 nvidia96xx (not compatible with X.org server 1.11)
+> --
+> NAME NVIDIA GeForce 6100 to GeForce 360
+> DRIVER nouveau
+> DRIVER2 nvidia-current
+> DRIVER2_NO_SSE nvidia96xx
+> --
+> NAME NVIDIA GeForce 400 series and later
+> DRIVER nouveau
+> DRIVER2 nvidia-current
+> DRIVER2_NO_SSE nvidia96xx
+> 
+>> Modified: ldetect-lst/trunk/lst/Cards+
+>> ===================================================================
+>> --- ldetect-lst/trunk/lst/Cards+	2011-12-02 16:46:06 UTC (rev 
+2236)
+>> +++ ldetect-lst/trunk/lst/Cards+	2011-12-02 18:35:53 UTC (rev 
+2237)
+>> @@ -260,11 +260,11 @@
+>>
+>>  NAME NVIDIA GeForce 2 MX to GeForce 4
+>>  DRIVER nouveau
+>> -DRIVER2 nvidia96xx
+>> +#DRIVER2 nvidia96xx (not compatible with X.org server 1.11)
+>>
+>>  NAME NVIDIA GeForce FX series
+>>  DRIVER nouveau
+>> -DRIVER2 nvidia173
+>> +#DRIVER2 nvidia173 (not compatible with X.org server 1.11)
+>>
+>>  NAME NVIDIA GeForce 6100 to GeForce 360
+>>  DRIVER nouveau
+
+Ahh.  I just started playing with 96xx updates on a 
+GeForce 2 MX machine.  Can't make it work.  I'll try 
+again later...  
+ 
+
+-- 
+sig goes here...  
+blind Pete  
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010933.html b/zarb-ml/mageia-dev/2012-January/010933.html new file mode 100644 index 000000000..be52f36c5 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010933.html @@ -0,0 +1,122 @@ + + + + [Mageia-dev] [packages-commits] [190229] new version 2.5.0 + + + + + + + + + +

[Mageia-dev] [packages-commits] [190229] new version 2.5.0

+ Thomas Spuhler + thomas at btspuhler.com +
+ Wed Jan 4 04:56:31 CET 2012 +

+
+ +
On Tuesday, January 03, 2012 07:06:05 PM John Balcaen wrote:
+> 2012/1/3  <root at mageia.org>:
+> > Revision 190229 Author fwang Date 2012-01-04 02:11:16 +0100 (Wed, 04 Jan
+> > 2012)
+> > 
+> > Log Message
+> > 
+> > new version 2.5.0
+> > 
+> > Modified Paths
+> > 
+> > cauldron/digikam/current/SOURCES/sha1.lst
+> > cauldron/digikam/current/SPECS/digikam.spec
+> 
+> [...]
+> Just in case digikam won't build until
+> https://bugs.kde.org/show_bug.cgi?id=287772 is fixed, maybe you can
+> help here ?
+Maybe this will motivate the developer of digikam to fix a nice program and 
+make it usable again. It has had some problems for much too long that haven't 
+gotten fixed.
+
+-- 
+Best regards
+Thomas Spuhler
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010934.html b/zarb-ml/mageia-dev/2012-January/010934.html new file mode 100644 index 000000000..671ecfad9 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010934.html @@ -0,0 +1,119 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2

+ Thomas Backlund + tmb at mageia.org +
+ Wed Jan 4 10:03:11 CET 2012 +

+
+ +
Anssi Hannula skrev 3.1.2012 23:05:
+> On 02.01.2012 12:21, guillomovitch wrote:
+>> Name        : dsniff                       Relocations: (not relocatable)
+>> Version     : 2.4                               Vendor: Mageia.Org
+>> Release     : 0.b1.1.mga2                   Build Date: Mon Jan  2 11:18:17 2012
+>> Install Date: (not installed)               Build Host: ecosse
+>> Group       : Monitoring                    Source RPM: (none)
+>> Size        : 210074                           License: BSD
+>> Signature   : (none)
+>> Packager    : guillomovitch<guillomovitch>
+>> URL         : http://www.monkey.org/~dugsong/dsniff/
+>> Summary     : Network audit tools
+>> Description :
+>> Tools to audit network and to demonstrate the insecurity of cleartext
+>> network protocols. Please do not abuse this software.
+>>
+>> guillomovitch<guillomovitch>  2.4-0.b1.1.mga2:
+>> + Revision: 189630
+>> - drop epoch, we don't care about updating from mdv anymore
+>
+> We don't?
+>
+
+Oh yes we do. Atleast from 2010.1
+
+> Previous upgraders like me still have dsniff-2.4-0.b2.14mdv2010.1 on
+> their MGA1 / cauldron systmes, which won't get upgraded to the MGA
+> package without epoch.
+> IMHO the epoch should be added.
+>
+
+Yeah, it must be fixed.
+
+--
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010935.html b/zarb-ml/mageia-dev/2012-January/010935.html new file mode 100644 index 000000000..b8d5b25f8 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010935.html @@ -0,0 +1,124 @@ + + + + [Mageia-dev] [packages-commits] [190229] new version 2.5.0 + + + + + + + + + +

[Mageia-dev] [packages-commits] [190229] new version 2.5.0

+ John Balcaen + mikala at mageia.org +
+ Wed Jan 4 10:36:19 CET 2012 +

+
+ +
2012/1/4 Thomas Spuhler <thomas at btspuhler.com>:
+> On Tuesday, January 03, 2012 07:06:05 PM John Balcaen wrote:
+>> 2012/1/3  <root at mageia.org>:
+>> > Revision 190229 Author fwang Date 2012-01-04 02:11:16 +0100 (Wed, 04 Jan
+>> > 2012)
+>> >
+>> > Log Message
+>> >
+>> > new version 2.5.0
+>> >
+>> > Modified Paths
+>> >
+>> > cauldron/digikam/current/SOURCES/sha1.lst
+>> > cauldron/digikam/current/SPECS/digikam.spec
+>>
+>> [...]
+>> Just in case digikam won't build until
+>> https://bugs.kde.org/show_bug.cgi?id=287772 is fixed, maybe you can
+>> help here ?
+> Maybe this will motivate the developer of digikam to fix a nice program and
+> make it usable again. It has had some problems for much too long that haven't
+> gotten fixed.
+I'm not sure to understand ;o)
+
+-- 
+Balcaen John
+Jabber-id: mikala at jabber.littleboboy.net
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010936.html b/zarb-ml/mageia-dev/2012-January/010936.html new file mode 100644 index 000000000..b375ff2d3 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010936.html @@ -0,0 +1,129 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Wed Jan 4 10:51:40 CET 2012 +

+
+ +
Le 03/01/2012 22:05, Anssi Hannula a écrit :
+> On 02.01.2012 12:21, guillomovitch wrote:
+>> Name        : dsniff                       Relocations: (not relocatable)
+>> Version     : 2.4                               Vendor: Mageia.Org
+>> Release     : 0.b1.1.mga2                   Build Date: Mon Jan  2 11:18:17 2012
+>> Install Date: (not installed)               Build Host: ecosse
+>> Group       : Monitoring                    Source RPM: (none)
+>> Size        : 210074                           License: BSD
+>> Signature   : (none)
+>> Packager    : guillomovitch<guillomovitch>
+>> URL         : http://www.monkey.org/~dugsong/dsniff/
+>> Summary     : Network audit tools
+>> Description :
+>> Tools to audit network and to demonstrate the insecurity of cleartext
+>> network protocols. Please do not abuse this software.
+>>
+>> guillomovitch<guillomovitch>  2.4-0.b1.1.mga2:
+>> + Revision: 189630
+>> - drop epoch, we don't care about updating from mdv anymore
+>
+> We don't?
+AFAIK, smooth upgrade garantee was only for mga1.
+
+> Previous upgraders like me still have dsniff-2.4-0.b2.14mdv2010.1 on
+> their MGA1 / cauldron systmes, which won't get upgraded to the MGA
+> package without epoch.
+> IMHO the epoch should be added.
+Well, given the target population, I though it was not worth to bloat 
+the spec file forever just to handle a transitional issue. But feel free 
+to readd it.
+
+-- 
+BOFH excuse #260:
+
+We're upgrading /dev/null
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010937.html b/zarb-ml/mageia-dev/2012-January/010937.html new file mode 100644 index 000000000..73cf7adfb --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010937.html @@ -0,0 +1,119 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2

+ Michael Scherer + misc at zarb.org +
+ Wed Jan 4 10:54:11 CET 2012 +

+
+ +
Le mercredi 04 janvier 2012 à 11:03 +0200, Thomas Backlund a écrit :
+> Anssi Hannula skrev 3.1.2012 23:05:
+> > On 02.01.2012 12:21, guillomovitch wrote:
+> >> Name        : dsniff                       Relocations: (not relocatable)
+> >> Version     : 2.4                               Vendor: Mageia.Org
+> >> Release     : 0.b1.1.mga2                   Build Date: Mon Jan  2 11:18:17 2012
+> >> Install Date: (not installed)               Build Host: ecosse
+> >> Group       : Monitoring                    Source RPM: (none)
+> >> Size        : 210074                           License: BSD
+> >> Signature   : (none)
+> >> Packager    : guillomovitch<guillomovitch>
+> >> URL         : http://www.monkey.org/~dugsong/dsniff/
+> >> Summary     : Network audit tools
+> >> Description :
+> >> Tools to audit network and to demonstrate the insecurity of cleartext
+> >> network protocols. Please do not abuse this software.
+> >>
+> >> guillomovitch<guillomovitch>  2.4-0.b1.1.mga2:
+> >> + Revision: 189630
+> >> - drop epoch, we don't care about updating from mdv anymore
+> >
+> > We don't?
+> >
+> 
+> Oh yes we do. Atleast from 2010.1
+
+We did for 1, not for 2 or cauldron or anything else. So as long the
+package is not pushed on 1, I think we agreed that people could not care
+about upgrade path from Mandriva.
+
+-- 
+Michael Scherer
+
+
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010938.html b/zarb-ml/mageia-dev/2012-January/010938.html new file mode 100644 index 000000000..9f975e4dc --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010938.html @@ -0,0 +1,110 @@ + + + + [Mageia-dev] BS down for now + + + + + + + + + +

[Mageia-dev] BS down for now

+ Michael Scherer + misc at zarb.org +
+ Wed Jan 4 10:57:16 CET 2012 +

+
+ +
Hi,
+
+as signaled by jq and mikala, the BS is down for the moment, a issue
+with chroot. It sems perl(URPM) is no longer provided ( and urpmi
+provide perl(urpm) instead ), and therefore, we cannot install
+basesystem.
+
+Sysadmins are looking at the problem, we will keep you updated.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010939.html b/zarb-ml/mageia-dev/2012-January/010939.html new file mode 100644 index 000000000..727cf8abe --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010939.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] External monitor resolution probing broken since this morning + + + + + + + + + +

[Mageia-dev] External monitor resolution probing broken since this morning

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Wed Jan 4 11:42:43 CET 2012 +

+
+ +
Le 03/01/2012 18:17, Anssi Hannula a écrit :
+> Does the Xorg.0.log contain a modelist and/or raw EDID data?
+>
+> If so, do those look correct? (you can use e.g. monitor-parse-edid or
+> just paste here)
+The modelines listed in xorg.0.log match xrandr output:
+[  6014.632] (II) intel(0): EDID for output VGA1
+[  6014.632] (II) intel(0): Printing probed modes for output VGA1
+[  6014.632] (II) intel(0): Modeline "1024x768"x60.0   65.00  1024 1048 
+1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz)
+[  6014.632] (II) intel(0): Modeline "800x600"x60.3   40.00  800 840 968 
+1056  600 601 605 628 +hsync +vsync (37.9 kHz)
+[  6014.632] (II) intel(0): Modeline "800x600"x56.2   36.00  800 824 896 
+1024  600 601 603 625 +hsync +vsync (35.2 kHz)
+[  6014.632] (II) intel(0): Modeline "848x480"x60.0   33.75  848 864 976 
+1088  480 486 494 517 +hsync +vsync (31.0 kHz)
+[  6014.632] (II) intel(0): Modeline "640x480"x59.9   25.18  640 656 752 
+800  480 489 492 525 -hsync -vsync (31.5 kHz)
+
+Technically, they are not wrong, just truncated.
+
+What's interesting, tough, is that xrandr --prop only has EDID output 
+for the laptop panel (LVDS1), not for the external screen.
+-- 
+BOFH excuse #261:
+
+The Usenet news is out of date
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010940.html b/zarb-ml/mageia-dev/2012-January/010940.html new file mode 100644 index 000000000..aefbe2454 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010940.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] BS down for now + + + + + + + + + +

[Mageia-dev] BS down for now

+ Pascal Terjan + pterjan at gmail.com +
+ Wed Jan 4 11:44:55 CET 2012 +

+
+ +
On Wed, Jan 4, 2012 at 09:57, Michael Scherer <misc at zarb.org> wrote:
+> Hi,
+>
+> as signaled by jq and mikala, the BS is down for the moment, a issue
+> with chroot. It sems perl(URPM) is no longer provided ( and urpmi
+> provide perl(urpm) instead ), and therefore, we cannot install
+> basesystem.
+>
+> Sysadmins are looking at the problem, we will keep you updated.
+
+It seems the package had been removed from the mirrors (investigation
+in progress), it has been restored and build system should work fine.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010941.html b/zarb-ml/mageia-dev/2012-January/010941.html new file mode 100644 index 000000000..91ce1b478 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010941.html @@ -0,0 +1,85 @@ + + + + [Mageia-dev] External monitor resolution probing broken since this morning + + + + + + + + + +

[Mageia-dev] External monitor resolution probing broken since this morning

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Wed Jan 4 13:01:04 CET 2012 +

+
+ +
Le 04/01/2012 11:42, Guillaume Rousse a écrit :
+> What's interesting, tough, is that xrandr --prop only has EDID output
+> for the laptop panel (LVDS1), not for the external screen.
+After switching to another DVI plug on the monitor, and switching back 
+to the original one, everything went back to normal. I guess it was some 
+physical contact issue :/
+
+-- 
+BOFH excuse #190:
+
+Proprietary Information.
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010942.html b/zarb-ml/mageia-dev/2012-January/010942.html new file mode 100644 index 000000000..09148e546 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010942.html @@ -0,0 +1,121 @@ + + + + [Mageia-dev] [packages-commits] [190229] new version 2.5.0 + + + + + + + + + +

[Mageia-dev] [packages-commits] [190229] new version 2.5.0

+ Angelo Naselli + anaselli at linux.it +
+ Wed Jan 4 13:17:23 CET 2012 +

+
+ +
In data mercoledì 4 gennaio 2012 03:06:05, John Balcaen ha scritto:
+> 2012/1/3  <root at mageia.org>:
+> > Revision 190229 Author fwang Date 2012-01-04 02:11:16 +0100 (Wed, 04 Jan
+> > 2012)
+> > 
+> > Log Message
+> > 
+> > new version 2.5.0
+> > 
+> > Modified Paths
+> > 
+> > cauldron/digikam/current/SOURCES/sha1.lst
+> > cauldron/digikam/current/SPECS/digikam.spec
+> 
+> [...]
+> Just in case digikam won't build until
+> https://bugs.kde.org/show_bug.cgi?id=287772 is fixed, maybe you can
+> help here ?
+John, can you ping me via irc, so that i can try to understand the problem?
+
+-- 
+	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/20120104/cb09b249/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010943.html b/zarb-ml/mageia-dev/2012-January/010943.html new file mode 100644 index 000000000..497a7e8d3 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010943.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2

+ Johnny A. Solbu + cooker at solbu.net +
+ Wed Jan 4 14:18:33 CET 2012 +

+
+ +
On Wednesday 04 January 2012 10:54, Michael Scherer wrote:
+> I think we agreed that people could not care
+> about upgrade path from Mandriva.
+
+So, people like me who still run 2010.2 on many systems and later on would like to move to mga2 should first upgrade to mga1 and then upgrade to mga2?
+Or am I missing something?
+
+-- 
+Johnny A. Solbu
+PGP key ID: 0xFA687324
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 189 bytes
+Desc: This is a digitally signed message part.
+URL: </pipermail/mageia-dev/attachments/20120104/c7daeaa0/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010944.html b/zarb-ml/mageia-dev/2012-January/010944.html new file mode 100644 index 000000000..9f71bcca9 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010944.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Wed Jan 4 15:16:00 CET 2012 +

+
+ +
Le 04/01/2012 14:18, Johnny A. Solbu a écrit :
+> On Wednesday 04 January 2012 10:54, Michael Scherer wrote:
+>> I think we agreed that people could not care
+>> about upgrade path from Mandriva.
+>
+> So, people like me who still run 2010.2 on many systems and later on would like to move to mga2 should first upgrade to mga1 and then upgrade to mga2?
+> Or am I missing something?
+No, 'no smooth upgrade garantee' only means you'll need to perform some 
+manual update procedure for some very specific packages. For instance 
+here, if you have dsniff installed, it won't be automatically upgraded, 
+and you'll have to uninstall it first:
+rpm -e dsniff
+urpmi dsniff
+
+-- 
+BOFH excuse #407:
+
+Route flapping at the NAP.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010945.html b/zarb-ml/mageia-dev/2012-January/010945.html new file mode 100644 index 000000000..07f24f745 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010945.html @@ -0,0 +1,121 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2

+ Anssi Hannula + anssi at mageia.org +
+ Wed Jan 4 15:16:02 CET 2012 +

+
+ +
On 04.01.2012 11:54, Michael Scherer wrote:
+> Le mercredi 04 janvier 2012 à 11:03 +0200, Thomas Backlund a écrit :
+>> Anssi Hannula skrev 3.1.2012 23:05:
+>>> On 02.01.2012 12:21, guillomovitch wrote:
+>>>> Name        : dsniff                       Relocations: (not relocatable)
+>>>> Version     : 2.4                               Vendor: Mageia.Org
+>>>> Release     : 0.b1.1.mga2                   Build Date: Mon Jan  2 11:18:17 2012
+>>>> Install Date: (not installed)               Build Host: ecosse
+>>>> Group       : Monitoring                    Source RPM: (none)
+>>>> Size        : 210074                           License: BSD
+>>>> Signature   : (none)
+>>>> Packager    : guillomovitch<guillomovitch>
+>>>> URL         : http://www.monkey.org/~dugsong/dsniff/
+>>>> Summary     : Network audit tools
+>>>> Description :
+>>>> Tools to audit network and to demonstrate the insecurity of cleartext
+>>>> network protocols. Please do not abuse this software.
+>>>>
+>>>> guillomovitch<guillomovitch>  2.4-0.b1.1.mga2:
+>>>> + Revision: 189630
+>>>> - drop epoch, we don't care about updating from mdv anymore
+>>>
+>>> We don't?
+>>>
+>>
+>> Oh yes we do. Atleast from 2010.1
+> 
+> We did for 1, not for 2 or cauldron or anything else. So as long the
+> package is not pushed on 1, I think we agreed that people could not care
+> about upgrade path from Mandriva.
+
+Well, I don't like that, IMO we should not remove upgradeability so
+soon, even if we won't officially support it.
+
+But anyway, this affects people doing 2010.1->mga1->mga2 as well... Or
+are you saying that isn't supported either, and people should do new
+installs??
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010946.html b/zarb-ml/mageia-dev/2012-January/010946.html new file mode 100644 index 000000000..b737adc05 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010946.html @@ -0,0 +1,130 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Wed Jan 4 15:27:38 CET 2012 +

+
+ +
Le 04/01/2012 15:16, Anssi Hannula a écrit :
+> On 04.01.2012 11:54, Michael Scherer wrote:
+>> Le mercredi 04 janvier 2012 à 11:03 +0200, Thomas Backlund a écrit :
+>>> Anssi Hannula skrev 3.1.2012 23:05:
+>>>> On 02.01.2012 12:21, guillomovitch wrote:
+>>>>> Name        : dsniff                       Relocations: (not relocatable)
+>>>>> Version     : 2.4                               Vendor: Mageia.Org
+>>>>> Release     : 0.b1.1.mga2                   Build Date: Mon Jan  2 11:18:17 2012
+>>>>> Install Date: (not installed)               Build Host: ecosse
+>>>>> Group       : Monitoring                    Source RPM: (none)
+>>>>> Size        : 210074                           License: BSD
+>>>>> Signature   : (none)
+>>>>> Packager    : guillomovitch<guillomovitch>
+>>>>> URL         : http://www.monkey.org/~dugsong/dsniff/
+>>>>> Summary     : Network audit tools
+>>>>> Description :
+>>>>> Tools to audit network and to demonstrate the insecurity of cleartext
+>>>>> network protocols. Please do not abuse this software.
+>>>>>
+>>>>> guillomovitch<guillomovitch>   2.4-0.b1.1.mga2:
+>>>>> + Revision: 189630
+>>>>> - drop epoch, we don't care about updating from mdv anymore
+>>>>
+>>>> We don't?
+>>>>
+>>>
+>>> Oh yes we do. Atleast from 2010.1
+>>
+>> We did for 1, not for 2 or cauldron or anything else. So as long the
+>> package is not pushed on 1, I think we agreed that people could not care
+>> about upgrade path from Mandriva.
+>
+> Well, I don't like that, IMO we should not remove upgradeability so
+> soon, even if we won't officially support it.
+>
+> But anyway, this affects people doing 2010.1->mga1->mga2 as well... Or
+> are you saying that isn't supported either, and people should do new
+> installs??
+No, I just find it painful to add an ugly epoch tag in the spec file 
+just to avoid some very few clever people (clever enough to run this 
+kind of software) the need to run a pair of commands to update this 
+specific package.
+
+However, if you prefer, just fix the spec file, I don't really care.
+-- 
+BOFH excuse #171:
+
+NOTICE: alloc: /dev/null: filesystem full
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010947.html b/zarb-ml/mageia-dev/2012-January/010947.html new file mode 100644 index 000000000..d323d01e0 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010947.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] gma500 display driver problem with Mageia 2 alpha + + + + + + + + + +

[Mageia-dev] gma500 display driver problem with Mageia 2 alpha

+ Mika Laitio + lamikr at pilppa.org +
+ Mon Jan 2 13:21:24 CET 2012 +

+
+ +
Hi
+
+I got couple of years old Nokia booklet which has gma500 gpu and 
+1280x768 panel. I installed i586 version of Mageia 2 alpha2. 
+Installation went fine but on next reboot the ui failed to show up.
+
+I went to drakconf console and there the display drake identified the 
+card ok and suggested using "Poulsbo US15W (gma500)" driver.
+That will install dkms-psb module that will howeve fail to load with 3.0 
+kernels.
+
+If I force the vesa mode in drakconf, then the display works ok in 
+1280x768 mode. (Thought not the world fastest display).
+
+Another option is to use fbdev drivers that to my understand uses
+new psb_gfx module that is available for 3.2 kernels.
+(/lib/modules/3.2.0-desktop586-0.rc7.2.mga2/kernel/drivers/staging/gma500/psb_gfx.ko.gz 
+on latest mageia devel kernel)
+
+With the fbdev kernel, I could however select the 800x600 resolution in 
+maximum with drakconf. Any idea what should be changed in drakconf
+to enable the psb_gfx/fbdev driver by default with gma500 and to allow
+to select higher resolution like 1280x768?
+
+At the moment I have updated all packages to latest versions in devel 
+repositories.
+
+# lsmod | grep psb_gfx
+psb_gfx               210260  0
+drm_kms_helper         32592  1 psb_gfx
+drm                   195723  2 psb_gfx,drm_kms_helper
+i2c_algo_bit           13080  1 psb_gfx
+i2c_core               29808  6 
+videodev,psb_gfx,i2c_isch,drm_kms_helper,drm,i2c_algo_bit
+video                  18641  2 psb_gfx,poulsbo
+
+Mika
+
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010948.html b/zarb-ml/mageia-dev/2012-January/010948.html new file mode 100644 index 000000000..7957b424d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010948.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] gma500 display driver problem with Mageia 2 alpha + + + + + + + + + +

[Mageia-dev] gma500 display driver problem with Mageia 2 alpha

+ Florian Hubold + doktor5000 at arcor.de +
+ Wed Jan 4 16:21:38 CET 2012 +

+
+ +
Am 02.01.2012 13:21, schrieb Mika Laitio:
+> Hi
+>
+> I got couple of years old Nokia booklet which has gma500 gpu and 1280x768
+> panel. I installed i586 version of Mageia 2 alpha2. Installation went fine
+> but on next reboot the ui failed to show up.
+>
+> I went to drakconf console and there the display drake identified the card ok
+> and suggested using "Poulsbo US15W (gma500)" driver.
+> That will install dkms-psb module that will howeve fail to load with 3.0
+> kernels.
+>
+> If I force the vesa mode in drakconf, then the display works ok in 1280x768
+> mode. (Thought not the world fastest display).
+>
+> Another option is to use fbdev drivers that to my understand uses
+> new psb_gfx module that is available for 3.2 kernels.
+> (/lib/modules/3.2.0-desktop586-0.rc7.2.mga2/kernel/drivers/staging/gma500/psb_gfx.ko.gz
+> on latest mageia devel kernel)
+>
+> With the fbdev kernel, I could however select the 800x600 resolution in
+> maximum with drakconf. Any idea what should be changed in drakconf
+> to enable the psb_gfx/fbdev driver by default with gma500 and to allow
+> to select higher resolution like 1280x768?
+Sorry, i don't have a GMA500 aka Poulsbo, but from what i remember investigating
+for alternatives to this driver (which is prone to breakage due to kernel updates)
+maybe you want to have a look at
+https://wiki.ubuntu.com/HardwareSupportComponentsVideoCardsPoulsbo
+and https://wiki.archlinux.org/index.php/Poulsbo#Kernel.27s_psb-gfx_module
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010949.html b/zarb-ml/mageia-dev/2012-January/010949.html new file mode 100644 index 000000000..5dd53795c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010949.html @@ -0,0 +1,148 @@ + + + + [Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement + + + + + + + + + +

[Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement

+ Luc Menut + lmenut at free.fr +
+ Wed Jan 4 16:53:40 CET 2012 +

+
+ +
Hello,
+
+We have recently discussed here about task-obsolete.
+http://www.mail-archive.com/mageia-dev@mageia.org/msg09762.html
+https://bugs.mageia.org/show_bug.cgi?id=3786
+
+I like the idea.
+But I think that we need to inform the user about the package(s) that we 
+will obsolete and remove on his system (and why: security, ..).
+So I tried to use README.*.urpmi to do this.
+But I found that currently, urpmi and rpmdrake don't handle very well 
+optional README.*.urpmi (%ghost); they always display information's 
+screen, even if the file doesn't exist.
+
+So, I propose here 2 enhancements for README.*.urpmi (POC patch for 
+urpm/install.pm, and task-obsolete.spec in attachment):
+
+1) add support for optional README.*.urpmi (%ghost in spec):
+This will allow to build this README.*.urpmi at install time in %pre, 
+%post or %trigger only when it's necessary.
+One use case from the recent past in my mind:
+we have no way to inform users that still use nspluginwrapper + i586 
+flashplayer on x86_64 (and only them), that this is now deprecated and 
+they should replace the i586 by the x86_64 flashplayer,
+https://bugs.mageia.org/show_bug.cgi?id=2146#c22
+https://bugs.mageia.org/show_bug.cgi?id=2146#c25
+
+2) handle README.*.(obsolete|deprecated).urpmi
+In order to display informations about the deprecated or obsoleted 
+package(s), I suggest to handle 2 new kinds of README.*.urpmi:
+- README."nameObsoletedPackage".obsolete.urpmi to inform about the 
+package we obsolete by task-obsolete
+e.g. java-1.6.0-sun*, https://bugs.mageia.org/show_bug.cgi?id=3101
+
+- README."nameDeprecatedPackage".deprecated.urpmi to inform about 
+package that we considere as deprecated, but we have no reason (no 
+vulnerability, security, ...) to force uninstallation (task-deprecated?).
+
+What do you think ?
+
+
+
+
+-- 
+Luc Menut
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: urpm-add_ghost_and_deprecated_obsolete_README_urpmi.patch
+Type: text/x-patch
+Size: 615 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20120104/19ecfd68/attachment.bin>
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: task-obsolete.spec
+Type: text/x-rpm-spec
+Size: 1124 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20120104/19ecfd68/attachment-0001.bin>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010950.html b/zarb-ml/mageia-dev/2012-January/010950.html new file mode 100644 index 000000000..abf1164e2 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010950.html @@ -0,0 +1,168 @@ + + + + [Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement + + + + + + + + + +

[Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Wed Jan 4 17:20:59 CET 2012 +

+
+ +
Le 04/01/2012 16:53, Luc Menut a écrit :
+> Hello,
+>
+> We have recently discussed here about task-obsolete.
+> http://www.mail-archive.com/mageia-dev@mageia.org/msg09762.html
+> https://bugs.mageia.org/show_bug.cgi?id=3786
+>
+> I like the idea.
+> But I think that we need to inform the user about the package(s) that we
+> will obsolete and remove on his system (and why: security, ..).
+> So I tried to use README.*.urpmi to do this.
+> But I found that currently, urpmi and rpmdrake don't handle very well
+> optional README.*.urpmi (%ghost); they always display information's
+> screen, even if the file doesn't exist.
+>
+> So, I propose here 2 enhancements for README.*.urpmi (POC patch for
+> urpm/install.pm, and task-obsolete.spec in attachment):
+>
+> 1) add support for optional README.*.urpmi (%ghost in spec):
+> This will allow to build this README.*.urpmi at install time in %pre,
+> %post or %trigger only when it's necessary.
+That will create files on the system unknown from rpm database, and 
+unknown from urpmi too.
+
+> One use case from the recent past in my mind:
+> we have no way to inform users that still use nspluginwrapper + i586
+> flashplayer on x86_64 (and only them), that this is now deprecated and
+> they should replace the i586 by the x86_64 flashplayer,
+> https://bugs.mageia.org/show_bug.cgi?id=2146#c22
+> https://bugs.mageia.org/show_bug.cgi?id=2146#c25
+>
+> 2) handle README.*.(obsolete|deprecated).urpmi
+> In order to display informations about the deprecated or obsoleted
+> package(s), I suggest to handle 2 new kinds of README.*.urpmi:
+> - README."nameObsoletedPackage".obsolete.urpmi to inform about the
+> package we obsolete by task-obsolete
+> e.g. java-1.6.0-sun*, https://bugs.mageia.org/show_bug.cgi?id=3101
+>
+> - README."nameDeprecatedPackage".deprecated.urpmi to inform about
+> package that we considere as deprecated, but we have no reason (no
+> vulnerability, security, ...) to force uninstallation (task-deprecated?).
+>
+> What do you think ?
+Rather than focusing on shiny automatic display mechanisms, I'd rather 
+work on information content.
+
+We currently have a ugly mix of README.mdk (4), README.mdv (5), 
+README.urpmi (46), README.update.urpmi (1), eventually others, without 
+any clue about their internal consistency. The last one I saw 
+(roundcubemail) had quite a bunch of informations about package upgrade, 
+but nothing about post-installation, for instance. Some of them use very 
+personal tone (Hello, this is Oden, your favorite apache manager, 
+advising you to visit my own web site to get additional modules, 
+cheers), while other are purely technical instructions (run mysql with 
+this file to create the database).
+
+We also have some packages (such as postfix) advising users to read this 
+file in their description:
+PLEASE READ THE %{_defaultdocdir}/%{name}/README.MDK FILE.
+
+So, today we have heterogeneous information cluttered in a gazillion 
+different microfiles, a subset of them being automatically displayed 
+during installation (ruining urpmi mass update output).
+
+Here are a few proposal of mines to make the situation better:
+- use a unique file name, enforced by convention, rather than references 
+in package description, the same way Debian does with README.debian
+- display its content only in graphical context: command-line users 
+usually know about this kind of convention to get information themselves
+- use standardised file content and markup to allow rpmdrake and other 
+graphical tools to achieve the same kind of selection than file 
+splitting today
+- define some kind of policy of what should be there, and what should 
+not, to achieve minimal consistency
+-- 
+BOFH excuse #187:
+
+Reformatting Page. Wait...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010951.html b/zarb-ml/mageia-dev/2012-January/010951.html new file mode 100644 index 000000000..ef8621b12 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010951.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] (likely Quick) meeting tonight + + + + + + + + + +

[Mageia-dev] (likely Quick) meeting tonight

+ Michael Scherer + misc at zarb.org +
+ Wed Jan 4 17:35:19 CET 2012 +

+
+ +
Hi,
+
+quick summary for tonight :
+- announce for alpha 3
+
+( ennael will not be here, and I may be late but do not plan to, but you
+never know with Paris public transportation )
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010952.html b/zarb-ml/mageia-dev/2012-January/010952.html new file mode 100644 index 000000000..611e7516a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010952.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement + + + + + + + + + +

[Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement

+ Johnny A. Solbu + cooker at solbu.net +
+ Wed Jan 4 17:55:40 CET 2012 +

+
+ +
On Wednesday 04 January 2012 17:20, Guillaume Rousse wrote:
+> a subset of them being automatically displayed during installation (ruining urpmi mass update output).
+
+I have an idea regarding this.
+What about storing all those notices in a file during install that one can review after the (automatic) update is complete. Then one can read it in calm and peace without having to remember to having to use " |tee autoinstall.txt" and what not, or reading like mad durng install and remember all info that is briefly displayed before it's scrolled away.
+
+I have no idea on how hard it might be to implement thou. Just thinking out loud. ;-)=
+
+-- 
+Johnny A. Solbu
+PGP key ID: 0xFA687324
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 189 bytes
+Desc: This is a digitally signed message part.
+URL: </pipermail/mageia-dev/attachments/20120104/a04e74ec/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010953.html b/zarb-ml/mageia-dev/2012-January/010953.html new file mode 100644 index 000000000..feeb38eb3 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010953.html @@ -0,0 +1,120 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2

+ Thomas Backlund + tmb at mageia.org +
+ Wed Jan 4 18:05:28 CET 2012 +

+
+ +
04.01.2012 11:54, Michael Scherer skrev:
+> Le mercredi 04 janvier 2012 à 11:03 +0200, Thomas Backlund a écrit :
+>> Anssi Hannula skrev 3.1.2012 23:05:
+>>> On 02.01.2012 12:21, guillomovitch wrote:
+>>>> Name        : dsniff                       Relocations: (not relocatable)
+>>>> Version     : 2.4                               Vendor: Mageia.Org
+>>>> Release     : 0.b1.1.mga2                   Build Date: Mon Jan  2 11:18:17 2012
+>>>> Install Date: (not installed)               Build Host: ecosse
+>>>> Group       : Monitoring                    Source RPM: (none)
+>>>> Size        : 210074                           License: BSD
+>>>> Signature   : (none)
+>>>> Packager    : guillomovitch<guillomovitch>
+>>>> URL         : http://www.monkey.org/~dugsong/dsniff/
+>>>> Summary     : Network audit tools
+>>>> Description :
+>>>> Tools to audit network and to demonstrate the insecurity of cleartext
+>>>> network protocols. Please do not abuse this software.
+>>>>
+>>>> guillomovitch<guillomovitch>   2.4-0.b1.1.mga2:
+>>>> + Revision: 189630
+>>>> - drop epoch, we don't care about updating from mdv anymore
+>>>
+>>> We don't?
+>>>
+>>
+>> Oh yes we do. Atleast from 2010.1
+>
+> We did for 1, not for 2 or cauldron or anything else. So as long the
+> package is not pushed on 1, I think we agreed that people could not care
+> about upgrade path from Mandriva.
+>
+
+That does not mean we should intentionally break upgrades either.
+
+--
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010954.html b/zarb-ml/mageia-dev/2012-January/010954.html new file mode 100644 index 000000000..3cede749e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010954.html @@ -0,0 +1,137 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2

+ Michael Scherer + misc at zarb.org +
+ Wed Jan 4 18:29:07 CET 2012 +

+
+ +
Le mercredi 04 janvier 2012 à 16:16 +0200, Anssi Hannula a écrit :
+> On 04.01.2012 11:54, Michael Scherer wrote:
+> > Le mercredi 04 janvier 2012 à 11:03 +0200, Thomas Backlund a écrit :
+> >> Anssi Hannula skrev 3.1.2012 23:05:
+> >>> On 02.01.2012 12:21, guillomovitch wrote:
+> >>>> Name        : dsniff                       Relocations: (not relocatable)
+> >>>> Version     : 2.4                               Vendor: Mageia.Org
+> >>>> Release     : 0.b1.1.mga2                   Build Date: Mon Jan  2 11:18:17 2012
+> >>>> Install Date: (not installed)               Build Host: ecosse
+> >>>> Group       : Monitoring                    Source RPM: (none)
+> >>>> Size        : 210074                           License: BSD
+> >>>> Signature   : (none)
+> >>>> Packager    : guillomovitch<guillomovitch>
+> >>>> URL         : http://www.monkey.org/~dugsong/dsniff/
+> >>>> Summary     : Network audit tools
+> >>>> Description :
+> >>>> Tools to audit network and to demonstrate the insecurity of cleartext
+> >>>> network protocols. Please do not abuse this software.
+> >>>>
+> >>>> guillomovitch<guillomovitch>  2.4-0.b1.1.mga2:
+> >>>> + Revision: 189630
+> >>>> - drop epoch, we don't care about updating from mdv anymore
+> >>>
+> >>> We don't?
+> >>>
+> >>
+> >> Oh yes we do. Atleast from 2010.1
+> > 
+> > We did for 1, not for 2 or cauldron or anything else. So as long the
+> > package is not pushed on 1, I think we agreed that people could not care
+> > about upgrade path from Mandriva.
+> 
+> Well, I don't like that, IMO we should not remove upgradeability so
+> soon, even if we won't officially support it.
+
+Well, if we do not officially support it, then we do not support it,
+that's all. There is no "that's unofficially supported" or stuff like
+that. Supported mean "we will do test and fix bug if they happen", and
+not supported mean "we reserve our right to not do anything".
+
+And that's exactly what happen right now.
+
+> But anyway, this affects people doing 2010.1->mga1->mga2 as well... Or
+> are you saying that isn't supported either, and people should do new
+> installs??
+
+We do not support upgrading mdv2010.1 rpms with rpm from mga2, so if a
+maintainer want to remove this, he can.
+
+Someone doing mdv2010.1->mga1 will end with a mix of mdv2010.1 and mga1
+if the system is not cleaned, and that's not something we should
+support, not more than mga X + any random repository upgrade to mga X+1 
+
+IE, that's not mga1 -> mga2, that's mga1 + 3rd party repo that happened
+to work by chance to mga2. 
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010955.html b/zarb-ml/mageia-dev/2012-January/010955.html new file mode 100644 index 000000000..3194b7571 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010955.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Wed Jan 4 18:58:55 CET 2012 +

+
+ +
Le 04/01/2012 18:05, Thomas Backlund a écrit :
+> That does not mean we should intentionally break upgrades either.
+I wonder how much energy will be wasted replying to this thread before 
+someone fix the package directly...
+-- 
+BOFH excuse #388:
+
+Bad user karma.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010956.html b/zarb-ml/mageia-dev/2012-January/010956.html new file mode 100644 index 000000000..cfe3de2b6 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010956.html @@ -0,0 +1,156 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2

+ Anssi Hannula + anssi at mageia.org +
+ Wed Jan 4 19:09:14 CET 2012 +

+
+ +
On 04.01.2012 19:29, Michael Scherer wrote:
+> Le mercredi 04 janvier 2012 à 16:16 +0200, Anssi Hannula a écrit :
+>> On 04.01.2012 11:54, Michael Scherer wrote:
+>>> Le mercredi 04 janvier 2012 à 11:03 +0200, Thomas Backlund a écrit :
+>>>> Anssi Hannula skrev 3.1.2012 23:05:
+>>>>> On 02.01.2012 12:21, guillomovitch wrote:
+>>>>>> Name        : dsniff                       Relocations: (not relocatable)
+>>>>>> Version     : 2.4                               Vendor: Mageia.Org
+>>>>>> Release     : 0.b1.1.mga2                   Build Date: Mon Jan  2 11:18:17 2012
+>>>>>> Install Date: (not installed)               Build Host: ecosse
+>>>>>> Group       : Monitoring                    Source RPM: (none)
+>>>>>> Size        : 210074                           License: BSD
+>>>>>> Signature   : (none)
+>>>>>> Packager    : guillomovitch<guillomovitch>
+>>>>>> URL         : http://www.monkey.org/~dugsong/dsniff/
+>>>>>> Summary     : Network audit tools
+>>>>>> Description :
+>>>>>> Tools to audit network and to demonstrate the insecurity of cleartext
+>>>>>> network protocols. Please do not abuse this software.
+>>>>>>
+>>>>>> guillomovitch<guillomovitch>  2.4-0.b1.1.mga2:
+>>>>>> + Revision: 189630
+>>>>>> - drop epoch, we don't care about updating from mdv anymore
+>>>>>
+>>>>> We don't?
+>>>>>
+>>>>
+>>>> Oh yes we do. Atleast from 2010.1
+>>>
+>>> We did for 1, not for 2 or cauldron or anything else. So as long the
+>>> package is not pushed on 1, I think we agreed that people could not care
+>>> about upgrade path from Mandriva.
+>>
+>> Well, I don't like that, IMO we should not remove upgradeability so
+>> soon, even if we won't officially support it.
+> 
+> Well, if we do not officially support it, then we do not support it,
+> that's all. There is no "that's unofficially supported" or stuff like
+> that. Supported mean "we will do test and fix bug if they happen", and
+> not supported mean "we reserve our right to not do anything".
+> 
+> And that's exactly what happen right now.
+
+IMO there is a level between "officially supported" and "we
+intentionally break it", which means that we advise against it but do
+not hinder people from doing it.
+
+Also, I personally do fix any upgradeability bugs for the last several
+releases if such are reported to me (though you are right that I do not
+specifically test them, hence "unsupported".
+
+>> But anyway, this affects people doing 2010.1->mga1->mga2 as well... Or
+>> are you saying that isn't supported either, and people should do new
+>> installs??
+> 
+> We do not support upgrading mdv2010.1 rpms with rpm from mga2, so if a
+> maintainer want to remove this, he can.
+> 
+> Someone doing mdv2010.1->mga1 will end with a mix of mdv2010.1 and mga1
+> if the system is not cleaned, and that's not something we should
+> support, not more than mga X + any random repository upgrade to mga X+1 
+> 
+> IE, that's not mga1 -> mga2, that's mga1 + 3rd party repo that happened
+> to work by chance to mga2. 
+
+I have to strongly disagree with this. If upgrading from 2010.1 to mga1
+is officially supported (and it is), we can't say "you can't upgrade
+your mga1 system to mga2 anymore because you have some old pkgs
+installed which we never asked you to remove" (assuming no non-mdv 3rd
+party repos here).
+
+Upgrading the distribution via path N -> N+1 -> N+2 -> N+3 -> N+4
+(without extra repositories) should *always* be supported, and I see no
+reason to break that for the mdv->mga transition point either.
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010957.html b/zarb-ml/mageia-dev/2012-January/010957.html new file mode 100644 index 000000000..dc4bb3aed --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010957.html @@ -0,0 +1,117 @@ + + + + [Mageia-dev] Adding additional provides to php database modules + + + + + + + + + +

[Mageia-dev] Adding additional provides to php database modules

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Wed Jan 4 20:08:35 CET 2012 +

+
+ +
Am Mittwoch, 28. Dezember 2011, 17:01:17 schrieb Guillaume Rousse:
+> Le 19/12/2011 03:02, Thomas Spuhler a écrit :
+> > Could you please explain a little more what you are looking for.
+> > PHP provides the php-mysql and php-pdo-mysql
+> 
+> He wants to add a php-database virtual package, provided by the
+> different php database bindings.
+Exactly. So mediawiki and drupal could just require "php-database" or 
+something like that.
+
+> 
+> The only problem here is that, pdo aside, there is no unified database
+> interface in php. Some applications may have explicit support for some
+> databases, this doesn't mean they have generic support for any database.
+> You're likely to quickly run into applications able to work with mysql,
+> postgresql or sqlite, and those able to work with just mysql or
+> postgresql. In theory, you'll end up with as much virtual package as
+> potential combination.
+I see the problem. So it would be actually better for each application like 
+drupal and mediawiki to have its own virtual provides for the database 
+packages (like drupal already does).
+
+Thanks,
+
+Oliver
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010958.html b/zarb-ml/mageia-dev/2012-January/010958.html new file mode 100644 index 000000000..0093ed9d1 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010958.html @@ -0,0 +1,131 @@ + + + + [Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement + + + + + + + + + +

[Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement

+ Luc Menut + lmenut at free.fr +
+ Wed Jan 4 20:13:51 CET 2012 +

+
+ +
Le 04/01/2012 17:20, Guillaume Rousse a écrit :
+>> 1) add support for optional README.*.urpmi (%ghost in spec):
+>> This will allow to build this README.*.urpmi at install time in %pre,
+>> %post or %trigger only when it's necessary.
+> That will create files on the system unknown from rpm database, and
+> unknown from urpmi too.
+
+nope, %ghost files are known from rpm database.
+rpm -qpl task-obsolete-1-1.mga2.noarch.rpm
+/usr/share/doc/task-obsolete
+/usr/share/doc/task-obsolete/README.null-dummy.obsolete.urpmi
+/usr/share/doc/task-obsolete/README.null.obsolete.urpmi
+
+
+> Rather than focusing on shiny automatic display mechanisms, I'd rather
+> work on information content.
+
+we can|should do both.
+
+[...]
+>
+> Here are a few proposal of mines to make the situation better:
+> - use a unique file name, enforced by convention, rather than references
+> in package description, the same way Debian does with README.debian
+> - display its content only in graphical context: command-line users
+> usually know about this kind of convention to get information themselves
+> - use standardised file content and markup to allow rpmdrake and other
+> graphical tools to achieve the same kind of selection than file
+> splitting today
+> - define some kind of policy of what should be there, and what should
+> not, to achieve minimal consistency
+
+I'm not particularly attached at the current system, but I find it works 
+rather well.
+If we want that users read informations, the information should be 
+relevant in the context (too many informations, kill information);
+e.g. it's useless (personnaly, I consider it's bad) to display 
+information about install when we update a package, and vice versa (I 
+don't know debian, and if the unique file README.debian allow this).
+
+Luc
+
+-- 
+Luc Menut
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010959.html b/zarb-ml/mageia-dev/2012-January/010959.html new file mode 100644 index 000000000..8e256cd41 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010959.html @@ -0,0 +1,116 @@ + + + + [Mageia-dev] Proposal: Cinnamon for Mageia + + + + + + + + + +

[Mageia-dev] Proposal: Cinnamon for Mageia

+ bernd + bernd.deinzer at t-online.de +
+ Wed Jan 4 20:21:29 CET 2012 +

+
+ +
As you know, Cinnamon is a fork of Gnome-Shell with the look & feel &
+workflow of Gnome2, developed and maintained by Clement Lefebvre
+"Clem" from Linux-Mint.
+
+At the moment, already rpms and debs for other distributions like Ubuntu,
+Fedora, Arch and OpenSuse are built: 
+http://cinnamon.linuxmint.com/?page_id=61
+
+In my opinion, Cinnamon will be a sustainable alternative for 
+ex-Gnome2-users,
+who don't like the "smartphone-look" of Gnome3
+
+So I propose to implement Cinnamon also in Mageia as a third "heavy" DE 
+next to
+KDE4 and Gnome3
+
+Regards,
+Bernd
+
+
+
+//////
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20120104/1311d74c/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010960.html b/zarb-ml/mageia-dev/2012-January/010960.html new file mode 100644 index 000000000..f055f2c3c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010960.html @@ -0,0 +1,137 @@ + + + + [Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement + + + + + + + + + +

[Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement

+ Anssi Hannula + anssi at mageia.org +
+ Wed Jan 4 20:26:34 CET 2012 +

+
+ +
On 04.01.2012 17:53, Luc Menut wrote:
+> Hello,
+> 
+> We have recently discussed here about task-obsolete.
+> http://www.mail-archive.com/mageia-dev@mageia.org/msg09762.html
+> https://bugs.mageia.org/show_bug.cgi?id=3786
+> 
+> I like the idea.
+> But I think that we need to inform the user about the package(s) that we
+> will obsolete and remove on his system (and why: security, ..).
+> So I tried to use README.*.urpmi to do this.
+> But I found that currently, urpmi and rpmdrake don't handle very well
+> optional README.*.urpmi (%ghost); they always display information's
+> screen, even if the file doesn't exist.
+> 
+> So, I propose here 2 enhancements for README.*.urpmi (POC patch for
+> urpm/install.pm, and task-obsolete.spec in attachment):
+> 
+> 1) add support for optional README.*.urpmi (%ghost in spec):
+> This will allow to build this README.*.urpmi at install time in %pre,
+> %post or %trigger only when it's necessary.
+> One use case from the recent past in my mind:
+> we have no way to inform users that still use nspluginwrapper + i586
+> flashplayer on x86_64 (and only them), that this is now deprecated and
+> they should replace the i586 by the x86_64 flashplayer,
+> https://bugs.mageia.org/show_bug.cgi?id=2146#c22
+> https://bugs.mageia.org/show_bug.cgi?id=2146#c25
+
+This change seems reasonable.
+
+> 2) handle README.*.(obsolete|deprecated).urpmi
+> In order to display informations about the deprecated or obsoleted
+> package(s), I suggest to handle 2 new kinds of README.*.urpmi:
+> - README."nameObsoletedPackage".obsolete.urpmi to inform about the
+> package we obsolete by task-obsolete
+> e.g. java-1.6.0-sun*, https://bugs.mageia.org/show_bug.cgi?id=3101
+> 
+> - README."nameDeprecatedPackage".deprecated.urpmi to inform about
+> package that we considere as deprecated, but we have no reason (no
+> vulnerability, security, ...) to force uninstallation (task-deprecated?).
+
+I don't understand the need for this one, isn't this just the same as
+README.urpmi?
+
+> What do you think ?
+
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010961.html b/zarb-ml/mageia-dev/2012-January/010961.html new file mode 100644 index 000000000..5db61564f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010961.html @@ -0,0 +1,110 @@ + + + + [Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement + + + + + + + + + +

[Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement

+ Anssi Hannula + anssi at mageia.org +
+ Wed Jan 4 20:32:08 CET 2012 +

+
+ +
On 04.01.2012 18:20, Guillaume Rousse wrote:
+> Here are a few proposal of mines to make the situation better:
+> - use a unique file name, enforced by convention, rather than references
+> in package description, the same way Debian does with README.debian
+> - display its content only in graphical context: command-line users
+> usually know about this kind of convention to get information themselves
+> - use standardised file content and markup to allow rpmdrake and other
+> graphical tools to achieve the same kind of selection than file
+> splitting today
+> - define some kind of policy of what should be there, and what should
+> not, to achieve minimal consistency
+
++1
+
+except for the 2nd point; I do want any important information to be
+shown automatically. For example, I don't check the documentation of
+each and every package on each and every update for upgrade information.
+
+I also agree Johnny, all the information should be shown in the end of
+the urpmi run, not in the middle of installing packages where one may
+not notice them.
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010962.html b/zarb-ml/mageia-dev/2012-January/010962.html new file mode 100644 index 000000000..8edfbccff --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010962.html @@ -0,0 +1,123 @@ + + + + [Mageia-dev] Proposal: Cinnamon for Mageia + + + + + + + + + +

[Mageia-dev] Proposal: Cinnamon for Mageia

+ Michael Scherer + misc at zarb.org +
+ Wed Jan 4 20:50:57 CET 2012 +

+
+ +
Le mercredi 04 janvier 2012 à 20:21 +0100, bernd a écrit :
+> As you know, Cinnamon is a fork of Gnome-Shell with the look & feel & 
+> workflow of Gnome2, developed and maintained by Clement Lefebvre
+> "Clem" from Linux-Mint.
+> 
+> At the moment, already rpms and debs for other distributions like
+> Ubuntu,
+> Fedora, Arch and OpenSuse are built:
+> http://cinnamon.linuxmint.com/?page_id=61
+> 
+> In my opinion, Cinnamon will be a sustainable alternative for
+> ex-Gnome2-users,
+> who don't like the "smartphone-look" of Gnome3
+
+It will be sustainable when it will have been sustained a bit, don't you
+think ? ( because mint already announced first to add js extension to
+gnome shell, then to fork gnome 2, then to develop a new DE , so maybe
+they will do another thing next week ).
+
+( and personally, I do have both a smartphone and gnome 3, and I wonder
+if people who say there is a smartphone look to gnome 3 have a
+smartphone, cause mine do not really look like gnome 3 )
+
+I do not have much trust in linuxmint code ( there is several unfixed
+serious flaw in their python tools, like
+https://github.com/linuxmint/mintupdate/blob/master/usr/lib/linuxmint/mintUpdate/mintUpdate.py#L1444 or 
+https://github.com/linuxmint/mintnanny/blob/master/usr/lib/linuxmint/mintNanny/mintNanny.py#L71
+ ), but if someone do proper packages ( and if they do not open hole
+like these one ), why not. 
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010963.html b/zarb-ml/mageia-dev/2012-January/010963.html new file mode 100644 index 000000000..46a6cd9c0 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010963.html @@ -0,0 +1,122 @@ + + + + [Mageia-dev] references to outside web sites/wiki + + + + + + + + + +

[Mageia-dev] references to outside web sites/wiki

+ Romain d'Alverny + rdalverny at gmail.com +
+ Wed Jan 4 21:06:03 CET 2012 +

+
+ +
Hi!
+
+(same post sent to mageia-dev)
+
+If you find, or wrote, in our wiki (http://wiki.mageia.org/en/ ) stuff
+that references documentation hosted on the MDV wiki
+(http://wiki.mandriva.com/ ), it is a good idea to not only reference
+it now, but to really import the content into our own wiki, now.
+
+That is valid for other sources as well, of course, but
+wiki.mandriva.com may be shut down for good in just a few days (no
+comment about the thing, just stating a fact).
+
+wiki.mandriva.com contents are licensed under CC-By-SA 2.5 (see
+http://wiki.mandriva.com/en/Mandriva:Copyrights). So you can import
+contents from it, please comment your commit with a mention to the
+original URL + a mention in the end of the article, like "Portions of
+this are imported from ..., licensed under CC-By-SA 2.5". It can be
+portions, or full articles.
+
+Would be good too to be able to mount a static mirror copy of it, if
+it's needed, but I am not sure how to import it (wget'ing a mediawiki
+instance is tricky).
+
+Btw, do we have hard dependencies (documentation, I mean) in other
+MDV's online resources? Bugzilla? List archives? or are these properly
+archived elsewhere? other?
+
+(note to self, push forward the contributions & db licensing policy to
+make it really explicit that it will be encouraged to do so with
+Mageia's stuff)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010964.html b/zarb-ml/mageia-dev/2012-January/010964.html new file mode 100644 index 000000000..ce1bf70b8 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010964.html @@ -0,0 +1,118 @@ + + + + [Mageia-dev] Adding additional provides to php database modules + + + + + + + + + +

[Mageia-dev] Adding additional provides to php database modules

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Wed Jan 4 21:12:09 CET 2012 +

+
+ +
Le 04/01/2012 20:08, Oliver Burger a écrit :
+>> The only problem here is that, pdo aside, there is no unified database
+>> interface in php. Some applications may have explicit support for some
+>> databases, this doesn't mean they have generic support for any database.
+>> You're likely to quickly run into applications able to work with mysql,
+>> postgresql or sqlite, and those able to work with just mysql or
+>> postgresql. In theory, you'll end up with as much virtual package as
+>> potential combination.
+> I see the problem. So it would be actually better for each application like
+> drupal and mediawiki to have its own virtual provides for the database
+> packages (like drupal already does).
+<pedantism>
+"virtual provides" doesn't means anything, because there isn't any 
+"physical provides". You're speaking of a virtual package here.
+</pedantism>
+
+I just had a look at the solution implemented in drupal package. The 
+drupal-mysql and drupal-postgresql packages seems wrong, because they 
+enforces a dependency against a local database, whereas it should only 
+requires the correct pdo package. This small issue aside, the whole idea 
+seems quite overkill for me: it is really useful to add 3 empty packages 
+just to handle this interactively, whereas documenting the issue would 
+be as much efficient ?
+
+BTW, the PDO case is precisely the one for which the package-specific 
+solution is not needed: any PDO compliant database should work, as PDO 
+is an abstraction layer :)
+-- 
+BOFH excuse #295:
+
+The Token fell out of the ring. Call us when you find it.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010965.html b/zarb-ml/mageia-dev/2012-January/010965.html new file mode 100644 index 000000000..587e9c474 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010965.html @@ -0,0 +1,145 @@ + + + + [Mageia-dev] Rpmlint configuration, false positives + + + + + + + + + +

[Mageia-dev] Rpmlint configuration, false positives

+ Florian Hubold + doktor5000 at arcor.de +
+ Wed Jan 4 21:17:55 CET 2012 +

+
+ +
Am 27.08.2011 22:19, schrieb Michael Scherer:
+> Le samedi 27 août 2011 à 22:06 +0200, Florian Hubold a écrit :
+>> Am 04.03.2011 22:30, schrieb Michael Scherer:
+>>>
+>>> But we can filter and configure it to be a little more perfect.
+>>>
+>>> In a rather autocratic fashion, as the maintainer of rpmlint ( both packages
+>>> and uptream ), as a packager representative, and as a apprentice dictator
+>>> ( since there is lots of open position in this sector since a few weeks ),
+>>> I propose that this become the canonical source for rpmlint configuration.
+>>>
+>>> In practice, that mean that false positives will have to be added there,
+>>> that stuff that are noted as errors need to be set in that package, and
+>>> any policy changes must be made there.
+>>>
+>>> So the question is "how do we deal with evolution ( ie, how do we decide
+>>> something is now a error, or no longer one".
+>>>
+>>> Traditionally, packagers didn't care at all, and so the configuration bitrotted
+>>> since a long time, and people didn't used it, and I just added false positives
+>>> when packagers notified it ( ie, almost never, except when I noticed some of 
+>>> them ).
+>>> I suspect that my lack of communication around that didn't help ( and so
+>>> people didn't knew they could ask for adding a false positive to the list
+>>> of error to ignore ).
+>>>
+>>> Yet, I think we can do better, so feel free to suggest any mad idea for this.
+>> What about the following, AFAIK those are deprecated and rpmlint shouldn't 
+>> complain about:
+>
+Stumbled upon two more false positives, when using %setup_compile_flags
+during %build, presumably because it also starts with %setup:
+
+W: setup-not-quiet
+
+W: setup-not-in-prep
+
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010966.html b/zarb-ml/mageia-dev/2012-January/010966.html new file mode 100644 index 000000000..5e90ee23a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010966.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] references to outside web sites/wiki + + + + + + + + + +

[Mageia-dev] references to outside web sites/wiki

+ Johnny A. Solbu + cooker at solbu.net +
+ Wed Jan 4 22:36:43 CET 2012 +

+
+ +
On Wednesday 04 January 2012 21:06, Romain d'Alverny wrote:
+> wiki.mandriva.com may be shut down for good in just a few days
+
+What? Are Mandriva serisouly considering closing down the Wiki?
+Where did you hear this?
+
+Or did you make a general comment on the fact that external wikis sometimes may shut down?
+
+-- 
+Johnny A. Solbu
+PGP key ID: 0xFA687324
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 189 bytes
+Desc: This is a digitally signed message part.
+URL: </pipermail/mageia-dev/attachments/20120104/a3ecbbdd/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010967.html b/zarb-ml/mageia-dev/2012-January/010967.html new file mode 100644 index 000000000..8e2d5b5e7 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010967.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] references to outside web sites/wiki + + + + + + + + + +

[Mageia-dev] references to outside web sites/wiki

+ Romain d'Alverny + rdalverny at gmail.com +
+ Wed Jan 4 22:56:01 CET 2012 +

+
+ +
On Wed, Jan 4, 2012 at 22:36, Johnny A. Solbu <cooker at solbu.net> wrote:
+> On Wednesday 04 January 2012 21:06, Romain d'Alverny wrote:
+>> wiki.mandriva.com may be shut down for good in just a few days
+>
+> What? Are Mandriva serisouly considering closing down the Wiki?
+
+Mandriva is on the path to filing for bankruptcy on January 16th.
+Sources (in French):
+ * https://linuxfr.org/users/jaypee/journaux/fin-de-mandriva
+ * http://www.boursorama.com/forum-mandriva-ex-mandrakesoft-courrier-de-mandriva-414340508-1
+
+In the event it does occur, their servers may be shut down anytime.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010968.html b/zarb-ml/mageia-dev/2012-January/010968.html new file mode 100644 index 000000000..2130286ca --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010968.html @@ -0,0 +1,111 @@ + + + + [Mageia-dev] references to outside web sites/wiki + + + + + + + + + +

[Mageia-dev] references to outside web sites/wiki

+ Florian Hubold + doktor5000 at arcor.de +
+ Wed Jan 4 22:57:03 CET 2012 +

+
+ +
Am 04.01.2012 22:36, schrieb Johnny A. Solbu:
+> On Wednesday 04 January 2012 21:06, Romain d'Alverny wrote:
+>> wiki.mandriva.com may be shut down for good in just a few days
+> What? Are Mandriva serisouly considering closing down the Wiki?
+> Where did you hear this?
+>
+> Or did you make a general comment on the fact that external wikis sometimes may shut down?
+>
+You didn't get the thread in the international Mandriva forum?
+Have a look: http://forum.mandriva.com/en/viewtopic.php?p=854370#p854370
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010969.html b/zarb-ml/mageia-dev/2012-January/010969.html new file mode 100644 index 000000000..81579225a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010969.html @@ -0,0 +1,129 @@ + + + + [Mageia-dev] Proposal: Cinnamon for Mageia + + + + + + + + + +

[Mageia-dev] Proposal: Cinnamon for Mageia

+ JA Magallon + jamagallon at ono.com +
+ Wed Jan 4 22:58:24 CET 2012 +

+
+ +
On Wed, 04 Jan 2012 20:50:57 +0100
+Michael Scherer <misc at zarb.org> wrote:
+
+> Le mercredi 04 janvier 2012 à 20:21 +0100, bernd a écrit :
+> > As you know, Cinnamon is a fork of Gnome-Shell with the look & feel & 
+> > workflow of Gnome2, developed and maintained by Clement Lefebvre
+> > "Clem" from Linux-Mint.
+> > 
+> > At the moment, already rpms and debs for other distributions like
+> > Ubuntu,
+> > Fedora, Arch and OpenSuse are built:
+> > http://cinnamon.linuxmint.com/?page_id=61
+> > 
+> > In my opinion, Cinnamon will be a sustainable alternative for
+> > ex-Gnome2-users,
+> > who don't like the "smartphone-look" of Gnome3
+> 
+> It will be sustainable when it will have been sustained a bit, don't you
+> think ? ( because mint already announced first to add js extension to
+> gnome shell, then to fork gnome 2, then to develop a new DE , so maybe
+> they will do another thing next week ).
+> 
+> ( and personally, I do have both a smartphone and gnome 3, and I wonder
+> if people who say there is a smartphone look to gnome 3 have a
+> smartphone, cause mine do not really look like gnome 3 )
+> 
+> I do not have much trust in linuxmint code ( there is several unfixed
+> serious flaw in their python tools, like
+> https://github.com/linuxmint/mintupdate/blob/master/usr/lib/linuxmint/mintUpdate/mintUpdate.py#L1444 or 
+> https://github.com/linuxmint/mintnanny/blob/master/usr/lib/linuxmint/mintNanny/mintNanny.py#L71
+>  ), but if someone do proper packages ( and if they do not open hole
+> like these one ), why not. 
+> 
+
+If the choice is like install gnome-shell or cinnamon, just two packages
+with a conflict, and applets work both in gnome3-fallback-mode and in
+cinnamon, and if....
+
+In short, if it is _just_ a gnome-shell replacement, no worries. Package it
+and if it dies on a month, nothing happens. If you have to tweak half gnome
+platform to get it running, by by...
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010970.html b/zarb-ml/mageia-dev/2012-January/010970.html new file mode 100644 index 000000000..40e6ecacf --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010970.html @@ -0,0 +1,211 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2

+ Michael Scherer + misc at zarb.org +
+ Wed Jan 4 23:16:31 CET 2012 +

+
+ +
Le mercredi 04 janvier 2012 à 20:09 +0200, Anssi Hannula a écrit :
+> On 04.01.2012 19:29, Michael Scherer wrote:
+> > Le mercredi 04 janvier 2012 à 16:16 +0200, Anssi Hannula a écrit :
+> >> On 04.01.2012 11:54, Michael Scherer wrote:
+> >>> Le mercredi 04 janvier 2012 à 11:03 +0200, Thomas Backlund a écrit :
+> >>>> Anssi Hannula skrev 3.1.2012 23:05:
+> >>>>> On 02.01.2012 12:21, guillomovitch wrote:
+> >>>>>> Name        : dsniff                       Relocations: (not relocatable)
+> >>>>>> Version     : 2.4                               Vendor: Mageia.Org
+> >>>>>> Release     : 0.b1.1.mga2                   Build Date: Mon Jan  2 11:18:17 2012
+> >>>>>> Install Date: (not installed)               Build Host: ecosse
+> >>>>>> Group       : Monitoring                    Source RPM: (none)
+> >>>>>> Size        : 210074                           License: BSD
+> >>>>>> Signature   : (none)
+> >>>>>> Packager    : guillomovitch<guillomovitch>
+> >>>>>> URL         : http://www.monkey.org/~dugsong/dsniff/
+> >>>>>> Summary     : Network audit tools
+> >>>>>> Description :
+> >>>>>> Tools to audit network and to demonstrate the insecurity of cleartext
+> >>>>>> network protocols. Please do not abuse this software.
+> >>>>>>
+> >>>>>> guillomovitch<guillomovitch>  2.4-0.b1.1.mga2:
+> >>>>>> + Revision: 189630
+> >>>>>> - drop epoch, we don't care about updating from mdv anymore
+> >>>>>
+> >>>>> We don't?
+> >>>>>
+> >>>>
+> >>>> Oh yes we do. Atleast from 2010.1
+> >>>
+> >>> We did for 1, not for 2 or cauldron or anything else. So as long the
+> >>> package is not pushed on 1, I think we agreed that people could not care
+> >>> about upgrade path from Mandriva.
+> >>
+> >> Well, I don't like that, IMO we should not remove upgradeability so
+> >> soon, even if we won't officially support it.
+> > 
+> > Well, if we do not officially support it, then we do not support it,
+> > that's all. There is no "that's unofficially supported" or stuff like
+> > that. Supported mean "we will do test and fix bug if they happen", and
+> > not supported mean "we reserve our right to not do anything".
+> > 
+> > And that's exactly what happen right now.
+> 
+> IMO there is a level between "officially supported" and "we
+> intentionally break it", which means that we advise against it but do
+> not hinder people from doing it.
+
+Yes, there is different levels of support, obviously, since people have
+different  but that doesn't mean we should rely on them, or try to
+officially use them. Again, saying "we support that, so we do that, and
+we don't support this, so people are free to do what they want" is
+simpler. 
+
+The whole scheme of having "stuff we do", "stuff we do not promise but
+try to", "stuff we do not promise and we do not try to" ( or more ) make
+things less clear for everybody. Having a non uniform policy will make
+things harder for newer packagers ( and for olders too ). 
+
+We have users ( in the past ) that complained about the lack of
+reliability of packages on Mandriva. And this was IMHO because we had a
+policy of 'we keep everything and we say they are in a section of "maybe
+supported"'. The whole message "contribs is not supported but main is"
+was simple and yet, too complex to grasp ( because people didn't check
+contrib/main before installing anything, ). It was also far from the
+truth because some stuff in contribs were more supported than stuff in
+main, and thus we were sending mixed messages. 
+
+So we should really stick on what we support, and send a simple, clear
+and correct message.
+
+And I think we need to keep things simple to solve such issues in the
+long run.
+
+
+> >> But anyway, this affects people doing 2010.1->mga1->mga2 as well... Or
+> >> are you saying that isn't supported either, and people should do new
+> >> installs??
+> > 
+> > We do not support upgrading mdv2010.1 rpms with rpm from mga2, so if a
+> > maintainer want to remove this, he can.
+> > 
+> > Someone doing mdv2010.1->mga1 will end with a mix of mdv2010.1 and mga1
+> > if the system is not cleaned, and that's not something we should
+> > support, not more than mga X + any random repository upgrade to mga X+1 
+> > 
+> > IE, that's not mga1 -> mga2, that's mga1 + 3rd party repo that happened
+> > to work by chance to mga2. 
+> 
+> I have to strongly disagree with this. If upgrading from 2010.1 to mga1
+> is officially supported (and it is), we can't say "you can't upgrade
+> your mga1 system to mga2 anymore because you have some old pkgs
+> installed which we never asked you to remove" (assuming no non-mdv 3rd
+> party repos here).
+
+First,  it doesn't break the whole upgrade. 
+In fact, if we look carefully, people who were running non supported
+software ( ie a package from Mandriva ) will still run the same
+unsupported software and the same binary. And upgrade will likely work
+without error messages. Because nothing requires dsniff, except its own
+subpackage.
+
+Secondly, it didn't matter much before Guillaume uploaded dsniff. 
+
+1 week ago, anyone who would have upgraded to mga2 with dsniff installed
+from mdv would have been in the exact same situation than now, except
+nobody cared at all. And the proof that nobody cared is that nobody
+pushed the rpm sooner. Would it have been pushed to 1, yes, that would
+have breached what we agreed to do. But it was not pushed to 1 ( and I
+would say "likely on purpose" ). So the only change with this upload is
+for people installing dsniff later.
+
+
+3rd point, the whole point of saying "we do not support this" is not to
+say "we don't support, but we should still support it to some extent".
+It is to be able to say "we do not support, so the maintainer can clean
+it if he want". You are free to support it if you wish, but Guillaume is
+also free to not support it, and choose to clean instead ( because epoch
+tags are ugly ). 
+
+If we wanted to support upgrading from mdv 2010.1/2 to mga2, or
+upgrading people who mix distribution packages ( be it because they do
+not know, or on purpose, that's the same problem from a technical PoV ),
+it should have been said much sooner.
+
+I do not understand, could people tell me what did they understood we
+would do when we said "we will not support upgrade this after mageia
+1" ?
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010971.html b/zarb-ml/mageia-dev/2012-January/010971.html new file mode 100644 index 000000000..e6ee0a611 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010971.html @@ -0,0 +1,245 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2

+ Anssi Hannula + anssi at mageia.org +
+ Thu Jan 5 00:05:16 CET 2012 +

+
+ +
On 05.01.2012 00:16, Michael Scherer wrote:
+> Le mercredi 04 janvier 2012 à 20:09 +0200, Anssi Hannula a écrit :
+>> On 04.01.2012 19:29, Michael Scherer wrote:
+>>> Le mercredi 04 janvier 2012 à 16:16 +0200, Anssi Hannula a écrit :
+>>>> On 04.01.2012 11:54, Michael Scherer wrote:
+>>>>> Le mercredi 04 janvier 2012 à 11:03 +0200, Thomas Backlund a écrit :
+>>>>>> Anssi Hannula skrev 3.1.2012 23:05:
+>>>>>>> On 02.01.2012 12:21, guillomovitch wrote:
+>>>>>>>> Name        : dsniff                       Relocations: (not relocatable)
+>>>>>>>> Version     : 2.4                               Vendor: Mageia.Org
+>>>>>>>> Release     : 0.b1.1.mga2                   Build Date: Mon Jan  2 11:18:17 2012
+>>>>>>>> Install Date: (not installed)               Build Host: ecosse
+>>>>>>>> Group       : Monitoring                    Source RPM: (none)
+>>>>>>>> Size        : 210074                           License: BSD
+>>>>>>>> Signature   : (none)
+>>>>>>>> Packager    : guillomovitch<guillomovitch>
+>>>>>>>> URL         : http://www.monkey.org/~dugsong/dsniff/
+>>>>>>>> Summary     : Network audit tools
+>>>>>>>> Description :
+>>>>>>>> Tools to audit network and to demonstrate the insecurity of cleartext
+>>>>>>>> network protocols. Please do not abuse this software.
+>>>>>>>>
+>>>>>>>> guillomovitch<guillomovitch>  2.4-0.b1.1.mga2:
+>>>>>>>> + Revision: 189630
+>>>>>>>> - drop epoch, we don't care about updating from mdv anymore
+>>>>>>>
+>>>>>>> We don't?
+>>>>>>>
+>>>>>>
+>>>>>> Oh yes we do. Atleast from 2010.1
+>>>>>
+>>>>> We did for 1, not for 2 or cauldron or anything else. So as long the
+>>>>> package is not pushed on 1, I think we agreed that people could not care
+>>>>> about upgrade path from Mandriva.
+>>>>
+>>>> Well, I don't like that, IMO we should not remove upgradeability so
+>>>> soon, even if we won't officially support it.
+>>>
+>>> Well, if we do not officially support it, then we do not support it,
+>>> that's all. There is no "that's unofficially supported" or stuff like
+>>> that. Supported mean "we will do test and fix bug if they happen", and
+>>> not supported mean "we reserve our right to not do anything".
+>>>
+>>> And that's exactly what happen right now.
+>>
+>> IMO there is a level between "officially supported" and "we
+>> intentionally break it", which means that we advise against it but do
+>> not hinder people from doing it.
+> 
+> Yes, there is different levels of support, obviously, since people have
+> different  but that doesn't mean we should rely on them, or try to
+> officially use them. Again, saying "we support that, so we do that, and
+> we don't support this, so people are free to do what they want" is
+> simpler. 
+> 
+> The whole scheme of having "stuff we do", "stuff we do not promise but
+> try to", "stuff we do not promise and we do not try to" ( or more ) make
+> things less clear for everybody. Having a non uniform policy will make
+> things harder for newer packagers ( and for olders too ). 
+> 
+> We have users ( in the past ) that complained about the lack of
+> reliability of packages on Mandriva. And this was IMHO because we had a
+> policy of 'we keep everything and we say they are in a section of "maybe
+> supported"'. The whole message "contribs is not supported but main is"
+> was simple and yet, too complex to grasp ( because people didn't check
+> contrib/main before installing anything, )
+
+It was not too complex, just badly implemented. The users got *no*
+in-GUI notification at all that contrib was unsupported (most users
+don't read wiki pages etc, especially if we don't link them to them).
+
+> . It was also far from the
+> truth because some stuff in contribs were more supported than stuff in
+> main, and thus we were sending mixed messages. 
+
+Right.
+
+> So we should really stick on what we support, and send a simple, clear
+> and correct message.
+> 
+> And I think we need to keep things simple to solve such issues in the
+> long run.
+
+I'm not advocating any change on the message sent to users, just to not
+break upgrade intentionally (by removing near-zero-maintentance upgrade
+support by dropping obsoletes/epochs that are needed for upgrade from
+the several last distribution versions).
+
+>>>> But anyway, this affects people doing 2010.1->mga1->mga2 as well... Or
+>>>> are you saying that isn't supported either, and people should do new
+>>>> installs??
+>>>
+>>> We do not support upgrading mdv2010.1 rpms with rpm from mga2, so if a
+>>> maintainer want to remove this, he can.
+>>>
+>>> Someone doing mdv2010.1->mga1 will end with a mix of mdv2010.1 and mga1
+>>> if the system is not cleaned, and that's not something we should
+>>> support, not more than mga X + any random repository upgrade to mga X+1 
+>>>
+>>> IE, that's not mga1 -> mga2, that's mga1 + 3rd party repo that happened
+>>> to work by chance to mga2. 
+>>
+>> I have to strongly disagree with this. If upgrading from 2010.1 to mga1
+>> is officially supported (and it is), we can't say "you can't upgrade
+>> your mga1 system to mga2 anymore because you have some old pkgs
+>> installed which we never asked you to remove" (assuming no non-mdv 3rd
+>> party repos here).
+> 
+> First,  it doesn't break the whole upgrade. 
+> In fact, if we look carefully, people who were running non supported
+> software ( ie a package from Mandriva ) will still run the same
+> unsupported software and the same binary. And upgrade will likely work
+> without error messages. Because nothing requires dsniff, except its own
+> subpackage.
+> 
+> Secondly, it didn't matter much before Guillaume uploaded dsniff. 
+> 
+> 1 week ago, anyone who would have upgraded to mga2 with dsniff installed
+> from mdv would have been in the exact same situation than now, except
+> nobody cared at all. And the proof that nobody cared is that nobody
+> pushed the rpm sooner. Would it have been pushed to 1, yes, that would
+> have breached what we agreed to do. But it was not pushed to 1 ( and I
+> would say "likely on purpose" ). So the only change with this upload is
+> for people installing dsniff later.
+
+I care. I also still have dozens of missing mdv packages in my TODO that
+I intend to import to cauldron and mga1. dsniff was one of those, though
+I'm not sure yet if I care enough about it to request it to submitted to
+mga1 updates, since I don't use it on my mga1 systems (only on cauldron).
+
+> 3rd point, the whole point of saying "we do not support this" is not to
+> say "we don't support, but we should still support it to some extent".
+> It is to be able to say "we do not support, so the maintainer can clean
+> it if he want". You are free to support it if you wish, but Guillaume is
+> also free to not support it, and choose to clean instead ( because epoch
+> tags are ugly ). 
+
+I completely agree. However, I consider this to break MGA1->MGA2
+upgrade, which *is* supported.
+
+> If we wanted to support upgrading from mdv 2010.1/2 to mga2, or
+> upgrading people who mix distribution packages ( be it because they do
+> not know, or on purpose, that's the same problem from a technical PoV ),
+> it should have been said much sooner.
+
+I'm fine with us not supporting 2010.1->mga2. However, I'm not fine with
+breaking 2010.1->mga1->mga2.
+
+And saying "it didn't completely break" while user has in his mga2
+installation old packages is IMO not an option.
+
+If it was intended that 2010.1->mga1 system wouldn't be completely
+upgradable (all packages) to mga2, we should've made it clear when we
+offered the mdv2010.1 -> mga1 upgrade path. But we didn't, so we should
+completely support 2010.1->mga1->mga2 (with which I agree with).
+
+> I do not understand, could people tell me what did they understood we
+> would do when we said "we will not support upgrade this after mageia
+> 1" ?
+
+I understood it as 2010.1->mga2 would not necessarily work, but
+2010.1->mga1->mga2 would still work fine, without old packages left,
+except for those for which no new versions exist in the distribution.
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010972.html b/zarb-ml/mageia-dev/2012-January/010972.html new file mode 100644 index 000000000..84ecbdeca --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010972.html @@ -0,0 +1,125 @@ + + + + [Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement + + + + + + + + + +

[Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement

+ Luc Menut + lmenut at free.fr +
+ Thu Jan 5 00:28:25 CET 2012 +

+
+ +
Le 04/01/2012 20:26, Anssi Hannula a écrit :
+> On 04.01.2012 17:53, Luc Menut wrote:
+[...]
+>> 1) add support for optional README.*.urpmi (%ghost in spec):
+>> >  This will allow to build this README.*.urpmi at install time in %pre,
+>> >  %post or %trigger only when it's necessary.
+>> >  One use case from the recent past in my mind:
+>> >  we have no way to inform users that still use nspluginwrapper + i586
+>> >  flashplayer on x86_64 (and only them), that this is now deprecated and
+>> >  they should replace the i586 by the x86_64 flashplayer,
+>> >  https://bugs.mageia.org/show_bug.cgi?id=2146#c22
+>> >  https://bugs.mageia.org/show_bug.cgi?id=2146#c25
+> This change seems reasonable.
+>
+>> >  2) handle README.*.(obsolete|deprecated).urpmi
+[...]
+> I don't understand the need for this one, isn't this just the same as
+> README.urpmi?
+
+You are right, we don't need this part; each trigger can add its message 
+in task-obsolete/README.urpmi.
+
+we just need the following patch to handle %ghost README.urpmi :
+
+Index: urpm/install.pm
+===================================================================
+--- urpm/install.pm     (revision 2572)
++++ urpm/install.pm     (working copy)
+@@ -109,6 +109,7 @@
+
+      foreach my $file ($pkg->files) {
+         my ($kind) = $file =~ m!/README([^/]*)\.urpmi$! or next;
++       -r $file or next;
+         my $valid;
+         if ($kind eq '') {
+             $valid = 1;
+
+
+
+-- 
+Luc Menut
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010973.html b/zarb-ml/mageia-dev/2012-January/010973.html new file mode 100644 index 000000000..ef26b25d8 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010973.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] references to outside web sites/wiki + + + + + + + + + +

[Mageia-dev] references to outside web sites/wiki

+ Kamil Rytarowski + n54 at gmx.com +
+ Thu Jan 5 00:33:16 CET 2012 +

+
+ +
W dniu 04.01.2012 21:06, Romain d'Alverny pisze:
+> Would be good too to be able to mount a static mirror copy of it, if
+> it's needed, but I am not sure how to import it (wget'ing a mediawiki
+> instance is tricky).
+>
+Please take a look here http://code.google.com/p/wikiteam/
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010974.html b/zarb-ml/mageia-dev/2012-January/010974.html new file mode 100644 index 000000000..5a73c8d69 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010974.html @@ -0,0 +1,117 @@ + + + + [Mageia-dev] [packages-commits] [190229] new version 2.5.0 + + + + + + + + + +

[Mageia-dev] [packages-commits] [190229] new version 2.5.0

+ Angelo Naselli + anaselli at linux.it +
+ Thu Jan 5 00:47:34 CET 2012 +

+
+ +
mercoledì 4 gennaio 2012 alle 13:17, Angelo Naselli ha scritto:
+> In data mercoledì 4 gennaio 2012 03:06:05, John Balcaen ha scritto:
+> > 2012/1/3  <root at mageia.org>:
+> > > Revision 190229 Author fwang Date 2012-01-04 02:11:16 +0100 (Wed, 04 Jan
+> > > 2012)
+> > > 
+> > > Log Message
+> > > 
+> > > new version 2.5.0
+> > > 
+> > > Modified Paths
+> > > 
+> > > cauldron/digikam/current/SOURCES/sha1.lst
+> > > cauldron/digikam/current/SPECS/digikam.spec
+> > 
+> > [...]
+> > Just in case digikam won't build until
+> > https://bugs.kde.org/show_bug.cgi?id=287772 is fixed, maybe you can
+> > help here ?
+> John, can you ping me via irc, so that i can try to understand the problem?
+> 
+> 
+FWIW patch:
+http://bugsfiles.kde.org/attachment.cgi?id=67460
+builds correctly that part, but as said i don't know
+the code, so i don't know the changes.
+It fails after though:
+home/anaselli/mageia/digikam/BUILD/digikam-2.5.0/core/utilities/setup/setupplugins.cpp: In member function ‘void Digikam::SetupPlugins::slotCheckAll()’:
+/home/anaselli/mageia/digikam/BUILD/digikam-2.5.0/core/utilities/setup/setupplugins.cpp:161:20: error: ‘class KIPI::ConfigWidget’ has no member named ‘slotCheckAll’
+/home/anaselli/mageia/digikam/BUILD/digikam-2.5.0/core/utilities/setup/setupplugins.cpp: In member function ‘void Digikam::SetupPlugins::slotClear()’:
+/home/anaselli/mageia/digikam/BUILD/digikam-2.5.0/core/utilities/setup/setupplugins.cpp:168:20: error: ‘class KIPI::ConfigWidget’ has no member named ‘slotClear’
+make[2]: *** [core/digikam/CMakeFiles/digikam.dir/__/utilities/setup/setupplugins.cpp.o] Errore 1
+make[2]: *** Attesa dei processi non terminati....
+make[1]: *** [core/digikam/CMakeFiles/digikam.dir/all] Errore 2
+Any kipi interface changes?
+
+Angelo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010975.html b/zarb-ml/mageia-dev/2012-January/010975.html new file mode 100644 index 000000000..be46b20ca --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010975.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] references to outside web sites/wiki + + + + + + + + + +

[Mageia-dev] references to outside web sites/wiki

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Thu Jan 5 01:11:50 CET 2012 +

+
+ +
Am Donnerstag, 5. Januar 2012, 00:33:16 schrieb Kamil Rytarowski:
+> W dniu 04.01.2012 21:06, Romain d'Alverny pisze:
+> > Would be good too to be able to mount a static mirror copy of it, if
+> > it's needed, but I am not sure how to import it (wget'ing a mediawiki
+> > instance is tricky).
+> 
+> Please take a look here http://code.google.com/p/wikiteam/
+I'm trying this just now. Will keep you informed.
+
+Thanks Kamil for pointing to this project.
+
+Oliver
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010976.html b/zarb-ml/mageia-dev/2012-January/010976.html new file mode 100644 index 000000000..7817ccc57 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010976.html @@ -0,0 +1,114 @@ + + + + [Mageia-dev] references to outside web sites/wiki + + + + + + + + + +

[Mageia-dev] references to outside web sites/wiki

+ Johnny A. Solbu + cooker at solbu.net +
+ Thu Jan 5 02:58:44 CET 2012 +

+
+ +
On Wednesday 04 January 2012 22:57, Florian Hubold wrote:
+> You didn't get the thread in the international Mandriva forum?
+
+No. I don't watch forums. I'm an old school user who started with Usenet in august 1998, and IRC a month later.
+I only use/read forums when I have to, like searching google for solutions to various problems. ;-)=
+
+I remember my ISP at that time, actively advertized Usenet groups back then. They even had Outlook Express automatically setup with a Usenet account as part of the automatic email setup routine. That's how I discovered usenet, and I still use it to this day.
+
+The only modern "forum" I use is facebook, only because it forces everyone to use their actuall names. I use it soley for the purpose of keeping in contact with friends who don't like email and IRC to much. :-)=
+
+-- 
+Johnny A. Solbu
+PGP key ID: 0xFA687324
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 189 bytes
+Desc: This is a digitally signed message part.
+URL: </pipermail/mageia-dev/attachments/20120105/7312ea13/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010977.html b/zarb-ml/mageia-dev/2012-January/010977.html new file mode 100644 index 000000000..005c8ead2 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010977.html @@ -0,0 +1,120 @@ + + + + [Mageia-dev] [packages-commits] [190229] new version 2.5.0 + + + + + + + + + +

[Mageia-dev] [packages-commits] [190229] new version 2.5.0

+ Nicolas L. + neoclust.kde at free.fr +
+ Thu Jan 5 03:17:11 CET 2012 +

+
+ +
Le 05/01/2012 00:47, Angelo Naselli a écrit :
+> mercoledì 4 gennaio 2012 alle 13:17, Angelo Naselli ha scritto:
+>> In data mercoledì 4 gennaio 2012 03:06:05, John Balcaen ha scritto:
+>>> 2012/1/3<root at mageia.org>:
+>>>> Revision 190229 Author fwang Date 2012-01-04 02:11:16 +0100 (Wed, 04 Jan
+>>>> 2012)
+>>>>
+>>>> Log Message
+>>>>
+>>>> new version 2.5.0
+>>>>
+>>>> Modified Paths
+>>>>
+>>>> cauldron/digikam/current/SOURCES/sha1.lst
+>>>> cauldron/digikam/current/SPECS/digikam.spec
+>>> [...]
+>>> Just in case digikam won't build until
+>>> https://bugs.kde.org/show_bug.cgi?id=287772 is fixed, maybe you can
+>>> help here ?
+>> John, can you ping me via irc, so that i can try to understand the problem?
+>>
+>>
+> FWIW patch:
+> http://bugsfiles.kde.org/attachment.cgi?id=67460
+> builds correctly that part, but as said i don't know
+> the code, so i don't know the changes.
+> It fails after though:
+> home/anaselli/mageia/digikam/BUILD/digikam-2.5.0/core/utilities/setup/setupplugins.cpp: In member function ‘void Digikam::SetupPlugins::slotCheckAll()’:
+> /home/anaselli/mageia/digikam/BUILD/digikam-2.5.0/core/utilities/setup/setupplugins.cpp:161:20: error: ‘class KIPI::ConfigWidget’ has no member named ‘slotCheckAll’
+> /home/anaselli/mageia/digikam/BUILD/digikam-2.5.0/core/utilities/setup/setupplugins.cpp: In member function ‘void Digikam::SetupPlugins::slotClear()’:
+> /home/anaselli/mageia/digikam/BUILD/digikam-2.5.0/core/utilities/setup/setupplugins.cpp:168:20: error: ‘class KIPI::ConfigWidget’ has no member named ‘slotClear’
+> make[2]: *** [core/digikam/CMakeFiles/digikam.dir/__/utilities/setup/setupplugins.cpp.o] Errore 1
+> make[2]: *** Attesa dei processi non terminati....
+> make[1]: *** [core/digikam/CMakeFiles/digikam.dir/all] Errore 2
+> Any kipi interface changes?
+>
+> Angelo
+can you try with : this commit : 
+http://commits.kde.org/digikam/25cc9c9876a5233bd630105d0110319892d4e18c    
+please
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010978.html b/zarb-ml/mageia-dev/2012-January/010978.html new file mode 100644 index 000000000..9b48a1327 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010978.html @@ -0,0 +1,106 @@ + + + + [Mageia-dev] KDE 4.8 rc2 (4.7.97) landing soon on cauldron + + + + + + + + + +

[Mageia-dev] KDE 4.8 rc2 (4.7.97) landing soon on cauldron

+ John Balcaen + mikala at mageia.org +
+ Thu Jan 5 04:01:03 CET 2012 +

+
+ +
Hello,
+
+Just to say that KDE 4.7.97 is now available on svn, i'll push it
+probably tomorrow afternoon in fact since i'm more tired & busy than
+expected.
+
+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/2012-January/010979.html b/zarb-ml/mageia-dev/2012-January/010979.html new file mode 100644 index 000000000..6345b2fd8 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010979.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] [packages-commits] [190229] new version 2.5.0 + + + + + + + + + +

[Mageia-dev] [packages-commits] [190229] new version 2.5.0

+ Angelo Naselli + anaselli at linux.it +
+ Thu Jan 5 12:26:56 CET 2012 +

+
+ +
> can you try with : this commit :
+> http://commits.kde.org/digikam/25cc9c9876a5233bd630105d0110319892d4e18c
+> please
+Yes it works :)
+
+But i think we're going to release new kipi so it should not be needed if not 
+in case of a backport, and since it's not open yet....
+
+
+-- 
+	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/20120105/16751f2e/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010980.html b/zarb-ml/mageia-dev/2012-January/010980.html new file mode 100644 index 000000000..cacf1f2bd --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010980.html @@ -0,0 +1,147 @@ + + + + [Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement + + + + + + + + + +

[Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Thu Jan 5 13:54:10 CET 2012 +

+
+ +
Le 04/01/2012 20:13, Luc Menut a écrit :
+> Le 04/01/2012 17:20, Guillaume Rousse a écrit :
+>>> 1) add support for optional README.*.urpmi (%ghost in spec):
+>>> This will allow to build this README.*.urpmi at install time in %pre,
+>>> %post or %trigger only when it's necessary.
+>> That will create files on the system unknown from rpm database, and
+>> unknown from urpmi too.
+>
+> nope, %ghost files are known from rpm database.
+> rpm -qpl task-obsolete-1-1.mga2.noarch.rpm
+> /usr/share/doc/task-obsolete
+> /usr/share/doc/task-obsolete/README.null-dummy.obsolete.urpmi
+> /usr/share/doc/task-obsolete/README.null.obsolete.urpmi
+Then the database will always contains entries for some files that only 
+will potentially exist on the systeme. The whole idea of conditionnaly 
+creating files in post-installation seems a bad idea.
+
+>> Rather than focusing on shiny automatic display mechanisms, I'd rather
+>> work on information content.
+>
+> we can|should do both.
+>
+> [...]
+>>
+>> Here are a few proposal of mines to make the situation better:
+>> - use a unique file name, enforced by convention, rather than references
+>> in package description, the same way Debian does with README.debian
+>> - display its content only in graphical context: command-line users
+>> usually know about this kind of convention to get information themselves
+>> - use standardised file content and markup to allow rpmdrake and other
+>> graphical tools to achieve the same kind of selection than file
+>> splitting today
+>> - define some kind of policy of what should be there, and what should
+>> not, to achieve minimal consistency
+>
+> I'm not particularly attached at the current system, but I find it works
+> rather well.
+> If we want that users read informations, the information should be
+> relevant in the context (too many informations, kill information);
+Indeed, that's why I suggest using standardised documentation templates 
+and conventions, rather than automated mecanisms.
+
+> e.g. it's useless (personnaly, I consider it's bad) to display
+> information about install when we update a package, and vice versa (I
+> don't know debian, and if the unique file README.debian allow this).
+The README.debian is just a plain old reference text file, and is never 
+automatically displayed. Debian does however has a powerful 
+post-installation interactive mecanism (debconf), which is usually used 
+for configuration, but could also get used for this kind of 
+context-specific information.
+
+I completly agree on the generic idea of making information access 
+easier. But I wouldn't reduce this to just extracting the minimal subset 
+of relevant information so as to display it automatically. Especially if 
+the suggested implementation involves messing with rpm idea of installed 
+files, and also make information access more complex for users as myself 
+who prefer to read plain old documentation files manually.
+
+This kind of context-dependant logic should better get implemented in 
+the installer rather than individual packages. And even in that case, 
+the added value of a technical solution someone will have to maintain
+over a simple remark in flashplayer plugin package documentation is 
+discussable.
+-- 
+BOFH excuse #62:
+
+need to wrap system in aluminum foil to fix problem
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010981.html b/zarb-ml/mageia-dev/2012-January/010981.html new file mode 100644 index 000000000..5e360e880 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010981.html @@ -0,0 +1,118 @@ + + + + [Mageia-dev] references to outside web sites/wiki + + + + + + + + + +

[Mageia-dev] references to outside web sites/wiki

+ Buchan Milne + bgmilne at zarb.org +
+ Thu Jan 5 15:54:36 CET 2012 +

+
+ +
On Wednesday, 4 January 2012 23:56:01 Romain d'Alverny wrote:
+> On Wed, Jan 4, 2012 at 22:36, Johnny A. Solbu <cooker at solbu.net> wrote:
+> > On Wednesday 04 January 2012 21:06, Romain d'Alverny wrote:
+> >> wiki.mandriva.com may be shut down for good in just a few days
+> > 
+> > What? Are Mandriva serisouly considering closing down the Wiki?
+> 
+> Mandriva is on the path to filing for bankruptcy on January 16th.
+
+There may be more consequences / preparation than ensuring our web content is 
+fully independant.
+
+We may need to consider:
+1)Prepare for upgrading our servers from Mandiva 2010.x to Mageia (1?). 
+However, I know for a fact that some packages we have on them are not 
+available in Mageia yet.
+
+2)Ensuring we are ready for users who are still on Mandriva to migrate to 
+Mageia. IMHO, this should mean:
+-Backports media resolved
+-Highlighting documentation on upgrading / switching (e.g. downgrading from 
+Mandriva 2011 to Mageia 1, even if it is by exporting package leaf list and 
+backing up /etc, /usr/local/ etc. and re-install keeping /home) such as 
+http://www.mageia.org/en/1/migrate/ on the Wiki and website/blog post
+-Forum section dedicated to assisting users migrating?
+-Blog post prepared, something that commenters on various news sites can point 
+to in replies?
+-Possibly considering contacting large mirror sites (e.g. mirrors.kernel.org) 
+who currently mirror Mandriva, but not Mageia?
+-A concerted effort to start producing comprehensive documentation, as soon we 
+may not be able to point users to online copies of Mandriva documentation
+
+(I personally need to upgrade 3 of my machines and a few machines of 
+friends/family/colleagues)
+
+Regards,
+Buchan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010982.html b/zarb-ml/mageia-dev/2012-January/010982.html new file mode 100644 index 000000000..553407be8 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010982.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] references to outside web sites/wiki + + + + + + + + + +

[Mageia-dev] references to outside web sites/wiki

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Thu Jan 5 16:05:32 CET 2012 +

+
+ +
2012/1/5 Buchan Milne <bgmilne at zarb.org>:
+> -Possibly considering contacting large mirror sites (e.g. mirrors.kernel.org)
+> who currently mirror Mandriva, but not Mageia?
+
+Just for the records: mirrors.kernel.org mirror Mageia.
+But surely there are more large sites to be contacted.
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010983.html b/zarb-ml/mageia-dev/2012-January/010983.html new file mode 100644 index 000000000..942018231 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010983.html @@ -0,0 +1,175 @@ + + + + [Mageia-dev] [packages-commits] [191611] - new sources + + + + + + + + + +

[Mageia-dev] [packages-commits] [191611] - new sources

+ Jani Välimaa + jani.valimaa at gmail.com +
+ Thu Jan 5 16:38:25 CET 2012 +

+
+ +
2012/1/5  <root at mageia.org>:
+> Revision 191611 Author matteo Date 2012-01-05 16:10:45 +0100 (Thu, 05 Jan
+> 2012)
+>
+> Log Message
+>
+> - new sources
+> - switched antico launcher icon with mageia icon
+>
+> Modified Paths
+>
+> cauldron/antico/current/SPECS/antico.spec
+>
+> Modified: cauldron/antico/current/SPECS/antico.spec
+> ===================================================================
+> --- cauldron/antico/current/SPECS/antico.spec	2012-01-05 15:10:00 UTC (rev
+> 191610)
+> +++ cauldron/antico/current/SPECS/antico.spec	2012-01-05 15:10:45 UTC (rev
+> 191611)
+> @@ -1,13 +1,16 @@
+> -%define git 33b232a
+> +#define git 33b232a
+> +%define git 74aa84c
+>
+>  Name:		antico
+>  Version:	0.2
+> -Release:	%mkrel -c git 1
+> +Release:	%mkrel -c git 2
+>  Summary:	Antico Desktop/Window Manager
+>  License:	GPLv2
+>  Url:		http://www.giuseppecigala.it/Antico.html
+>  #Source0:	https://github.com/antico/antico/tarball/master
+> -Source:		%{name}-%{name}-%{git}.tar.gz
+> +Source:		pasmatt-%{name}-%{git}.zip
+> +#Source:		%{name}-%{name}-%{git}.tar.gz
+> +Patch0:		%{name}-mageia_icon.patch
+>  Group:		Graphical desktop/Other
+>
+>  BuildRequires:	qt4-devel
+> @@ -23,17 +26,20 @@
+>  without any other external dependencies.
+>
+>  %prep
+> -%setup -q -n %{name}-%{name}-%{git}
+> +%setup -q -n pasmatt-%{name}-%{git}
+> +%apply_patches
+>
+>  # patch to make antico more modular
+> -find . -name "*.cpp" -type f -exec sed -i -e
+> 's|QCoreApplication::applicationDirPath()[[:space:]]+[[:space:]]"/antico.cfg"|QDir::homePath()
+> + "/.antico.cfg"|g' {} \;
+> -find . -name "*.cpp" -type f -exec sed -i -e
+> 's|QCoreApplication::applicationDirPath()[[:space:]]+[[:space:]]"/theme|QDir::rootPath()
+> + "usr/share/antico/theme|g' {} \;
+> -find . -name "*.cpp" -type f -exec sed -i -e
+> 's|QCoreApplication::applicationDirPath()[[:space:]]+[[:space:]]"/language|QDir::rootPath()
+> + "usr/share/antico/language|g' {} \;
+> +# fixed upstream (pasmatt fork on github)
+> +#find . -name "*.cpp" -type f -exec sed -i -e
+> 's|QCoreApplication::applicationDirPath()[[:space:]]+[[:space:]]"/antico.cfg"|QDir::homePath()
+> + "/.antico.cfg"|g' {} \;
+> +#find . -name "*.cpp" -type f -exec sed -i -e
+> 's|QCoreApplication::applicationDirPath()[[:space:]]+[[:space:]]"/theme|QDir::rootPath()
+> + "usr/share/antico/theme|g' {} \;
+> +#find . -name "*.cpp" -type f -exec sed -i -e
+> 's|QCoreApplication::applicationDirPath()[[:space:]]+[[:space:]]"/language|QDir::rootPath()
+> + "usr/share/antico/language|g' {} \;
+>
+>  %build
+>  %{qmake_qt4}
+> -# workaround to allow compilation on mga2 (why?)
+> -%make SUBLIBS="-lXext -lX11"
+> +# FIXED - workaround to allow compilation on mga2 (why?)
+> +#%make SUBLIBS="-lXext -lX11"
+> +%make
+>
+>  %install
+>  %__rm -fr %{buildroot}
+>
+
+Please remove old, obsoleted and not needed parts of .spec instead of
+commenting them out. IMHO there's no need to keep eg. 3 different
+source tags in .spec. Changes can be restored and reverted from svn
+afterwards if needed.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010984.html b/zarb-ml/mageia-dev/2012-January/010984.html new file mode 100644 index 000000000..642c2d564 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010984.html @@ -0,0 +1,112 @@ + + + + [Mageia-dev] references to outside web sites/wiki + + + + + + + + + +

[Mageia-dev] references to outside web sites/wiki

+ Damien Lallement + mageia at damsweb.net +
+ Thu Jan 5 16:28:39 CET 2012 +

+
+ +
Le 05/01/2012 15:54, Buchan Milne a écrit :
+> On Wednesday, 4 January 2012 23:56:01 Romain d'Alverny wrote:
+>> On Wed, Jan 4, 2012 at 22:36, Johnny A. Solbu<cooker at solbu.net>  wrote:
+>>> On Wednesday 04 January 2012 21:06, Romain d'Alverny wrote:
+>>>> wiki.mandriva.com may be shut down for good in just a few days
+>>>
+>>> What? Are Mandriva serisouly considering closing down the Wiki?
+>>
+>> Mandriva is on the path to filing for bankruptcy on January 16th.
+>
+> There may be more consequences / preparation than ensuring our web content is
+> fully independant.
+>
+> We may need to consider:
+> 1)Prepare for upgrading our servers from Mandiva 2010.x to Mageia (1?).
+> However, I know for a fact that some packages we have on them are not
+> available in Mageia yet.
+
+This will be done this month with boklm, misc, rtp and I going to our 
+datacenter in Marseille for the upgrade, the installation of a new 
+server for QA/packagers and the installation of the ARM BS.
+
+> [...]
+
+Dams
+-- 
+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/2012-January/010985.html b/zarb-ml/mageia-dev/2012-January/010985.html new file mode 100644 index 000000000..4d76311fb --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010985.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement + + + + + + + + + +

[Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement

+ Anssi Hannula + anssi at mageia.org +
+ Thu Jan 5 17:49:43 CET 2012 +

+
+ +
On 05.01.2012 14:54, Guillaume Rousse wrote:
+> Le 04/01/2012 20:13, Luc Menut a écrit :
+>> Le 04/01/2012 17:20, Guillaume Rousse a écrit :
+>>>> 1) add support for optional README.*.urpmi (%ghost in spec):
+>>>> This will allow to build this README.*.urpmi at install time in %pre,
+>>>> %post or %trigger only when it's necessary.
+>>> That will create files on the system unknown from rpm database, and
+>>> unknown from urpmi too.
+>>
+>> nope, %ghost files are known from rpm database.
+>> rpm -qpl task-obsolete-1-1.mga2.noarch.rpm
+>> /usr/share/doc/task-obsolete
+>> /usr/share/doc/task-obsolete/README.null-dummy.obsolete.urpmi
+>> /usr/share/doc/task-obsolete/README.null.obsolete.urpmi
+> Then the database will always contains entries for some files that only
+> will potentially exist on the systeme. The whole idea of conditionnaly
+> creating files in post-installation seems a bad idea.
+
+Those already exist for all localization which is not installed in your
+system. However, I do agree it is significantly worse in this case as
+the user can wonder why a *documentation* file that seems important by
+its filename is missing.
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010986.html b/zarb-ml/mageia-dev/2012-January/010986.html new file mode 100644 index 000000000..e72b8cfed --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010986.html @@ -0,0 +1,126 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron nonfree/release drakx-installer-images-1.59-2.mga2.nonfree + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron nonfree/release drakx-installer-images-1.59-2.mga2.nonfree

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Thu Jan 5 18:22:35 CET 2012 +

+
+ +
On 5 January 2012 17:34, tmb <buildsystem-daemon at mageia.org> wrote:
+> tmb <tmb> 1.59-2.mga2:
+> + Revision: 191558
+> - build with kernel-3.2.0-1.mga2
+> - kernel-firmware-extra is now kernel-firmware-nonfree
+
+BTW, boot.iso is huge.
+Most of it is the two kernels flavors (desktop & server) and their modules
+for storage, network, ...
+
+The rationale for having 2 alternatives was to have a fallback when main kernel
+failes to handle the hardware.
+
+Eg by kernel*2.4.x times, we had kernel-BOOT-2.4.x as main kernel
+(== main flavor debloated/reduced down) and a kernel-2.2.x as
+alternative.
+Thus if the newer 2.4.x branch failed to handle a machine,
+odds were that old 2.2.x  would success.
+
+Later we provide an older kernel, eg 2.6.11-6mdk-i586-up-1GB,
+2.6.11-6mdkBOOT & 2.6.8.1-12mdkBOOT).
+
+But now we use the same codebase for both alternatives.
+The only difference is that we use two flavors, regular/desktop
+and server.
+
+At least on x86_64, I fail to see how the small difference between
+these two flavors can help any machine.
+
+I suggest we drop the kernel-server alternative at least on x86_64
+in order to save half boot.iso size (less of course on the tainted one)
+as well as saving 20m for packages on CDs & DVDs.
+
+And maybe on i586 too...
+
+WDYT?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010987.html b/zarb-ml/mageia-dev/2012-January/010987.html new file mode 100644 index 000000000..0887138a3 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010987.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] Required documentation not yet imported from Mandriva wiki + + + + + + + + + +

[Mageia-dev] Required documentation not yet imported from Mandriva wiki

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Thu Jan 5 18:26:23 CET 2012 +

+
+ +
Hi,
+
+as all of you might know by now, it could happen that the Mandriva
+wiki will go offline on January 16th.
+In order to make sure we don't loose important documentation, please
+check if you are using any Mandriva documentation that hasnot yet been
+imported into the Mageia wiki.
+I know, there's some arround (e.g. the overlinking/underlinking pages).
+
+Please tell here or better still, import those pages and tell here!
+
+Mandriva wiki is under CC-by-SA, so there is no license issues.
+
+Oliver
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010988.html b/zarb-ml/mageia-dev/2012-January/010988.html new file mode 100644 index 000000000..3139fd041 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010988.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] [soft-commits] [2578] left-background for Mageia 2 Alpha3 + + + + + + + + + +

[Mageia-dev] [soft-commits] [2578] left-background for Mageia 2 Alpha3

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Thu Jan 5 19:10:05 CET 2012 +

+
+ +
On 5 January 2012 19:00,  <root at mageia.org> wrote:
+> Revision 2578 Author ennael Date 2012-01-05 19:00:54 +0100 (Thu, 05 Jan
+> 2012)
+>
+> Log Message
+>
+> left-background for Mageia 2 Alpha3
+
+you should have altered perl-install/install/NEWS too...
+
+> drakx/trunk/perl-install/install/pixmaps/left-background.png
+>
+> Modified: drakx/trunk/perl-install/install/pixmaps/left-background.png
+> ===================================================================
+> (Binary files differ)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010989.html b/zarb-ml/mageia-dev/2012-January/010989.html new file mode 100644 index 000000000..561d93e27 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010989.html @@ -0,0 +1,160 @@ + + + + [Mageia-dev] [packages-commits] [189967] - version upgrade + + + + + + + + + +

[Mageia-dev] [packages-commits] [189967] - version upgrade

+ Matteo + pasotti.matteo at gmail.com +
+ Thu Jan 5 20:15:14 CET 2012 +

+
+ +
-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
+Il 03/01/2012 17:18, Jani Välimaa ha scritto:
+> 2012/1/3  <root at mageia.org>:
+>> Revision 189967 Author matteo Date 2012-01-03 16:46:56 +0100 (Tue, 03 Jan
+>> 2012)
+>>
+>> Log Message
+>>
+>> - version upgrade
+>> - used macros instead of command names
+>>
+>> Modified Paths
+>>
+>> cauldron/x86info/current/SPECS/x86info.spec
+>>
+>> Modified: cauldron/x86info/current/SPECS/x86info.spec
+>> ===================================================================
+>> --- cauldron/x86info/current/SPECS/x86info.spec	2012-01-03 15:45:07 UTC (rev
+>> 189966)
+>> +++ cauldron/x86info/current/SPECS/x86info.spec	2012-01-03 15:46:56 UTC (rev
+>> 189967)
+>> @@ -1,5 +1,5 @@
+>>  %define	name	x86info
+>> -%define	version	1.29
+>> +%define	version	1.30
+>>  %define realver	%{version}
+>>  #define cvsdate	20050420
+>>
+>> @@ -11,7 +11,7 @@
+>>  Group:		System/Kernel and hardware
+>>  BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot
+>>  URL:		http://www.codemonkey.org.uk/projects/x86info/
+>> -Source0:	%{name}-%{realver}%{?cvsdate:-%{cvsdate}}.tar.bz2
+>> +Source0:	%{name}-%{realver}%{?cvsdate:-%{cvsdate}}.tgz
+>>  Patch0:		x86info-1.17-intel-flags.patch
+>>  Patch1:		x86info-1.17-intel-caches.patch
+>>  Patch2:		x86info-1.17-cpuid-with-ecx-input.patch
+>> @@ -33,17 +33,18 @@
+>>  %setup -q -n %{name}-%{realver}
+>>
+>>  %build
+>> -make CFLAGS="%{optflags}"
+>> +#make CFLAGS="%{optflags}"
+>> +%make
+>>
+>>  %install
+>> -rm -rf %{buildroot}
+>> -install -d %{buildroot}%{_bindir}
+>> -install -d %{buildroot}%{_mandir}/man1
+>> -install -m755 %{name} %{buildroot}%{_bindir}/
+>> -install -m755 %{name}.1 %{buildroot}%{_mandir}/man1/
+>> +%__rm -rf %{buildroot}
+>> +%__install -d %{buildroot}%{_bindir}
+>> +%__install -d %{buildroot}%{_mandir}/man1
+>> +%__install -m755 %{name} %{buildroot}%{_bindir}/
+>> +%__install -m755 %{name}.1 %{buildroot}%{_mandir}/man1/
+>>
+> 
+> I think this is pretty much opposite what everyone else is doing. IMHO
+> this also makes .spec harder to read.
+Hi Jani,
+I'm not able to find references on our wiki that say macros (like
+%__install or %__rm) are deprecated, can You point me in the right
+direction, please?
+
+IMHO the spec file is as readable as the others.
+Regards,
+- -- 
+Matteo
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.11 (GNU/Linux)
+Comment: Using GnuPG with Mageia - http://enigmail.mozdev.org/
+
+iQEcBAEBAgAGBQJPBfa/AAoJED3LowjDDWbNTCkH+QF1KleqJc1qU5qyjE7X4dtM
+FL7iC3OAN93yvVYp57ABHKy9RTF87vbcg6TcRn47BrL4kk8kTUvRftSW94kOIfAJ
+Mp7bINrX7UjKPIS4VMvKW56yUN4JMPMcJ9f7pNIE25tnwBzg+Ov0A9MiqVMEZqQE
+28GSbl63OFnBag0bDsLKd8POveH91N7FivKcQ5KKwGXm/kw60dlHqn0EH06DSMkV
+jTrLU6j4iUvuPitcm22kBtYPsppTyuKmisGrGwCUoJu2sLMZon0zOTbq0GJnSqDb
+EhV6w7NiW6ZQeM1+Zvc9IsftzCrJgoWsrTRvabH8B5CPQHb1AcDdid3oSW7SU3Y=
+=Zrqs
+-----END PGP SIGNATURE-----
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010990.html b/zarb-ml/mageia-dev/2012-January/010990.html new file mode 100644 index 000000000..65538cd48 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010990.html @@ -0,0 +1,141 @@ + + + + [Mageia-dev] [packages-commits] [189967] - version upgrade + + + + + + + + + +

[Mageia-dev] [packages-commits] [189967] - version upgrade

+ Matteo + pasotti.matteo at gmail.com +
+ Thu Jan 5 20:36:12 CET 2012 +

+
+ +
-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
+Il 03/01/2012 17:30, Guillaume Rousse ha scritto:
+> Le 03/01/2012 17:18, Jani Välimaa a écrit :
+>>> @@ -11,7 +11,7 @@
+>>>   Group:        System/Kernel and hardware
+>>>   BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot
+>>>   URL:        http://www.codemonkey.org.uk/projects/x86info/
+>>> -Source0:    %{name}-%{realver}%{?cvsdate:-%{cvsdate}}.tar.bz2
+>>> +Source0:    %{name}-%{realver}%{?cvsdate:-%{cvsdate}}.tgz
+>>>   Patch0:        x86info-1.17-intel-flags.patch
+>>>   Patch1:        x86info-1.17-intel-caches.patch
+>>>   Patch2:        x86info-1.17-cpuid-with-ecx-input.patch
+>>> @@ -33,17 +33,18 @@
+>>>   %setup -q -n %{name}-%{realver}
+>>>
+>>>   %build
+>>> -make CFLAGS="%{optflags}"
+>>> +#make CFLAGS="%{optflags}"
+>>> +%make
+>>>
+>>>   %install
+>>> -rm -rf %{buildroot}
+>>> -install -d %{buildroot}%{_bindir}
+>>> -install -d %{buildroot}%{_mandir}/man1
+>>> -install -m755 %{name} %{buildroot}%{_bindir}/
+>>> -install -m755 %{name}.1 %{buildroot}%{_mandir}/man1/
+>>> +%__rm -rf %{buildroot}
+>>> +%__install -d %{buildroot}%{_bindir}
+>>> +%__install -d %{buildroot}%{_mandir}/man1
+>>> +%__install -m755 %{name} %{buildroot}%{_bindir}/
+>>> +%__install -m755 %{name}.1 %{buildroot}%{_mandir}/man1/
+>>>
+>>
+>> I think this is pretty much opposite what everyone else is doing. IMHO
+>> this also makes .spec harder to read.
+> Morevoer, it mixes pure cosmetics changes, as some of those macros just
+> expand to the command itself, as install vs %__install,
+Hi Guillaume,
+I'm sorry, but I don't think that /usr/bin/install it's equal to
+'install'. There are technical reasons to avoid these macros? Can you
+suggest me some reference, please? I'm not able to find nothing about
+this topic.
+
+ with behaviour
+> changes, as other macros expand to the command with additional
+> arguments, as make vs %make, which is actually make -j.
+> 
+So if I need to invoke make -j what should I do?
+Again, excuse me -I'm not so skilled- but why should I avoid to call
+make using -j option?
+
+Be patient, please :-)
+- -- 
+Matteo
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.11 (GNU/Linux)
+Comment: Using GnuPG with Mageia - http://enigmail.mozdev.org/
+
+iQEcBAEBAgAGBQJPBfuoAAoJED3LowjDDWbNZFIH/jDp/mS0Cw3yFIFHuOnBJ70y
+tVw5z+D8DUf0SSOaXU5htnob9zXEg5fyl+adEcDb3s7XLl4Y/Bw5ER38YwHO4Kad
+e5n/UnDCIuaWZeSkaRegMJRtu8mjCvnz4303M6VQbS/bopgbFZ5oTmVS5jM0YIEK
+Qw35ACjrelcZSQy49HyDehbIT9g4jEvLSM+q7nEIF5EosQ1o+pnu/K6FtnCtD64V
+bkUQcnvBoGTibqeD1dhI8dp7DPLEuc1GsZikxPctpSMmojwwZQP5lNyodkko3eyh
+iQ3GAT/JSUZB2D8ysYSUgJUFR9hcgFtaETg5byo8vhUQFN9tgYRUzr4kjrO2v6I=
+=NhEx
+-----END PGP SIGNATURE-----
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010991.html b/zarb-ml/mageia-dev/2012-January/010991.html new file mode 100644 index 000000000..f2b4e583b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010991.html @@ -0,0 +1,189 @@ + + + + [Mageia-dev] [packages-commits] [191611] - new sources + + + + + + + + + +

[Mageia-dev] [packages-commits] [191611] - new sources

+ Matteo + pasotti.matteo at gmail.com +
+ Thu Jan 5 20:37:45 CET 2012 +

+
+ +
-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
+Il 05/01/2012 16:38, Jani Välimaa ha scritto:
+> 2012/1/5  <root at mageia.org>:
+>> Revision 191611 Author matteo Date 2012-01-05 16:10:45 +0100 (Thu, 05 Jan
+>> 2012)
+>>
+>> Log Message
+>>
+>> - new sources
+>> - switched antico launcher icon with mageia icon
+>>
+>> Modified Paths
+>>
+>> cauldron/antico/current/SPECS/antico.spec
+>>
+>> Modified: cauldron/antico/current/SPECS/antico.spec
+>> ===================================================================
+>> --- cauldron/antico/current/SPECS/antico.spec	2012-01-05 15:10:00 UTC (rev
+>> 191610)
+>> +++ cauldron/antico/current/SPECS/antico.spec	2012-01-05 15:10:45 UTC (rev
+>> 191611)
+>> @@ -1,13 +1,16 @@
+>> -%define git 33b232a
+>> +#define git 33b232a
+>> +%define git 74aa84c
+>>
+>>  Name:		antico
+>>  Version:	0.2
+>> -Release:	%mkrel -c git 1
+>> +Release:	%mkrel -c git 2
+>>  Summary:	Antico Desktop/Window Manager
+>>  License:	GPLv2
+>>  Url:		http://www.giuseppecigala.it/Antico.html
+>>  #Source0:	https://github.com/antico/antico/tarball/master
+>> -Source:		%{name}-%{name}-%{git}.tar.gz
+>> +Source:		pasmatt-%{name}-%{git}.zip
+>> +#Source:		%{name}-%{name}-%{git}.tar.gz
+>> +Patch0:		%{name}-mageia_icon.patch
+>>  Group:		Graphical desktop/Other
+>>
+>>  BuildRequires:	qt4-devel
+>> @@ -23,17 +26,20 @@
+>>  without any other external dependencies.
+>>
+>>  %prep
+>> -%setup -q -n %{name}-%{name}-%{git}
+>> +%setup -q -n pasmatt-%{name}-%{git}
+>> +%apply_patches
+>>
+>>  # patch to make antico more modular
+>> -find . -name "*.cpp" -type f -exec sed -i -e
+>> 's|QCoreApplication::applicationDirPath()[[:space:]]+[[:space:]]"/antico.cfg"|QDir::homePath()
+>> + "/.antico.cfg"|g' {} \;
+>> -find . -name "*.cpp" -type f -exec sed -i -e
+>> 's|QCoreApplication::applicationDirPath()[[:space:]]+[[:space:]]"/theme|QDir::rootPath()
+>> + "usr/share/antico/theme|g' {} \;
+>> -find . -name "*.cpp" -type f -exec sed -i -e
+>> 's|QCoreApplication::applicationDirPath()[[:space:]]+[[:space:]]"/language|QDir::rootPath()
+>> + "usr/share/antico/language|g' {} \;
+>> +# fixed upstream (pasmatt fork on github)
+>> +#find . -name "*.cpp" -type f -exec sed -i -e
+>> 's|QCoreApplication::applicationDirPath()[[:space:]]+[[:space:]]"/antico.cfg"|QDir::homePath()
+>> + "/.antico.cfg"|g' {} \;
+>> +#find . -name "*.cpp" -type f -exec sed -i -e
+>> 's|QCoreApplication::applicationDirPath()[[:space:]]+[[:space:]]"/theme|QDir::rootPath()
+>> + "usr/share/antico/theme|g' {} \;
+>> +#find . -name "*.cpp" -type f -exec sed -i -e
+>> 's|QCoreApplication::applicationDirPath()[[:space:]]+[[:space:]]"/language|QDir::rootPath()
+>> + "usr/share/antico/language|g' {} \;
+>>
+>>  %build
+>>  %{qmake_qt4}
+>> -# workaround to allow compilation on mga2 (why?)
+>> -%make SUBLIBS="-lXext -lX11"
+>> +# FIXED - workaround to allow compilation on mga2 (why?)
+>> +#%make SUBLIBS="-lXext -lX11"
+>> +%make
+>>
+>>  %install
+>>  %__rm -fr %{buildroot}
+>>
+> 
+> Please remove old, obsoleted and not needed parts of .spec instead of
+> commenting them out. IMHO there's no need to keep eg. 3 different
+> source tags in .spec. Changes can be restored and reverted from svn
+> afterwards if needed.
+Yes, you're right. I'll clean this spec asap.
+Thank you.
+- -- 
+Matteo
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.11 (GNU/Linux)
+Comment: Using GnuPG with Mageia - http://enigmail.mozdev.org/
+
+iQEcBAEBAgAGBQJPBfwJAAoJED3LowjDDWbN7zwH/Ax0YYijiwcgHysc4YV8GQT7
+Eb9IRRBDs56z8ZXnvG4scjBMEx3BdpeCFY9Mx5rtsuaV/YQzKb0oDwnsnI/TOsXO
+RRSVNbUCn2sjWv+wUNK+YSypOYohiQOaK/wf0eRp+NiSAdz+shbaygSlAAInEdGz
+7ZS3XxjxfTldNex2TC4YbqscnoyIpsQRvVClIiyK36pMPbSBLNZY8pb80uFnlyHv
+wk5ye3jHsKeZtL/SPncShlUnF1KJPHXs49FiNY1RHf603gGZ1CNax4c2H8hyS3kO
+G+QBzOICHH/IJpgTUiJzsrHbEN7IOfvQwGYP6aJwSX93eZ+Lls2iaBZT5z6zyqk=
+=CveC
+-----END PGP SIGNATURE-----
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010992.html b/zarb-ml/mageia-dev/2012-January/010992.html new file mode 100644 index 000000000..494eaf822 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010992.html @@ -0,0 +1,137 @@ + + + + [Mageia-dev] [packages-commits] [189967] - version upgrade + + + + + + + + + +

[Mageia-dev] [packages-commits] [189967] - version upgrade

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Thu Jan 5 20:47:15 CET 2012 +

+
+ +
Le 05/01/2012 20:36, Matteo a écrit :
+> -----BEGIN PGP SIGNED MESSAGE-----
+> Hash: SHA1
+>
+> Il 03/01/2012 17:30, Guillaume Rousse ha scritto:
+>> Le 03/01/2012 17:18, Jani Välimaa a écrit :
+>>>> @@ -11,7 +11,7 @@
+>>>>    Group:        System/Kernel and hardware
+>>>>    BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot
+>>>>    URL:        http://www.codemonkey.org.uk/projects/x86info/
+>>>> -Source0:    %{name}-%{realver}%{?cvsdate:-%{cvsdate}}.tar.bz2
+>>>> +Source0:    %{name}-%{realver}%{?cvsdate:-%{cvsdate}}.tgz
+>>>>    Patch0:        x86info-1.17-intel-flags.patch
+>>>>    Patch1:        x86info-1.17-intel-caches.patch
+>>>>    Patch2:        x86info-1.17-cpuid-with-ecx-input.patch
+>>>> @@ -33,17 +33,18 @@
+>>>>    %setup -q -n %{name}-%{realver}
+>>>>
+>>>>    %build
+>>>> -make CFLAGS="%{optflags}"
+>>>> +#make CFLAGS="%{optflags}"
+>>>> +%make
+>>>>
+>>>>    %install
+>>>> -rm -rf %{buildroot}
+>>>> -install -d %{buildroot}%{_bindir}
+>>>> -install -d %{buildroot}%{_mandir}/man1
+>>>> -install -m755 %{name} %{buildroot}%{_bindir}/
+>>>> -install -m755 %{name}.1 %{buildroot}%{_mandir}/man1/
+>>>> +%__rm -rf %{buildroot}
+>>>> +%__install -d %{buildroot}%{_bindir}
+>>>> +%__install -d %{buildroot}%{_mandir}/man1
+>>>> +%__install -m755 %{name} %{buildroot}%{_bindir}/
+>>>> +%__install -m755 %{name}.1 %{buildroot}%{_mandir}/man1/
+>>>>
+>>>
+>>> I think this is pretty much opposite what everyone else is doing. IMHO
+>>> this also makes .spec harder to read.
+>> Morevoer, it mixes pure cosmetics changes, as some of those macros just
+>> expand to the command itself, as install vs %__install,
+> Hi Guillaume,
+> I'm sorry, but I don't think that /usr/bin/install it's equal to
+> 'install'. There are technical reasons to avoid these macros? Can you
+> suggest me some reference, please? I'm not able to find nothing about
+> this topic.
+Just readability, and consistency with other packages. There is no 
+advantage to justify this additional complexity here.
+
+>   with behaviour
+>> changes, as other macros expand to the command with additional
+>> arguments, as make vs %make, which is actually make -j.
+>>
+> So if I need to invoke make -j what should I do?
+> Again, excuse me -I'm not so skilled- but why should I avoid to call
+> make using -j option?
+>
+> Be patient, please :-)
+You shouldn't. You're supposed to use %make, not 'make' nor '%__make'. 
+The problem is just to mix cosmetic and non-cosmetic changes in a single 
+commit.
+-- 
+BOFH excuse #281:
+
+The co-locator cannot verify the frame-relay gateway to the ISDN server.
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010993.html b/zarb-ml/mageia-dev/2012-January/010993.html new file mode 100644 index 000000000..9c9e26f98 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010993.html @@ -0,0 +1,111 @@ + + + + [Mageia-dev] [packages-commits] [189967] - version upgrade + + + + + + + + + +

[Mageia-dev] [packages-commits] [189967] - version upgrade

+ Jani Välimaa + jani.valimaa at gmail.com +
+ Thu Jan 5 21:14:02 CET 2012 +

+
+ +
2012/1/5 Matteo <pasotti.matteo at gmail.com>:
+> -----BEGIN PGP SIGNED MESSAGE-----
+> Hash: SHA1
+>
+> Il 03/01/2012 17:18, Jani Välimaa ha scritto:
+>> 2012/1/3  <root at mageia.org>:
+>>> Revision 189967 Author matteo Date 2012-01-03 16:46:56 +0100 (Tue, 03 Jan
+>>> 2012)
+>>>
+>>> Log Message
+>>>
+>>> - version upgrade
+>>> - used macros instead of command names
+>>>
+>>
+>> I think this is pretty much opposite what everyone else is doing. IMHO
+>> this also makes .spec harder to read.
+> Hi Jani,
+> I'm not able to find references on our wiki that say macros (like
+> %__install or %__rm) are deprecated, can You point me in the right
+> direction, please?
+>
+> IMHO the spec file is as readable as the others.
+
+I'm not sure what our wiki says about this, but in majority of .specs
+I've seen in these couple of years I've been a packager, macros aren't
+used for install, mkdir or cp.
+
+This was also discussed a few months ago [1], but no decisions was made.
+
+There was link to Fedora wiki [2] about macros in the previous
+discussion. In short, Fedora wiki basically says that macros shouldn't
+be used for system executables. Maybe this should be also stated in
+our wiki?!
+
+[1] https://www.zarb.org/pipermail/mageia-dev/2011-August/007400.html
+[2] http://fedoraproject.org/wiki/Packaging:Guidelines#Macros
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010994.html b/zarb-ml/mageia-dev/2012-January/010994.html new file mode 100644 index 000000000..38e4abb09 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010994.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron nonfree/release drakx-installer-images-1.59-2.mga2.nonfree + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron nonfree/release drakx-installer-images-1.59-2.mga2.nonfree

+ Sander Lepik + sander.lepik at eesti.ee +
+ Thu Jan 5 22:23:46 CET 2012 +

+
+ +
05.01.2012 19:22, Thierry Vignaud kirjutas:
+> On 5 January 2012 17:34, tmb<buildsystem-daemon at mageia.org>  wrote:
+>> tmb<tmb>  1.59-2.mga2:
+>> + Revision: 191558
+>> - build with kernel-3.2.0-1.mga2
+>> - kernel-firmware-extra is now kernel-firmware-nonfree
+> And maybe on i586 too...
+>
+> WDYT?
+Good idea, boot.iso is needed to get things running. You can install other kernels later.
+
+--
+Sander
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010995.html b/zarb-ml/mageia-dev/2012-January/010995.html new file mode 100644 index 000000000..c0ddf41bf --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010995.html @@ -0,0 +1,321 @@ + + + + [Mageia-dev] List of CVE referencing software versions present in Mageia 1 + + + + + + + + + +

[Mageia-dev] List of CVE referencing software versions present in Mageia 1

+ Pascal Terjan + pterjan at gmail.com +
+ Thu Jan 5 23:37:54 CET 2012 +

+
+ +
Here is the output of a little script I just wrote.
+
+Vulnerable version, please check that a patch was applied if needed
+* arora 0.11.0
+  - CVE-2011-3367
+* bind 9.8.0
+  - CVE-2011-1907
+  - CVE-2011-1910
+  - CVE-2011-2464
+  - CVE-2011-2465
+  - CVE-2011-4313
+* cherokee 1.0.19
+  - CVE-2011-2190
+  - CVE-2011-2191
+* conky 1.8.1
+  - CVE-2011-3616
+* cups 1.4.6
+  - CVE-2011-2896
+  - CVE-2011-3170
+* dbus 1.4.1
+  - CVE-2011-2200
+* dhcp 4.2.1
+  - CVE-2011-0997
+  - CVE-2011-2748
+  - CVE-2011-2749
+  - CVE-2011-4539
+* drupal 7.0
+  - CVE-2011-2687
+  - CVE-2011-3730
+* empathy 2.34.0
+  - CVE-2011-3635
+  - CVE-2011-4170
+* etherape 0.9.10
+  - CVE-2011-3369
+* fuse 2.8.5
+  - CVE-2011-0541
+  - CVE-2011-0542
+  - CVE-2011-0543
+* ganglia 3.1.7
+  - CVE-2011-3741
+* gdm 2.32.1
+  - CVE-2011-1709
+* gimp 2.6.11
+  - CVE-2011-1178
+  - CVE-2011-1782
+* glibc 2.12.1
+  - CVE-2011-1071
+  - CVE-2011-1089
+  - CVE-2011-1095
+  - CVE-2011-1658
+  - CVE-2011-1659
+* glpi 0.78.2
+  - CVE-2011-2720
+* icinga
+  - CVE-2011-2179
+* jasper 1.900.1
+  - CVE-2011-4516
+  - CVE-2011-4517
+* keepalived 1.2.2
+  - CVE-2011-1784
+* kernel 2.6.38.8
+  - CVE-2011-0726
+  - CVE-2011-1170
+  - CVE-2011-1171
+  - CVE-2011-1172
+  - CVE-2011-1173
+  - CVE-2011-1771
+  - CVE-2011-1776
+  - CVE-2011-2184
+  - CVE-2011-2213
+  - CVE-2011-2484
+  - CVE-2011-2492
+  - CVE-2011-2497
+  - CVE-2011-2534
+  - CVE-2011-2689
+  - CVE-2011-2695
+  - CVE-2011-2700
+  - CVE-2011-2723
+  - CVE-2011-2928
+* libgnomesu 1.0.0
+  - CVE-2011-1946
+* libsndfile 1.0.23
+  - CVE-2011-2696
+* libsoup 2.32.2
+  - CVE-2011-2524
+* libuser 0.56.18
+  - CVE-2011-0002
+* libvirt 0.9.0
+  - CVE-2011-2178
+  - CVE-2011-2511
+* libxml 1.8.17
+  - CVE-2011-1944
+* linux
+  - CVE-2011-2162
+* logrotate 3.7.9
+  - CVE-2011-1098
+  - CVE-2011-1154
+  - CVE-2011-1155
+* mailman 2.1.13
+  - CVE-2011-0707
+* mapserver 5.6.6
+  - CVE-2011-2703
+  - CVE-2011-2704
+  - CVE-2011-2975
+* nagios 3.2.3
+  - CVE-2011-1523
+* ncpfs 2.2.6
+  - CVE-2011-1679
+  - CVE-2011-1680
+* openafs 1.4.14
+  - CVE-2011-0430
+  - CVE-2011-0431
+* openbsd
+  - CVE-2011-2895
+* openldap 2.4.25
+  - CVE-2011-4079
+* openssl 1.0.0d
+  - CVE-2011-1945
+  - CVE-2011-3207
+  - CVE-2011-3210
+* openswan 2.6.28
+  - CVE-2011-4073
+* openttd 1.1.0
+  - CVE-2011-3341
+  - CVE-2011-3342
+  - CVE-2011-3343
+* oprofile 0.9.6
+  - CVE-2011-1760
+  - CVE-2011-2471
+  - CVE-2011-2472
+  - CVE-2011-2473
+* perl 5.12.3
+  - CVE-2011-1487
+* php 5.3.6
+  - CVE-2011-1148
+  - CVE-2011-1657
+  - CVE-2011-1938
+  - CVE-2011-2202
+  - CVE-2011-2483
+  - CVE-2011-3182
+  - CVE-2011-3267
+  - CVE-2011-3268
+  - CVE-2011-4885
+* pidgin 2.7.11
+  - CVE-2011-2943
+  - CVE-2011-3184
+  - CVE-2011-3185
+  - CVE-2011-4601
+  - CVE-2011-4602
+  - CVE-2011-4603
+* plib 1.8.5
+  - CVE-2011-4620
+* prosody 0.7.0
+  - CVE-2011-2205
+* puppet 2.6.8
+  - CVE-2011-3848
+  - CVE-2011-3869
+  - CVE-2011-3870
+  - CVE-2011-3871
+* puppet_enterprise_users
+  - CVE-2011-3872
+* python 2.7.1
+  - CVE-2011-1521
+* quagga 0.99.18
+  - CVE-2011-3323
+  - CVE-2011-3324
+  - CVE-2011-3325
+  - CVE-2011-3326
+  - CVE-2011-3327
+* quassel 0.7.2
+  - CVE-2011-3354
+* rekonq 0.7.0
+  - CVE-2011-3366
+* rsyslog 5.6.2
+  - CVE-2011-3200
+* ruby 1.8.7.p334
+  - CVE-2011-4815
+* samba 3.5.8
+  - CVE-2011-1678
+  - CVE-2011-2522
+  - CVE-2011-2694
+  - CVE-2011-2724
+* squid 3.1.15
+  - CVE-2011-4096
+* systemtap 1.3
+  - CVE-2011-1769
+* t1lib 5.1.2
+  - CVE-2011-0764
+  - CVE-2011-1552
+  - CVE-2011-1553
+  - CVE-2011-1554
+* tmux 1.4
+  - CVE-2011-1496
+* vino 2.32.1
+  - CVE-2011-0904
+  - CVE-2011-0905
+* weechat 0.3.0
+  - CVE-2011-1428
+* wireshark 1.4.6
+  - CVE-2011-1957
+  - CVE-2011-1958
+  - CVE-2011-1959
+  - CVE-2011-2174
+  - CVE-2011-2175
+  - CVE-2011-2597
+  - CVE-2011-2698
+  - CVE-2011-3360
+  - CVE-2011-4101
+  - CVE-2011-4102
+* wordpress 3.1.1
+  - CVE-2011-3122
+  - CVE-2011-3125
+  - CVE-2011-3126
+  - CVE-2011-3127
+  - CVE-2011-3128
+  - CVE-2011-3129
+  - CVE-2011-3130
+* xen 4.1.0
+  - CVE-2011-1583
+  - CVE-2011-1898
+  - CVE-2011-3262
+
+Maybe vulnerable
+
+* phpmyadmin 3.3.10:
+  - CVE-2011-3181: 3.3.10.3 3.3.10.0 3.3.10.1 3.3.10.2
+  - CVE-2011-2506: 3.3.10.0 3.3.10.1
+  - CVE-2011-2507: 3.3.10.0 3.3.10.1
+  - CVE-2011-2508: 3.3.10.0 3.3.10.1
+  - CVE-2011-4107: 3.3.10.3 3.3.10.4 3.3.10.0 3.3.10.1 3.3.10.2
+  - CVE-2011-2642: 3.3.10.1 3.3.10.2 3.3.10.0
+  - CVE-2011-2719: 3.3.10.1 3.3.10.2 3.3.10.0
+  - CVE-2011-2505: 3.3.10.0 3.3.10.1
+* glibc 2.12.1:
+  - CVE-2011-0536: 2.12.1.7.el6_0.3
+* policykit 0.9:
+  - CVE-2011-1485: 0.96
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010996.html b/zarb-ml/mageia-dev/2012-January/010996.html new file mode 100644 index 000000000..44b490995 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010996.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] List of CVE referencing software versions present in Mageia 1 + + + + + + + + + +

[Mageia-dev] List of CVE referencing software versions present in Mageia 1

+ Maarten Vanraes + alien at rmail.be +
+ Thu Jan 5 23:52:00 CET 2012 +

+
+ +
Op donderdag 05 januari 2012 23:37:54 schreef Pascal Terjan:
+> Here is the output of a little script I just wrote.
+
+would it be also possible to check our bugzilla for the CVE? to see if it's 
+already there, or maybe resolved?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010997.html b/zarb-ml/mageia-dev/2012-January/010997.html new file mode 100644 index 000000000..bc8401612 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010997.html @@ -0,0 +1,111 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release ldetect-0.11.4-1.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release ldetect-0.11.4-1.mga2

+ Maarten Vanraes + alien at rmail.be +
+ Thu Jan 5 23:53:10 CET 2012 +

+
+ +
Op donderdag 05 januari 2012 23:40:14 schreef tv:
+> Name        : ldetect                      Relocations: (not relocatable)
+> Version     : 0.11.4                            Vendor: Mageia.Org
+> Release     : 1.mga2                        Build Date: Thu Jan  5 23:38:18
+> 2012 Install Date: (not installed)               Build Host: ecosse
+> Group       : System/Kernel and hardware    Source RPM: (none)
+> Size        : 32127                            License: GPL
+> Signature   : (none)
+> Packager    : tv <tv>
+> URL         : http://www.mandrivalinux.com
+> Summary     : Light hardware detection tool
+> Description :
+> The hardware device lists provided by this package are used as a lookup
+> table to get hardware auto-detection.
+> 
+> tv <tv> 0.11.4-1.mga2:
+> + Revision: 191911
+> - fix building with dietlibc
+> - $<(log)
+
+what does this last line mean?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010998.html b/zarb-ml/mageia-dev/2012-January/010998.html new file mode 100644 index 000000000..0a19bf97c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010998.html @@ -0,0 +1,118 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release ldetect-0.11.4-1.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release ldetect-0.11.4-1.mga2

+ Anssi Hannula + anssi at mageia.org +
+ Thu Jan 5 23:54:15 CET 2012 +

+
+ +
On 06.01.2012 00:53, Maarten Vanraes wrote:
+> Op donderdag 05 januari 2012 23:40:14 schreef tv:
+>> Name        : ldetect                      Relocations: (not relocatable)
+>> Version     : 0.11.4                            Vendor: Mageia.Org
+>> Release     : 1.mga2                        Build Date: Thu Jan  5 23:38:18
+>> 2012 Install Date: (not installed)               Build Host: ecosse
+>> Group       : System/Kernel and hardware    Source RPM: (none)
+>> Size        : 32127                            License: GPL
+>> Signature   : (none)
+>> Packager    : tv <tv>
+>> URL         : http://www.mandrivalinux.com
+>> Summary     : Light hardware detection tool
+>> Description :
+>> The hardware device lists provided by this package are used as a lookup
+>> table to get hardware auto-detection.
+>>
+>> tv <tv> 0.11.4-1.mga2:
+>> + Revision: 191911
+>> - fix building with dietlibc
+>> - $<(log)
+> 
+> what does this last line mean?
+> 
+
+Too late, he already fixed it 10min ago.
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/010999.html b/zarb-ml/mageia-dev/2012-January/010999.html new file mode 100644 index 000000000..1bd509b2d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/010999.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2

+ Angelo Naselli + anaselli at linux.it +
+ Thu Jan 5 23:58:26 CET 2012 +

+
+ +
> 1 week ago, anyone who would have upgraded to mga2 with dsniff installed
+> from mdv would have been in the exact same situation than now, except
+> nobody cared at all. And the proof that nobody cared is that nobody
+> pushed the rpm sooner. Would it have been pushed to 1, yes, that would
+> have breached what we agreed to do. But it was not pushed to 1 ( and I
+> would say "likely on purpose" ). So the only change with this upload is
+> for people installing dsniff later.
+mga1 is not dead yet, so if someone who install mga1 now, could ask for dsniff
+and that should go to update since it is in mdv2010, right? That could be a 
+problem imho... there always could be one person who upgrade from mdv2010 
+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/20120105/582967df/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011000.html b/zarb-ml/mageia-dev/2012-January/011000.html new file mode 100644 index 000000000..c3dc3248a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011000.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release screengrab-0.9.85-2.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release screengrab-0.9.85-2.mga2

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Fri Jan 6 00:23:29 CET 2012 +

+
+ +
On 6 January 2012 00:03, matteo <buildsystem-daemon at mageia.org> wrote:
+> matteo <matteo> 0.9.85-2.mga2:
+> + Revision: 191937
+> + rebuild (emptylog)
+
+What for?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011001.html b/zarb-ml/mageia-dev/2012-January/011001.html new file mode 100644 index 000000000..8fca7cc74 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011001.html @@ -0,0 +1,127 @@ + + + + [Mageia-dev] [changelog] cauldron core/release yaflight-0.1.5-2.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] cauldron core/release yaflight-0.1.5-2.mga2

+ Thomas Backlund + tmb at mageia.org +
+ Fri Jan 6 00:25:49 CET 2012 +

+
+ +
06.01.2012 01:12, matteo skrev:
+> Name        : yaflight                     Relocations: (not relocatable)
+> Version     : 0.1.5                             Vendor: Mageia.Org
+> Release     : 2.mga2                        Build Date: Fri Jan  6 00:07:17 2012
+> Install Date: (not installed)               Build Host: jonund
+> Group       : Games/Other                   Source RPM: (none)
+> Size        : 28001                            License: GPLv2+
+
+[...]
+
+>
+> matteo<matteo>  0.1.5-2.mga2:
+> + Revision: 191947
+> - added license as doc; spec file reviewed
+
+Hi, you dont need to duplicate the license file on all packages you 
+touch. We already ship them in the common-licenses package:
+
+$ rpm -ql common-licenses
+/usr/share/common-licenses
+/usr/share/common-licenses/Apache
+/usr/share/common-licenses/Artistic
+/usr/share/common-licenses/GFDL
+/usr/share/common-licenses/GPL
+/usr/share/common-licenses/GPLv2
+/usr/share/common-licenses/GPLv3
+/usr/share/common-licenses/LGPL
+/usr/share/common-licenses/LGPLv2.1
+/usr/share/common-licenses/LGPLv3
+/usr/share/common-licenses/MPL
+/usr/share/common-licenses/ZPL
+
+--
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011002.html b/zarb-ml/mageia-dev/2012-January/011002.html new file mode 100644 index 000000000..a585ecddd --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011002.html @@ -0,0 +1,119 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release screengrab-0.9.85-2.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release screengrab-0.9.85-2.mga2

+ Matteo + pasotti.matteo at gmail.com +
+ Fri Jan 6 00:43:22 CET 2012 +

+
+ +
-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
+Il 06/01/2012 00:23, Thierry Vignaud ha scritto:
+> On 6 January 2012 00:03, matteo <buildsystem-daemon at mageia.org> wrote:
+>> matteo <matteo> 0.9.85-2.mga2:
+>> + Revision: 191937
+>> + rebuild (emptylog)
+> 
+> What for?
+I was using SILENT into the svn message, sorry.
+I rebuilt packages after replacing some macro with commands name (e.g.
+%__install, %__rm, %__sed) and after that I've removed %clean section
+(as the guidelines says).
+The same for other packages I submitted tonight.
+Regards,
+- -- 
+Matteo
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.11 (GNU/Linux)
+Comment: Using GnuPG with Mageia - http://enigmail.mozdev.org/
+
+iQEcBAEBAgAGBQJPBjWUAAoJED3LowjDDWbNVAUH/3mhROCYZHRYT4yBc26IZiL7
+kWsesw6ZfeVpEbQWR5LxjvZejcvev565hhA9YhENJrMKV9so7AdnALkpA2CIH9Cf
+V0PIXP2r8NzCdFIqBNSIoyRzxWWAKcBdS8G4YUzJ50iT4j/g9XyThxjL+22bpzbN
+8O/ALgreCDSPxde7zGkT7ZMdW1z88UWXz2tdkXhA3Xp4/iiVRDfdCV8OvOA8PVQ2
+QjbdFrjtEV6lF8UkMaU9A4N94zTscII3EyzN89c6RDreIo+o3nEdImk0Uy0Z9Rw0
+7EF0ZVKIycDE90xqgV9HrBJVeS+quN2uFJ06Iac3jsSpw9zBeIVVyaQeI8pvlmg=
+=IYn0
+-----END PGP SIGNATURE-----
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011003.html b/zarb-ml/mageia-dev/2012-January/011003.html new file mode 100644 index 000000000..5eb84171a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011003.html @@ -0,0 +1,115 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release screengrab-0.9.85-2.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release screengrab-0.9.85-2.mga2

+ John Balcaen + mikala at mageia.org +
+ Fri Jan 6 00:55:02 CET 2012 +

+
+ +
2012/1/5 Matteo <pasotti.matteo at gmail.com>:
+> -----BEGIN PGP SIGNED MESSAGE-----
+> Hash: SHA1
+>
+> Il 06/01/2012 00:23, Thierry Vignaud ha scritto:
+>> On 6 January 2012 00:03, matteo <buildsystem-daemon at mageia.org> wrote:
+>>> matteo <matteo> 0.9.85-2.mga2:
+>>> + Revision: 191937
+>>> + rebuild (emptylog)
+>>
+>> What for?
+> I was using SILENT into the svn message, sorry.
+> I rebuilt packages after replacing some macro with commands name (e.g.
+> %__install, %__rm, %__sed) and after that I've removed %clean section
+> (as the guidelines says).
+> The same for other packages I submitted tonight.
+For this kind of changes there's no really reason to push them aka
+it's just cosmetic changes without effect on the package itself.
+So if it's not a requires/suggests/BR/files list fix i would say that
+you can wait before submitting this kind of changes more « useful »
+changes.
+
+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/2012-January/011004.html b/zarb-ml/mageia-dev/2012-January/011004.html new file mode 100644 index 000000000..f44d36d4b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011004.html @@ -0,0 +1,132 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release screengrab-0.9.85-2.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release screengrab-0.9.85-2.mga2

+ Matteo + pasotti.matteo at gmail.com +
+ Fri Jan 6 01:04:05 CET 2012 +

+
+ +
-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
+Il 06/01/2012 00:55, John Balcaen ha scritto:
+> 2012/1/5 Matteo <pasotti.matteo at gmail.com>:
+>> -----BEGIN PGP SIGNED MESSAGE-----
+>> Hash: SHA1
+>>
+>> Il 06/01/2012 00:23, Thierry Vignaud ha scritto:
+>>> On 6 January 2012 00:03, matteo <buildsystem-daemon at mageia.org> wrote:
+>>>> matteo <matteo> 0.9.85-2.mga2:
+>>>> + Revision: 191937
+>>>> + rebuild (emptylog)
+>>>
+>>> What for?
+>> I was using SILENT into the svn message, sorry.
+>> I rebuilt packages after replacing some macro with commands name (e.g.
+>> %__install, %__rm, %__sed) and after that I've removed %clean section
+>> (as the guidelines says).
+>> The same for other packages I submitted tonight.
+> For this kind of changes there's no really reason to push them aka
+> it's just cosmetic changes without effect on the package itself.
+> So if it's not a requires/suggests/BR/files list fix i would say that
+> you can wait before submitting this kind of changes more « useful »
+> changes.
+> 
+> Regards,
+Got it, thank you all for your patience :-)
+Regards,
+- -- 
+Matteo
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.11 (GNU/Linux)
+Comment: Using GnuPG with Mageia - http://enigmail.mozdev.org/
+
+iQEcBAEBAgAGBQJPBjptAAoJED3LowjDDWbNDkYIAINxJTOy3x98H1K7wVYvUZEE
+opG+YpW6Q7i0spZBS51yn9K+EPHWrNM5DIS99Fwfm+LRXiyuzmlCzj2es+XFWNTd
+YGntXUNtGeYxy7kd5wJfsuTjTm1eCFXOS9RJgRVIYw34RKLanN1MvffI6Nt0SGJi
+Y3sKfvKDNrk04TbrtlM49GW/SCVIMkCHGPl4T9zZj7urimY7zPsY9M0E6asK1+mo
+aAPft6jeTci6kLzrMdyGA8QttvV0dm+yBMbqiQUWWGsAZ2BOe/9vMvY4tb8EI1pk
+94NK0joTG491qvzXkxeip7WlyAOIz0tqOLS5YpHilCNejkfulMsf6DCR8cc/dfg=
+=b8Ji
+-----END PGP SIGNATURE-----
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011005.html b/zarb-ml/mageia-dev/2012-January/011005.html new file mode 100644 index 000000000..37102be36 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011005.html @@ -0,0 +1,138 @@ + + + + [Mageia-dev] [packages-commits] [189967] - version upgrade + + + + + + + + + +

[Mageia-dev] [packages-commits] [189967] - version upgrade

+ Thomas Spuhler + thomas at btspuhler.com +
+ Fri Jan 6 01:33:43 CET 2012 +

+
+ +
On Thursday, January 05, 2012 12:36:12 PM Matteo wrote:
+> Il 03/01/2012 17:30, Guillaume Rousse ha scritto:
+> > Le 03/01/2012 17:18, Jani Välimaa a écrit :
+> >>> @@ -11,7 +11,7 @@
+> >>> 
+> >>>   Group:        System/Kernel and hardware
+> >>>   BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot
+> >>>   URL:        http://www.codemonkey.org.uk/projects/x86info/
+> >>> 
+> >>> -Source0:    %{name}-%{realver}%{?cvsdate:-%{cvsdate}}.tar.bz2
+> >>> +Source0:    %{name}-%{realver}%{?cvsdate:-%{cvsdate}}.tgz
+> >>> 
+> >>>   Patch0:        x86info-1.17-intel-flags.patch
+> >>>   Patch1:        x86info-1.17-intel-caches.patch
+> >>>   Patch2:        x86info-1.17-cpuid-with-ecx-input.patch
+> >>> 
+> >>> @@ -33,17 +33,18 @@
+> >>> 
+> >>>   %setup -q -n %{name}-%{realver}
+> >>>   
+> >>>   %build
+> >>> 
+> >>> -make CFLAGS="%{optflags}"
+> >>> +#make CFLAGS="%{optflags}"
+> >>> +%make
+> >>> 
+> >>>   %install
+> >>> 
+> >>> -rm -rf %{buildroot}
+> >>> -install -d %{buildroot}%{_bindir}
+> >>> -install -d %{buildroot}%{_mandir}/man1
+> >>> -install -m755 %{name} %{buildroot}%{_bindir}/
+> >>> -install -m755 %{name}.1 %{buildroot}%{_mandir}/man1/
+> >>> +%__rm -rf %{buildroot}
+> >>> +%__install -d %{buildroot}%{_bindir}
+> >>> +%__install -d %{buildroot}%{_mandir}/man1
+> >>> +%__install -m755 %{name} %{buildroot}%{_bindir}/
+> >>> +%__install -m755 %{name}.1 %{buildroot}%{_mandir}/man1/
+> >> 
+> >> I think this is pretty much opposite what everyone else is doing. IMHO
+> >> this also makes .spec harder to read.
+> > 
+> > Morevoer, it mixes pure cosmetics changes, as some of those macros just
+> > expand to the command itself, as install vs %__install,
+> 
+> Hi Guillaume,
+> I'm sorry, but I don't think that /usr/bin/install it's equal to
+> 'install'. There are technical reasons to avoid these macros? Can you
+> suggest me some reference, please? I'm not able to find nothing about
+> this topic.
+> 
+>  with behaviour
+> 
+> > changes, as other macros expand to the command with additional
+> > arguments, as make vs %make, which is actually make -j.
+> 
+> So if I need to invoke make -j what should I do?
+> Again, excuse me -I'm not so skilled- but why should I avoid to call
+> make using -j option?
+> 
+> Be patient, please :-)
+Why are you signing your e-mail with a key that is not public?
+-- 
+Best regards
+Thomas Spuhler
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011006.html b/zarb-ml/mageia-dev/2012-January/011006.html new file mode 100644 index 000000000..2e677d965 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011006.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] [packages-commits] [189967] - version upgrade + + + + + + + + + +

[Mageia-dev] [packages-commits] [189967] - version upgrade

+ Matteo + pasotti.matteo at gmail.com +
+ Fri Jan 6 01:43:35 CET 2012 +

+
+ +
-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
+Il 06/01/2012 01:33, Thomas Spuhler ha scritto:
+> Why are you signing your e-mail with a key that is not public?
+Hi Thomas,
+I sent my public key to pool.sks-keyservers.net time ago.
+Regards,
+- -- 
+Matteo
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.11 (GNU/Linux)
+Comment: Using GnuPG with Mageia - http://enigmail.mozdev.org/
+
+iQEcBAEBAgAGBQJPBkOmAAoJED3LowjDDWbNTKAH/i7/7am0BdUgJzTYQRTweaAq
+O3BDAdTzO9X0F1OeQecZFa4pgKsMY7NPRTq2acGCBmxnWsReESOxaKp1z01jODpc
+OPyXGaPolXWyXwpvJrOKfEtT8CEUeqSzCsGQ3Hl/90xV8Uqf+2aOPlb6yD81tqdA
+ceKS9a+NBTz6ftexSguo3r6wOxOr3humhE2f/UNf/HMj3RPOdai5P/R6MdZfdX2O
++yCo7s8Uf3FfuSSMTIb1sYLDihwU0DXk/vGlB4dw7Q5oONDpC771d4lQer+tQNXw
+bZ0mF/oz6qHd1R4EKh2Gj0TULQ9TsbMLp+oC7ncZhx3HQLrTXlruQgJ0GTSUgfA=
+=U4F1
+-----END PGP SIGNATURE-----
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011007.html b/zarb-ml/mageia-dev/2012-January/011007.html new file mode 100644 index 000000000..2f7cffc47 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011007.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release screengrab-0.9.85-2.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release screengrab-0.9.85-2.mga2

+ Anssi Hannula + anssi at mageia.org +
+ Fri Jan 6 02:06:57 CET 2012 +

+
+ +
On 06.01.2012 01:23, Thierry Vignaud wrote:
+> On 6 January 2012 00:03, matteo <buildsystem-daemon at mageia.org> wrote:
+>> matteo <matteo> 0.9.85-2.mga2:
+>> + Revision: 191937
+>> + rebuild (emptylog)
+
+Can we have youri block uploads that are "rebuild (emptylog)"?
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011008.html b/zarb-ml/mageia-dev/2012-January/011008.html new file mode 100644 index 000000000..1187b7f44 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011008.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] List of CVE referencing software versions present in Mageia 1 + + + + + + + + + +

[Mageia-dev] List of CVE referencing software versions present in Mageia 1

+ John Balcaen + mikala at mageia.org +
+ Fri Jan 6 02:18:51 CET 2012 +

+
+ +
2012/1/5 Pascal Terjan <pterjan at gmail.com>:
+> Here is the output of a little script I just wrote.
+>
+> Vulnerable version, please check that a patch was applied if needed
+> * quassel 0.7.2
+>  - CVE-2011-3354
+It's fixed.
+> * rekonq 0.7.0
+>  - CVE-2011-3366
+Hum this one is more problematic in fact, & need a total rediff since
+the patch made by upstream @ this moment is *quite* different in file
+name/location & in fact i would prefer to update to the last stable
+version.
+
+
+
+
+-- 
+Balcaen John
+Jabber-id: mikala at jabber.littleboboy.net
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011009.html b/zarb-ml/mageia-dev/2012-January/011009.html new file mode 100644 index 000000000..c58858b04 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011009.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] references to outside web sites/wiki + + + + + + + + + +

[Mageia-dev] references to outside web sites/wiki

+ Glen Ogilvie + nelg at linuxsolutions.co.nz +
+ Fri Jan 6 08:31:27 CET 2012 +

+
+ +
> On Wednesday, 4 January 2012 23:56:01 Romain d'Alverny wrote:
+> > On Wed, Jan 4, 2012 at 22:36, Johnny A. Solbu <cooker at solbu.net> wrote:
+> > > On Wednesday 04 January 2012 21:06, Romain d'Alverny wrote:
+> > >> wiki.mandriva.com may be shut down for good in just a few days
+> > >
+> > > What? Are Mandriva serisouly considering closing down the Wiki?
+> >
+> > Mandriva is on the path to filing for bankruptcy on January 16th.
+
+Does anyone have a complete mirror / copy of the Mandriva svn repository, or
+a complete set of SRPMs from cooker?   I would be concerned this becomes 
+unavailable, as it's a valuable resource for packages not yet imported into 
+Mageia and contains a history of the package that Mageia does not have.
+
+Regards
+Glen Ogilvie
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011010.html b/zarb-ml/mageia-dev/2012-January/011010.html new file mode 100644 index 000000000..0a8335ffc --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011010.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] List of CVE referencing software versions present in Mageia 1 + + + + + + + + + +

[Mageia-dev] List of CVE referencing software versions present in Mageia 1

+ Jerome Quelin + jquelin at gmail.com +
+ Fri Jan 6 10:42:57 CET 2012 +

+
+ +
On 12/01/05 22:37 +0000, Pascal Terjan wrote:
+> * perl 5.12.3
+>   - CVE-2011-1487
+
+fixed since 2011-05-16
+
+jérôme 
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011011.html b/zarb-ml/mageia-dev/2012-January/011011.html new file mode 100644 index 000000000..806be6e8a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011011.html @@ -0,0 +1,458 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Robert Fox + list at foxconsult.net +
+ Fri Jan 6 11:16:52 CET 2012 +

+
+ +
After latest Cauldron updates, I got a real long list of suggested
+"orphans" - but I believe some of these packages are needed (like hal or
+basesystem-minimal) -
+
+How do I clear out the orphans - like reset the logic behind it so the
+correct packages will be orphaned?  Or is a fresh install in order??
+
+
+The following packages:
+  aisleriot-3.3.1-1.mga2.x86_64
+  alacarte-0.13.2-3.mga1.noarch
+  alsa-plugins-doc-1.0.24-5.mga2.noarch
+  apg-2.2.3-7.mga2.x86_64
+  basesystem-minimal-2-3.mga2.x86_64
+  bug-buddy-2.32.0-4.mga2.x86_64
+  caribou-0.4.1-2.mga2.x86_64
+  caribou-gtk3-0.4.1-2.mga2.x86_64
+  cdrkit-isotools-1.1.11-1.mga1.x86_64
+  cronie-1.4.8-1.mga2.x86_64
+  cronie-anacron-1.4.8-1.mga2.x86_64
+  crontabs-1.10-15.mga1.noarch
+  cryptsetup-1.4.1-1.mga2.x86_64
+  cups-pk-helper-0.2.1-1.mga2.x86_64
+  dnsmasq-base-2.59-1.mga2.x86_64
+  etcskel-1.63-28.mga1.noarch
+  evolution-webcal-2.32.0-4.mga2.x86_64
+  gio-sharp-2.22.3-1.mga2.noarch
+  gir-repository-0.6.6-0.20100907.3.mga1.x86_64
+  gjs-1.31.6-1.mga2.x86_64
+  glchess-3.3.3-1.mga2.x86_64
+  glines-3.3.3-1.mga2.x86_64
+  gmime-sharp-2.6.3-1.mga2.x86_64
+  gnect-3.3.3-1.mga2.x86_64
+  gnibbles-3.3.3-1.mga2.x86_64
+  gnobots2-3.3.3-1.mga2.x86_64
+  gnome-applets-3.3.1-1.mga2.x86_64
+  gnome-backgrounds-3.3.3-1.mga2.noarch
+  gnome-contacts-3.3.1-1.mga2.x86_64
+  gnome-control-center-3.3.3-1.mga2.x86_64
+  gnome-desktop-2.32.1-2.mga2.x86_64
+  gnome-desktop-common-2.32.1-2.mga2.x86_64
+  gnome-documents-0.3.3-2.mga2.x86_64
+  gnome-games-3.3.3-1.mga2.x86_64
+  gnome-games-common-3.3.3-1.mga2.x86_64
+  gnome-mahjongg-3.3.3-1.mga2.x86_64
+  gnome-menus-3.3.1-1.mga2.x86_64
+  gnome-panel-3.3.3-1.mga2.x86_64
+  gnome-python-applet-2.32.0-6.mga1.x86_64
+  gnome-screensaver-3.2.0-1.mga2.x86_64
+  gnome-search-tool-3.3.1-1.mga2.x86_64
+  gnome-session-3.3.3-1.mga2.x86_64
+  gnome-shell-3.3.3-1.mga2.x86_64
+  gnome-sudoku-3.3.3-1.mga2.x86_64
+  gnome-system-monitor-3.3.3-1.mga2.x86_64
+  gnome-tweak-tool-3.3.0-0.20111127.1.mga2.noarch
+  gnome-user-docs-3.2.2-1.mga2.noarch
+  gnomine-3.3.3-1.mga2.x86_64
+  gnotravex-3.3.3-1.mga2.x86_64
+  gnotski-3.3.3-1.mga2.x86_64
+  gnutls-3.0.9-1.mga2.x86_64
+  google-gadgets-common-0.11.2-8.mga2.x86_64
+  google-gadgets-qt-0.11.2-8.mga2.x86_64
+  graphite2-1.0.3-2.mga2.x86_64
+  grub-0.97-32.mga1.x86_64
+  gtali-3.3.3-1.mga2.x86_64
+  gtkhtml-3.14-3.32.2-2.mga2.x86_64
+  hal-0.5.14-6.mga1.x86_64
+  hal-info-0.0-5.20091130.3.mga1.noarch
+  hupnp-devel-1.0.0-1.mga2.x86_64
+  ia_ora-gnome-1.0.25-1.mga1.x86_64
+  iagno-3.3.3-1.mga2.x86_64
+  jovie-handbook-4.7.97-1.mga2.noarch
+  kaccessible-4.7.97-1.mga2.x86_64
+  kate-handbook-4.7.97-0.mga2.noarch
+  kde4-style-iaora-0.3.2-1.mga2.x86_64
+  kde4-style-iaora-common-0.3.2-1.mga2.x86_64
+  kdebase4-workspace-googlegadgets-4.7.97-1.mga2.x86_64
+  kdeedu4-core-4.6.5-1.mga1.x86_64
+  kdegraphics4-4.6.90-2.mga2.noarch
+  kpartx-0.4.8-18.mga1.x86_64
+  ktexteditor-4.7.97-0.mga2.x86_64
+  lib64OpenEXR-devel-1.7.0-1.mga2.x86_64
+  lib64archive2-2.8.5-1.mga2.x86_64
+  lib64art_lgpl-devel-2.3.21-3.mga1.x86_64
+  lib64audit-devel-2.1.3-1.mga2.x86_64
+  lib64avahi-client-devel-0.6.30-6.mga2.x86_64
+  lib64avahi-common-devel-0.6.30-6.mga2.x86_64
+  lib64avahi-compat-libdns_sd-devel-0.6.30-6.mga2.x86_64
+  lib64avahi-compat-libdns_sd1-0.6.30-6.mga2.x86_64
+  lib64avahi-ui1-0.6.30-6.mga2.x86_64
+  lib64avformats52-0.6.3-1.mga1.x86_64
+  lib64boost_program_options1.44.0-1.44.0-6.mga1.x86_64
+  lib64boost_program_options1.47.0-1.47.0-2.mga2.x86_64
+  lib64boost_regex1.47.0-1.47.0-2.mga2.x86_64
+  lib64boost_signals1.47.0-1.47.0-2.mga2.x86_64
+  lib64boost_system1.47.0-1.47.0-2.mga2.x86_64
+  lib64boost_thread1.47.0-1.47.0-2.mga2.x86_64
+  lib64brasero1-2.32.1-2.mga1.x86_64
+  lib64camel19-2.32.2-1.mga1.x86_64
+  lib64camel29-3.2.1-1.mga2.x86_64
+  lib64camel30-3.3.1.1-2.mga2.x86_64
+  lib64caribou-gir1.0-0.4.1-2.mga2.x86_64
+  lib64caribou0-0.4.1-2.mga2.x86_64
+  lib64cdio_cdda0-0.82-3.mga1.x86_64
+  lib64cdt4-2.26.3-7.mga1.x86_64
+  lib64cheese-gtk18-2.32.0-1.mga1.x86_64
+  lib64clucene-core2-2.3.3.4-0.mga2.x86_64
+  lib64clucene-devel-2.3.3.4-0.mga2.x86_64
+  lib64clucene0-0.9.21b-3.mga1.x86_64
+  lib64clucene_shared2-2.3.3.4-0.mga2.x86_64
+  lib64clutter-gst-gir1.0-1.4.4-2.mga2.x86_64
+  lib64clutter-gtk-gir1.0-1.1.2-2.mga2.x86_64
+  lib64cogl2-1.7.8-1.mga2.x86_64
+  lib64config9-1.4.8-1.mga2.x86_64
+  lib64cryptsetup1-1.3.1-1.mga2.x86_64
+  lib64cups2-devel-1.5.0-2.mga2.x86_64
+  lib64db5.1-5.1.25-5.mga2.x86_64
+  lib64digikamcore1-1.9.0-1.mga1.x86_64
+  lib64digikamdatabase1-1.9.0-1.mga1.x86_64
+  lib64directfb1.4_5-1.4.11-2.mga1.x86_64
+  lib64dmapsharing2-2.1.9-3.mga1.x86_64
+  lib64ebackend0-2.32.2-1.mga1.x86_64
+  lib64ebackend1-3.2.1-1.mga2.x86_64
+  lib64ebook10-2.32.2-1.mga1.x86_64
+  lib64ebook12-3.3.1.1-2.mga2.x86_64
+  lib64ecal10-3.2.1-1.mga2.x86_64
+  lib64ecal8-2.32.2-1.mga1.x86_64
+  lib64edata-book11-3.2.1-1.mga2.x86_64
+  lib64edata-book12-3.3.1.1-2.mga2.x86_64
+  lib64edata-book8-2.32.2-1.mga1.x86_64
+  lib64edata-cal10-2.32.2-1.mga1.x86_64
+  lib64edata-cal13-3.2.1-1.mga2.x86_64
+  lib64edata-cal14-3.3.2-1.mga2.x86_64
+  lib64edataserver14-2.32.2-1.mga1.x86_64
+  lib64edataserver15-3.2.1-1.mga2.x86_64
+  lib64edataserverui11-2.32.2-1.mga1.x86_64
+  lib64egroupwise13-2.32.2-1.mga1.x86_64
+  lib64enchant-devel-1.6.0-3.mga2.x86_64
+  lib64epc1.0_2-0.3.11-3.mga1.x86_64
+  lib64evince-gir3.0-3.3.3.1-2.mga2.x86_64
+  lib64exiv2_10-0.21.1-1.mga1.x86_64
+  lib64ext2fs-devel-1.42-1.mga2.x86_64
+  lib64folks-gir0.6-0.6.6-1.mga2.x86_64
+  lib64folks22-0.4.2-1.mga1.x86_64
+  lib64galago3-0.5.2-11.mga1.x86_64
+  lib64gcr0-2.32.1-1.mga1.x86_64
+  lib64gcrypt-devel-1.5.0-2.mga2.x86_64
+  lib64gdata-gir0.0-0.11.0-1.mga2.x86_64
+  lib64gdbm-devel-1.10-1.mga2.x86_64
+  lib64gdbm3-1.8.3-16.mga1.x86_64
+  lib64gdict1.0_6-3.3.2-1.mga2.x86_64
+  lib64gdprivate-gir1.0-0.3.3-2.mga2.x86_64
+  lib64gee-gir1.0-0.6.3-1.mga2.x86_64
+  lib64ggadget-dbus1.0_0-0.11.2-8.mga2.x86_64
+  lib64ggadget-js1.0_0-0.11.2-8.mga2.x86_64
+  lib64ggadget-qt1.0_0-0.11.2-8.mga2.x86_64
+  lib64ggadget-webkitjs0-0.11.2-8.mga2.x86_64
+  lib64ggadget-xdg1.0_0-0.11.2-8.mga2.x86_64
+  lib64ggadget1.0_0-0.11.2-8.mga2.x86_64
+  lib64gjs-gir1.0-1.31.6-1.mga2.x86_64
+  lib64glew1.5-1.5.8-2.mga1.x86_64
+  lib64gmenu-gir3.0-3.3.1-1.mga2.x86_64
+  lib64gmime2.4_2-2.4.23-2.mga1.x86_64
+  lib64gmp-devel-5.0.2-2.mga2.x86_64
+  lib64gnome-bluetooth-applet-gir1.0-3.3.3-1.mga2.x86_64
+  lib64gnome-bluetooth-gir1.0-3.3.3-1.mga2.x86_64
+  lib64gnome-bluetooth8-3.2.1-1.mga2.x86_64
+  lib64gnome-desktop-2_17-2.32.1-2.mga2.x86_64
+  lib64gnome-media0-2.32.0-3.mga1.x86_64
+  lib64gnome-menu2-2.30.5-2.mga1.x86_64
+  lib64gnome-menu3_0-3.3.1-1.mga2.x86_64
+  lib64gnome-window-settings1-3.2.2-1.mga2.x86_64
+  lib64gnomebreakpad-2.32.0-4.mga2.x86_64
+  lib64gnomekbd-gir3.0-3.2.0-1.mga2.x86_64
+  lib64gnomekbd4-2.32.0-2.mga1.x86_64
+  lib64gnutls-devel-3.0.9-1.mga2.x86_64
+  lib64gnutls-ssl27-3.0.9-1.mga2.x86_64
+  lib64gnutls26-2.10.5-2.mga1.x86_64
+  lib64goa-gir1.0-3.3.0-1.mga2.x86_64
+  lib64gpg-error-devel-1.10-2.mga2.x86_64
+  lib64gpsd19-2.95-4.mga1.x86_64
+  lib64graph4-2.26.3-7.mga1.x86_64
+  lib64gsf-1_114-1.14.22-1.mga2.x86_64
+  lib64gssdp2-0.10.0-1.mga1.x86_64
+  lib64gtk-vnc1.0_0-0.5.0-1.mga2.x86_64
+  lib64gtkhtml-3.14_19-3.32.2-2.mga2.x86_64
+  lib64gupnp-igd1.0_3-0.1.11-1.mga2.x86_64
+  lib64gupnp3-0.16.0-1.mga1.x86_64
+  lib64gvc5-2.26.3-7.mga1.x86_64
+  lib64gweather1-2.30.3-1.mga1.x86_64
+  lib64gwsoap4-4.7.95-2.mga2.x86_64
+  lib64hal1-0.5.14-6.mga1.x86_64
+  lib64hupnp1-1.0.0-1.mga2.x86_64
+  lib64icu44-4.4.2-2.mga1.x86_64
+  lib64ilmbase-devel-1.0.2-2.mga2.x86_64
+  lib64imobiledevice1-1.0.6-1.mga1.x86_64
+  lib64ip4tc0-1.4.12.1-11.mga2.x86_64
+  lib64ip6tc0-1.4.12.1-11.mga2.x86_64
+  lib64iptables5-1.4.10-3.mga1.x86_64
+  lib64iptables6-1.4.11.1-2.mga2.x86_64
+  lib64iptables7-1.4.12.1-11.mga2.x86_64
+  lib64iso9660_7-0.82-3.mga1.x86_64
+  lib64jasper-devel-1.900.1-12.mga2.x86_64
+  lib64jbig-devel-2.0-5.mga1.x86_64
+  lib64kabc_groupdav4-4.4.11.1-2.mga1.x86_64
+  lib64kabc_slox4-4.4.11.1-2.mga1.x86_64
+  lib64kabckolab4-4.4.11.1-2.mga1.x86_64
+  lib64kactivities5-4.7.3-2.mga2.x86_64
+  lib64kalarm_calendar4-4.7.4-1.mga2.x86_64
+  lib64kalarm_resources4-4.7.4-1.mga2.x86_64
+  lib64kastencontrollers4-4.7.4-1.mga2.x86_64
+  lib64kastencore4-4.7.4-1.mga2.x86_64
+  lib64kastengui4-4.7.4-1.mga2.x86_64
+  lib64kateinterfaces4-4.7.97-0.mga2.x86_64
+  lib64kcal_groupdav4-4.4.11.1-2.mga1.x86_64
+  lib64kcal_groupwise4-4.7.95-2.mga2.x86_64
+  lib64kcal_slox4-4.4.11.1-2.mga1.x86_64
+  lib64kcalkolab4-4.4.11.1-2.mga1.x86_64
+  lib64kdcraw9-4.6.5-0.mga1.x86_64
+  lib64kexiv2_9-4.6.5-0.mga1.x86_64
+  lib64kgroupwarebase4-4.4.11.1-2.mga1.x86_64
+  lib64kgroupwaredav4-4.4.11.1-2.mga1.x86_64
+  lib64knoteskolab4-4.4.11.1-2.mga1.x86_64
+  lib64korg_stdprinting4-4.4.11.1-2.mga1.x86_64
+  lib64korganizer_calendar4-4.4.11.1-2.mga1.x86_64
+  lib64korganizer_eventviewer4-4.4.11.1-2.mga1.x86_64
+  lib64krb53-devel-1.9.2-2.mga2.x86_64
+  lib64kslox4-4.4.11.1-2.mga1.x86_64
+  lib64ktexteditor-codesnippets0-4.7.97-0.mga2.x86_64
+  lib64libqtsolution1-1.0.0-1.mga2.x86_64
+  lib64mad-devel-0.15.1b-10.mga1.x86_64
+  lib64magick4-6.7.2.3-3.mga2.x86_64
+  lib64marblewidget11-4.6.5-1.mga1.x86_64
+  lib64mbox4-4.4.11.1-0.mga1.x86_64
+  lib64mediastreamer0-3.3.2-2.mga1.x86_64
+  lib64mimelib4-4.4.11.1-2.mga1.x86_64
+  lib64mjpegtools1.9_0-1.9.0-10.mga1.x86_64
+  lib64modman1-0.4.6-8.mga1.x86_64
+  lib64modprobe0-3.6-17.mga1.x86_64
+  lib64mtp8-1.0.6-1.mga1.x86_64
+  lib64net-snmp25-5.6.1-7.mga1.x86_64
+  lib64nettle-devel-2.4-1.mga2.x86_64
+  lib64networkmanager-gir1.0-0.9.2.0-1.mga2.x86_64
+  lib64nfnetlink0-1.0.0-5.mga2.x86_64
+  lib64nmclient-gir1.0-0.9.2.0-1.mga2.x86_64
+  lib64ntfs10-2.0.0-9.mga2.x86_64
+  lib64oktetacore4-4.7.4-1.mga2.x86_64
+  lib64oktetagui4-4.7.4-1.mga2.x86_64
+  lib64oktetakastencontrollers4-4.7.4-1.mga2.x86_64
+  lib64oktetakastencore4-4.7.4-1.mga2.x86_64
+  lib64oktetakastengui4-4.7.4-1.mga2.x86_64
+  lib64opal3.6.8-plugins-3.6.8-2.mga1.x86_64
+  lib64openjpeg2-1.3-7.mga1.x86_64
+  lib64p11-kit-devel-0.10-1.mga2.x86_64
+  lib64pam-devel-1.1.3-5.mga2.x86_64
+  lib64panel-applet-2_0-2.32.1-5.mga1.x86_64
+  lib64panel-applet-3_0-2.32.1-5.mga1.x86_64
+  lib64parted0-2.3-1.mga1.x86_64
+  lib64polkit-gir1.0-0.102-4.mga2.x86_64
+  lib64poppler-gir0.16-0.16.7-3.mga2.x86_64
+  lib64poppler-glib6-0.16.7-3.mga2.x86_64
+  lib64poppler13-0.16.7-3.mga2.x86_64
+  lib64ppl7-0.10.2-6.mga1.x86_64
+  lib64ppl_c2-0.10.2-6.mga1.x86_64
+  lib64proxy-gnome-0.4.7-3.mga2.x86_64
+  lib64raptor1-1.4.21-2.mga1.x86_64
+  lib64rasqal2-0.9.21-1.mga1.x86_64
+  lib64rhythmbox3-0.13.3-5.mga1.x86_64
+  lib64rpm1-4.8.1-15.mga2.x86_64
+  lib64samplerate-devel-0.1.8-1.mga2.x86_64
+  lib64sasl2-devel-2.1.23-15.mga2.x86_64
+  lib64sopranoindex1-2.7.1-1.mga2.x86_64
+  lib64sushi-gir1.0-0.3.0-1.mga2.x86_64
+  lib64sushi1.0_0-0.3.0-1.mga2.x86_64
+  lib64swscaler0-0.6.3-1.mga1.x86_64
+  lib64taglib_c0-1.7-1.mga2.x86_64
+  lib64tasn1-devel-2.11-1.mga2.x86_64
+  lib64tcl8.6-8.6-0.b1.7.mga1.x86_64
+  lib64telepathy-glib-gir0.12-0.17.3-1.mga2.x86_64
+  lib64telepathy-kde-accounts-kcm4-0.2.0-1.mga2.x86_64
+  lib64telepathy-logger-gir0.2-0.2.12-1.mga2.x86_64
+  lib64telepathy-qt4_1-0.8.0-1.mga2.x86_64
+  lib64tiff-devel-4.0.0-1.mga2.x86_64
+  lib64tk8.6-8.6-0.b1.8.mga1.x86_64
+  lib64tracker-gir0.12-0.12.9-3.mga2.x86_64
+  lib64tracker0.8_0-0.8.17-4.mga1.x86_64
+  lib64uClibc0.9.30.3-0.9.30.3-2.mga1.x86_64
+  lib64unac1-1.8.0-2.mga1.x86_64
+  lib64upower-gir1.0-0.9.14-11.mga2.x86_64
+  lib64webkitgtk1.0_2-1.2.7-4.mga1.x86_64
+  lib64wnck3_0-3.2.1-1.mga2.x86_64
+  lib64xcb-atom1-0.3.6-3.mga1.x86_64
+  lib64xcb-aux0-0.3.6-3.mga1.x86_64
+  lib64xcb-event1-0.3.6-3.mga1.x86_64
+  lib64xcb-icccm1-0.3.6-3.mga1.x86_64
+  lib64xcb-image0-0.3.6-3.mga1.x86_64
+  lib64xcb-property1-0.3.6-3.mga1.x86_64
+  lib64xcb-render-util0-0.3.6-3.mga1.x86_64
+  lib64xcb-reply1-0.3.6-3.mga1.x86_64
+  lib64xcb-util-devel-0.3.8-3.mga2.x86_64
+  lib64xft-devel-2.2.0-2.mga2.x86_64
+  lib64xpm-devel-3.5.9-3.mga2.x86_64
+  lib64xslt-devel-1.1.26-6.mga2.x86_64
+  lib64ytnef0-1.5-5.mga1.x86_64
+  lib64zip1-0.9.3-3.mga1.x86_64
+  libcdio_cdda0-0.82-3.mga1.i586
+  libgalago-0.5.2-11.mga1.x86_64
+  libpng12_0-1.2.46-4.mga2.i586
+  libproxy-gxsettings-0.4.7-3.mga2.x86_64
+  libtextcat-2.2-11.mga1.x86_64
+  libtiff3-3.9.5-1.mga2.i586
+  libwnck3-3.2.1-1.mga2.x86_64
+  locales-br-2.14.1-2.mga2.x86_64
+  locales-fr-2.14.1-2.mga2.x86_64
+  mobile-broadband-provider-info-20110511-2.git20111207.1.mga2.noarch
+  modemmanager-0.5-1.mga2.x86_64
+  mpg123-1.13.4-4.mga2.x86_64
+  mutter-3.3.3-1.mga2.x86_64
+  nash-6.0.93-25.mga2.x86_64
+  odt2txt-0.4-2.mga1.x86_64
+  packagekit-gtk3-module-0.6.21-2.mga2.x86_64
+  passwd-0.78-2.mga1.x86_64
+  perl-Crypt-OpenSSL-RSA-0.280.0-1.mga2.x86_64
+  perl-Crypt-OpenSSL-Random-0.40.0-6.mga2.x86_64
+  perl-DB_File-1.824.0-2.mga2.x86_64
+  perl-Encode-Detect-1.10.0-4.mga2.x86_64
+  perl-Geography-Countries-2009041301.0.0-1.mga1.noarch
+  perl-Hal-Cdroms-0.03-5.mga1.noarch
+  perl-IP-Country-2.270.0-1.mga1.noarch
+  perl-MIME-Lite-3.28.0-1.mga2.noarch
+  perl-Mail-DKIM-0.390.0-1.mga1.noarch
+  perl-Mail-SPF-2.7.0-3.mga1.noarch
+  perl-Mail-SpamAssassin-3.3.2-0.0.r2260312.1.mga1.x86_64
+  perl-Net-DNS-0.670.0-1.mga2.x86_64
+  perl-Net-Ident-1.230.0-2.mga1.noarch
+  perl-NetAddr-IP-4.58.0-1.mga2.x86_64
+  perl-Sys-Hostname-Long-1.4-8.mga1.noarch
+  perl-Version-Requirements-0.101.21-1.mga2.noarch
+  python-at-spi-1.32.0-4.mga2.x86_64
+  python-beaker-1.5.4-2.mga1.noarch
+  python-gnome-menus-3.3.1-1.mga2.x86_64
+  python-mako-0.5.0-1.mga2.noarch
+  python-markupsafe-0.12-1.mga1.x86_64
+  qt4-designer-plugin-webkit-4.7.4-5.mga2.x86_64
+  qt4-style-iaora-0.3.2-1.mga2.x86_64
+  quadrapassel-3.3.3-1.mga2.x86_64
+  rootfiles-11.0-7.mga1.noarch
+  sash-3.7-12.mga1.x86_64
+  shared-desktop-ontologies-devel-0.8.1-1.mga2.noarch
+  spamassassin-3.3.2-0.0.r2260312.1.mga1.x86_64
+  sushi-0.3.0-1.mga2.x86_64
+  telepathy-kde-accounts-kcm-0.2.0-1.mga2.x86_64
+  telepathy-kde-presence-dataengine-0.2.0-1.mga2.x86_64
+  telepathy-kde-text-ui-0.2.0-1.mga2.x86_64
+  termcap-11.0.1-19.mga1.noarch
+  time-1.7-37.mga1.x86_64
+  timezone-2011m-0.mga2.x86_64
+  tomboy-1.9.4-1.mga2.x86_64
+  tracker-0.12.9-3.mga2.x86_64
+  uClibc-0.9.30.3-2.mga1.x86_64
+  unoconv-0.4-1.mga2.noarch
+  usbutils-005-1.mga2.x86_64
+  utempter-0.5.5-12.mga1.x86_64
+  vim-minimal-7.3.372-1.mga2.x86_64
+  vorbis-tools-1.4.0-3.mga1.x86_64
+  xulrunner-9.0.1-2.mga2.x86_64
+are now orphaned, if you wish to remove them, you can use "urpme
+--auto-orphans"
+unlocking urpmi database
+unlocking rpm database
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011012.html b/zarb-ml/mageia-dev/2012-January/011012.html new file mode 100644 index 000000000..cd290d2b2 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011012.html @@ -0,0 +1,213 @@ + + + + [Mageia-dev] Numerous mariadb issues today. + + + + + + + + + +

[Mageia-dev] Numerous mariadb issues today.

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Fri Jan 6 11:21:44 CET 2012 +

+
+ +
Hi,
+
+There are several problems today with mariadb, some more serious than
+others:
+
+Firstly, (a minor problem) the log file:
+Jan  3 14:04:34 jimmy mysqld_safe[10642]: 120103 14:04:34 mysqld_safe
+Logging to '/var/log/mysqld/mysqld.log'.
+Jan  3 14:04:34 jimmy mysqld_safe[10642]: 120103 14:04:34 mysqld_safe
+Starting mysqld daemon with databases from /var/lib/mysql
+Jan  3 14:05:53 jimmy mysqld-prepare-db-dir[11245]: touch: cannot touch
+`/var/log/mysqld.log': Permission denied
+Jan  3 14:05:53 jimmy mysqld-prepare-db-dir[11245]: chown: cannot access
+`/var/log/mysqld.log': No such file or directory
+Jan  3 14:05:53 jimmy mysqld-prepare-db-dir[11245]: chmod: cannot access
+`/var/log/mysqld.log': No such file or directory
+
+As the script is run as the mysql user, it cannot touch the
+(non-existant) log file as the directory is owned by root. Better to do
+this in a %post script to ensure the file is all present and properly
+owned to avoid this error.
+
+
+
+Secondly, several plugins were moved to mariadb-obsolete. I have most of
+my databases stored in innodb format and this was one of the plugins
+moved over. Even when I did install the -obsolete package to get
+ha_innodb back, I couldn't use it:
+
+120106 10:15:02 Percona XtraDB (http://www.percona.com) 1.1.8-20.1
+started; log sequence number 52870027141
+120106 10:15:02 [ERROR] Function 'InnoDB' already exists
+120106 10:15:02 [ERROR] Couldn't load plugin named 'InnoDB' with soname
+'ha_innodb.so'.
+
+Now I believe this is due to XtraDB duplicating the features of InnoDB
+and thus effectively obsoleting it... does this mean I simply shouldn't
+load InnoDB plugin now? Does it mean all the tweaks I made in my.cnf for
+innodb pool sizes etc. now no longer work? What is the fallout from this
+change?
+
+
+Thirdly, federated was changed to fedaratedx, but federated was still
+shipped in the mariadb-obsolete package... Sadly however the default
+my.cnf still tries to load the ha_federated.so by default and activate
+via a "federated" option in default my.cnf. So not only is a plugin
+activated that is not installed, even when you do install
+mariadb-obsolete, the "federated" option seems to no longer work anyway:
+
+120106 10:14:16 [ERROR] /usr/sbin/mysqld: unknown option '--federated'
+
+So the "federated" option and the plugin load itself in my.cnf needs to
+be updated somehow, both in the default my.cnf but also some attempt
+should be made to update existing my.cnf too (with a backup).
+
+
+Col
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011013.html b/zarb-ml/mageia-dev/2012-January/011013.html new file mode 100644 index 000000000..7cb79e701 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011013.html @@ -0,0 +1,89 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Funda Wang + fundawang at gmail.com +
+ Fri Jan 6 11:42:15 CET 2012 +

+
+ +
I guess a lot of them are suggested by other packages, rather than required.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20120106/afe74573/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011014.html b/zarb-ml/mageia-dev/2012-January/011014.html new file mode 100644 index 000000000..b4936a3e3 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011014.html @@ -0,0 +1,166 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Robert Fox + list at foxconsult.net +
+ Fri Jan 6 11:43:21 CET 2012 +

+
+ +
On Fri, 2012-01-06 at 12:32 +0200, Shlomi Fish wrote:
+> On Fri, 06 Jan 2012 11:16:52 +0100
+> Robert Fox <list at foxconsult.net> wrote:
+> 
+> > After latest Cauldron updates, I got a real long list of suggested
+> > "orphans" - but I believe some of these packages are needed (like hal or
+> > basesystem-minimal) -
+> > 
+> > How do I clear out the orphans - like reset the logic behind it so the
+> > correct packages will be orphaned?  Or is a fresh install in order??
+> > 
+> 
+> What I normally do is invoke urpmi with the list of packages that I want in
+> which case it says that it will mark them as manually installed and they won't
+> be auto-orphaned.
+> 
+
+Thanks Shlomi - I was thinking that - but to know the packages I want
+vs. the packages that are needed for the basic system . . . I don't know
+them all by heart - like hal - is it needed still?  
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011015.html b/zarb-ml/mageia-dev/2012-January/011015.html new file mode 100644 index 000000000..84106f79c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011015.html @@ -0,0 +1,113 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Shlomi Fish + shlomif at shlomifish.org +
+ Fri Jan 6 11:32:16 CET 2012 +

+
+ +
On Fri, 06 Jan 2012 11:16:52 +0100
+Robert Fox <list at foxconsult.net> wrote:
+
+> After latest Cauldron updates, I got a real long list of suggested
+> "orphans" - but I believe some of these packages are needed (like hal or
+> basesystem-minimal) -
+> 
+> How do I clear out the orphans - like reset the logic behind it so the
+> correct packages will be orphaned?  Or is a fresh install in order??
+> 
+
+What I normally do is invoke urpmi with the list of packages that I want in
+which case it says that it will mark them as manually installed and they won't
+be auto-orphaned.
+
+Regards,
+
+	Shlomi Fish
+
+[SNIPPED]
+
+-- 
+-----------------------------------------------------------------
+Shlomi Fish       http://www.shlomifish.org/
+Best Introductory Programming Language - http://shlom.in/intro-lang
+
+I don’t believe in fairies. Oops! A fairy died.
+I don’t believe in fairies. Oops! Another fairy died.
+
+Please reply to list if it's a mailing list post - http://shlom.in/reply .
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011016.html b/zarb-ml/mageia-dev/2012-January/011016.html new file mode 100644 index 000000000..147aaec49 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011016.html @@ -0,0 +1,188 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Shlomi Fish + shlomif at shlomifish.org +
+ Fri Jan 6 11:52:16 CET 2012 +

+
+ +
On Fri, 06 Jan 2012 11:43:21 +0100
+Robert Fox <list at foxconsult.net> wrote:
+
+> On Fri, 2012-01-06 at 12:32 +0200, Shlomi Fish wrote:
+> > On Fri, 06 Jan 2012 11:16:52 +0100
+> > Robert Fox <list at foxconsult.net> wrote:
+> > 
+> > > After latest Cauldron updates, I got a real long list of suggested
+> > > "orphans" - but I believe some of these packages are needed (like hal or
+> > > basesystem-minimal) -
+> > > 
+> > > How do I clear out the orphans - like reset the logic behind it so the
+> > > correct packages will be orphaned?  Or is a fresh install in order??
+> > > 
+> > 
+> > What I normally do is invoke urpmi with the list of packages that I want in
+> > which case it says that it will mark them as manually installed and they won't
+> > be auto-orphaned.
+> > 
+> 
+> Thanks Shlomi - I was thinking that - but to know the packages I want
+> vs. the packages that are needed for the basic system . . . I don't know
+> them all by heart - like hal - is it needed still?  
+> 
+
+You're welcome.
+
+I don't have the "hal" package installed on either of my systems (both x86-64)
+and most everything seems fine (except from various minor bugs in various
+higher-level packages that I'm sure have nothing to do with "hal".).
+
+Regards,
+
+	Shlomi Fish
+
+-- 
+-----------------------------------------------------------------
+Shlomi Fish       http://www.shlomifish.org/
+Chuck Norris/etc. Facts - http://www.shlomifish.org/humour/bits/facts/
+
+Larry Wall can make shit up, and the computer will understand what he means.
+
+Please reply to list if it's a mailing list post - http://shlom.in/reply .
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011017.html b/zarb-ml/mageia-dev/2012-January/011017.html new file mode 100644 index 000000000..52a60cf46 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011017.html @@ -0,0 +1,169 @@ + + + + [Mageia-dev] [RFC] new ldetect, using libkmod + + + + + + + + + +

[Mageia-dev] [RFC] new ldetect, using libkmod

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Fri Jan 6 11:56:13 CET 2012 +

+
+ +
Hi
+
+I've uploaded in core/updates_testing a new ldetect, using libkmod instead
+of libmodprobe. I've also fixed several memleaks.
+There you'll find a drakxtools rebuild for this new libldetect.
+
+This result in:
+- faster lspcidrake
+- using quite less RAM ; eg on my test machine:
+  o harddrake2 uses 106M of resident memory instead of 127
+  o mcc utilise uses 47M of resident memory instead of 48M
+
+Output of lspcidrake should be the same as before modulo for some ISA bridges.
+Please report any significant change.
+
+How to test:
+  lspcidrake > /tmp/pci1
+  urpmi.update 'Core Updates Testing'
+  urpmi --media='Core Updates Testing' ldetect
+  lspcidrake > /tmp/pci2
+  diff -u /tmp/pci[12]
+
+See you
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011018.html b/zarb-ml/mageia-dev/2012-January/011018.html new file mode 100644 index 000000000..c5d136f28 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011018.html @@ -0,0 +1,177 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ wolf python london + lyh19901223 at gmail.com +
+ Fri Jan 6 12:00:48 CET 2012 +

+
+ +
On 6 January 2012 18:43, Robert Fox <list at foxconsult.net> wrote:
+> On Fri, 2012-01-06 at 12:32 +0200, Shlomi Fish wrote:
+>> On Fri, 06 Jan 2012 11:16:52 +0100
+>> Robert Fox <list at foxconsult.net> wrote:
+>>
+>> > After latest Cauldron updates, I got a real long list of suggested
+>> > "orphans" - but I believe some of these packages are needed (like hal or
+>> > basesystem-minimal) -
+>> >
+>> > How do I clear out the orphans - like reset the logic behind it so the
+>> > correct packages will be orphaned?  Or is a fresh install in order??
+>> >
+>>
+>> What I normally do is invoke urpmi with the list of packages that I want in
+>> which case it says that it will mark them as manually installed and they won't
+>> be auto-orphaned.
+>>
+>
+> Thanks Shlomi - I was thinking that - but to know the packages I want
+> vs. the packages that are needed for the basic system . . . I don't know
+> them all by heart - like hal - is it needed still?
+>
+
+hal is deprecated in most linux distros(Debian and Gentoo as far as I
+know), but E17
+needs it. I'm using E17 here. You don't use E17, so it can be removed safely.
+
+
+-- 
+________________________
+Yes, I use Debian GNU/L
+wolf python london(WPL)
+Do as you soul should do !
+________________________
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011019.html b/zarb-ml/mageia-dev/2012-January/011019.html new file mode 100644 index 000000000..9118cc121 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011019.html @@ -0,0 +1,112 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Fri Jan 6 12:27:32 CET 2012 +

+
+ +
2012/1/6 Robert Fox <list at foxconsult.net>:
+> After latest Cauldron updates, I got a real long list of suggested
+> "orphans" - but I believe some of these packages are needed (like hal or
+> basesystem-minimal) -
+>
+> How do I clear out the orphans - like reset the logic behind it so the
+> correct packages will be orphaned?  Or is a fresh install in order??
+>
+>
+> The following packages:
+>  aisleriot-3.3.1-1.mga2.x86_64
+>  alacarte-0.13.2-3.mga1.noarch
+>  alsa-plugins-doc-1.0.24-5.mga2.noarch
+> ....
+
+This is a well known issue.
+To clear out the list you need a deep knowledge of the system to
+determine which packages are really not needed anymore.
+
+Lately  this --auto-orphans line shreddered my whole system on a fresh
+install after the first update, several system services could not
+start at next reboot, applications did not run, etc. One of the very
+few times I had to re-install because of a bug. Call me newbie or
+pussy but until this is not a secure function I will never touch it
+again.
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011020.html b/zarb-ml/mageia-dev/2012-January/011020.html new file mode 100644 index 000000000..4a4108080 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011020.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] references to outside web sites/wiki + + + + + + + + + +

[Mageia-dev] references to outside web sites/wiki

+ Michael Scherer + misc at zarb.org +
+ Fri Jan 6 12:28:15 CET 2012 +

+
+ +
Le vendredi 06 janvier 2012 à 20:31 +1300, Glen Ogilvie a écrit :
+> > On Wednesday, 4 January 2012 23:56:01 Romain d'Alverny wrote:
+> > > On Wed, Jan 4, 2012 at 22:36, Johnny A. Solbu <cooker at solbu.net> wrote:
+> > > > On Wednesday 04 January 2012 21:06, Romain d'Alverny wrote:
+> > > >> wiki.mandriva.com may be shut down for good in just a few days
+> > > >
+> > > > What? Are Mandriva serisouly considering closing down the Wiki?
+> > >
+> > > Mandriva is on the path to filing for bankruptcy on January 16th.
+> 
+> Does anyone have a complete mirror / copy of the Mandriva svn repository, or
+> a complete set of SRPMs from cooker?   I would be concerned this becomes 
+> unavailable, as it's a valuable resource for packages not yet imported into 
+> Mageia and contains a history of the package that Mageia does not have.
+
+D-C should still hold the srpm. 
+
+For the svn you would have to start now syncing, IMHO.
+( even if I doubt mdv will die )
+-- 
+Michael Scherer 
+
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011021.html b/zarb-ml/mageia-dev/2012-January/011021.html new file mode 100644 index 000000000..aae278ba2 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011021.html @@ -0,0 +1,127 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Robert Fox + list at foxconsult.net +
+ Fri Jan 6 12:34:58 CET 2012 +

+
+ +
On Fri, 2012-01-06 at 12:27 +0100, Wolfgang Bornath wrote:
+> 2012/1/6 Robert Fox <list at foxconsult.net>:
+> > After latest Cauldron updates, I got a real long list of suggested
+> > "orphans" - but I believe some of these packages are needed (like hal or
+> > basesystem-minimal) -
+> >
+> > How do I clear out the orphans - like reset the logic behind it so the
+> > correct packages will be orphaned?  Or is a fresh install in order??
+> >
+> >
+> > The following packages:
+> >  aisleriot-3.3.1-1.mga2.x86_64
+> >  alacarte-0.13.2-3.mga1.noarch
+> >  alsa-plugins-doc-1.0.24-5.mga2.noarch
+> > ....
+> 
+> This is a well known issue.
+> To clear out the list you need a deep knowledge of the system to
+> determine which packages are really not needed anymore.
+> 
+> Lately  this --auto-orphans line shreddered my whole system on a fresh
+> install after the first update, several system services could not
+> start at next reboot, applications did not run, etc. One of the very
+> few times I had to re-install because of a bug. Call me newbie or
+> pussy but until this is not a secure function I will never touch it
+> again.
+> 
+
+Wolfgang, I would never call you a pussy ;-)
+
+I agree with your comments, and that is the reason I brought this topic
+to this list - the "auto-orphans" feature is sometimes unreliable (or
+unpredictable) and Mageia should consider either removing it or
+improving it so it works as advertised.  I too had sporadic problems
+with this function and hesitate to use it when it spits out such a list
+(where I am not sure what is "safe to remove or not)
+
+Cheers,
+Robert
+
+
+
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011022.html b/zarb-ml/mageia-dev/2012-January/011022.html new file mode 100644 index 000000000..f82866ce6 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011022.html @@ -0,0 +1,120 @@ + + + + [Mageia-dev] List of CVE referencing software versions present in Mageia 1 + + + + + + + + + +

[Mageia-dev] List of CVE referencing software versions present in Mageia 1

+ Buchan Milne + bgmilne at zarb.org +
+ Fri Jan 6 13:00:30 CET 2012 +

+
+ +
On Friday, 6 January 2012 00:37:54 Pascal Terjan wrote:
+> Here is the output of a little script I just wrote.
+
+Could we turn this script into a database, accessible to security team and 
+maintainer of the package, which allows tracking of updates, and possibly 
+integration with bugzilla, issuing of advisories, and providing OVAL data?
+
+> Vulnerable version, please check that a patch was applied if needed
+
+> * mapserver 5.6.6
+>   - CVE-2011-2703
+>   - CVE-2011-2704
+>   - CVE-2011-2975
+
+$ mgarepo maintdb get mapserver
+obgr_seneca
+
+> * openldap 2.4.25
+>   - CVE-2011-4079
+
+https://bugs.mageia.org/buglist.cgi?quicksearch=CVE-2011-4079
+leads to:
+https://bugs.mageia.org/show_bug.cgi?id=3193
+Package in QA.
+
+> * samba 3.5.8
+>   - CVE-2011-1678
+https://bugs.mageia.org/show_bug.cgi?id=2950 for cifs-utils, package in QA
+https://bugs.mageia.org/show_bug.cgi?id=3980 for samba, package in QA
+>   - CVE-2011-2522
+>   - CVE-2011-2694
+
+https://bugs.mageia.org/show_bug.cgi?id=3980, package in QA
+
+>   - CVE-2011-2724
+https://bugs.mageia.org/show_bug.cgi?id=2950 for cifs-utils, package in QA
+https://bugs.mageia.org/show_bug.cgi?id=3980 for samba, package in QA
+
+Regards,
+Buchan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011023.html b/zarb-ml/mageia-dev/2012-January/011023.html new file mode 100644 index 000000000..f42525e73 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011023.html @@ -0,0 +1,117 @@ + + + + [Mageia-dev] List of CVE referencing software versions present in Mageia 1 + + + + + + + + + +

[Mageia-dev] List of CVE referencing software versions present in Mageia 1

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Fri Jan 6 13:00:28 CET 2012 +

+
+ +
Le 05/01/2012 23:37, Pascal Terjan a écrit :
+> Here is the output of a little script I just wrote.
+>
+> Vulnerable version, please check that a patch was applied if needed
+I tried to do it for bind, and dhcp, however I'm a bit confused about 
+the svn tree...
+
+For bind, the updates/1/bind/current path contains a SPEC file 
+corresponding to a 9.8.1-6.P1 package, which doesn't exist anywhere on 
+the mirror:
+9.8.1P1-1.mga1 for pending updates updates_testing
+9.8.0-6.P4.mga1 for available updates
+9.8.0-6.P1.mga1 for release
+
+For dhcp, the updates/1/dhcp/current path contains a SPEC file 
+corresponding to the release package (3:4.2.1-0.P1.3):
+3:4.2.1-0.P1.3.1.mga1 for pending updates
+3:4.2.1-0.P1.3.mga1 for release
+
+So, I guess 1/<foo>/current should match release package, 
+updates/1/<foo>/current should match latest available update, but where 
+is located pending updates package content ?
+
+[..]
+> * openssl 1.0.0d
+>    - CVE-2011-1945
+>    - CVE-2011-3207
+>    - CVE-2011-3210
++ CVE-2011-4108
++ CVE-2011-4109
++ CVE-2011-4576
++ CVE-2011-4577
++ CVE-2011-4619
++ CVE-2012-0027
+
+-- 
+BOFH excuse #11:
+
+magnetic interference from money/credit cards
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011024.html b/zarb-ml/mageia-dev/2012-January/011024.html new file mode 100644 index 000000000..eefc0390e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011024.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Fri Jan 6 13:02:26 CET 2012 +

+
+ +
On 6 January 2012 12:27, Wolfgang Bornath <molch.b at googlemail.com> wrote:
+> This is a well known issue.
+> To clear out the list you need a deep knowledge of the system to
+> determine which packages are really not needed anymore.
+>
+> Lately  this --auto-orphans line shreddered my whole system on a fresh
+> install after the first update, several system services could not
+> start at next reboot, applications did not run, etc. One of the very
+> few times I had to re-install because of a bug. Call me newbie or
+> pussy but until this is not a secure function I will never touch it
+> again.
+
+This is just a bogus claim:
+If some apps break after removing orphan packages, they'll break too
+after manually removing such packages, meaning they lack some
+requires...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011025.html b/zarb-ml/mageia-dev/2012-January/011025.html new file mode 100644 index 000000000..87b1e2a0d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011025.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Fri Jan 6 13:12:43 CET 2012 +

+
+ +
2012/1/6 Thierry Vignaud <thierry.vignaud at gmail.com>:
+> On 6 January 2012 12:27, Wolfgang Bornath <molch.b at googlemail.com> wrote:
+>> This is a well known issue.
+>> To clear out the list you need a deep knowledge of the system to
+>> determine which packages are really not needed anymore.
+>>
+>> Lately  this --auto-orphans line shreddered my whole system on a fresh
+>> install after the first update, several system services could not
+>> start at next reboot, applications did not run, etc. One of the very
+>> few times I had to re-install because of a bug. Call me newbie or
+>> pussy but until this is not a secure function I will never touch it
+>> again.
+>
+> This is just a bogus claim:
+> If some apps break after removing orphan packages, they'll break too
+> after manually removing such packages, meaning they lack some
+> requires...
+
+Yes, right, I'd not remove such packages manually - they were marked
+as orphans and removed by the function - which is my claim.
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011026.html b/zarb-ml/mageia-dev/2012-January/011026.html new file mode 100644 index 000000000..1776a2a7e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011026.html @@ -0,0 +1,111 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Fri Jan 6 13:16:59 CET 2012 +

+
+ +
2012/1/6 Wolfgang Bornath <molch.b at googlemail.com>:
+> 2012/1/6 Thierry Vignaud <thierry.vignaud at gmail.com>:
+>> On 6 January 2012 12:27, Wolfgang Bornath <molch.b at googlemail.com> wrote:
+>>> This is a well known issue.
+>>> To clear out the list you need a deep knowledge of the system to
+>>> determine which packages are really not needed anymore.
+>>>
+>>> Lately  this --auto-orphans line shreddered my whole system on a fresh
+>>> install after the first update, several system services could not
+>>> start at next reboot, applications did not run, etc. One of the very
+>>> few times I had to re-install because of a bug. Call me newbie or
+>>> pussy but until this is not a secure function I will never touch it
+>>> again.
+>>
+>> This is just a bogus claim:
+>> If some apps break after removing orphan packages, they'll break too
+>> after manually removing such packages, meaning they lack some
+>> requires...
+>
+> Yes, right, I'd not remove such packages manually - they were marked
+> as orphans and removed by the function - which is my claim.
+
+To make it clear - my claim is that the orphan function marked
+packages as orphans which are needed and which I'd never remove
+manually. If you have a list of 100 "orphans" it is next to impossible
+for a normal user to sit down and check each and every package if it
+is really an orphan (orphan in the sense of "not needed").
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011027.html b/zarb-ml/mageia-dev/2012-January/011027.html new file mode 100644 index 000000000..742b2b870 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011027.html @@ -0,0 +1,110 @@ + + + + [Mageia-dev] List of CVE referencing software versions present in Mageia 1 + + + + + + + + + +

[Mageia-dev] List of CVE referencing software versions present in Mageia 1

+ Florian Hubold + doktor5000 at arcor.de +
+ Fri Jan 6 13:17:55 CET 2012 +

+
+ +
Am 05.01.2012 23:37, schrieb Pascal Terjan:
+> Here is the output of a little script I just wrote.
+>
+> Vulnerable version, please check that a patch was applied if needed
+At first, thanks a million times for this :)
+> * conky 1.8.1
+>   - CVE-2011-3616
+Just fixed.
+> * cups 1.4.6
+>   - CVE-2011-2896
+>   - CVE-2011-3170
+Both fixed since 2011-10-23
+> * wireshark 1.4.6
+>   - CVE-2011-1957
+>   - CVE-2011-1958
+>   - CVE-2011-1959
+>   - CVE-2011-2174
+>   - CVE-2011-2175
+>   - CVE-2011-2597
+>   - CVE-2011-2698
+>   - CVE-2011-3360
+>   - CVE-2011-4101
+>   - CVE-2011-4102
+We got wireshark 1.4.10, all fixed, but the listing is missing at least
+
+  - CVE-2011-3483
+  - CVE-2011-3266
+
+which were fixed already in last 1.4.6 update.
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011028.html b/zarb-ml/mageia-dev/2012-January/011028.html new file mode 100644 index 000000000..fbb2f1ee2 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011028.html @@ -0,0 +1,154 @@ + + + + [Mageia-dev] Mageia 2 alpha 3 in progress + + + + + + + + + +

[Mageia-dev] Mageia 2 alpha 3 in progress

+ Anne nicolas + ennael at mageia.org +
+ Fri Jan 6 13:26:45 CET 2012 +

+
+ +
Hi there
+
+First of all, happy new year 2012 and all the best for you and your family.
+
+Mageia 2 alpha3 isos are now in progress, public release is planned
+for 12th of january. Please do not provide for now major updates on
+packages as we will freeze local repository in coming hours.
+
+Thanks for advance
+
+-- 
+Anne
+http://www.mageia.org
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011029.html b/zarb-ml/mageia-dev/2012-January/011029.html new file mode 100644 index 000000000..72f6dc456 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011029.html @@ -0,0 +1,217 @@ + + + + [Mageia-dev] Numerous mariadb issues today. + + + + + + + + + +

[Mageia-dev] Numerous mariadb issues today.

+ Maarten Vanraes + alien at rmail.be +
+ Fri Jan 6 13:32:29 CET 2012 +

+
+ +
Op vrijdag 06 januari 2012 11:21:44 schreef Colin Guthrie:
+> Hi,
+> 
+> There are several problems today with mariadb, some more serious than
+> others:
+> 
+> Firstly, (a minor problem) the log file:
+> Jan  3 14:04:34 jimmy mysqld_safe[10642]: 120103 14:04:34 mysqld_safe
+> Logging to '/var/log/mysqld/mysqld.log'.
+> Jan  3 14:04:34 jimmy mysqld_safe[10642]: 120103 14:04:34 mysqld_safe
+> Starting mysqld daemon with databases from /var/lib/mysql
+> Jan  3 14:05:53 jimmy mysqld-prepare-db-dir[11245]: touch: cannot touch
+> `/var/log/mysqld.log': Permission denied
+> Jan  3 14:05:53 jimmy mysqld-prepare-db-dir[11245]: chown: cannot access
+> `/var/log/mysqld.log': No such file or directory
+> Jan  3 14:05:53 jimmy mysqld-prepare-db-dir[11245]: chmod: cannot access
+> `/var/log/mysqld.log': No such file or directory
+> 
+> As the script is run as the mysql user, it cannot touch the
+> (non-existant) log file as the directory is owned by root. Better to do
+> this in a %post script to ensure the file is all present and properly
+> owned to avoid this error.
+
+that is strange, this was an error that also mysql has had since ages; and i 
+fixed for both mysql and mariadb in cauldron, are you using an older my.cnf?
+this error was there before and is non-fatal iirc. however, newer my.cnf files 
+should have the correct path
+ 
+> Secondly, several plugins were moved to mariadb-obsolete. I have most of
+> my databases stored in innodb format and this was one of the plugins
+> moved over. Even when I did install the -obsolete package to get
+> ha_innodb back, I couldn't use it:
+> 
+> 120106 10:15:02 Percona XtraDB (http://www.percona.com) 1.1.8-20.1
+> started; log sequence number 52870027141
+> 120106 10:15:02 [ERROR] Function 'InnoDB' already exists
+> 120106 10:15:02 [ERROR] Couldn't load plugin named 'InnoDB' with soname
+> 'ha_innodb.so'.
+> 
+> Now I believe this is due to XtraDB duplicating the features of InnoDB
+> and thus effectively obsoleting it... does this mean I simply shouldn't
+> load InnoDB plugin now? Does it mean all the tweaks I made in my.cnf for
+> innodb pool sizes etc. now no longer work? What is the fallout from this
+> change?
+
+indeed you shouldn't use the -obsolete ones, the xtradb should nicely use your 
+innodb database, xtradb is a innodb with extra patches, so any innodb tuning 
+is still valid for xtradb.
+
+otoh, loading the ha_innodb.so should overwrite the internal xtradb code, so 
+i'll have to see why this isn't working.
+
+
+> Thirdly, federated was changed to fedaratedx, but federated was still
+> shipped in the mariadb-obsolete package... Sadly however the default
+> my.cnf still tries to load the ha_federated.so by default and activate
+> via a "federated" option in default my.cnf. So not only is a plugin
+> activated that is not installed, even when you do install
+> mariadb-obsolete, the "federated" option seems to no longer work anyway:
+> 
+> 120106 10:14:16 [ERROR] /usr/sbin/mysqld: unknown option '--federated'
+> 
+> So the "federated" option and the plugin load itself in my.cnf needs to
+> be updated somehow, both in the default my.cnf but also some attempt
+> should be made to update existing my.cnf too (with a backup).
+
+only the load plugin should be changed into federatedx.so instead of 
+federated.so ; the "federated" option is still valid for federatedx
+
+getting this error, means that you don't have any of them both loaded.
+
+sadly, my.cnf is a config file, i can provide a newer my.cnf all i want, it's 
+not like i can modify the my.cnf file for existing upgrades?
+
+
+my thoughts on plugins is: "xtradb is internal, because innodb was internal; 
+federatedx was external, because federated was external"
+
+can you recheck that a new my.cnf file at the very least works out of the box? 
+and is this x86_64 or i586?
+
+i'm not sure yet as how to do the upgrade to newer my.cnf other than maybe add 
+this to errata and maybe README.install.urpmi
+
+but, if you install using rpmdrake, didn't you get a popup box with the my.cnf 
+differences?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011030.html b/zarb-ml/mageia-dev/2012-January/011030.html new file mode 100644 index 000000000..78289e7de --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011030.html @@ -0,0 +1,277 @@ + + + + [Mageia-dev] Numerous mariadb issues today. + + + + + + + + + +

[Mageia-dev] Numerous mariadb issues today.

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Fri Jan 6 14:29:29 CET 2012 +

+
+ +
'Twas brillig, and Maarten Vanraes at 06/01/12 12:32 did gyre and gimble:
+> Op vrijdag 06 januari 2012 11:21:44 schreef Colin Guthrie:
+>> Hi,
+>>
+>> There are several problems today with mariadb, some more serious than
+>> others:
+>>
+>> Firstly, (a minor problem) the log file:
+>> Jan  3 14:04:34 jimmy mysqld_safe[10642]: 120103 14:04:34 mysqld_safe
+>> Logging to '/var/log/mysqld/mysqld.log'.
+>> Jan  3 14:04:34 jimmy mysqld_safe[10642]: 120103 14:04:34 mysqld_safe
+>> Starting mysqld daemon with databases from /var/lib/mysql
+>> Jan  3 14:05:53 jimmy mysqld-prepare-db-dir[11245]: touch: cannot touch
+>> `/var/log/mysqld.log': Permission denied
+>> Jan  3 14:05:53 jimmy mysqld-prepare-db-dir[11245]: chown: cannot access
+>> `/var/log/mysqld.log': No such file or directory
+>> Jan  3 14:05:53 jimmy mysqld-prepare-db-dir[11245]: chmod: cannot access
+>> `/var/log/mysqld.log': No such file or directory
+>>
+>> As the script is run as the mysql user, it cannot touch the
+>> (non-existant) log file as the directory is owned by root. Better to do
+>> this in a %post script to ensure the file is all present and properly
+>> owned to avoid this error.
+> 
+> that is strange, this was an error that also mysql has had since ages; and i 
+> fixed for both mysql and mariadb in cauldron, are you using an older my.cnf?
+> this error was there before and is non-fatal iirc. however, newer my.cnf files 
+> should have the correct path
+
+Ahh yes my my.cnf file didn't have the:
+
+[mysqld_safe]
+log-error=/var/log/mysqld/mysqld.log
+pid-file=/var/run/mysqld/mysqld.pid
+
+bits.
+
+If the default my.cnf file ships with that path (don't know if it does
+or if it's patched in our packages) then perhaps the
+mysqld-prepare-db-dir script should also be updated to use that as the
+default?
+
+>> Secondly, several plugins were moved to mariadb-obsolete. I have most of
+>> my databases stored in innodb format and this was one of the plugins
+>> moved over. Even when I did install the -obsolete package to get
+>> ha_innodb back, I couldn't use it:
+>>
+>> 120106 10:15:02 Percona XtraDB (http://www.percona.com) 1.1.8-20.1
+>> started; log sequence number 52870027141
+>> 120106 10:15:02 [ERROR] Function 'InnoDB' already exists
+>> 120106 10:15:02 [ERROR] Couldn't load plugin named 'InnoDB' with soname
+>> 'ha_innodb.so'.
+>>
+>> Now I believe this is due to XtraDB duplicating the features of InnoDB
+>> and thus effectively obsoleting it... does this mean I simply shouldn't
+>> load InnoDB plugin now? Does it mean all the tweaks I made in my.cnf for
+>> innodb pool sizes etc. now no longer work? What is the fallout from this
+>> change?
+> 
+> indeed you shouldn't use the -obsolete ones, the xtradb should nicely use your 
+> innodb database, xtradb is a innodb with extra patches, so any innodb tuning 
+> is still valid for xtradb.
+
+OK, cool. As long as it still reads e.g. innodb_* from my.conf then all
+will be well I think :)
+
+> otoh, loading the ha_innodb.so should overwrite the internal xtradb code, so 
+> i'll have to see why this isn't working.
+
+Cool, I'll leave that with you :D
+
+>> Thirdly, federated was changed to fedaratedx, but federated was still
+>> shipped in the mariadb-obsolete package... Sadly however the default
+>> my.cnf still tries to load the ha_federated.so by default and activate
+>> via a "federated" option in default my.cnf. So not only is a plugin
+>> activated that is not installed, even when you do install
+>> mariadb-obsolete, the "federated" option seems to no longer work anyway:
+>>
+>> 120106 10:14:16 [ERROR] /usr/sbin/mysqld: unknown option '--federated'
+>>
+>> So the "federated" option and the plugin load itself in my.cnf needs to
+>> be updated somehow, both in the default my.cnf but also some attempt
+>> should be made to update existing my.cnf too (with a backup).
+> 
+> only the load plugin should be changed into federatedx.so instead of 
+> federated.so ; the "federated" option is still valid for federatedx
+> 
+> getting this error, means that you don't have any of them both loaded.
+
+Hmm, I thought I had tried all combinations, but I obviously didn't try
+the ha_federatedx.so + federated option... gah, sorry about that. Still
+the plugin name in the conf does still need updating, so at least I'm
+not completely daft :D
+
+> sadly, my.cnf is a config file, i can provide a newer my.cnf all i want, it's 
+> not like i can modify the my.cnf file for existing upgrades?
+
+There are various things you can do with sed/awk on upgrades... I'd at
+very least suggest a "sed -i 's/ha_federated\.so/ha_federatedx\.so/g'
+/etc/my.cnf" to fix up that issue (which would prevent mysql starting...
+looking back, that was probably the fundamental issue I had.
+
+> my thoughts on plugins is: "xtradb is internal, because innodb was internal; 
+> federatedx was external, because federated was external"
+
+Hmm? innodb was not internal before was it? I thought it was a plugin
+since a very long time (I pretty sure I remember panicking when Oden
+enabled it for the first time a year or two back). Perhaps I'm wrong tho'.
+
+
+If you do make xtradb a plugin, then I'd suggest doing a "sed -i
+'s/ha_innodb\.so/ha_xtradb\.so/g' m/etc/my.cnf" in the %post also.
+
+
+> can you recheck that a new my.cnf file at the very least works out of the box? 
+> and is this x86_64 or i586?
+
+It doesn't. It mentions ha_federated.so as mentioned above rather than
+ha_federatedx.so, so this needs to be fixed. This is on x86_64 but I
+guess that doesn't matter here.
+
+> i'm not sure yet as how to do the upgrade to newer my.cnf other than maybe add 
+> this to errata and maybe README.install.urpmi
+> 
+> but, if you install using rpmdrake, didn't you get a popup box with the my.cnf 
+> differences?
+
+I did get the popup, but of course as the ha_federated.so thing was the
+same, this is probably why I ran into trouble.
+
+Cheers
+
+Col
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011031.html b/zarb-ml/mageia-dev/2012-January/011031.html new file mode 100644 index 000000000..fd967b112 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011031.html @@ -0,0 +1,157 @@ + + + + [Mageia-dev] Numerous mariadb issues today. + + + + + + + + + +

[Mageia-dev] Numerous mariadb issues today.

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Fri Jan 6 14:31:47 CET 2012 +

+
+ +
'Twas brillig, and Colin Guthrie at 06/01/12 13:29 did gyre and gimble:
+> 'Twas brillig, and Maarten Vanraes at 06/01/12 12:32 did gyre and gimble:
+> If you do make xtradb a plugin, then I'd suggest doing a "sed -i
+> 's/ha_innodb\.so/ha_xtradb\.so/g' m/etc/my.cnf" in the %post also.
+
+Oh and possibly this too:
+
+sed -i 's/^err-log=/log-error=/' /etc/my.cnf
+
+
+As it seems this syntax changed at some point... not sure when.
+
+Col
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011032.html b/zarb-ml/mageia-dev/2012-January/011032.html new file mode 100644 index 000000000..813e8e392 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011032.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Fri Jan 6 15:17:53 CET 2012 +

+
+ +
On 6 January 2012 13:16, Wolfgang Bornath <molch.b at googlemail.com> wrote:
+>>> This is just a bogus claim:
+>>> If some apps break after removing orphan packages, they'll break too
+>>> after manually removing such packages, meaning they lack some
+>>> requires...
+>>
+>> Yes, right, I'd not remove such packages manually - they were marked
+>> as orphans and removed by the function - which is my claim.
+>
+> To make it clear - my claim is that the orphan function marked
+> packages as orphans which are needed and which I'd never remove
+> manually. If you have a list of 100 "orphans" it is next to impossible
+> for a normal user to sit down and check each and every package if it
+> is really an orphan (orphan in the sense of "not needed").
+
+I never say you manually removed them.
+Again, if packages break after urpme --auto-orphans, they can break
+after manually removing packages, thus the issue is that those
+packages lacks requires on needed components.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011033.html b/zarb-ml/mageia-dev/2012-January/011033.html new file mode 100644 index 000000000..036f9e1e8 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011033.html @@ -0,0 +1,131 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Thomas Spuhler + thomas at btspuhler.com +
+ Fri Jan 6 15:19:54 CET 2012 +

+
+ +
On Friday, January 06, 2012 05:16:59 AM Wolfgang Bornath wrote:
+> 2012/1/6 Wolfgang Bornath <molch.b at googlemail.com>:
+> > 2012/1/6 Thierry Vignaud <thierry.vignaud at gmail.com>:
+> >> On 6 January 2012 12:27, Wolfgang Bornath <molch.b at googlemail.com> wrote:
+> >>> This is a well known issue.
+> >>> To clear out the list you need a deep knowledge of the system to
+> >>> determine which packages are really not needed anymore.
+> >>> 
+> >>> Lately  this --auto-orphans line shreddered my whole system on a fresh
+> >>> install after the first update, several system services could not
+> >>> start at next reboot, applications did not run, etc. One of the very
+> >>> few times I had to re-install because of a bug. Call me newbie or
+> >>> pussy but until this is not a secure function I will never touch it
+> >>> again.
+> >> 
+> >> This is just a bogus claim:
+> >> If some apps break after removing orphan packages, they'll break too
+> >> after manually removing such packages, meaning they lack some
+> >> requires...
+> > 
+> > Yes, right, I'd not remove such packages manually - they were marked
+> > as orphans and removed by the function - which is my claim.
+> 
+> To make it clear - my claim is that the orphan function marked
+> packages as orphans which are needed and which I'd never remove
+> manually. If you have a list of 100 "orphans" it is next to impossible
+> for a normal user to sit down and check each and every package if it
+> is really an orphan (orphan in the sense of "not needed").
++1
+-- 
+Best regards
+Thomas Spuhler
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011034.html b/zarb-ml/mageia-dev/2012-January/011034.html new file mode 100644 index 000000000..99d855df2 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011034.html @@ -0,0 +1,135 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ LinuxBSDos.com + finid at linuxbsdos.com +
+ Fri Jan 6 15:53:13 CET 2012 +

+
+ +
> 2012/1/6 Robert Fox <list at foxconsult.net>:
+>> After latest Cauldron updates, I got a real long list of suggested
+>> "orphans" - but I believe some of these packages are needed (like hal or
+>> basesystem-minimal) -
+>>
+>> How do I clear out the orphans - like reset the logic behind it so the
+>> correct packages will be orphaned?  Or is a fresh install in order??
+>>
+>>
+>> The following packages:
+>>  aisleriot-3.3.1-1.mga2.x86_64
+>>  alacarte-0.13.2-3.mga1.noarch
+>>  alsa-plugins-doc-1.0.24-5.mga2.noarch
+>> ....
+>
+> This is a well known issue.
+> To clear out the list you need a deep knowledge of the system to
+> determine which packages are really not needed anymore.
+>
+> Lately  this --auto-orphans line shreddered my whole system on a fresh
+> install after the first update, several system services could not
+> start at next reboot, applications did not run, etc. One of the very
+> few times I had to re-install because of a bug. Call me newbie or
+> pussy but until this is not a secure function I will never touch it
+> again.
+>
+
+Btw, this problem is not unique to Mageia. After I hosed a Debian
+installation by running apt with auto-orphans, I vowed never to mess with
+orphans again.
+
+The system has to be intelligent enough to know what is or is not an orphan.
+
+--
+Finid.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011035.html b/zarb-ml/mageia-dev/2012-January/011035.html new file mode 100644 index 000000000..97ab0e036 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011035.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Fri Jan 6 16:13:48 CET 2012 +

+
+ +
2012/1/6 Thierry Vignaud <thierry.vignaud at gmail.com>:
+> On 6 January 2012 13:16, Wolfgang Bornath <molch.b at googlemail.com> wrote:
+>>>> This is just a bogus claim:
+>>>> If some apps break after removing orphan packages, they'll break too
+>>>> after manually removing such packages, meaning they lack some
+>>>> requires...
+>>>
+>>> Yes, right, I'd not remove such packages manually - they were marked
+>>> as orphans and removed by the function - which is my claim.
+>>
+>> To make it clear - my claim is that the orphan function marked
+>> packages as orphans which are needed and which I'd never remove
+>> manually. If you have a list of 100 "orphans" it is next to impossible
+>> for a normal user to sit down and check each and every package if it
+>> is really an orphan (orphan in the sense of "not needed").
+>
+> I never say you manually removed them.
+> Again, if packages break after urpme --auto-orphans, they can break
+> after manually removing packages, thus the issue is that those
+> packages lacks requires on needed components.
+
+Ah, I see your reasoning, of course, if the packager forgot to name
+the requires then urpmi declares them as orphans. But then, to be
+safe, you have to forget about auto-orphans altogether because you can
+not be sure that all packagers did their homework.
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011036.html b/zarb-ml/mageia-dev/2012-January/011036.html new file mode 100644 index 000000000..6d7e5506a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011036.html @@ -0,0 +1,127 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Fri Jan 6 16:13:49 CET 2012 +

+
+ +
On 6 January 2012 15:53, LinuxBSDos.com <finid at linuxbsdos.com> wrote:
+>> This is a well known issue.
+>> To clear out the list you need a deep knowledge of the system to
+>> determine which packages are really not needed anymore.
+>>
+>> Lately  this --auto-orphans line shreddered my whole system on a fresh
+>> install after the first update, several system services could not
+>> start at next reboot, applications did not run, etc. One of the very
+>> few times I had to re-install because of a bug. Call me newbie or
+>> pussy but until this is not a secure function I will never touch it
+>> again.
+>
+> Btw, this problem is not unique to Mageia. After I hosed a Debian
+> installation by running apt with auto-orphans, I vowed never to mess with
+> orphans again.
+>
+> The system has to be intelligent enough to know what is or is not an orphan.
+
+It is.
+orphan packages are packages that were never directly requested/installed;
+they're packages that got installed because they were requested or suggested
+by other packages that were explicitely choosed.
+Then if you remove the package you explicitely choose, urpmi sees that the
+packages that were requested by this one are no more required by anything
+and since you never explicitely requested them, it offer to remove them.
+
+You can explicitely request them by running "urpmi <package>" and it'll never
+be in the orphan list anymore after.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011037.html b/zarb-ml/mageia-dev/2012-January/011037.html new file mode 100644 index 000000000..4b17de1b5 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011037.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Fri Jan 6 16:27:47 CET 2012 +

+
+ +
On 6 January 2012 16:13, Wolfgang Bornath <molch.b at googlemail.com> wrote:
+>>>>> This is just a bogus claim:
+>>>>> If some apps break after removing orphan packages, they'll break too
+>>>>> after manually removing such packages, meaning they lack some
+>>>>> requires...
+>>>>
+>>>> Yes, right, I'd not remove such packages manually - they were marked
+>>>> as orphans and removed by the function - which is my claim.
+>>>
+>>> To make it clear - my claim is that the orphan function marked
+>>> packages as orphans which are needed and which I'd never remove
+>>> manually. If you have a list of 100 "orphans" it is next to impossible
+>>> for a normal user to sit down and check each and every package if it
+>>> is really an orphan (orphan in the sense of "not needed").
+>>
+>> I never say you manually removed them.
+>> Again, if packages break after urpme --auto-orphans, they can break
+>> after manually removing packages, thus the issue is that those
+>> packages lacks requires on needed components.
+>
+> Ah, I see your reasoning, of course, if the packager forgot to name
+> the requires then urpmi declares them as orphans. But then, to be
+> safe, you have to forget about auto-orphans altogether because you can
+> not be sure that all packagers did their homework.
+
+You'll still break minimal install + manual choices.
+Those've to be fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011038.html b/zarb-ml/mageia-dev/2012-January/011038.html new file mode 100644 index 000000000..693e99381 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011038.html @@ -0,0 +1,142 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Thomas Backlund + tmb at mageia.org +
+ Fri Jan 6 16:33:21 CET 2012 +

+
+ +
06.01.2012 12:16, Robert Fox skrev:
+> After latest Cauldron updates, I got a real long list of suggested
+> "orphans" - but I believe some of these packages are needed (like hal or
+> basesystem-minimal) -
+>
+> How do I clear out the orphans - like reset the logic behind it so the
+> correct packages will be orphaned?  Or is a fresh install in order??
+>
+>
+> The following packages:
+
+[...]
+
+>    basesystem-minimal-2-3.mga2.x86_64
+
+You have apparently uninstalled basesystem with rpm -e, since urpmi wont 
+allow you to remove it. So you got basesystem-minimal and all deps free 
+for removal now.
+
+--
+Thomas
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011039.html b/zarb-ml/mageia-dev/2012-January/011039.html new file mode 100644 index 000000000..4796c098b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011039.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] List of CVE referencing software versions present in Mageia 1 + + + + + + + + + +

[Mageia-dev] List of CVE referencing software versions present in Mageia 1

+ Jani Välimaa + jani.valimaa at gmail.com +
+ Fri Jan 6 16:40:40 CET 2012 +

+
+ +
2012/1/6 Pascal Terjan <pterjan at gmail.com>:
+> Here is the output of a little script I just wrote.
+>
+> Vulnerable version, please check that a patch was applied if needed
+
+..snip..
+
+> * openttd 1.1.0
+>  - CVE-2011-3341
+>  - CVE-2011-3342
+>  - CVE-2011-3343
+
+Fixed.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011040.html b/zarb-ml/mageia-dev/2012-January/011040.html new file mode 100644 index 000000000..2491d96a6 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011040.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Fri Jan 6 16:48:42 CET 2012 +

+
+ +
Le 06/01/2012 16:13, Wolfgang Bornath a écrit :
+> Ah, I see your reasoning, of course, if the packager forgot to name
+> the requires then urpmi declares them as orphans. But then, to be
+> safe, you have to forget about auto-orphans altogether because you can
+> not be sure that all packagers did their homework.
+Then you have to forget about using packages because you're not sure 
+packagers did their work correctly.
+
+So far, still no one proved than 'orphan' status was wrong regarding 
+urpmi definition of what is an orphan package, rather than regarding 
+their own personal expectation.
+
+-- 
+BOFH excuse #370:
+
+Virus due to computers having unsafe sex.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011041.html b/zarb-ml/mageia-dev/2012-January/011041.html new file mode 100644 index 000000000..aca66a115 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011041.html @@ -0,0 +1,123 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Florian Hubold + doktor5000 at arcor.de +
+ Fri Jan 6 16:58:03 CET 2012 +

+
+ +
Am 06.01.2012 16:48, schrieb Guillaume Rousse:
+> Le 06/01/2012 16:13, Wolfgang Bornath a écrit :
+>> Ah, I see your reasoning, of course, if the packager forgot to name
+>> the requires then urpmi declares them as orphans. But then, to be
+>> safe, you have to forget about auto-orphans altogether because you can
+>> not be sure that all packagers did their homework.
+> Then you have to forget about using packages because you're not sure
+> packagers did their work correctly.
+>
+> So far, still no one proved than 'orphan' status was wrong regarding urpmi
+> definition of what is an orphan package, rather than regarding their own
+> personal expectation.
+>
+Maybe the problem comes from the fact that urpmi's orphan definition
+and the scope/purpose of the auto-orphan function is nowhere
+officially documented AFAIK, and so users think that it magically
+does whatever they imagine that this should do.
+
+I'd like to document it in our wiki, so at least we can point those
+people to some documentation and they understand how this is
+supposed to work.
+
+So what would you like to add to such documentation, currently i'd
+start with tv's explanation:
+
+    orphan packages are packages that were never directly requested/installed;
+    they're packages that got installed because they were requested or suggested
+    by other packages that were explicitely choosed.
+    Then if you remove the package you explicitely choose, urpmi sees that the
+    packages that were requested by this one are no more required by anything
+    and since you never explicitely requested them, it offer to remove them.
+
+    You can explicitely request them by running "urpmi <package>" and it'll never
+    be in the orphan list anymore after.
+
+
+Also mentioning /var/lib/rpm/installed-through-deps.list and the
+description of it from urpmi.files manpage.
+
+
+BTW: why is apropos telling me there's nothing appropriate for urpm/urpmi?
+Is that a bug?
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011042.html b/zarb-ml/mageia-dev/2012-January/011042.html new file mode 100644 index 000000000..ed5f49225 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011042.html @@ -0,0 +1,155 @@ + + + + [Mageia-dev] mirror problem ? + + + + + + + + + +

[Mageia-dev] mirror problem ?

+ philippe makowski + makowski.mageia at gmail.com +
+ Fri Jan 6 16:58:28 CET 2012 +

+
+ +
Hi,
+
+am I the only one that can't do updates since yesterday ?
+
+I get this message :
+
+erreur: /var/cache/urpmi/partial/autocorr-fr-3.4.4.2-0.3.mga1.noarch.rpm:
+not an rpm package
+erreur: /var/cache/urpmi/partial/libreoffice-opensymbol-fonts-3.4.4.2-0.3.mga1.noarch.rpm:
+not an rpm package
+erreur: /var/cache/urpmi/partial/libreoffice-xsltfilter-3.4.4.2-0.3.mga1.x86_64.rpm:
+not an rpm package
+erreur: /var/cache/urpmi/partial/libreoffice-pyuno-3.4.4.2-0.3.mga1.x86_64.rpm:
+not an rpm package
+    http://mirrors.mageia.org/api/mageia.1.x86_64.list:
+media/../../i586/media/core/updates/libreoffice-opensymbol-fonts-3.4.4.2-0.3.mga1.noarch.rpm
+    http://mirrors.mageia.org/api/mageia.1.x86_64.list:
+media/../../i586/media/core/updates/autocorr-fr-3.4.4.2-0.3.mga1.noarch.rpm
+erreur: /var/cache/urpmi/partial/libreoffice-opensymbol-fonts-3.4.4.2-0.3.mga1.noarch.rpm:
+not an rpm package
+erreur: /var/cache/urpmi/partial/autocorr-fr-3.4.4.2-0.3.mga1.noarch.rpm:
+not an rpm package
+L'installation a échoué à cause de paquets bogués :
+    http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/1/x86_64/media/core/updates/libreoffice-xsltfilter-3.4.4.2-0.3.mga1.x86_64.rpm
+    http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/1/i586/media/core/updates/libreoffice-opensymbol-fonts-3.4.4.2-0.3.mga1.noarch.rpm
+    http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/1/x86_64/media/core/updates/libreoffice-pyuno-3.4.4.2-0.3.mga1.x86_64.rpm
+    http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/1/i586/media/core/updates/autocorr-fr-3.4.4.2-0.3.mga1.noarch.rpm
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011043.html b/zarb-ml/mageia-dev/2012-January/011043.html new file mode 100644 index 000000000..fab8b8c67 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011043.html @@ -0,0 +1,181 @@ + + + + [Mageia-dev] mirror problem ? + + + + + + + + + +

[Mageia-dev] mirror problem ?

+ Pascal Terjan + pterjan at gmail.com +
+ Fri Jan 6 17:11:04 CET 2012 +

+
+ +
On Fri, Jan 6, 2012 at 15:58, philippe makowski
+<makowski.mageia at gmail.com> wrote:
+> Hi,
+>
+> am I the only one that can't do updates since yesterday ?
+>
+> I get this message :
+>
+> erreur: /var/cache/urpmi/partial/autocorr-fr-3.4.4.2-0.3.mga1.noarch.rpm:
+> not an rpm package
+> erreur: /var/cache/urpmi/partial/libreoffice-opensymbol-fonts-3.4.4.2-0.3.mga1.noarch.rpm:
+> not an rpm package
+> erreur: /var/cache/urpmi/partial/libreoffice-xsltfilter-3.4.4.2-0.3.mga1.x86_64.rpm:
+> not an rpm package
+> erreur: /var/cache/urpmi/partial/libreoffice-pyuno-3.4.4.2-0.3.mga1.x86_64.rpm:
+> not an rpm package
+>    http://mirrors.mageia.org/api/mageia.1.x86_64.list:
+> media/../../i586/media/core/updates/libreoffice-opensymbol-fonts-3.4.4.2-0.3.mga1.noarch.rpm
+>    http://mirrors.mageia.org/api/mageia.1.x86_64.list:
+> media/../../i586/media/core/updates/autocorr-fr-3.4.4.2-0.3.mga1.noarch.rpm
+> erreur: /var/cache/urpmi/partial/libreoffice-opensymbol-fonts-3.4.4.2-0.3.mga1.noarch.rpm:
+> not an rpm package
+> erreur: /var/cache/urpmi/partial/autocorr-fr-3.4.4.2-0.3.mga1.noarch.rpm:
+> not an rpm package
+> L'installation a échoué à cause de paquets bogués :
+>    http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/1/x86_64/media/core/updates/libreoffice-xsltfilter-3.4.4.2-0.3.mga1.x86_64.rpm
+>    http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/1/i586/media/core/updates/libreoffice-opensymbol-fonts-3.4.4.2-0.3.mga1.noarch.rpm
+>    http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/1/x86_64/media/core/updates/libreoffice-pyuno-3.4.4.2-0.3.mga1.x86_64.rpm
+>    http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/1/i586/media/core/updates/autocorr-fr-3.4.4.2-0.3.mga1.noarch.rpm
+
+The first package is valid here:
+
+[pterjan at coin dr]$ wget
+http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/1/x86_64/media/core/updates/libreoffice-xsltfilter-3.4.4.2-0.3.mga1.x86_64.rpm
+--2012-01-06 17:10:06--
+http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/1/x86_64/media/core/updates/libreoffice-xsltfilter-3.4.4.2-0.3.mga1.x86_64.rpm
+R�solution de distrib-coffee.ipsl.jussieu.fr
+(distrib-coffee.ipsl.jussieu.fr)... 134.157.176.20
+Connexion vers distrib-coffee.ipsl.jussieu.fr
+(distrib-coffee.ipsl.jussieu.fr)|134.157.176.20|:80...connect�.
+requ�te HTTP transmise, en attente de la r�ponse...200 OK
+Longueur: 187713 (183K) [text/plain]
+Sauvegarde en : �libreoffice-xsltfilter-3.4.4.2-0.3.mga1.x86_64.rpm�
+
+100%[=======================================================================================================================================>]
+187 713     65,2K/s   ds 2,8s
+
+2012-01-06 17:10:09 (65,2 KB/s) -
+�libreoffice-xsltfilter-3.4.4.2-0.3.mga1.x86_64.rpm� sauvegard�
+[187713/187713]
+
+[pterjan at coin dr]$ rpm -qp libreoffice-xsltfilter-3.4.4.2-0.3.mga1.x86_64.rpm
+libreoffice-xsltfilter-3.4.4.2-0.3.mga1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011044.html b/zarb-ml/mageia-dev/2012-January/011044.html new file mode 100644 index 000000000..3a35d403e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011044.html @@ -0,0 +1,134 @@ + + + + [Mageia-dev] mirror problem ? + + + + + + + + + +

[Mageia-dev] mirror problem ?

+ philippe makowski + makowski.mageia at gmail.com +
+ Fri Jan 6 17:48:14 CET 2012 +

+
+ +
2012/1/6 Pascal Terjan <pterjan at gmail.com>:
+> The first package is valid here:
+>
+strange
+I tried many times after a urpmi --clean with no success
+and now, with another mirror, no problem
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011045.html b/zarb-ml/mageia-dev/2012-January/011045.html new file mode 100644 index 000000000..b582ae0bb --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011045.html @@ -0,0 +1,152 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Fri Jan 6 17:55:42 CET 2012 +

+
+ +
'Twas brillig, and Robert Fox at 06/01/12 10:16 did gyre and gimble:
+> After latest Cauldron updates, I got a real long list of suggested
+> "orphans" - but I believe some of these packages are needed (like hal or
+> basesystem-minimal) -
+> 
+> How do I clear out the orphans - like reset the logic behind it so the
+> correct packages will be orphaned?  Or is a fresh install in order??
+
+FWIW, as I see some people not liking this feature, personally I don't
+use --auto-orphans, but instead use "urpmq --not-available" to find
+packages I have installed that are no longer provided by the
+repositories. This will typically include old and unneeded library
+majors etc. that accumulate after a while.
+
+This list is much clearer in what it actually outputs and is basically
+the same as the yum orphan list command (I forget what the command
+actually is, but it's what inspired me to write the first version which
+in turn was vastly improved by a native implementation by (IIRC) Pascal
+Terjan :))
+
+Col
+
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011046.html b/zarb-ml/mageia-dev/2012-January/011046.html new file mode 100644 index 000000000..a433c0d71 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011046.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] references to outside web sites/wiki + + + + + + + + + +

[Mageia-dev] references to outside web sites/wiki

+ Johnny A. Solbu + cooker at solbu.net +
+ Fri Jan 6 18:21:20 CET 2012 +

+
+ +
On Friday 06 January 2012 08:31, Glen Ogilvie wrote:
+> Does anyone have <..> a complete set of SRPMs from cooker?
+
+I just did a "du -hs" to see how large the SRPMS dir is for the last two releases, in case anyone wan't to know how much they will have to mirror.
+2011 - 50GB
+2010.2 - 46GB
+
+Personally I'm in the process of downloading 2010.2's SRPMS dir, for the first time, just in case Mandriva really does get shut down, and the mirrors automatically remove it.
+(2010.2 is the latest MDV I have installed on my systems. I only have a virtual 2011 install, for development purposes)
+
+Thou I seriously don't believe All of the mirrors will start to remove Mandriva from their servers. Especially those who still have old releases. Some mirrors still have everything as far back as MDK 7.2.
+So, some mirrors will exist even if Mandriva closes down.
+
+-- 
+Johnny A. Solbu
+PGP key ID: 0xFA687324
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 189 bytes
+Desc: This is a digitally signed message part.
+URL: </pipermail/mageia-dev/attachments/20120106/77e3d6fa/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011047.html b/zarb-ml/mageia-dev/2012-January/011047.html new file mode 100644 index 000000000..24748565a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011047.html @@ -0,0 +1,126 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Johnny A. Solbu + cooker at solbu.net +
+ Fri Jan 6 18:40:25 CET 2012 +

+
+ +
On Friday 06 January 2012 16:13, Thierry Vignaud wrote:
+> > The system has to be intelligent enough to know what is or is not an orphan.
+> 
+> It is.
+
+We claim that it is not.
+
+> orphan packages are packages that were never directly requested/installed;
+> they're packages that got installed because they were requested or suggested
+> by other packages that were explicitely choosed.
+
+Then why does it offer to remove packages that will Break the system, even if the package was never manually requested?
+
+I have experienced this my self, many years ago.
+Back when I had MDK 9.1 I was looking for an id3 tag editor, for mp3 tagging. I installed one, tested it uninstalled it and tested a new one untill I found one that suited my needs.
+One of the packages i tested, and uninstalled, also wanted to uninstall _All_ of KDE in teh process, claming KDE was no longer required.
+
+Obviously this bug have never really been looked at, or it would have been fixed long ago. Most likely this has not been reported as a bug, or the bug was not correctly resolved, possibly due to inadequate descrition of the bug.
+
+
+The end result is that many of us handle this feature like the plague; very carefully to avoid destruction.
+Many never use this feature, fearing it could destroy the system, prompting a reinstall.
+
+-- 
+Johnny A. Solbu
+PGP key ID: 0xFA687324
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 189 bytes
+Desc: This is a digitally signed message part.
+URL: </pipermail/mageia-dev/attachments/20120106/f02afddf/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011048.html b/zarb-ml/mageia-dev/2012-January/011048.html new file mode 100644 index 000000000..958e9ae87 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011048.html @@ -0,0 +1,134 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Balcaen John + mikala at mageia.org +
+ Fri Jan 6 18:54:23 CET 2012 +

+
+ +
Le vendredi 6 janvier 2012 14:40:25, Johnny A. Solbu a écrit :
+> On Friday 06 January 2012 16:13, Thierry Vignaud wrote:
+> > > The system has to be intelligent enough to know what is or is not an
+> > > orphan.
+> > 
+> > It is.
+> 
+> We claim that it is not.
+> 
+> > orphan packages are packages that were never directly
+> > requested/installed; they're packages that got installed because they
+> > were requested or suggested by other packages that were explicitely
+> > choosed.
+> 
+> Then why does it offer to remove packages that will Break the system, even
+> if the package was never manually requested?
+> 
+> I have experienced this my self, many years ago.
+> Back when I had MDK 9.1 I was looking for an id3 tag editor, for mp3
+> tagging. I installed one, tested it uninstalled it and tested a new one
+> untill I found one that suited my needs. One of the packages i tested, and
+> uninstalled, also wanted to uninstall _All_ of KDE in teh process, claming
+> KDE was no longer required.
+> 
+> Obviously this bug have never really been looked at, or it would have been
+> fixed long ago. Most likely this has not been reported as a bug, or the
+> bug was not correctly resolved, possibly due to inadequate descrition of
+> the bug.
+The bug is not in urpmi but in the installer phase here.
+I guess when you did encounter that you just remove task-kde from your system, 
+this one is pulling all kde deps, so when removed it's logical from urpmi to 
+consider kde deps as orphans.
+Installer should install package like kdebase4-workspace, kdebase4-runtime etc 
+etc  so you can't face the same issue by removing task-kde for example.
+(Of course it's probably more easy & they might be a reason to use task- in 
+installer instead of specific 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/2012-January/011049.html b/zarb-ml/mageia-dev/2012-January/011049.html new file mode 100644 index 000000000..2ee0b75ea --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011049.html @@ -0,0 +1,121 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Sander Lepik + sander.lepik at eesti.ee +
+ Fri Jan 6 18:55:39 CET 2012 +

+
+ +
06.01.2012 19:40, Johnny A. Solbu kirjutas:
+> On Friday 06 January 2012 16:13, Thierry Vignaud wrote:
+>>> The system has to be intelligent enough to know what is or is not an orphan.
+>> It is.
+> We claim that it is not.
+Well, the system is ok. Just some packages are probably bogus and don't require all packages 
+they need.
+> The end result is that many of us handle this feature like the plague; very carefully to avoid destruction.
+> Many never use this feature, fearing it could destroy the system, prompting a reinstall.
+Maybe at mdk9.1 it had problems. Tho' i'm not sure if urpmi even had that option at that 
+time. For me orphans are always worked. There is one thing that can cause problems - task 
+(meta) packages. For example if you remove task-kde4 then yes, you get a lot of kde packages 
+that are marked as orphans as task-kde4 pulled them in and is now uninstalled. But if some 
+package has requires on other package then this other package isn't marked as orphan.
+
+--
+Sander
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011050.html b/zarb-ml/mageia-dev/2012-January/011050.html new file mode 100644 index 000000000..27e6304e5 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011050.html @@ -0,0 +1,83 @@ + + + + [Mageia-dev] references to outside web sites/wiki + + + + + + + + + +

[Mageia-dev] references to outside web sites/wiki

+ Frank Griffin + ftg at roadrunner.com +
+ Fri Jan 6 19:00:49 CET 2012 +

+
+ +
On 01/06/2012 12:21 PM, Johnny A. Solbu wrote:
+> Thou I seriously don't believe All of the mirrors will start to remove 
+> Mandriva from their servers. Especially those who still have old 
+> releases. Some mirrors still have everything as far back as MDK 7.2. 
+> So, some mirrors will exist even if Mandriva closes down. 
+
+I doubt that Olivier Thauvin (the maintainer of distrib-coffee) would 
+get rid of them if they were of use to Mageia.
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011051.html b/zarb-ml/mageia-dev/2012-January/011051.html new file mode 100644 index 000000000..3fcc4e9f3 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011051.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] references to outside web sites/wiki + + + + + + + + + +

[Mageia-dev] references to outside web sites/wiki

+ Florian Hubold + doktor5000 at arcor.de +
+ Fri Jan 6 19:26:37 CET 2012 +

+
+ +
Am 06.01.2012 19:00, schrieb Frank Griffin:
+> On 01/06/2012 12:21 PM, Johnny A. Solbu wrote:
+>> Thou I seriously don't believe All of the mirrors will start to remove
+>> Mandriva from their servers. Especially those who still have old releases.
+>> Some mirrors still have everything as far back as MDK 7.2. So, some mirrors
+>> will exist even if Mandriva closes down. 
+>
+> I doubt that Olivier Thauvin (the maintainer of distrib-coffee) would get rid
+> of them if they were of use to Mageia.
+>
+They are, because otherwise changelogs predating 2007.1
+would be lost due to various SVN crashes.
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011052.html b/zarb-ml/mageia-dev/2012-January/011052.html new file mode 100644 index 000000000..a37f380e6 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011052.html @@ -0,0 +1,140 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Florian Hubold + doktor5000 at arcor.de +
+ Fri Jan 6 19:31:13 CET 2012 +

+
+ +
Am 06.01.2012 17:55, schrieb Colin Guthrie:
+> 'Twas brillig, and Robert Fox at 06/01/12 10:16 did gyre and gimble:
+>> After latest Cauldron updates, I got a real long list of suggested
+>> "orphans" - but I believe some of these packages are needed (like hal or
+>> basesystem-minimal) -
+>>
+>> How do I clear out the orphans - like reset the logic behind it so the
+>> correct packages will be orphaned?  Or is a fresh install in order??
+> FWIW, as I see some people not liking this feature, personally I don't
+> use --auto-orphans, but instead use "urpmq --not-available" to find
+> packages I have installed that are no longer provided by the
+> repositories. This will typically include old and unneeded library
+> majors etc. that accumulate after a while.
+>
+> This list is much clearer in what it actually outputs and is basically
+> the same as the yum orphan list command (I forget what the command
+> actually is, but it's what inspired me to write the first version which
+> in turn was vastly improved by a native implementation by (IIRC) Pascal
+> Terjan :))
+>
+> Col
+>
+>
+Interesting, now i rememeber you mentioned this already a few times.
+Will also add it to said wiki page.
+
+
+Unrelated, could anyone please comment on how rpm-find-leaves
+aka urpmi_rpm-find-leaves fits into the picture?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011053.html b/zarb-ml/mageia-dev/2012-January/011053.html new file mode 100644 index 000000000..1dd6f1807 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011053.html @@ -0,0 +1,138 @@ + + + + [Mageia-dev] [ANN] the installer stage1 now use standard pppd & pppoe + + + + + + + + + +

[Mageia-dev] [ANN] the installer stage1 now use standard pppd & pppoe

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Fri Jan 6 20:13:00 CET 2012 +

+
+ +
Hi
+
+Is there people still using PPP at install time (stage1, not the
+graphical stage2)?
+That is eg: booting boot.iso and selecting ppp/adsl after being
+offered to choose
+between installing from disk, HTTP, FTP, NFS, CD, ...
+
+I've made this stage1 using standard pppd & pppoe instead of a 10 years
+ago old snapshot.
+
+If you test it, please do test latest cauldron's boot.iso from yesterday
+
+x86_64:
+-rw-r--r--. 1 qemu     qemu     20971520 Jan  6 00:07 boot.iso
+
+
+Thanks
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011054.html b/zarb-ml/mageia-dev/2012-January/011054.html new file mode 100644 index 000000000..073ecf803 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011054.html @@ -0,0 +1,140 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Dale Huckeby + spock at evansville.net +
+ Fri Jan 6 20:06:12 CET 2012 +

+
+ +
On Fri, 6 Jan 2012, Thierry Vignaud wrote:
+
+> On 6 January 2012 15:53, LinuxBSDos.com <finid at linuxbsdos.com> wrote:
+>>> This is a well known issue.
+>>> To clear out the list you need a deep knowledge of the system to
+>>> determine which packages are really not needed anymore.
+>>>
+>>> Lately  this --auto-orphans line shreddered my whole system on a fresh
+>>> install after the first update, several system services could not
+>>> start at next reboot, applications did not run, etc. One of the very
+>>> few times I had to re-install because of a bug. Call me newbie or
+>>> pussy but until this is not a secure function I will never touch it
+>>> again.
+>>
+>> Btw, this problem is not unique to Mageia. After I hosed a Debian
+>> installation by running apt with auto-orphans, I vowed never to mess with
+>> orphans again.
+>>
+>> The system has to be intelligent enough to know what is or is not an orphan.
+>
+> It is.
+> orphan packages are packages that were never directly requested/installed;
+> they're packages that got installed because they were requested or suggested
+> by other packages that were explicitely choosed.
+> Then if you remove the package you explicitely choose, urpmi sees that the
+> packages that were requested by this one are no more required by anything
+> and since you never explicitely requested them, it offer to remove them.
+
+Evidently once I've installed package A which requests X, sometimes packages
+F, L, and T might subsequently get installed which also need X *and presumably
+would have requested it had it not already been installed*.  But when I uninstall
+A it orphans X because A is the only package that *requested* it.  When F, L,
+and T are installed can't all the packages they *would have requested* be marked
+whether or not they're already installed?  That way a package would be orphaned
+only when the last package that needs it is uninstalled?  Or am I missing
+something?
+
+Dale Huckeby
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011055.html b/zarb-ml/mageia-dev/2012-January/011055.html new file mode 100644 index 000000000..8ab7f406e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011055.html @@ -0,0 +1,119 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Fri Jan 6 20:14:27 CET 2012 +

+
+ +
On 6 January 2012 18:40, Johnny A. Solbu <cooker at solbu.net> wrote:
+>> > The system has to be intelligent enough to know what is or is not an orphan.
+>>
+>> It is.
+>
+> We claim that it is not.
+>
+>> orphan packages are packages that were never directly requested/installed;
+>> they're packages that got installed because they were requested or suggested
+>> by other packages that were explicitely choosed.
+>
+> Then why does it offer to remove packages that will Break the system, even if the package was never manually requested?
+>
+> I have experienced this my self, many years ago.
+> Back when I had MDK 9.1 I was looking for an id3 tag editor, for mp3 tagging. I installed one, tested it uninstalled it and tested a new one untill I found one that suited my needs.
+> One of the packages i tested, and uninstalled, also wanted to uninstall _All_ of KDE in teh process, claming KDE was no longer required.
+
+You understand there was NO ORPHAN SUPPORT back at this time, don't you?
+This is totally off topic...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011056.html b/zarb-ml/mageia-dev/2012-January/011056.html new file mode 100644 index 000000000..061002ed7 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011056.html @@ -0,0 +1,126 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Fri Jan 6 20:20:04 CET 2012 +

+
+ +
On 6 January 2012 18:54, Balcaen John <mikala at mageia.org> wrote:
+> The bug is not in urpmi but in the installer phase here.
+
+No.
+(Anyway the installer uses urpmi)
+
+> I guess when you did encounter that you just remove task-kde from your system,
+> this one is pulling all kde deps, so when removed it's logical from urpmi to
+> consider kde deps as orphans.
+> Installer should install package like kdebase4-workspace, kdebase4-runtime etc
+> etc  so you can't face the same issue by removing task-kde for example.
+> (Of course it's probably more easy & they might be a reason to use task- in
+> installer instead of specific package).
+
+No. the install will only install task-<desktop> or  task-<desktop>-minimal.
+If you remove  task-<desktop>, well you shoot yourself in foot, too bad for
+you.
+
+Remember that this discussion obviously manually removed basesystem
+since rpmdrake refuses to remove it for safety.
+We cannot prevent that unless we don't provide rpm so that people
+cannot shoot theirself in the foot.
+
+If people get bit because they're removing task-* or basesystem, then
+we'd better enhance the description of those packages so that people
+don't try blindly to remove them.
+
+That would be the real bug.
+
+Something like "if you remove this package, you'll lost your desktop/games/
+devel tools/..."
+We could even make rpmdrake popup big red warnings when trying
+to remove a task-XXXX package.
+
+See you
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011057.html b/zarb-ml/mageia-dev/2012-January/011057.html new file mode 100644 index 000000000..c621766f2 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011057.html @@ -0,0 +1,188 @@ + + + + [Mageia-dev] Numerous mariadb issues today. + + + + + + + + + +

[Mageia-dev] Numerous mariadb issues today.

+ Maarten Vanraes + alien at rmail.be +
+ Fri Jan 6 20:23:13 CET 2012 +

+
+ +
Op vrijdag 06 januari 2012 14:29:29 schreef Colin Guthrie:
+[...]
+> Ahh yes my my.cnf file didn't have the:
+> 
+> [mysqld_safe]
+> log-error=/var/log/mysqld/mysqld.log
+> pid-file=/var/run/mysqld/mysqld.pid
+> 
+> bits.
+> 
+> If the default my.cnf file ships with that path (don't know if it does
+> or if it's patched in our packages) then perhaps the
+> mysqld-prepare-db-dir script should also be updated to use that as the
+> default?
+
+since for ages, we ship our own my.cnf.
+
+mysql-prepare-db-dir uses the my.cnf values to get the log-error, so that's 
+already ok.
+
+[...]
+> > indeed you shouldn't use the -obsolete ones, the xtradb should nicely use
+> > your innodb database, xtradb is a innodb with extra patches, so any
+> > innodb tuning is still valid for xtradb.
+> 
+> OK, cool. As long as it still reads e.g. innodb_* from my.conf then all
+> will be well I think :)
+
+yup
+
+[...]
+> > only the load plugin should be changed into federatedx.so instead of
+> > federated.so ; the "federated" option is still valid for federatedx
+> > 
+> > getting this error, means that you don't have any of them both loaded.
+> 
+> Hmm, I thought I had tried all combinations, but I obviously didn't try
+> the ha_federatedx.so + federated option... gah, sorry about that. Still
+> the plugin name in the conf does still need updating, so at least I'm
+> not completely daft :D
+
+afaik i had a sed line that did change the federated.so in to federatedx.so in 
+the spec file ... i'll need to doublecheck...
+
+> > sadly, my.cnf is a config file, i can provide a newer my.cnf all i want,
+> > it's not like i can modify the my.cnf file for existing upgrades?
+> 
+> There are various things you can do with sed/awk on upgrades... I'd at
+> very least suggest a "sed -i 's/ha_federated\.so/ha_federatedx\.so/g'
+> /etc/my.cnf" to fix up that issue (which would prevent mysql starting...
+> looking back, that was probably the fundamental issue I had.
+
+i'm gonna relook, but it looks like this exact line is in the spec file... 
+maybe it's not in the correct section... could you by any chance look at the 
+spec file as well?, i never did a %pre and %post thing before...
+
+> > my thoughts on plugins is: "xtradb is internal, because innodb was
+> > internal; federatedx was external, because federated was external"
+> 
+> Hmm? innodb was not internal before was it? I thought it was a plugin
+> since a very long time (I pretty sure I remember panicking when Oden
+> enabled it for the first time a year or two back). Perhaps I'm wrong tho'.
+
+i don't know, i based myself on the spec file for the mysql that was in 
+cauldron.
+
+> If you do make xtradb a plugin, then I'd suggest doing a "sed -i
+> 's/ha_innodb\.so/ha_xtradb\.so/g' m/etc/my.cnf" in the %post also.
+> 
+> > can you recheck that a new my.cnf file at the very least works out of the
+> > box? and is this x86_64 or i586?
+> 
+> It doesn't. It mentions ha_federated.so as mentioned above rather than
+> ha_federatedx.so, so this needs to be fixed. This is on x86_64 but I
+> guess that doesn't matter here.
+[...]
+
+strange, maybe something is wrong with the sed line...
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011058.html b/zarb-ml/mageia-dev/2012-January/011058.html new file mode 100644 index 000000000..6c86aae6d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011058.html @@ -0,0 +1,118 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Sander Lepik + sander.lepik at eesti.ee +
+ Fri Jan 6 20:57:39 CET 2012 +

+
+ +
06.01.2012 21:06, Dale Huckeby kirjutas:
+>
+> Evidently once I've installed package A which requests X, sometimes packages
+> F, L, and T might subsequently get installed which also need X *and presumably
+> would have requested it had it not already been installed*.  But when I uninstall
+> A it orphans X because A is the only package that *requested* it.  When F, L,
+> and T are installed can't all the packages they *would have requested* be marked
+> whether or not they're already installed?  That way a package would be orphaned
+> only when the last package that needs it is uninstalled?  Or am I missing
+> something?
+This is already so. See example: http://pastebin.com/AMj87QiV - after first urpme 
+libplasmaweather4 should be marked as orphan but it's not as it's still required by other 
+package.
+
+--
+Sander
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011059.html b/zarb-ml/mageia-dev/2012-January/011059.html new file mode 100644 index 000000000..5e0d7f628 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011059.html @@ -0,0 +1,118 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Johnny A. Solbu + cooker at solbu.net +
+ Fri Jan 6 23:02:45 CET 2012 +

+
+ +
On Friday 06 January 2012 20:14, Thierry Vignaud wrote:
+> You understand there was NO ORPHAN SUPPORT back at this time, don't you?
+
+And you fail to see my point, that this has been a problem since back then. Judging by this thread it is obviously Still a problem. It has just moved into the orphan support.
+
+> This is totally off topic...
+
+Is that so?
+How on earth could an /example/ relatet to the same issiue which Still plague users be off topic?
+
+-- 
+Johnny A. Solbu
+PGP key ID: 0xFA687324
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 189 bytes
+Desc: This is a digitally signed message part.
+URL: </pipermail/mageia-dev/attachments/20120106/c3b14fd9/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011060.html b/zarb-ml/mageia-dev/2012-January/011060.html new file mode 100644 index 000000000..2a741b215 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011060.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ LinuxBSDos.com + finid at linuxbsdos.com +
+ Fri Jan 6 16:08:47 CET 2012 +

+
+ +
> On 6 January 2012 13:16, Wolfgang Bornath <molch.b at googlemail.com> wrote:
+>>>> This is just a bogus claim:
+>>>> If some apps break after removing orphan packages, they'll break too
+>>>> after manually removing such packages, meaning they lack some
+>>>> requires...
+>>>
+>>> Yes, right, I'd not remove such packages manually - they were marked
+>>> as orphans and removed by the function - which is my claim.
+>>
+>> To make it clear - my claim is that the orphan function marked
+>> packages as orphans which are needed and which I'd never remove
+>> manually. If you have a list of 100 "orphans" it is next to impossible
+>> for a normal user to sit down and check each and every package if it
+>> is really an orphan (orphan in the sense of "not needed").
+>
+> I never say you manually removed them.
+> Again, if packages break after urpme --auto-orphans, they can break
+> after manually removing packages, thus the issue is that those
+> packages lacks requires on needed components.
+>
+
+I don't think that's true. Removing a package will not remove other
+packages that it depends on, so nothing should break if you remove it.
+
+--
+Finid
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011061.html b/zarb-ml/mageia-dev/2012-January/011061.html new file mode 100644 index 000000000..723ec9608 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011061.html @@ -0,0 +1,106 @@ + + + + [Mageia-dev] references to outside web sites/wiki + + + + + + + + + +

[Mageia-dev] references to outside web sites/wiki

+ Glen Ogilvie + nelg at linuxsolutions.co.nz +
+ Fri Jan 6 23:34:58 CET 2012 +

+
+ +
On Sat, 07 Jan 2012, Michael Scherer wrote:
+> Le vendredi 06 janvier 2012 à 20:31 +1300, Glen Ogilvie a écrit :
+> > > On Wednesday, 4 January 2012 23:56:01 Romain d'Alverny wrote:
+> > > > On Wed, Jan 4, 2012 at 22:36, Johnny A. Solbu <cooker at solbu.net> 
+wrote:
+> > > > > On Wednesday 04 January 2012 21:06, Romain d'Alverny wrote:
+> > > > >> wiki.mandriva.com may be shut down for good in just a few days
+> > > > >
+> > > > > What? Are Mandriva serisouly considering closing down the Wiki?
+> > > >
+> > > > Mandriva is on the path to filing for bankruptcy on January 16th.
+> >
+> > Does anyone have a complete mirror / copy of the Mandriva svn repository,
+> > or a complete set of SRPMs from cooker?   I would be concerned this
+> > becomes unavailable, as it's a valuable resource for packages not yet
+> > imported into Mageia and contains a history of the package that Mageia
+> > does not have.
+>
+> D-C should still hold the srpm.
+
+D-C = distrib-coffee?
+
+I've grabbed my own copy of all the srpms for cooker, along with plf and the 
+new replacement for plf;  
+(ftp://mirror.yandex.ru/mandriva/official/restricted/2011.0/SRPMS/),  
+
+As I didn't know how long they would stay on the mirrors.   If anyone is 
+looking for something in the future, I'll have a copy dated 6/1/2012.
+
+Regards
+Glen Ogilvie
+
+
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011062.html b/zarb-ml/mageia-dev/2012-January/011062.html new file mode 100644 index 000000000..ea930a8d4 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011062.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Johnny A. Solbu + cooker at solbu.net +
+ Sat Jan 7 00:09:11 CET 2012 +

+
+ +
On Friday 06 January 2012 18:54, Balcaen John wrote:
+> I guess when you did encounter that you just remove task-kde from your system
+
+I did not. I should have been more clearly with my example. :-)=
+The packages in my example where all console program, that I installed and removed using urpm[ie]. So I explicitly removed only the one program I just installed. And it did not install any other packages, as a result of dependencies.
+
+And this is my point. We uninstall a specific program, not a meta/task package, which result in some packages beeing marked as orphaned, when they are infact Not orphaned.
+
+Because of this we don't trust it.
+
+-- 
+Johnny A. Solbu
+PGP key ID: 0xFA687324
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 189 bytes
+Desc: This is a digitally signed message part.
+URL: </pipermail/mageia-dev/attachments/20120107/b0979285/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011063.html b/zarb-ml/mageia-dev/2012-January/011063.html new file mode 100644 index 000000000..e958680b5 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011063.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Sat Jan 7 07:41:43 CET 2012 +

+
+ +
2012/1/6 Guillaume Rousse <guillomovitch at gmail.com>:
+> Le 06/01/2012 16:13, Wolfgang Bornath a écrit :
+>
+>> Ah, I see your reasoning, of course, if the packager forgot to name
+>> the requires then urpmi declares them as orphans. But then, to be
+>> safe, you have to forget about auto-orphans altogether because you can
+>> not be sure that all packagers did their homework.
+>
+> Then you have to forget about using packages because you're not sure
+> packagers did their work correctly.
+
+I'd argue like that as well if we were in court. But it's not the
+same: if a packager misses something and the installation does not
+work, so what? I can use another package or distribution. But if he
+causes urpmi to regard a needed package as orphan and lets me remove
+it the system can break, now that is a problem.
+
+> So far, still no one proved than 'orphan' status was wrong regarding urpmi
+> definition of what is an orphan package, rather than regarding their own
+> personal expectation.
+
+Yes, because the user does not care about any such definitions when he
+reads on the console or in rpmdrake "These packages are orphans now,
+you can safely remove them". I'd suggest to change this sentence ASAP
+into "If you are sure that it will not break anything you can remove
+them now". This would be a better advice for the user than "you can
+safely remove".
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011064.html b/zarb-ml/mageia-dev/2012-January/011064.html new file mode 100644 index 000000000..a8167d83c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011064.html @@ -0,0 +1,113 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ LinuxBSDos.com + finid at linuxbsdos.com +
+ Sat Jan 7 08:18:14 CET 2012 +

+
+ +
> 2012/1/6 Guillaume Rousse <guillomovitch at gmail.com>:
+>> Le 06/01/2012 16:13, Wolfgang Bornath a écrit :
+>>
+>>> Ah, I see your reasoning, of course, if the packager forgot to name
+>>> the requires then urpmi declares them as orphans. But then, to be
+>>> safe, you have to forget about auto-orphans altogether because you can
+>>> not be sure that all packagers did their homework.
+>>
+>> Then you have to forget about using packages because you're not sure
+>> packagers did their work correctly.
+>
+> I'd argue like that as well if we were in court. But it's not the
+> same: if a packager misses something and the installation does not
+> work, so what? I can use another package or distribution. But if he
+> causes urpmi to regard a needed package as orphan and lets me remove
+> it the system can break, now that is a problem.
+>
+>> So far, still no one proved than 'orphan' status was wrong regarding
+>> urpmi
+>> definition of what is an orphan package, rather than regarding their own
+>> personal expectation.
+>
+> Yes, because the user does not care about any such definitions when he
+> reads on the console or in rpmdrake "These packages are orphans now,
+> you can safely remove them". I'd suggest to change this sentence ASAP
+> into "If you are sure that it will not break anything you can remove
+> them now". This would be a better advice for the user than "you can
+> safely remove".
+>
+
+True that the user does not and should not care about definitions of an
+orphan, but also, the user should not be put in a situation where he/she
+will have to go hunting for what could or could not break anything.
+
+--
+finid
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011065.html b/zarb-ml/mageia-dev/2012-January/011065.html new file mode 100644 index 000000000..d0236afa5 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011065.html @@ -0,0 +1,120 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Maarten Vanraes + alien at rmail.be +
+ Sat Jan 7 08:48:43 CET 2012 +

+
+ +
Op vrijdag 06 januari 2012 13:02:26 schreef Thierry Vignaud:
+> On 6 January 2012 12:27, Wolfgang Bornath <molch.b at googlemail.com> wrote:
+> > This is a well known issue.
+> > To clear out the list you need a deep knowledge of the system to
+> > determine which packages are really not needed anymore.
+> > 
+> > Lately  this --auto-orphans line shreddered my whole system on a fresh
+> > install after the first update, several system services could not
+> > start at next reboot, applications did not run, etc. One of the very
+> > few times I had to re-install because of a bug. Call me newbie or
+> > pussy but until this is not a secure function I will never touch it
+> > again.
+> 
+> This is just a bogus claim:
+> If some apps break after removing orphan packages, they'll break too
+> after manually removing such packages, meaning they lack some
+> requires...
+
+perhaps, to instill more confidence, we could:
+
+- have only list the leaf orphans; which means of course, you can do it 
+multiple times, or maybe --recursive to give them all
+- not to list in orphan list packages which don't contain any files: ie, tasks
+- mention clearly that if they want to use some package, that they can install 
+it
+- list separately and sorted the ones with changed access times? as in, they 
+have been used since install? (unless partition is mounted noatime, of 
+course... /o\
+
+personally, orphans can break packages, but basesystem and basesystem-minimal 
+should both not be removed, perhaps we can even put on a warning if those are 
+not installed; when running --auto-orphans.
+
+perhaps a combination of these options could instill more confidence... but... 
+is it worth it???
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011066.html b/zarb-ml/mageia-dev/2012-January/011066.html new file mode 100644 index 000000000..e49db639e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011066.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Sander Lepik + sander.lepik at eesti.ee +
+ Sat Jan 7 09:42:00 CET 2012 +

+
+ +
07.01.2012 01:09, Johnny A. Solbu kirjutas:
+> On Friday 06 January 2012 18:54, Balcaen John wrote:
+>> I guess when you did encounter that you just remove task-kde from your system
+> I did not. I should have been more clearly with my example. :-)=
+> The packages in my example where all console program, that I installed and removed using urpm[ie]. So I explicitly removed only the one program I just installed. And it did not install any other packages, as a result of dependencies.
+>
+> And this is my point. We uninstall a specific program, not a meta/task package, which result in some packages beeing marked as orphaned, when they are infact Not orphaned.
+Give us command line example. Install something and remove it and then show me what got 
+orphaned if it wasn't orphan before. What you claim here doesn't sound right as i haven't 
+seen it myself.
+
+--
+Sander
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011067.html b/zarb-ml/mageia-dev/2012-January/011067.html new file mode 100644 index 000000000..34995922a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011067.html @@ -0,0 +1,134 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ ptyxs + ptyxs at free.fr +
+ Sat Jan 7 11:14:12 CET 2012 +

+
+ +
Le 06/01/2012 17:55, Colin Guthrie a écrit :
+> 'Twas brillig, and Robert Fox at 06/01/12 10:16 did gyre and gimble:
+>> After latest Cauldron updates, I got a real long list of suggested
+>> "orphans" - but I believe some of these packages are needed (like hal or
+>> basesystem-minimal) -
+>>
+>> How do I clear out the orphans - like reset the logic behind it so the
+>> correct packages will be orphaned?  Or is a fresh install in order??
+> FWIW, as I see some people not liking this feature, personally I don't
+> use --auto-orphans, but instead use "urpmq --not-available" to find
+> packages I have installed that are no longer provided by the
+> repositories. This will typically include old and unneeded library
+> majors etc. that accumulate after a while.
+>
+> This list is much clearer in what it actually outputs and is basically
+> the same as the yum orphan list command (I forget what the command
+> actually is, but it's what inspired me to write the first version which
+> in turn was vastly improved by a native implementation by (IIRC) Pascal
+> Terjan :))
+>
+> Col
+>
+>
+The problem is not 'I like it'/'I don't like it', the problem is that 
+this feature caused sometimes the loss of very important packages making 
+the system unusable and leading to a necessary reinstallation.
+
+
+-- 
+Ce courriel a été émis à partir du système d'exploitation Mandriva
+Linux
+Préférez les logiciels libres et les formats ouverts.
+LINUX ? IL Y A MOINS BIEN, MAIS... C'EST PLUS CHER !!
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011068.html b/zarb-ml/mageia-dev/2012-January/011068.html new file mode 100644 index 000000000..96fc16217 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011068.html @@ -0,0 +1,146 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ andre999 + andre999mga at laposte.net +
+ Sat Jan 7 11:18:40 CET 2012 +

+
+ +
Sander Lepik a écrit :
+> 07.01.2012 01:09, Johnny A. Solbu kirjutas:
+>> On Friday 06 January 2012 18:54, Balcaen John wrote:
+>>> I guess when you did encounter that you just remove task-kde from 
+>>> your system
+>> I did not. I should have been more clearly with my example. :-)=
+>> The packages in my example where all console program, that I 
+>> installed and removed using urpm[ie]. So I explicitly removed only 
+>> the one program I just installed. And it did not install any other 
+>> packages, as a result of dependencies.
+>>
+>> And this is my point. We uninstall a specific program, not a 
+>> meta/task package, which result in some packages beeing marked as 
+>> orphaned, when they are infact Not orphaned.
+> Give us command line example. Install something and remove it and then 
+> show me what got orphaned if it wasn't orphan before. What you claim 
+> here doesn't sound right as i haven't seen it myself.
+>
+> -- 
+> Sander
+
+It is not exactly the same thing, but in more than one occasion when I 
+installed packages with similar functions at the same time, to compare 
+them, say A, B, and C, and later uninstalled B and C, I have found A to 
+be declared an orphan.  Only to find that it had been required by one of 
+the others.
+(I often prefer command-line packages.  It is simple to add them to the 
+menu if I want.  And I have often enough made such comparisons.  To be 
+fair, I haven't done much of that since installing Mageia, when it first 
+became available.)
+
+Really though, we should consider how people work with installing software.
+
+The auto-orphans option and how it currently works is based on the 
+assumption that if package A is installed as a requirement of package B, 
+that on uninstalling B, one will want to uninstall A.  That to me is a 
+false premise.
+It is likely to be the case, but not necessarily.
+Generally users will use the graphic installer (rpmdrake), as it is more 
+convenient.  When the question of orphans is presented, if it is 
+presented, one should be presented with the same options that are 
+presented on installation with required packages.  That is, to be able 
+to query the description ("more info") of the associated packages, and 
+thus readily make an informed decision of what to remove.
+As well, the message should be that the orphaned packages "may" be no 
+longer useful, instead of saying that they can be safely removed.
+Sure, in terms of not being strictly required by other packages, they 
+can be safely removed, but if I had always followed the auto-orphan 
+advice, I would have uninstalled gnome on more than one occasion.  
+(Which is my usual desktop environment.)
+
+What is more important is what is needed for the user to be able to use 
+their computer as they wish, with the packages providing the functions 
+they wish.  In that sense, auto-orphans does indeed break systems.
+
+My 2 cents :)
+
+-- 
+André
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011069.html b/zarb-ml/mageia-dev/2012-January/011069.html new file mode 100644 index 000000000..2efdd68a1 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011069.html @@ -0,0 +1,156 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ ptyxs + ptyxs at free.fr +
+ Sat Jan 7 11:25:49 CET 2012 +

+
+ +
Le 07/01/2012 11:18, andre999 a écrit :
+> Sander Lepik a écrit :
+>> 07.01.2012 01:09, Johnny A. Solbu kirjutas:
+>>> On Friday 06 January 2012 18:54, Balcaen John wrote:
+>>>> I guess when you did encounter that you just remove task-kde from 
+>>>> your system
+>>> I did not. I should have been more clearly with my example. :-)=
+>>> The packages in my example where all console program, that I 
+>>> installed and removed using urpm[ie]. So I explicitly removed only 
+>>> the one program I just installed. And it did not install any other 
+>>> packages, as a result of dependencies.
+>>>
+>>> And this is my point. We uninstall a specific program, not a 
+>>> meta/task package, which result in some packages beeing marked as 
+>>> orphaned, when they are infact Not orphaned.
+>> Give us command line example. Install something and remove it and 
+>> then show me what got orphaned if it wasn't orphan before. What you 
+>> claim here doesn't sound right as i haven't seen it myself.
+>>
+>> -- 
+>> Sander
+>
+> It is not exactly the same thing, but in more than one occasion when I 
+> installed packages with similar functions at the same time, to compare 
+> them, say A, B, and C, and later uninstalled B and C, I have found A 
+> to be declared an orphan.  Only to find that it had been required by 
+> one of the others.
+> (I often prefer command-line packages.  It is simple to add them to 
+> the menu if I want.  And I have often enough made such comparisons.  
+> To be fair, I haven't done much of that since installing Mageia, when 
+> it first became available.)
+>
+> Really though, we should consider how people work with installing 
+> software.
+>
+> The auto-orphans option and how it currently works is based on the 
+> assumption that if package A is installed as a requirement of package 
+> B, that on uninstalling B, one will want to uninstall A.  That to me 
+> is a false premise.
+> It is likely to be the case, but not necessarily.
+> Generally users will use the graphic installer (rpmdrake), as it is 
+> more convenient.  When the question of orphans is presented, if it is 
+> presented, one should be presented with the same options that are 
+> presented on installation with required packages.  That is, to be able 
+> to query the description ("more info") of the associated packages, and 
+> thus readily make an informed decision of what to remove.
+> As well, the message should be that the orphaned packages "may" be no 
+> longer useful, instead of saying that they can be safely removed.
+> Sure, in terms of not being strictly required by other packages, they 
+> can be safely removed, but if I had always followed the auto-orphan 
+> advice, I would have uninstalled gnome on more than one occasion.  
+> (Which is my usual desktop environment.)
+>
+> What is more important is what is needed for the user to be able to 
+> use their computer as they wish, with the packages providing the 
+> functions they wish.  In that sense, auto-orphans does indeed break 
+> systems.
+>
+> My 2 cents :)
+>
++1
+
+
+-- 
+Ce courriel a été émis à partir du système d'exploitation Mandriva
+Linux
+Préférez les logiciels libres et les formats ouverts.
+LINUX ? IL Y A MOINS BIEN, MAIS... C'EST PLUS CHER !!
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011070.html b/zarb-ml/mageia-dev/2012-January/011070.html new file mode 100644 index 000000000..c8b3ae401 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011070.html @@ -0,0 +1,114 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Sander Lepik + sander.lepik at eesti.ee +
+ Sat Jan 7 11:37:16 CET 2012 +

+
+ +
07.01.2012 12:18, andre999 kirjutas:
+> It is not exactly the same thing, but in more than one occasion when I installed packages 
+> with similar functions at the same time, to compare them, say A, B, and C, and later 
+> uninstalled B and C, I have found A to be declared an orphan.  Only to find that it had 
+> been required by one of the others.
+> (I often prefer command-line packages.  It is simple to add them to the menu if I want.  
+> And I have often enough made such comparisons.  To be fair, I haven't done much of that 
+> since installing Mageia, when it first became available.)
+So what you say is:
+
+urpmi A
+urpmi B
+urpmi C
+
+urpme B C
+
+A would be orphan? Really?! Show me. I want an example!
+> The auto-orphans option and how it currently works is based on the assumption that if 
+> package A is installed as a requirement of package B, that on uninstalling B, one will 
+> want to uninstall A.  That to me is a false premise.
+You do get the point of orphans?! System has no AI. It only knows what it has to know. If 
+you still want A you would just run urpmi A and urpme --auto-orphans won't remove it! Simple 
+as that.
+
+--
+Sander
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011071.html b/zarb-ml/mageia-dev/2012-January/011071.html new file mode 100644 index 000000000..b936fa520 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011071.html @@ -0,0 +1,146 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Sat Jan 7 11:39:29 CET 2012 +

+
+ +
2012/1/7 andre999 <andre999mga at laposte.net>:
+> Sander Lepik a écrit :
+>>
+>> 07.01.2012 01:09, Johnny A. Solbu kirjutas:
+>>>
+>>> On Friday 06 January 2012 18:54, Balcaen John wrote:
+>>>>
+>>>> I guess when you did encounter that you just remove task-kde from your
+>>>> system
+>>>
+>>> I did not. I should have been more clearly with my example. :-)=
+>>> The packages in my example where all console program, that I installed
+>>> and removed using urpm[ie]. So I explicitly removed only the one program I
+>>> just installed. And it did not install any other packages, as a result of
+>>> dependencies.
+>>>
+>>> And this is my point. We uninstall a specific program, not a meta/task
+>>> package, which result in some packages beeing marked as orphaned, when they
+>>> are infact Not orphaned.
+>>
+>> Give us command line example. Install something and remove it and then
+>> show me what got orphaned if it wasn't orphan before. What you claim here
+>> doesn't sound right as i haven't seen it myself.
+>>
+>> --
+>> Sander
+>
+>
+> It is not exactly the same thing, but in more than one occasion when I
+> installed packages with similar functions at the same time, to compare them,
+> say A, B, and C, and later uninstalled B and C, I have found A to be
+> declared an orphan.  Only to find that it had been required by one of the
+> others.
+> (I often prefer command-line packages.  It is simple to add them to the menu
+> if I want.  And I have often enough made such comparisons.  To be fair, I
+> haven't done much of that since installing Mageia, when it first became
+> available.)
+>
+> Really though, we should consider how people work with installing software.
+>
+> The auto-orphans option and how it currently works is based on the
+> assumption that if package A is installed as a requirement of package B,
+> that on uninstalling B, one will want to uninstall A.  That to me is a false
+> premise.
+> It is likely to be the case, but not necessarily.
+> Generally users will use the graphic installer (rpmdrake), as it is more
+> convenient.  When the question of orphans is presented, if it is presented,
+> one should be presented with the same options that are presented on
+> installation with required packages.  That is, to be able to query the
+> description ("more info") of the associated packages, and thus readily make
+> an informed decision of what to remove.
+
+This is ok if you have 2 or 3 orphans. But it is unpractical if more
+packages are declared as orphans. As I wrote earlier, when he is
+presented with a list of 20 or even 100 "orphans" the user will
+definitely not sit down and check each package for "more info".
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011072.html b/zarb-ml/mageia-dev/2012-January/011072.html new file mode 100644 index 000000000..83e6893f7 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011072.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Thomas Backlund + tmb at mageia.org +
+ Sat Jan 7 11:59:30 CET 2012 +

+
+ +
07.01.2012 09:18, LinuxBSDos.com skrev:
+>
+> True that the user does not and should not care about definitions of an
+> orphan, but also, the user should not be put in a situation where he/she
+> will have to go hunting for what could or could not break anything.
+>
+
+Well urpme is not at fault. It's doing exactly what it's told.
+
+It cant solve packager errors. If a packager has forgot a "Requires",
+urpmi does not know that.
+
+The only things --auto-orphans has to go on is:
+1. is the package on the "keep list" such as basesystem -> dont remove.
+2. is the package required by some other package -> dont remove.
+3. is the package manually installed with urpmi/rpmdrake -> dont remove.
+4. is the package the current running kernel -> dont remove.
+
+
+So, if you find your system would be broken (or got broken) by running
+urpme --auto-orphans (or the same function in rpmdrake), and you want
+it fixed, file bug reports.
+
+And not against urpmi/rpmdrake, but the package that stopped working.
+
+--
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011073.html b/zarb-ml/mageia-dev/2012-January/011073.html new file mode 100644 index 000000000..bd3b4e480 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011073.html @@ -0,0 +1,119 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Sat Jan 7 12:39:07 CET 2012 +

+
+ +
2012/1/7 Thomas Backlund <tmb at mageia.org>:
+> 07.01.2012 09:18, LinuxBSDos.com skrev:
+>>
+>>
+>> True that the user does not and should not care about definitions of an
+>> orphan, but also, the user should not be put in a situation where he/she
+>> will have to go hunting for what could or could not break anything.
+>>
+>
+> Well urpme is not at fault. It's doing exactly what it's told.
+>
+> It cant solve packager errors. If a packager has forgot a "Requires",
+> urpmi does not know that.
+>
+> The only things --auto-orphans has to go on is:
+> 1. is the package on the "keep list" such as basesystem -> dont remove.
+> 2. is the package required by some other package -> dont remove.
+> 3. is the package manually installed with urpmi/rpmdrake -> dont remove.
+> 4. is the package the current running kernel -> dont remove.
+>
+>
+> So, if you find your system would be broken (or got broken) by running
+> urpme --auto-orphans (or the same function in rpmdrake), and you want
+> it fixed, file bug reports.
+>
+> And not against urpmi/rpmdrake, but the package that stopped working.
+
+Of course this is one way to find bugs in packages. But what about the
+documented (in German) case where
+ - after fresh installation, reboot (ok) and updates right after
+installation I was presented with a list of more than 100 "orphans".
+ - I ran 'urpme --auto-orphans' and rebooted
+ - several system services (which started successfully after
+installation) refused to start now because of missing files
+
+Of course urpmi was not the culprit because it only checks
+dependencies. But that did matter in that situation. The auto-orphans
+function obviously listed packages which may have no dependencies but
+are needed by the system. That's why I do not complain about urpmi but
+about the whole function. As long as this function is only based on
+package dependencies it is not safe to use it.
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011074.html b/zarb-ml/mageia-dev/2012-January/011074.html new file mode 100644 index 000000000..65b299ddd --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011074.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Sat Jan 7 12:41:16 CET 2012 +

+
+ +
2012/1/7 Wolfgang Bornath <molch.b at googlemail.com>:
+>
+> Of course this is one way to find bugs in packages. But what about the
+> documented (in German) case where
+
+Sorry, "documented" is not the correct word. I could not document it
+with logs or namng of files. I only stated what I did and what it
+resulted to.
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011075.html b/zarb-ml/mageia-dev/2012-January/011075.html new file mode 100644 index 000000000..12d9365ea --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011075.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Sander Lepik + sander.lepik at eesti.ee +
+ Sat Jan 7 12:43:09 CET 2012 +

+
+ +
07.01.2012 13:39, Wolfgang Bornath kirjutas:
+> Of course this is one way to find bugs in packages. But what about the
+> documented (in German) case where
+>   - after fresh installation, reboot (ok) and updates right after
+> installation I was presented with a list of more than 100 "orphans".
+>   - I ran 'urpme --auto-orphans' and rebooted
+>   - several system services (which started successfully after
+> installation) refused to start now because of missing files
+>
+> Of course urpmi was not the culprit because it only checks
+> dependencies. But that did matter in that situation. The auto-orphans
+> function obviously listed packages which may have no dependencies but
+> are needed by the system. That's why I do not complain about urpmi but
+> about the whole function. As long as this function is only based on
+> package dependencies it is not safe to use it.
+Did you choose custom install and unchecked some options? Or did you use LiveCD maybe? 
+Anyway.. function is not to blame. Next time copy those packages that are going to be 
+uninstalled. And they can be rechecked. Which are needed and why they get orphaned.
+
+--
+Sander
+
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011076.html b/zarb-ml/mageia-dev/2012-January/011076.html new file mode 100644 index 000000000..c0e5a4acd --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011076.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Johnny A. Solbu + cooker at solbu.net +
+ Sat Jan 7 13:11:43 CET 2012 +

+
+ +
On Saturday 07 January 2012 09:42, Sander Lepik wrote:
+> Give us command line example. Install something and remove it and then show me what got 
+> orphaned if it wasn't orphan before. What you claim here doesn't sound right as i haven't 
+> seen it myself.
+
+I'll do that next time I come across it.
+The example from way back in MDK 9.1 is the example I remember from the top of my head, simply because it wanted to uninstall my entire graphical system.
+
+-- 
+Johnny A. Solbu
+PGP key ID: 0xFA687324
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 189 bytes
+Desc: This is a digitally signed message part.
+URL: </pipermail/mageia-dev/attachments/20120107/f50fe64e/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011077.html b/zarb-ml/mageia-dev/2012-January/011077.html new file mode 100644 index 000000000..6c75bc956 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011077.html @@ -0,0 +1,142 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ andre999 + andre999mga at laposte.net +
+ Sat Jan 7 13:23:48 CET 2012 +

+
+ +
Sander Lepik a écrit :
+> 07.01.2012 12:18, andre999 kirjutas:
+>> It is not exactly the same thing, but in more than one occasion when 
+>> I installed packages with similar functions at the same time, to 
+>> compare them, say A, B, and C, and later uninstalled B and C, I have 
+>> found A to be declared an orphan.  Only to find that it had been 
+>> required by one of the others.
+>> (I often prefer command-line packages.  It is simple to add them to 
+>> the menu if I want.  And I have often enough made such comparisons.  
+>> To be fair, I haven't done much of that since installing Mageia, when 
+>> it first became available.)
+> So what you say is:
+>
+> urpmi A
+> urpmi B
+> urpmi C
+
+Not at all.  That is installing A, B, and C sequentially, one after the 
+other.
+Using urpmi, installing at the same time would be
+
+urpmi A B C
+
+Although I'm not sure that it would work the same as rpmdrake, which I 
+use so as to more easily select and install packages with similar functions.
+I'm sure that most users with similar considerations would do the same.
+Of course if one is involved in developing or testing packages, urpmi is 
+convenient, but otherwise a graphical interface like rpmdrake is easier.
+>
+> urpme B C
+>
+> A would be orphan? Really?! Show me. I want an example!
+
+Not your example.  But that is not what I said.
+
+>> The auto-orphans option and how it currently works is based on the 
+>> assumption that if package A is installed as a requirement of package 
+>> B, that on uninstalling B, one will want to uninstall A.  That to me 
+>> is a false premise.
+> You do get the point of orphans?! System has no AI. It only knows what 
+> it has to know. If you still want A you would just run urpmi A and 
+> urpme --auto-orphans won't remove it! Simple as that.
+
+I understand very well the concept.  My point is that, in terms of what 
+users can reasonably expect to happen, and how auto-orphans is applied, 
+the concept is flawed.
+Telling users that it is safe to remove identified "orphans", where the 
+expected functioning of their system can be seriously impacted, is 
+simply not appropriate.
+(One could say not very "user-friendly".)
+
+BTW, the solution to remove the auto-orphan message for a package, a 
+feigned install of an already installed package, is rather obtuse, to 
+say the least.
+>
+> -- 
+> Sander
+>
+-- 
+André
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011078.html b/zarb-ml/mageia-dev/2012-January/011078.html new file mode 100644 index 000000000..305b0d385 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011078.html @@ -0,0 +1,121 @@ + + + + [Mageia-dev] imported .src.rpm / .spec attribution + + + + + + + + + +

[Mageia-dev] imported .src.rpm / .spec attribution

+ Florent Monnier + monnier.florent at gmail.com +
+ Sat Jan 7 13:23:10 CET 2012 +

+
+ +
Hi,
+
+In Mandriva I was using this command to make proper attribution of imported 
+.spec files:
+
+$ mdvsys import foo.src.rpm --message 'this spec file is imported from Fedora 
+where it was written by X'
+
+I'm trying to make the equivalent with this command:
+
+$ mgarepo putsrpm -m "this spec file is imported from Mandriva where it was 
+written by X" package.src.rpm
+error: no such option: -m
+
+$ mgarepo putsrpm --message "this spec file is imported from Mandriva where it 
+was written by X" package.src.rpm
+error: no such option: --message
+
+$ mgarepo putsrpm --help | grep -- -m
+    -m LOG  Log message used when commiting changes
+
+What is the right command line to achieve this?
+
+Thanks
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011079.html b/zarb-ml/mageia-dev/2012-January/011079.html new file mode 100644 index 000000000..fdce76498 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011079.html @@ -0,0 +1,112 @@ + + + + [Mageia-dev] Alpha3 release notes + + + + + + + + + +

[Mageia-dev] Alpha3 release notes

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Sat Jan 7 13:40:44 CET 2012 +

+
+ +
Hi all,
+
+please do have a look at the alpha3 release notes:
+https://wiki.mageia.org/en/Mageia_2_alpha3 and fix/complete them. By
+keeping them up to date during the alpha/beta/rc phases we will
+finally have some nice release notes for Mageia2.
+
+It really only takes a few minutes for everyone...
+
+Oliver
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011080.html b/zarb-ml/mageia-dev/2012-January/011080.html new file mode 100644 index 000000000..20d5d0bf2 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011080.html @@ -0,0 +1,132 @@ + + + + [Mageia-dev] imported .src.rpm / .spec attribution + + + + + + + + + +

[Mageia-dev] imported .src.rpm / .spec attribution

+ Luc Menut + lmenut at free.fr +
+ Sat Jan 7 13:58:05 CET 2012 +

+
+ +
Le 07/01/2012 13:23, Florent Monnier a écrit :
+> Hi,
+>
+> In Mandriva I was using this command to make proper attribution of imported
+> .spec files:
+>
+> $ mdvsys import foo.src.rpm --message 'this spec file is imported from Fedora
+> where it was written by X'
+>
+> I'm trying to make the equivalent with this command:
+>
+> $ mgarepo putsrpm -m "this spec file is imported from Mandriva where it was
+> written by X" package.src.rpm
+> error: no such option: -m
+>
+> $ mgarepo putsrpm --message "this spec file is imported from Mandriva where it
+> was written by X" package.src.rpm
+> error: no such option: --message
+>
+> $ mgarepo putsrpm --help | grep -- -m
+>      -m LOG  Log message used when commiting changes
+>
+> What is the right command line to achieve this?
+>
+
+Can you try mgarepo putsrpm -l LOG ... ?
+
+Could you please file a bugreport?
+
+regards,
+Luc
+
+
+-- 
+Luc Menut
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011081.html b/zarb-ml/mageia-dev/2012-January/011081.html new file mode 100644 index 000000000..32b49eb3e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011081.html @@ -0,0 +1,116 @@ + + + + [Mageia-dev] Alpha3 release notes + + + + + + + + + +

[Mageia-dev] Alpha3 release notes

+ Maarten Vanraes + alien at rmail.be +
+ Sat Jan 7 14:34:39 CET 2012 +

+
+ +
Op zaterdag 07 januari 2012 13:40:44 schreef Oliver Burger:
+> Hi all,
+> 
+> please do have a look at the alpha3 release notes:
+> https://wiki.mageia.org/en/Mageia_2_alpha3 and fix/complete them. By
+> keeping them up to date during the alpha/beta/rc phases we will
+> finally have some nice release notes for Mageia2.
+> 
+> It really only takes a few minutes for everyone...
+> 
+> Oliver
+
+i updated https://wiki.mageia.org/en/Mageia_2_alpha3#Databases
+
+is this sort of what you want? or is it too much?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011082.html b/zarb-ml/mageia-dev/2012-January/011082.html new file mode 100644 index 000000000..adbd7df57 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011082.html @@ -0,0 +1,126 @@ + + + + [Mageia-dev] imported .src.rpm / .spec attribution + + + + + + + + + +

[Mageia-dev] imported .src.rpm / .spec attribution

+ Maarten Vanraes + alien at rmail.be +
+ Sat Jan 7 14:36:28 CET 2012 +

+
+ +
Op zaterdag 07 januari 2012 13:23:10 schreef Florent Monnier:
+> Hi,
+> 
+> In Mandriva I was using this command to make proper attribution of imported
+> .spec files:
+> 
+> $ mdvsys import foo.src.rpm --message 'this spec file is imported from
+> Fedora where it was written by X'
+> 
+> I'm trying to make the equivalent with this command:
+> 
+> $ mgarepo putsrpm -m "this spec file is imported from Mandriva where it was
+> written by X" package.src.rpm
+> error: no such option: -m
+> 
+> $ mgarepo putsrpm --message "this spec file is imported from Mandriva where
+> it was written by X" package.src.rpm
+> error: no such option: --message
+> 
+> $ mgarepo putsrpm --help | grep -- -m
+>     -m LOG  Log message used when commiting changes
+> 
+> What is the right command line to achieve this?
+> 
+> Thanks
+
+i thought "mgarepo import file.src.rpm" was what was done? and not putsrpm?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011083.html b/zarb-ml/mageia-dev/2012-January/011083.html new file mode 100644 index 000000000..77d29f29a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011083.html @@ -0,0 +1,125 @@ + + + + [Mageia-dev] Alpha3 release notes + + + + + + + + + +

[Mageia-dev] Alpha3 release notes

+ Thomas Backlund + tmb at mageia.org +
+ Sat Jan 7 14:40:35 CET 2012 +

+
+ +
Maarten Vanraes skrev 7.1.2012 15:34:
+> Op zaterdag 07 januari 2012 13:40:44 schreef Oliver Burger:
+>> Hi all,
+>>
+>> please do have a look at the alpha3 release notes:
+>> https://wiki.mageia.org/en/Mageia_2_alpha3 and fix/complete them. By
+>> keeping them up to date during the alpha/beta/rc phases we will
+>> finally have some nice release notes for Mageia2.
+>>
+>> It really only takes a few minutes for everyone...
+>>
+>> Oliver
+>
+> i updated https://wiki.mageia.org/en/Mageia_2_alpha3#Databases
+>
+> is this sort of what you want? or is it too much?
+
+
+I would replace "an as of yet unreleased MariaDB 5.5.18"
+
+with "MariaDB 5.5.18 prerelease"
+
+--
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011084.html b/zarb-ml/mageia-dev/2012-January/011084.html new file mode 100644 index 000000000..8a7b0a5b7 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011084.html @@ -0,0 +1,106 @@ + + + + [Mageia-dev] imported .src.rpm / .spec attribution + + + + + + + + + +

[Mageia-dev] imported .src.rpm / .spec attribution

+ Luc Menut + lmenut at free.fr +
+ Sat Jan 7 14:51:20 CET 2012 +

+
+ +
Le 07/01/2012 14:36, Maarten Vanraes a écrit :
+> i thought "mgarepo import file.src.rpm" was what was done? and not putsrpm?
+
+it's exactly the same command; import is an alias for putsrpm.
+    command_aliases = {"import": "putsrpm"}
+
+-- 
+Luc Menut
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011085.html b/zarb-ml/mageia-dev/2012-January/011085.html new file mode 100644 index 000000000..a777cf3f4 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011085.html @@ -0,0 +1,132 @@ + + + + [Mageia-dev] imported .src.rpm / .spec attribution + + + + + + + + + +

[Mageia-dev] imported .src.rpm / .spec attribution

+ Florent Monnier + monnier.florent at gmail.com +
+ Sat Jan 7 14:53:59 CET 2012 +

+
+ +
Le samedi 07 janvier 2012 13:58:05, Luc Menut a écrit :
+> Le 07/01/2012 13:23, Florent Monnier a écrit :
+> > Hi,
+> > 
+> > In Mandriva I was using this command to make proper attribution of
+> > imported .spec files:
+> > 
+> > $ mdvsys import foo.src.rpm --message 'this spec file is imported from
+> > Fedora where it was written by X'
+> > 
+> > I'm trying to make the equivalent with this command:
+> > 
+> > $ mgarepo putsrpm -m "this spec file is imported from Mandriva where it
+> > was written by X" package.src.rpm
+> > error: no such option: -m
+> > 
+> > $ mgarepo putsrpm --message "this spec file is imported from Mandriva
+> > where it was written by X" package.src.rpm
+> > error: no such option: --message
+> > 
+> > $ mgarepo putsrpm --help | grep -- -m
+> > 
+> >      -m LOG  Log message used when commiting changes
+> > 
+> > What is the right command line to achieve this?
+> 
+> Can you try mgarepo putsrpm -l LOG ... ?
+
+Yes it does work, thanks
+
+> Could you please file a bugreport?
+
+Is this right?
+https://bugs.mageia.org/show_bug.cgi?id=4053
+
+-- 
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011086.html b/zarb-ml/mageia-dev/2012-January/011086.html new file mode 100644 index 000000000..12551c2f0 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011086.html @@ -0,0 +1,128 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Sat Jan 7 15:24:35 CET 2012 +

+
+ +
2012/1/7 Sander Lepik <sander.lepik at eesti.ee>:
+> 07.01.2012 13:39, Wolfgang Bornath kirjutas:
+>>
+>> Of course this is one way to find bugs in packages. But what about the
+>> documented (in German) case where
+>>  - after fresh installation, reboot (ok) and updates right after
+>> installation I was presented with a list of more than 100 "orphans".
+>>  - I ran 'urpme --auto-orphans' and rebooted
+>>  - several system services (which started successfully after
+>> installation) refused to start now because of missing files
+>>
+>> Of course urpmi was not the culprit because it only checks
+>> dependencies. But that did matter in that situation. The auto-orphans
+>> function obviously listed packages which may have no dependencies but
+>> are needed by the system. That's why I do not complain about urpmi but
+>> about the whole function. As long as this function is only based on
+>> package dependencies it is not safe to use it.
+>
+> Did you choose custom install and unchecked some options? Or did you use
+> LiveCD maybe? Anyway.. function is not to blame. Next time copy those
+> packages that are going to be uninstalled. And they can be rechecked. Which
+> are needed and why they get orphaned.
+
+Used the full DVD (32-bit) Mageia 2 Alpha 2
+ - minimal install with X
+ - after installation and reboot everything was ok
+ - setup the package media (dedicated mirror) and did 'urpmi -auto-update'
+ - I did NOT install or remove one single package manually
+ - after that urpmi showed a list of more than 100 orphans
+ - used 'urpme -auto-orphans
+ - at reboot the start messages showed several errors concerning
+crond, network-up, postfix, display manager, etc. - system start
+stopped before x was started. Repeated the boot process with same
+result.
+
+A side question is why I got so many orphans in a minimal system with
+only around 700 packages in total and only around 2 or 3 dozens of
+updates (all this happened not long after Alpha 2 release.)
+
+Of course urpmi is not the culprit, it is the shortcomings of the
+function as it is. It should just not be there if its use could lead
+to such behavior, no matter where the cause comes from. Simply said: a
+gasoline brand should not be sold if it could do damage to the car's
+motor, no matter which of the components of the fluid causes the
+damage..
+
+Anyhow, I will repeat the same operation when Alpha 2 is released in a
+couple of days and as soon as the system shows orphans I will document
+that list and (if the same problem arises) dmesg output if available.
+What else do you need for a reasonable documentation?
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011087.html b/zarb-ml/mageia-dev/2012-January/011087.html new file mode 100644 index 000000000..b38b6111e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011087.html @@ -0,0 +1,84 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Sander Lepik + sander.lepik at eesti.ee +
+ Sat Jan 7 15:39:58 CET 2012 +

+
+ +
07.01.2012 16:24, Wolfgang Bornath kirjutas:
+>
+> Used the full DVD (32-bit) Mageia 2 Alpha 2
+>   - minimal install with X
+How? AFAIK this is not one of the default options.
+
+--
+Sander
+
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011088.html b/zarb-ml/mageia-dev/2012-January/011088.html new file mode 100644 index 000000000..a66fc16fb --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011088.html @@ -0,0 +1,113 @@ + + + + [Mageia-dev] [packages-commits] [192938] wxGTK2.8-devel + + + + + + + + + +

[Mageia-dev] [packages-commits] [192938] wxGTK2.8-devel

+ Jani Välimaa + jani.valimaa at gmail.com +
+ Sat Jan 7 15:57:33 CET 2012 +

+
+ +
2012/1/7  <root at mageia.org>:
+> Revision 192938 Author blue_prawn Date 2012-01-07 15:42:20 +0100 (Sat, 07
+> Jan 2012)
+>
+> Log Message
+>
+> wxGTK2.8-devel
+>
+
+Aand what did you do with wxGTK2.8-devel? This doesn't explain it at
+all. Changelog entry must be more descriptive, like "wgGTK2.8-devel
+was renamed to wxgtk2.8-devel".
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011089.html b/zarb-ml/mageia-dev/2012-January/011089.html new file mode 100644 index 000000000..66d84c6c3 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011089.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Sat Jan 7 16:09:18 CET 2012 +

+
+ +
2012/1/7 Sander Lepik <sander.lepik at eesti.ee>:
+> 07.01.2012 16:24, Wolfgang Bornath kirjutas:
+>>
+>>
+>> Used the full DVD (32-bit) Mageia 2 Alpha 2
+>>  - minimal install with X
+>
+> How? AFAIK this is not one of the default options.
+
+It is.
+1. Select "Custom" at the DE selection
+2. Unmark all package groups
+3. Up comes a selection of 4 options:
+ - minimal with x
+ - minimal without x
+ - truely minimal (only base system
+ - minimal with documentation (which is an option you can select
+together with one of the first 2.
+
+So, yes, it is a defined set of packages. That's why I used it.
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011090.html b/zarb-ml/mageia-dev/2012-January/011090.html new file mode 100644 index 000000000..5794988c8 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011090.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Sander Lepik + sander.lepik at eesti.ee +
+ Sat Jan 7 16:30:04 CET 2012 +

+
+ +
07.01.2012 17:09, Wolfgang Bornath kirjutas:
+> 2012/1/7 Sander Lepik<sander.lepik at eesti.ee>:
+>> 07.01.2012 16:24, Wolfgang Bornath kirjutas:
+>>>
+>>> Used the full DVD (32-bit) Mageia 2 Alpha 2
+>>>   - minimal install with X
+>> How? AFAIK this is not one of the default options.
+> It is.
+> 1. Select "Custom" at the DE selection
+> 2. Unmark all package groups
+> 3. Up comes a selection of 4 options:
+>   - minimal with x
+>   - minimal without x
+>   - truely minimal (only base system
+>   - minimal with documentation (which is an option you can select
+> together with one of the first 2.
+>
+> So, yes, it is a defined set of packages. That's why I used it.
+Ok, next time if you test, do the same. But before removing orphans copy them for later 
+debugging.
+
+--
+Sander
+
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011091.html b/zarb-ml/mageia-dev/2012-January/011091.html new file mode 100644 index 000000000..647398be9 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011091.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] Alpha3 release notes + + + + + + + + + +

[Mageia-dev] Alpha3 release notes

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Sat Jan 7 16:40:35 CET 2012 +

+
+ +
2012/1/7 Thomas Backlund <tmb at mageia.org>:
+> Maarten Vanraes skrev 7.1.2012 15:34:
+>
+>> i updated https://wiki.mageia.org/en/Mageia_2_alpha3#Databases
+>>
+>> is this sort of what you want? or is it too much?
+> I would replace "an as of yet unreleased MariaDB 5.5.18"
+> with "MariaDB 5.5.18 prerelease"
+
+I rewrote it a bit.
+
+@ all: please look especially at those parts without any content and
+complete them :)
+
+Oliver
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011092.html b/zarb-ml/mageia-dev/2012-January/011092.html new file mode 100644 index 000000000..b5e73112f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011092.html @@ -0,0 +1,226 @@ + + + + [Mageia-dev] Interesting issue after kernel update (Error 18) + + + + + + + + + +

[Mageia-dev] Interesting issue after kernel update (Error 18)

+ Michel Catudal + michelcatudal at gmail.com +
+ Sat Jan 7 16:51:13 CET 2012 +

+
+ +
After a reboot the I get an Error 18 message telling me that the Selected Cylinder exceeds the maximum supported by the bios.
+I then assumed that the new kernel must be crap and tried to use the previous kernel and got the same error message.
+
+My system is a bit odd that the bios sees the drives in the wrong order.
+
+I have 3 2TB drives, The first 2 drives have Linux stuff installed and the 3rd drive has eComStation (OS/2) seen as HPFS/NTFS under Linux.
+The bios as showned by my bootloader sees it as drive 0-2-1 instead 0f 0-1-2. Grub sees it the same way, but linux sees it in the correct order.
+
+Mageia is installed on the second drive as you can see, correctly identified as sdb
+
+[root at localhost grub]# df
+Sys. de fichiers    Taille  Uti. Disp. Uti% Monté sur
+/dev/sdb9             493G  326G  142G  70% /
+/dev/sdb3             136M   43M   86M  34% /boot
+/dev/sdb10            354G   27G  310G   8% /home/michel/vm_files
+
+What I found was that the installer of the new kernel scrapped my menu.lst file, I fixed it with an editor while booted on Scientific Linux.
+This may explain why when I installed Mageia that grub would not work and I had to set grub correctly.
+To get Mageia to work after the installation I had to first boot on Scientific Linux, I added a boot block in SL6 menu.lst and booted on Mageia
+I then fixed menu.lst and rebooted, everything was cool then. When I updated the kernel it messed up and I could no longer boot on Mageia.
+I must have forgotten as I got burned by the same screw up this morning.
+
+Here is the content of the menu.lst file prior to the upgrade followed by the one after the upgrade, notice that the installer changed the drive information by mistake. It didn't change the boot for Centos and Scientific Linux.
+
+I would think that there should be a way for the Mageia installer (and grub) to know when what the bios thinks and what is real match.
+As to why the bios gets the wrong order of the drives, I am not sure. Maybe it has a hard time with the OS/2 partitions. I had similar issues when I put a vista drive of a friend in my computer. her Dell was shot and I had to recover tons of pictures for her.
+
+--------------------------------------------------------------------------------------------------------------------------------------------------
+
+timeout 10
+color black/cyan yellow/cyan
+default 0
+
+title 2.6.38.8-server-8.mga
+kernel (hd2,2)/vmlinuz-2.6.38.8-server-8.mga BOOT_IMAGE=2.6.38.8-server-8.mga root=UUID=69fa904e-c5d1-461d-851f-4b8f5c3fae6a nokmsboot resume=UUID=0ca4e00e-69be-4824-be88-f457951aa974 splash=0 selinux=0 vga=788
+initrd (hd2,2)/initrd-2.6.38.8-server-8.mga.img
+
+title 2.6.38.8-server-6.mga
+kernel (hd2,2)/vmlinuz-2.6.38.8-server-6.mga BOOT_IMAGE=2.6.38.8-server-6.mga root=UUID=69fa904e-c5d1-461d-851f-4b8f5c3fae6a nokmsboot resume=UUID=0ca4e00e-69be-4824-be88-f457951aa974 splash=0 vga=788
+initrd (hd2,2)/initrd-2.6.38.8-server-6.mga.img
+
+title linux
+kernel (hd2,2)/vmlinuz BOOT_IMAGE=linux root=UUID=69fa904e-c5d1-461d-851f-4b8f5c3fae6a nokmsboot resume=UUID=0ca4e00e-69be-4824-be88-f457951aa974 splash=0 selinux=0 vga=788
+initrd (hd2,2)/initrd.img
+
+title linux-nonfb
+kernel (hd2,2)/vmlinuz BOOT_IMAGE=linux-nonfb root=UUID=69fa904e-c5d1-461d-851f-4b8f5c3fae6a nokmsboot resume=UUID=0ca4e00e-69be-4824-be88-f457951aa974
+initrd (hd2,2)/initrd.img
+
+title failsafe
+kernel (hd2,2)/vmlinuz BOOT_IMAGE=failsafe root=UUID=69fa904e-c5d1-461d-851f-4b8f5c3fae6a failsafe
+initrd (hd2,2)/initrd.img
+
+title 2.6.38.7-server-1.mga
+kernel (hd2,2)/vmlinuz-2.6.38.7-server-1.mga BOOT_IMAGE=2.6.38.7-server-1.mga root=UUID=69fa904e-c5d1-461d-851f-4b8f5c3fae6a nokmsboot resume=UUID=0ca4e00e-69be-4824-be88-f457951aa974 splash=silent vga=788
+initrd (hd2,2)/initrd-2.6.38.7-server-1.mga.img
+
+title 2.6.38.8-server-6.mga
+kernel (hd2,2)/vmlinuz-2.6.38.8-server-6.mga BOOT_IMAGE=2.6.38.8-server-6.mga root=UUID=69fa904e-c5d1-461d-851f-4b8f5c3fae6a nokmsboot resume=UUID=0ca4e00e-69be-4824-be88-f457951aa974 splash=silent vga=788
+initrd (hd2,2)/initrd-2.6.38.8-server-6.mga.img
+
+title Centos Linux (2.6.32-131.12.1.el6.x86_64)
+     root (hd2,1)
+     kernel /vmlinuz-2.6.32-131.12.1.el6.x86_64 ro root=UUID=66b960ab-2013-4e86-9ea0-b9d94618394c rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=fr_FR.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=cf  rhgb selinux=0 crashkernel=auto 
+nouveau.modeset=0 rdblacklist=nouveau vga=0x37D
+     initrd /initramfs-2.6.32-131.12.1.el6.x86_64.img
+
+title Scientific Linux (2.6.32-131.6.1.el6.x86_64)
+     root (hd2,0)
+     kernel /vmlinuz-2.6.32-131.6.1.el6.x86_64 ro root=UUID=6acb0018-50dc-4e19-8035-cc3e68c05d83 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=fr_FR.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=cf nomodeset crashkernel=128M rhgb quiet selinux=0 
+nouveau.modeset=0 rdblacklist=nouveau
+     initrd /initramfs-2.6.32-131.6.1.el6.x86_64.img
+----------------------------------------------------------------------------------------------------------------------------------------------------------------
+
+timeout 10
+color black/cyan yellow/cyan
+default 0
+
+title 2.6.38.8-server-8.mga
+kernel (hd1,2)/vmlinuz-2.6.38.8-server-8.mga BOOT_IMAGE=2.6.38.8-server-8.mga root=UUID=69fa904e-c5d1-461d-851f-4b8f5c3fae6a nokmsboot resume=UUID=0ca4e00e-69be-4824-be88-f457951aa974 splash=0 selinux=0 vga=788
+initrd (hd1,2)/initrd-2.6.38.8-server-8.mga.img
+
+title 2.6.38.8-server-6.mga
+kernel (hd1,2)/vmlinuz-2.6.38.8-server-6.mga BOOT_IMAGE=2.6.38.8-server-6.mga root=UUID=69fa904e-c5d1-461d-851f-4b8f5c3fae6a nokmsboot resume=UUID=0ca4e00e-69be-4824-be88-f457951aa974 splash=0 vga=788
+initrd (hd1,2)/initrd-2.6.38.8-server-6.mga.img
+
+title linux
+kernel (hd1,2)/vmlinuz BOOT_IMAGE=linux root=UUID=69fa904e-c5d1-461d-851f-4b8f5c3fae6a nokmsboot resume=UUID=0ca4e00e-69be-4824-be88-f457951aa974 splash=0 selinux=0 vga=788
+initrd (hd1,2)/initrd.img
+
+title linux-nonfb
+kernel (hd1,2)/vmlinuz BOOT_IMAGE=linux-nonfb root=UUID=69fa904e-c5d1-461d-851f-4b8f5c3fae6a nokmsboot resume=UUID=0ca4e00e-69be-4824-be88-f457951aa974
+initrd (hd1,2)/initrd.img
+
+title failsafe
+kernel (hd1,2)/vmlinuz BOOT_IMAGE=failsafe root=UUID=69fa904e-c5d1-461d-851f-4b8f5c3fae6a failsafe
+initrd (hd1,2)/initrd.img
+
+title 2.6.38.7-server-1.mga
+kernel (hd1,2)/vmlinuz-2.6.38.7-server-1.mga BOOT_IMAGE=2.6.38.7-server-1.mga root=UUID=69fa904e-c5d1-461d-851f-4b8f5c3fae6a nokmsboot resume=UUID=0ca4e00e-69be-4824-be88-f457951aa974 splash=silent vga=788
+initrd (hd1,2)/initrd-2.6.38.7-server-1.mga.img
+
+title 2.6.38.8-server-6.mga
+kernel (hd1,2)/vmlinuz-2.6.38.8-server-6.mga BOOT_IMAGE=2.6.38.8-server-6.mga root=UUID=69fa904e-c5d1-461d-851f-4b8f5c3fae6a nokmsboot resume=UUID=0ca4e00e-69be-4824-be88-f457951aa974 splash=silent vga=788
+initrd (hd1,2)/initrd-2.6.38.8-server-6.mga.img
+
+title Centos Linux (2.6.32-131.12.1.el6.x86_64)
+     root (hd2,1)
+     kernel /vmlinuz-2.6.32-131.12.1.el6.x86_64 ro root=UUID=66b960ab-2013-4e86-9ea0-b9d94618394c rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=fr_FR.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=cf  rhgb selinux=0 crashkernel=auto 
+nouveau.modeset=0 rdblacklist=nouveau vga=0x37D
+     initrd /initramfs-2.6.32-131.12.1.el6.x86_64.img
+
+
+title Scientific Linux (2.6.32-131.6.1.el6.x86_64)
+     root (hd2,0)
+     kernel /vmlinuz-2.6.32-131.6.1.el6.x86_64 ro root=UUID=6acb0018-50dc-4e19-8035-cc3e68c05d83 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=fr_FR.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=cf nomodeset crashkernel=128M rhgb quiet selinux=0 
+nouveau.modeset=0 rdblacklist=nouveau
+     initrd /initramfs-2.6.32-131.6.1.el6.x86_64.img
+
+title 2.6.38.8-server-9.mga
+kernel (hd1,2)/vmlinuz-2.6.38.8-server-9.mga BOOT_IMAGE=2.6.38.8-server-9.mga root=UUID=69fa904e-c5d1-461d-851f-4b8f5c3fae6a nokmsboot resume=UUID=0ca4e00e-69be-4824-be88-f457951aa974 splash=0 selinux=0 vga=788
+initrd (hd1,2)/initrd-2.6.38.8-server-9.mga.img
+
+
+-- 
+For OS/2 and Linux Software visit
+http://home.comcast.net/~mcatudal
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011093.html b/zarb-ml/mageia-dev/2012-January/011093.html new file mode 100644 index 000000000..4f5ad45f4 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011093.html @@ -0,0 +1,82 @@ + + + + [Mageia-dev] references to outside web sites/wiki + + + + + + + + + +

[Mageia-dev] references to outside web sites/wiki

+ David Walser + luigiwalser at yahoo.com +
+ Sat Jan 7 17:14:22 CET 2012 +

+
+ +
Wolfgang Bornath wrote:
+> 2012/1/5 Buchan Milne <bgmilne at zarb.org>:
+>> -Possibly considering contacting large mirror sites (e.g. mirrors.kernel.org)
+>> who currently mirror Mandriva, but not Mageia?
+> 
+> Just for the records: mirrors.kernel.org mirror Mageia.
+> But surely there are more large sites to be contacted.
+
+carroll.aset.psu.edu is one of the major mirrors in the USA that's missing Mageia still.
+
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011094.html b/zarb-ml/mageia-dev/2012-January/011094.html new file mode 100644 index 000000000..ec92a763f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011094.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] references to outside web sites/wiki + + + + + + + + + +

[Mageia-dev] references to outside web sites/wiki

+ David Walser + luigiwalser at yahoo.com +
+ Sat Jan 7 17:18:00 CET 2012 +

+
+ +
Glen Ogilvie wrote:
+>> On Wednesday, 4 January 2012 23:56:01 Romain d'Alverny wrote:
+>> > On Wed, Jan 4, 2012 at 22:36, Johnny A. Solbu <cooker at solbu.net> wrote:
+>> > > On Wednesday 04 January 2012 21:06, Romain d'Alverny wrote:
+>> > >> wiki.mandriva.com may be shut down for good in just a few days
+>> > >
+>> > > What? Are Mandriva serisouly considering closing down the Wiki?
+>> >
+>> > Mandriva is on the path to filing for bankruptcy on January 16th.
+> 
+> Does anyone have a complete mirror / copy of the Mandriva svn repository, or
+> a complete set of SRPMs from cooker?   I would be concerned this becomes 
+> unavailable, as it's a valuable resource for packages not yet imported into 
+> Mageia and contains a history of the package that Mageia does not have.
+
+I asked about this on IRC and was directed to http://rsvndump.sourceforge.net/ as a tool that can be used to download their SVN repository.  
+I'd *really* like to see this happen and be somewhere that everyone has access to (i.e. not have me try to do it myself).  If there's anything 
+needed to help make this happen, I'm willing to help however I can.  I'd really hate for us to lose MDV's SVN packages repository.
+
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011095.html b/zarb-ml/mageia-dev/2012-January/011095.html new file mode 100644 index 000000000..90b300662 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011095.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Claire Robinson + eeeemail at gmail.com +
+ Sat Jan 7 17:37:04 CET 2012 +

+
+ +
On 07/01/12 15:30, Sander Lepik wrote:
+> 07.01.2012 17:09, Wolfgang Bornath kirjutas:
+>> 2012/1/7 Sander Lepik<sander.lepik at eesti.ee>:
+>>> 07.01.2012 16:24, Wolfgang Bornath kirjutas:
+>>>>
+>>>> Used the full DVD (32-bit) Mageia 2 Alpha 2
+>>>> - minimal install with X
+>>> How? AFAIK this is not one of the default options.
+>> It is.
+>> 1. Select "Custom" at the DE selection
+>> 2. Unmark all package groups
+>> 3. Up comes a selection of 4 options:
+>> - minimal with x
+>> - minimal without x
+>> - truely minimal (only base system
+>> - minimal with documentation (which is an option you can select
+>> together with one of the first 2.
+>>
+>> So, yes, it is a defined set of packages. That's why I used it.
+> Ok, next time if you test, do the same. But before removing orphans copy
+> them for later debugging.
+>
+> --
+> Sander
+>
+
+
+Could this bug have anything to do with occasional --auto-orphans glitches?
+
+https://bugs.mageia.org/show_bug.cgi?id=1754
+
+(urpmq --requires-recursive doesn't show everything that would be installed)
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011096.html b/zarb-ml/mageia-dev/2012-January/011096.html new file mode 100644 index 000000000..a4489d1f5 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011096.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Thomas Spuhler + thomas at btspuhler.com +
+ Sat Jan 7 17:48:36 CET 2012 +

+
+ +
On Friday, January 06, 2012 12:57:39 PM Sander Lepik wrote:
+> 06.01.2012 21:06, Dale Huckeby kirjutas:
+> > Evidently once I've installed package A which requests X, sometimes
+> > packages F, L, and T might subsequently get installed which also need X
+> > *and presumably would have requested it had it not already been
+> > installed*.  But when I uninstall A it orphans X because A is the only
+> > package that *requested* it.  When F, L, and T are installed can't all
+> > the packages they *would have requested* be marked whether or not
+> > they're already installed?  That way a package would be orphaned only
+> > when the last package that needs it is uninstalled?  Or am I missing
+> > something?
+> 
+> This is already so. See example: http://pastebin.com/AMj87QiV - after first
+> urpme libplasmaweather4 should be marked as orphan but it's not as it's
+> still required by other package.
+> 
+> --
+> Sander
+
+It seems to me, auto-orphans gives more headaches than benefits. Why are we 
+clinching to it?
+
+-- 
+Best regards
+Thomas Spuhler
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011097.html b/zarb-ml/mageia-dev/2012-January/011097.html new file mode 100644 index 000000000..887388d03 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011097.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] Welcoming Kamil among the Mageia packagers + + + + + + + + + +

[Mageia-dev] Welcoming Kamil among the Mageia packagers

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Sat Jan 7 18:24:35 CET 2012 +

+
+ +
Hi there,
+
+let me welcome Kamil Rytarowski - Mageia login name kamil - as a full
+Mageia packager.
+In the time I had the pleasure to mentor him, I got to know him as a
+dedicated and alert person showing me from time to time that I should
+read the packaging policies from time to time.
+
+So Kamil, welcome to the team!
+And if you should face any problem or any situation unclear to you,
+just remember, there are more senior people out here to ask.
+
+Oliver
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011098.html b/zarb-ml/mageia-dev/2012-January/011098.html new file mode 100644 index 000000000..29080f8bb --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011098.html @@ -0,0 +1,143 @@ + + + + [Mageia-dev] Seamonkey package + + + + + + + + + +

[Mageia-dev] Seamonkey package

+ Florian Hubold + doktor5000 at arcor.de +
+ Sat Jan 7 18:36:41 CET 2012 +

+
+ +
Am 16.04.2011 16:05, schrieb Christiaan Welvaart:
+> On Fri, 11 Mar 2011, Tux99 wrote:
+>
+>> I just downloaded the latest Seamonkey 2.0.12 SRPM from Mandriva cooker and
+>> rebuilt it on my Mageia VM and it built flawlessly, I only had to remove
+>> all the obsolete "%if %mdkversion" sections, but all dependecies are
+>> available in Mageia.
+>> So technically importing Seamonkey into Mageia seems straightforward, the
+>> only issue is licensing (as for Firefox).
+>>
+>> Christiaan I'm a newbie packager here at Mageia so personally I'd much
+>> prefer if you maintain this package for Mageia, it looks far too complex
+>> for me. :)
+>
+> I uploaded "iceape 2.0.12" a few days ago, changing the name and icons/logo
+> took me almost a month. Unfortunately there are still some bugs in this
+> area:  the release notes menu item for example currently still points to
+> seamonkey. It should probably point to a mageia wiki page.
+>
+> Since I don't like the icons that is used for debian's iceape, I created a
+> new icon based on the logo. It looks like it can still be improved, however,
+> and the throbber is currently static. So it would be great if someone could
+> re-do the icon (without creating a completely new design), and animate it for
+> the throbber (he SVG files are in iceape-branding.tar in the source rpm and
+> svn)...
+>
+>
+>     Christiaan
+>
+As iceape for mga1 hasn't seen any update in the last 6 months,
+and there are multiple serious security issues that need fixing,
+how do we handle this?
+
+And i've found no real reason for this rebranding in the first place,
+and this seems also be the case for Fedora, and they have a strong
+legal department.
+http://pkgs.fedoraproject.org/gitweb/?p=seamonkey.git
+
+>From what i read on bugreports between debian packagers and
+mozilla guys about that branding situation, the only thing that would
+need to be done to seamonkey (actually the same would need to
+be done for all our mozilla packages, unless we have permission
+to use the branding, which would imply that all our modifications
+on mozilla packages would need to be reviewed and ack-ed by mozilla
+to get the branding permission) would be to use --disable-official-branding
+configure option.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011099.html b/zarb-ml/mageia-dev/2012-January/011099.html new file mode 100644 index 000000000..c1bde5d1a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011099.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Thomas Backlund + tmb at mageia.org +
+ Sat Jan 7 18:40:57 CET 2012 +

+
+ +
07.01.2012 17:09, Wolfgang Bornath skrev:
+> 2012/1/7 Sander Lepik<sander.lepik at eesti.ee>:
+>> 07.01.2012 16:24, Wolfgang Bornath kirjutas:
+>>>
+>>>
+>>> Used the full DVD (32-bit) Mageia 2 Alpha 2
+>>>   - minimal install with X
+>>
+>> How? AFAIK this is not one of the default options.
+>
+> It is.
+> 1. Select "Custom" at the DE selection
+> 2. Unmark all package groups
+> 3. Up comes a selection of 4 options:
+>   - minimal with x
+>   - minimal without x
+>   - truely minimal (only base system
+>   - minimal with documentation (which is an option you can select
+> together with one of the first 2.
+>
+> So, yes, it is a defined set of packages. That's why I used it.
+>
+
+Ok. a real working example (of a "non-working" --auto-orphans)
+
+Thanks wobo, it's this kind of info we really need.
+
+Now lets try to reproduce and fix it.
+
+--
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011100.html b/zarb-ml/mageia-dev/2012-January/011100.html new file mode 100644 index 000000000..f2277f40c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011100.html @@ -0,0 +1,110 @@ + + + + [Mageia-dev] Welcoming Kamil among the Mageia packagers + + + + + + + + + +

[Mageia-dev] Welcoming Kamil among the Mageia packagers

+ Kamil Rytarowski + n54 at gmx.com +
+ Sat Jan 7 19:51:24 CET 2012 +

+
+ +
W dniu 07.01.2012 18:24, Oliver Burger pisze:
+> Hi there,
+>
+> let me welcome Kamil Rytarowski - Mageia login name kamil - as a full
+> Mageia packager.
+> In the time I had the pleasure to mentor him, I got to know him as a
+> dedicated and alert person showing me from time to time that I should
+> read the packaging policies from time to time.
+>
+> So Kamil, welcome to the team!
+> And if you should face any problem or any situation unclear to you,
+> just remember, there are more senior people out here to ask.
+>
+> Oliver
+I'm very glad to be a part of our team.
+
+Thank you for your hospitable welcome and help from you and the all 
+helpful people among our developers!
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011101.html b/zarb-ml/mageia-dev/2012-January/011101.html new file mode 100644 index 000000000..e009e8ce9 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011101.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Maarten Vanraes + alien at rmail.be +
+ Sat Jan 7 21:13:45 CET 2012 +

+
+ +
Op zaterdag 07 januari 2012 17:48:36 schreef Thomas Spuhler:
+[...]
+> It seems to me, auto-orphans gives more headaches than benefits. Why are we
+> clinching to it?
+
+because it works for me (and several others)
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011102.html b/zarb-ml/mageia-dev/2012-January/011102.html new file mode 100644 index 000000000..76ba13f27 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011102.html @@ -0,0 +1,143 @@ + + + + [Mageia-dev] [packages-commits] [193033] Suggests sectools instead of a Requires ( mga # 2808) + + + + + + + + + +

[Mageia-dev] [packages-commits] [193033] Suggests sectools instead of a Requires ( mga # 2808)

+ Luc Menut + lmenut at free.fr +
+ Sun Jan 8 02:18:28 CET 2012 +

+
+ +
Le 08/01/2012 02:01, root at mageia.org a écrit :
+> Revision
+>     193033
+> Author
+>     dmorgan
+> Date
+>     2012-01-08 02:01:07 +0100 (Sun, 08 Jan 2012)
+>
+>
+>       Log Message
+>
+> Suggests sectools instead of a Requires ( mga # 2808)
+>
+>
+>       Modified Paths
+>
+>   * updates/1/msec/current/SPECS/msec.spec
+>     <#updates1mseccurrentSPECSmsecspec>
+>
+> Modified: updates/1/msec/current/SPECS/msec.spec
+> ===================================================================
+> --- updates/1/msec/current/SPECS/msec.spec	2012-01-08 00:58:08 UTC (rev 193032)
+> +++ updates/1/msec/current/SPECS/msec.spec	2012-01-08 01:01:07 UTC (rev 193033)
+> @@ -1,4 +1,4 @@
+> -%define		subrel 5
+> +%define		subrel 6
+>
+>   Name:		msec
+>   Version:	0.80.10
+> @@ -22,7 +22,7 @@
+>   Requires:	chkconfig
+>   Requires:	mailx
+>   Requires:	python
+> -Requires:	sectool
+> +Suggests:	sectool
+>   # at least xargs is used
+>   Requires:	findutils
+>   # ensure sysctl.conf and inittab are present before installing msec
+>
+>
+
+wouldn't it be better to split the sectool plugin in a subpackage, cf.
+https://bugs.mageia.org/show_bug.cgi?id=2255#c68
+https://bugs.mageia.org/attachment.cgi?id=1329&action=diff
+
+Luc
+
+-- 
+Luc Menut
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011103.html b/zarb-ml/mageia-dev/2012-January/011103.html new file mode 100644 index 000000000..2c3bda470 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011103.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] Alpha3 release notes + + + + + + + + + +

[Mageia-dev] Alpha3 release notes

+ Juan Luis Baptiste + juancho at mageia.org +
+ Sun Jan 8 05:16:16 CET 2012 +

+
+ +
On Sat, Jan 7, 2012 at 7:40 AM, Oliver Burger <oliver.bgr at googlemail.com> wrote:
+> Hi all,
+>
+> please do have a look at the alpha3 release notes:
+> https://wiki.mageia.org/en/Mageia_2_alpha3 and fix/complete them. By
+> keeping them up to date during the alpha/beta/rc phases we will
+> finally have some nice release notes for Mageia2.
+>
+
+Question, should we add new programs only or updated ones to new versions too ?
+
+-- 
+Juancho
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011104.html b/zarb-ml/mageia-dev/2012-January/011104.html new file mode 100644 index 000000000..35c056e37 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011104.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] Alpha3 release notes + + + + + + + + + +

[Mageia-dev] Alpha3 release notes

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Sun Jan 8 09:04:28 CET 2012 +

+
+ +
2012/1/8 Juan Luis Baptiste <juancho at mageia.org>:
+> On Sat, Jan 7, 2012 at 7:40 AM, Oliver Burger <oliver.bgr at googlemail.com> wrote:
+>> Hi all,
+>>
+>> please do have a look at the alpha3 release notes:
+>> https://wiki.mageia.org/en/Mageia_2_alpha3 and fix/complete them. By
+>> keeping them up to date during the alpha/beta/rc phases we will
+>> finally have some nice release notes for Mageia2.
+>>
+>
+> Question, should we add new programs only or updated ones to new versions too ?
+>
+Both. And don't be afraid to add too many notes. We can always filter
+it, so it doesn't get too long.
+
+Oliver
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011105.html b/zarb-ml/mageia-dev/2012-January/011105.html new file mode 100644 index 000000000..13becb294 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011105.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] Alpha3 release notes + + + + + + + + + +

[Mageia-dev] Alpha3 release notes

+ magnus + magnus.mud at googlemail.com +
+ Sun Jan 8 09:31:41 CET 2012 +

+
+ +
Should we add a remark for the support of the 4k-boundary?
+
+magnus
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20120108/641473d1/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011106.html b/zarb-ml/mageia-dev/2012-January/011106.html new file mode 100644 index 000000000..fbf53aca3 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011106.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] Alpha3 release notes + + + + + + + + + +

[Mageia-dev] Alpha3 release notes

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Sun Jan 8 09:56:18 CET 2012 +

+
+ +
2012/1/8 magnus <magnus.mud at googlemail.com>:
+> Should we add a remark for the support of the 4k-boundary?
+>
+I'd say so. Somewhere in the basesystem / installer part.
+
+ennael, what do you think?
+
+Oliver
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011107.html b/zarb-ml/mageia-dev/2012-January/011107.html new file mode 100644 index 000000000..2fd6ccebf --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011107.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] Missing signatures + + + + + + + + + +

[Mageia-dev] Missing signatures

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Sun Jan 8 10:06:10 CET 2012 +

+
+ +
Hi there,
+
+I noticed, that some packages have missing signatures this morning:
+
+/var/cache/urpmi/rpms/acpid-2.0.14-1.mga2.i586.rpm: Missing signature
+(OK ((none)))
+/var/cache/urpmi/rpms/ldetect-0.11.5-1.mga2.i586.rpm: Missing
+signature (OK ((none)))
+/var/cache/urpmi/rpms/libldetect0.11-0.11.5-1.mga2.i586.rpm: Missing
+signature (OK ((none)))
+
+Could this be related to yesterday's changes in the bs code?
+
+Oliver
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011108.html b/zarb-ml/mageia-dev/2012-January/011108.html new file mode 100644 index 000000000..86876d602 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011108.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] Missing signatures + + + + + + + + + +

[Mageia-dev] Missing signatures

+ Jani Välimaa + jani.valimaa at gmail.com +
+ Sun Jan 8 10:08:56 CET 2012 +

+
+ +
2012/1/8 Oliver Burger <oliver.bgr at googlemail.com>:
+> Hi there,
+>
+> I noticed, that some packages have missing signatures this morning:
+>
+
+It's also reported to bugzilla:
+https://bugs.mageia.org/show_bug.cgi?id=4067
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011109.html b/zarb-ml/mageia-dev/2012-January/011109.html new file mode 100644 index 000000000..578e03b66 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011109.html @@ -0,0 +1,144 @@ + + + + [Mageia-dev] [packages-commits] [193033] Suggests sectools instead of a Requires ( mga # 2808) + + + + + + + + + +

[Mageia-dev] [packages-commits] [193033] Suggests sectools instead of a Requires ( mga # 2808)

+ D.Morgan + dmorganec at gmail.com +
+ Sun Jan 8 10:43:21 CET 2012 +

+
+ +
On Sun, Jan 8, 2012 at 2:18 AM, Luc Menut <lmenut at free.fr> wrote:
+> Le 08/01/2012 02:01, root at mageia.org a écrit :
+>>
+>> Revision
+>>    193033
+>> Author
+>>    dmorgan
+>> Date
+>>    2012-01-08 02:01:07 +0100 (Sun, 08 Jan 2012)
+>>
+>>
+>>      Log Message
+>>
+>> Suggests sectools instead of a Requires ( mga # 2808)
+>>
+>>
+>>      Modified Paths
+>>
+>>  * updates/1/msec/current/SPECS/msec.spec
+>>    <#updates1mseccurrentSPECSmsecspec>
+>>
+>>
+>> Modified: updates/1/msec/current/SPECS/msec.spec
+>> ===================================================================
+>> --- updates/1/msec/current/SPECS/msec.spec      2012-01-08 00:58:08 UTC
+>> (rev 193032)
+>> +++ updates/1/msec/current/SPECS/msec.spec      2012-01-08 01:01:07 UTC
+>> (rev 193033)
+>> @@ -1,4 +1,4 @@
+>> -%define                subrel 5
+>> +%define                subrel 6
+>>
+>>  Name:         msec
+>>  Version:      0.80.10
+>> @@ -22,7 +22,7 @@
+>>  Requires:     chkconfig
+>>  Requires:     mailx
+>>  Requires:     python
+>> -Requires:      sectool
+>> +Suggests:      sectool
+>>  # at least xargs is used
+>>  Requires:     findutils
+>>  # ensure sysctl.conf and inittab are present before installing msec
+>>
+>>
+>
+> wouldn't it be better to split the sectool plugin in a subpackage, cf.
+> https://bugs.mageia.org/show_bug.cgi?id=2255#c68
+> https://bugs.mageia.org/attachment.cgi?id=1329&action=diff
+>
+> Luc
+>
+> --
+> Luc Menut
+
+this can be an idea yes, i will take this into consideration
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011110.html b/zarb-ml/mageia-dev/2012-January/011110.html new file mode 100644 index 000000000..93268672c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011110.html @@ -0,0 +1,110 @@ + + + + [Mageia-dev] Missing signatures + + + + + + + + + +

[Mageia-dev] Missing signatures

+ Thomas Backlund + tmb at mageia.org +
+ Sun Jan 8 12:29:23 CET 2012 +

+
+ +
08.01.2012 11:08, Jani Välimaa skrev:
+> 2012/1/8 Oliver Burger<oliver.bgr at googlemail.com>:
+>> Hi there,
+>>
+>> I noticed, that some packages have missing signatures this morning:
+>>
+>
+> It's also reported to bugzilla:
+> https://bugs.mageia.org/show_bug.cgi?id=4067
+>
+
+Yep we had a brief hickup in the signing process, wich I fixed some ~6 
+hours ago.
+
+I just resubmitted some packages with missing signatures, so new 
+packagas should be available shorty.
+
+If you find anymore of them, just bump rel and resubmit.
+
+--
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011111.html b/zarb-ml/mageia-dev/2012-January/011111.html new file mode 100644 index 000000000..3d951554a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011111.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] Missing signatures + + + + + + + + + +

[Mageia-dev] Missing signatures

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Sun Jan 8 12:45:29 CET 2012 +

+
+ +
2012/1/8 Thomas Backlund <tmb at mageia.org>:
+>
+> Yep we had a brief hickup in the signing process, wich I fixed some ~6 hours
+> ago.
+>
+> I just resubmitted some packages with missing signatures, so new packagas
+> should be available shorty.
+>
+> If you find anymore of them, just bump rel and resubmit.
+>
+Ok.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011112.html b/zarb-ml/mageia-dev/2012-January/011112.html new file mode 100644 index 000000000..4bfaa83f1 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011112.html @@ -0,0 +1,111 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Sun Jan 8 13:19:54 CET 2012 +

+
+ +
Le 07/01/2012 11:14, ptyxs a écrit :
+> Le 06/01/2012 17:55, Colin Guthrie a écrit :
+>> 'Twas brillig, and Robert Fox at 06/01/12 10:16 did gyre and gimble:
+>>> After latest Cauldron updates, I got a real long list of suggested
+>>> "orphans" - but I believe some of these packages are needed (like hal or
+>>> basesystem-minimal) -
+>>>
+>>> How do I clear out the orphans - like reset the logic behind it so the
+>>> correct packages will be orphaned? Or is a fresh install in order??
+>> FWIW, as I see some people not liking this feature, personally I don't
+>> use --auto-orphans, but instead use "urpmq --not-available" to find
+>> packages I have installed that are no longer provided by the
+>> repositories. This will typically include old and unneeded library
+>> majors etc. that accumulate after a while.
+>>
+>> This list is much clearer in what it actually outputs and is basically
+>> the same as the yum orphan list command (I forget what the command
+>> actually is, but it's what inspired me to write the first version which
+>> in turn was vastly improved by a native implementation by (IIRC) Pascal
+>> Terjan :))
+>>
+>> Col
+>>
+>>
+> The problem is not 'I like it'/'I don't like it', the problem is that
+> this feature caused sometimes the loss of very important packages making
+> the system unusable and leading to a necessary reinstallation.
+rpm -e --nodeps also.
+
+-- 
+BOFH excuse #42:
+
+spaghetti cable cause packet failure
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011113.html b/zarb-ml/mageia-dev/2012-January/011113.html new file mode 100644 index 000000000..55f1c8516 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011113.html @@ -0,0 +1,197 @@ + + + + [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia + + + + + + + + + +

[Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia

+ Luc Menut + lmenut at free.fr +
+ Sun Jan 8 15:19:15 CET 2012 +

+
+ +
Hello,
+
+first, sorry to reply so late, and when you have started to update 
+hunspell dictionaries packages.
+
+Le 21/12/2011 08:15, Kamil Rytarowski a écrit :
+> Hello!
+[...]
+>
+> There was a discuss on
+> 1) preparing policies on hunspell-dictionaries
+> 2) deprecate and kill myspell in Mga2
+> 3) changing the default path of dictionaries, from /usr/share/myspell to
+> /usr/share/hunspell (and to keep backward compatibility links in myspell
+> directory)
+> 4) to provide "enchant-dictionary" and "hunspell-dictionary" by every
+> hunspell-dictionary
+>
+> So finally, I've prepared a first version of the policy
+> https://wiki.mageia.org/en/Hunspell-dictionary_policy
+> If you like, please tell me your comments of it. Is it right? (Also: is
+> the .spec correct?) When everything will be accepted then every
+> hunspell-dictionary will be updated according to the policy.
+
+some comments about the policy:
+
+Version:        1.0
+Release:        %mkrel %{upstream_release}.%{rel}
+
+I don't think it will be possible to use Version 1.0 and upstream 
+version only in the release; most hunspell dictionaries already use 
+upstream version as version and have a version > 1.0.
+
+--
+
+#Mageia values: 1 - aspell, 2 - hunspell, 3 - language specific
+Provides:       enchant-dictionary = 2
+Provides:       hunspell-dictionary
+Provides:       dictionary-%{languagecode}
+
+about the version value of the provides: is the meaning (1 - aspell, 2 - 
+hunspell, 3 - language specific) really needed? is it currently used?
+Because I think that it could be usefull that the versionned provides 
+indicates the location of the dictionary:
+- current enchant-dictionary = 2 ->> /usr/share/dict/mozilla
+- enchant-dictionary from hunspell ->> enchant-dictionary = 4 ->> 
+/usr/share/hunspell and /usr/share/myspell,
+- enchant-dictionary from future hunspell without compatibility link in 
+/usr/share/myspell ->> enchant-dictionary = 5 ->> /usr/share/hunspell only,
+- ...
+
+(it seems weird for me to use the same "enchant-dictionary = 2" 
+versionned provide, both for "deprecated" myspell dictionaries, and new 
+hunspell dictionaries.)
+
+if the versionned provides indicates the location, we can use it if 
+necessary in Conflicts or Requires in others packages.
+e.g. currently Firefox searches dictionnaries in /usr/share/dict/mozilla 
+(myspell dictionaries). when we change this location, we could add a 
+Requires enchant-dictionary = 4.
+
+same for hunspell-dictionary and dictionary-%{languagecode}, a 
+versionned provides could indicate the location of the dictionary.
+if we want to be able to remove easily all the compatibility link in the 
+future, we should really consider this.
+
+
+>
+> PS. The changes of enchant will be proposed or accepted later, Funda has
+> already prepared the package.
+
+new hunspell dictionaries provides enchant-dictionary and obsoletes 
+myspell dictionaries, but enchant still can't use the new hunspell 
+dictionaries. I think that it should be fixed ASAP, or we will release 
+an alpha 3 with broken spelling for lot of languages.
+I propose the attached patches for enchant, so that enchant can use 
+dictionaries from /usr/share/hunspell, /usr/share/myspell, and 
+/usr/share/dict/ooo.
+Anssi, Kamil, WDYT ?
+
+same problem with firefox and thunderbird, they use dictionaries from 
+/usr/share/dict/mozilla = myspell dictionaries, that are obsoleted.
+(Will we wait for the complete migration, to release alpha 3 ? )
+
+CC: Anssi, enchant and thunderbird maintainer
+     dmorgan, firefox maintainer
+
+
+regards,
+Luc
+
+-- 
+Luc Menut
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: enchant-1.6.0-add-more-myspell-dicts-dirs.patch
+Type: text/x-patch
+Size: 646 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20120108/f40db454/attachment.bin>
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: enchant_spec.diff
+Type: text/x-patch
+Size: 823 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20120108/f40db454/attachment-0001.bin>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011114.html b/zarb-ml/mageia-dev/2012-January/011114.html new file mode 100644 index 000000000..056f2847a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011114.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia + + + + + + + + + +

[Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia

+ Thomas Backlund + tmb at mageia.org +
+ Sun Jan 8 15:29:18 CET 2012 +

+
+ +
08.01.2012 16:19, Luc Menut skrev:
+
+> same problem with firefox and thunderbird, they use dictionaries from
+> /usr/share/dict/mozilla = myspell dictionaries, that are obsoleted.
+> (Will we wait for the complete migration, to release alpha 3 ? )
+>
+
+
+Nope. Alpha3 iso building is working from a frozen repo
+
+--
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011115.html b/zarb-ml/mageia-dev/2012-January/011115.html new file mode 100644 index 000000000..9ca3f7453 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011115.html @@ -0,0 +1,123 @@ + + + + [Mageia-dev] RFC: Drop mkinitrd completely in favour of dracut. + + + + + + + + + +

[Mageia-dev] RFC: Drop mkinitrd completely in favour of dracut.

+ Olivier Blin + mageia at blino.org +
+ Sun Jan 8 15:40:25 CET 2012 +

+
+ +
Anssi Hannula <anssi at mageia.org> writes:
+
+>>>> Is it possible to detect missing radeon firmware in initrd in early
+>>>> boot, and then switch to loading radeon with modeset=0 ?
+
+[...]
+
+> Does loading of radeon modesetting kernel driver without firmware break
+> the boot completely, or does it just make X.org server fail to start?
+
+Here it sorts of breaks the boot.
+The display is not usable at all, either in the console or in gdm. The
+screen is flickering with purple color/green colors on top, and white in
+the bigger part of the screen.
+
+Card:ATI Radeon HD 2000 and later (radeon/fglrx): ATI Technologies
+Inc|RV610 video device [Radeon HD 2400 PRO] [DISPLAY_VGA]
+
+-- 
+Olivier Blin - blino
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011116.html b/zarb-ml/mageia-dev/2012-January/011116.html new file mode 100644 index 000000000..05b28fb03 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011116.html @@ -0,0 +1,110 @@ + + + + [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia + + + + + + + + + +

[Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia

+ Luc Menut + lmenut at free.fr +
+ Sun Jan 8 15:41:08 CET 2012 +

+
+ +
Le 08/01/2012 15:29, Thomas Backlund a écrit :
+> 08.01.2012 16:19, Luc Menut skrev:
+>
+>> same problem with firefox and thunderbird, they use dictionaries from
+>> /usr/share/dict/mozilla = myspell dictionaries, that are obsoleted.
+>> (Will we wait for the complete migration, to release alpha 3 ? )
+>>
+>
+>
+> Nope. Alpha3 iso building is working from a frozen repo
+>
+
+OK sorry, thanks Thomas for the clarification.
+I badly understood the mail of Anne about "Mageia 2 alpha 3 in progress".
+
+Luc
+
+
+-- 
+Luc Menut
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011117.html b/zarb-ml/mageia-dev/2012-January/011117.html new file mode 100644 index 000000000..2c73e2419 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011117.html @@ -0,0 +1,113 @@ + + + + [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia + + + + + + + + + +

[Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia

+ Thomas Backlund + tmb at mageia.org +
+ Sun Jan 8 15:44:53 CET 2012 +

+
+ +
08.01.2012 16:41, Luc Menut skrev:
+> Le 08/01/2012 15:29, Thomas Backlund a écrit :
+>> 08.01.2012 16:19, Luc Menut skrev:
+>>
+>>> same problem with firefox and thunderbird, they use dictionaries from
+>>> /usr/share/dict/mozilla = myspell dictionaries, that are obsoleted.
+>>> (Will we wait for the complete migration, to release alpha 3 ? )
+>>>
+>>
+>>
+>> Nope. Alpha3 iso building is working from a frozen repo
+>>
+>
+> OK sorry, thanks Thomas for the clarification.
+> I badly understood the mail of Anne about "Mageia 2 alpha 3 in progress".
+>
+
+Yeah, the point is we still dont want big changes if we need to resync 
+due to some bug, missing packages, ....
+
+--
+Thomas
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011118.html b/zarb-ml/mageia-dev/2012-January/011118.html new file mode 100644 index 000000000..598cc1230 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011118.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ ptyxs + ptyxs at free.fr +
+ Sun Jan 8 15:48:23 CET 2012 +

+
+ +
Le 07/01/2012 21:13, Maarten Vanraes a écrit :
+> Op zaterdag 07 januari 2012 17:48:36 schreef Thomas Spuhler:
+> [...]
+>> It seems to me, auto-orphans gives more headaches than benefits. Why are we
+>> clinching to it?
+> because it works for me (and several others)
+>
+It works SOMETIMES and sometimes it crashes the whole system.
+
+-- 
+Ce courriel a été émis à partir du système d'exploitation Mandriva
+Linux
+Préférez les logiciels libres et les formats ouverts.
+LINUX ? IL Y A MOINS BIEN, MAIS... C'EST PLUS CHER !!
+
+
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011119.html b/zarb-ml/mageia-dev/2012-January/011119.html new file mode 100644 index 000000000..fcb7113b1 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011119.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Sun Jan 8 16:45:12 CET 2012 +

+
+ +
2012/1/8 ptyxs <ptyxs at free.fr>:
+> Le 07/01/2012 21:13, Maarten Vanraes a écrit :
+>>
+>> Op zaterdag 07 januari 2012 17:48:36 schreef Thomas Spuhler:
+>> [...]
+>>>
+>>> It seems to me, auto-orphans gives more headaches than benefits. Why are
+>>> we
+>>> clinching to it?
+>>
+>> because it works for me (and several others)
+>>
+> It works SOMETIMES and sometimes it crashes the whole system.
+>
+
+I admit that it has been working for me most of the times but I did
+not use it very often. But what is the priority here? It should only
+be implemented when it works for everybody (with the usual few
+exceptions) and not just because it works for some.
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011120.html b/zarb-ml/mageia-dev/2012-January/011120.html new file mode 100644 index 000000000..246cab637 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011120.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Pascal Terjan + pterjan at gmail.com +
+ Sun Jan 8 16:59:32 CET 2012 +

+
+ +
On Sat, Jan 7, 2012 at 16:48, Thomas Spuhler <thomas at btspuhler.com> wrote:
+> On Friday, January 06, 2012 12:57:39 PM Sander Lepik wrote:
+>> 06.01.2012 21:06, Dale Huckeby kirjutas:
+>> > Evidently once I've installed package A which requests X, sometimes
+>> > packages F, L, and T might subsequently get installed which also need X
+>> > *and presumably would have requested it had it not already been
+>> > installed*.  But when I uninstall A it orphans X because A is the only
+>> > package that *requested* it.  When F, L, and T are installed can't all
+>> > the packages they *would have requested* be marked whether or not
+>> > they're already installed?  That way a package would be orphaned only
+>> > when the last package that needs it is uninstalled?  Or am I missing
+>> > something?
+>>
+>> This is already so. See example: http://pastebin.com/AMj87QiV - after first
+>> urpme libplasmaweather4 should be marked as orphan but it's not as it's
+>> still required by other package.
+>>
+>> --
+>> Sander
+>
+> It seems to me, auto-orphans gives more headaches than benefits. Why are we
+> clinching to it?
+
+Because I and meany other people finding it useful never faced any
+problems on their machine with it.
+
+The only problems I can remember are:
+- people wanted to remove some things required by task-kde, which
+implied removing task-kde, and then all of kde was orphan. I think
+many things were move to suggests since
+- some kind of install was installing packages requested by nothing
+and they were not marked as requested so they were listed as orphans,
+but this was fixed long ago
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011121.html b/zarb-ml/mageia-dev/2012-January/011121.html new file mode 100644 index 000000000..48fc94fb1 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011121.html @@ -0,0 +1,126 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Pascal Terjan + pterjan at gmail.com +
+ Sun Jan 8 17:01:10 CET 2012 +

+
+ +
On Sat, Jan 7, 2012 at 14:24, Wolfgang Bornath <molch.b at googlemail.com> wrote:
+> 2012/1/7 Sander Lepik <sander.lepik at eesti.ee>:
+>> 07.01.2012 13:39, Wolfgang Bornath kirjutas:
+>>>
+>>> Of course this is one way to find bugs in packages. But what about the
+>>> documented (in German) case where
+>>>  - after fresh installation, reboot (ok) and updates right after
+>>> installation I was presented with a list of more than 100 "orphans".
+>>>  - I ran 'urpme --auto-orphans' and rebooted
+>>>  - several system services (which started successfully after
+>>> installation) refused to start now because of missing files
+>>>
+>>> Of course urpmi was not the culprit because it only checks
+>>> dependencies. But that did matter in that situation. The auto-orphans
+>>> function obviously listed packages which may have no dependencies but
+>>> are needed by the system. That's why I do not complain about urpmi but
+>>> about the whole function. As long as this function is only based on
+>>> package dependencies it is not safe to use it.
+>>
+>> Did you choose custom install and unchecked some options? Or did you use
+>> LiveCD maybe? Anyway.. function is not to blame. Next time copy those
+>> packages that are going to be uninstalled. And they can be rechecked. Which
+>> are needed and why they get orphaned.
+>
+> Used the full DVD (32-bit) Mageia 2 Alpha 2
+>  - minimal install with X
+>  - after installation and reboot everything was ok
+>  - setup the package media (dedicated mirror) and did 'urpmi -auto-update'
+>  - I did NOT install or remove one single package manually
+>  - after that urpmi showed a list of more than 100 orphans
+>  - used 'urpme -auto-orphans
+>  - at reboot the start messages showed several errors concerning
+> crond, network-up, postfix, display manager, etc. - system start
+> stopped before x was started. Repeated the boot process with same
+> result.
+>
+> A side question is why I got so many orphans in a minimal system with
+> only around 700 packages in total and only around 2 or 3 dozens of
+> updates (all this happened not long after Alpha 2 release.)
+>
+> Of course urpmi is not the culprit, it is the shortcomings of the
+> function as it is. It should just not be there if its use could lead
+> to such behavior, no matter where the cause comes from. Simply said: a
+> gasoline brand should not be sold if it could do damage to the car's
+> motor, no matter which of the components of the fluid causes the
+> damage..
+>
+> Anyhow, I will repeat the same operation when Alpha 2 is released in a
+> couple of days and as soon as the system shows orphans I will document
+> that list and (if the same problem arises) dmesg output if available.
+> What else do you need for a reasonable documentation?
+
+Thanks, this is obviously an installation bug as those packages should
+be listed as requested.
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011122.html b/zarb-ml/mageia-dev/2012-January/011122.html new file mode 100644 index 000000000..10c7ee6d6 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011122.html @@ -0,0 +1,116 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ ptyxs + ptyxs at free.fr +
+ Sun Jan 8 17:04:54 CET 2012 +

+
+ +
Le 08/01/2012 16:59, Pascal Terjan a écrit :
+> On Sat, Jan 7, 2012 at 16:48, Thomas Spuhler<thomas at btspuhler.com>  wrote:
+>> On Friday, January 06, 2012 12:57:39 PM Sander Lepik wrote:
+>>> 06.01.2012 21:06, Dale Huckeby kirjutas:
+>>>> Evidently once I've installed package A which requests X, sometimes
+>>>> packages F, L, and T might subsequently get installed which also need X
+>>>> *and presumably would have requested it had it not already been
+>>>> installed*.  But when I uninstall A it orphans X because A is the only
+>>>> package that *requested* it.  When F, L, and T are installed can't all
+>>>> the packages they *would have requested* be marked whether or not
+>>>> they're already installed?  That way a package would be orphaned only
+>>>> when the last package that needs it is uninstalled?  Or am I missing
+>>>> something?
+>>> This is already so. See example: http://pastebin.com/AMj87QiV - after first
+>>> urpme libplasmaweather4 should be marked as orphan but it's not as it's
+>>> still required by other package.
+>>>
+>>> --
+>>> Sander
+>> It seems to me, auto-orphans gives more headaches than benefits. Why are we
+>> clinching to it?
+> Because I and meany other people finding it useful never faced any
+> problems on their machine with it.
+>
+> The only problems I can remember are:
+> - people wanted to remove some things required by task-kde, which
+> implied removing task-kde, and then all of kde was orphan. I think
+> many things were move to suggests since
+> - some kind of install was installing packages requested by nothing
+> and they were not marked as requested so they were listed as orphans,
+> but this was fixed long ago
+>
+I recently installed Okular then i removed xpdf and then used 
+auto-orphans : I immedialtely lost any possibility to use wifi...
+
+
+-- 
+Ce courriel a été émis à partir du système d'exploitation Mandriva
+Linux
+Préférez les logiciels libres et les formats ouverts.
+LINUX ? IL Y A MOINS BIEN, MAIS... C'EST PLUS CHER !!
+
+
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011123.html b/zarb-ml/mageia-dev/2012-January/011123.html new file mode 100644 index 000000000..e2a716eb6 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011123.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] Missing signatures + + + + + + + + + +

[Mageia-dev] Missing signatures

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Sun Jan 8 17:27:42 CET 2012 +

+
+ +
On 8 January 2012 12:29, Thomas Backlund <tmb at mageia.org> wrote:
+> Yep we had a brief hickup in the signing process, wich I fixed some ~6 hours
+> ago.
+>
+> I just resubmitted some packages with missing signatures, so new packagas
+> should be available shorty.
+>
+> If you find anymore of them, just bump rel and resubmit.
+
+You forgot core/updates_testing/
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011124.html b/zarb-ml/mageia-dev/2012-January/011124.html new file mode 100644 index 000000000..72192b025 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011124.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] mentors + apprentices + + + + + + + + + +

[Mageia-dev] mentors + apprentices

+ philippe makowski + makowski.mageia at gmail.com +
+ Sun Jan 8 17:36:27 CET 2012 +

+
+ +
Hi,
+
+I think I will have more free time now
+so if an apprentice is looking for a mentor, you can contact me
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011125.html b/zarb-ml/mageia-dev/2012-January/011125.html new file mode 100644 index 000000000..63fa4b3ff --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011125.html @@ -0,0 +1,120 @@ + + + + [Mageia-dev] Missing signatures + + + + + + + + + +

[Mageia-dev] Missing signatures

+ Luc Menut + lmenut at free.fr +
+ Sun Jan 8 17:36:38 CET 2012 +

+
+ +
Le 08/01/2012 12:29, Thomas Backlund a écrit :
+> 08.01.2012 11:08, Jani Välimaa skrev:
+>> 2012/1/8 Oliver Burger<oliver.bgr at googlemail.com>:
+>>> Hi there,
+>>>
+>>> I noticed, that some packages have missing signatures this morning:
+>>>
+>>
+>> It's also reported to bugzilla:
+>> https://bugs.mageia.org/show_bug.cgi?id=4067
+>>
+>
+> Yep we had a brief hickup in the signing process, wich I fixed some ~6
+> hours ago.
+>
+
+It seems not completely fixed; gedit-3.3.2-1.mga2 built today 08 janv. 
+2012 at 15:51:09 CET is not signed.
+
+rpm -qpi gedit-3.3.2-1.mga2.x86_64.rpm
+Name        : gedit
+Version     : 3.3.2
+Release     : 1.mga2
+Architecture: x86_64
+Install Date: (not installed)
+Group       : Editors
+Size        : 12797127
+License     : GPLv2+
+Signature   : (none)     <<<<<<<<<<<<<<<<<<<<<<<<<<
+Source RPM  : gedit-3.3.2-1.mga2.src.rpm
+Build Date  : dim. 08 janv. 2012 15:51:09 CET
+Build Host  : jonund
+Relocations : (not relocatable)
+Packager    : wally <wally>
+
+
+-- 
+Luc Menut
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011126.html b/zarb-ml/mageia-dev/2012-January/011126.html new file mode 100644 index 000000000..613d84769 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011126.html @@ -0,0 +1,119 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release qesteidutil-3.4.0-3.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release qesteidutil-3.4.0-3.mga2

+ Sander Lepik + sander.lepik at eesti.ee +
+ Sun Jan 8 18:35:51 CET 2012 +

+
+ +
18.12.2011 10:45, Mageia Team kirjutas:
+> Name        : qesteidutil                  Relocations: (not relocatable)
+> Version     : 3.4.0                             Vendor: Mageia.Org
+> Release     : 3.mga2                        Build Date: Sun Dec 18 09:36:19 2011
+> Install Date: (not installed)               Build Host: ecosse
+> Group       : Office                        Source RPM: (none)
+> Size        : 794924                           License: LGPLv2
+> Signature   : (none)
+> Packager    : Mageia Team<http://www.mageia.org>
+> URL         : http://id.eesti.ee
+> Summary     : Estonian ID card utility
+> Description :
+> QEsteidUtil is a user-friendly application for managing Estonian ID Cards.
+> It can be used to to change and unlock PIN codes, examine the personal
+> information stored on the card, extract and view the certificates, set
+> up mobile ID and configure a personal @eesti.ee e-mail address.
+>
+> fwang<fwang>  3.4.0-3.mga2:
+> + Revision: 183700
+> - br qtwebkit
+Why this br? I fail to see reason. :)
+
+--
+Sander
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011127.html b/zarb-ml/mageia-dev/2012-January/011127.html new file mode 100644 index 000000000..dc1ac8dc9 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011127.html @@ -0,0 +1,203 @@ + + + + [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia + + + + + + + + + +

[Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia

+ Anssi Hannula + anssi at mageia.org +
+ Sun Jan 8 20:01:31 CET 2012 +

+
+ +
On 08.01.2012 16:19, Luc Menut wrote:
+> Hello,
+> 
+> first, sorry to reply so late, and when you have started to update
+> hunspell dictionaries packages.
+> 
+> Le 21/12/2011 08:15, Kamil Rytarowski a écrit :
+>> Hello!
+> [...]
+>>
+>> There was a discuss on
+>> 1) preparing policies on hunspell-dictionaries
+>> 2) deprecate and kill myspell in Mga2
+>> 3) changing the default path of dictionaries, from /usr/share/myspell to
+>> /usr/share/hunspell (and to keep backward compatibility links in myspell
+>> directory)
+>> 4) to provide "enchant-dictionary" and "hunspell-dictionary" by every
+>> hunspell-dictionary
+>>
+>> So finally, I've prepared a first version of the policy
+>> https://wiki.mageia.org/en/Hunspell-dictionary_policy
+>> If you like, please tell me your comments of it. Is it right? (Also: is
+>> the .spec correct?) When everything will be accepted then every
+>> hunspell-dictionary will be updated according to the policy.
+> 
+> some comments about the policy:
+> 
+> Version:        1.0
+> Release:        %mkrel %{upstream_release}.%{rel}
+> 
+> I don't think it will be possible to use Version 1.0 and upstream
+> version only in the release; most hunspell dictionaries already use
+> upstream version as version and have a version > 1.0.
+
+Strong +1 from me for not using hardcoded Version 1.0, please instead
+use the %upstream_release in Version.
+
+I don't see any reason to break the versioning policy here.
+
+> -- 
+> 
+> #Mageia values: 1 - aspell, 2 - hunspell, 3 - language specific
+> Provides:       enchant-dictionary = 2
+> Provides:       hunspell-dictionary
+> Provides:       dictionary-%{languagecode}
+> 
+> about the version value of the provides: is the meaning (1 - aspell, 2 -
+> hunspell, 3 - language specific) really needed? is it currently used?
+
+The intention was that when a package depended on enchant-dictionary,
+urpmi would prefer language specific enchant dictionaries over hunspell
+dictionaries over aspell dictionaries when presenting a list for the user.
+
+> Because I think that it could be usefull that the versionned provides
+> indicates the location of the dictionary:
+> - current enchant-dictionary = 2 ->> /usr/share/dict/mozilla
+> - enchant-dictionary from hunspell ->> enchant-dictionary = 4 ->>
+> /usr/share/hunspell and /usr/share/myspell,
+> - enchant-dictionary from future hunspell without compatibility link in
+> /usr/share/myspell ->> enchant-dictionary = 5 ->> /usr/share/hunspell only,
+> - ...
+> 
+> (it seems weird for me to use the same "enchant-dictionary = 2"
+> versionned provide, both for "deprecated" myspell dictionaries, and new
+> hunspell dictionaries.)
+> 
+> if the versionned provides indicates the location, we can use it if
+> necessary in Conflicts or Requires in others packages.
+> e.g. currently Firefox searches dictionnaries in /usr/share/dict/mozilla
+> (myspell dictionaries). when we change this location, we could add a
+> Requires enchant-dictionary = 4.
+
+IMO a better way to handle this would be
+Provides:	mozilla-dictionary
+Provides:	hunspell-dictionary
+Provides:	myspell-dictionary
+
+based on which directories are contained in the package, since other
+packages are generally interested in whether the package provides
+dictionaries in a specific location. (i.e. a package using dictionaries
+in /usr/share/hunspell doesn't care if there are some extra dictionaries
+provided in other directories).
+
+> same for hunspell-dictionary and dictionary-%{languagecode}, a
+> versionned provides could indicate the location of the dictionary.
+> if we want to be able to remove easily all the compatibility link in the
+> future, we should really consider this.
+> 
+> 
+>>
+>> PS. The changes of enchant will be proposed or accepted later, Funda has
+>> already prepared the package.
+> 
+> new hunspell dictionaries provides enchant-dictionary and obsoletes
+> myspell dictionaries, but enchant still can't use the new hunspell
+> dictionaries. I think that it should be fixed ASAP, or we will release
+> an alpha 3 with broken spelling for lot of languages.
+> I propose the attached patches for enchant, so that enchant can use
+> dictionaries from /usr/share/hunspell, /usr/share/myspell, and
+> /usr/share/dict/ooo.
+> Anssi, Kamil, WDYT ?
+
+Seems OK.
+
+> same problem with firefox and thunderbird, they use dictionaries from
+> /usr/share/dict/mozilla = myspell dictionaries, that are obsoleted.
+> (Will we wait for the complete migration, to release alpha 3 ? )
+> 
+> CC: Anssi, enchant and thunderbird maintainer
+>     dmorgan, firefox maintainer
+> 
+> 
+> regards,
+> Luc
+> 
+
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011128.html b/zarb-ml/mageia-dev/2012-January/011128.html new file mode 100644 index 000000000..57d735c3b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011128.html @@ -0,0 +1,119 @@ + + + + [Mageia-dev] Orphans - those poor orphans . . . + + + + + + + + + +

[Mageia-dev] Orphans - those poor orphans . . .

+ Pascal Terjan + pterjan at gmail.com +
+ Sun Jan 8 20:41:12 CET 2012 +

+
+ +
On Sun, Jan 8, 2012 at 16:04, ptyxs <ptyxs at free.fr> wrote:
+> Le 08/01/2012 16:59, Pascal Terjan a écrit :
+>
+>> On Sat, Jan 7, 2012 at 16:48, Thomas Spuhler<thomas at btspuhler.com>  wrote:
+>>>
+>>> On Friday, January 06, 2012 12:57:39 PM Sander Lepik wrote:
+>>>>
+>>>> 06.01.2012 21:06, Dale Huckeby kirjutas:
+>>>>>
+>>>>> Evidently once I've installed package A which requests X, sometimes
+>>>>> packages F, L, and T might subsequently get installed which also need X
+>>>>> *and presumably would have requested it had it not already been
+>>>>> installed*.  But when I uninstall A it orphans X because A is the only
+>>>>> package that *requested* it.  When F, L, and T are installed can't all
+>>>>> the packages they *would have requested* be marked whether or not
+>>>>> they're already installed?  That way a package would be orphaned only
+>>>>> when the last package that needs it is uninstalled?  Or am I missing
+>>>>> something?
+>>>>
+>>>> This is already so. See example: http://pastebin.com/AMj87QiV - after
+>>>> first
+>>>> urpme libplasmaweather4 should be marked as orphan but it's not as it's
+>>>> still required by other package.
+>>>>
+>>>> --
+>>>> Sander
+>>>
+>>> It seems to me, auto-orphans gives more headaches than benefits. Why are
+>>> we
+>>> clinching to it?
+>>
+>> Because I and meany other people finding it useful never faced any
+>> problems on their machine with it.
+>>
+>> The only problems I can remember are:
+>> - people wanted to remove some things required by task-kde, which
+>> implied removing task-kde, and then all of kde was orphan. I think
+>> many things were move to suggests since
+>> - some kind of install was installing packages requested by nothing
+>> and they were not marked as requested so they were listed as orphans,
+>> but this was fixed long ago
+>>
+> I recently installed Okular then i removed xpdf and then used auto-orphans :
+> I immedialtely lost any possibility to use wifi...
+
+What would be useful would be to know what package was removed, and
+how it had been installed
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011129.html b/zarb-ml/mageia-dev/2012-January/011129.html new file mode 100644 index 000000000..bf969a1f8 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011129.html @@ -0,0 +1,195 @@ + + + + [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia + + + + + + + + + +

[Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia

+ Kamil Rytarowski + n54 at gmx.com +
+ Sun Jan 8 21:18:26 CET 2012 +

+
+ +
W dniu 08.01.2012 15:19, Luc Menut pisze:
+> Hello,
+Hello Luc, thank you for you mail.
+>
+> first, sorry to reply so late, and when you have started to update 
+> hunspell dictionaries packages.
+>
+> Le 21/12/2011 08:15, Kamil Rytarowski a écrit :
+>> Hello!
+> [...]
+>>
+>> There was a discuss on
+>> 1) preparing policies on hunspell-dictionaries
+>> 2) deprecate and kill myspell in Mga2
+>> 3) changing the default path of dictionaries, from /usr/share/myspell to
+>> /usr/share/hunspell (and to keep backward compatibility links in myspell
+>> directory)
+>> 4) to provide "enchant-dictionary" and "hunspell-dictionary" by every
+>> hunspell-dictionary
+>>
+>> So finally, I've prepared a first version of the policy
+>> https://wiki.mageia.org/en/Hunspell-dictionary_policy
+>> If you like, please tell me your comments of it. Is it right? (Also: is
+>> the .spec correct?) When everything will be accepted then every
+>> hunspell-dictionary will be updated according to the policy.
+>
+> some comments about the policy:
+>
+> Version:        1.0
+> Release:        %mkrel %{upstream_release}.%{rel}
+>
+> I don't think it will be possible to use Version 1.0 and upstream 
+> version only in the release; most hunspell dictionaries already use 
+> upstream version as version and have a version > 1.0.
+upstream version != upstream release
+
+We will keep Fedora versioning.
+>
+> -- 
+>
+> #Mageia values: 1 - aspell, 2 - hunspell, 3 - language specific
+> Provides:       enchant-dictionary = 2
+> Provides:       hunspell-dictionary
+> Provides:       dictionary-%{languagecode}
+>
+> about the version value of the provides: is the meaning (1 - aspell, 2 
+> - hunspell, 3 - language specific) really needed? is it currently used?
+> Because I think that it could be usefull that the versionned provides 
+> indicates the location of the dictionary:
+> - current enchant-dictionary = 2 ->> /usr/share/dict/mozilla
+> - enchant-dictionary from hunspell ->> enchant-dictionary = 4 ->> 
+> /usr/share/hunspell and /usr/share/myspell,
+> - enchant-dictionary from future hunspell without compatibility link 
+> in /usr/share/myspell ->> enchant-dictionary = 5 ->> 
+> /usr/share/hunspell only,
+> - ...
+>
+> (it seems weird for me to use the same "enchant-dictionary = 2" 
+> versionned provide, both for "deprecated" myspell dictionaries, and 
+> new hunspell dictionaries.)
+> if the versionned provides indicates the location, we can use it if 
+> necessary in Conflicts or Requires in others packages.
+> e.g. currently Firefox searches dictionnaries in 
+> /usr/share/dict/mozilla (myspell dictionaries). when we change this 
+> location, we could add a Requires enchant-dictionary = 4.
+>
+> same for hunspell-dictionary and dictionary-%{languagecode}, a 
+> versionned provides could indicate the location of the dictionary.
+> if we want to be able to remove easily all the compatibility link in 
+> the future, we should really consider this.
+>
+If a package requires enchant-dictionary, then language specific will be 
+chosen before Aspell. This is the whole idea behind it. (eg. Voikko is 
+chosen before hunspell-fi and aspell-fi too). And I'm against some 
+special versioning for directories, we don't really need it.
+>
+>>
+>> PS. The changes of enchant will be proposed or accepted later, Funda has
+>> already prepared the package.
+>
+> new hunspell dictionaries provides enchant-dictionary and obsoletes 
+> myspell dictionaries, but enchant still can't use the new hunspell 
+> dictionaries. I think that it should be fixed ASAP, or we will release 
+> an alpha 3 with broken spelling for lot of languages.
+> I propose the attached patches for enchant, so that enchant can use 
+> dictionaries from /usr/share/hunspell, /usr/share/myspell, and 
+> /usr/share/dict/ooo.
+> Anssi, Kamil, WDYT ?
+Yes feel free to fix it. As far as I saw Funda was already working with 
+enchant disabling Aspell and Myspell.
+>
+> same problem with firefox and thunderbird, they use dictionaries from 
+> /usr/share/dict/mozilla = myspell dictionaries, that are obsoleted.
+This must be fixed too - as soon as possible.
+> (Will we wait for the complete migration, to release alpha 3 ? )
+I won't wait now, we are short on time. I want to finish everything 
+before the general version freeze.
+>
+> CC: Anssi, enchant and thunderbird maintainer
+>     dmorgan, firefox maintainer
+>
+>
+> regards,
+> Luc
+>
+So finally - I'm focusing right now just on the Hunspell dictionaries 
+and this is my painstaking job. And then after it or in the same time 
+there is need to fix the last remaining packages to use Hunspell/Enchant 
+correctly.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011130.html b/zarb-ml/mageia-dev/2012-January/011130.html new file mode 100644 index 000000000..01512cb16 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011130.html @@ -0,0 +1,126 @@ + + + + [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia + + + + + + + + + +

[Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia

+ Thomas Backlund + tmb at mageia.org +
+ Sun Jan 8 21:43:23 CET 2012 +

+
+ +
08.01.2012 22:18, Kamil Rytarowski skrev:
+> W dniu 08.01.2012 15:19, Luc Menut pisze:
+
+>> same problem with firefox and thunderbird, they use dictionaries from
+>> /usr/share/dict/mozilla = myspell dictionaries, that are obsoleted.
+> This must be fixed too - as soon as possible.
+>> (Will we wait for the complete migration, to release alpha 3 ? )
+> I won't wait now, we are short on time. I want to finish everything
+> before the general version freeze.
+
+Kamil.
+
+You must take better note when we send info on -dev ml.
+
+Quoting ennael in thread: [Mageia-dev] Mageia 2 alpha 3 in progress
+
+<quote>
+Hi there
+
+First of all, happy new year 2012 and all the best for you and your family.
+
+Mageia 2 alpha3 isos are now in progress, public release is planned
+for 12th of january. Please do not provide for now major updates on
+packages as we will freeze local repository in coming hours.
+
+Thanks for advance
+</quote>
+
+
+Theese changes should really have waited until alpha3 was released.
+
+Fortunately for you I synced the frozen repo with cauldron ~3 hours
+before you started pushing the changes.
+
+Hopefully we dont need anything more from cauldron for alpha3 isos
+now as we would have to start cherry-picking the packages, meaning
+more work for us.
+
+--
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011131.html b/zarb-ml/mageia-dev/2012-January/011131.html new file mode 100644 index 000000000..94cf346f0 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011131.html @@ -0,0 +1,133 @@ + + + + [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia + + + + + + + + + +

[Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia

+ Luc Menut + lmenut at free.fr +
+ Sun Jan 8 22:04:18 CET 2012 +

+
+ +
Le 08/01/2012 21:18, Kamil Rytarowski a écrit :
+> W dniu 08.01.2012 15:19, Luc Menut pisze:
+>> Hello,
+
+[...]
+
+>> if the versionned provides indicates the location, we can use it if
+>> necessary in Conflicts or Requires in others packages.
+>> e.g. currently Firefox searches dictionnaries in
+>> /usr/share/dict/mozilla (myspell dictionaries). when we change this
+>> location, we could add a Requires enchant-dictionary = 4.
+>>
+>> same for hunspell-dictionary and dictionary-%{languagecode}, a
+>> versionned provides could indicate the location of the dictionary.
+>> if we want to be able to remove easily all the compatibility link in
+>> the future, we should really consider this.
+>>
+> If a package requires enchant-dictionary, then language specific will be
+> chosen before Aspell. This is the whole idea behind it. (eg. Voikko is
+> chosen before hunspell-fi and aspell-fi too).
+
+OK, I understand the use for enchant-dictionary.
+
+> And I'm against some
+> special versioning for directories, we don't really need it.
+
+sorry but I don't agree with you here.
+e.g. in coming days, we will fix firefox (and other mozilla apps) to use 
+hunspell-dictionaries; we will update the link to
+/usr/lib64/firefox-9.0.1/dictionaries -> /usr/share/hunspell
+and change the requires to hunspell-dictionary.
+
+but hunspell-dictionaries "old generation" (mga1) provide 
+hunspell-dictionary, and install dictionaries only in /usr/share/myspell.
+how do you plan to handle that the fixed firefox will absolutly need 
+hunspell-dictionaries "new generation", and can't work with 
+hunspell-dictionaries "old generation" ?
+
+
+regards,
+
+Luc
+
+
+-- 
+Luc Menut
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011132.html b/zarb-ml/mageia-dev/2012-January/011132.html new file mode 100644 index 000000000..3feb6d2a2 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011132.html @@ -0,0 +1,114 @@ + + + + [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia + + + + + + + + + +

[Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia

+ Kamil Rytarowski + n54 at gmx.com +
+ Sun Jan 8 22:48:33 CET 2012 +

+
+ +
W dniu 08.01.2012 21:43, Thomas Backlund pisze:
+> 08.01.2012 22:18, Kamil Rytarowski skrev:
+>> W dniu 08.01.2012 15:19, Luc Menut pisze:
+>
+>>> same problem with firefox and thunderbird, they use dictionaries from
+>>> /usr/share/dict/mozilla = myspell dictionaries, that are obsoleted.
+>> This must be fixed too - as soon as possible.
+>>> (Will we wait for the complete migration, to release alpha 3 ? )
+>> I won't wait now, we are short on time. I want to finish everything
+>> before the general version freeze.
+>
+> Kamil.
+>
+> You must take better note when we send info on -dev ml.
+>
+> Quoting ennael in thread: [Mageia-dev] Mageia 2 alpha 3 in progress
+>
+> <quote>
+> Hi there
+>
+> First of all, happy new year 2012 and all the best for you and your 
+> family.
+>
+> Mageia 2 alpha3 isos are now in progress, public release is planned
+> for 12th of january. Please do not provide for now major updates on
+> packages as we will freeze local repository in coming hours.
+>
+> Thanks for advance
+> </quote>
+Right, excuse me! Thankfully nothing is effected.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011133.html b/zarb-ml/mageia-dev/2012-January/011133.html new file mode 100644 index 000000000..93ea20efd --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011133.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] gma500 display driver problem with Mageia 2 alpha + + + + + + + + + +

[Mageia-dev] gma500 display driver problem with Mageia 2 alpha

+ Mika Laitio + lamikr at pilppa.org +
+ Sun Jan 8 22:54:37 CET 2012 +

+
+ +
> Sorry, i don't have a GMA500 aka Poulsbo, but from what i remember investigating
+> for alternatives to this driver (which is prone to breakage due to kernel updates)
+> maybe you want to have a look at
+> https://wiki.ubuntu.com/HardwareSupportComponentsVideoCardsPoulsbo
+> and https://wiki.archlinux.org/index.php/Poulsbo#Kernel.27s_psb-gfx_module
+
+Yes, I have read those pages and both of them confirm that the original
+psb driver that the drakconf try to install as a DKMS module for gma500
+will not work with 3.0 kernel coming with Mageia 2.0 alpha1.
+(compilation of dkms module will fail)
+
+So there would now be need for changing the drakconf to use by default
+some other driver. The easiest candidate would propably be now the
+psb_gfx module that comes already as a module in mageia 3.0 kernels.
+
+I think I am already using this new "psb_gfx" driver as I selected the
+fbdev driver in the drakconf. (Instead of selecting the default driver
+suggested that would have installed the psb dkms module and failed).
+
+This psb_gfx driver works for me, but at the moment I only have 800x600
+resolution instead of the 1280x720.
+
+Mika
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011134.html b/zarb-ml/mageia-dev/2012-January/011134.html new file mode 100644 index 000000000..268400cf0 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011134.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] urpmi installing src.rpm defaults to --buildrequires + + + + + + + + + +

[Mageia-dev] urpmi installing src.rpm defaults to --buildrequires

+ Maarten Vanraes + alien at rmail.be +
+ Sun Jan 8 23:12:41 CET 2012 +

+
+ +
Hi,
+
+i donno if it's me, but i noticed the following:
+
+[alien at localhost manaplus]$ /usr/sbin/urpmi 
+/tmp/manaplus-1.1.5.1-4.mga1.src.rpm 
+please use --buildrequires or --install-src, defaulting to --buildrequires
+
+...
+
+i noticed something was wrong when i clicked on the .src.rpm file on the file 
+browser and chose install the src.rpm file...
+
+I do believe it should default to --install-src ?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011135.html b/zarb-ml/mageia-dev/2012-January/011135.html new file mode 100644 index 000000000..9883a9385 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011135.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] urpmi installing src.rpm defaults to --buildrequires + + + + + + + + + +

[Mageia-dev] urpmi installing src.rpm defaults to --buildrequires

+ Pascal Terjan + pterjan at gmail.com +
+ Sun Jan 8 23:26:38 CET 2012 +

+
+ +
On Sun, Jan 8, 2012 at 22:12, Maarten Vanraes <alien at rmail.be> wrote:
+> Hi,
+>
+> i donno if it's me, but i noticed the following:
+>
+> [alien at localhost manaplus]$ /usr/sbin/urpmi
+> /tmp/manaplus-1.1.5.1-4.mga1.src.rpm
+> please use --buildrequires or --install-src, defaulting to --buildrequires
+>
+> ...
+>
+> i noticed something was wrong when i clicked on the .src.rpm file on the file
+> browser and chose install the src.rpm file...
+>
+> I do believe it should default to --install-src ?
+
+Maybe it should depend if you are root
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011136.html b/zarb-ml/mageia-dev/2012-January/011136.html new file mode 100644 index 000000000..f480449aa --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011136.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia + + + + + + + + + +

[Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia

+ Luc Menut + lmenut at free.fr +
+ Sun Jan 8 23:31:27 CET 2012 +

+
+ +
Le 08/01/2012 21:18, Kamil Rytarowski a écrit :
+> W dniu 08.01.2012 15:19, Luc Menut pisze:
+>> new hunspell dictionaries provides enchant-dictionary and obsoletes
+>> myspell dictionaries, but enchant still can't use the new hunspell
+>> dictionaries. I think that it should be fixed ASAP, or we will release
+>> an alpha 3 with broken spelling for lot of languages.
+>> I propose the attached patches for enchant, so that enchant can use
+>> dictionaries from /usr/share/hunspell, /usr/share/myspell, and
+>> /usr/share/dict/ooo.
+>> Anssi, Kamil, WDYT ?
+> Yes feel free to fix it.
+
+done -> enchant-1.6.0-4.mga2
+
+
+-- 
+Luc Menut
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011137.html b/zarb-ml/mageia-dev/2012-January/011137.html new file mode 100644 index 000000000..4510659db --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011137.html @@ -0,0 +1,120 @@ + + + + [Mageia-dev] Security updates needing testing (please help) + + + + + + + + + +

[Mageia-dev] Security updates needing testing (please help)

+ David Walser + luigiwalser at yahoo.com +
+ Mon Jan 9 00:02:19 CET 2012 +

+
+ +
There are a number of needed security updates for Mageia 1 that have already been built and just need QA testing so that they can be 
+released.  Most of them have testcases already described in the comments.  Please help test these if you can so we can get these updates 
+released.
+
+Needs testing on i586:
+https://bugs.mageia.org/show_bug.cgi?id=2950 cifs-utils
+https://bugs.mageia.org/show_bug.cgi?id=3311 proftpd
+https://bugs.mageia.org/show_bug.cgi?id=3980 samba
+
+Needs testing on x86_64:
+https://bugs.mageia.org/show_bug.cgi?id=3902 jasper
+https://bugs.mageia.org/show_bug.cgi?id=3937 dhcp
+https://bugs.mageia.org/show_bug.cgi?id=3939 nfs-utils
+https://bugs.mageia.org/show_bug.cgi?id=3940 libxml2
+https://bugs.mageia.org/show_bug.cgi?id=3942 icu
+https://bugs.mageia.org/show_bug.cgi?id=3982 libsndfile
+https://bugs.mageia.org/show_bug.cgi?id=3985 libtiff
+https://bugs.mageia.org/show_bug.cgi?id=3993 gif2png
+https://bugs.mageia.org/show_bug.cgi?id=3994 t1lib
+https://bugs.mageia.org/show_bug.cgi?id=3998 gimp
+https://bugs.mageia.org/show_bug.cgi?id=3999 libzip
+https://bugs.mageia.org/show_bug.cgi?id=2064 krb5-appl
+
+Needs testing on both:
+https://bugs.mageia.org/show_bug.cgi?id=3895 PHP (Thomas also needs to rebuild php-apc and php-eaccelerator)
+https://bugs.mageia.org/show_bug.cgi?id=3955 cyrus-imapd
+
+Already tested, needs pushed by sysadmins:
+https://bugs.mageia.org/show_bug.cgi?id=3941 libarchive
+https://bugs.mageia.org/show_bug.cgi?id=3995 libuser
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011138.html b/zarb-ml/mageia-dev/2012-January/011138.html new file mode 100644 index 000000000..4f63c036f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011138.html @@ -0,0 +1,128 @@ + + + + [Mageia-dev] Security updates needing testing (please help) + + + + + + + + + +

[Mageia-dev] Security updates needing testing (please help)

+ Anssi Hannula + anssi at mageia.org +
+ Mon Jan 9 00:07:42 CET 2012 +

+
+ +
On 09.01.2012 01:02, David Walser wrote:
+> There are a number of needed security updates for Mageia 1 that have already been built and just need QA testing so that they can be 
+> released.  Most of them have testcases already described in the comments.  Please help test these if you can so we can get these updates 
+> released.
+> 
+> Needs testing on i586:
+> https://bugs.mageia.org/show_bug.cgi?id=2950 cifs-utils
+> https://bugs.mageia.org/show_bug.cgi?id=3311 proftpd
+> https://bugs.mageia.org/show_bug.cgi?id=3980 samba
+> 
+> Needs testing on x86_64:
+> https://bugs.mageia.org/show_bug.cgi?id=3902 jasper
+> https://bugs.mageia.org/show_bug.cgi?id=3937 dhcp
+> https://bugs.mageia.org/show_bug.cgi?id=3939 nfs-utils
+> https://bugs.mageia.org/show_bug.cgi?id=3940 libxml2
+> https://bugs.mageia.org/show_bug.cgi?id=3942 icu
+> https://bugs.mageia.org/show_bug.cgi?id=3982 libsndfile
+> https://bugs.mageia.org/show_bug.cgi?id=3985 libtiff
+> https://bugs.mageia.org/show_bug.cgi?id=3993 gif2png
+> https://bugs.mageia.org/show_bug.cgi?id=3994 t1lib
+> https://bugs.mageia.org/show_bug.cgi?id=3998 gimp
+> https://bugs.mageia.org/show_bug.cgi?id=3999 libzip
+> https://bugs.mageia.org/show_bug.cgi?id=2064 krb5-appl
+> 
+> Needs testing on both:
+> https://bugs.mageia.org/show_bug.cgi?id=3895 PHP (Thomas also needs to rebuild php-apc and php-eaccelerator)
+> https://bugs.mageia.org/show_bug.cgi?id=3955 cyrus-imapd
+> 
+> Already tested, needs pushed by sysadmins:
+> https://bugs.mageia.org/show_bug.cgi?id=3941 libarchive
+> https://bugs.mageia.org/show_bug.cgi?id=3995 libuser
+> 
+
+What about
+https://bugs.mageia.org/show_bug.cgi?id=3601 krusader
+
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011139.html b/zarb-ml/mageia-dev/2012-January/011139.html new file mode 100644 index 000000000..289906fc7 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011139.html @@ -0,0 +1,131 @@ + + + + [Mageia-dev] Security updates needing testing (please help) + + + + + + + + + +

[Mageia-dev] Security updates needing testing (please help)

+ Manuel Hiebel + manuel at hiebel.eu +
+ Mon Jan 9 00:14:03 CET 2012 +

+
+ +
On lun., 2012-01-09 at 01:07 +0200, Anssi Hannula wrote:
+> On 09.01.2012 01:02, David Walser wrote:
+> > There are a number of needed security updates for Mageia 1 that have already been built and just need QA testing so that they can be 
+> > released.  Most of them have testcases already described in the comments.  Please help test these if you can so we can get these updates 
+> > released.
+> > 
+> > Needs testing on i586:
+> > https://bugs.mageia.org/show_bug.cgi?id=2950 cifs-utils
+> > https://bugs.mageia.org/show_bug.cgi?id=3311 proftpd
+> > https://bugs.mageia.org/show_bug.cgi?id=3980 samba
+> > 
+> > Needs testing on x86_64:
+> > https://bugs.mageia.org/show_bug.cgi?id=3902 jasper
+> > https://bugs.mageia.org/show_bug.cgi?id=3937 dhcp
+> > https://bugs.mageia.org/show_bug.cgi?id=3939 nfs-utils
+> > https://bugs.mageia.org/show_bug.cgi?id=3940 libxml2
+> > https://bugs.mageia.org/show_bug.cgi?id=3942 icu
+> > https://bugs.mageia.org/show_bug.cgi?id=3982 libsndfile
+> > https://bugs.mageia.org/show_bug.cgi?id=3985 libtiff
+> > https://bugs.mageia.org/show_bug.cgi?id=3993 gif2png
+> > https://bugs.mageia.org/show_bug.cgi?id=3994 t1lib
+> > https://bugs.mageia.org/show_bug.cgi?id=3998 gimp
+> > https://bugs.mageia.org/show_bug.cgi?id=3999 libzip
+> > https://bugs.mageia.org/show_bug.cgi?id=2064 krb5-appl
+> > 
+> > Needs testing on both:
+> > https://bugs.mageia.org/show_bug.cgi?id=3895 PHP (Thomas also needs to rebuild php-apc and php-eaccelerator)
+> > https://bugs.mageia.org/show_bug.cgi?id=3955 cyrus-imapd
+> > 
+> > Already tested, needs pushed by sysadmins:
+> > https://bugs.mageia.org/show_bug.cgi?id=3941 libarchive
+> > https://bugs.mageia.org/show_bug.cgi?id=3995 libuser
+> > 
+> 
+> What about
+> https://bugs.mageia.org/show_bug.cgi?id=3601 krusader
+> 
+And all updates candidates:
+https://bugs.mageia.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=waiting%20for%20QA%20test&sharer_id=22
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011140.html b/zarb-ml/mageia-dev/2012-January/011140.html new file mode 100644 index 000000000..516b2013b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011140.html @@ -0,0 +1,116 @@ + + + + [Mageia-dev] urpmi installing src.rpm defaults to --buildrequires + + + + + + + + + +

[Mageia-dev] urpmi installing src.rpm defaults to --buildrequires

+ Maarten Vanraes + alien at rmail.be +
+ Mon Jan 9 00:25:51 CET 2012 +

+
+ +
Op zondag 08 januari 2012 23:26:38 schreef Pascal Terjan:
+> On Sun, Jan 8, 2012 at 22:12, Maarten Vanraes <alien at rmail.be> wrote:
+> > Hi,
+> > 
+> > i donno if it's me, but i noticed the following:
+> > 
+> > [alien at localhost manaplus]$ /usr/sbin/urpmi
+> > /tmp/manaplus-1.1.5.1-4.mga1.src.rpm
+> > please use --buildrequires or --install-src, defaulting to
+> > --buildrequires
+> > 
+> > ...
+> > 
+> > i noticed something was wrong when i clicked on the .src.rpm file on the
+> > file browser and chose install the src.rpm file...
+> > 
+> > I do believe it should default to --install-src ?
+> 
+> Maybe it should depend if you are root
+
+the thing is that defaulting to --buildrequires is not intuitive, ok, it's 
+what you mostly use, but not what you expect if you're using urpmi.
+
+imho if you wanted the buildrequires; you'd exactly do that.
+
+i imagine this also changes that in GUI and you're installing .src.rpm, it 
+should NOT ask for superuser credentials... because it's not needed and 
+definately not what you want.
+
+is this behavior changed recently, or was it always like this?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011141.html b/zarb-ml/mageia-dev/2012-January/011141.html new file mode 100644 index 000000000..2a9289698 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011141.html @@ -0,0 +1,122 @@ + + + + [Mageia-dev] urpmi installing src.rpm defaults to --buildrequires + + + + + + + + + +

[Mageia-dev] urpmi installing src.rpm defaults to --buildrequires

+ Pascal Terjan + pterjan at gmail.com +
+ Mon Jan 9 01:01:26 CET 2012 +

+
+ +
On Sun, Jan 8, 2012 at 23:25, Maarten Vanraes <alien at rmail.be> wrote:
+> Op zondag 08 januari 2012 23:26:38 schreef Pascal Terjan:
+>> On Sun, Jan 8, 2012 at 22:12, Maarten Vanraes <alien at rmail.be> wrote:
+>> > Hi,
+>> >
+>> > i donno if it's me, but i noticed the following:
+>> >
+>> > [alien at localhost manaplus]$ /usr/sbin/urpmi
+>> > /tmp/manaplus-1.1.5.1-4.mga1.src.rpm
+>> > please use --buildrequires or --install-src, defaulting to
+>> > --buildrequires
+>> >
+>> > ...
+>> >
+>> > i noticed something was wrong when i clicked on the .src.rpm file on the
+>> > file browser and chose install the src.rpm file...
+>> >
+>> > I do believe it should default to --install-src ?
+>>
+>> Maybe it should depend if you are root
+>
+> the thing is that defaulting to --buildrequires is not intuitive, ok, it's
+> what you mostly use, but not what you expect if you're using urpmi.
+>
+> imho if you wanted the buildrequires; you'd exactly do that.
+
+I think urpmi used to always install buildrequires and have no option.
+The old behaviour remained as default.
+
+> i imagine this also changes that in GUI and you're installing .src.rpm, it
+> should NOT ask for superuser credentials... because it's not needed and
+> definately not what you want.
+>
+> is this behavior changed recently, or was it always like this?
+
+It has always been like that as far as I remember
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011142.html b/zarb-ml/mageia-dev/2012-January/011142.html new file mode 100644 index 000000000..53c74249e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011142.html @@ -0,0 +1,157 @@ + + + + [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia + + + + + + + + + +

[Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia

+ Kamil Rytarowski + n54 at gmx.com +
+ Mon Jan 9 01:07:38 CET 2012 +

+
+ +
W dniu 08.01.2012 22:04, Luc Menut pisze:
+> Le 08/01/2012 21:18, Kamil Rytarowski a écrit :
+>> W dniu 08.01.2012 15:19, Luc Menut pisze:
+>>> Hello,
+>
+> [...]
+>
+>>> if the versionned provides indicates the location, we can use it if
+>>> necessary in Conflicts or Requires in others packages.
+>>> e.g. currently Firefox searches dictionnaries in
+>>> /usr/share/dict/mozilla (myspell dictionaries). when we change this
+>>> location, we could add a Requires enchant-dictionary = 4.
+>>>
+>>> same for hunspell-dictionary and dictionary-%{languagecode}, a
+>>> versionned provides could indicate the location of the dictionary.
+>>> if we want to be able to remove easily all the compatibility link in
+>>> the future, we should really consider this.
+>>>
+>> If a package requires enchant-dictionary, then language specific will be
+>> chosen before Aspell. This is the whole idea behind it. (eg. Voikko is
+>> chosen before hunspell-fi and aspell-fi too).
+>
+> OK, I understand the use for enchant-dictionary.
+>
+>> And I'm against some
+>> special versioning for directories, we don't really need it.
+>
+> sorry but I don't agree with you here.
+> e.g. in coming days, we will fix firefox (and other mozilla apps) to 
+> use hunspell-dictionaries; we will update the link to
+> /usr/lib64/firefox-9.0.1/dictionaries -> /usr/share/hunspell
+> and change the requires to hunspell-dictionary.
+>
+> but hunspell-dictionaries "old generation" (mga1) provide 
+> hunspell-dictionary, and install dictionaries only in /usr/share/myspell.
+Just a technical note:
+Old Hunspell dictionaries don't provide anything additional. They are 
+just dangling without any special integration with the system, please 
+take a look: 
+http://svnweb.mageia.org/packages/cauldron/hunspell-fr/current/SPECS/hunspell-fr.spec?revision=134361&view=markup
+
+$ urpmq --provides hunspell-nl
+hunspell-nl[== 2.00-2.mga1]
+
+New Hunspell dictionaries obsolete&provide Myspell packages and come 
+into the Myspell place. They also install dictionaries into the same 
+place as the predecessor - this is why I put it into the place of the 
+old enchant-dictionary=2 place.
+
+Gentoo uses common packages for Myspell and Hunspell dictionaries. So 
+this is additional argument to put Hunspell in the place of Myspell.
+> how do you plan to handle that the fixed firefox will absolutly need 
+> hunspell-dictionaries "new generation", 
+Fix Mozilla packages (in Mga2) to use new generation dictionaries in 
+/usr/share/hunspell
+> and can't work with hunspell-dictionaries "old generation" ?
+>
+Is there need for anything needed in addition of just higher 
+version&release of every new generation hunspell-dictionary in Mga2, 
+then the one in Mga1? In Mga2 every hunspell-dictionary will be in the 
+new generation version.
+
+And I think we support Mga1->Mga2 full migration, so everything will be 
+working.
+
+Am I right?
+>
+> regards,
+>
+> Luc
+>
+>
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011143.html b/zarb-ml/mageia-dev/2012-January/011143.html new file mode 100644 index 000000000..d5b953c98 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011143.html @@ -0,0 +1,123 @@ + + + + [Mageia-dev] urpmi installing src.rpm defaults to --buildrequires + + + + + + + + + +

[Mageia-dev] urpmi installing src.rpm defaults to --buildrequires

+ Maarten Vanraes + alien at rmail.be +
+ Mon Jan 9 01:29:12 CET 2012 +

+
+ +
Op maandag 09 januari 2012 01:01:26 schreef Pascal Terjan:
+> On Sun, Jan 8, 2012 at 23:25, Maarten Vanraes <alien at rmail.be> wrote:
+> > Op zondag 08 januari 2012 23:26:38 schreef Pascal Terjan:
+> >> On Sun, Jan 8, 2012 at 22:12, Maarten Vanraes <alien at rmail.be> wrote:
+> >> > Hi,
+> >> > 
+> >> > i donno if it's me, but i noticed the following:
+> >> > 
+> >> > [alien at localhost manaplus]$ /usr/sbin/urpmi
+> >> > /tmp/manaplus-1.1.5.1-4.mga1.src.rpm
+> >> > please use --buildrequires or --install-src, defaulting to
+> >> > --buildrequires
+> >> > 
+> >> > ...
+> >> > 
+> >> > i noticed something was wrong when i clicked on the .src.rpm file on
+> >> > the file browser and chose install the src.rpm file...
+> >> > 
+> >> > I do believe it should default to --install-src ?
+> >> 
+> >> Maybe it should depend if you are root
+> > 
+> > the thing is that defaulting to --buildrequires is not intuitive, ok,
+> > it's what you mostly use, but not what you expect if you're using urpmi.
+> > 
+> > imho if you wanted the buildrequires; you'd exactly do that.
+> 
+> I think urpmi used to always install buildrequires and have no option.
+> The old behaviour remained as default.
+> 
+> > i imagine this also changes that in GUI and you're installing .src.rpm,
+> > it should NOT ask for superuser credentials... because it's not needed
+> > and definately not what you want.
+> > 
+> > is this behavior changed recently, or was it always like this?
+> 
+> It has always been like that as far as I remember
+
+hmm, maybe i've always used rpm -ivh file.src.rpm then...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011144.html b/zarb-ml/mageia-dev/2012-January/011144.html new file mode 100644 index 000000000..848fc72a5 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011144.html @@ -0,0 +1,219 @@ + + + + [Mageia-dev] mentors + apprentices + + + + + + + + + +

[Mageia-dev] mentors + apprentices

+ andre999 + andre999mga at laposte.net +
+ Mon Jan 9 07:04:47 CET 2012 +

+
+ +
Hi everyone,
+
+We have a newly qualified packager, kamil, who is already maintaining over 160 
+packages.  He is largely responsible for the considerabe decrease in 
+unmaintained packages in the last few days, although many other packagers have 
+contributed.
+
+We have another Mandriva packager who has joined our packaging team, nelg (Glen 
+Ogilvie), and is bringing himself up to date for Mageia with jquelin.
+
+Also note that philippem (Philippe Makowski) has just posted a message inviting 
+potential apprentices to contact him for mentoring.
+Any other mentors who feel that they can take on another apprentice are invited 
+to post to this thread.
+
+Currently we have 4 apprentice candidates looking for a mentor.
+
+am2605 (Andrew Myers), has been waiting now about 5 weeks.
+He is a longtime Fedora, a web developer, interested in packaging related to 
+Gnome, Java, Eclipse among others, teaching himself Mageia packaging basics.
+
+cddesjar (Christopher Desjardins), has been waiting about 3 weeks.
+He has basic .deb and .rpm packaging experience, including doing texworks and 
+jags on Mageia for himself.  Would like to maintain these and R-base.
+
+dglent (Dimitrios Glentadakis), had been waiting about a week.
+He has experience packaging in his personal repos (mageia-gr.org and previously 
+mandrivalinux.gr) with applications he uses, which he would like to package for 
+Mageia repos.  He speaks French and English.
+
+cyprix (Sam Bailey)
+He is a long time Mandriva then Mageia user, who runs hosting servers in his 
+work, and is interested in packaging programs for hosting and web-app services.
+
+Note that those who have been waiting the longest are at the top of the list.
+
+You can find more details at:
+https://wiki.mageia.org/en/Becoming_a_Mageia_Packager#Packager_apprentice_candidates
+
+Mentors, let me know who you take on, and I'll update the tables for you.
+
+Thanks :-)
+
+----
+
+Anyone else looking for a mentor, let me know so I can add your name as an 
+apprentice candidate -- or you can do it yourself.
+https://wiki.mageia.org/en/Becoming_a_Mageia_Packager#Packager_apprentice_candidates 
+
+
+See also the previous sections, on becoming a Mageia packager :
+https://wiki.mageia.org/mw-en/index.php?title=Becoming_a_Mageia_Packager&action=submit#What_is_needed_to_become_a_Mageia_packager
+
+To find a mentor, it helps to also post to this list (mageia-dev), or hang out 
+on IRC at freenode #mageia-mentoring.
+Don't forget that if you contact a mentor directly, they know that you are 
+actively interested.
+
+Regards :-)
+
+-- 
+André
+(Packager mentoring program coordinator)
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011145.html b/zarb-ml/mageia-dev/2012-January/011145.html new file mode 100644 index 000000000..67c436d57 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011145.html @@ -0,0 +1,228 @@ + + + + [Mageia-dev] mentors + apprentices + + + + + + + + + +

[Mageia-dev] mentors + apprentices

+ D.Morgan + dmorganec at gmail.com +
+ Mon Jan 9 07:25:09 CET 2012 +

+
+ +
On Mon, Jan 9, 2012 at 7:04 AM, andre999 <andre999mga at laposte.net> wrote:
+> Hi everyone,
+>
+> We have a newly qualified packager, kamil, who is already maintaining over
+> 160 packages.  He is largely responsible for the considerabe decrease in
+> unmaintained packages in the last few days, although many other packagers
+> have contributed.
+>
+> We have another Mandriva packager who has joined our packaging team, nelg
+> (Glen Ogilvie), and is bringing himself up to date for Mageia with jquelin.
+>
+> Also note that philippem (Philippe Makowski) has just posted a message
+> inviting potential apprentices to contact him for mentoring.
+> Any other mentors who feel that they can take on another apprentice are
+> invited to post to this thread.
+>
+> Currently we have 4 apprentice candidates looking for a mentor.
+>
+> am2605 (Andrew Myers), has been waiting now about 5 weeks.
+> He is a longtime Fedora, a web developer, interested in packaging related to
+> Gnome, Java, Eclipse among others, teaching himself Mageia packaging basics.
+
+when i will have a new slot free i would be interested in this package
+as he knows java / eclipse. So let see when i will have one (
+shouldn't be long )
+
+
+>
+> cddesjar (Christopher Desjardins), has been waiting about 3 weeks.
+> He has basic .deb and .rpm packaging experience, including doing texworks
+> and jags on Mageia for himself.  Would like to maintain these and R-base.
+>
+> dglent (Dimitrios Glentadakis), had been waiting about a week.
+> He has experience packaging in his personal repos (mageia-gr.org and
+> previously mandrivalinux.gr) with applications he uses, which he would like
+> to package for Mageia repos.  He speaks French and English.
+>
+> cyprix (Sam Bailey)
+> He is a long time Mandriva then Mageia user, who runs hosting servers in his
+> work, and is interested in packaging programs for hosting and web-app
+> services.
+>
+> Note that those who have been waiting the longest are at the top of the
+> list.
+>
+> You can find more details at:
+> https://wiki.mageia.org/en/Becoming_a_Mageia_Packager#Packager_apprentice_candidates
+>
+> Mentors, let me know who you take on, and I'll update the tables for you.
+>
+> Thanks :-)
+>
+> ----
+>
+> Anyone else looking for a mentor, let me know so I can add your name as an
+> apprentice candidate -- or you can do it yourself.
+> https://wiki.mageia.org/en/Becoming_a_Mageia_Packager#Packager_apprentice_candidates
+>
+> See also the previous sections, on becoming a Mageia packager :
+> https://wiki.mageia.org/mw-en/index.php?title=Becoming_a_Mageia_Packager&action=submit#What_is_needed_to_become_a_Mageia_packager
+>
+> To find a mentor, it helps to also post to this list (mageia-dev), or hang
+> out on IRC at freenode #mageia-mentoring.
+> Don't forget that if you contact a mentor directly, they know that you are
+> actively interested.
+>
+> Regards :-)
+>
+> --
+> André
+> (Packager mentoring program coordinator)
+>
+>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011146.html b/zarb-ml/mageia-dev/2012-January/011146.html new file mode 100644 index 000000000..4f588633a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011146.html @@ -0,0 +1,73 @@ + + + + [Mageia-dev] mentors + apprentices + + + + + + + + + +

[Mageia-dev] mentors + apprentices

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Mon Jan 9 10:06:56 CET 2012 +

+
+ +
Le 01/01/2012 03:11, Josh King a écrit :
+> On 12/31/2011 02:29 AM, andre999 wrote:
+>> Florian Hubold a écrit :
+>>> According to
+>>> https://wiki.mageia.org/en/Becoming_a_Mageia_Packager#Mentoring_team
+>>> he is already mentored by guillomovitch, or is that incorrect?
+>>>
+>> sorry I overlooked that, from many months back -- he didn't start due to
+>> health problems, which are over now
+>>
+> So should I begin working with guillomovitch, or someone else? Sorry for
+> the sort of OT post just wanted to make sure.
+yes, just ping me on IRC when you're ready.
+
+-- 
+BOFH excuse #64:
+
+CPU needs recalibration
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011147.html b/zarb-ml/mageia-dev/2012-January/011147.html new file mode 100644 index 000000000..f8d5c1e54 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011147.html @@ -0,0 +1,168 @@ + + + + [Mageia-dev] mentors + apprentices + + + + + + + + + +

[Mageia-dev] mentors + apprentices

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Mon Jan 9 10:07:50 CET 2012 +

+
+ +
Le 09/01/2012 07:04, andre999 a écrit :
+> cyprix (Sam Bailey)
+> He is a long time Mandriva then Mageia user, who runs hosting servers in
+> his work, and is interested in packaging programs for hosting and
+> web-app services.
+I can mentor him (as everyone else intested in servers applications in 
+general).
+
+-- 
+BOFH excuse #2:
+
+solar flares
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011148.html b/zarb-ml/mageia-dev/2012-January/011148.html new file mode 100644 index 000000000..95ef7ad1a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011148.html @@ -0,0 +1,182 @@ + + + + [Mageia-dev] packaging help required + + + + + + + + + +

[Mageia-dev] packaging help required

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Mon Jan 9 10:27:33 CET 2012 +

+
+ +
Hello list.
+
+I've had a look at jenkins, which is an interesting continuous 
+integration build bot. But it's yet another piece^H^H^Henterprise-grade 
+java application, and the currently available packages
+(http://pkg.jenkins-ci.org/redhat/) exhibit all classical problems:
+- no building from sources
+- private copies of libraries
+- repackaging of another packaging system (war)
+- horrible suze-flavour init script
+
+I can eventually fix the last point, but I'm unable to adress the 
+others. Is there anyone else interested in sharing the work ?
+
+-- 
+BOFH excuse #179:
+
+multicasts on broken packets
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011149.html b/zarb-ml/mageia-dev/2012-January/011149.html new file mode 100644 index 000000000..62f5fb096 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011149.html @@ -0,0 +1,179 @@ + + + + [Mageia-dev] RFT: xen support + + + + + + + + + +

[Mageia-dev] RFT: xen support

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Mon Jan 9 10:26:35 CET 2012 +

+
+ +
On 11 April 2011 10:33, Thomas Backlund <tmb at iki.fi> wrote:
+> And as of kernel-2.6.38.2-4.mga1 there has been some cleanups and addons for
+> xen:
+>
+> There is now a kernel-xen-pvops that also should work as dom0.
+>
+> Now this is mostly upstream kenel.org code so its not as fully
+> featured as the old kernel-xen. You can see the features listed here:
+> http://wiki.xensource.com/xenwiki/XenParavirtOps.
+>
+> There is one exception: our 2.6.38 kernel has xen-netback backend driver
+> added.
+>
+> So those of you that have been using xen, please test atleast the following:
+>
+> - check that kernel-server still works as a xen guest
+> - try to use kernel-xen-pvops as dom0 and see how it works
+> (you can also try to use kernel-xen-pvops as a normal xen guest)
+
+Doesn't that mean that when running in XEN, the installer shouldn't
+pick kernel-server
+instead of kernel-desktop? (since we've no dom0 support in the later)
+Or even kernel-xen-pvps if there's no HW support for virtualisation?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011150.html b/zarb-ml/mageia-dev/2012-January/011150.html new file mode 100644 index 000000000..e1e98bf3a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011150.html @@ -0,0 +1,194 @@ + + + + [Mageia-dev] RFT: xen support + + + + + + + + + +

[Mageia-dev] RFT: xen support

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Mon Jan 9 10:49:39 CET 2012 +

+
+ +
Le 09/01/2012 10:26, Thierry Vignaud a écrit :
+> On 11 April 2011 10:33, Thomas Backlund<tmb at iki.fi>  wrote:
+>> And as of kernel-2.6.38.2-4.mga1 there has been some cleanups and addons for
+>> xen:
+>>
+>> There is now a kernel-xen-pvops that also should work as dom0.
+>>
+>> Now this is mostly upstream kenel.org code so its not as fully
+>> featured as the old kernel-xen. You can see the features listed here:
+>> http://wiki.xensource.com/xenwiki/XenParavirtOps.
+>>
+>> There is one exception: our 2.6.38 kernel has xen-netback backend driver
+>> added.
+>>
+>> So those of you that have been using xen, please test atleast the following:
+>>
+>> - check that kernel-server still works as a xen guest
+>> - try to use kernel-xen-pvops as dom0 and see how it works
+>> (you can also try to use kernel-xen-pvops as a normal xen guest)
+>
+> Doesn't that mean that when running in XEN, the installer shouldn't
+> pick kernel-server
+> instead of kernel-desktop? (since we've no dom0 support in the later)
+> Or even kernel-xen-pvps if there's no HW support for virtualisation?
+If 'running in Xen' means 'running as guest', you don't need any special 
+kernel for hardware virtualisation, and just a kernel with Xen support 
+for paravirtualisation. The dom0 support is only needed for the xen 
+host. Which means the installer kernel itself should have xen support to 
+be runnable in any context.
+
+By the way, kernel-xen-pvops isn't needed anymore, and could be safely 
+dropped AFAIK.
+
+-- 
+BOFH excuse #24:
+
+network packets travelling uphill (use a carrier pigeon)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011151.html b/zarb-ml/mageia-dev/2012-January/011151.html new file mode 100644 index 000000000..e83236e65 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011151.html @@ -0,0 +1,180 @@ + + + + [Mageia-dev] RFT: xen support + + + + + + + + + +

[Mageia-dev] RFT: xen support

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Mon Jan 9 11:04:21 CET 2012 +

+
+ +
On 9 January 2012 10:26, Thierry Vignaud <thierry.vignaud at gmail.com> wrote:
+> Doesn't that mean that when running in XEN, the installer shouldn't
+> pick kernel-server
+> instead of kernel-desktop? (since we've no dom0 support in the later)
+> Or even kernel-xen-pvps if there's no HW support for virtualisation?
+
+Sg like this.
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: xen1.diff
+Type: application/octet-stream
+Size: 2448 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20120109/d93f433f/attachment-0002.obj>
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: xen2.diff
+Type: application/octet-stream
+Size: 2437 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20120109/d93f433f/attachment-0003.obj>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011152.html b/zarb-ml/mageia-dev/2012-January/011152.html new file mode 100644 index 000000000..af241ea7c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011152.html @@ -0,0 +1,192 @@ + + + + [Mageia-dev] RFT: xen support + + + + + + + + + +

[Mageia-dev] RFT: xen support

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Mon Jan 9 11:06:02 CET 2012 +

+
+ +
On 9 January 2012 10:49, Guillaume Rousse <guillomovitch at gmail.com> wrote:
+>>> And as of kernel-2.6.38.2-4.mga1 there has been some cleanups and addons
+>>> for
+>>> xen:
+>>>
+>>> There is now a kernel-xen-pvops that also should work as dom0.
+>>>
+>>> Now this is mostly upstream kenel.org code so its not as fully
+>>> featured as the old kernel-xen. You can see the features listed here:
+>>> http://wiki.xensource.com/xenwiki/XenParavirtOps.
+>>>
+>>> There is one exception: our 2.6.38 kernel has xen-netback backend driver
+>>> added.
+>>>
+>>> So those of you that have been using xen, please test atleast the
+>>> following:
+>>>
+>>> - check that kernel-server still works as a xen guest
+>>> - try to use kernel-xen-pvops as dom0 and see how it works
+>>> (you can also try to use kernel-xen-pvops as a normal xen guest)
+>>
+>>
+>> Doesn't that mean that when running in XEN, the installer shouldn't
+>> pick kernel-server
+>> instead of kernel-desktop? (since we've no dom0 support in the later)
+>> Or even kernel-xen-pvps if there's no HW support for virtualisation?
+>
+> If 'running in Xen' means 'running as guest', you don't need any special
+> kernel for hardware virtualisation, and just a kernel with Xen support for
+> paravirtualisation. The dom0 support is only needed for the xen host. Which
+> means the installer kernel itself should have xen support to be runnable in
+> any context.
+
+Either we should restore alt1 in installer or we should enable DOM0 support
+in desktop kernel
+Then we sh
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011153.html b/zarb-ml/mageia-dev/2012-January/011153.html new file mode 100644 index 000000000..459b9e7c5 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011153.html @@ -0,0 +1,177 @@ + + + + [Mageia-dev] RFT: xen support + + + + + + + + + +

[Mageia-dev] RFT: xen support

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Mon Jan 9 11:08:31 CET 2012 +

+
+ +
On 9 January 2012 11:06, Thierry Vignaud <thierry.vignaud at gmail.com> wrote:
+>>>> - check that kernel-server still works as a xen guest
+>>>> - try to use kernel-xen-pvops as dom0 and see how it works
+>>>> (you can also try to use kernel-xen-pvops as a normal xen guest)
+>>>
+>>> Doesn't that mean that when running in XEN, the installer shouldn't
+>>> pick kernel-server
+>>> instead of kernel-desktop? (since we've no dom0 support in the later)
+>>> Or even kernel-xen-pvps if there's no HW support for virtualisation?
+>>
+>> If 'running in Xen' means 'running as guest', you don't need any special
+>> kernel for hardware virtualisation, and just a kernel with Xen support for
+>> paravirtualisation. The dom0 support is only needed for the xen host. Which
+>> means the installer kernel itself should have xen support to be runnable in
+>> any context.
+>
+> Either we should restore alt1 in installer or we should enable DOM0 support
+> in desktop kernel
+
+I would rahther choose the later as server kernel doesn't work everywhere
+(PAE requirement on ia32...) like Fedora does
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011154.html b/zarb-ml/mageia-dev/2012-January/011154.html new file mode 100644 index 000000000..a87c70102 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011154.html @@ -0,0 +1,201 @@ + + + + [Mageia-dev] RFT: xen support + + + + + + + + + +

[Mageia-dev] RFT: xen support

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Mon Jan 9 11:25:30 CET 2012 +

+
+ +
Le 09/01/2012 11:06, Thierry Vignaud a écrit :
+> On 9 January 2012 10:49, Guillaume Rousse<guillomovitch at gmail.com>  wrote:
+>>>> And as of kernel-2.6.38.2-4.mga1 there has been some cleanups and addons
+>>>> for
+>>>> xen:
+>>>>
+>>>> There is now a kernel-xen-pvops that also should work as dom0.
+>>>>
+>>>> Now this is mostly upstream kenel.org code so its not as fully
+>>>> featured as the old kernel-xen. You can see the features listed here:
+>>>> http://wiki.xensource.com/xenwiki/XenParavirtOps.
+>>>>
+>>>> There is one exception: our 2.6.38 kernel has xen-netback backend driver
+>>>> added.
+>>>>
+>>>> So those of you that have been using xen, please test atleast the
+>>>> following:
+>>>>
+>>>> - check that kernel-server still works as a xen guest
+>>>> - try to use kernel-xen-pvops as dom0 and see how it works
+>>>> (you can also try to use kernel-xen-pvops as a normal xen guest)
+>>>
+>>>
+>>> Doesn't that mean that when running in XEN, the installer shouldn't
+>>> pick kernel-server
+>>> instead of kernel-desktop? (since we've no dom0 support in the later)
+>>> Or even kernel-xen-pvps if there's no HW support for virtualisation?
+>>
+>> If 'running in Xen' means 'running as guest', you don't need any special
+>> kernel for hardware virtualisation, and just a kernel with Xen support for
+>> paravirtualisation. The dom0 support is only needed for the xen host. Which
+>> means the installer kernel itself should have xen support to be runnable in
+>> any context.
+>
+> Either we should restore alt1 in installer or we should enable DOM0 support
+> in desktop kernel
+You seems to be confusing xen basic support and xen dom0 support. The 
+later is only useful for server kernel, while the first one should be 
+enabled for all kernels. Provided the original concerns with nvidia AGP 
+support are fixed now.
+
+-- 
+BOFH excuse #75:
+
+There isn't any problem
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011155.html b/zarb-ml/mageia-dev/2012-January/011155.html new file mode 100644 index 000000000..7c1fbf36e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011155.html @@ -0,0 +1,167 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release perl-FusionInventory-Agent-2.1.13-1.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release perl-FusionInventory-Agent-2.1.13-1.mga2

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Mon Jan 9 11:34:16 CET 2012 +

+
+ +
Le 09/01/2012 11:31, jquelin a écrit :
+[..]
+> jquelin<jquelin>  2.1.13-1.mga2:
+> + Revision: 193899
+> - imported package perl-FusionInventory-Agent
+This package already exists as 'fusioninventory-agent'.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011156.html b/zarb-ml/mageia-dev/2012-January/011156.html new file mode 100644 index 000000000..2f2bf3d3c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011156.html @@ -0,0 +1,175 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release perl-FusionInventory-Agent-2.1.13-1.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release perl-FusionInventory-Agent-2.1.13-1.mga2

+ Jerome Quelin + jquelin at gmail.com +
+ Mon Jan 9 11:45:10 CET 2012 +

+
+ +
On 12/01/09 11:34 +0100, Guillaume Rousse wrote:
+> >jquelin<jquelin>  2.1.13-1.mga2:
+> >+ Revision: 193899
+> >- imported package perl-FusionInventory-Agent
+> This package already exists as 'fusioninventory-agent'.
+
+hmm. then why are there broken dependencies on:
+perl(FusionInventory::Agent::AccountInfo)
+perl(FusionInventory::Agent::Network)
+perl(FusionInventory::Agent::SNMP)
+perl(FusionInventory::Agent::XML::Query::SimpleMessage)
+perl(FusionInventory::Agent::XML::Response::Prolog)
+perl(FusionInventory::Logger)
+
+jérôme 
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011157.html b/zarb-ml/mageia-dev/2012-January/011157.html new file mode 100644 index 000000000..482d54672 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011157.html @@ -0,0 +1,183 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release perl-FusionInventory-Agent-2.1.13-1.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release perl-FusionInventory-Agent-2.1.13-1.mga2

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Mon Jan 9 11:53:08 CET 2012 +

+
+ +
Le 09/01/2012 11:45, Jerome Quelin a écrit :
+> On 12/01/09 11:34 +0100, Guillaume Rousse wrote:
+>>> jquelin<jquelin>   2.1.13-1.mga2:
+>>> + Revision: 193899
+>>> - imported package perl-FusionInventory-Agent
+>> This package already exists as 'fusioninventory-agent'.
+>
+> hmm. then why are there broken dependencies on:
+> perl(FusionInventory::Agent::AccountInfo)
+> perl(FusionInventory::Agent::Network)
+> perl(FusionInventory::Agent::SNMP)
+> perl(FusionInventory::Agent::XML::Query::SimpleMessage)
+> perl(FusionInventory::Agent::XML::Response::Prolog)
+> perl(FusionInventory::Logger)
+Because what is packaged now is the 2.2.0 beta version of the agent, and 
+I'm battling with my fellow developper to have him release beta versions 
+of the plugins too. I'm gonna either take over as upstream release 
+manager, or package git snapshots instead.
+
+-- 
+BOFH excuse #17:
+
+fat electrons in the lines
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011158.html b/zarb-ml/mageia-dev/2012-January/011158.html new file mode 100644 index 000000000..9040dc29c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011158.html @@ -0,0 +1,174 @@ + + + + [Mageia-dev] RFT: xen support + + + + + + + + + +

[Mageia-dev] RFT: xen support

+ Thomas Backlund + tmb at mageia.org +
+ Mon Jan 9 12:01:21 CET 2012 +

+
+ +
Guillaume Rousse skrev 9.1.2012 12:25:
+
+> You seems to be confusing xen basic support and xen dom0 support. The
+> later is only useful for server kernel, while the first one should be
+> enabled for all kernels. Provided the original concerns with nvidia AGP
+> support are fixed now.
+>
+
+We wont enable xen support on 32bit desktop* kernels as XEN requires PAE
+
+And netbook kernels wont get xen support on either arch.
+
+For 64bit kernels it can be considered.
+
+
+And I think I'll can merge xen-pvops with server kernel.
+
+--
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011159.html b/zarb-ml/mageia-dev/2012-January/011159.html new file mode 100644 index 000000000..4fdc4edb0 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011159.html @@ -0,0 +1,119 @@ + + + + [Mageia-dev] [RFC] new ldetect, using libkmod + + + + + + + + + +

[Mageia-dev] [RFC] new ldetect, using libkmod

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Mon Jan 9 12:28:25 CET 2012 +

+
+ +
'Twas brillig, and Thierry Vignaud at 06/01/12 10:56 did gyre and gimble:
+> Hi
+> 
+> I've uploaded in core/updates_testing a new ldetect, using libkmod instead
+> of libmodprobe. I've also fixed several memleaks.
+> There you'll find a drakxtools rebuild for this new libldetect.
+> 
+> This result in:
+> - faster lspcidrake
+> - using quite less RAM ; eg on my test machine:
+>   o harddrake2 uses 106M of resident memory instead of 127
+>   o mcc utilise uses 47M of resident memory instead of 48M
+> 
+> Output of lspcidrake should be the same as before modulo for some ISA bridges.
+> Please report any significant change.
+> 
+> How to test:
+>   lspcidrake > /tmp/pci1
+>   urpmi.update 'Core Updates Testing'
+>   urpmi --media='Core Updates Testing' ldetect
+>   lspcidrake > /tmp/pci2
+>   diff -u /tmp/pci[12]
+> 
+> See you
+
+
+[root at jimmy ~]# urpmi --media="CoreUpdatesTesting-64" ldetect
+A requested package cannot be installed:
+lib64ldetect0.12-0.12.0-0.5.mga2.x86_64 (due to unsatisfied
+libkmod.so.1()(64bit))
+Continue installation anyway? (Y/n) n
+
+Can't seem to find that file :s
+
+Col
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011160.html b/zarb-ml/mageia-dev/2012-January/011160.html new file mode 100644 index 000000000..25601f3e4 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011160.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] [RFC] new ldetect, using libkmod + + + + + + + + + +

[Mageia-dev] [RFC] new ldetect, using libkmod

+ Thomas Backlund + tmb at mageia.org +
+ Mon Jan 9 12:38:55 CET 2012 +

+
+ +
Colin Guthrie skrev 9.1.2012 13:28:
+>
+> [root at jimmy ~]# urpmi --media="CoreUpdatesTesting-64" ldetect
+> A requested package cannot be installed:
+> lib64ldetect0.12-0.12.0-0.5.mga2.x86_64 (due to unsatisfied
+> libkmod.so.1()(64bit))
+> Continue installation anyway? (Y/n) n
+>
+> Can't seem to find that file :s
+>
+
+you forgot about --search-media vs --media again :)
+
+--
+Thomas
+
+ + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011161.html b/zarb-ml/mageia-dev/2012-January/011161.html new file mode 100644 index 000000000..61d42af06 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011161.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] [RFC] new ldetect, using libkmod + + + + + + + + + +

[Mageia-dev] [RFC] new ldetect, using libkmod

+ Thomas Backlund + tmb at mageia.org +
+ Mon Jan 9 12:39:28 CET 2012 +

+
+ +
Thomas Backlund skrev 9.1.2012 13:38:
+> Colin Guthrie skrev 9.1.2012 13:28:
+>>
+>> [root at jimmy ~]# urpmi --media="CoreUpdatesTesting-64" ldetect
+>> A requested package cannot be installed:
+>> lib64ldetect0.12-0.12.0-0.5.mga2.x86_64 (due to unsatisfied
+>> libkmod.so.1()(64bit))
+>> Continue installation anyway? (Y/n) n
+>>
+>> Can't seem to find that file :s
+>>
+>
+> you forgot about --search-media vs --media again :)
+>
+
+and that would be --searchmedia
+
+> --
+> Thomas
+
+
+ + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011162.html b/zarb-ml/mageia-dev/2012-January/011162.html new file mode 100644 index 000000000..f40d46eba --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011162.html @@ -0,0 +1,128 @@ + + + + [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia + + + + + + + + + +

[Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia

+ Kamil Rytarowski + n54 at gmx.com +
+ Mon Jan 9 13:05:37 CET 2012 +

+
+ +
W dniu 08.01.2012 20:01, Anssi Hannula pisze:
+Hello Anssi!
+> On 08.01.2012 16:19, Luc Menut wrote:
+>> some comments about the policy:
+>>
+>> Version:        1.0
+>> Release:        %mkrel %{upstream_release}.%{rel}
+>>
+>> I don't think it will be possible to use Version 1.0 and upstream
+>> version only in the release; most hunspell dictionaries already use
+>> upstream version as version and have a version>  1.0.
+> Strong +1 from me for not using hardcoded Version 1.0, please instead
+> use the %upstream_release in Version.
+>
+> I don't see any reason to break the versioning policy here.
+Excuse me. I've added a note to the policy.
+We will keep the same versions of dictionaries like Fedora. Version 
+"1.0" is just for Esperanto.
+>> Because I think that it could be usefull that the versionned provides
+>> indicates the location of the dictionary:
+>> - current enchant-dictionary = 2 ->>  /usr/share/dict/mozilla
+>> - enchant-dictionary from hunspell ->>  enchant-dictionary = 4 ->>
+>> /usr/share/hunspell and /usr/share/myspell,
+>> - enchant-dictionary from future hunspell without compatibility link in
+>> /usr/share/myspell ->>  enchant-dictionary = 5 ->>  /usr/share/hunspell only,
+>> - ...
+>>
+>> (it seems weird for me to use the same "enchant-dictionary = 2"
+>> versionned provide, both for "deprecated" myspell dictionaries, and new
+>> hunspell dictionaries.)
+>>
+>> if the versionned provides indicates the location, we can use it if
+>> necessary in Conflicts or Requires in others packages.
+>> e.g. currently Firefox searches dictionnaries in /usr/share/dict/mozilla
+>> (myspell dictionaries). when we change this location, we could add a
+>> Requires enchant-dictionary = 4.
+> IMO a better way to handle this would be
+> Provides:	mozilla-dictionary
+> Provides:	hunspell-dictionary
+> Provides:	myspell-dictionary
+>
+> based on which directories are contained in the package, since other
+> packages are generally interested in whether the package provides
+> dictionaries in a specific location. (i.e. a package using dictionaries
+> in /usr/share/hunspell doesn't care if there are some extra dictionaries
+> provided in other directories).
+I like this idea!
+Luc what do you think? Maybe we can consider the providing 
+"mozilla-dictionary" and then even install symlinks into a specific 
+directory like /usr/share/mozilla-dictionary ?
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011163.html b/zarb-ml/mageia-dev/2012-January/011163.html new file mode 100644 index 000000000..9a928e0f2 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011163.html @@ -0,0 +1,168 @@ + + + + [Mageia-dev] patches overlapping + + + + + + + + + +

[Mageia-dev] patches overlapping

+ Florent Monnier + monnier.florent at gmail.com +
+ Mon Jan 9 13:54:49 CET 2012 +

+
+ +
Hi,
+
+I have a package with 2 patches, each modifying one line that is in the 
+context of the other patch. So the second one that is applied is rejected.
+
+I would like to know what is the correct way to handle this?
+
+Should the context of the second one correspond to the modified version by the 
+first one?
+(Also using only 2 lines of context instead of 3 lines would resolve it in my 
+case.)
+
+Thanks
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011164.html b/zarb-ml/mageia-dev/2012-January/011164.html new file mode 100644 index 000000000..5305d7448 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011164.html @@ -0,0 +1,192 @@ + + + + [Mageia-dev] patches overlapping + + + + + + + + + +

[Mageia-dev] patches overlapping

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Mon Jan 9 14:29:11 CET 2012 +

+
+ +
'Twas brillig, and Florent Monnier at 09/01/12 12:54 did gyre and gimble:
+> Hi,
+> 
+> I have a package with 2 patches, each modifying one line that is in the 
+> context of the other patch. So the second one that is applied is rejected.
+> 
+> I would like to know what is the correct way to handle this?
+> 
+> Should the context of the second one correspond to the modified version by the 
+> first one?
+> (Also using only 2 lines of context instead of 3 lines would resolve it in my 
+> case.)
+
+They should apply in order. So if the first one changes something that
+the second one uses in it's context, the second patch should be updated
+to include the changed context.
+
+But better to try and push the changes upstream if at all possible.  If
+it's some customisation that we do that isn't relevant for upstream then
+it may be easier to combine the patches into one, again only if that's
+relevant to do so.
+
+Col
+
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011165.html b/zarb-ml/mageia-dev/2012-January/011165.html new file mode 100644 index 000000000..12890f4c4 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011165.html @@ -0,0 +1,122 @@ + + + + [Mageia-dev] [RFC] new ldetect, using libkmod + + + + + + + + + +

[Mageia-dev] [RFC] new ldetect, using libkmod

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Mon Jan 9 14:33:10 CET 2012 +

+
+ +
'Twas brillig, and Thomas Backlund at 09/01/12 11:39 did gyre and gimble:
+> Thomas Backlund skrev 9.1.2012 13:38:
+>> Colin Guthrie skrev 9.1.2012 13:28:
+>>>
+>>> [root at jimmy ~]# urpmi --media="CoreUpdatesTesting-64" ldetect
+>>> A requested package cannot be installed:
+>>> lib64ldetect0.12-0.12.0-0.5.mga2.x86_64 (due to unsatisfied
+>>> libkmod.so.1()(64bit))
+>>> Continue installation anyway? (Y/n) n
+>>>
+>>> Can't seem to find that file :s
+>>>
+>>
+>> you forgot about --search-media vs --media again :)
+>>
+> 
+> and that would be --searchmedia
+
+Yes, yes I did, but I blame TV for his example :D
+
+
+However, what really tripped my up was this command:
+
+[root at jimmy ~]# urpmi "libkmod.so.1()(64bit))"
+No package named libkmod.so.1()(64bit))
+
+
+But if you look closely, there is an extra ) in there.... so a
+copy+paste error occurring between my chair and keyboard again!
+
+*sigh*
+
+I am clever sometimes.... honest! :p
+
+Cheers
+
+Col
+
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011166.html b/zarb-ml/mageia-dev/2012-January/011166.html new file mode 100644 index 000000000..2f5c0d576 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011166.html @@ -0,0 +1,136 @@ + + + + [Mageia-dev] [RFC] new ldetect, using libkmod + + + + + + + + + +

[Mageia-dev] [RFC] new ldetect, using libkmod

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Mon Jan 9 14:37:37 CET 2012 +

+
+ +
'Twas brillig, and Thierry Vignaud at 06/01/12 10:56 did gyre and gimble:
+> Hi
+> 
+> I've uploaded in core/updates_testing a new ldetect, using libkmod instead
+> of libmodprobe. I've also fixed several memleaks.
+> There you'll find a drakxtools rebuild for this new libldetect.
+> 
+> This result in:
+> - faster lspcidrake
+> - using quite less RAM ; eg on my test machine:
+>   o harddrake2 uses 106M of resident memory instead of 127
+>   o mcc utilise uses 47M of resident memory instead of 48M
+> 
+> Output of lspcidrake should be the same as before modulo for some ISA bridges.
+> Please report any significant change.
+> 
+> How to test:
+>   lspcidrake > /tmp/pci1
+>   urpmi.update 'Core Updates Testing'
+>   urpmi --media='Core Updates Testing' ldetect
+>   lspcidrake > /tmp/pci2
+>   diff -u /tmp/pci[12]
+
+My diff:
+
+[root at jimmy ~]# diff -u /tmp/pci[12]
+--- /tmp/pci1	2012-01-09 11:26:05.114996239 +0000
++++ /tmp/pci2	2012-01-09 13:33:27.295455837 +0000
+@@ -6,7 +6,7 @@
+ iwl4965         : Intel Corporation|PRO/Wireless 4965 AG or AGN
+[Kedron] Network Connection [NETWORK_OTHER] (rev: 61)
+ i2c_i801        : Intel Corporation|N10/ICH 7 Family SMBus Controller
+[SERIAL_SMBUS] (rev: 01)
+ ata_piix        : Intel Corporation|82801GBM/GHM (ICH7-M Family) SATA
+Controller [IDE mode] [STORAGE_IDE] (rev: 01)
+-iTCO_wdt        : Intel Corporation|82801GBM (ICH7-M) LPC Interface
+Bridge [BRIDGE_ISA] (rev: 01)
++leds_ss4200     : Intel Corporation|82801GBM (ICH7-M) LPC Interface
+Bridge [BRIDGE_ISA] (rev: 01)
+ unknown         : Intel Corporation|82801 Mobile PCI Bridge
+[BRIDGE_PCI] (rev: e1)
+ ehci_hcd        : Intel Corporation|N10/ICH 7 Family USB2 EHCI
+Controller [SERIAL_USB] (rev: 01)
+ uhci_hcd        : Intel Corporation|N10/ICH 7 Family USB UHCI
+Controller #4 [SERIAL_USB] (rev: 01)
+
+
+So I think a small regression (tho it is in BRIDGE_ISA as you mentioned).
+
+Not sure I want the leds_ss4200 driver here :D
+
+Col
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011167.html b/zarb-ml/mageia-dev/2012-January/011167.html new file mode 100644 index 000000000..30ac96671 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011167.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] [RFC] new ldetect, using libkmod + + + + + + + + + +

[Mageia-dev] [RFC] new ldetect, using libkmod

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Mon Jan 9 14:41:25 CET 2012 +

+
+ +
On 9 January 2012 14:37, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+> -iTCO_wdt        : Intel Corporation|82801GBM (ICH7-M) LPC Interface
+> Bridge [BRIDGE_ISA] (rev: 01)
+> +leds_ss4200     : Intel Corporation|82801GBM (ICH7-M) LPC Interface
+> Bridge [BRIDGE_ISA] (rev: 01)
+>  unknown         : Intel Corporation|82801 Mobile PCI Bridge
+> [BRIDGE_PCI] (rev: e1)
+>  ehci_hcd        : Intel Corporation|N10/ICH 7 Family USB2 EHCI
+> Controller [SERIAL_USB] (rev: 01)
+>  uhci_hcd        : Intel Corporation|N10/ICH 7 Family USB UHCI
+> Controller #4 [SERIAL_USB] (rev: 01)
+>
+>
+> So I think a small regression (tho it is in BRIDGE_ISA as you mentioned).
+>
+> Not sure I want the leds_ss4200 driver here :D
+
+I don't think you actually wanted iTCO_wdt either :-)
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011168.html b/zarb-ml/mageia-dev/2012-January/011168.html new file mode 100644 index 000000000..7ab0a7ee9 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011168.html @@ -0,0 +1,155 @@ + + + + [Mageia-dev] Install prompt about pcmcia and 2.2 kernel + + + + + + + + + +

[Mageia-dev] Install prompt about pcmcia and 2.2 kernel

+ Frank Griffin + ftg at roadrunner.com +
+ Mon Jan 9 16:00:30 CET 2012 +

+
+ +
Still there after this morning's update.  What situation is this 
+intended to address ?
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011169.html b/zarb-ml/mageia-dev/2012-January/011169.html new file mode 100644 index 000000000..79d472197 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011169.html @@ -0,0 +1,163 @@ + + + + [Mageia-dev] Install prompt about pcmcia and 2.2 kernel + + + + + + + + + +

[Mageia-dev] Install prompt about pcmcia and 2.2 kernel

+ Thomas Backlund + tmb at mageia.org +
+ Mon Jan 9 16:08:54 CET 2012 +

+
+ +
Frank Griffin skrev 9.1.2012 17:00:
+> Still there after this morning's update.  What situation is this
+> intended to address ?
+>
+
+What arch, and how do you install?
+We removed the pcmcia and kernel check a while back...
+
+
+--
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011170.html b/zarb-ml/mageia-dev/2012-January/011170.html new file mode 100644 index 000000000..b7b6c823e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011170.html @@ -0,0 +1,166 @@ + + + + [Mageia-dev] Install prompt about pcmcia and 2.2 kernel + + + + + + + + + +

[Mageia-dev] Install prompt about pcmcia and 2.2 kernel

+ Frank Griffin + ftg at roadrunner.com +
+ Mon Jan 9 16:08:22 CET 2012 +

+
+ +
On 01/09/2012 10:08 AM, Thomas Backlund wrote:
+> Frank Griffin skrev 9.1.2012 17:00:
+>> Still there after this morning's update.  What situation is this
+>> intended to address ?
+>>
+>
+> What arch, and how do you install?
+> We removed the pcmcia and kernel check a while back...
+>
+>
+> -- 
+> Thomas
+>
+x86_64, isolinux boot and HTTP install from local cauldron mirror.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011171.html b/zarb-ml/mageia-dev/2012-January/011171.html new file mode 100644 index 000000000..def92671c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011171.html @@ -0,0 +1,171 @@ + + + + [Mageia-dev] Install prompt about pcmcia and 2.2 kernel + + + + + + + + + +

[Mageia-dev] Install prompt about pcmcia and 2.2 kernel

+ Frank Griffin + ftg at roadrunner.com +
+ Mon Jan 9 16:11:08 CET 2012 +

+
+ +
On 01/09/2012 10:08 AM, Thomas Backlund wrote:
+> Frank Griffin skrev 9.1.2012 17:00:
+>> Still there after this morning's update.  What situation is this
+>> intended to address ?
+>>
+>
+> What arch, and how do you install?
+> We removed the pcmcia and kernel check a while back...
+>
+>
+> -- 
+> Thomas
+>
+Oh, wait a minute.  My bad.  In order to boot isolinux, this machine has 
+a local copy of the install files needed by an isolinux grub entry, and 
+they're probably out-of-sync.  I'll re-test.
+
+What threw me was the fact that this shows up after stage1 is loaded 
+from the server.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011172.html b/zarb-ml/mageia-dev/2012-January/011172.html new file mode 100644 index 000000000..5d6fce109 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011172.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] Security updates needing testing (please help) + + + + + + + + + +

[Mageia-dev] Security updates needing testing (please help)

+ David Walser + luigiwalser at yahoo.com +
+ Mon Jan 9 16:14:51 CET 2012 +

+
+ +
Thank you to Dave Hodgins, David Geiger, Claire Robinson, and Thomas Backlund
+for helping to get some of these cleared out!  Updated status below.
+
+> There are a number of needed security updates for Mageia 1 that have already
+been built and just need QA
+> testing so that they can be 
+> released.  Most of them have testcases already described in the comments. 
+Please help test these if you can
+> so we can get these updates 
+> released.
+> 
+> Needs testing on i586:
+https://bugs.mageia.org/show_bug.cgi?id=4064 sqlitebrowser
+
+> Needs testing on x86_64:
+https://bugs.mageia.org/show_bug.cgi?id=3937 dhcp
+https://bugs.mageia.org/show_bug.cgi?id=3939 nfs-utils
+https://bugs.mageia.org/show_bug.cgi?id=2064 krb5-appl
+https://bugs.mageia.org/show_bug.cgi?id=3284 msec
+https://bugs.mageia.org/show_bug.cgi?id=3955 cyrus-imapd
+https://bugs.mageia.org/show_bug.cgi?id=3997 mhonarc
+ 
+> Needs testing on both:
+https://bugs.mageia.org/show_bug.cgi?id=3895 PHP (Thomas also needs to rebuild
+php-apc and php-eaccelerator)
+https://bugs.mageia.org/show_bug.cgi?id=3956 networkmanager
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011173.html b/zarb-ml/mageia-dev/2012-January/011173.html new file mode 100644 index 000000000..7a435823b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011173.html @@ -0,0 +1,161 @@ + + + + [Mageia-dev] Install prompt about pcmcia and 2.2 kernel + + + + + + + + + +

[Mageia-dev] Install prompt about pcmcia and 2.2 kernel

+ Frank Griffin + ftg at roadrunner.com +
+ Mon Jan 9 16:59:37 CET 2012 +

+
+ +
On 01/09/2012 10:11 AM, Frank Griffin wrote:
+>
+> Oh, wait a minute.  My bad.  In order to boot isolinux, this machine 
+> has a local copy of the install files needed by an isolinux grub 
+> entry, and they're probably out-of-sync.  I'll re-test.
+>
+> What threw me was the fact that this shows up after stage1 is loaded 
+> from the server.
+>
+That was it.  Sorry for the noise.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011174.html b/zarb-ml/mageia-dev/2012-January/011174.html new file mode 100644 index 000000000..c025b2c03 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011174.html @@ -0,0 +1,121 @@ + + + + [Mageia-dev] Security updates needing testing (please help) + + + + + + + + + +

[Mageia-dev] Security updates needing testing (please help)

+ Claire Robinson + eeeemail at gmail.com +
+ Mon Jan 9 18:01:05 CET 2012 +

+
+ +
On 09/01/12 15:14, David Walser wrote:
+> Thank you to Dave Hodgins, David Geiger, Claire Robinson, and Thomas Backlund
+> for helping to get some of these cleared out!  Updated status below.
+>
+>> There are a number of needed security updates for Mageia 1 that have already
+> been built and just need QA
+>> testing so that they can be
+>> released.  Most of them have testcases already described in the comments.
+> Please help test these if you can
+>> so we can get these updates
+>> released.
+>>
+>> Needs testing on i586:
+> https://bugs.mageia.org/show_bug.cgi?id=4064 sqlitebrowser
+>
+>> Needs testing on x86_64:
+> https://bugs.mageia.org/show_bug.cgi?id=3937 dhcp
+> https://bugs.mageia.org/show_bug.cgi?id=3939 nfs-utils
+> https://bugs.mageia.org/show_bug.cgi?id=2064 krb5-appl
+> https://bugs.mageia.org/show_bug.cgi?id=3284 msec
+> https://bugs.mageia.org/show_bug.cgi?id=3955 cyrus-imapd
+> https://bugs.mageia.org/show_bug.cgi?id=3997 mhonarc
+>
+>> Needs testing on both:
+> https://bugs.mageia.org/show_bug.cgi?id=3895 PHP (Thomas also needs to rebuild
+> php-apc and php-eaccelerator)
+> https://bugs.mageia.org/show_bug.cgi?id=3956 networkmanager
+>
+
+Most QA stopped for Christmas but we're getting back to normal now David 
+thanks.
+
+There were alot of bugs added over the Christmas period so unfortunately 
+there has been quite a list to come back to afterwards and we've been 
+snowed under but getting on top of it again now.
+
+If anybody wishes to help out it is always welcome! There is a list of 
+QA bugs available at :-
+
+https://bugs.mageia.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=waiting%20for%20QA%20test&sharer_id=22
+
+Thanks
+
+Claire
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011175.html b/zarb-ml/mageia-dev/2012-January/011175.html new file mode 100644 index 000000000..093025b4d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011175.html @@ -0,0 +1,186 @@ + + + + [Mageia-dev] [packages-commits] [194095] Update to 3.7.0 + + + + + + + + + +

[Mageia-dev] [packages-commits] [194095] Update to 3.7.0

+ Jani Välimaa + jani.valimaa at gmail.com +
+ Mon Jan 9 18:05:20 CET 2012 +

+
+ +
2012/1/9  <root at mageia.org>:
+> Revision 194095 Author philippem Date 2012-01-09 18:01:20 +0100 (Mon, 09 Jan
+> 2012)
+>
+> Log Message
+>
+> Update to 3.7.0
+>
+> Modified Paths
+>
+> cauldron/python-zope-interface/current/SPECS/python-zope-interface.spec
+>
+> Modified:
+> cauldron/python-zope-interface/current/SPECS/python-zope-interface.spec
+> ===================================================================
+> ---
+> cauldron/python-zope-interface/current/SPECS/python-zope-interface.spec	2012-01-09
+> 16:59:18 UTC (rev 194094)
+> +++
+> cauldron/python-zope-interface/current/SPECS/python-zope-interface.spec	2012-01-09
+> 17:01:20 UTC (rev 194095)
+> @@ -39,7 +39,6 @@
+>  %{__cp} -p CHANGES.txt COPYRIGHT.txt LICENSE.txt README.txt \
+>  		%{buildroot}%{_docdir}/%{name}-%{version}/
+>
+> -
+>  %check
+>  %{__python} setup.py test
+>
+>
+
+If you need to fix a typo in previous commit, use svn propedit:
+
+svn propedit --revprop -r <release> svn:log
+svn+ssh://svn.mageia.org/svn/packages
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011176.html b/zarb-ml/mageia-dev/2012-January/011176.html new file mode 100644 index 000000000..507f5bed2 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011176.html @@ -0,0 +1,178 @@ + + + + [Mageia-dev] VirtualBox grief. Upgrading from MGA1 to Cauldron keep failing + + + + + + + + + +

[Mageia-dev] VirtualBox grief. Upgrading from MGA1 to Cauldron keep failing

+ Johnny A. Solbu + cooker at solbu.net +
+ Mon Jan 9 18:28:22 CET 2012 +

+
+ +
I have been trying for the last 15 hours to install Cauldron by upgrading from 1. I have cloned my mga1 VirtualBox install for this purpose.
+
+I run this command: "urpmi -auto --auto-select --replacefiles"
+For some reason it keeps loosing connection to the mirror server, and exit's with an error code. (curl exit's with 7, and wget with 4). most of the time I just restart the command (up-arrow key and Enter) and it continues, up to a point which is different from each time.
+Sometimes it exit's saying something to the effect of "You probably want to update your database" (Translated).
+I have cloned the install 3 times, because the failed upgrade results in an unusable system. Which looses it's abillity to use the network. Traceroute and firefox, for example, cannot use the network when the final point of failure occurs.
+
+Now I'm trying to force it to download /all/ the packages it want to upgrade, using this command:
+"urpmi --auto --auto-select --no-install --download-all --keep",
+As expected, this also fails at some point, but I am able to continue downloading by running the command again. (I'm repeating the command separated by semicolons, which seems to save me a lot of babysitting. :-)=  ) But for some reason the same retrying fail if I do not ise the switches "--no-install --download-all".
+
+
+And now I have a suspicion that VirtualBox (v3.1.8-3, MDV 2010.2) is to blame. At no point does the host computer loose any connections. Traceroute tests on the host to the same addresses that at the same time fails traceroute from the guest, works fine.
+
+Have anyone else seen this happening?
+
+-- 
+Johnny A. Solbu
+PGP key ID: 0xFA687324
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 189 bytes
+Desc: This is a digitally signed message part.
+URL: </pipermail/mageia-dev/attachments/20120109/2f8d8dde/attachment-0001.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011177.html b/zarb-ml/mageia-dev/2012-January/011177.html new file mode 100644 index 000000000..2fcb6435f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011177.html @@ -0,0 +1,166 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release roundcubemail-0.7.1-1.mga2 + + + + + + + + + +

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

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Mon Jan 9 19:45:07 CET 2012 +

+
+ +
On 9 January 2012 19:25, dams <buildsystem-daemon at mageia.org> wrote:
+> RoundCube Webmail is a browser-based multilingual IMAP client with an
+> application-like user interface. It provides full functionality you
+> expect from an e-mail client, including MIME support, address book,
+> folder manipulation, message searching and spell checking. RoundCube
+> Webmail is written in PHP and requires a MySQL or PostgreSQL database.
+> The user interface is fully skinnable using XHTML and CSS 2.
+>
+> If upgading an existing installation, please read instructions under
+> %{docdir}/README.urpmi for upgrading your MySQL/PostgreSQL/SQLite
+> database.
+
+Repeat after me: I won't put unexpanded macros in %descritions
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011178.html b/zarb-ml/mageia-dev/2012-January/011178.html new file mode 100644 index 000000000..6e992b229 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011178.html @@ -0,0 +1,168 @@ + + + + [Mageia-dev] Fwd: Gtk+ 3.3.7+ bugfix will BREAK Xorg (before 1.12) unless patch is applied + + + + + + + + + +

[Mageia-dev] Fwd: Gtk+ 3.3.7+ bugfix will BREAK Xorg (before 1.12) unless patch is applied

+ Olav Vitters + olav at vitters.nl +
+ Mon Jan 9 20:12:10 CET 2012 +

+
+ +
Need to apply some patches to xorg otherwise the next gtk+ version won't
+work properly (the bug is in xorg; gtk+ will just expose it).
+-- 
+Regards,
+Olav
+-------------- next part --------------
+An embedded message was scrubbed...
+From: Olav Vitters <olav at vitters.nl>
+Subject: Gtk+ 3.3.7+ bugfix will BREAK Xorg (before 1.12) unless patch is
+	applied
+Date: Mon, 9 Jan 2012 20:11:06 +0100
+Size: 1893
+URL: </pipermail/mageia-dev/attachments/20120109/5850aa64/attachment.mht>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011179.html b/zarb-ml/mageia-dev/2012-January/011179.html new file mode 100644 index 000000000..f881704e0 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011179.html @@ -0,0 +1,174 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release roundcubemail-0.7.1-1.mga2 + + + + + + + + + +

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

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Mon Jan 9 22:30:53 CET 2012 +

+
+ +
Le 09/01/2012 19:45, Thierry Vignaud a écrit :
+> On 9 January 2012 19:25, dams<buildsystem-daemon at mageia.org>  wrote:
+>> RoundCube Webmail is a browser-based multilingual IMAP client with an
+>> application-like user interface. It provides full functionality you
+>> expect from an e-mail client, including MIME support, address book,
+>> folder manipulation, message searching and spell checking. RoundCube
+>> Webmail is written in PHP and requires a MySQL or PostgreSQL database.
+>> The user interface is fully skinnable using XHTML and CSS 2.
+>>
+>> If upgading an existing installation, please read instructions under
+>> %{docdir}/README.urpmi for upgrading your MySQL/PostgreSQL/SQLite
+>> database.
+>
+> Repeat after me: I won't put unexpanded macros in %descritions
+He didn't, they were already present. Anyway, I'm really doubtful about 
+the usefulness of using package description to suggest reading 
+documentation.
+
+-- 
+BOFH excuse #34:
+
+(l)user error
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011180.html b/zarb-ml/mageia-dev/2012-January/011180.html new file mode 100644 index 000000000..59958d0c6 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011180.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] Security updates needing testing (please help) + + + + + + + + + +

[Mageia-dev] Security updates needing testing (please help)

+ David Walser + luigiwalser at yahoo.com +
+ Mon Jan 9 23:40:28 CET 2012 +

+
+ +
Thank you to Dave Hodgins, David Geiger, Claire Robinson, Manuel Hiebel, and Thomas Backlund
+for helping to get some of these cleared out!  Updated status below.
+> 
+> There are a number of needed security updates for Mageia 1 that have already been built and just need QA
+> testing so that they can be released.  Most of them have testcases already described in the comments. 
+> Please help test these if you can so we can get these updates released.
+> 
+> Needs testing on i586:
+https://bugs.mageia.org/show_bug.cgi?id=3956 networkmanager
+
+> Needs testing on x86_64:
+https://bugs.mageia.org/show_bug.cgi?id=3937 dhcp
+https://bugs.mageia.org/show_bug.cgi?id=3939 nfs-utils
+https://bugs.mageia.org/show_bug.cgi?id=2064 krb5-appl
+https://bugs.mageia.org/show_bug.cgi?id=3955 cyrus-imapd
+ 
+> Needs testing on both:
+https://bugs.mageia.org/show_bug.cgi?id=3895 PHP (Thomas also needs to rebuild php-apc and php-eaccelerator)
+
+Already tested, needs pushed by sysadmins:
+https://bugs.mageia.org/show_bug.cgi?id=4064 sqlitebrowser
+https://bugs.mageia.org/show_bug.cgi?id=3284 msec
+https://bugs.mageia.org/show_bug.cgi?id=3997 mhonarc
+
+And a reminder from your friendly QA team that all update candidates can be viewed at:
+https://bugs.mageia.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=waiting%20for%20QA%20test&sharer_id=22
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011181.html b/zarb-ml/mageia-dev/2012-January/011181.html new file mode 100644 index 000000000..4a7d47a03 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011181.html @@ -0,0 +1,236 @@ + + + + [Mageia-dev] [RFC] Moving various packages/codecs to tainted + + + + + + + + + +

[Mageia-dev] [RFC] Moving various packages/codecs to tainted

+ Anssi Hannula + anssi at mageia.org +
+ Tue Jan 10 00:12:26 CET 2012 +

+
+ +
Hi all!
+
+As I've noted in some previous emails, our core/tainted media codec
+split-up is currently arbitrary without any specific logic.
+
+As far as I remember, the tainted policy is that codecs for formats that
+are claimed to be covered by patents should be there.
+
+Per that policy, at least the AC-3/DTS/MP3/MPEG-2/MPEG-4/H.264/VC-1
+decoders and AC-3/MPEG-2/MPEG-4 encoders we have in core should be moved
+to tainted section. Note that this will make most current
+.mkv/.avi/.mp4/.mov/.wmv/.mp3 files unplayable without packages from
+tainted section.
+
+I've covered the other-distributions status earlier [1] in more detail,
+but a quick rehash: Fedora doesn't have these codecs at all,
+Debian/Ubuntu ship them in Main section, Arch has them as well.
+
+The (probably slightly incomplete) list of source packages that need
+some action (completely or partially moved to tainted) can be found below.
+
+Shall I implement the move of the packages?
+(after the current ISOs process is done)
+
+Needs to be moved completely to tainted:
+
+a52dec - AC-3 decoding library
+mad - MP3 decoding library
+mpeg2dec - MPEG-2 video decoding library
+ocaml-mad - uses mad
+pymad - uses mad
+vdr-plugin-dvd - uses a52dec
+vdr-plugin-mp3 - uses mad
+
+Needs to be moved to tainted or to implement two separate builds:
+
+alsaplayer - uses mad
+audacity - uses mad
+k3b - uses mad
+kwave - uses mad
+lastfm-player - uses mad
+libextractor - uses mpeg2dec
+libtunepimp - uses mad
+mixxx - uses mad
+mjpegtools - uses mpeg2dec
+normalize - uses mad
+qtractor - uses mad
+scummvm - uses mad
+sox - uses mad
+stepmania - uses mad
+stratagus2.1 - uses mad
+streamripper - uses mad
+xbmc - uses mpeg2dec
+
+Already has dual build, but needs more stuff to be tainted-only:
+
+avidemux - AC-3 dec+enc, DTS dec, MPEG-2 dec/enc, MPEG-4 dec/enc,
+	   H.264 dec, uses mpeg2dec, VC-1 dec
+cdrdao - uses mad
+ffmpeg - AC-3 dec+enc, DTS dec, MPEG-2 dec/enc, MPEG-4 dec/enc,
+         H.264 dec, VC-1 dec
+gstreamer0.10-ffmpeg - as above
+gstreamer0.10-plugins-bad - uses mpeg2dec
+gstreamer0.10-plugins-ugly - uses mpeg2dec
+mpd - uses mad
+mplayer - AC-3 dec+enc, DTS dec, MPEG-2 dec/enc, MPEG-4 dec/enc,
+         H.264 dec, VC-1 dec
+vlc - uses mad, a52dec, mpeg2dec
+xine-lib1.2 - uses mad
+
+
+I didn't include in the above list several formats:
+- ASF (no active licesing program IIRC, Fedora ships it as well)
+- MPEG-2 TS (apparently even Fedora ships them, dunno if oversight,
+  though)
+- H.263 (no active licensing program IIRC, relatively obscure when
+compared to others)
+
+
+[1] https://www.zarb.org/pipermail/mageia-dev/20101012/001084.html
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011182.html b/zarb-ml/mageia-dev/2012-January/011182.html new file mode 100644 index 000000000..171c6f9ed --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011182.html @@ -0,0 +1,175 @@ + + + + [Mageia-dev] [RFC] Moving various packages/codecs to tainted + + + + + + + + + +

[Mageia-dev] [RFC] Moving various packages/codecs to tainted

+ David Walser + luigiwalser at yahoo.com +
+ Tue Jan 10 00:30:18 CET 2012 +

+
+ +
Anssi Hannula wrote:
+> Hi all!
+> 
+> As I've noted in some previous emails, our core/tainted media codec
+> split-up is currently arbitrary without any specific logic.
+> 
+> As far as I remember, the tainted policy is that codecs for formats that
+> are claimed to be covered by patents should be there.
+> 
+> Per that policy, at least the AC-3/DTS/MP3/MPEG-2/MPEG-4/H.264/VC-1
+> decoders and AC-3/MPEG-2/MPEG-4 encoders we have in core should be moved
+> to tainted section. Note that this will make most current
+> .mkv/.avi/.mp4/.mov/.wmv/.mp3 files unplayable without packages from
+> tainted section.
+
+That's the absolute last thing I want to see happen.  It's one of the reasons Fedora and others that do that are not viable options for a lot 
+of non-technical users, and it just makes it so you have to jump through a lot of extra hoops just to have a reasonably working system 
+(whether it's your own or for family members that you might be maintaining).  Obvouisly just about every codec in use has patents relevant to 
+it, but I think we're OK to stick with the ones Mandriva shipped for years in core (like mp3 decoding) and things that were in PLF in tainted 
+(like mp3 encoding) even if it seems arbitrary.  If anything, it'd be nice if more not-likely-to-be-problematic codecs could be moved to 
+core.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011183.html b/zarb-ml/mageia-dev/2012-January/011183.html new file mode 100644 index 000000000..53fedc528 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011183.html @@ -0,0 +1,157 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release roundcubemail-0.7.1-1.mga2 + + + + + + + + + +

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

+ Maarten Vanraes + alien at rmail.be +
+ Tue Jan 10 00:38:31 CET 2012 +

+
+ +
Op maandag 09 januari 2012 22:30:53 schreef Guillaume Rousse:
+[...]
+> He didn't, they were already present. Anyway, I'm really doubtful about
+> the usefulness of using package description to suggest reading
+> documentation.
+
+good point
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011184.html b/zarb-ml/mageia-dev/2012-January/011184.html new file mode 100644 index 000000000..3e039fc5f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011184.html @@ -0,0 +1,188 @@ + + + + [Mageia-dev] [RFC] Moving various packages/codecs to tainted + + + + + + + + + +

[Mageia-dev] [RFC] Moving various packages/codecs to tainted

+ Anssi Hannula + anssi at mageia.org +
+ Tue Jan 10 00:38:52 CET 2012 +

+
+ +
On 10.01.2012 01:30, David Walser wrote:
+> Anssi Hannula wrote:
+>> Hi all!
+>>
+>> As I've noted in some previous emails, our core/tainted media codec
+>> split-up is currently arbitrary without any specific logic.
+>>
+>> As far as I remember, the tainted policy is that codecs for formats that
+>> are claimed to be covered by patents should be there.
+>>
+>> Per that policy, at least the AC-3/DTS/MP3/MPEG-2/MPEG-4/H.264/VC-1
+>> decoders and AC-3/MPEG-2/MPEG-4 encoders we have in core should be moved
+>> to tainted section. Note that this will make most current
+>> .mkv/.avi/.mp4/.mov/.wmv/.mp3 files unplayable without packages from
+>> tainted section.
+> 
+> That's the absolute last thing I want to see happen.  It's one of the reasons Fedora and others that do that are not viable options for a lot 
+> of non-technical users, and it just makes it so you have to jump through a lot of extra hoops just to have a reasonably working system 
+> (whether it's your own or for family members that you might be maintaining).  Obvouisly just about every codec in use has patents relevant to 
+> it, but I think we're OK to stick with the ones Mandriva shipped for years in core (like mp3 decoding) and things that were in PLF in tainted 
+> (like mp3 encoding) even if it seems arbitrary.  If anything, it'd be nice if more not-likely-to-be-problematic codecs could be moved to 
+> core.
+
+I'm absolutely fine with either moving codecs to core or tainted, as
+long as we are at least somewhat consistent in what is in core and what
+is in tainted. However, I do not really like the reasoning "we do it
+like mandriva did no matter if it is sensible or not".
+
+I'd possibly understand "we do it like mandriva did because they didn't
+apparently have problems with these pkgs", but it IMHO wouldn't really
+fly as we could just s/mandriva/ubuntu/ in that statement (and Ubuntu is
+much more prominent than mdv IMO) and then everything would be in core...
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011185.html b/zarb-ml/mageia-dev/2012-January/011185.html new file mode 100644 index 000000000..8e3577075 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011185.html @@ -0,0 +1,257 @@ + + + + [Mageia-dev] [RFC] Moving various packages/codecs to tainted + + + + + + + + + +

[Mageia-dev] [RFC] Moving various packages/codecs to tainted

+ Maarten Vanraes + alien at rmail.be +
+ Tue Jan 10 00:42:38 CET 2012 +

+
+ +
Op dinsdag 10 januari 2012 00:12:26 schreef Anssi Hannula:
+> Hi all!
+> 
+> As I've noted in some previous emails, our core/tainted media codec
+> split-up is currently arbitrary without any specific logic.
+> 
+> As far as I remember, the tainted policy is that codecs for formats that
+> are claimed to be covered by patents should be there.
+> 
+> Per that policy, at least the AC-3/DTS/MP3/MPEG-2/MPEG-4/H.264/VC-1
+> decoders and AC-3/MPEG-2/MPEG-4 encoders we have in core should be moved
+> to tainted section. Note that this will make most current
+> .mkv/.avi/.mp4/.mov/.wmv/.mp3 files unplayable without packages from
+> tainted section.
+> 
+> I've covered the other-distributions status earlier [1] in more detail,
+> but a quick rehash: Fedora doesn't have these codecs at all,
+> Debian/Ubuntu ship them in Main section, Arch has them as well.
+> 
+> The (probably slightly incomplete) list of source packages that need
+> some action (completely or partially moved to tainted) can be found below.
+> 
+> Shall I implement the move of the packages?
+> (after the current ISOs process is done)
+> 
+> Needs to be moved completely to tainted:
+> 
+> a52dec - AC-3 decoding library
+> mad - MP3 decoding library
+> mpeg2dec - MPEG-2 video decoding library
+> ocaml-mad - uses mad
+> pymad - uses mad
+> vdr-plugin-dvd - uses a52dec
+> vdr-plugin-mp3 - uses mad
+> 
+> Needs to be moved to tainted or to implement two separate builds:
+> 
+> alsaplayer - uses mad
+> audacity - uses mad
+> k3b - uses mad
+> kwave - uses mad
+> lastfm-player - uses mad
+> libextractor - uses mpeg2dec
+> libtunepimp - uses mad
+> mixxx - uses mad
+> mjpegtools - uses mpeg2dec
+> normalize - uses mad
+> qtractor - uses mad
+> scummvm - uses mad
+> sox - uses mad
+> stepmania - uses mad
+> stratagus2.1 - uses mad
+> streamripper - uses mad
+> xbmc - uses mpeg2dec
+> 
+> Already has dual build, but needs more stuff to be tainted-only:
+> 
+> avidemux - AC-3 dec+enc, DTS dec, MPEG-2 dec/enc, MPEG-4 dec/enc,
+> 	   H.264 dec, uses mpeg2dec, VC-1 dec
+> cdrdao - uses mad
+> ffmpeg - AC-3 dec+enc, DTS dec, MPEG-2 dec/enc, MPEG-4 dec/enc,
+>          H.264 dec, VC-1 dec
+> gstreamer0.10-ffmpeg - as above
+> gstreamer0.10-plugins-bad - uses mpeg2dec
+> gstreamer0.10-plugins-ugly - uses mpeg2dec
+> mpd - uses mad
+> mplayer - AC-3 dec+enc, DTS dec, MPEG-2 dec/enc, MPEG-4 dec/enc,
+>          H.264 dec, VC-1 dec
+> vlc - uses mad, a52dec, mpeg2dec
+> xine-lib1.2 - uses mad
+> 
+> 
+> I didn't include in the above list several formats:
+> - ASF (no active licesing program IIRC, Fedora ships it as well)
+> - MPEG-2 TS (apparently even Fedora ships them, dunno if oversight,
+>   though)
+> - H.263 (no active licensing program IIRC, relatively obscure when
+> compared to others)
+> 
+> 
+> [1] https://www.zarb.org/pipermail/mageia-dev/20101012/001084.html
+
+
+that's a big list... but then afaict, what you say does reflect the policy that 
+was presented...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011186.html b/zarb-ml/mageia-dev/2012-January/011186.html new file mode 100644 index 000000000..276b7d88f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011186.html @@ -0,0 +1,171 @@ + + + + [Mageia-dev] Fwd: Gtk+ 3.3.7+ bugfix will BREAK Xorg (before 1.12) unless patch is applied + + + + + + + + + +

[Mageia-dev] Fwd: Gtk+ 3.3.7+ bugfix will BREAK Xorg (before 1.12) unless patch is applied

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Jan 10 01:08:07 CET 2012 +

+
+ +
'Twas brillig, and Olav Vitters at 09/01/12 19:12 did gyre and gimble:
+> Need to apply some patches to xorg otherwise the next gtk+ version won't
+> work properly (the bug is in xorg; gtk+ will just expose it).
+
+Applied locally here... seems we updated to 1.11.3 in svn and both
+patches cherry picked fine (still compiling tho')
+
+Col
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011187.html b/zarb-ml/mageia-dev/2012-January/011187.html new file mode 100644 index 000000000..779e644e3 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011187.html @@ -0,0 +1,173 @@ + + + + [Mageia-dev] [RFC] Moving various packages/codecs to tainted + + + + + + + + + +

[Mageia-dev] [RFC] Moving various packages/codecs to tainted

+ Juan Luis Baptiste + juancho at mageia.org +
+ Tue Jan 10 01:54:49 CET 2012 +

+
+ +
On Mon, Jan 9, 2012 at 6:38 PM, Anssi Hannula <anssi at mageia.org> wrote:
+> I'm absolutely fine with either moving codecs to core or tainted, as
+> long as we are at least somewhat consistent in what is in core and what
+> is in tainted. However, I do not really like the reasoning "we do it
+> like mandriva did no matter if it is sensible or not".
+>
+> I'd possibly understand "we do it like mandriva did because they didn't
+> apparently have problems with these pkgs", but it IMHO wouldn't really
+> fly as we could just s/mandriva/ubuntu/ in that statement (and Ubuntu is
+> much more prominent than mdv IMO) and then everything would be in core...
+>
+
+IMHO, for sake's of simplicity and user friendliness, we should leave
+everything in core until there's a real threat from someone about
+patents. Surely if it appears some day,  we wouldn't be the first ones
+to be approached which would leave us plenty of time to correct this
+issue and move affected packages to tainted.
+
+
+-- 
+Juancho
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011188.html b/zarb-ml/mageia-dev/2012-January/011188.html new file mode 100644 index 000000000..4f278fe5f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011188.html @@ -0,0 +1,180 @@ + + + + [Mageia-dev] [RFC] Moving various packages/codecs to tainted + + + + + + + + + +

[Mageia-dev] [RFC] Moving various packages/codecs to tainted

+ Frank Griffin + ftg at roadrunner.com +
+ Tue Jan 10 02:06:17 CET 2012 +

+
+ +
On 01/09/2012 06:38 PM, Anssi Hannula wrote:
+> On 10.01.2012 01:30, David Walser wrote:
+>
+>> That's the absolute last thing I want to see happen.  It's one of the reasons Fedora and others that do that are not viable options for a lot
+>> of non-technical users, and it just makes it so you have to jump through a lot of extra hoops just to have a reasonably working system
+> I'm absolutely fine with either moving codecs to core or tainted, as
+> long as we are at least somewhat consistent in what is in core and what
+> is in tainted.
+
+I agree with both of you, but the problem is the difference between 
+non-free and tainted.  Unfortunately, both are required for a 
+"reasonably working system".  But in the case of nonfree, it's just a 
+matter of us internally getting past the "purity of the media" issue.  
+In the case of tainted, there are legal issues.
+
+I think that the ultimate solution is going to have to be integrated 
+support in the installer allowing the user to hook up either nonfree, 
+tainted, or both, just by answering a simple prompt.  The mirror 
+database probably ought to (if it doesn't already) keep track of which 
+mirrors supply nonfree and tainted (or better still, check at install 
+time), and customize mirror selection based on the user's response.
+
+For non-network installs, I don't see a way around separate ISOs, at 
+least for tainted.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011189.html b/zarb-ml/mageia-dev/2012-January/011189.html new file mode 100644 index 000000000..21fe1f45b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011189.html @@ -0,0 +1,172 @@ + + + + [Mageia-dev] [RFC] Moving various packages/codecs to tainted + + + + + + + + + +

[Mageia-dev] [RFC] Moving various packages/codecs to tainted

+ Frank Griffin + ftg at roadrunner.com +
+ Tue Jan 10 02:12:37 CET 2012 +

+
+ +
On 01/09/2012 08:06 PM, Frank Griffin wrote:
+> The mirror database probably ought to (if it doesn't already) keep 
+> track of which mirrors supply nonfree and tainted (or better still, 
+> check at install time), and customize mirror selection based on the 
+> user's response.
+This didn't quite come out as I intended.  The "or better still, check 
+at install time" bit was meant to include local mirrors that wouldn't be 
+in the mirror database and which were chosen explicitly in a network or 
+hard-disk install, i. e. if nonfree and tainted are there, allow the 
+user to use them.
+
+I was not advocating dynamic checking of every mirror in the database to 
+see if the database info concerning nonfree and tainted was correct 
+(although that should probably be done before proceeding to use a mirror 
+which the database says has these directories just in case it does not).
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011190.html b/zarb-ml/mageia-dev/2012-January/011190.html new file mode 100644 index 000000000..46ebbdc2f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011190.html @@ -0,0 +1,160 @@ + + + + [Mageia-dev] mentors + apprentices + + + + + + + + + +

[Mageia-dev] mentors + apprentices

+ andre999 + andre999mga at laposte.net +
+ Tue Jan 10 02:20:10 CET 2012 +

+
+ +
D.Morgan a écrit :
+> On Mon, Jan 9, 2012 at 7:04 AM, andre999<andre999mga at laposte.net>  wrote:
+>    
+[...]
+>> am2605 (Andrew Myers), has been waiting now about 5 weeks.
+>> He is a longtime Fedora, a web developer, interested in packaging related to
+>> Gnome, Java, Eclipse among others, teaching himself Mageia packaging basics.
+>>      
+> when i will have a new slot free i would be interested in this package
+> as he knows java / eclipse. So let see when i will have one (
+> shouldn't be long )
+>    
+
+I'll let him know
+
+-- 
+André
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011191.html b/zarb-ml/mageia-dev/2012-January/011191.html new file mode 100644 index 000000000..c892795f7 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011191.html @@ -0,0 +1,197 @@ + + + + [Mageia-dev] [RFC] Moving various packages/codecs to tainted + + + + + + + + + +

[Mageia-dev] [RFC] Moving various packages/codecs to tainted

+ David Walser + luigiwalser at yahoo.com +
+ Tue Jan 10 03:08:02 CET 2012 +

+
+ +
Anssi Hannula wrote:
+> On 10.01.2012 01:30, David Walser wrote:
+>> Anssi Hannula wrote:
+>>> Hi all!
+>>>
+>>> As I've noted in some previous emails, our core/tainted media codec
+>>> split-up is currently arbitrary without any specific logic.
+>>>
+>>> As far as I remember, the tainted policy is that codecs for formats that
+>>> are claimed to be covered by patents should be there.
+>>>
+>>> Per that policy, at least the AC-3/DTS/MP3/MPEG-2/MPEG-4/H.264/VC-1
+>>> decoders and AC-3/MPEG-2/MPEG-4 encoders we have in core should be moved
+>>> to tainted section. Note that this will make most current
+>>> .mkv/.avi/.mp4/.mov/.wmv/.mp3 files unplayable without packages from
+>>> tainted section.
+>> 
+>> That's the absolute last thing I want to see happen.  It's one of the reasons Fedora and others that do that are not viable options for a 
+lot 
+>> of non-technical users, and it just makes it so you have to jump through a lot of extra hoops just to have a reasonably working system 
+>> (whether it's your own or for family members that you might be maintaining).  Obvouisly just about every codec in use has patents relevant 
+to 
+>> it, but I think we're OK to stick with the ones Mandriva shipped for years in core (like mp3 decoding) and things that were in PLF in 
+tainted 
+>> (like mp3 encoding) even if it seems arbitrary.  If anything, it'd be nice if more not-likely-to-be-problematic codecs could be moved to 
+>> core.
+> 
+> I'm absolutely fine with either moving codecs to core or tainted, as
+> long as we are at least somewhat consistent in what is in core and what
+> is in tainted. However, I do not really like the reasoning "we do it
+> like mandriva did no matter if it is sensible or not".
+> 
+> I'd possibly understand "we do it like mandriva did because they didn't
+> apparently have problems with these pkgs", but it IMHO wouldn't really
+> fly as we could just s/mandriva/ubuntu/ in that statement (and Ubuntu is
+> much more prominent than mdv IMO) and then everything would be in core...
+
+Sure, I but I think Mandriva achieved a good balance between respecting patents and not being overly paranoid.  I suppose you can't blame a 
+US company like RedHat for being overly paranoid, but as you said, Mandriva hasn't had any problems.  Are there any there examples out of 
+there of distros trying to achieve this balance?  Obviously we don't want to follow Ubuntu or ROSA in pretending patents don't exist.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011192.html b/zarb-ml/mageia-dev/2012-January/011192.html new file mode 100644 index 000000000..94f62ef7b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011192.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia + + + + + + + + + +

[Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia

+ andre999 + andre999mga at laposte.net +
+ Tue Jan 10 03:14:15 CET 2012 +

+
+ +
Kamil Rytarowski a écrit :
+> W dniu 08.01.2012 20:01, Anssi Hannula pisze:
+[...]
+>> IMO a better way to handle this would be
+>> Provides:    mozilla-dictionary
+>> Provides:    hunspell-dictionary
+>> Provides:    myspell-dictionary
+>>
+>> based on which directories are contained in the package, since other
+>> packages are generally interested in whether the package provides
+>> dictionaries in a specific location. (i.e. a package using dictionaries
+>> in /usr/share/hunspell doesn't care if there are some extra dictionaries
+>> provided in other directories).
+> I like this idea!
+> Luc what do you think? Maybe we can consider the providing 
+> "mozilla-dictionary" and then even install symlinks into a specific 
+> directory like /usr/share/mozilla-dictionary ?
+>
+Good idea.  The essence of what we are trying to do.
+
+-- 
+André
+
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011193.html b/zarb-ml/mageia-dev/2012-January/011193.html new file mode 100644 index 000000000..d5e93ff7c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011193.html @@ -0,0 +1,208 @@ + + + + [Mageia-dev] Fwd: Re: [Kolab-devel] Supercolliding a PHP array - DoS Attacks + + + + + + + + + +

[Mageia-dev] Fwd: Re: [Kolab-devel] Supercolliding a PHP array - DoS Attacks

+ Thomas Spuhler + thomas at btspuhler.com +
+ Tue Jan 10 03:48:31 CET 2012 +

+
+ +
I got this from the Kolab folks: 
+
+----------  Forwarded Message  ----------
+
+-----Message original-----
+De: "ABBAS Alain" <alain.abbas at libertech.fr>
+Envoyé: 9 janvier 2012 22:48:02 UTC
+A: kolab-users at kolab.org
+Cc: kolab-devel at kolab.org
+Sujet : [Kolab-devel] Supercolliding a PHP array - DoS Attacks
+
+Hello
+
+There are a serious Dos Attack issue in PHP prior to 5.3.9
+
+This attack is more than easy and serious. 
+PHP 5.3.9 has a change to prevent this DoS attack. Microsoft's also has this 
+issue which MS and made an
+emergency patch available last week  to fix this.
+
+see the links
+
+http://nikic.github.com/2011/12/28/Supercolliding-a-PHP-array.html
+http://cryptanalysis.eu/blog/2011/12/28/effective-dos-attacks-against-web-
+application-plattforms-hashdos/
+http://williamedwardscoder.tumblr.com/post/14939418095/hash-table-attacks-
+impervious-hash-tables
+
+oops typo 
+does Kolab.org plan to give an update of php for this security issue? 
+
+Regards
+
+_______________________________________________
+Kolab-devel mailing list
+Kolab-devel at kolab.org
+https://kolab.org/mailman/listinfo/kolab-devel
+
+
+
+-- 
+Best regards
+Thomas Spuhler
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011194.html b/zarb-ml/mageia-dev/2012-January/011194.html new file mode 100644 index 000000000..eb014062c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011194.html @@ -0,0 +1,175 @@ + + + + [Mageia-dev] [RFC] Moving various packages/codecs to tainted + + + + + + + + + +

[Mageia-dev] [RFC] Moving various packages/codecs to tainted

+ andre999 + andre999mga at laposte.net +
+ Tue Jan 10 04:12:05 CET 2012 +

+
+ +
Juan Luis Baptiste a écrit :
+> On Mon, Jan 9, 2012 at 6:38 PM, Anssi Hannula<anssi at mageia.org>  wrote:
+>    
+>> I'm absolutely fine with either moving codecs to core or tainted, as
+>> long as we are at least somewhat consistent in what is in core and what
+>> is in tainted. However, I do not really like the reasoning "we do it
+>> like mandriva did no matter if it is sensible or not".
+>>
+>> I'd possibly understand "we do it like mandriva did because they didn't
+>> apparently have problems with these pkgs", but it IMHO wouldn't really
+>> fly as we could just s/mandriva/ubuntu/ in that statement (and Ubuntu is
+>> much more prominent than mdv IMO) and then everything would be in core...
+>>
+>>      
+> IMHO, for sake's of simplicity and user friendliness, we should leave
+> everything in core until there's a real threat from someone about
+> patents. Surely if it appears some day,  we wouldn't be the first ones
+> to be approached which would leave us plenty of time to correct this
+> issue and move affected packages to tainted.
+>
+>    
+I strongly agree with this approach.
+
+-- 
+André
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011195.html b/zarb-ml/mageia-dev/2012-January/011195.html new file mode 100644 index 000000000..1517c10c9 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011195.html @@ -0,0 +1,232 @@ + + + + [Mageia-dev] [RFC] Moving various packages/codecs to tainted + + + + + + + + + +

[Mageia-dev] [RFC] Moving various packages/codecs to tainted

+ Anssi Hannula + anssi at mageia.org +
+ Tue Jan 10 04:20:47 CET 2012 +

+
+ +
On 10.01.2012 04:08, David Walser wrote:
+> Anssi Hannula wrote:
+>> On 10.01.2012 01:30, David Walser wrote:
+>>> Anssi Hannula wrote:
+>>>> Hi all!
+>>>>
+>>>> As I've noted in some previous emails, our core/tainted media codec
+>>>> split-up is currently arbitrary without any specific logic.
+>>>>
+>>>> As far as I remember, the tainted policy is that codecs for formats that
+>>>> are claimed to be covered by patents should be there.
+>>>>
+>>>> Per that policy, at least the AC-3/DTS/MP3/MPEG-2/MPEG-4/H.264/VC-1
+>>>> decoders and AC-3/MPEG-2/MPEG-4 encoders we have in core should be moved
+>>>> to tainted section. Note that this will make most current
+>>>> .mkv/.avi/.mp4/.mov/.wmv/.mp3 files unplayable without packages from
+>>>> tainted section.
+>>>
+>>> That's the absolute last thing I want to see happen.  It's one of the reasons Fedora and others that do that are not viable options for a 
+> lot 
+>>> of non-technical users, and it just makes it so you have to jump through a lot of extra hoops just to have a reasonably working system 
+>>> (whether it's your own or for family members that you might be maintaining).  Obvouisly just about every codec in use has patents relevant 
+> to 
+>>> it, but I think we're OK to stick with the ones Mandriva shipped for years in core (like mp3 decoding) and things that were in PLF in 
+> tainted 
+>>> (like mp3 encoding) even if it seems arbitrary.  If anything, it'd be nice if more not-likely-to-be-problematic codecs could be moved to 
+>>> core.
+>>
+>> I'm absolutely fine with either moving codecs to core or tainted, as
+>> long as we are at least somewhat consistent in what is in core and what
+>> is in tainted. However, I do not really like the reasoning "we do it
+>> like mandriva did no matter if it is sensible or not".
+>>
+>> I'd possibly understand "we do it like mandriva did because they didn't
+>> apparently have problems with these pkgs", but it IMHO wouldn't really
+>> fly as we could just s/mandriva/ubuntu/ in that statement (and Ubuntu is
+>> much more prominent than mdv IMO) and then everything would be in core...
+> 
+> Sure, I but I think Mandriva achieved a good balance between respecting patents and not being overly paranoid.
+
+The problem is that that "balance" was achieved by sticking packages in
+PLF/main/contrib semi-randomly. For example, H.264 decoders and MPEG-4
+video encoders are in main/core, while e.g. AAC audio decoders are in
+PLF/tainted. If one'd put them into an order, IMO H.264 and MPEG-4 would
+be much more prominent and tainted candidates instead of AAC decoding...
+Also, in e.g. MPEG-4 case we have encoders both in core and in tainted,
+e.g. we have ffmpeg in core, but xvid in tainted.
+
+> I suppose you can't blame a 
+> US company like RedHat for being overly paranoid, but as you said, Mandriva hasn't had any problems.  Are there any there examples out of 
+> there of distros trying to achieve this balance?  Obviously we don't want to follow Ubuntu or ROSA in pretending patents don't exist.
+
+Linux Mint provides a "No codecs" CD:
+http://www.linuxmint.com/download.php
+
+Ubuntu has a patent policy (which basically IIRC says "rights owner or
+packager, please contact us if you think there is an infringement, we
+will investgate"):
+https://wiki.ubuntu.com/PatentPolicy
+
+Note also that the Ubuntu Live CD and therefore the default Ubuntu
+installation do not contain any codecs. By default Totem is installed,
+however, and gstreamer is plugged into "gnome-codec-install" (which
+seems really nice, do we use it?), so that wen you try to play an
+unsupported video the first time, it will prompt to install the codecs
+(it will also show a warning dialog about patents etc, but AFAICS this
+comes from gnome-codec-install itself, not Ubuntu).
+
+If the user installs a video player depending on ffmpeg, e.g. VLC via
+the software center, the codecs in ffmpeg will be pulled "normally",
+i.e. silently.
+
+Linux Mint had also gstreamer plugged to gnome-codec-install, so the
+codecs will be installed if the user tries to play such a video with
+totem (again with warnings).
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011196.html b/zarb-ml/mageia-dev/2012-January/011196.html new file mode 100644 index 000000000..5fcc00516 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011196.html @@ -0,0 +1,210 @@ + + + + [Mageia-dev] [RFC] Moving various packages/codecs to tainted + + + + + + + + + +

[Mageia-dev] [RFC] Moving various packages/codecs to tainted

+ andre999 + andre999mga at laposte.net +
+ Tue Jan 10 05:00:14 CET 2012 +

+
+ +
Frank Griffin a écrit :
+> On 01/09/2012 06:38 PM, Anssi Hannula wrote:
+>> On 10.01.2012 01:30, David Walser wrote:
+>>
+>>> That's the absolute last thing I want to see happen.  It's one of 
+>>> the reasons Fedora and others that do that are not viable options 
+>>> for a lot
+>>> of non-technical users, and it just makes it so you have to jump 
+>>> through a lot of extra hoops just to have a reasonably working system
+>> I'm absolutely fine with either moving codecs to core or tainted, as
+>> long as we are at least somewhat consistent in what is in core and what
+>> is in tainted.
+>
+> I agree with both of you, but the problem is the difference between 
+> non-free and tainted.  Unfortunately, both are required for a 
+> "reasonably working system".  But in the case of nonfree, it's just a 
+> matter of us internally getting past the "purity of the media" issue.  
+> In the case of tainted, there are legal issues.
+
+Patent claims are potential legal issues, since among other things, most 
+claims are invalidated when (or before) they reach the courts.  So it 
+makes much more sense to wait for real legal patent threats.  Agreed, it 
+does make sense to put packages in "tainted" when real threats arise.  
+Such cases will impact much bigger and richer targets before us, so we 
+will have plenty of time to react.
+
+> I think that the ultimate solution is going to have to be integrated 
+> support in the installer allowing the user to hook up either nonfree, 
+> tainted, or both, just by answering a simple prompt.  The mirror 
+> database probably ought to (if it doesn't already) keep track of which 
+> mirrors supply nonfree and tainted (or better still, check at install 
+> time), and customize mirror selection based on the user's response.
+
+Good idea.
+Note that only "tainted" is optional on official mirrors.  (Yet they all 
+seem to carry "tainted", including in the apparently "patent-threatened" 
+countries such as the U.S.)
+
+> For non-network installs, I don't see a way around separate ISOs, at 
+> least for tainted.
+
+Another reason why we should limit what goes into tainted.  Since many 
+users don't have a connexion reliable enough for network install.
+Our goal should be that it "just works out of the box", for as many 
+users as possible.
+Without unduly compromising our commitment to open source, of course.
+
+As for separate ISO's, if we go that route, we should arrive at some 
+solution that minimises the work involved (including testing) to produce 
+them.  Such as maybe producing a DVD with enough non-free firmware and 
+drivers to get almost everyone's hardware working properly, and then 
+excluding the few non-free packages to produce a totally free DVD for 
+the purists.
+(The non-free kernel-firmware package is only about 20M, for example.)
+
+-- 
+André
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011197.html b/zarb-ml/mageia-dev/2012-January/011197.html new file mode 100644 index 000000000..c8444f445 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011197.html @@ -0,0 +1,264 @@ + + + + [Mageia-dev] [RFC] Moving various packages/codecs to tainted + + + + + + + + + +

[Mageia-dev] [RFC] Moving various packages/codecs to tainted

+ andre999 + andre999mga at laposte.net +
+ Tue Jan 10 05:22:31 CET 2012 +

+
+ +
Anssi Hannula a écrit :
+> On 10.01.2012 04:08, David Walser wrote:
+>    
+>> Anssi Hannula wrote:
+>>      
+>>> On 10.01.2012 01:30, David Walser wrote:
+>>>        
+>>>> Anssi Hannula wrote:
+>>>>          
+>>>>> Hi all!
+>>>>>
+>>>>> As I've noted in some previous emails, our core/tainted media codec
+>>>>> split-up is currently arbitrary without any specific logic.
+>>>>>
+>>>>> As far as I remember, the tainted policy is that codecs for formats that
+>>>>> are claimed to be covered by patents should be there.
+>>>>>
+>>>>> Per that policy, at least the AC-3/DTS/MP3/MPEG-2/MPEG-4/H.264/VC-1
+>>>>> decoders and AC-3/MPEG-2/MPEG-4 encoders we have in core should be moved
+>>>>> to tainted section. Note that this will make most current
+>>>>> .mkv/.avi/.mp4/.mov/.wmv/.mp3 files unplayable without packages from
+>>>>> tainted section.
+>>>>>            
+>>>> That's the absolute last thing I want to see happen.  It's one of the reasons Fedora and others that do that are not viable options for a
+>>>>          
+>> lot
+>>      
+>>>> of non-technical users, and it just makes it so you have to jump through a lot of extra hoops just to have a reasonably working system
+>>>> (whether it's your own or for family members that you might be maintaining).  Obvouisly just about every codec in use has patents relevant
+>>>>          
+>> to
+>>      
+>>>> it, but I think we're OK to stick with the ones Mandriva shipped for years in core (like mp3 decoding) and things that were in PLF in
+>>>>          
+>> tainted
+>>      
+>>>> (like mp3 encoding) even if it seems arbitrary.  If anything, it'd be nice if more not-likely-to-be-problematic codecs could be moved to
+>>>> core.
+>>>>          
+>>> I'm absolutely fine with either moving codecs to core or tainted, as
+>>> long as we are at least somewhat consistent in what is in core and what
+>>> is in tainted. However, I do not really like the reasoning "we do it
+>>> like mandriva did no matter if it is sensible or not".
+>>>
+>>> I'd possibly understand "we do it like mandriva did because they didn't
+>>> apparently have problems with these pkgs", but it IMHO wouldn't really
+>>> fly as we could just s/mandriva/ubuntu/ in that statement (and Ubuntu is
+>>> much more prominent than mdv IMO) and then everything would be in core...
+>>>        
+>> Sure, I but I think Mandriva achieved a good balance between respecting patents and not being overly paranoid.
+>>      
+> The problem is that that "balance" was achieved by sticking packages in
+> PLF/main/contrib semi-randomly. For example, H.264 decoders and MPEG-4
+> video encoders are in main/core, while e.g. AAC audio decoders are in
+> PLF/tainted. If one'd put them into an order, IMO H.264 and MPEG-4 would
+> be much more prominent and tainted candidates instead of AAC decoding...
+> Also, in e.g. MPEG-4 case we have encoders both in core and in tainted,
+> e.g. we have ffmpeg in core, but xvid in tainted.
+>
+>    
+>> I suppose you can't blame a
+>> US company like RedHat for being overly paranoid, but as you said, Mandriva hasn't had any problems.  Are there any there examples out of
+>> there of distros trying to achieve this balance?  Obviously we don't want to follow Ubuntu or ROSA in pretending patents don't exist.
+>>      
+> Linux Mint provides a "No codecs" CD:
+> http://www.linuxmint.com/download.php
+>
+> Ubuntu has a patent policy (which basically IIRC says "rights owner or
+> packager, please contact us if you think there is an infringement, we
+> will investgate"):
+> https://wiki.ubuntu.com/PatentPolicy
+>    
+
+This is the type of patent policy we should have.
+It requires the registered patent holder to inform Ubuntu of the patent 
+claims and the specific package(s) involved before a patent claim is 
+considered by Ubuntu.
+With this policy, probably most of the packages now in "tainted" could 
+be transfered to core.
+
+> Note also that the Ubuntu Live CD and therefore the default Ubuntu
+> installation do not contain any codecs. By default Totem is installed,
+> however, and gstreamer is plugged into "gnome-codec-install" (which
+> seems really nice, do we use it?), so that wen you try to play an
+> unsupported video the first time, it will prompt to install the codecs
+> (it will also show a warning dialog about patents etc, but AFAICS this
+> comes from gnome-codec-install itself, not Ubuntu).
+>    
+
+That sounds nice.  The package that automatically found codecs in 
+Mandriva would give a lot of false positives, and would always go to a 
+paid site.  I removed the package, and most (but not all) of the media 
+concerned worked without additional codecs.
+
+> If the user installs a video player depending on ffmpeg, e.g. VLC via
+> the software center, the codecs in ffmpeg will be pulled "normally",
+> i.e. silently.
+>
+> Linux Mint had also gstreamer plugged to gnome-codec-install, so the
+> codecs will be installed if the user tries to play such a video with
+> totem (again with warnings).
+>    
+
+We should look into doing something along these lines.
+It would be advantageous however to have codec packages, for 
+installation before hand, as many users won't necessarily always an 
+Internet connexion available.
+
+-- 
+André
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011198.html b/zarb-ml/mageia-dev/2012-January/011198.html new file mode 100644 index 000000000..c2e1fd5b4 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011198.html @@ -0,0 +1,187 @@ + + + + [Mageia-dev] Fwd: Re: [Kolab-devel] Supercolliding a PHP array - DoS Attacks + + + + + + + + + +

[Mageia-dev] Fwd: Re: [Kolab-devel] Supercolliding a PHP array - DoS Attacks

+ David Walser + luigiwalser at yahoo.com +
+ Tue Jan 10 05:50:30 CET 2012 +

+
+ +
Thomas Spuhler wrote:
+> I got this from the Kolab folks: 
+> 
+> ----------  Forwarded Message  ----------
+> 
+> -----Message original-----
+> De: "ABBAS Alain" <alain.abbas at libertech.fr>
+> Envoyé: 9 janvier 2012 22:48:02 UTC
+> A: kolab-users at kolab.org
+> Cc: kolab-devel at kolab.org
+> Sujet : [Kolab-devel] Supercolliding a PHP array - DoS Attacks
+> 
+> Hello
+> 
+> There are a serious Dos Attack issue in PHP prior to 5.3.9
+> 
+> This attack is more than easy and serious. 
+
+Thanks Thomas, it's good to know the seriousness of this.  All the more reason to get the update for Mageia 1 pushed out.  Anyone that can 
+help QA the update is welcome.
+
+https://bugs.mageia.org/show_bug.cgi?id=3895
+
+Thomas, I saw you rebuilt php-eaccelerator for Cauldron.  That's good.  Please remember to also rebuild it and php-apc as part of the PHP 
+update for Mageia 1.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011199.html b/zarb-ml/mageia-dev/2012-January/011199.html new file mode 100644 index 000000000..f566e0574 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011199.html @@ -0,0 +1,165 @@ + + + + [Mageia-dev] mentors + apprentices + + + + + + + + + +

[Mageia-dev] mentors + apprentices

+ Olav Vitters + olav at vitters.nl +
+ Tue Jan 10 11:17:41 CET 2012 +

+
+ +
On Mon, Jan 09, 2012 at 01:04:47AM -0500, andre999 wrote:
+> We have a newly qualified packager, kamil, who is already
+> maintaining over 160 packages.  He is largely responsible for the
+> considerabe decrease in unmaintained packages in the last few days,
+> although many other packagers have contributed.
+> 
+> We have another Mandriva packager who has joined our packaging team,
+> nelg (Glen Ogilvie), and is bringing himself up to date for Mageia
+> with jquelin.
+> 
+> Also note that philippem (Philippe Makowski) has just posted a
+> message inviting potential apprentices to contact him for mentoring.
+
+Great news! Seems we have loads great new packagers! Could you perhaps
+announce all the new packagers over the last 2-3 months on
+http://blog.mageia.org/en/ ? Gives them a bit more visibility.. might
+result in a lot of new apprentices though (so perhaps mention
+apprentices are welcome, but might need to wait a bit for a mentor).
+Also think it is great that you get someone who guides you (mentor).
+
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011200.html b/zarb-ml/mageia-dev/2012-January/011200.html new file mode 100644 index 000000000..970a6641c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011200.html @@ -0,0 +1,155 @@ + + + + [Mageia-dev] [packages-commits] [194095] Update to 3.7.0 + + + + + + + + + +

[Mageia-dev] [packages-commits] [194095] Update to 3.7.0

+ philippe makowski + makowski.mageia at gmail.com +
+ Tue Jan 10 11:45:43 CET 2012 +

+
+ +
2012/1/9 Jani Välimaa <jani.valimaa at gmail.com>:
+>
+> If you need to fix a typo in previous commit, use svn propedit:
+>
+> svn propedit --revprop -r <release> svn:log
+> svn+ssh://svn.mageia.org/svn/packages
+
+thanks
+I didn't know that
+or I forgot
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011201.html b/zarb-ml/mageia-dev/2012-January/011201.html new file mode 100644 index 000000000..5020f7c51 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011201.html @@ -0,0 +1,306 @@ + + + + [Mageia-dev] Signature verification of sources + + + + + + + + + +

[Mageia-dev] Signature verification of sources

+ Buchan Milne + bgmilne at zarb.org +
+ Tue Jan 10 11:50:15 CET 2012 +

+
+ +
I think we should be in the position to be able to verify the origin of any 
+software we provide to users.
+
+While we have cryptographic verification of the RPMS (both 'binary' and src), 
+and we store the hashes of the sources, AFAIK we do very limited verification 
+of any signatures provided by upstream.
+
+Now, unfortunately, not all upstreams provide useful signatures:
+1)Not all upstreams provide signatures (some even say that there is no point, 
+as no-one verifies them)
+2)Some upstreams (such as kernel) use automated mechanisms to generate 
+signatures (and in the case of kernl explicitly state that they are only 
+useful for verifying that they match what is on kernel.org, not necessarily 
+that they match what linus generated)
+3)Some upstreams do provide signatures, but sometimes the signing identity 
+changes, or the mechanism (sign gzipped tarball once, unzipped tarball next 
+time)
+
+It seems difficult to argue for upstreams to provide good signatures if no-one 
+is verifying them
+
+So, I have started adding signature verification to my packages where upstream 
+provides signatures:
+-tevent
+-tdb
+-ldb
+-samba
+
+In the past few weeks, I have been moving to defining and using a 'check_sig' 
+macro, and I wonder if it would be useful to move it to spec-helper, and start 
+using it wherever possible.
+
+This is the version in the ldb spec:
+%define check_sig() export GNUPGHOME=%{_tmppath}/rpm-gpghome \
+if [ -d "$GNUPGHOME" ] \
+then echo "Error, GNUPGHOME $GNUPGHOME exists, remove it and try again"; exit 
+1 \
+fi \
+install -d -m700 $GNUPGHOME \
+gpg --import %{1} \
+gpg --trust-model always --verify %{2} %{?3} \
+rm -Rf $GNUPGHOME \
+
+
+Used as follows:
+
+Source: http://samba.org/ftp/ldb/ldb-%{ldbver}.tar.gz
+Source1: http://samba.org/ftp/ldb/ldb-%{ldbver}.tar.gz.asc
+Source2: jelmer.asc
+[...]
+
+%prep
+%check_sig %{SOURCE2} %{SOURCE1} %{SOURCE0}
+
+Producing:
+
++ export GNUPGHOME=/home/bgmilne/tmp/rpm-gpghome
++ GNUPGHOME=/home/bgmilne/tmp/rpm-gpghome
++ '[' -d /home/bgmilne/tmp/rpm-gpghome ']'
++ install -d -m700 /home/bgmilne/tmp/rpm-gpghome
++ gpg --import /home/bgmilne/Download/source/svn/mageia/ldb/SOURCES/jelmer.asc
+gpg: keyring `/home/bgmilne/tmp/rpm-gpghome/secring.gpg' created
+gpg: keyring `/home/bgmilne/tmp/rpm-gpghome/pubring.gpg' created
+gpg: /home/bgmilne/tmp/rpm-gpghome/trustdb.gpg: trustdb created
+gpg: key 1EEF5276: public key "Jelmer Vernooij <jelmer at samba.org>" imported
+gpg: key D729A457: public key "Jelmer Vernooij <jelmer at samba.org>" imported
+gpg: Total number processed: 2
+gpg:               imported: 2  (RSA: 1)
+gpg: no ultimately trusted keys found
++ gpg --trust-model always --verify 
+/home/bgmilne/Download/source/svn/mageia/ldb/SOURCES/ldb-1.1.4.tar.gz.asc 
+/home/bgmilne/Download/source/svn/mageia/ldb/SOURCES/ldb-1.1.4.tar.gz
+gpg: Signature made Sat 03 Dec 2011 01:14:25 SAST using RSA key ID D729A457
+gpg: Good signature from "Jelmer Vernooij <jelmer at samba.org>"
+gpg:                 aka "Jelmer Vernooij <jelmer at sernet.de>"
+gpg:                 aka "Jelmer Vernooij <jelmer at apache.org>"
+gpg:                 aka "Jelmer Vernooij <jelmer at debian.org>"
+gpg:                 aka "Jelmer Vernooij <jelmer at ubuntu.com>"
+gpg:                 aka "Jelmer Vernooij <jelmer at vernstok.nl>"
+gpg:                 aka "Jelmer Vernooij <jelmer at canonical.com>"
+gpg:                 aka "Jelmer Vernooij <jelmer at openchange.org>"
+gpg:                 aka "Jelmer Vernooij <jrvernooij at tigris.org>"
+gpg:                 aka "Jelmer Vernooij <jelmer.vernooij at canonical.com>"
+gpg: WARNING: Using untrusted key!
+gpg: Signature made Sat 03 Dec 2011 01:14:25 SAST using DSA key ID 1EEF5276
+gpg: Good signature from "Jelmer Vernooij <jelmer at samba.org>"
+gpg:                 aka "Jelmer Vernooij <jelmer at fsfe.org>"
+gpg:                 aka "Jelmer Vernooij <jelmer at sernet.de>"
+gpg:                 aka "Jelmer Vernooij <jelmer at debian.org>"
+gpg:                 aka "Jelmer Vernooij <jelmer at ubuntu.com>"
+gpg:                 aka "Jelmer Vernooij <jrvernoo at cs.uu.nl>"
+gpg:                 aka "Jelmer Vernooij <jelmer at vernstok.nl>"
+gpg:                 aka "Jelmer Vernooij <jelmer at openchange.org>"
+gpg:                 aka "Jelmer Vernooij <jrvernooij at tigris.org>"
+gpg:                 aka "Jelmer Vernooij <jelmer at a-eskwadraat.nl>"
+gpg: WARNING: Using untrusted key!
++ rm -Rf /home/bgmilne/tmp/rpm-gpghome
+
+Tampering with the source results in:
+
++ export GNUPGHOME=/home/bgmilne/tmp/rpm-gpghome
++ GNUPGHOME=/home/bgmilne/tmp/rpm-gpghome
++ '[' -d /home/bgmilne/tmp/rpm-gpghome ']'
++ install -d -m700 /home/bgmilne/tmp/rpm-gpghome
++ gpg --import /home/bgmilne/Download/source/svn/mageia/ldb/SOURCES/jelmer.asc
+gpg: keyring `/home/bgmilne/tmp/rpm-gpghome/secring.gpg' created
+gpg: keyring `/home/bgmilne/tmp/rpm-gpghome/pubring.gpg' created
+gpg: /home/bgmilne/tmp/rpm-gpghome/trustdb.gpg: trustdb created
+gpg: key 1EEF5276: public key "Jelmer Vernooij <jelmer at samba.org>" imported
+gpg: key D729A457: public key "Jelmer Vernooij <jelmer at samba.org>" imported
+gpg: Total number processed: 2
+gpg:               imported: 2  (RSA: 1)
+gpg: no ultimately trusted keys found
++ gpg --trust-model always --verify 
+/home/bgmilne/Download/source/svn/mageia/ldb/SOURCES/ldb-1.1.4.tar.gz.asc 
+/home/bgmilne/Download/source/svn/mageia/ldb/SOURCES/ldb-1.1.4.tar.gz
+gpg: Signature made Sat 03 Dec 2011 01:14:25 SAST using RSA key ID D729A457
+gpg: BAD signature from "Jelmer Vernooij <jelmer at samba.org>"
+gpg: Signature made Sat 03 Dec 2011 01:14:25 SAST using DSA key ID 1EEF5276
+gpg: BAD signature from "Jelmer Vernooij <jelmer at samba.org>"
+error: Bad exit status from /home/bgmilne/tmp/rpm-tmp.YqBT4j (%prep)
+
+
+
+Or, if %{_tmppath}/rpm-gpghome exists (important to check for, since we are 
+using --trust-model always):
+
+Executing(%prep): /bin/sh -e /home/bgmilne/tmp/rpm-tmp.OEoIHT
++ umask 022
++ cd /home/bgmilne/rpm/BUILD
++ '[' 1 -eq 1 ']'
++ '[' 1 -eq 1 ']'
++ '[' 1 -eq 1 ']'
++ export GNUPGHOME=/home/bgmilne/tmp/rpm-gpghome
++ GNUPGHOME=/home/bgmilne/tmp/rpm-gpghome
++ '[' -d /home/bgmilne/tmp/rpm-gpghome ']'
++ echo 'Error, GNUPGHOME /home/bgmilne/tmp/rpm-gpghome exists, remove it and 
+try again'
+Error, GNUPGHOME /home/bgmilne/tmp/rpm-gpghome exists, remove it and try again
++ exit 1
+error: Bad exit status from /home/bgmilne/tmp/rpm-tmp.OEoIHT (%prep)
+
+
+Comments?
+
+Regards,
+Buchan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011202.html b/zarb-ml/mageia-dev/2012-January/011202.html new file mode 100644 index 000000000..62934858d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011202.html @@ -0,0 +1,207 @@ + + + + [Mageia-dev] [RFC] Moving various packages/codecs to tainted + + + + + + + + + +

[Mageia-dev] [RFC] Moving various packages/codecs to tainted

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Jan 10 12:04:57 CET 2012 +

+
+ +
'Twas brillig, and andre999 at 10/01/12 03:12 did gyre and gimble:
+> Juan Luis Baptiste a écrit :
+>> On Mon, Jan 9, 2012 at 6:38 PM, Anssi Hannula<anssi at mageia.org>  wrote:
+>>   
+>>> I'm absolutely fine with either moving codecs to core or tainted, as
+>>> long as we are at least somewhat consistent in what is in core and what
+>>> is in tainted. However, I do not really like the reasoning "we do it
+>>> like mandriva did no matter if it is sensible or not".
+>>>
+>>> I'd possibly understand "we do it like mandriva did because they didn't
+>>> apparently have problems with these pkgs", but it IMHO wouldn't really
+>>> fly as we could just s/mandriva/ubuntu/ in that statement (and Ubuntu is
+>>> much more prominent than mdv IMO) and then everything would be in
+>>> core...
+>>>
+>>>      
+>> IMHO, for sake's of simplicity and user friendliness, we should leave
+>> everything in core until there's a real threat from someone about
+>> patents. Surely if it appears some day,  we wouldn't be the first ones
+>> to be approached which would leave us plenty of time to correct this
+>> issue and move affected packages to tainted.
+>>
+>>    
+> I strongly agree with this approach.
+> 
+
+I don't. Especially not with this message now in a public forum
+admitting that we'd just be sticking our heads in the sand with regards
+to this issue.
+
+If any legal action was taken, any efforts to plan for and deal with the
+issues involved will be seen as a sign of good faith. This is very much
+the opposite and thus would lead to stronger legal action should it ever
+come to that.
+
+I really do not get the problem with splitting things out into the
+appropriate repos.
+
+The only real question is about whether to enable those repos by default
+and include the RPMs.
+
+The split is a purely technical decision that should (in theory at
+least) have zero impact on a default install unless we specifically
+decide to allow it to.
+
+
+Col
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011203.html b/zarb-ml/mageia-dev/2012-January/011203.html new file mode 100644 index 000000000..5c487df12 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011203.html @@ -0,0 +1,184 @@ + + + + [Mageia-dev] [RFC] Moving various packages/codecs to tainted + + + + + + + + + +

[Mageia-dev] [RFC] Moving various packages/codecs to tainted

+ Pascal Terjan + pterjan at gmail.com +
+ Tue Jan 10 14:07:17 CET 2012 +

+
+ +
On Tue, Jan 10, 2012 at 03:20, Anssi Hannula <anssi at mageia.org> wrote:
+> The problem is that that "balance" was achieved by sticking packages in
+> PLF/main/contrib semi-randomly. For example, H.264 decoders and MPEG-4
+> video encoders are in main/core, while e.g. AAC audio decoders are in
+> PLF/tainted. If one'd put them into an order, IMO H.264 and MPEG-4 would
+> be much more prominent and tainted candidates instead of AAC decoding...
+> Also, in e.g. MPEG-4 case we have encoders both in core and in tainted,
+> e.g. we have ffmpeg in core, but xvid in tainted.
+
+I agree we need rules, but "being covered with patents" does not make
+sense, as the patent owner may agree with using it in free software.
+I think something like "No actively enforced patent" in core would be good.
+
+>> I suppose you can't blame a
+>> US company like RedHat for being overly paranoid, but as you said, Mandriva hasn't had any problems.  Are there any there examples out of
+>> there of distros trying to achieve this balance?  Obviously we don't want to follow Ubuntu or ROSA in pretending patents don't exist.
+>
+> Linux Mint provides a "No codecs" CD:
+> http://www.linuxmint.com/download.php
+>
+> Ubuntu has a patent policy (which basically IIRC says "rights owner or
+> packager, please contact us if you think there is an infringement, we
+> will investgate"):
+> https://wiki.ubuntu.com/PatentPolicy
+>
+> Note also that the Ubuntu Live CD and therefore the default Ubuntu
+> installation do not contain any codecs. By default Totem is installed,
+> however, and gstreamer is plugged into "gnome-codec-install" (which
+> seems really nice, do we use it?), so that wen you try to play an
+> unsupported video the first time, it will prompt to install the codecs
+> (it will also show a warning dialog about patents etc, but AFAICS this
+> comes from gnome-codec-install itself, not Ubuntu).
+
+This looks nice
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011204.html b/zarb-ml/mageia-dev/2012-January/011204.html new file mode 100644 index 000000000..6302b2de9 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011204.html @@ -0,0 +1,165 @@ + + + + [Mageia-dev] mentors + apprentices + + + + + + + + + +

[Mageia-dev] mentors + apprentices

+ Josh King + josh at linuxpunks.com +
+ Tue Jan 10 15:01:26 CET 2012 +

+
+ +
On 01/10/2012 04:17 AM, Olav Vitters wrote:
+> On Mon, Jan 09, 2012 at 01:04:47AM -0500, andre999 wrote:
+>> We have a newly qualified packager, kamil, who is already
+>> maintaining over 160 packages.  He is largely responsible for the
+>> considerabe decrease in unmaintained packages in the last few days,
+>> although many other packagers have contributed.
+>>
+>> We have another Mandriva packager who has joined our packaging team,
+>> nelg (Glen Ogilvie), and is bringing himself up to date for Mageia
+>> with jquelin.
+>>
+>> Also note that philippem (Philippe Makowski) has just posted a
+>> message inviting potential apprentices to contact him for mentoring.
+>
+> Great news! Seems we have loads great new packagers! Could you perhaps
+> announce all the new packagers over the last 2-3 months on
+> http://blog.mageia.org/en/ ? Gives them a bit more visibility.. might
+> result in a lot of new apprentices though (so perhaps mention
+> apprentices are welcome, but might need to wait a bit for a mentor).
+> Also think it is great that you get someone who guides you (mentor).
+>
+
+How about adding new packagers to planet.mageia.org as well (if they 
+have a blog)? It's always fun to read what other people are up to
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011205.html b/zarb-ml/mageia-dev/2012-January/011205.html new file mode 100644 index 000000000..4f3c8df38 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011205.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Luis Daniel Lucio Quiroz + dlucio at okay.com.mx +
+ Mon Jan 9 05:47:54 CET 2012 +

+
+ +
AS i understand
+we are not a rolling distribution, so i dont get why i'm getting tickets to 
+update release.
+
+What I mean, if you consider an update, like the one i did squid 3.1.12 to 
+3.1.15 please explain why.  Otherwhise i gues it is better you cand use Mageia 
+cauldron SRPM and do backport for  your self.
+
+
+LD
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011206.html b/zarb-ml/mageia-dev/2012-January/011206.html new file mode 100644 index 000000000..d0f7d0e9d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011206.html @@ -0,0 +1,119 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Christian Lohmaier + lohmaier+mageia at googlemail.com +
+ Tue Jan 10 19:12:29 CET 2012 +

+
+ +
Hi Luis, *,
+
+On Mon, Jan 9, 2012 at 5:47 AM, Luis Daniel Lucio Quiroz
+<dlucio at okay.com.mx> wrote:
+> AS i understand
+> we are not a rolling distribution, so i dont get why i'm getting tickets to
+> update release.
+>
+> What I mean, if you consider an update, like the one i did squid 3.1.12 to
+> 3.1.15 please explain why.
+
+No knowing squid's release-numbering-scheme, but update in micro
+version usually are (fully compatible) bugfix releases, so why is an
+explanation necessary? The explanation is "fixed bugs"
+
+And using a fixed upstream release surely is preferable over adding
+patches manually, isn't it?
+
+> Otherwhise i gues it is better you cand use Mageia
+> cauldron SRPM and do backport for  your self.
+
+I understand a backport as adding a version with new features, usually
+signalled by an update in either major or minor version. Those might
+come with break in backwards or forwad-compatibility, so giving clear
+reason why it should be backported surely is justified.
+
+The lower in the stack (the more other packages depend on the package
+in question), the more thought needs to be put into it. But if a
+package that no other package depends on is concerned, then I'd say it
+is up to the  packager to decide whether he/she will go through the
+trouble of backporting it. If the spec is well written, and
+configuring the package is "sane", then it is easy, if it is a
+hacked-together spec/build-system it is hard.
+
+But bugfixreleases (i.e. just micro version changed for most package
+versioning schemes) should just consist of updating the source-tarball
+(and maybe dropping some patches that found their way upstream and
+rediff the remaining ones) and I don't understand your request to
+"stop" those requests.
+
+ciao
+Christian
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011207.html b/zarb-ml/mageia-dev/2012-January/011207.html new file mode 100644 index 000000000..3424c2387 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011207.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Tue Jan 10 19:40:57 CET 2012 +

+
+ +
Le 10/01/2012 19:12, Christian Lohmaier a écrit :
+> And using a fixed upstream release surely is preferable over adding
+> patches manually, isn't it?
+No. Adding bugfix-specific patches ensure you just fix specific issues, 
+whereas updating software version usually doesn't offer any kind of 
+garanty against behavior changes.
+
+-- 
+BOFH excuse #424:
+
+operation failed because: there is no message for this error (#1014)
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011208.html b/zarb-ml/mageia-dev/2012-January/011208.html new file mode 100644 index 000000000..be36a0241 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011208.html @@ -0,0 +1,172 @@ + + + + [Mageia-dev] Signature verification of sources + + + + + + + + + +

[Mageia-dev] Signature verification of sources

+ Johnny A. Solbu + cooker at solbu.net +
+ Tue Jan 10 20:00:35 CET 2012 +

+
+ +
On Tuesday 10 January 2012 11:50, Buchan Milne wrote:
+> I think we should be in the position to be able to verify the origin of any 
+> software we provide to users.
+
+I think this is a good initiative.
+Does other distros do this?
+Perhaps we can ask other distros to start doing the same, and thus give upstream developers a reason for signing.
+
+
+-- 
+Johnny A. Solbu
+PGP key ID: 0xFA687324
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 189 bytes
+Desc: This is a digitally signed message part.
+URL: </pipermail/mageia-dev/attachments/20120110/6457ed43/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011209.html b/zarb-ml/mageia-dev/2012-January/011209.html new file mode 100644 index 000000000..46d1065ca --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011209.html @@ -0,0 +1,176 @@ + + + + [Mageia-dev] Signature verification of sources + + + + + + + + + +

[Mageia-dev] Signature verification of sources

+ Dan Fandrich + dan at coneharvesters.com +
+ Tue Jan 10 20:09:51 CET 2012 +

+
+ +
On Tue, Jan 10, 2012 at 08:00:35PM +0100, Johnny A. Solbu wrote:
+> I think this is a good initiative.
+> Does other distros do this?
+> Perhaps we can ask other distros to start doing the same, and thus give upstream developers a reason for signing.
+
+I believe at least some source-based distros (e.g. Gentoo) do this since
+there's no other means to ensure that the end user isn't downloading and
+compiling compromised source.  It's not really necessary with RPM as
+the spec file creator can verify the source manually (using GPG or other
+means) before packaging it into an SRPM signed by his key. But, chances
+are that manual step is not happening now so making it automatic isn't
+a bad idea.
+
+>>> Dan
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 288 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20120110/3a12f314/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011210.html b/zarb-ml/mageia-dev/2012-January/011210.html new file mode 100644 index 000000000..d3415e1e5 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011210.html @@ -0,0 +1,161 @@ + + + + [Mageia-dev] Display manager + + + + + + + + + +

[Mageia-dev] Display manager

+ Paiiou + paiiou at free.fr +
+ Tue Jan 10 20:22:53 CET 2012 +

+
+ +
The "Provides" most of the display manager shows "dm".
+This is not the case of xdm and lxdm.
+Should we not add?
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011211.html b/zarb-ml/mageia-dev/2012-January/011211.html new file mode 100644 index 000000000..ceb931b60 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011211.html @@ -0,0 +1,151 @@ + + + + [Mageia-dev] [RFC] Moving various packages/codecs to tainted + + + + + + + + + +

[Mageia-dev] [RFC] Moving various packages/codecs to tainted

+ Maarten Vanraes + alien at rmail.be +
+ Tue Jan 10 21:01:14 CET 2012 +

+
+ +
Op dinsdag 10 januari 2012 14:07:17 schreef Pascal Terjan:
+[...]
+
+I agree with pterjan on this
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011212.html b/zarb-ml/mageia-dev/2012-January/011212.html new file mode 100644 index 000000000..f4cab863f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011212.html @@ -0,0 +1,166 @@ + + + + [Mageia-dev] Signature verification of sources + + + + + + + + + +

[Mageia-dev] Signature verification of sources

+ P. Christeas + xrg at linux.gr +
+ Tue Jan 10 21:23:25 CET 2012 +

+
+ +
On Tuesday 10 January 2012, Buchan Milne wrote:
+> I think we should be in the position to be able to verify the origin of any
+> software we provide to users.
+> ...
+
+Just a reminder: a git-based build process would implicitly cover that aspect, 
+since the comit SHAs would be traceable back to the code maintainers.
+
+
+
+
+-- 
+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/2012-January/011213.html b/zarb-ml/mageia-dev/2012-January/011213.html new file mode 100644 index 000000000..34ca86dd4 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011213.html @@ -0,0 +1,194 @@ + + + + [Mageia-dev] [RFC] Moving various packages/codecs to tainted + + + + + + + + + +

[Mageia-dev] [RFC] Moving various packages/codecs to tainted

+ Michael Scherer + misc at zarb.org +
+ Tue Jan 10 21:46:06 CET 2012 +

+
+ +
Le lundi 09 janvier 2012 à 21:08 -0500, David Walser a écrit :
+
+> Sure, I but I think Mandriva achieved a good balance between respecting patents and not being overly paranoid.  
+> I suppose you can't blame a US company like RedHat for being overly paranoid, but as you said, Mandriva hasn't 
+> had any problems.  Are there any there examples out of there of distros trying to achieve this balance?  
+> Obviously we don't want to follow Ubuntu or ROSA in pretending patents don't exist.
+
+You forgot that Mandriva didn't have any lawyers to begin with.
+And Red Hat had problem with patents, like the 2 issues mentionned there
+http://arstechnica.com/open-source/news/2009/03/red-hat-faces-another-patent-infringement-lawsuit-over-jboss.ars
+
+If you dig in SEC filling, you would see such problems in the past too.
+
+Now, users should not fear patents, they would likely not be sued. And
+to tell the truth, neither would the association or mirrors, that's not
+the issue. This would be a issue however for some type of commercial
+users ie a OEM shipping Mageia.
+
+And if people really want to take users in mind ( and I said enough time
+that I personally don't ), people should then keep in mind that most
+potential users are not able to install a distribution and that the OEM
+road is the only one for them. And this OEM road requires us to be clear
+on patents to ease their work as much as possible, hence the split ( and
+the split is also valid for non-free, because some non-free package have
+restrictive licenses, like "not for commercial use" or stuff like that
+).
+
+And if we want to have people working on the distribution, we need to
+make sure they are able to create a commercial offer around it without
+too much risk or problem. OEM is such a way, as would various others.
+
+While I would advocate a removal of tainted ( since I do not care of
+users, nor commercial developers ), there is reasons to keep it to ease
+the work of others.
+
+Also, keep in mind that some people would not be aware of the patents
+issues if there was no split in the first place, or would not know how
+widespread it is. And I think we all agree that we should avoid a second
+SCO-like case, this time based on patents, and one of the various step
+to prevent that would be to make sure people are aware.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011214.html b/zarb-ml/mageia-dev/2012-January/011214.html new file mode 100644 index 000000000..ee4c054fa --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011214.html @@ -0,0 +1,164 @@ + + + + [Mageia-dev] VirtualBox grief. Upgrading from MGA1 to Cauldron keep failing + + + + + + + + + +

[Mageia-dev] VirtualBox grief. Upgrading from MGA1 to Cauldron keep failing

+ Florian Hubold + doktor5000 at arcor.de +
+ Tue Jan 10 22:34:02 CET 2012 +

+
+ +
Am 09.01.2012 18:28, schrieb Johnny A. Solbu:
+> I have been trying for the last 15 hours to install Cauldron by upgrading from 1. I have cloned my mga1 VirtualBox install for this purpose.
+>
+> I run this command: "urpmi -auto --auto-select --replacefiles"
+> For some reason it keeps loosing connection to the mirror server, and exit's with an error code. (curl exit's with 7, and wget with 4). most of the time I just restart the command (up-arrow key and Enter) and it continues, up to a point which is different from each time.
+> Sometimes it exit's saying something to the effect of "You probably want to update your database" (Translated).
+> I have cloned the install 3 times, because the failed upgrade results in an unusable system. Which looses it's abillity to use the network. Traceroute and firefox, for example, cannot use the network when the final point of failure occurs.
+Also happened to me in asimilar manner, default dualarch mageia 1 install,
+upgraded to urpmi via cauldron. Sometime in the process i've noticed
+that the error was about curl, but the command was:
+urpmi --auto-update --auto --wget
+And after installing wget it went through in one run.
+Before it only updated like 20-30 packages, failed. Rinse and repeat.
+> Now I'm trying to force it to download /all/ the packages it want to upgrade, using this command:
+> "urpmi --auto --auto-select --no-install --download-all --keep",
+> As expected, this also fails at some point, but I am able to continue downloading by running the command again. (I'm repeating the command separated by semicolons, which seems to save me a lot of babysitting. :-)=  ) But for some reason the same retrying fail if I do not ise the switches "--no-install --download-all".
+>
+>
+> And now I have a suspicion that VirtualBox (v3.1.8-3, MDV 2010.2) is to blame. At no point does the host computer loose any connections. Traceroute tests on the host to the same addresses that at the same time fails traceroute from the guest, works fine.
+>
+> Have anyone else seen this happening?
+>
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011215.html b/zarb-ml/mageia-dev/2012-January/011215.html new file mode 100644 index 000000000..0b5a71006 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011215.html @@ -0,0 +1,170 @@ + + + + [Mageia-dev] Signature verification of sources + + + + + + + + + +

[Mageia-dev] Signature verification of sources

+ Florian Hubold + doktor5000 at arcor.de +
+ Tue Jan 10 22:59:14 CET 2012 +

+
+ +
Am 10.01.2012 20:09, schrieb Dan Fandrich:
+> On Tue, Jan 10, 2012 at 08:00:35PM +0100, Johnny A. Solbu wrote:
+>> I think this is a good initiative.
+>> Does other distros do this?
+>> Perhaps we can ask other distros to start doing the same, and thus give upstream developers a reason for signing.
+> I believe at least some source-based distros (e.g. Gentoo) do this since
+> there's no other means to ensure that the end user isn't downloading and
+> compiling compromised source.  
+Well, even that didn't protect them from distributing backdoored unrealircd:
+https://bugs.gentoo.org/show_bug.cgi?id=323691#c2
+But in general it seems a good way to go. Always wondered why some SPECs
+had .asc signatures defined in Source tags, but nothing used them.
+
+> It's not really necessary with RPM as
+> the spec file creator can verify the source manually (using GPG or other
+> means) before packaging it into an SRPM signed by his key. But, chances
+> are that manual step is not happening now so making it automatic isn't
+> a bad idea.
+>
+>>>> Dan
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011216.html b/zarb-ml/mageia-dev/2012-January/011216.html new file mode 100644 index 000000000..041a58534 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011216.html @@ -0,0 +1,162 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release gcompris-12.01-1.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release gcompris-12.01-1.mga2

+ Angelo Naselli + anaselli at linux.it +
+ Tue Jan 10 23:03:02 CET 2012 +

+
+ +
Thanks, you know why  :)
+-- 
+	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/20120110/f92e351e/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011217.html b/zarb-ml/mageia-dev/2012-January/011217.html new file mode 100644 index 000000000..b11e9b74a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011217.html @@ -0,0 +1,131 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Luis Daniel Lucio Quiroz + dlucio at okay.com.mx +
+ Wed Jan 11 03:28:15 CET 2012 +

+
+ +
Le mardi 10 janvier 2012 19:12:29 Christian Lohmaier a écrit :
+> Hi Luis, *,
+> 
+> On Mon, Jan 9, 2012 at 5:47 AM, Luis Daniel Lucio Quiroz
+> 
+> <dlucio at okay.com.mx> wrote:
+> > AS i understand
+> > we are not a rolling distribution, so i dont get why i'm getting tickets
+> > to
+> > update release.
+> > 
+> > What I mean, if you consider an update, like the one i did squid 3.1.12 to
+> > 3.1.15 please explain why.
+> 
+> No knowing squid's release-numbering-scheme, but update in micro
+> version usually are (fully compatible) bugfix releases, so why is an
+> explanation necessary? The explanation is "fixed bugs"
+> 
+> And using a fixed upstream release surely is preferable over adding
+> patches manually, isn't it?
+> 
+> > Otherwhise i gues it is better you cand use Mageia
+> >
+> > cauldron SRPM and do backport for  your self.
+> 
+> I understand a backport as adding a version with new features, usually
+> signalled by an update in either major or minor version. Those might
+> come with break in backwards or forwad-compatibility, so giving clear
+> reason why it should be backported surely is justified.
+> 
+> The lower in the stack (the more other packages depend on the package
+> in question), the more thought needs to be put into it. But if a
+> package that no other package depends on is concerned, then I'd say it
+> is up to the  packager to decide whether he/she will go through the
+> trouble of backporting it. If the spec is well written, and
+> configuring the package is "sane", then it is easy, if it is a
+> hacked-together spec/build-system it is hard.
+> 
+> But bugfixreleases (i.e. just micro version changed for most package
+> versioning schemes) should just consist of updating the source-tarball
+> (and maybe dropping some patches that found their way upstream and
+> rediff the remaining ones) and I don't understand your request to
+> "stop" those requests.
+> 
+> ciao
+> Christian
+> Email Shield provided by NOCWorldWide.com
+
+You dont get me,
+
+I mean, stop asking updates for mageia 1 just because there is another 
+newversion.
+
+LD
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011218.html b/zarb-ml/mageia-dev/2012-January/011218.html new file mode 100644 index 000000000..5383e127b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011218.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Johnny A. Solbu + cooker at solbu.net +
+ Wed Jan 11 05:32:50 CET 2012 +

+
+ +
On Wednesday 11 January 2012 03:28, Luis Daniel Lucio Quiroz wrote:
+> I mean, stop asking updates for mageia 1 just because there is another 
+> newversion.
+
+May I suggest that next time, say it in so many words.
+
+Some of us are not good at reading between the lines, and your original post was written in a way that indicated that it was not clear on that you where talking about just what you said you where talking about in your last post. :-)=
+
+
+And I agree with you. Updating packages in a released product just because a new version is out is not a valid reason by itself. If on the other hand it fixes some bugs or security holes, it's worth considering.
+
+-- 
+Johnny A. Solbu
+PGP key ID: 0xFA687324
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 189 bytes
+Desc: This is a digitally signed message part.
+URL: </pipermail/mageia-dev/attachments/20120111/9c53ce7f/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011219.html b/zarb-ml/mageia-dev/2012-January/011219.html new file mode 100644 index 000000000..d3b673f16 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011219.html @@ -0,0 +1,153 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release gcompris-12.01-1.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release gcompris-12.01-1.mga2

+ Jose Jorge + lists.jjorge at free.fr +
+ Wed Jan 11 07:30:17 CET 2012 +

+
+ +
Le 10/01/2012 23:03, Angelo Naselli a écrit :
+> Thanks, you know why  :)
+Hé hé, this time Bruno was really fast!
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011220.html b/zarb-ml/mageia-dev/2012-January/011220.html new file mode 100644 index 000000000..493371472 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011220.html @@ -0,0 +1,168 @@ + + + + [Mageia-dev] Fosdem 2012 - Mageia stand + + + + + + + + + +

[Mageia-dev] Fosdem 2012 - Mageia stand

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Wed Jan 11 08:56:27 CET 2012 +

+
+ +
Hi there,
+
+as you might already know from previous mails or from the blog post published
+yesterday, Mageia is (again) attending Fosdem this year.
+http://blog.mageia.org/en/2012/01/10/happy-new-mageia-year/
+
+
+Aside from participating in some discussion sessions and a talk done by misc,
+we are also having a stand there for showing mageia to the public.
+For this we do still need some help from you. We should have two people there
+all the time and as you might imagine, nobody wants to stand there all day.
+So if you are attending FOSDEM this year and are willing to help us, please
+enter your name here:
+https://wiki.mageia.org/en/Fosdem_2012#Mageia_booth
+
+Looking forward to meeting many people there,
+
+Oliver
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011221.html b/zarb-ml/mageia-dev/2012-January/011221.html new file mode 100644 index 000000000..71fd9b803 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011221.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Buchan Milne + bgmilne at zarb.org +
+ Wed Jan 11 08:57:41 CET 2012 +

+
+ +
On Wednesday, 11 January 2012 06:32:50 Johnny A. Solbu wrote:
+> On Wednesday 11 January 2012 03:28, Luis Daniel Lucio Quiroz wrote:
+> > I mean, stop asking updates for mageia 1 just because there is another
+> > newversion.
+> 
+> May I suggest that next time, say it in so many words.
+> 
+> Some of us are not good at reading between the lines, and your original
+> post was written in a way that indicated that it was not clear on that you
+> where talking about just what you said you where talking about in your
+> last post. :-)=
+> 
+> 
+> And I agree with you. Updating packages in a released product just because
+> a new version is out is not a valid reason by itself. If on the other hand
+> it fixes some bugs or security holes, it's worth considering.
+
+Resolving the backports situation would however provide a means for users who 
+want to track upstream (for various reasons, such as being able to get support 
+from upstreams who don't really want to support 'historic' releases) without:
+1)Forcing all users to get the update
+2)Requiring excessive QA work
+3)Requiring bug reports for each update
+
+Regards,
+Buchan
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011222.html b/zarb-ml/mageia-dev/2012-January/011222.html new file mode 100644 index 000000000..b3bf81460 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011222.html @@ -0,0 +1,161 @@ + + + + [Mageia-dev] Signature verification of sources + + + + + + + + + +

[Mageia-dev] Signature verification of sources

+ Buchan Milne + bgmilne at staff.telkomsa.net +
+ Wed Jan 11 08:58:53 CET 2012 +

+
+ +
On Tuesday, 10 January 2012 22:23:25 P. Christeas wrote:
+> On Tuesday 10 January 2012, Buchan Milne wrote:
+> > I think we should be in the position to be able to verify the origin of
+> > any software we provide to users.
+> > ...
+> 
+> Just a reminder: a git-based build process would implicitly cover that
+> aspect, since the comit SHAs would be traceable back to the code
+> maintainers.
+
+As far as I understand, it wouldn't necessarily provide a guarantee that the 
+upstream git was compromised before it was cloned by the package maintainer.
+
+Regards,
+Buchan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011223.html b/zarb-ml/mageia-dev/2012-January/011223.html new file mode 100644 index 000000000..68a395e8b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011223.html @@ -0,0 +1,124 @@ + + + + [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help + + + + + + + + + +

[Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help

+ Marja van Waes + marja11 at xs4all.nl +
+ Wed Jan 11 09:42:04 CET 2012 +

+
+ +
On 03/01/12 10:09, Wolfgang Bornath wrote:
+> 2012/1/3 Michael Scherer<misc at zarb.org>:
+>> Le lundi 02 janvier 2012 à 22:17 +0100, Maarten Vanraes a écrit :
+>>> Op maandag 02 januari 2012 21:40:31 schreef Michael Scherer:
+>>>> Le lundi 02 janvier 2012 à 19:41 +0100, Marja van Waes a écrit :
+>>>>> Hi everyone,
+>>>>>
+>>>>> Can someone please help to fix bug 1956?
+>>>>>
+>>>>> You don't need to be a regular forum visitor.
+>>>>>
+>>>>> We need someone to find and implement a probably existing MOD,  needed
+>>>>> to keep forum posts history when unlimited edit time is enabled
+>>>>>
+>>>>>   From wobo's comment #32:
+>>>>> Capabilities needed:
+>>>>> Well, one could say that anybody who
+>>>>>
+>>>>>    - knows how to run phpBB as admin and
+>>>>>    - has seen a line of php
+>>>>>    - knows how to edit code (respecting tags and such)
+>>>>>    - knows how to cut&paste
+>>>>>
+>>>>> should be able to install an existing MOD (if I'm not mistaken there is
+>>>>> one or more).
+>>>>>
+>>>>> I know next to nothing about php coding. But I've been running a phpBB
+>>>>> forum for a couple of years and successfully implemented some MODs in
+>>>>> phpBB2 and phpBB3. With no help (except the phpBB-forum in case of
+>>>>> problems).
+>>>>>
+>>>>> In practice you have a detailed installation README for each MOD. Like
+>>>>>
+>>>>>    - open file /foo/bar/doo.php
+>>>>>    - Find the line which starts with '......'
+>>>>>    - After that add
+>>>>>    - "........."
+>>>>>
+>>>>> And more such step-by-step guidance
+>>>> My eyes start to bleed dues to such "guidances".
+>>> i'm sure misc means to say that we should have all our changes in
+>>> packages/puppet config so that we can update without issues. and with file
+>>> edits, that's a whole different thing.
+>> I was more thinking of proper patchs or better, proper modules, with
+>> files to deploy in a well know directory .
+> I only gave a part of an example. MODs are made as enhancement to the
+> standard software. The easiest MOD is like Michael wrote: "a module
+> with files to deploy in a well known directory". But in most cases
+> they consist of files to copy into various directories of the program
+> tree and changes to existing files of the software. There are other
+> MODs which can be implemented automatically - which is far worse IMHO.
+> This is where a modded phpBB3 could turn into a nightmare to maintain
+> - believe me, I've been there :(
+>
+> Of course no developper of a MOD could know what somebody has already
+> done to the standard files, so it's not possible do use only patches.
+> And it could be (and that happens quite often) that a MOD is not
+> compatible to your already "modificated" forum software (destroys
+> other modifications or whatever).
+>
+> IMHO the best way in this case here would be a mod written for our
+> setup, all changes well defined to make it maintainable in a proper
+> way. Saying this I beg to think again whether the issue  justifies all
+> the time and work.
+>
+It would make me very, very happy, does that count a little? If I were 
+sure that I'd be able to learn how to do it, I would now consider to 
+halve the time I use for the Bug Squad and Doc Team and start learning.
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011224.html b/zarb-ml/mageia-dev/2012-January/011224.html new file mode 100644 index 000000000..3fb237d6d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011224.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Florian Hubold + doktor5000 at arcor.de +
+ Wed Jan 11 09:43:33 CET 2012 +

+
+ +
Am 11.01.2012 08:57, schrieb Buchan Milne:
+> On Wednesday, 11 January 2012 06:32:50 Johnny A. Solbu wrote:
+>> On Wednesday 11 January 2012 03:28, Luis Daniel Lucio Quiroz wrote:
+>>> I mean, stop asking updates for mageia 1 just because there is another
+>>> newversion.
+>> May I suggest that next time, say it in so many words.
+>>
+>> Some of us are not good at reading between the lines, and your original
+>> post was written in a way that indicated that it was not clear on that you
+>> where talking about just what you said you where talking about in your
+>> last post. :-)=
+>>
+>>
+>> And I agree with you. Updating packages in a released product just because
+>> a new version is out is not a valid reason by itself. If on the other hand
+>> it fixes some bugs or security holes, it's worth considering.
+> Resolving the backports situation would however provide a means for users who 
+> want to track upstream (for various reasons, such as being able to get support 
+> from upstreams who don't really want to support 'historic' releases) without:
+> 1)Forcing all users to get the update
+> 2)Requiring excessive QA work
+> 3)Requiring bug reports for each update
+Well, 2) and 3) are not valid reasons here, because backports should get
+a similar amount of QA testing as normal update candidates, and for
+the updates policy require a bugreport for validation through QA.
+Check https://wiki.mageia.org/en/Backports_policy#Steps
+and https://wiki.mageia.org/en/Updates_policy
+> Regards,
+> Buchan
+>
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011225.html b/zarb-ml/mageia-dev/2012-January/011225.html new file mode 100644 index 000000000..876ce9f5c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011225.html @@ -0,0 +1,183 @@ + + + + [Mageia-dev] Fosdem 2012 - Mageia stand + + + + + + + + + +

[Mageia-dev] Fosdem 2012 - Mageia stand

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Wed Jan 11 10:15:02 CET 2012 +

+
+ +
'Twas brillig, and Oliver Burger at 11/01/12 07:56 did gyre and gimble:
+> as you might already know from previous mails or from the blog post published
+> yesterday, Mageia is (again) attending Fosdem this year.
+> http://blog.mageia.org/en/2012/01/10/happy-new-mageia-year/
+> 
+> 
+> Aside from participating in some discussion sessions and a talk done by misc,
+> we are also having a stand there for showing mageia to the public.
+> For this we do still need some help from you. We should have two people there
+> all the time and as you might imagine, nobody wants to stand there all day.
+> So if you are attending FOSDEM this year and are willing to help us, please
+> enter your name here:
+> https://wiki.mageia.org/en/Fosdem_2012#Mageia_booth
+> 
+> Looking forward to meeting many people there,
+
+In a stunning break from the norm, I've actually managed to not plan a
+skiing holiday over the FOSDEM weekend... Misc won't believe me but I
+WILL be there!
+
+Added my name to the list.
+
+Col
+
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011226.html b/zarb-ml/mageia-dev/2012-January/011226.html new file mode 100644 index 000000000..95f775389 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011226.html @@ -0,0 +1,155 @@ + + + + [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help + + + + + + + + + +

[Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Wed Jan 11 10:54:58 CET 2012 +

+
+ +
2012/1/11 Marja van Waes <marja11 at xs4all.nl>:
+> On 03/01/12 10:09, Wolfgang Bornath wrote:
+>>
+>> 2012/1/3 Michael Scherer<misc at zarb.org>:
+>>>
+>>> Le lundi 02 janvier 2012 à 22:17 +0100, Maarten Vanraes a écrit :
+>>>>
+>>>> Op maandag 02 januari 2012 21:40:31 schreef Michael Scherer:
+>>>>>
+>>>>> Le lundi 02 janvier 2012 à 19:41 +0100, Marja van Waes a écrit :
+>>>>>>
+>>>>>> Hi everyone,
+>>>>>>
+>>>>>> Can someone please help to fix bug 1956?
+>>>>>>
+>>>>>> You don't need to be a regular forum visitor.
+>>>>>>
+>>>>>> We need someone to find and implement a probably existing MOD,  needed
+>>>>>> to keep forum posts history when unlimited edit time is enabled
+>>>>>>
+>>>>>>  From wobo's comment #32:
+>>>>>> Capabilities needed:
+>>>>>> Well, one could say that anybody who
+>>>>>>
+>>>>>>   - knows how to run phpBB as admin and
+>>>>>>   - has seen a line of php
+>>>>>>   - knows how to edit code (respecting tags and such)
+>>>>>>   - knows how to cut&paste
+>>>>>>
+>>>>>> should be able to install an existing MOD (if I'm not mistaken there
+>>>>>> is
+>>>>>> one or more).
+>>>>>>
+>>>>>> I know next to nothing about php coding. But I've been running a phpBB
+>>>>>> forum for a couple of years and successfully implemented some MODs in
+>>>>>> phpBB2 and phpBB3. With no help (except the phpBB-forum in case of
+>>>>>> problems).
+>>>>>>
+>>>>>> In practice you have a detailed installation README for each MOD. Like
+>>>>>>
+>>>>>>   - open file /foo/bar/doo.php
+>>>>>>   - Find the line which starts with '......'
+>>>>>>   - After that add
+>>>>>>   - "........."
+>>>>>>
+>>>>>> And more such step-by-step guidance
+>>>>>
+>>>>> My eyes start to bleed dues to such "guidances".
+>>>>
+>>>> i'm sure misc means to say that we should have all our changes in
+>>>> packages/puppet config so that we can update without issues. and with
+>>>> file
+>>>> edits, that's a whole different thing.
+>>>
+>>> I was more thinking of proper patchs or better, proper modules, with
+>>> files to deploy in a well know directory .
+>>
+>> I only gave a part of an example. MODs are made as enhancement to the
+>> standard software. The easiest MOD is like Michael wrote: "a module
+>> with files to deploy in a well known directory". But in most cases
+>> they consist of files to copy into various directories of the program
+>> tree and changes to existing files of the software. There are other
+>> MODs which can be implemented automatically - which is far worse IMHO.
+>> This is where a modded phpBB3 could turn into a nightmare to maintain
+>> - believe me, I've been there :(
+>>
+>> Of course no developper of a MOD could know what somebody has already
+>> done to the standard files, so it's not possible do use only patches.
+>> And it could be (and that happens quite often) that a MOD is not
+>> compatible to your already "modificated" forum software (destroys
+>> other modifications or whatever).
+>>
+>> IMHO the best way in this case here would be a mod written for our
+>> setup, all changes well defined to make it maintainable in a proper
+>> way. Saying this I beg to think again whether the issue  justifies all
+>> the time and work.
+>>
+> It would make me very, very happy, does that count a little? If I were sure
+> that I'd be able to learn how to do it, I would now consider to halve the
+> time I use for the Bug Squad and Doc Team and start learning.
+
+Why? IMHO this complete issue is going out of proportions. Let's
+remember why we *seem to need* this MOD in the first place. And what
+will we find? The time-to-edit discussion, again. In the council
+meeting where it was decided to have this mod It looked as the best
+way to please a disturbing minority request, the more as that same
+minority gave the impression that such a MOD could be implemented
+within a reasonable time span. As we see now after 8 months, this was
+never the case.
+
+Adding the fact that a test period of several months with a much
+looser time-to-edit setting in the German Mageia forum showed not one
+single case of misuse brings me to the conviction that we should
+rather rethink the time-to-edit limitation itself than to waste
+manpower on this issue. Manpower which is needed at more important
+tasks, if I may say.
+
+-- 
+wobo
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011227.html b/zarb-ml/mageia-dev/2012-January/011227.html new file mode 100644 index 000000000..433b50edd --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011227.html @@ -0,0 +1,74 @@ + + + + [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help + + + + + + + + + +

[Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Wed Jan 11 11:06:55 CET 2012 +

+
+ +
Am Mittwoch, 11. Januar 2012, 10:54:58 schrieb Wolfgang Bornath:
+> Why? IMHO this complete issue is going out of proportions. Let's
+> remember why we *seem to need* this MOD in the first place. And what
+> will we find? The time-to-edit discussion, again. In the council
+> meeting where it was decided to have this mod It looked as the best
+> way to please a disturbing minority request, the more as that same
+> minority gave the impression that such a MOD could be implemented
+> within a reasonable time span. As we see now after 8 months, this was
+> never the case.
+> 
+> Adding the fact that a test period of several months with a much
+> looser time-to-edit setting in the German Mageia forum showed not one
+> single case of misuse brings me to the conviction that we should
+> rather rethink the time-to-edit limitation itself than to waste
+> manpower on this issue. Manpower which is needed at more important
+> tasks, if I may say.
+
++1
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011228.html b/zarb-ml/mageia-dev/2012-January/011228.html new file mode 100644 index 000000000..d0e877e05 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011228.html @@ -0,0 +1,236 @@ + + + + [Mageia-dev] [RFC] Moving various packages/codecs to tainted + + + + + + + + + +

[Mageia-dev] [RFC] Moving various packages/codecs to tainted

+ andre999 + andre999mga at laposte.net +
+ Wed Jan 11 12:29:32 CET 2012 +

+
+ +
Colin Guthrie a écrit :
+> 'Twas brillig, and andre999 at 10/01/12 03:12 did gyre and gimble:
+>    
+>> Juan Luis Baptiste a écrit :
+>>      
+>>> On Mon, Jan 9, 2012 at 6:38 PM, Anssi Hannula<anssi at mageia.org>   wrote:
+>>>
+>>>        
+>>>> I'm absolutely fine with either moving codecs to core or tainted, as
+>>>> long as we are at least somewhat consistent in what is in core and what
+>>>> is in tainted. However, I do not really like the reasoning "we do it
+>>>> like mandriva did no matter if it is sensible or not".
+>>>>
+>>>> I'd possibly understand "we do it like mandriva did because they didn't
+>>>> apparently have problems with these pkgs", but it IMHO wouldn't really
+>>>> fly as we could just s/mandriva/ubuntu/ in that statement (and Ubuntu is
+>>>> much more prominent than mdv IMO) and then everything would be in
+>>>> core...
+>>>>
+>>>>
+>>>>          
+>>> IMHO, for sake's of simplicity and user friendliness, we should leave
+>>> everything in core until there's a real threat from someone about
+>>> patents. Surely if it appears some day,  we wouldn't be the first ones
+>>> to be approached which would leave us plenty of time to correct this
+>>> issue and move affected packages to tainted.
+>>>
+>>>        
+>> I strongly agree with this approach.
+>>      
+> I don't. Especially not with this message now in a public forum
+> admitting that we'd just be sticking our heads in the sand with regards
+> to this issue.
+>
+> If any legal action was taken, any efforts to plan for and deal with the
+> issues involved will be seen as a sign of good faith. This is very much
+> the opposite and thus would lead to stronger legal action should it ever
+> come to that.
+>
+> I really do not get the problem with splitting things out into the
+> appropriate repos.
+>
+> The only real question is about whether to enable those repos by default
+> and include the RPMs.
+>    
+
+We're talking about codecs, essentially the decoders which are used to 
+read encoded files.
+If the patent claims are valid/enforceable (and most aren't), it is up 
+to the patent holder to decide if it is in their interest to enforce the 
+patent claims.
+Since they will normally attempt to collect royalties from those using 
+the encoders to generate encoded content, it is in their interest avoid 
+enforcing claims against users of decoders, as the more such decoders 
+are used, the more the demand for the corresponding encoders, and thus 
+the more royalties they will collect.  So it seems to me entirely 
+logical to await notification that they indeed intend to collect 
+royalties for these codec decoders.
+However I do agree that we should put encoders that seem to be covered 
+by valid patents in some countries in "tainted".
+
+This might seem to be not worth the effort, particularly since, to the 
+best of my knowledge, even in software patent impacted countries such as 
+the U.S., no Linux mirror has chosen to not carry all the supposedly 
+patent-affected packages produced by the distro.
+However by including codec decoders on our isos, we will give users a 
+much more friendly experience, particularly those that can not use 
+online repos during installation.
+We have to decide whether we would consider a package affected by patents.
+I'm just trying to suggest that we hold off putting codec decoders in 
+"tainted" until we know that the patent holder intends to enforce the 
+patent (against us or other similar users).
+
+Of course we could always be dogmatic about it.  It would be interesting 
+producing a release the next time there is a claim against the Linux kernel.
+
+> The split is a purely technical decision that should (in theory at
+> least) have zero impact on a default install unless we specifically
+> decide to allow it to.
+>    
+
+One could say that there is a considerable political side of the issue.
+Is the claim potentially valid ? (We probably already consider that, to 
+some degree.)
+Does the patent holder intend to enforce it, in our context.  (We should 
+consider that.)
+
+As far as the impact goes, if we don't separate likely enforced from 
+other patent claims, we won't be able to provide codecs on our DVD's, 
+which will impact those who can not reliably do a network install.
+I'd rather that Mageia be known as a user-friendly distro.
+
+> Col
+>
+>    
+
+My 2 cents :)
+
+-- 
+André
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011229.html b/zarb-ml/mageia-dev/2012-January/011229.html new file mode 100644 index 000000000..0406ea7fc --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011229.html @@ -0,0 +1,172 @@ + + + + [Mageia-dev] Fosdem 2012 - Mageia stand + + + + + + + + + +

[Mageia-dev] Fosdem 2012 - Mageia stand

+ Marja van Waes + marja11 at xs4all.nl +
+ Wed Jan 11 12:35:58 CET 2012 +

+
+ +
On 11/01/12 10:15, Colin Guthrie wrote:
+> 'Twas brillig, and Oliver Burger at 11/01/12 07:56 did gyre and gimble:
+>> as you might already know from previous mails or from the blog post published
+>> yesterday, Mageia is (again) attending Fosdem this year.
+>> http://blog.mageia.org/en/2012/01/10/happy-new-mageia-year/
+>>
+>>
+>> Aside from participating in some discussion sessions and a talk done by misc,
+>> we are also having a stand there for showing mageia to the public.
+>> For this we do still need some help from you. We should have two people there
+>> all the time and as you might imagine, nobody wants to stand there all day.
+>> So if you are attending FOSDEM this year and are willing to help us, please
+>> enter your name here:
+>> https://wiki.mageia.org/en/Fosdem_2012#Mageia_booth
+>>
+>> Looking forward to meeting many people there,
+> In a stunning break from the norm, I've actually managed to not plan a
+> skiing holiday over the FOSDEM weekend... Misc won't believe me but I
+> WILL be there!
+>
+> Added my name to the list.
+>
+> Col
+>
+>
+Great :)
+
+You don't want to join the dinner saturday night? 
+https://wiki.mageia.org/en/Fosdem_2012#Dinner_Saturday_night
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011230.html b/zarb-ml/mageia-dev/2012-January/011230.html new file mode 100644 index 000000000..62857f70b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011230.html @@ -0,0 +1,156 @@ + + + + [Mageia-dev] Fosdem 2012 - Mageia stand + + + + + + + + + +

[Mageia-dev] Fosdem 2012 - Mageia stand

+ AL13N + alien at rmail.be +
+ Wed Jan 11 12:38:15 CET 2012 +

+
+ +
> 'Twas brillig, and Oliver Burger at 11/01/12 07:56 did gyre and gimble:
+[...]
+>> Looking forward to meeting many people there,
+>
+> In a stunning break from the norm, I've actually managed to not plan a
+> skiing holiday over the FOSDEM weekend... Misc won't believe me but I
+> WILL be there!
+>
+> Added my name to the list.
+
+Haha, no way! awesome though... don't forget to register on the wiki page
+for the saturday dinner
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011231.html b/zarb-ml/mageia-dev/2012-January/011231.html new file mode 100644 index 000000000..259a4e8d6 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011231.html @@ -0,0 +1,181 @@ + + + + [Mageia-dev] [RFC] Moving various packages/codecs to tainted + + + + + + + + + +

[Mageia-dev] [RFC] Moving various packages/codecs to tainted

+ Anssi Hannula + anssi at mageia.org +
+ Wed Jan 11 13:56:32 CET 2012 +

+
+ +
On 10.01.2012 15:07, Pascal Terjan wrote:
+> On Tue, Jan 10, 2012 at 03:20, Anssi Hannula <anssi at mageia.org> wrote:
+>> The problem is that that "balance" was achieved by sticking packages in
+>> PLF/main/contrib semi-randomly. For example, H.264 decoders and MPEG-4
+>> video encoders are in main/core, while e.g. AAC audio decoders are in
+>> PLF/tainted. If one'd put them into an order, IMO H.264 and MPEG-4 would
+>> be much more prominent and tainted candidates instead of AAC decoding...
+>> Also, in e.g. MPEG-4 case we have encoders both in core and in tainted,
+>> e.g. we have ffmpeg in core, but xvid in tainted.
+> 
+> I agree we need rules, but "being covered with patents" does not make
+> sense, as the patent owner may agree with using it in free software.
+> I think something like "No actively enforced patent" in core would be good.
+
+Possibly, but how do you define that, exactly?
+
+Does a licensing program count as "enforcing" or do you mean something else?
+
+>>> I suppose you can't blame a
+>>> US company like RedHat for being overly paranoid, but as you said, Mandriva hasn't had any problems.  Are there any there examples out of
+>>> there of distros trying to achieve this balance?  Obviously we don't want to follow Ubuntu or ROSA in pretending patents don't exist.
+>>
+>> Linux Mint provides a "No codecs" CD:
+>> http://www.linuxmint.com/download.php
+>>
+>> Ubuntu has a patent policy (which basically IIRC says "rights owner or
+>> packager, please contact us if you think there is an infringement, we
+>> will investgate"):
+>> https://wiki.ubuntu.com/PatentPolicy
+>>
+>> Note also that the Ubuntu Live CD and therefore the default Ubuntu
+>> installation do not contain any codecs. By default Totem is installed,
+>> however, and gstreamer is plugged into "gnome-codec-install" (which
+>> seems really nice, do we use it?), so that wen you try to play an
+>> unsupported video the first time, it will prompt to install the codecs
+>> (it will also show a warning dialog about patents etc, but AFAICS this
+>> comes from gnome-codec-install itself, not Ubuntu).
+> 
+> This looks nice
+> 
+
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011232.html b/zarb-ml/mageia-dev/2012-January/011232.html new file mode 100644 index 000000000..54ac218c3 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011232.html @@ -0,0 +1,146 @@ + + + + [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help + + + + + + + + + +

[Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help

+ Florian Hubold + doktor5000 at arcor.de +
+ Wed Jan 11 14:40:33 CET 2012 +

+
+ +
Am 11.01.2012 10:54, schrieb Wolfgang Bornath:
+> 2012/1/11 Marja van Waes <marja11 at xs4all.nl>:
+>> On 03/01/12 10:09, Wolfgang Bornath wrote:
+>>> 2012/1/3 Michael Scherer<misc at zarb.org>:
+>>>> Le lundi 02 janvier 2012 à 22:17 +0100, Maarten Vanraes a écrit :
+>>>>> Op maandag 02 januari 2012 21:40:31 schreef Michael Scherer:
+>>>>>> Le lundi 02 janvier 2012 à 19:41 +0100, Marja van Waes a écrit :
+>>>>>>> Hi everyone,
+>>>>>>>
+>>>>>>> Can someone please help to fix bug 1956?
+>>>>>>>
+>>>>>>> You don't need to be a regular forum visitor.
+>>>>>>>
+>>>>>>> We need someone to find and implement a probably existing MOD,  needed
+>>>>>>> to keep forum posts history when unlimited edit time is enabled
+>>>>>>>
+>>>>>>>  From wobo's comment #32:
+>>>>>>> Capabilities needed:
+>>>>>>> Well, one could say that anybody who
+>>>>>>>
+>>>>>>>   - knows how to run phpBB as admin and
+>>>>>>>   - has seen a line of php
+>>>>>>>   - knows how to edit code (respecting tags and such)
+>>>>>>>   - knows how to cut&paste
+>>>>>>>
+>>>>>>> should be able to install an existing MOD (if I'm not mistaken there
+>>>>>>> is
+>>>>>>> one or more).
+>>>>>>>
+>>>>>>> I know next to nothing about php coding. But I've been running a phpBB
+>>>>>>> forum for a couple of years and successfully implemented some MODs in
+>>>>>>> phpBB2 and phpBB3. With no help (except the phpBB-forum in case of
+>>>>>>> problems).
+>>>>>>>
+>>>>>>> In practice you have a detailed installation README for each MOD. Like
+>>>>>>>
+>>>>>>>   - open file /foo/bar/doo.php
+>>>>>>>   - Find the line which starts with '......'
+>>>>>>>   - After that add
+>>>>>>>   - "........."
+>>>>>>>
+>>>>>>> And more such step-by-step guidance
+>>>>>> My eyes start to bleed dues to such "guidances".
+>>>>> i'm sure misc means to say that we should have all our changes in
+>>>>> packages/puppet config so that we can update without issues. and with
+>>>>> file
+>>>>> edits, that's a whole different thing.
+>>>> I was more thinking of proper patchs or better, proper modules, with
+>>>> files to deploy in a well know directory .
+>>> I only gave a part of an example. MODs are made as enhancement to the
+>>> standard software. The easiest MOD is like Michael wrote: "a module
+>>> with files to deploy in a well known directory". But in most cases
+>>> they consist of files to copy into various directories of the program
+>>> tree and changes to existing files of the software. There are other
+>>> MODs which can be implemented automatically - which is far worse IMHO.
+>>> This is where a modded phpBB3 could turn into a nightmare to maintain
+>>> - believe me, I've been there :(
+>>>
+>>> Of course no developper of a MOD could know what somebody has already
+>>> done to the standard files, so it's not possible do use only patches.
+>>> And it could be (and that happens quite often) that a MOD is not
+>>> compatible to your already "modificated" forum software (destroys
+>>> other modifications or whatever).
+>>>
+>>> IMHO the best way in this case here would be a mod written for our
+>>> setup, all changes well defined to make it maintainable in a proper
+>>> way. Saying this I beg to think again whether the issue  justifies all
+>>> the time and work.
+>>>
+>> It would make me very, very happy, does that count a little? If I were sure
+>> that I'd be able to learn how to do it, I would now consider to halve the
+>> time I use for the Bug Squad and Doc Team and start learning.
+> Why? IMHO this complete issue is going out of proportions. Let's
+> remember why we *seem to need* this MOD in the first place. And what
+> will we find? The time-to-edit discussion, again. In the council
+> meeting where it was decided to have this mod It looked as the best
+> way to please a disturbing minority request, the more as that same
+> minority gave the impression that such a MOD could be implemented
+> within a reasonable time span. As we see now after 8 months, this was
+> never the case.
+>
+> Adding the fact that a test period of several months with a much
+> looser time-to-edit setting in the German Mageia forum showed not one
+> single case of misuse brings me to the conviction that we should
+> rather rethink the time-to-edit limitation itself than to waste
+> manpower on this issue. Manpower which is needed at more important
+> tasks, if I may say.
+>
+In general i don't like those +1 posts, but this ^^ one hits the nail on the head.
++1
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011233.html b/zarb-ml/mageia-dev/2012-January/011233.html new file mode 100644 index 000000000..d40b2b3d8 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011233.html @@ -0,0 +1,156 @@ + + + + [Mageia-dev] [RFC] Moving various packages/codecs to tainted + + + + + + + + + +

[Mageia-dev] [RFC] Moving various packages/codecs to tainted

+ Pascal Terjan + pterjan at gmail.com +
+ Wed Jan 11 15:01:40 CET 2012 +

+
+ +
On Wed, Jan 11, 2012 at 12:56, Anssi Hannula <anssi at mageia.org> wrote:
+> On 10.01.2012 15:07, Pascal Terjan wrote:
+>> On Tue, Jan 10, 2012 at 03:20, Anssi Hannula <anssi at mageia.org> wrote:
+>>> The problem is that that "balance" was achieved by sticking packages in
+>>> PLF/main/contrib semi-randomly. For example, H.264 decoders and MPEG-4
+>>> video encoders are in main/core, while e.g. AAC audio decoders are in
+>>> PLF/tainted. If one'd put them into an order, IMO H.264 and MPEG-4 would
+>>> be much more prominent and tainted candidates instead of AAC decoding...
+>>> Also, in e.g. MPEG-4 case we have encoders both in core and in tainted,
+>>> e.g. we have ffmpeg in core, but xvid in tainted.
+>>
+>> I agree we need rules, but "being covered with patents" does not make
+>> sense, as the patent owner may agree with using it in free software.
+>> I think something like "No actively enforced patent" in core would be good.
+>
+> Possibly, but how do you define that, exactly?
+>
+> Does a licensing program count as "enforcing" or do you mean something else?
+
+Yes, that's what I meant
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011234.html b/zarb-ml/mageia-dev/2012-January/011234.html new file mode 100644 index 000000000..6d85b0b33 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011234.html @@ -0,0 +1,106 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Antoine Pitrou + solipsis at pitrou.net +
+ Wed Jan 11 16:09:27 CET 2012 +

+
+ +
On Tue, 10 Jan 2012 20:28:15 -0600
+Luis Daniel Lucio Quiroz
+<dlucio at okay.com.mx> wrote:
+> 
+> You dont get me,
+> 
+> I mean, stop asking updates for mageia 1 just because there is another 
+> newversion.
+
+Uh.
+As a Mageia user I would expect Mageia to package significant *bugfix
+releases* and ship them in the updates for the stable distro.
+
+For example, it would be nice if an up-to-date Mageia 1 system had
+Python 2.7.2 rather than Python 2.7.1 (not a deal-breaker, of course,
+but nice). There's more than a hundred bug fixes between the two
+versions and I don't expect Mageia to have independently fixed many of
+these bugs.
+
+If you think shipping bugfixes isn't part of the QA for a stable version
+then I'm not sure what said QA should be (apart from updating Firefox
+to new major versions that is :-)).
+
+Regards
+
+Antoine.
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011235.html b/zarb-ml/mageia-dev/2012-January/011235.html new file mode 100644 index 000000000..9ac4382a0 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011235.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Wed Jan 11 16:51:55 CET 2012 +

+
+ +
Le 11/01/2012 16:09, Antoine Pitrou a écrit :
+> As a Mageia user I would expect Mageia to package significant *bugfix
+> releases* and ship them in the updates for the stable distro.
+You'd rather read the current update policy, rather than expect blind 
+assertions:
+https://wiki.mageia.org/en/Updates_policy
+
+> For example, it would be nice if an up-to-date Mageia 1 system had
+> Python 2.7.2 rather than Python 2.7.1 (not a deal-breaker, of course,
+> but nice). There's more than a hundred bug fixes between the two
+> versions and I don't expect Mageia to have independently fixed many of
+> these bugs.
+A bug may vary from a typo in a man page to a critical security update, 
+which make the number of claimed bugfix a poor decision metric. A 
+non-regression ensurance would be a better one, but it's quite difficult 
+to assert.
+
+> If you think shipping bugfixes isn't part of the QA for a stable version
+> then I'm not sure what said QA should be (apart from updating Firefox
+> to new major versions that is :-)).
+Welcome to our new QA team volonteer :)
+
+-- 
+BOFH excuse #368:
+
+Failure to adjust for daylight savings time.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011236.html b/zarb-ml/mageia-dev/2012-January/011236.html new file mode 100644 index 000000000..110360b53 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011236.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Juan Luis Baptiste + juancho at mageia.org +
+ Wed Jan 11 17:24:20 CET 2012 +

+
+ +
On Wed, Jan 11, 2012 at 3:43 AM, Florian Hubold <doktor5000 at arcor.de> wrote:
+> Well, 2) and 3) are not valid reasons here, because backports should get
+> a similar amount of QA testing as normal update candidates, and for
+> the updates policy require a bugreport for validation through QA.
+
+I think this is unrealistic in practice. For updates, QA will be
+testing one bug fix,  with a backport you will have dozens or more new
+features to test, you can't expect for QA to test all of them to be
+able to give the OK, more if they even don't use the backported app in
+a daily basis. Testing of a backport has to be more relaxed and
+compromise to test some basic stuff like that it installs and starts
+correctly, maybe the package maintainer can give some hints on what
+else to test, but the rest we will have to trust in the maintainer's
+judgement.
+
+If you think that all version backports should be tested in the same
+way as updates by QA, then all versions upgrades in cauldron should be
+tested by QA before pushing them to the BS right ? why risk for a bug
+on a program when updating to a new mga version and not when doing a
+backport ?, it's exactly the same situation.
+
+
+
+-- 
+Juancho
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011237.html b/zarb-ml/mageia-dev/2012-January/011237.html new file mode 100644 index 000000000..898dc0fd7 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011237.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help + + + + + + + + + +

[Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help

+ Marja van Waes + marja11 at xs4all.nl +
+ Wed Jan 11 17:41:46 CET 2012 +

+
+ +
On 11/01/12 10:54, Wolfgang Bornath wrote:
+> 2012/1/11 Marja van Waes<marja11 at xs4all.nl>:
+>> On 03/01/12 10:09, Wolfgang Bornath wrote:
+>>>>>
+>>>>>> Le lundi 02 janvier 2012 à 19:41 +0100, Marja van Waes a écrit :
+>>>>>>> Hi everyone,
+>>>>>>>
+>>>>>>> Can someone please help to fix bug 1956?
+>>>>>>>
+>>>
+>>> IMHO the best way in this case here would be a mod written for our
+>>> setup, all changes well defined to make it maintainable in a proper
+>>> way. Saying this I beg to think again whether the issue  justifies all
+>>> the time and work.
+>>>
+>> It would make me very, very happy, does that count a little? If I were sure
+>> that I'd be able to learn how to do it, I would now consider to halve the
+>> time I use for the Bug Squad and Doc Team and start learning.
+> Why? IMHO this complete issue is going out of proportions. Let's
+> remember why we *seem to need* this MOD in the first place. And what
+> will we find? The time-to-edit discussion, again. In the council
+> meeting where it was decided to have this mod It looked as the best
+> way to please a disturbing minority request, the more as that same
+> minority gave the impression that such a MOD could be implemented
+> within a reasonable time span. As we see now after 8 months, this was
+> never the case.
+
+I can't talk for that minority, of course. However, I can talk for myself:
+
+In such circumstances it is very possible that I'd agree to do something 
+to later find out I can't concentrate on the task no matter how hard I try.
+
+I regret it wasn't decided that the people who wanted unlimited edit 
+time should make the MOD, after which the unlimited edit time would be 
+implemented. They were going to get what they wanted (the unlimited edit 
+time), wouldn't that have "given them wings" to do that MOD?
+
+
+Regards,
+
+Marja
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011238.html b/zarb-ml/mageia-dev/2012-January/011238.html new file mode 100644 index 000000000..2e7f79aa8 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011238.html @@ -0,0 +1,113 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Antoine Pitrou + solipsis at pitrou.net +
+ Wed Jan 11 17:43:35 CET 2012 +

+
+ +
On Wed, 11 Jan 2012 16:51:55 +0100
+Guillaume Rousse
+<guillomovitch at gmail.com> wrote:
+> Le 11/01/2012 16:09, Antoine Pitrou a écrit :
+> > As a Mageia user I would expect Mageia to package significant *bugfix
+> > releases* and ship them in the updates for the stable distro.
+> You'd rather read the current update policy, rather than expect blind 
+> assertions:
+> https://wiki.mageia.org/en/Updates_policy
+
+Thanks.
+
+> > For example, it would be nice if an up-to-date Mageia 1 system had
+> > Python 2.7.2 rather than Python 2.7.1 (not a deal-breaker, of course,
+> > but nice). There's more than a hundred bug fixes between the two
+> > versions and I don't expect Mageia to have independently fixed many of
+> > these bugs.
+> A bug may vary from a typo in a man page to a critical security update, 
+> which make the number of claimed bugfix a poor decision metric. A 
+> non-regression ensurance would be a better one, but it's quite difficult 
+> to assert.
+
+As both an user and an upstream developer, I would not expect a Mageia
+packager to know better than the upstream developers what can
+constitute a regression, and what is a good compromise to fix or not.
+At least for well-maintained upstream projects, that is :-)
+
+> Welcome to our new QA team volonteer :)
+
+Agreed that my advice would be more constructive if I got involved, but
+I don't have the time for that.
+
+Regards
+
+Antoine.
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011239.html b/zarb-ml/mageia-dev/2012-January/011239.html new file mode 100644 index 000000000..9bc7beeb8 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011239.html @@ -0,0 +1,136 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Christian Lohmaier + lohmaier+mageia at googlemail.com +
+ Wed Jan 11 17:48:28 CET 2012 +

+
+ +
On Wed, Jan 11, 2012 at 4:51 PM, Guillaume Rousse
+<guillomovitch at gmail.com> wrote:
+> Le 11/01/2012 16:09, Antoine Pitrou a écrit :
+>
+>> As a Mageia user I would expect Mageia to package significant *bugfix
+>> releases* and ship them in the updates for the stable distro.
+>
+> You'd rather read the current update policy, rather than expect blind
+> assertions:
+> https://wiki.mageia.org/en/Updates_policy
+
+Whoa - this is a rather stupid policy. (my opinion, yours obviously differs).
+"For the most part, an update should consist of a <bold>patched build
+of the same version</bold> of the package released with the
+distribution,"
+
+Welcome to distro-isolation, putting burden on maintainers, giving
+them all the reason to deny a reasonable request for a bugfix release
+because it just is too much work to hunt for a specific commit that
+fixed bug x.
+
+>> For example, it would be nice if an up-to-date Mageia 1 system had
+>> Python 2.7.2 rather than Python 2.7.1 (not a deal-breaker, of course,
+>> but nice). There's more than a hundred bug fixes between the two
+>> versions and I don't expect Mageia to have independently fixed many of
+>> these bugs.
+>
+> A bug may vary from a typo in a man page to a critical security update,
+
+And a typo-fix is not worthwhile to have?
+
+> which make the number of claimed bugfix a poor decision metric. A
+> non-regression ensurance would be a better one, but it's quite difficult to
+> assert.
+
+Don't assume all upstream projects are a bunch of clueless idiots.
+
+For upstream releases that have a clear version/release scheme, with
+micro releases being compatible bugfixes only, the above mentioned
+policy is completely nonsense, same for your fear of regressions, etc.
+
+Sure, you cannot be save of regressions, but what makes you think you
+are smarter than upstream? What makes you so sure that not the one
+commit you add as a patch to your package is the one that causes the
+regressions?
+
+Regressions have the nice habit of being triggered by changes in
+apparently unrelated code...
+
+My 0.02€ only, but I strongly suggest for that update policy to be clarified.
+When there is no dedicated bugfix release procedure in the upstream
+package, an update is a rebuild of the same version with a
+corresponding patch. That's reasonable (as opposed to using a newer
+minor or even major release, those are backports).
+But once again: if upstream has a major.minor.micro scheme with micro
+versions being bugfix releases, I really don't see any sane reason for
+not "allowing" those updates.
+
+ciao
+Christian
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011240.html b/zarb-ml/mageia-dev/2012-January/011240.html new file mode 100644 index 000000000..7e84c9d19 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011240.html @@ -0,0 +1,144 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Pascal Terjan + pterjan at gmail.com +
+ Wed Jan 11 17:54:57 CET 2012 +

+
+ +
On Wed, Jan 11, 2012 at 16:48, Christian Lohmaier
+<lohmaier+mageia at googlemail.com> wrote:
+> On Wed, Jan 11, 2012 at 4:51 PM, Guillaume Rousse
+> <guillomovitch at gmail.com> wrote:
+>> Le 11/01/2012 16:09, Antoine Pitrou a écrit :
+>>
+>>> As a Mageia user I would expect Mageia to package significant *bugfix
+>>> releases* and ship them in the updates for the stable distro.
+>>
+>> You'd rather read the current update policy, rather than expect blind
+>> assertions:
+>> https://wiki.mageia.org/en/Updates_policy
+>
+> Whoa - this is a rather stupid policy. (my opinion, yours obviously differs).
+> "For the most part, an update should consist of a <bold>patched build
+> of the same version</bold> of the package released with the
+> distribution,"
+>
+> Welcome to distro-isolation, putting burden on maintainers, giving
+> them all the reason to deny a reasonable request for a bugfix release
+> because it just is too much work to hunt for a specific commit that
+> fixed bug x.
+>
+>>> For example, it would be nice if an up-to-date Mageia 1 system had
+>>> Python 2.7.2 rather than Python 2.7.1 (not a deal-breaker, of course,
+>>> but nice). There's more than a hundred bug fixes between the two
+>>> versions and I don't expect Mageia to have independently fixed many of
+>>> these bugs.
+>>
+>> A bug may vary from a typo in a man page to a critical security update,
+>
+> And a typo-fix is not worthwhile to have?
+>
+>> which make the number of claimed bugfix a poor decision metric. A
+>> non-regression ensurance would be a better one, but it's quite difficult to
+>> assert.
+>
+> Don't assume all upstream projects are a bunch of clueless idiots.
+
+Don't assume the opposite either, it really depend on each project.
+
+> For upstream releases that have a clear version/release scheme, with
+> micro releases being compatible bugfixes only, the above mentioned
+> policy is completely nonsense, same for your fear of regressions, etc.
+
+Yes, bugfix only release have always been accepted, this should be
+added to the exceptions on the wiki.
+
+> Sure, you cannot be save of regressions, but what makes you think you
+> are smarter than upstream? What makes you so sure that not the one
+> commit you add as a patch to your package is the one that causes the
+> regressions?
+
+Because the most changes you had, the most likely a regression is
+
+> Regressions have the nice habit of being triggered by changes in
+> apparently unrelated code...
+>
+> My 0.02€ only, but I strongly suggest for that update policy to be clarified.
+> When there is no dedicated bugfix release procedure in the upstream
+> package, an update is a rebuild of the same version with a
+> corresponding patch. That's reasonable (as opposed to using a newer
+> minor or even major release, those are backports).
+> But once again: if upstream has a major.minor.micro scheme with micro
+> versions being bugfix releases, I really don't see any sane reason for
+> not "allowing" those updates.
+
+Yes, they are actually allowed.
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011241.html b/zarb-ml/mageia-dev/2012-January/011241.html new file mode 100644 index 000000000..f8ac3e3c2 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011241.html @@ -0,0 +1,127 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Juan Luis Baptiste + juancho at mageia.org +
+ Wed Jan 11 18:43:35 CET 2012 +

+
+ +
On Wed, Jan 11, 2012 at 11:48 AM, Christian Lohmaier
+<lohmaier+mageia at googlemail.com> wrote:
+> Welcome to distro-isolation, putting burden on maintainers, giving
+> them all the reason to deny a reasonable request for a bugfix release
+> because it just is too much work to hunt for a specific commit that
+> fixed bug x.
+>
+
+You don't do packaging, right ?
+
+it isn't that hard and is how all distro's do it. Look at Fedora or
+SuSE's packages and you will see a lot of patch files fixing single
+bugs. It's a matter of following upstream bugzilla reports and see
+which commit fixes the issue in question, create a patch from it and
+apply it to the package. Most of the time you can get the patches to
+fix single bugs from other distros packages.
+
+If there's a bugfix-only release it's better as it will be easier to
+update, but many times they aren't and include new features which
+could introduce regressions so we have to cherry pick those fixes.
+Also many times there isn't a new release from upstream so the only
+option we have is to backport a single fix.
+
+>> A bug may vary from a typo in a man page to a critical security update,
+>
+> And a typo-fix is not worthwhile to have?
+>
+
+I think that what was meant here is that there are priorities for QA,
+where a security update is much more important and deserves more
+attention than a typo-fix. Of course, you are welcome to join the QA
+team to help them test those not so critical fixes if you really care
+that much about them.
+
+>
+> Sure, you cannot be save of regressions, but what makes you think you
+> are smarter than upstream? What makes you so sure that not the one
+> commit you add as a patch to your package is the one that causes the
+> regressions?
+>
+
+Because as I said earlier, we backport the "commit" that fixes that
+single issue, based on the info found on the bugzilla report of the
+upstream project. Also as you say most of the times upstream is not a
+bunch of clueless idiots so they will document very well each commit,
+making it easier for us to find those fixes.
+
+Cheers,
+
+-- 
+Juancho
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011242.html b/zarb-ml/mageia-dev/2012-January/011242.html new file mode 100644 index 000000000..ec4211d40 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011242.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Antoine Pitrou + solipsis at pitrou.net +
+ Wed Jan 11 19:22:23 CET 2012 +

+
+ +
On Wed, 11 Jan 2012 12:43:35 -0500
+Juan Luis Baptiste <juancho at mageia.org>
+wrote:
+> > Sure, you cannot be save of regressions, but what makes you think you
+> > are smarter than upstream? What makes you so sure that not the one
+> > commit you add as a patch to your package is the one that causes the
+> > regressions?
+> >
+> 
+> Because as I said earlier, we backport the "commit" that fixes that
+> single issue, based on the info found on the bugzilla report of the
+> upstream project.
+
+But how do you choose which patches you want to backport from the
+stream of bugfixes done by upstream? Should the packager monitor all
+bug fixing activity? (sure (s)he *can*, but that's a lot of work)
+
+Just because someone doesn't file a bug against Mageia doesn't mean the
+bug doesn't bother anybody, because many users don't report upstream
+bugs to the distro's tracker.
+(also, other users don't bother reporting bugs at all :-))
+
+Regards
+
+Antoine.
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011243.html b/zarb-ml/mageia-dev/2012-January/011243.html new file mode 100644 index 000000000..4a03cfa8e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011243.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Juan Luis Baptiste + juancho at mageia.org +
+ Wed Jan 11 19:33:41 CET 2012 +

+
+ +
On Wed, Jan 11, 2012 at 1:22 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
+> On Wed, 11 Jan 2012 12:43:35 -0500
+> But how do you choose which patches you want to backport from the
+> stream of bugfixes done by upstream?
+
+Because normally a single commit fixes a single bug and the commit
+message says it clearly, so it's easy to spot the fixes.
+
+> Should the packager monitor all
+> bug fixing activity? (sure (s)he *can*, but that's a lot of work)
+>
+
+No we don't need to, we just need to look for the fix we are
+interested in as I described before.
+
+> Just because someone doesn't file a bug against Mageia doesn't mean the
+> bug doesn't bother anybody, because many users don't report upstream
+> bugs to the distro's tracker.
+> (also, other users don't bother reporting bugs at all :-))
+>
+
+Don't think that when we get a bug report in mga bugzilla is because
+only mga users are affected ;) most of the time there's already an
+upstream bug report so we start following it and give any useful
+information we have about it. If it isn't we create it and follow it.
+
+-- 
+Juancho
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011244.html b/zarb-ml/mageia-dev/2012-January/011244.html new file mode 100644 index 000000000..99542ccd1 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011244.html @@ -0,0 +1,135 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Michael Scherer + misc at zarb.org +
+ Wed Jan 11 20:10:02 CET 2012 +

+
+ +
Le mercredi 11 janvier 2012 à 11:24 -0500, Juan Luis Baptiste a écrit :
+> On Wed, Jan 11, 2012 at 3:43 AM, Florian Hubold <doktor5000 at arcor.de> wrote:
+> > Well, 2) and 3) are not valid reasons here, because backports should get
+> > a similar amount of QA testing as normal update candidates, and for
+> > the updates policy require a bugreport for validation through QA.
+> 
+> I think this is unrealistic in practice. For updates, QA will be
+> testing one bug fix,  with a backport you will have dozens or more new
+> features to test, you can't expect for QA to test all of them to be
+> able to give the OK, more if they even don't use the backported app in
+> a daily basis. Testing of a backport has to be more relaxed and
+> compromise to test some basic stuff like that it installs and starts
+> correctly, maybe the package maintainer can give some hints on what
+> else to test, but the rest we will have to trust in the maintainer's
+> judgement.
+ 
+So trusting and having bugs are totally unrelated. And if you doubt that
+bugs appear, just see our bugzilla.
+We trust upstream ( most of them ), and yet there is bugs.
+
+> If you think that all version backports should be tested in the same
+> way as updates by QA, then all versions upgrades in cauldron should be
+> tested by QA before pushing them to the BS right ? 
+
+No, they should be tested before being put in the stable release. And
+that's exactly what we do by freezing and testing before release.
+
+> why risk for a bug
+> on a program when updating to a new mga version and not when doing a
+> backport ?, it's exactly the same situation.
+
+That was already extensively discussed in the past, but if we do the
+same stuff than in Mandriva, we will end with the same result than in
+Mandriva.
+- people don't test backports, because that's not mandatory 
+=> some bugs slips.
+
+then users start to say "do not use backport if you do not know what you
+do or if you are not expert, because I had $problem once". With time,
+such advice start to impermeate the community, and people start to
+simply not use backports.
+
+Worst, some people just do cherry picking of backports, and take one or
+two or them, and this result in wierd bugs with 2 effects :
+- we lose time
+- user think we are doing a bad quality distribution, because he has a
+mix that he is the only one in the world to have. Non technical users
+tell him he should not mix ( and they are right ), and so he start to
+feel bad because we gave him something that do not ork. Some users also
+end with system unsupported, so no security update, nor bugfixes.
+
+In the end, users complain that distribution is broken, and that impact
+our image. We cannot tell "do not mix", because we cannot tell them to
+update backports without fear, as that would be lying. And in the end,
+saying "this is not supported, but we offer to you" is just sending a
+confusing message.
+
+If we start to give low quality stuff as Mageia, people will just think
+Mageia is low quality.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011245.html b/zarb-ml/mageia-dev/2012-January/011245.html new file mode 100644 index 000000000..12645bed2 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011245.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Antoine Pitrou + solipsis at pitrou.net +
+ Wed Jan 11 20:19:46 CET 2012 +

+
+ +
On Wed, 11 Jan 2012 13:33:41 -0500
+Juan Luis Baptiste <juancho at mageia.org>
+wrote:
+> On Wed, Jan 11, 2012 at 1:22 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
+> > On Wed, 11 Jan 2012 12:43:35 -0500
+> > But how do you choose which patches you want to backport from the
+> > stream of bugfixes done by upstream?
+> 
+> Because normally a single commit fixes a single bug and the commit
+> message says it clearly, so it's easy to spot the fixes.
+> 
+> > Should the packager monitor all
+> > bug fixing activity? (sure (s)he *can*, but that's a lot of work)
+> >
+> 
+> No we don't need to, we just need to look for the fix we are
+> interested in as I described before.
+
+Uh, you have a hard time understanding a question don't you?
+
+I specifically asked *how* you come to be interested in a particular
+fix, rather than all of them.
+
+So, again, do you monitor all commits or is there another heuristic you
+apply to avoid that O(n) process?
+
+Regards
+
+Antoine.
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011246.html b/zarb-ml/mageia-dev/2012-January/011246.html new file mode 100644 index 000000000..79d21a414 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011246.html @@ -0,0 +1,218 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Michael Scherer + misc at zarb.org +
+ Wed Jan 11 20:32:59 CET 2012 +

+
+ +
Le mercredi 11 janvier 2012 à 17:48 +0100, Christian Lohmaier a écrit :
+> On Wed, Jan 11, 2012 at 4:51 PM, Guillaume Rousse
+> <guillomovitch at gmail.com> wrote:
+> > Le 11/01/2012 16:09, Antoine Pitrou a écrit :
+> >
+> >> As a Mageia user I would expect Mageia to package significant *bugfix
+> >> releases* and ship them in the updates for the stable distro.
+> >
+> > You'd rather read the current update policy, rather than expect blind
+> > assertions:
+> > https://wiki.mageia.org/en/Updates_policy
+> 
+> Whoa - this is a rather stupid policy. (my opinion, yours obviously differs).
+> "For the most part, an update should consist of a <bold>patched build
+> of the same version</bold> of the package released with the
+> distribution,"
+
+I am pretty sure that you can express yourself without starting by
+insulting people. That would surely help to be listened ( cause right
+now, I must tell that I am not very keen on that )
+
+> Welcome to distro-isolation, putting burden on maintainers, giving
+> them all the reason to deny a reasonable request for a bugfix release
+> because it just is too much work to hunt for a specific commit that
+> fixed bug x.
+
+If that's too much work for a maintainer and if that's important for
+you, you can :
+- do your own package, supported by yourself for yourself
+or :
+- provide the patch
+
+If that's too much work for you too, then that's likely too much work
+for others too.
+
+> >> For example, it would be nice if an up-to-date Mageia 1 system had
+> >> Python 2.7.2 rather than Python 2.7.1 (not a deal-breaker, of course,
+> >> but nice). There's more than a hundred bug fixes between the two
+> >> versions and I don't expect Mageia to have independently fixed many of
+> >> these bugs.
+> >
+> > A bug may vary from a typo in a man page to a critical security update,
+> 
+> And a typo-fix is not worthwhile to have?
+
+When we take in account the fact it would still need proper QA, there is
+likely stuff that are more important than a typo. And a typo is just a
+extreme case, and a simplificaition. If we start to have a complex
+update policy, we are just losing time for almost nothing.
+
+> > which make the number of claimed bugfix a poor decision metric. A
+> > non-regression ensurance would be a better one, but it's quite difficult to
+> > assert.
+> 
+> Don't assume all upstream projects are a bunch of clueless idiots.
+
+We didn't say that. We just assume that errors happen to everybody.
+
+> For upstream releases that have a clear version/release scheme, with
+> micro releases being compatible bugfixes only, the above mentioned
+> policy is completely nonsense, same for your fear of regressions, etc.
+
+Regressions do happens. 
+
+> Sure, you cannot be save of regressions, but what makes you think you
+> are smarter than upstream? What makes you so sure that not the one
+> commit you add as a patch to your package is the one that causes the
+> regressions?
+
+For 1, we usually do not do distro patch. I personnaly think this should
+be avoided as much as possible, and that we should push as much patch
+upstream. We have a rather huge backlog to clean.
+
+For 2, we also usually take patch from upstream. Some of us are also
+good enough to understand patchs, and to see what they mean, if they fix
+something, etc. Of course, there is some software that are rather
+specialized or obscure, but that's far from being the majority.
+
+> Regressions have the nice habit of being triggered by changes in
+> apparently unrelated code...
+
+
+And that's why we should reduce the number of changes. 
+
+> My 0.02€ only, but I strongly suggest for that update policy to be clarified.
+> When there is no dedicated bugfix release procedure in the upstream
+> package, an update is a rebuild of the same version with a
+> corresponding patch. That's reasonable (as opposed to using a newer
+> minor or even major release, those are backports).
+> But once again: if upstream has a major.minor.micro scheme with micro
+> versions being bugfix releases, I really don't see any sane reason for
+> not "allowing" those updates.
+
+Maybe if you started to be less insulting, and instead started to look
+at the discussion on the ml in the past on the list, when the policy was
+discussed ( and access to the old wiki too ), you would likely find the
+reasons saner.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011247.html b/zarb-ml/mageia-dev/2012-January/011247.html new file mode 100644 index 000000000..84de2538d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011247.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Johnny A. Solbu + cooker at solbu.net +
+ Wed Jan 11 20:38:48 CET 2012 +

+
+ +
On Wednesday 11 January 2012 19:33, Juan Luis Baptiste wrote:
+> > Should the packager monitor all
+> > bug fixing activity?
+>
+> No we don't need to, we just need to look for the fix we are
+> interested in as I described before.
+
+And how do one do that without monitoring most bugfixing activity or reviewing them, hunting for a particular fix?
+
+To some people, that magic trick is not obvious.
+
+-- 
+Johnny A. Solbu
+PGP key ID: 0xFA687324
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 189 bytes
+Desc: This is a digitally signed message part.
+URL: </pipermail/mageia-dev/attachments/20120111/e983f6db/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011248.html b/zarb-ml/mageia-dev/2012-January/011248.html new file mode 100644 index 000000000..a9fe4b2d1 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011248.html @@ -0,0 +1,106 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Juan Luis Baptiste + juancho at mageia.org +
+ Wed Jan 11 20:41:54 CET 2012 +

+
+ +
On Wed, Jan 11, 2012 at 2:19 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
+> On Wed, 11 Jan 2012 13:33:41 -0500
+>> >
+>>
+>> No we don't need to, we just need to look for the fix we are
+>> interested in as I described before.
+>
+> Uh, you have a hard time understanding a question don't you?
+>
+
+And you a hard time understanding an answer, don't you ? pfff...
+
+> I specifically asked *how* you come to be interested in a particular
+> fix, rather than all of them.
+>
+
+As I said, when there's a bug report on mga, we start investigating
+the problem and go and look at upstream for a bug report there for
+*that* particular bug. Then, when we see it fixed we go to the control
+versioning system ang create a patch from the commit that fixed *that*
+bug according to the upstream report and apply it to the mga package,
+what isn't clear about that ?
+
+> So, again, do you monitor all commits or is there another heuristic you
+> apply to avoid that O(n) process?
+>
+
+Again, read with attention what I said before and on this answer.
+
+-- 
+Juancho
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011249.html b/zarb-ml/mageia-dev/2012-January/011249.html new file mode 100644 index 000000000..e3e57695a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011249.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Juan Luis Baptiste + juancho at mageia.org +
+ Wed Jan 11 20:43:56 CET 2012 +

+
+ +
On Wed, Jan 11, 2012 at 2:38 PM, Johnny A. Solbu <cooker at solbu.net> wrote:
+> On Wednesday 11 January 2012 19:33, Juan Luis Baptiste wrote:
+> And how do one do that without monitoring most bugfixing activity or reviewing them, hunting for a particular fix?
+>
+> To some people, that magic trick is not obvious.
+>
+
+As I said before, the upstream bug report will tell you which commit
+fixed the bug, so you go ahead and get that particular revision and
+create a patch to apply to the packages, there's no need to monitor
+*all* bugfixing activity, you just look for what you need when you
+need to.
+
+-- 
+Juancho
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011250.html b/zarb-ml/mageia-dev/2012-January/011250.html new file mode 100644 index 000000000..f4ec66d2f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011250.html @@ -0,0 +1,150 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Michael Scherer + misc at zarb.org +
+ Wed Jan 11 20:50:32 CET 2012 +

+
+ +
Le mercredi 11 janvier 2012 à 16:09 +0100, Antoine Pitrou a écrit :
+> On Tue, 10 Jan 2012 20:28:15 -0600
+> Luis Daniel Lucio Quiroz
+> <dlucio at okay.com.mx> wrote:
+> > 
+> > You dont get me,
+> > 
+> > I mean, stop asking updates for mageia 1 just because there is another 
+> > newversion.
+> 
+> Uh.
+> As a Mageia user I would expect Mageia to package significant *bugfix
+> releases* and ship them in the updates for the stable distro.
+>
+> For example, it would be nice if an up-to-date Mageia 1 system had
+> Python 2.7.2 rather than Python 2.7.1 (not a deal-breaker, of course,
+> but nice). There's more than a hundred bug fixes between the two
+> versions and I don't expect Mageia to have independently fixed many of
+> these bugs.
+> 
+> If you think shipping bugfixes isn't part of the QA for a stable version
+> then I'm not sure what said QA should be (apart from updating Firefox
+> to new major versions that is :-)).
+
+The policy ( as I remember when we discussed on this ml ) would allow to
+ship it, the specific case that I had in mind was postgresql, because it
+has a strict policy on backporting fixes, and regression testing, but
+python would fit too.
+
+However, my current workload and priority list do not place "doing a
+python update" on the top of the list. As you say, that's not a deal
+breaker, so I prefer to focus on what would be more important or urgent
+( like for example, fixing servers and broken raid array ).
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011251.html b/zarb-ml/mageia-dev/2012-January/011251.html new file mode 100644 index 000000000..57769ea5a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011251.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ zezinho + lists.jjorge at free.fr +
+ Wed Jan 11 20:56:44 CET 2012 +

+
+ +
Le mercredi 11 janvier 2012 19:22:23, Antoine Pitrou a écrit :
+> Just because someone doesn't file a bug against Mageia doesn't mean the
+> bug doesn't bother anybody, because many users don't report upstream
+> bugs to the distro's tracker.
+> (also, other users don't bother reporting bugs at all :-))
+> 
+
+That's it. This is why we provide the whole bugfix release from upstream as 
+update when it is a PURE BUGFIX release (no new features).
+
+Backports are here for releases with new features.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011252.html b/zarb-ml/mageia-dev/2012-January/011252.html new file mode 100644 index 000000000..286ef43b5 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011252.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Antoine Pitrou + solipsis at pitrou.net +
+ Wed Jan 11 21:05:53 CET 2012 +

+
+ +
On Wed, 11 Jan 2012 14:41:54 -0500
+Juan Luis Baptiste <juancho at mageia.org>
+wrote:
+> 
+> As I said, when there's a bug report on mga, we start investigating
+> the problem and go and look at upstream for a bug report there for
+> *that* particular bug.
+
+So let me repeat myself from two messages above (!):
+
+“Just because someone doesn't file a bug against Mageia doesn't mean the
+bug doesn't bother anybody, because many users don't report upstream
+bugs to the distro's tracker.”
+
+Regards
+
+Antoine.
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011253.html b/zarb-ml/mageia-dev/2012-January/011253.html new file mode 100644 index 000000000..65d57bb8a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011253.html @@ -0,0 +1,153 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Juan Luis Baptiste + juancho at mageia.org +
+ Wed Jan 11 21:10:01 CET 2012 +

+
+ +
On Wed, Jan 11, 2012 at 2:10 PM, Michael Scherer <misc at zarb.org> wrote:
+> Le mercredi 11 janvier 2012 à 11:24 -0500, Juan Luis Baptiste a écrit :
+>
+> So trusting and having bugs are totally unrelated. And if you doubt that
+> bugs appear, just see our bugzilla.
+> We trust upstream ( most of them ), and yet there is bugs.
+
+No, they're not totally unrelated when we don't have the man power to
+do through QA on every package, we need to trust on the packager (and
+upstream of course) that he did his best to test the new version
+without expecting him to have tested all the new features, Or do you
+expect that a QA member get a list of all the new features of a
+backport and start testing them one by one ? that's what I call
+unrealistic in practice.
+
+>
+>> If you think that all version backports should be tested in the same
+>> way as updates by QA, then all versions upgrades in cauldron should be
+>> tested by QA before pushing them to the BS right ?
+>
+> No, they should be tested before being put in the stable release. And
+> that's exactly what we do by freezing and testing before release.
+>
+
+Of course but again, we can't test *all* the new features of *all* the
+programs that are going to a new release, we do our best for most of
+them. Critical components like installer, kernel, drak* tools, etc
+need more testing and that's where (our very small team) QA should
+spend their time after a freeze. The rest we have to do our best to
+test after each version update of a package.
+
+>> why risk for a bug
+>> on a program when updating to a new mga version and not when doing a
+>> backport ?, it's exactly the same situation.
+>
+> That was already extensively discussed in the past, but if we do the
+> same stuff than in Mandriva, we will end with the same result than in
+> Mandriva.
+> - people don't test backports, because that's not mandatory
+> => some bugs slips.
+>
+
+Of course and that will also happen when updating packages during the
+development cycle of cauldron. Yes, we do freeze to be able to test,
+but we cant test every new feature of all applications. We test the
+most critical stuff which we can't risk to have bugs (and they also
+slip some times).
+
+>
+> In the end, users complain that distribution is broken, and that impact
+> our image. We cannot tell "do not mix", because we cannot tell them to
+> update backports without fear, as that would be lying. And in the end,
+> saying "this is not supported, but we offer to you" is just sending a
+> confusing message.
+>
+> If we start to give low quality stuff as Mageia, people will just think
+> Mageia is low quality.
+>
+
+Users will complain anyway, they will complain because there aren't
+backports of their favorite application or because a backported
+version has a bug, so we need to find a balance between those two.
+Expecting to do the same amount of testing to a backport will put too
+much burden on QA and will make the process of backporting a version
+too slow for the users. So we need to have more lax tests for
+backports, enough to guarantee that the application works for it's
+main features and doesn't put too much burnden on QA, than for updates
+which need to gurantee that a bug is really fixed. How to define which
+should be those tests ? that's the issue as I see it. We could have a
+"backports team" thought, that would do QA for backports without
+taking time from the updates QA team...
+
+Also the other problem is the third-party repos which brings lots of
+problems because packages are of low quality and don't follow our
+standards, and if we don't have our own backports and move fast enough
+users will continue to use those third-party repos, which will also
+bring the "Mageia is of low quality" problem.
+
+
+-- 
+Juancho
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011254.html b/zarb-ml/mageia-dev/2012-January/011254.html new file mode 100644 index 000000000..0da422562 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011254.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Juan Luis Baptiste + juancho at mageia.org +
+ Wed Jan 11 21:13:05 CET 2012 +

+
+ +
On Wed, Jan 11, 2012 at 3:05 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
+>
+> “Just because someone doesn't file a bug against Mageia doesn't mean the
+> bug doesn't bother anybody, because many users don't report upstream
+> bugs to the distro's tracker.”
+>
+
+Simple, we won't fix bugs that aren't reported or noticed by us,
+that's unrealistic, someone needs to bring the attention to us if they
+want it to be fixed.
+
+-- 
+Juancho
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011255.html b/zarb-ml/mageia-dev/2012-January/011255.html new file mode 100644 index 000000000..6487224e4 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011255.html @@ -0,0 +1,83 @@ + + + + [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help + + + + + + + + + +

[Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help

+ nicolas vigier + boklm at mars-attacks.org +
+ Wed Jan 11 21:13:50 CET 2012 +

+
+ +
On Wed, 11 Jan 2012, Marja van Waes wrote:
+
+>
+> I can't talk for that minority, of course. However, I can talk for myself:
+>
+> In such circumstances it is very possible that I'd agree to do something to 
+> later find out I can't concentrate on the task no matter how hard I try.
+>
+> I regret it wasn't decided that the people who wanted unlimited edit time 
+> should make the MOD, after which the unlimited edit time would be 
+> implemented. They were going to get what they wanted (the unlimited edit 
+> time), wouldn't that have "given them wings" to do that MOD?
+
+I think unlimited edit time should be enabled, but there is no need for
+a MOD. Creating a MOD to keep history of post edits is not really trivial,
+and could be difficult to maintain in the future. If we really want this
+feature, it would probably be better to have it implemented in upstream
+phpbb before we use it.
+
+But the main problem is not edit time, I don't really care about edit
+time myself. The main problem is that there seems to be a majority of
+people who think it should be enabled, that there is no good reason to
+not do it, or at least try it for a few months (as was proposed several
+times by different people), but it is still not done, because someone
+decided it shouldn't be done. It could have been enabled in 2 minutes
+8 months ago and we would have avoided those endless debates.
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011256.html b/zarb-ml/mageia-dev/2012-January/011256.html new file mode 100644 index 000000000..d699c34f4 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011256.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Antoine Pitrou + solipsis at pitrou.net +
+ Wed Jan 11 21:44:39 CET 2012 +

+
+ +
On Wed, 11 Jan 2012 15:13:05 -0500
+Juan Luis Baptiste <juancho at mageia.org>
+wrote:
+> On Wed, Jan 11, 2012 at 3:05 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
+> >
+> > “Just because someone doesn't file a bug against Mageia doesn't mean the
+> > bug doesn't bother anybody, because many users don't report upstream
+> > bugs to the distro's tracker.”
+> >
+> 
+> Simple, we won't fix bugs that aren't reported or noticed by us,
+> that's unrealistic, someone needs to bring the attention to us if they
+> want it to be fixed.
+
+And my point is that these bugs are fixed automatically if you follow
+bugfix releases from upstream...
+
+Apparently you like to create work for yourself, though :)
+
+Regards
+
+Antoine.
+
+
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011257.html b/zarb-ml/mageia-dev/2012-January/011257.html new file mode 100644 index 000000000..8a80ca862 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011257.html @@ -0,0 +1,67 @@ + + + + [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help + + + + + + + + + +

[Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help

+ Maarten Vanraes + alien at rmail.be +
+ Wed Jan 11 21:47:58 CET 2012 +

+
+ +
Op woensdag 11 januari 2012 21:13:50 schreef nicolas vigier:
+[...]
+> But the main problem is not edit time, I don't really care about edit
+> time myself. The main problem is that there seems to be a majority of
+> people who think it should be enabled, that there is no good reason to
+> not do it, or at least try it for a few months (as was proposed several
+> times by different people), but it is still not done, because someone
+> decided it shouldn't be done. It could have been enabled in 2 minutes
+> 8 months ago and we would have avoided those endless debates.
+
+in retrospect, i agree with you on this
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011258.html b/zarb-ml/mageia-dev/2012-January/011258.html new file mode 100644 index 000000000..ee86d87bf --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011258.html @@ -0,0 +1,126 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Christian Lohmaier + lohmaier+mageia at googlemail.com +
+ Wed Jan 11 21:53:48 CET 2012 +

+
+ +
On Wed, Jan 11, 2012 at 6:43 PM, Juan Luis Baptiste <juancho at mageia.org> wrote:
+> On Wed, Jan 11, 2012 at 11:48 AM, Christian Lohmaier
+> <lohmaier+mageia at googlemail.com> wrote:
+> [...]
+> You don't do packaging, right ?
+
+Wrong. I do packaging, although not for any distro.
+
+> it isn't that hard and is how all distro's do it. Look at Fedora or
+> SuSE's packages and you will see a lot of patch files fixing single
+> bugs.
+
+adding patches to the packages and releasing them instead of waiting
+for a new upstream release is different from having the policy to
+stick with whatever release was used when releasing the distro and
+then only apply fixes via patches.
+
+I'm not saying that you must not use patches to fix bugs. There are
+cases where a bug is homegrown/specific to the distro and thus not
+suitable for fixing upstream, there are cases where development cylce
+is too slow/it is not sensible to wait for upstream.
+
+> It's a matter of following upstream bugzilla reports and see
+> which commit fixes the issue in question, create a patch from it and
+> apply it to the package. Most of the time you can get the patches to
+> fix single bugs from other distros packages.
+
+It is not a question whether it is possible. It is a question whether
+it makes sense in the first place.
+And no doubt it creates a lot more work for package maintainers.
+Both for initially hunting for the commit that fixes the bug, and
+later when patches conflict, and later when a package is updated to a
+new release.
+
+> Because as I said earlier, we backport the "commit" that fixes that
+> single issue,
+
+Every change, also those that introduce a regression is a "commit".
+So implicitly you're saying that you will only fix the "easy" bugs,
+but anything that involves more than touching 10lines of code will not
+be chosen, since it might introduce regressions.
+
+ciao
+Christian
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011259.html b/zarb-ml/mageia-dev/2012-January/011259.html new file mode 100644 index 000000000..c3ead89fc --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011259.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Christian Lohmaier + lohmaier+mageia at googlemail.com +
+ Wed Jan 11 21:54:04 CET 2012 +

+
+ +
On Wed, Jan 11, 2012 at 8:56 PM, zezinho <lists.jjorge at free.fr> wrote:
+> Le mercredi 11 janvier 2012 19:22:23, Antoine Pitrou a écrit :
+>> Just because someone doesn't file a bug against Mageia doesn't mean the
+>> bug doesn't bother anybody, because many users don't report upstream
+>> bugs to the distro's tracker.
+>> (also, other users don't bother reporting bugs at all :-))
+>
+> That's it. This is why we provide the whole bugfix release from upstream as
+> update when it is a PURE BUGFIX release (no new features).
+
+This would be sane, but this is not what is written in the update
+policy wiki page.
+
+ciao
+Christian
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011260.html b/zarb-ml/mageia-dev/2012-January/011260.html new file mode 100644 index 000000000..2dad045aa --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011260.html @@ -0,0 +1,234 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Christian Lohmaier + lohmaier+mageia at googlemail.com +
+ Wed Jan 11 21:54:24 CET 2012 +

+
+ +
On Wed, Jan 11, 2012 at 8:32 PM, Michael Scherer <misc at zarb.org> wrote:
+> Le mercredi 11 janvier 2012 à 17:48 +0100, Christian Lohmaier a écrit :
+>> On Wed, Jan 11, 2012 at 4:51 PM, Guillaume Rousse
+>> <guillomovitch at gmail.com> wrote:
+>> > Le 11/01/2012 16:09, Antoine Pitrou a écrit :
+>> >
+>> >> As a Mageia user I would expect Mageia to package significant *bugfix
+>> >> releases* and ship them in the updates for the stable distro.
+>> >
+>> > You'd rather read the current update policy, rather than expect blind
+>> > assertions:
+>> > https://wiki.mageia.org/en/Updates_policy
+>>
+>> Whoa - this is a rather stupid policy. (my opinion, yours obviously differs).
+>> "For the most part, an update should consist of a <bold>patched build
+>> of the same version</bold> of the package released with the
+>> distribution,"
+>
+> I am pretty sure that you can express yourself without starting by
+> insulting people.
+
+Well, if you feel insulted when I state my personal opinion about the
+policy, then I cannot help it.
+I also find a different word for it - In my opinion it is a stupid
+policy. It might not reflect what was discussed on the mailinglist,
+but that is not my fault either - I can only judge what is written on
+that wiki-page, and once again: that policy doesn't make any sense to
+me.
+Feeling insulted means that you apparently were deeply involved in
+formulating the policy, too bad, but cannot be helped. Sorry if your
+feelings are hurt.
+
+>> Welcome to distro-isolation, putting burden on maintainers, giving
+>> them all the reason to deny a reasonable request for a bugfix release
+>> because it just is too much work to hunt for a specific commit that
+>> fixed bug x.
+>
+> If that's too much work for a maintainer and if that's important for
+> you, you can :
+> - do your own package, supported by yourself for yourself
+
+I do for the packages I care of.
+
+> or :
+> - provide the patch
+
+No, that's pointless. I'd rather supply the patch upstream, so it will
+be integrated in the upstream package.
+
+> If that's too much work for you too, then that's likely too much work
+> for others too.
+
+You're mixing stuff around: We/I am talking about the case when there
+*is* an bugfix release available from upstream, but the policy
+dictates to extract individual patches for a subset of the fixes only-
+and that subset being bugs filed in mageia's bugzilla. This doesn't
+make sense.
+If the maintainer could use the fixed upstream release, then all that
+is needed is to bumb the version-tag in the spec and rebuild. You
+don't question that this is easier than hunting down a patch and
+adding that to the package, do you?
+Any cases where just bumping the version and rebuilding won't work are
+cases that don't fall in the bugfix-only category.
+
+>> > [...]
+>> > A bug may vary from a typo in a man page to a critical security update,
+>>
+>> And a typo-fix is not worthwhile to have?
+>
+> When we take in account the fact it would still need proper QA, there is
+> likely stuff that are more important than a typo. And a typo is just a
+> extreme case, and a simplificaition. If we start to have a complex
+> update policy, we are just losing time for almost nothing.
+
+No doubt about that - the above statement was more meant in the terms
+of only applying selective fixes by patch, as opposed to taking the
+release that has those bugs fixed+additional easy stuff.
+So why only fix "bug that is reported in mageia's bugzilla", but not
+"the typo that was fixed upstream".
+
+>> Sure, you cannot be save of regressions, but what makes you think you
+>> are smarter than upstream? What makes you so sure that not the one
+>> commit you add as a patch to your package is the one that causes the
+>> regressions?
+>
+> For 1, we usually do not do distro patch. I personnaly think this should
+> be avoided as much as possible, and that we should push as much patch
+> upstream. We have a rather huge backlog to clean.
+>
+> For 2, we also usually take patch from upstream. Some of us are also
+> good enough to understand patchs, and to see what they mean, if they fix
+> something, etc. Of course, there is some software that are rather
+> specialized or obscure, but that's far from being the majority.
+
+So then again: what makes selectively fixing bugs better in terms of
+regression prevention than applying a bugfix release from upstream?
+You an Juan Luis basically say: Less changes, less chance for
+breakage. This is a "Milchmädchenrechnung"  (naive assessment of the
+situation). Fixed done by upstream are applied by people familiar with
+the code in question, usually way  more familiar than the package
+maintainer. Yes the regressions do happen. Even if a fix looks simple,
+it can introduce a regression.
+And by only selectively applying patches it means that: You might have
+a "lesser chance" of regressions, but instead of the regressions you
+still have the other "regular bugs" that were fixed.
+
+>> Regressions have the nice habit of being triggered by changes in
+>> apparently unrelated code...
+>
+> And that's why we should reduce the number of changes.
+
+That's why reducing the number of changes won't help.
+
+> Maybe if you started to be less insulting, and instead started to look
+> at the discussion on the ml in the past on the list,
+
+I might have had if the wiki policy did point to it.
+
+> when the policy was
+> discussed ( and access to the old wiki too ), you would likely find the
+> reasons saner.
+
+Even with your explanations (thanks for taking the time), I still
+disagree and still don't find them any more sane than before.
+
+The only good thing that you made clear is that you discourage
+distro-only patches, but instead favor fixed that are directly from
+upstream.
+
+ciao
+Christian
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011261.html b/zarb-ml/mageia-dev/2012-January/011261.html new file mode 100644 index 000000000..7941373b6 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011261.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Juan Luis Baptiste + juancho at mageia.org +
+ Wed Jan 11 21:56:19 CET 2012 +

+
+ +
On Wed, Jan 11, 2012 at 3:44 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
+> And my point is that these bugs are fixed automatically if you follow
+> bugfix releases from upstream...
+>
+> Apparently you like to create work for yourself, though :)
+>
+
+No, it seems that you like to read what you like to read, On this
+thread has been clear that if there's a bugfix *only* release then we
+will update to that version, *but* when it isn't then we *can't*
+update to it, and we'll have to cherry pick fixes as I have described,
+according to the reported bugs. That's how we and any distro does it.
+
+
+-- 
+Juancho
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011262.html b/zarb-ml/mageia-dev/2012-January/011262.html new file mode 100644 index 000000000..51f28b935 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011262.html @@ -0,0 +1,79 @@ + + + + [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help + + + + + + + + + +

[Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Wed Jan 11 21:57:38 CET 2012 +

+
+ +
2012/1/11 Maarten Vanraes <alien at rmail.be>:
+> Op woensdag 11 januari 2012 21:13:50 schreef nicolas vigier:
+> [...]
+>> But the main problem is not edit time, I don't really care about edit
+>> time myself. The main problem is that there seems to be a majority of
+>> people who think it should be enabled, that there is no good reason to
+>> not do it, or at least try it for a few months (as was proposed several
+>> times by different people), but it is still not done, because someone
+>> decided it shouldn't be done. It could have been enabled in 2 minutes
+>> 8 months ago and we would have avoided those endless debates.
+>
+> in retrospect, i agree with you on this
+
+That's why I wrote what I wrote. :)
+A great majority wants no limitation of time-to-edit so it should be
+set instead of telling that majority something like "If you want it,
+develop that MOD, then you can have what you want." - at least
+everything I know about democratic decisions tells me that.
+
+I think I have made my point of view clear, 'nuff said.
+
+-- 
+wobo
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011263.html b/zarb-ml/mageia-dev/2012-January/011263.html new file mode 100644 index 000000000..404f7e573 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011263.html @@ -0,0 +1,135 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Juan Luis Baptiste + juancho at mageia.org +
+ Wed Jan 11 22:09:56 CET 2012 +

+
+ +
On Wed, Jan 11, 2012 at 3:53 PM, Christian Lohmaier
+<lohmaier+mageia at googlemail.com> wrote:
+> adding patches to the packages and releasing them instead of waiting
+> for a new upstream release is different from having the policy to
+> stick with whatever release was used when releasing the distro and
+> then only apply fixes via patches.
+>
+
+Some times you can't wait for an upstream release, think for example
+of a security update. Also not all projects do bugfix only releases,
+but include new features as well so per our policy, we can't update to
+that version and that's when we have to cherry pick updates to apply
+to package in the stable version of mga. The problem seems to be that
+that isn't clear on the policy.
+
+> I'm not saying that you must not use patches to fix bugs. There are
+> cases where a bug is homegrown/specific to the distro and thus not
+> suitable for fixing upstream, there are cases where development cylce
+> is too slow/it is not sensible to wait for upstream.
+>
+
+Exactly, plus the other case I just said.
+
+> It is not a question whether it is possible. It is a question whether
+> it makes sense in the first place.
+> And no doubt it creates a lot more work for package maintainers.
+> Both for initially hunting for the commit that fixes the bug, and
+> later when patches conflict, and later when a package is updated to a
+> new release.
+
+As I said, no one is talking about picking up a fix if there's a bug
+fix only release, it's for when it isn't and we need to reduce the
+chance of regressions by taking the modifications that *exactly* fix
+that bug.
+
+>
+>> Because as I said earlier, we backport the "commit" that fixes that
+>> single issue,
+>
+> Every change, also those that introduce a regression is a "commit".
+> So implicitly you're saying that you will only fix the "easy" bugs,
+> but anything that involves more than touching 10lines of code will not
+> be chosen, since it might introduce regressions.
+>
+
+No, I'm saying that we will look for the commit that fixes the issue
+in question and not anything else, it doesn't matter if the fix is
+one, 10, 50 lines and/or touches 1, 2 or 10 files.
+
+And again, if there's a bugfix *only* release available when we are
+working on a bug, or we know that there will be one soon, then we can
+update to that version. In the other cases we have to go the long
+route and patch the packges with individual fixes.
+
+-- 
+Juancho
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011264.html b/zarb-ml/mageia-dev/2012-January/011264.html new file mode 100644 index 000000000..f83a99bba --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011264.html @@ -0,0 +1,66 @@ + + + + [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help + + + + + + + + + +

[Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help

+ Romain d'Alverny + rdalverny at gmail.com +
+ Wed Jan 11 22:23:29 CET 2012 +

+
+ +
On Wed, Jan 11, 2012 at 21:13, nicolas vigier <boklm at mars-attacks.org> wrote:
+> The main problem is that there seems to be a majority of
+> people who think it should be enabled, that there is no good reason to
+> not do it, or at least try it for a few months (as was proposed several
+> times by different people), but it is still not done, because someone
+> decided it shouldn't be done. It could have been enabled in 2 minutes
+> 8 months ago and we would have avoided those endless debates.
+
+So it goes back to a Council discussion/decision, where the above was
+decided. Next Monday meeting.
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011265.html b/zarb-ml/mageia-dev/2012-January/011265.html new file mode 100644 index 000000000..6fcaab113 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011265.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] imported .src.rpm / .spec attribution + + + + + + + + + +

[Mageia-dev] imported .src.rpm / .spec attribution

+ Florent Monnier + monnier.florent at gmail.com +
+ Wed Jan 11 22:58:55 CET 2012 +

+
+ +
Le samedi 07 janvier 2012 14:53:59, vous avez écrit :
+> Le samedi 07 janvier 2012 13:58:05, Luc Menut a écrit :
+> > Le 07/01/2012 13:23, Florent Monnier a écrit :
+> > > Hi,
+> > > 
+> > > In Mandriva I was using this command to make proper attribution of
+> > > imported .spec files:
+> > > 
+> > > $ mdvsys import foo.src.rpm --message 'this spec file is imported from
+> > > Fedora where it was written by X'
+> > > 
+> > > I'm trying to make the equivalent with this command:
+> > > 
+> > > $ mgarepo putsrpm -m "this spec file is imported from Mandriva where it
+> > > was written by X" package.src.rpm
+> > > error: no such option: -m
+> > > 
+> > > $ mgarepo putsrpm --message "this spec file is imported from Mandriva
+> > > where it was written by X" package.src.rpm
+> > > error: no such option: --message
+> > > 
+> > > $ mgarepo putsrpm --help | grep -- -m
+> > > 
+> > >      -m LOG  Log message used when commiting changes
+> > > 
+> > > What is the right command line to achieve this?
+> > 
+> > Can you try mgarepo putsrpm -l LOG ... ?
+> 
+> Yes it does work, thanks
+
+
+Also I would like to know how to get the name of a mandriva packager from its 
+mandriva nickname? (in order to make the proper attribution of the imported 
+.spec file.)
+
+I have also noticed that several Mageia packagers don't do any proper 
+attribution to the original authors of the spec files when importing. Is it 
+considered optional ? because when I was a Mandriva packager, when I was 
+importing Fedora spec files and debian patches I have been asked by them to 
+make this proper attribution when importing. Why is it considered optional 
+when it comes from Mandriva ?
+
+-- 
+Cheers
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011266.html b/zarb-ml/mageia-dev/2012-January/011266.html new file mode 100644 index 000000000..094b35b4a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011266.html @@ -0,0 +1,131 @@ + + + + [Mageia-dev] [RFC] Moving various packages/codecs to tainted + + + + + + + + + +

[Mageia-dev] [RFC] Moving various packages/codecs to tainted

+ Anssi Hannula + anssi at mageia.org +
+ Thu Jan 12 02:32:41 CET 2012 +

+
+ +
On 11.01.2012 16:01, Pascal Terjan wrote:
+> On Wed, Jan 11, 2012 at 12:56, Anssi Hannula <anssi at mageia.org> wrote:
+>> On 10.01.2012 15:07, Pascal Terjan wrote:
+>>> On Tue, Jan 10, 2012 at 03:20, Anssi Hannula <anssi at mageia.org> wrote:
+>>>> The problem is that that "balance" was achieved by sticking packages in
+>>>> PLF/main/contrib semi-randomly. For example, H.264 decoders and MPEG-4
+>>>> video encoders are in main/core, while e.g. AAC audio decoders are in
+>>>> PLF/tainted. If one'd put them into an order, IMO H.264 and MPEG-4 would
+>>>> be much more prominent and tainted candidates instead of AAC decoding...
+>>>> Also, in e.g. MPEG-4 case we have encoders both in core and in tainted,
+>>>> e.g. we have ffmpeg in core, but xvid in tainted.
+>>>
+>>> I agree we need rules, but "being covered with patents" does not make
+>>> sense, as the patent owner may agree with using it in free software.
+>>> I think something like "No actively enforced patent" in core would be good.
+>>
+>> Possibly, but how do you define that, exactly?
+>>
+>> Does a licensing program count as "enforcing" or do you mean something else?
+> 
+> Yes, that's what I meant
+
+So it doesn't change anything regarding my original post, since all the
+codecs I talked about have licensing programs.
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011267.html b/zarb-ml/mageia-dev/2012-January/011267.html new file mode 100644 index 000000000..972e1b027 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011267.html @@ -0,0 +1,120 @@ + + + + [Mageia-dev] [RFC] Moving various packages/codecs to tainted + + + + + + + + + +

[Mageia-dev] [RFC] Moving various packages/codecs to tainted

+ David Walser + luigiwalser at yahoo.com +
+ Thu Jan 12 03:23:20 CET 2012 +

+
+ +
andre999 wrote:
+> We're talking about codecs, essentially the decoders which are used to 
+> read encoded files.
+> If the patent claims are valid/enforceable (and most aren't), it is up 
+> to the patent holder to decide if it is in their interest to enforce the 
+> patent claims.
+> Since they will normally attempt to collect royalties from those using 
+> the encoders to generate encoded content, it is in their interest avoid 
+> enforcing claims against users of decoders, as the more such decoders 
+> are used, the more the demand for the corresponding encoders, and thus 
+> the more royalties they will collect.  So it seems to me entirely 
+> logical to await notification that they indeed intend to collect 
+> royalties for these codec decoders.
+> However I do agree that we should put encoders that seem to be covered 
+> by valid patents in some countries in "tainted".
+
+If we really want a hard and fast rule, I agree that this makes the most sense.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011268.html b/zarb-ml/mageia-dev/2012-January/011268.html new file mode 100644 index 000000000..c3541b841 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011268.html @@ -0,0 +1,117 @@ + + + + [Mageia-dev] [RFC] Moving various packages/codecs to tainted + + + + + + + + + +

[Mageia-dev] [RFC] Moving various packages/codecs to tainted

+ Dan Fandrich + dan at coneharvesters.com +
+ Thu Jan 12 03:53:20 CET 2012 +

+
+ +
On Wed, Jan 11, 2012 at 09:23:20PM -0500, David Walser wrote:
+> andre999 wrote:
+> > However I do agree that we should put encoders that seem to be covered 
+> > by valid patents in some countries in "tainted".
+> 
+> If we really want a hard and fast rule, I agree that this makes the most sense.
+
+If you look hard enough, just about any significant software is probably
+violating a software patent in some country in the world (see
+http://www.nosoftwarepatents.com/en/m/dangers/linux.html).  Any criteria
+used to determine "tainted" or not has to be more concrete than "seems" to
+be covered by valid patents.  Under that criteria, the Linux kernel would
+have to go into tainted since it violates patents by Microsoft, Bedrock
+Computer Technologies, McDonnell Douglas, etc.
+
+>>> Dan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011269.html b/zarb-ml/mageia-dev/2012-January/011269.html new file mode 100644 index 000000000..a91430fa7 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011269.html @@ -0,0 +1,119 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Buchan Milne + bgmilne at zarb.org +
+ Thu Jan 12 09:45:29 CET 2012 +

+
+ +
On Wednesday, 11 January 2012 20:22:23 Antoine Pitrou wrote:
+> On Wed, 11 Jan 2012 12:43:35 -0500
+> Juan Luis Baptiste <juancho at mageia.org>
+> 
+> wrote:
+> > > Sure, you cannot be save of regressions, but what makes you think you
+> > > are smarter than upstream? What makes you so sure that not the one
+> > > commit you add as a patch to your package is the one that causes the
+> > > regressions?
+> > 
+> > Because as I said earlier, we backport the "commit" that fixes that
+> > single issue, based on the info found on the bugzilla report of the
+> > upstream project.
+> 
+> But how do you choose which patches you want to backport from the
+> stream of bugfixes done by upstream?
+
+Speaking for myself, and using openldap as an example:
+1)I am active on the mailing lists (e.g. openldap-technical)
+2)I am subscribed to the bugs mailing list (openldap-its)
+3)I check commits in git for the OPENLDAP_REL_ENG_2_4 branch
+
+Typically, if I see 'crasher' in the commimt, I'll look at using that patch 
+for an update.
+
+> Should the packager monitor all
+> bug fixing activity? (sure (s)he *can*, but that's a lot of work)
+> 
+> Just because someone doesn't file a bug against Mageia doesn't mean the
+> bug doesn't bother anybody, because many users don't report upstream
+> bugs to the distro's tracker.
+> (also, other users don't bother reporting bugs at all :-))
+
+And this is the reason I would like to see backports, so I can:
+1)Provide bugfix and security updates with no regressions, in updates
+2)Provide latest upstream stable release in backports, so a user can 
+conveniently contribute (e.g. bug reports) upstream.
+
+But, note that pushing unwanted packages to 99% of our users is not a solution 
+either, we don't want to be Fedora, where every month you effectively have a 
+new distribution ...
+
+Regards,
+Buchan
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011270.html b/zarb-ml/mageia-dev/2012-January/011270.html new file mode 100644 index 000000000..83d3af921 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011270.html @@ -0,0 +1,79 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Buchan Milne + bgmilne at zarb.org +
+ Thu Jan 12 09:45:58 CET 2012 +

+
+ +
On Wednesday, 11 January 2012 21:56:44 zezinho wrote:
+
+> Backports are here for releases with new features.
+
+Where?
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011271.html b/zarb-ml/mageia-dev/2012-January/011271.html new file mode 100644 index 000000000..6dbb0c819 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011271.html @@ -0,0 +1,112 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Buchan Milne + bgmilne at zarb.org +
+ Thu Jan 12 09:48:40 CET 2012 +

+
+ +
On Wednesday, 11 January 2012 22:10:01 Juan Luis Baptiste wrote:
+> On Wed, Jan 11, 2012 at 2:10 PM, Michael Scherer <misc at zarb.org> wrote:
+> > Le mercredi 11 janvier 2012 à 11:24 -0500, Juan Luis Baptiste a écrit :
+> > 
+> > So trusting and having bugs are totally unrelated. And if you doubt that
+> > bugs appear, just see our bugzilla.
+> > We trust upstream ( most of them ), and yet there is bugs.
+> 
+> No, they're not totally unrelated when we don't have the man power to
+> do through QA on every package, we need to trust on the packager (and
+> upstream of course) that he did his best to test the new version
+> without expecting him to have tested all the new features, Or do you
+> expect that a QA member get a list of all the new features of a
+> backport and start testing them one by one ? that's what I call
+> unrealistic in practice.
+> 
+> >> If you think that all version backports should be tested in the same
+> >> way as updates by QA, then all versions upgrades in cauldron should be
+> >> tested by QA before pushing them to the BS right ?
+> > 
+> > No, they should be tested before being put in the stable release. And
+> > that's exactly what we do by freezing and testing before release.
+> 
+> Of course but again, we can't test *all* the new features of *all* the
+> programs that are going to a new release, we do our best for most of
+> them. Critical components like installer, kernel, drak* tools, etc
+> need more testing and that's where (our very small team) QA should
+> spend their time after a freeze. The rest we have to do our best to
+> test after each version update of a package.
+
+And this is IMHO why we should not necessarily enforce full QA on backports.
+
+It is ridiculous to enforce more testing on a package in backports, than most 
+likely was done for it while in cauldron before a release, especially 
+considering the user has a relatively easy mechanism for reverting to the 
+working package.
+
+If QA can state definitively that every package in a release is fully tested, 
+then I might agree.
+
+But, some of the reason to *have* backports is to allow users on stable 
+releases to test new versions that exist in cauldron.
+
+Regards,
+Buchan
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011272.html b/zarb-ml/mageia-dev/2012-January/011272.html new file mode 100644 index 000000000..384c02f36 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011272.html @@ -0,0 +1,82 @@ + + + + [Mageia-dev] imported .src.rpm / .spec attribution + + + + + + + + + +

[Mageia-dev] imported .src.rpm / .spec attribution

+ Buchan Milne + bgmilne at staff.telkomsa.net +
+ Thu Jan 12 09:51:48 CET 2012 +

+
+ +
On Wednesday, 11 January 2012 23:58:55 Florent Monnier wrote:
+
+> I have also noticed that several Mageia packagers don't do any proper
+> attribution to the original authors of the spec files when importing. Is it
+> considered optional ?
+
+In my case, I am mostly importing my own packages from Mageia, or entirely new 
+packages ...
+
+Maybe you could provide examples.
+
+> because when I was a Mandriva packager, when I was
+> importing Fedora spec files and debian patches I have been asked by them to
+> make this proper attribution when importing. Why is it considered optional
+> when it comes from Mandriva ?
+
+Because many maintainers here maintained packages at Mandriva, and they would 
+effectively attribute the package to themself?
+
+Regards,
+Buchan
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011273.html b/zarb-ml/mageia-dev/2012-January/011273.html new file mode 100644 index 000000000..9374ee1cd --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011273.html @@ -0,0 +1,118 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Buchan Milne + bgmilne at zarb.org +
+ Thu Jan 12 10:05:34 CET 2012 +

+
+ +
On Wednesday, 11 January 2012 22:05:53 Antoine Pitrou wrote:
+> On Wed, 11 Jan 2012 14:41:54 -0500
+> Juan Luis Baptiste <juancho at mageia.org>
+> 
+> wrote:
+> > As I said, when there's a bug report on mga, we start investigating
+> > the problem and go and look at upstream for a bug report there for
+> > *that* particular bug.
+> 
+> So let me repeat myself from two messages above (!):
+> 
+> “Just because someone doesn't file a bug against Mageia doesn't mean the
+> bug doesn't bother anybody, because many users don't report upstream
+> bugs to the distro's tracker.”
+
+Why not?
+
+IMHO, a user who experiences a bug has two effective paths they can follow to 
+get a bugfix:
+
+1)File a bug with the distribution, and have the distribution worry about 
+reporting or fixing the bug and providing an update
+
+2)File a bug upstream, when the bug is fixed uptream, file a bug with the 
+distributor, referencing the upstream bug 
+
+An approach that doens't include a bug filed with the distribution means the 
+user doesn't really seem interested in receiving an update from the 
+distribution.
+
+If you just want every new piece of software as soon as possible, you should 
+run Cauldron.
+
+If you believe every bugfix-only-release from every piece of software should 
+be pushed out by distributions, can you clarify:
+1)Why users who are not affected by some obscure bug (e.g. typo in a man page 
+they will never read) should be forced to download unnecessary packages (at 
+high cost in some cases)
+2)How you will identify all upstreams which have a good history of bugfix-only 
+releases, and how you will automate the selection of these packages to go to 
+updates, and how you will streamline this process through QA.
+
+Anyway, you seem to be of the assumption that all the contributors to the 
+distribution you are using have so much more time on their hands than you do, 
+while in actual fact I believe almost all contributors are *very* contstrained 
+on time. If you don't think it is worth your time to help out, why should we 
+waste time (which could be used to ensure the next release has all bugfixes) 
+on new bugfix releases we don't need?
+
+Regards,
+Buchan
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011274.html b/zarb-ml/mageia-dev/2012-January/011274.html new file mode 100644 index 000000000..831d33fab --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011274.html @@ -0,0 +1,148 @@ + + + + [Mageia-dev] Over-zealous rpmlint policy (rejecting rt) + + + + + + + + + +

[Mageia-dev] Over-zealous rpmlint policy (rejecting rt)

+ Buchan Milne + bgmilne at zarb.org +
+ Thu Jan 12 10:12:04 CET 2012 +

+
+ +
I am trying to get rt (3.8.11) into the distro (a package that I am using on a 
+different distro in a production environment), to be followed up with the rt 
+(4.0.4) I have queued (which I am testing in preparation for upgrading our 
+production environment).
+
+I would really like to get this package into the distro, but it is being 
+rejected 
+(http://pkgsubmit.mageia.org/uploads/rejected//cauldron/core/release/20120110140334.buchan.valstar.18287.youri) 
+due to:
+
+Submission errors, aborting:
+- rt-3.8.11-1.mga2.noarch:
+ - dir-or-file-in-usr-local /usr/local/lib/rt/plugins
+ - dir-or-file-in-usr-local /usr/local/lib/rt
+ - dir-or-file-in-usr-local /usr/local/lib/rt/po
+ - dir-or-file-in-usr-local /usr/local/lib/rt/lib
+ - dir-or-file-in-usr-local /usr/local/etc/rt
+ - dir-or-file-in-usr-local /usr/local/lib/rt/html
+
+The documented way for extending RT is by installing files in this location. 
+We can either:
+1)Make it more difficult for users to extend RT with local plugins etc.
+2)Fix rpmlint
+3)Not have RT
+
+misc, you have experience of both rt and rpmlint, can you provide an opinion?
+
+Would it be possible to separate 'dir-or-file-usr-local' into separate rules 
+(one for files, one for dirs)? While I agree we shouldn't ship files in 
+/usr/local, I don't see why we shouldn't ship dirs in /usr/local ...
+
+
+Regards,
+Buchan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011275.html b/zarb-ml/mageia-dev/2012-January/011275.html new file mode 100644 index 000000000..9d2657968 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011275.html @@ -0,0 +1,127 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Antoine Pitrou + solipsis at pitrou.net +
+ Thu Jan 12 10:27:59 CET 2012 +

+
+ +
On Thu, 12 Jan 2012 11:05:34 +0200
+Buchan Milne <bgmilne at zarb.org> wrote:
+> 
+> An approach that doens't include a bug filed with the distribution means the 
+> user doesn't really seem interested in receiving an update from the 
+> distribution.
+
+Do note there are bugs that may go unnoticed by the user even though
+they are affected (for example if they have to do with resource
+consumption or subtle data corruption or other reliability stuff).
+
+> If you just want every new piece of software as soon as possible, you should 
+> run Cauldron.
+
+Obviously, that's not what I want.
+
+> 1)Why users who are not affected by some obscure bug (e.g. typo in a man page 
+> they will never read) should be forced to download unnecessary packages (at 
+> high cost in some cases)
+
+This is already the case. Regularly Mageia suggests me updates that I
+have not asked for since I have not filed a bug for them (and may not
+even be affected).
+
+Besides, your example is silly: I don't know of a software project that
+makes new releases only to fix typos in man pages. Bugfix releases *do*
+contain worthwhile fixes.
+
+> 2)How you will identify all upstreams which have a good history of bugfix-only 
+> releases, and how you will automate the selection of these packages to go to 
+> updates, and how you will streamline this process through QA.
+
+Each packager can decide if their upstream package is well-behaved or
+not. Of course, better be conservative and not package bugfix releases
+if you aren't totally confident. Still, some upstream teams *are*
+well-behaved.
+
+> Anyway, you seem to be of the assumption that all the contributors to the 
+> distribution you are using have so much more time on their hands than you do, 
+> while in actual fact I believe almost all contributors are *very* contstrained 
+> on time.
+
+Relying on upstream for bug fixes may actually free some of the time
+spent doing custom patching and testing. But I agree volunteer time is a
+big blocker in most open source projects.
+
+> If you don't think it is worth your time to help out, why should we 
+> waste time (which could be used to ensure the next release has all bugfixes) 
+> on new bugfix releases we don't need?
+
+Usually bugs are fixed for a reason (i.e. they affect someone
+somewhere). Why you think people don't need bug fixes is beyond me:
+Mageia users aren't, presumably, more stupid / more careless than users
+of other distributions.
+
+Regards
+
+Antoine.
+
+
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011276.html b/zarb-ml/mageia-dev/2012-January/011276.html new file mode 100644 index 000000000..44041dc69 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011276.html @@ -0,0 +1,150 @@ + + + + [Mageia-dev] Over-zealous rpmlint policy (rejecting rt) + + + + + + + + + +

[Mageia-dev] Over-zealous rpmlint policy (rejecting rt)

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Jan 12 10:55:07 CET 2012 +

+
+ +
'Twas brillig, and Buchan Milne at 12/01/12 09:12 did gyre and gimble:
+> I don't see why we shouldn't ship dirs in /usr/local ...
+
+I don't really see the point in shipping the dirs personally.
+
+Any separate extension that is packaged should not go into /usr/local
+anyway, so these folders are purely for users doing this manually.
+
+I would expect that the "make install" stage of any extension
+installation would automatically create those folders anyway, so I
+really don't see the benefit of adding these empty folders into a
+package. The gain in doing so seems minimal to the point of useless.
+
+Of course if extensions do not have installer scripts then the user will
+have to create those folders themselves, but if they are following a
+manual recipe anyway, what's an extra mkdir during that process going to
+cost them? Very little IMO.
+
+Disclaimer: I have no experience of rt itself, so I could be missing
+something contextual here.
+
+Cheers!
+
+Col
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011277.html b/zarb-ml/mageia-dev/2012-January/011277.html new file mode 100644 index 000000000..4767ce088 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011277.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Thu Jan 12 11:03:22 CET 2012 +

+
+ +
Le 12/01/2012 10:27, Antoine Pitrou a écrit :
+> Each packager can decide if their upstream package is well-behaved or
+> not. Of course, better be conservative and not package bugfix releases
+> if you aren't totally confident. Still, some upstream teams *are*
+> well-behaved.
+Some means actually a very few minority among our thousands packages. 
+And even when upstream new release is perfectly safe, we're dealing with 
+binary updates here, meaning we also have to ensure the build 
+environment is perfectly similar (same compiler and build chain version, 
+for instance). Even today, when we try to always rebuild everything just 
+before release, we can't ensure it perfectly. This means there is no 0% 
+risk situation. Meaning we can never be perfectly confident.
+
+Also, there is a responsability issue. Would you assume providing an 
+update disclaiming any kind of liability such as "here is a perfectly 
+safe update from us, but if it ever breaks anything, blame someone else" ?
+
+All of this involves the need of a balance between involved work, 
+estimated risks, and expected benefits. The first factor being mostly 
+related to available workforce, you're welcome to join the team to 
+modify this balance.
+
+-- 
+BOFH excuse #392:
+
+It's union rules. There's nothing we can do about it. Sorry.
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011278.html b/zarb-ml/mageia-dev/2012-January/011278.html new file mode 100644 index 000000000..6f3ad14b9 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011278.html @@ -0,0 +1,126 @@ + + + + [Mageia-dev] packaging help required + + + + + + + + + +

[Mageia-dev] packaging help required

+ Andrew Myers + am2605 at gmail.com +
+ Thu Jan 12 12:12:11 CET 2012 +

+
+ +
Yes, this sounds like something I may be able to help with.
+
+I'm currently in the list of ppl looking for mentors, but this sounds like
+I task I may have the skills to assist with..,
+
+Andrew
+
+On Monday, January 9, 2012, Guillaume Rousse <guillomovitch at gmail.com>
+wrote:
+> Hello list.
+>
+> I've had a look at jenkins, which is an interesting continuous
+integration build bot. But it's yet another piece^H^H^Henterprise-grade
+java application, and the currently available packages
+> (http://pkg.jenkins-ci.org/redhat/) exhibit all classical problems:
+> - no building from sources
+> - private copies of libraries
+> - repackaging of another packaging system (war)
+> - horrible suze-flavour init script
+>
+> I can eventually fix the last point, but I'm unable to adress the others.
+Is there anyone else interested in sharing the work ?
+>
+> --
+> BOFH excuse #179:
+>
+> multicasts on broken packets
+>
+
+-- 
+Sent from Gmail Mobile
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20120112/e83bc6f6/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011279.html b/zarb-ml/mageia-dev/2012-January/011279.html new file mode 100644 index 000000000..201756563 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011279.html @@ -0,0 +1,162 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Buchan Milne + bgmilne at zarb.org +
+ Thu Jan 12 12:19:02 CET 2012 +

+
+ +
On Thursday, 12 January 2012 11:27:59 Antoine Pitrou wrote:
+> On Thu, 12 Jan 2012 11:05:34 +0200
+> 
+> Buchan Milne <bgmilne at zarb.org> wrote:
+> > An approach that doens't include a bug filed with the distribution means
+> > the user doesn't really seem interested in receiving an update from the
+> > distribution.
+> 
+> Do note there are bugs that may go unnoticed by the user even though
+> they are affected (for example if they have to do with resource
+> consumption or subtle data corruption or other reliability stuff).
+
+Right, and in most cases, upstreams should make enough noise about issues like 
+that so maintainers know to push an update. Upstreams that don't are 
+irresponsible, or have their heads in the ground.
+
+> > If you just want every new piece of software as soon as possible, you
+> > should run Cauldron.
+> 
+> Obviously, that's not what I want.
+> 
+> > 1)Why users who are not affected by some obscure bug (e.g. typo in a man
+> > page they will never read) should be forced to download unnecessary
+> > packages (at high cost in some cases)
+> 
+> This is already the case. Regularly Mageia suggests me updates that I
+> have not asked for since I have not filed a bug for them (and may not
+> even be affected).
+
+'users who are unaffected' and 'I didn't ask for an update' are vastly 
+different things. But, it seems you also don't want to get an unnecessarily 
+huge volume of updates ...
+
+> Besides, your example is silly: I don't know of a software project that
+> makes new releases only to fix typos in man pages. Bugfix releases *do*
+> contain worthwhile fixes.
+
+Sure, but on average, probably 75% or more of the software in a release will 
+have some upstream release that has at least one bugfix in it per year, does 
+that mean that we should ship updates to 75% of the packages for each 
+supported distro every year?
+
+> > 2)How you will identify all upstreams which have a good history of
+> > bugfix-only releases, and how you will automate the selection of these
+> > packages to go to updates, and how you will streamline this process
+> > through QA.
+> 
+> Each packager can decide if their upstream package is well-behaved or
+> not. Of course, better be conservative and not package bugfix releases
+> if you aren't totally confident. Still, some upstream teams *are*
+> well-behaved.
+
+Right, and this is (mostly) done, although IMHO the updates policy needs to be 
+updated to make this more explicit.
+
+> > Anyway, you seem to be of the assumption that all the contributors to the
+> > distribution you are using have so much more time on their hands than you
+> > do, while in actual fact I believe almost all contributors are *very*
+> > contstrained on time.
+> 
+> Relying on upstream for bug fixes may actually free some of the time
+> spent doing custom patching and testing.
+
+You assume:
+1)Upstream and packager have no relationship
+2)Bugfixes are done in isolation
+
+> But I agree volunteer time is a
+> big blocker in most open source projects.
+> 
+> > If you don't think it is worth your time to help out, why should we
+> > waste time (which could be used to ensure the next release has all
+> > bugfixes) on new bugfix releases we don't need?
+> 
+> Usually bugs are fixed for a reason (i.e. they affect someone
+> somewhere). Why you think people don't need bug fixes is beyond me:
+
+That wasn't the argument. The argument is that there is a cost to every 
+update, and the question that has to be answered is whether the minimal 
+improvement in some package is worth the time, effort, resource, bandwidth 
+involved, or whether the user is better served by having a completely up-to-
+date minimal-bug-affected-release 2 months later, than having 1000 updates 
+shipped every month and a new low quality release in 2 months, which forces 
+more updates down their expensive internet connection, leaving them with a 
+high cost, low quality experience.
+
+> Mageia users aren't, presumably, more stupid / more careless than users
+> of other distributions.
+
+No, but the point of Mageia is to provide a usable distribution, not one where 
+you get breakage every 2nd week due to supposed 'bugfix' releases of new 
+software.
+
+Regards,
+Buchan
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011280.html b/zarb-ml/mageia-dev/2012-January/011280.html new file mode 100644 index 000000000..feffd181a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011280.html @@ -0,0 +1,158 @@ + + + + [Mageia-dev] Over-zealous rpmlint policy (rejecting rt) + + + + + + + + + +

[Mageia-dev] Over-zealous rpmlint policy (rejecting rt)

+ Buchan Milne + bgmilne at zarb.org +
+ Thu Jan 12 12:39:43 CET 2012 +

+
+ +
On Thursday, 12 January 2012 11:55:07 Colin Guthrie wrote:
+> 'Twas brillig, and Buchan Milne at 12/01/12 09:12 did gyre and gimble:
+> > I don't see why we shouldn't ship dirs in /usr/local ...
+> 
+> I don't really see the point in shipping the dirs personally.
+> 
+> Any separate extension that is packaged should not go into /usr/local
+> anyway,
+
+No one ever said they would, you snipped the part of my mail saying that 
+'locally installed' customisations, IOW, ones not managed by the package 
+manager etc., go there.
+
+> so these folders are purely for users doing this manually.
+
+Yes. And that's why we provide /usr/local/share/applications?
+
+/me wonders if 'filesystem' would make it through the BS.
+
+> I would expect that the "make install" stage of any extension
+> installation would automatically create those folders anyway, so I
+> really don't see the benefit of adding these empty folders into a
+> package.
+
+So, why would 'make isntall' of rt, which has been configured to itself live 
+in a system location, explicitly create these directories?
+
+> The gain in doing so seems minimal to the point of useless.
+
+I can remove the dirs in the package, but also, what is the benefit? On a 
+system dedicated to running a request tracking system, should we explicitly 
+make it more difficult to run said system that it would be if installed from 
+source?
+
+> Of course if extensions do not have installer scripts then the user will
+> have to create those folders themselves, but if they are following a
+> manual recipe anyway, what's an extra mkdir during that process going to
+> cost them? Very little IMO.
+> 
+> Disclaimer: I have no experience of rt itself, so I could be missing
+> something contextual here.
+
+Well, I haven't myself used extensions that live here, because I have to be 
+careful not to deliver something one of our vendors is contracted to deliver. 
+I'll test one on my laptop ...
+
+Regards,
+Buchan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011281.html b/zarb-ml/mageia-dev/2012-January/011281.html new file mode 100644 index 000000000..e0aa414e9 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011281.html @@ -0,0 +1,192 @@ + + + + [Mageia-dev] Over-zealous rpmlint policy (rejecting rt) + + + + + + + + + +

[Mageia-dev] Over-zealous rpmlint policy (rejecting rt)

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Jan 12 13:09:24 CET 2012 +

+
+ +
'Twas brillig, and Buchan Milne at 12/01/12 11:39 did gyre and gimble:
+> On Thursday, 12 January 2012 11:55:07 Colin Guthrie wrote:
+>> 'Twas brillig, and Buchan Milne at 12/01/12 09:12 did gyre and gimble:
+>>> I don't see why we shouldn't ship dirs in /usr/local ...
+>>
+>> I don't really see the point in shipping the dirs personally.
+>>
+>> Any separate extension that is packaged should not go into /usr/local
+>> anyway,
+> 
+> No one ever said they would, you snipped the part of my mail saying that 
+> 'locally installed' customisations, IOW, ones not managed by the package 
+> manager etc., go there.
+
+Yeah I know I was just trying to be explicit and clear with my reply and
+reasoning. I wasn't pointing out something you missed or anything. Sorry
+for the confusion (the opposite of what I had intended!)
+
+>> so these folders are purely for users doing this manually.
+> 
+> Yes. And that's why we provide /usr/local/share/applications?
+
+Hmm, that seems a bit silly to me. Why do we provide that? I'd say we
+should drop it unless someone can argue otherwise (maybe it's part of
+the filesystem layout spec?)
+
+>> I would expect that the "make install" stage of any extension
+>> installation would automatically create those folders anyway, so I
+>> really don't see the benefit of adding these empty folders into a
+>> package.
+> 
+> So, why would 'make isntall' of rt, which has been configured to itself live 
+> in a system location, explicitly create these directories?
+
+Because it's broken? Just because the upstream folks do something like
+that does not mean they are correct. I'd say that if any app's make
+install is writing things outside of their --prefix (with a few
+exceptions for things like udev rules etc. that need to live in /lib -
+but thankfully with the work done by Fedora folks even this exception is
+dying away) or --sysconfdir etc. then it's broken.
+
+>> The gain in doing so seems minimal to the point of useless.
+> 
+> I can remove the dirs in the package, but also, what is the benefit? On a 
+> system dedicated to running a request tracking system, should we explicitly 
+> make it more difficult to run said system that it would be if installed from 
+> source?
+
+I really don't buy the "make it more difficult" argument... that's what
+I was trying to highlight in my previous mail. The "make install" stage
+of any extension should make the dirs for you anyway... If that's the
+case it is precisely the same difficulty as without those dirs. If
+manual copying is required, then, yes, it is a tiny amount more
+complicated, but people will be following instructions anyway and if the
+added "complication" of a mkdir command or two will trip someone up,
+then I don't think that person should have root powers and able to write
+in /usr/local in the first place if this is their level of skill!!!
+
+
+Like I say, this is just my opinion, and I certainly don't feel super
+strongly on the topic. It's just that I wouldn't expect any rpm to own
+anything in /usr/local tree (and that goes for the one you pointed out
+above too!).
+
+Col
+
+
+
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011282.html b/zarb-ml/mageia-dev/2012-January/011282.html new file mode 100644 index 000000000..8213df18e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011282.html @@ -0,0 +1,110 @@ + + + + [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help + + + + + + + + + +

[Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help

+ Marja van Waes + marja11 at xs4all.nl +
+ Thu Jan 12 13:26:22 CET 2012 +

+
+ +
On 11/01/12 21:13, nicolas vigier wrote:
+> On Wed, 11 Jan 2012, Marja van Waes wrote:
+>
+>> I can't talk for that minority, of course. However, I can talk for myself:
+>>
+>> In such circumstances it is very possible that I'd agree to do something to
+>> later find out I can't concentrate on the task no matter how hard I try.
+>>
+>> I regret it wasn't decided that the people who wanted unlimited edit time
+>> should make the MOD, after which the unlimited edit time would be
+>> implemented. They were going to get what they wanted (the unlimited edit
+>> time), wouldn't that have "given them wings" to do that MOD?
+> I think unlimited edit time should be enabled, but there is no need for
+> a MOD. Creating a MOD to keep history of post edits is not really trivial,
+> and could be difficult to maintain in the future. If we really want this
+> feature, it would probably be better to have it implemented in upstream
+> phpbb before we use it.
+>
+> But the main problem is not edit time, I don't really care about edit
+> time myself. The main problem is that there seems to be a majority of
+> people who think it should be enabled, that there is no good reason to
+> not do it, or at least try it for a few months (as was proposed several
+> times by different people), but it is still not done, because someone
+> decided it shouldn't be done. It could have been enabled in 2 minutes
+> 8 months ago and we would have avoided those endless debates.
+>
+This issue is about a seeming majority of people wanting a certain 
+feature. It is not about a buggy forum. It is about an enhancement, that 
+isn't even an enhancement in everybody's eyes.
+
+Maintainers of packages have the freedom to refuse to do an enhancement 
+request https://wiki.mageia.org/en/Bug_policy#Enhancement_requests
+Maintainers can refuse regardless of what reason they have to refuse.
+
+Why don't we give the maât the same right for the unlimited edit time 
+request?
+
+Moreover, in article 18 of the Universal Declaration of Human Rights it 
+says:
+Everyone has the right to freedom of thought, conscience and religion.......
+http://en.wikipedia.org/wiki/Universal_Declaration_of_Human_Rights#Article_18
+
+This article was of course written for all those cases when someone has 
+different thoughts, conscience and/or religion than we have.
+
+It is evident from what maât wrote, that he is convinced the edit time 
+should stay very limited. Why do we ignore the universal declaration of 
+human rights and try to force him to do something that is against his 
+conscience?
+
+Regards,
+Marja
+
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011283.html b/zarb-ml/mageia-dev/2012-January/011283.html new file mode 100644 index 000000000..313c0a588 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011283.html @@ -0,0 +1,132 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ andre999 + andre999mga at laposte.net +
+ Thu Jan 12 13:47:05 CET 2012 +

+
+ +
Buchan Milne a écrit :
+> On Wednesday, 11 January 2012 22:10:01 Juan Luis Baptiste wrote:
+>    
+>> On Wed, Jan 11, 2012 at 2:10 PM, Michael Scherer<misc at zarb.org>  wrote:
+>>      
+>>> Le mercredi 11 janvier 2012 à 11:24 -0500, Juan Luis Baptiste a écrit :
+>>>
+>>> So trusting and having bugs are totally unrelated. And if you doubt that
+>>> bugs appear, just see our bugzilla.
+>>> We trust upstream ( most of them ), and yet there is bugs.
+>>>        
+>> No, they're not totally unrelated when we don't have the man power to
+>> do through QA on every package, we need to trust on the packager (and
+>> upstream of course) that he did his best to test the new version
+>> without expecting him to have tested all the new features, Or do you
+>> expect that a QA member get a list of all the new features of a
+>> backport and start testing them one by one ? that's what I call
+>> unrealistic in practice.
+>>
+>>      
+>>>> If you think that all version backports should be tested in the same
+>>>> way as updates by QA, then all versions upgrades in cauldron should be
+>>>> tested by QA before pushing them to the BS right ?
+>>>>          
+>>> No, they should be tested before being put in the stable release. And
+>>> that's exactly what we do by freezing and testing before release.
+>>>        
+>> Of course but again, we can't test *all* the new features of *all* the
+>> programs that are going to a new release, we do our best for most of
+>> them. Critical components like installer, kernel, drak* tools, etc
+>> need more testing and that's where (our very small team) QA should
+>> spend their time after a freeze. The rest we have to do our best to
+>> test after each version update of a package.
+>>      
+> And this is IMHO why we should not necessarily enforce full QA on backports.
+>
+> It is ridiculous to enforce more testing on a package in backports, than most
+> likely was done for it while in cauldron before a release, especially
+> considering the user has a relatively easy mechanism for reverting to the
+> working package.
+>
+> If QA can state definitively that every package in a release is fully tested,
+> then I might agree.
+>
+> But, some of the reason to *have* backports is to allow users on stable
+> releases to test new versions that exist in cauldron.
+>
+> Regards,
+> Buchan
+>
+>    
++1
+If I remember correctly, our early discussions on backports proposed 
+that most of the responsibility for testing would be by those requesting 
+the backport in question, and the developer and/or maintainer.  So that 
+QA would give priority to regular updates.
+And that backports may have somewhat less testing, although we would try 
+to give the same level of testing as regular updates.
+The requirement to have them first in cauldron was at least partly 
+related to increasing the quality of backports.
+I agree that it is important to enable backports, to help ensure a 
+higher quality than will likely result with too much use of 3rd-party repos.
+
+Regards
+
+-- 
+André
+
+
+ + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011284.html b/zarb-ml/mageia-dev/2012-January/011284.html new file mode 100644 index 000000000..00b6a6d71 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011284.html @@ -0,0 +1,129 @@ + + + + [Mageia-dev] Existing Cauldron VM users willing to test gnome-boxes? + + + + + + + + + +

[Mageia-dev] Existing Cauldron VM users willing to test gnome-boxes?

+ Olav Vitters + olav at vitters.nl +
+ Thu Jan 12 13:53:29 CET 2012 +

+
+ +
Anyone making use of qemu + kvm for VMs on Cauldron?
+
+Could you please install gnome-boxes, start it from the command line and
+tell me if it works when you select some .iso file + create + start a
+VM?
+Please test on x86_64 (as host).
+
+Note: It is not working for me, but I have solved all known problems. At
+the moment I just like to know if perhaps it is my lack of VM knowledge
+and/or a local problem.
+
+Michael Hill has already done lots of testing + discussion with
+upstream, but him+me fail to get a VM. Him due to a bug I think in
+gnome-boxes on i586/i686, me.. no idea why it is failing.
+
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011285.html b/zarb-ml/mageia-dev/2012-January/011285.html new file mode 100644 index 000000000..c242bf28d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011285.html @@ -0,0 +1,68 @@ + + + + [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help + + + + + + + + + +

[Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help

+ nicolas vigier + boklm at mars-attacks.org +
+ Thu Jan 12 14:06:11 CET 2012 +

+
+ +
On Thu, 12 Jan 2012, Marja van Waes wrote:
+
+>
+> It is evident from what maât wrote, that he is convinced the edit time 
+> should stay very limited. Why do we ignore the universal declaration of 
+> human rights and try to force him to do something that is against his 
+> conscience?
+
+Because it's Mageia's forum, not his forum.
+
+And this has nothing to do with human rights ...
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011286.html b/zarb-ml/mageia-dev/2012-January/011286.html new file mode 100644 index 000000000..49eed6681 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011286.html @@ -0,0 +1,111 @@ + + + + [Mageia-dev] packaging help required + + + + + + + + + +

[Mageia-dev] packaging help required

+ D.Morgan + dmorganec at gmail.com +
+ Thu Jan 12 14:14:06 CET 2012 +

+
+ +
On Mon, Jan 9, 2012 at 10:27 AM, Guillaume Rousse
+<guillomovitch at gmail.com> wrote:
+> Hello list.
+>
+> I've had a look at jenkins, which is an interesting continuous integration
+> build bot. But it's yet another piece^H^H^Henterprise-grade java
+> application, and the currently available packages
+> (http://pkg.jenkins-ci.org/redhat/) exhibit all classical problems:
+> - no building from sources
+> - private copies of libraries
+> - repackaging of another packaging system (war)
+> - horrible suze-flavour init script
+>
+> I can eventually fix the last point, but I'm unable to adress the others. Is
+> there anyone else interested in sharing the work ?
+>
+> --
+> BOFH excuse #179:
+>
+> multicasts on broken packets
+
+can you make a src.rpm available somewhere for us to look ? ( we
+should be able to help with gil on the java packaging related issues )
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011287.html b/zarb-ml/mageia-dev/2012-January/011287.html new file mode 100644 index 000000000..4ce97131d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011287.html @@ -0,0 +1,157 @@ + + + + [Mageia-dev] Re : Re : Re : E17 packaging + + + + + + + + + +

[Mageia-dev] Re : Re : Re : E17 packaging

+ Matthew Dawkins + mattydaw at gmail.com +
+ Thu Jan 12 14:41:25 CET 2012 +

+
+ +
On Mon, Oct 31, 2011 at 3:40 PM, Michael Scherer <misc at zarb.org> wrote:
+
+> Le lundi 31 octobre 2011 à 16:56 +0000, Philippe Reynes a écrit :
+> >
+> > So, yes, there isn't any way to manage bug/security issue in a very
+> > easy way when upstream team don't provide stable tarball. So, what is
+> > the mageia policy in this case ? no packaging at all ? "private"
+> > packaging ?
+>
+> So far, there is no policy specific for this issue. Hence the importance
+> of discussing.
+>
+> Personnaly, I think we should really try hard to avoid a 4th
+> firefox-like problem.
+>
+> I also think the current way is not something that will satisfy upstream
+> coders if we ship old versions of their software when they think it is
+> not ready.
+>
+> So as Florian told, maybe packaging a proper script to update e17 could
+> help. I think we can ship the stable bit of e17, for people wanting to
+> use them.
+> Or see
+> https://www.mageia.org/pipermail/mageia-dev/2011-October/009155.html
+> for other type of solution.
+>
+> --
+> Michael Scherer
+>
+>
+
+Has there been any more discussion/progress on E17 at mga? I have finally
+merged all the UnityLinux specs up with Mandriva.
+
+We've always maintained a fuller suite of E17 pkgs and there are
+instructions to boot on how to do svn trunk checkouts and tarballing of the
+sources.
+
+Anyone interested in doing a cross mdv<>mga maintainership of E17?
+
+Regards,
+Matt Dawkins
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20120112/c7b6c764/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011288.html b/zarb-ml/mageia-dev/2012-January/011288.html new file mode 100644 index 000000000..7c0936436 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011288.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Johnny A. Solbu + cooker at solbu.net +
+ Thu Jan 12 15:45:39 CET 2012 +

+
+ +
On Thursday 12 January 2012 10:05, Buchan Milne wrote:
+> many users don't report upstream
+> bugs to the distro's tracker.”
+> 
+> Why not?
+
+Why should they? As far as the average Joe is concerned they should only have to file a bug one place.
+This is how many of them think. And I agree with them.
+
+> 1)File a bug with the distribution, and have the distribution worry about 
+> reporting or fixing the bug and providing an update
+> 
+> 2)File a bug upstream, when the bug is fixed uptream, file a bug with the 
+> distributor, referencing the upstream bug 
+
+My experience is that if they file a bug report in the first place, they Either contact the upstream developer or the distribution's bugzilla team. They never do both, as they believe that doing both is a waste of time, since the fixed version eventually find it's way to the distribution anyway.
+
+> An approach that doens't include a bug filed with the distribution means the 
+> user doesn't really seem interested in receiving an update from the 
+> distribution.
+
+Incorrect assumption.
+As someone who is the support service for some users I have some experience with this. They assume that any serious bug will be fixed in one of the next releaces, because that's how it works with Microsoft. And they haven't heard of anyone filing any bug at Microsoft. The bugs just get fixed without them ever repporting anything, and they assume that this is how things are supposed to work. Sometimes they even think that what we consider as bugs, they believe it is how things are supposed to work.
+
+If they're not happy with how the system works, they often conclude that Linux Sucks Ass, and move back to Windows or OS X.
+
+-- 
+Johnny A. Solbu
+PGP key ID: 0xFA687324
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 189 bytes
+Desc: This is a digitally signed message part.
+URL: </pipermail/mageia-dev/attachments/20120112/78a63cba/attachment.asc>
+
+ + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011289.html b/zarb-ml/mageia-dev/2012-January/011289.html new file mode 100644 index 000000000..6e0219e71 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011289.html @@ -0,0 +1,82 @@ + + + + [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help + + + + + + + + + +

[Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Thu Jan 12 15:48:32 CET 2012 +

+
+ +
2012/1/12 Marja van Waes <marja11 at xs4all.nl>:
+>
+> Moreover, in article 18 of the Universal Declaration of Human Rights it
+> says:
+> Everyone has the right to freedom of thought, conscience and religion.......
+> http://en.wikipedia.org/wiki/Universal_Declaration_of_Human_Rights#Article_18
+
+Yes, so why do you deny these right sto the majority of the forum people?
+
+> This article was of course written for all those cases when someone has
+> different thoughts, conscience and/or religion than we have.
+
+< It is evident from what maāt wrote, that he is convinced the edit time
+> should stay very limited. Why do we ignore the universal declaration of
+> human rights and try to force him to do something that is against his
+> conscience?
+
+I guess you agree that those principles where written with the spirit
+of democracy behind it all - so you agree also that those declarations
+do not say that one has the right to force his opinion on all others.
+
+As I wrote in the bug report: we will hopefully see a decision about
+this in next council meeting to close this discussion for good.
+
+-- 
+wobo
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011290.html b/zarb-ml/mageia-dev/2012-January/011290.html new file mode 100644 index 000000000..8d721ecc0 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011290.html @@ -0,0 +1,126 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Buchan Milne + bgmilne at zarb.org +
+ Thu Jan 12 16:29:43 CET 2012 +

+
+ +
On Thursday, 12 January 2012 16:45:39 Johnny A. Solbu wrote:
+> On Thursday 12 January 2012 10:05, Buchan Milne wrote:
+> > many users don't report upstream
+> > bugs to the distro's tracker.”
+> > 
+> > Why not?
+> 
+> Why should they? As far as the average Joe is concerned they should only
+> have to file a bug one place. This is how many of them think. And I agree
+> with them.
+> 
+> > 1)File a bug with the distribution, and have the distribution worry about
+> > reporting or fixing the bug and providing an update
+> > 
+> > 2)File a bug upstream, when the bug is fixed uptream, file a bug with the
+> > distributor, referencing the upstream bug
+> 
+> My experience is that if they file a bug report in the first place, they
+> Either contact the upstream developer or the distribution's bugzilla team.
+
+I covered this in (1).
+
+> They never do both, as they believe that doing both is a waste of time,
+> since the fixed version eventually find it's way to the distribution
+> anyway.
+
+Sure, it will, on the next release of the distribution, assuming the new 
+upstream release was before version freeze.
+
+> > An approach that doens't include a bug filed with the distribution means
+> > the user doesn't really seem interested in receiving an update from the
+> > distribution.
+> 
+> Incorrect assumption.
+> As someone who is the support service for some users I have some experience
+> with this. They assume that any serious bug will be fixed in one of the
+> next releaces,
+
+But this *is* the case. What we are talking about *here*, is that the bugfix 
+update be shipped to old releases.
+
+> because that's how it works with Microsoft.
+
+Yes, non-critical release will be shipped in next SP, a year or so later.
+
+> And they
+> haven't heard of anyone filing any bug at Microsoft.
+
+Just because they haven't, doesn't mean it doesn't happen.
+
+> The bugs just get
+> fixed without them ever repporting anything, and they assume that this is
+> how things are supposed to work. Sometimes they even think that what we
+> consider as bugs, they believe it is how things are supposed to work.
+> 
+> If they're not happy with how the system works, they often conclude that
+> Linux Sucks Ass, and move back to Windows or OS X.
+
+But, your comparison is invalid. Users must pay for the privilege of upgrading 
+to get non-critical bugfixes the latter, and wait quite some time for the 
+former.
+
+Regards,
+Buchan
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011291.html b/zarb-ml/mageia-dev/2012-January/011291.html new file mode 100644 index 000000000..8136278a2 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011291.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] Seamonkey package + + + + + + + + + +

[Mageia-dev] Seamonkey package

+ Florian Hubold + doktor5000 at arcor.de +
+ Thu Jan 12 16:55:12 CET 2012 +

+
+ +
Am 07.01.2012 18:36, schrieb Florian Hubold:
+> Am 16.04.2011 16:05, schrieb Christiaan Welvaart:
+>> On Fri, 11 Mar 2011, Tux99 wrote:
+>>
+>>> I just downloaded the latest Seamonkey 2.0.12 SRPM from Mandriva cooker and
+>>> rebuilt it on my Mageia VM and it built flawlessly, I only had to remove
+>>> all the obsolete "%if %mdkversion" sections, but all dependecies are
+>>> available in Mageia.
+>>> So technically importing Seamonkey into Mageia seems straightforward, the
+>>> only issue is licensing (as for Firefox).
+>>>
+>>> Christiaan I'm a newbie packager here at Mageia so personally I'd much
+>>> prefer if you maintain this package for Mageia, it looks far too complex
+>>> for me. :)
+>> I uploaded "iceape 2.0.12" a few days ago, changing the name and icons/logo
+>> took me almost a month. Unfortunately there are still some bugs in this
+>> area:  the release notes menu item for example currently still points to
+>> seamonkey. It should probably point to a mageia wiki page.
+>>
+>> Since I don't like the icons that is used for debian's iceape, I created a
+>> new icon based on the logo. It looks like it can still be improved, however,
+>> and the throbber is currently static. So it would be great if someone could
+>> re-do the icon (without creating a completely new design), and animate it for
+>> the throbber (he SVG files are in iceape-branding.tar in the source rpm and
+>> svn)...
+>>
+>>
+>>     Christiaan
+>>
+> As iceape for mga1 hasn't seen any update in the last 6 months,
+> and there are multiple serious security issues that need fixing,
+> how do we handle this?
+>
+> And i've found no real reason for this rebranding in the first place,
+> and this seems also be the case for Fedora, and they have a strong
+> legal department.
+> http://pkgs.fedoraproject.org/gitweb/?p=seamonkey.git
+>
+> >From what i read on bugreports between debian packagers and
+> mozilla guys about that branding situation, the only thing that would
+> need to be done to seamonkey (actually the same would need to
+> be done for all our mozilla packages, unless we have permission
+> to use the branding, which would imply that all our modifications
+> on mozilla packages would need to be reviewed and ack-ed by mozilla
+> to get the branding permission) would be to use --disable-official-branding
+> configure option.
+>
+>
+Ping?
+
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011292.html b/zarb-ml/mageia-dev/2012-January/011292.html new file mode 100644 index 000000000..b1f5ee82a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011292.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help + + + + + + + + + +

[Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help

+ Marja van Waes + marja11 at xs4all.nl +
+ Thu Jan 12 17:06:32 CET 2012 +

+
+ +
On 12/01/12 15:48, Wolfgang Bornath wrote:
+> 2012/1/12 Marja van Waes<marja11 at xs4all.nl>:
+>> Moreover, in article 18 of the Universal Declaration of Human Rights it
+>> says:
+>> Everyone has the right to freedom of thought, conscience and religion.......
+>> http://en.wikipedia.org/wiki/Universal_Declaration_of_Human_Rights#Article_18
+> Yes, so why do you deny these right sto the majority of the forum people?
+>
+I don't :)
+I don't even deny it when our seeming majority would turn out to be a 
+minority.
+
+Please be careful with the words "the majority", we don't have a good 
+tool yet to know what everybody wants.
+
+That would mean: inform everybody in the Mageia community in a factual 
+way about the different points of view and then let them vote 
+anonymously. Too many users don't see the polls, I think it would be 
+better to have them on www.mageia.org, instead of hidden in forum threads.
+
+It would be good to make sure there isn't a different, "silent majority" 
+here.
+
+
+>> This article was of course written for all those cases when someone has
+>> different thoughts, conscience and/or religion than we have.
+> <  It is evident from what maāt wrote, that he is convinced the edit time
+>> should stay very limited. Why do we ignore the universal declaration of
+>> human rights and try to force him to do something that is against his
+>> conscience?
+> I guess you agree that those principles where written with the spirit
+> of democracy behind it all - so you agree also that those declarations
+> do not say that one has the right to force his opinion on all others.
+
+Of course not. Funny that you seem to think maât did that, I didn't see 
+him force anyone to use the forum as it is.
+
+
+
+> As I wrote in the bug report: we will hopefully see a decision about
+> this in next council meeting to close this discussion for good
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011293.html b/zarb-ml/mageia-dev/2012-January/011293.html new file mode 100644 index 000000000..1f2015e15 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011293.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help + + + + + + + + + +

[Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Thu Jan 12 17:47:05 CET 2012 +

+
+ +
2012/1/12 Marja van Waes <marja11 at xs4all.nl>:
+> On 12/01/12 15:48, Wolfgang Bornath wrote:
+>>
+>> 2012/1/12 Marja van Waes<marja11 at xs4all.nl>:
+>>>
+>>> Moreover, in article 18 of the Universal Declaration of Human Rights it
+>>> says:
+>>> Everyone has the right to freedom of thought, conscience and
+>>> religion.......
+>>>
+>>> http://en.wikipedia.org/wiki/Universal_Declaration_of_Human_Rights#Article_18
+>>
+>> Yes, so why do you deny these right sto the majority of the forum people?
+>>
+> I don't :)
+> I don't even deny it when our seeming majority would turn out to be a
+> minority.
+>
+> Please be careful with the words "the majority", we don't have a good tool
+> yet to know what everybody wants.
+
+Hmm, from the people who participated in the initial discussion which
+led to the council compromise I count 2 in favor of the limitation,
+the rest against it. This I call a majority.
+During the 8 months since we have this issue I read lots of complaints
+about the limitation, I did not read any post in favor of it. This is
+what I call a majority.
+
+In an election or a poll (a democratic process) how much weight do
+those have who do not give their vote? In every election there is a
+number of people who do not vote, either because they don't care or
+none of the given options is to their liking. But I haven't seen an
+election or poll where the "silent" number was counted in favor for
+one side or the other. So, if you are talking about the silent
+majority I can ask you rightfully, on which side the silent majority
+would be.
+
+
+>> I guess you agree that those principles where written with the spirit
+>> of democracy behind it all - so you agree also that those declarations
+>> do not say that one has the right to force his opinion on all others.
+>
+>
+> Of course not. Funny that you seem to think maât did that, I didn't see him
+> force anyone to use the forum as it is.
+
+Then you think that his behavior is ok and everybody who doesn't like
+it can leave? That is not funny. It is against all that Mageia stands
+for.
+I think we do not have different opinions, we are living in different worlds.
+
+-- 
+wobo
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011294.html b/zarb-ml/mageia-dev/2012-January/011294.html new file mode 100644 index 000000000..c8817bad6 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011294.html @@ -0,0 +1,106 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Christian Lohmaier + lohmaier+mageia at googlemail.com +
+ Thu Jan 12 19:01:10 CET 2012 +

+
+ +
Hi Juan Luis,
+
+On Wed, Jan 11, 2012 at 10:09 PM, Juan Luis Baptiste <juancho at mageia.org> wrote:
+> [..]
+> As I said, no one is talking about picking up a fix if there's a bug
+> fix only release, it's for when it isn't and we need to reduce the
+> chance of regressions by taking the modifications that *exactly* fix
+> that bug.
+
+I strongly disagree. The policy is stating the exact opposite. And
+also Michael seems to defend the policy as it is written, and not your
+interpretation here.
+
+That again you might have a different understanding of
+bugfix-only-release. I think I stated mine often enough (increase in
+micro version when package follows major.minor.micro versioning scheme
+and no new features are introduced in micro releases).
+
+So please change the wording of the update policy accordingly
+https://wiki.mageia.org/en/Updates_policy reads:
+##########
+For the most part, an update should consist of a patched build of the
+same version of the package released with the distribution, with a few
+exceptions:
+
+* Software versions that are no longer supported upstream with updates
+(firefox and thunderbird seem to fall into this category these days)
+* Software that is version-bound to an online service (games, virus
+scanners?) and will only work with the latest version.
+* We will make exceptions for packages that did not make it into mga1
+and are additions to the distribution, provided they do not impact any
+other packages and can pass full QA.
+
+Updates are not the appropriate place for packages created to satisfy
+certain user's urges for "the latest". These types of builds belong in
+backports.
+##########
+I read it as "no version bumb is allowed (except for the three
+exception-cases listed) - bugs are only fixed using patches", and I
+don't see the interpretational freedom to allow upstream's bugfix
+releases. Updating from 1.3.2 to 1.3.3 would not be in compliance with
+the policy (if not in one of the three exception cases) - this is what
+I have called stupid policy (and still do).
+
+ciao
+Christian
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011295.html b/zarb-ml/mageia-dev/2012-January/011295.html new file mode 100644 index 000000000..eeedf9eb2 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011295.html @@ -0,0 +1,77 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Johnny A. Solbu + cooker at solbu.net +
+ Thu Jan 12 19:15:18 CET 2012 +

+
+ +
On Thursday 12 January 2012 19:01, Christian Lohmaier wrote:
+> Updating from 1.3.2 to 1.3.3 would not be in compliance with 
+> the policy (if not in one of the three exception cases) - this is what
+> I have called stupid policy (and still do).
+
+Hear, hear!
+
+-- 
+Johnny A. Solbu
+PGP key ID: 0xFA687324
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 189 bytes
+Desc: This is a digitally signed message part.
+URL: </pipermail/mageia-dev/attachments/20120112/3beb1034/attachment.asc>
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011296.html b/zarb-ml/mageia-dev/2012-January/011296.html new file mode 100644 index 000000000..911e45a68 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011296.html @@ -0,0 +1,141 @@ + + + + [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help + + + + + + + + + +

[Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help

+ Marja van Waes + marja11 at xs4all.nl +
+ Thu Jan 12 19:21:47 CET 2012 +

+
+ +
On 12/01/12 17:47, Wolfgang Bornath wrote:
+> 2012/1/12 Marja van Waes<marja11 at xs4all.nl>:
+>> On 12/01/12 15:48, Wolfgang Bornath wrote:
+>>> 2012/1/12 Marja van Waes<marja11 at xs4all.nl>:
+>>>> Moreover, in article 18 of the Universal Declaration of Human Rights it
+>>>> says:
+>>>> Everyone has the right to freedom of thought, conscience and
+>>>> religion.......
+>>>>
+>>>> http://en.wikipedia.org/wiki/Universal_Declaration_of_Human_Rights#Article_18
+>>> Yes, so why do you deny these right sto the majority of the forum people?
+>>>
+>> I don't :)
+>> I don't even deny it when our seeming majority would turn out to be a
+>> minority.
+>>
+>> Please be careful with the words "the majority", we don't have a good tool
+>> yet to know what everybody wants.
+> Hmm, from the people who participated in the initial discussion which
+> led to the council compromise I count 2 in favor of the limitation,
+> the rest against it. This I call a majority.
+> During the 8 months since we have this issue I read lots of complaints
+> about the limitation, I did not read any post in favor of it. This is
+> what I call a majority.
+
+I don't.
+
+There are a forum thread and a bug report with a lot of harsh words, and 
+only a minority of the Mageia community participated. It is possible 
+that the angry majority there has the same opinion as the real majority, 
+but we don't know yet.
+
+
+> In an election or a poll (a democratic process) how much weight do
+> those have who do not give their vote? In every election there is a
+> number of people who do not vote, either because they don't care or
+> none of the given options is to their liking. But I haven't seen an
+> election or poll where the "silent" number was counted in favor for
+> one side or the other. So, if you are talking about the silent
+> majority I can ask you rightfully, on which side the silent majority
+> would be.
+>
+I was not clear, sorry.
+
+IMHO, if every Mageia community member had received an invitation to 
+vote in a virtual polling station, seperated from the emotional forum 
+thread about the issue, there would have been a lot more votes.
+
+* It is well known that people can vote differently when there votes are 
+seen then when they are not seen.
+* Also a thread where such harsh words are said, makes some people run 
+away, and others reluctant to say what they think, for fear everything 
+might escalate further.
+* Apart from that, there are community members who never were aware this 
+thread was there
+* and others were, but didn't know it was the place to vote.
+
+Of course I don't know what outcome a proper democratic voting would 
+have given.
+>>> I guess you agree that those principles where written with the spirit
+>>> of democracy behind it all - so you agree also that those declarations
+>>> do not say that one has the right to force his opinion on all others.
+>>
+>> Of course not. Funny that you seem to think maât did that, I didn't see him
+>> force anyone to use the forum as it is.
+> Then you think that his behavior is ok and everybody who doesn't like
+> it can leave? That is not funny. It is against all that Mageia stands
+> for.
+> I think we do not have different opinions, we are living in different worlds.
+>
+
+I think that if a real majority wants a forum with unlimited edit time, 
+that we should have it.
+
+My point is, that Maât isn't our slave, we can't force him to do it, never.
+
+So then it would be necessary to look for someone else to take Maât's 
+place.
+
+I hope that if that happens, we'll at least manage to be nice to him and 
+thank him for the work he has done.
+
+
+
+
+
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011297.html b/zarb-ml/mageia-dev/2012-January/011297.html new file mode 100644 index 000000000..013b95e50 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011297.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Juan Luis Baptiste + juancho at mageia.org +
+ Thu Jan 12 20:04:07 CET 2012 +

+
+ +
On Thu, Jan 12, 2012 at 1:01 PM, Christian Lohmaier
+<lohmaier+mageia at googlemail.com> wrote:
+> On Wed, Jan 11, 2012 at 10:09 PM, Juan Luis Baptiste <juancho at mageia.org> wrote:
+>> [..]
+>> As I said, no one is talking about picking up a fix if there's a bug
+>> fix only release, it's for when it isn't and we need to reduce the
+>> chance of regressions by taking the modifications that *exactly* fix
+>> that bug.
+>
+> I strongly disagree. The policy is stating the exact opposite. And
+> also Michael seems to defend the policy as it is written, and not your
+> interpretation here.
+>
+
+No, I'm doing exactly as the policy says, patch current stable
+version. The thing about bugfix only releases is something that it
+seems packagers have been doing implicitly as pterjan said before, and
+needs to be added to the policy.
+
+> That again you might have a different understanding of
+> bugfix-only-release. I think I stated mine often enough (increase in
+> micro version when package follows major.minor.micro versioning scheme
+> and no new features are introduced in micro releases).
+>
+
+This isn't always the case, some projects include both bug fixes and
+new minor features in a micro version bump release. So you have to
+check first the Changelog to be sure it only includes bug fixes (which
+I do not completely agree for some cases, but that's another topic).
+
+> So please change the wording of the update policy accordingly
+> https://wiki.mageia.org/en/Updates_policy reads:
+> ##########
+
+[...]
+
+> ##########
+> I read it as "no version bumb is allowed (except for the three
+> exception-cases listed) - bugs are only fixed using patches", and I
+> don't see the interpretational freedom to allow upstream's bugfix
+> releases. Updating from 1.3.2 to 1.3.3 would not be in compliance with
+> the policy (if not in one of the three exception cases) - this is what
+> I have called stupid policy (and still do).
+>
+
+Yes, this must be added to the policy to avoid more confusions.
+
+
+-- 
+Juancho
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011298.html b/zarb-ml/mageia-dev/2012-January/011298.html new file mode 100644 index 000000000..252a4f413 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011298.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Christian Lohmaier + lohmaier+mageia at googlemail.com +
+ Thu Jan 12 20:10:59 CET 2012 +

+
+ +
On Thu, Jan 12, 2012 at 8:04 PM, Juan Luis Baptiste <juancho at mageia.org> wrote:
+> On Thu, Jan 12, 2012 at 1:01 PM, Christian Lohmaier
+> <lohmaier+mageia at googlemail.com> wrote:
+>> On Wed, Jan 11, 2012 at 10:09 PM, Juan Luis Baptiste <juancho at mageia.org> wrote:
+>>> [..]
+>>> As I said, no one is talking about picking up a fix if there's a bug
+>>> fix only release, it's for when it isn't and we need to reduce the
+>>> chance of regressions by taking the modifications that *exactly* fix
+>>> that bug.
+>>
+>> I strongly disagree. The policy is stating the exact opposite. And
+>> also Michael seems to defend the policy as it is written, and not your
+>> interpretation here.
+>>
+>
+> No, I'm doing exactly as the policy says, patch current stable
+> version.
+
+But then you're *not* doing as the policy says, as policy says:
+"same version of the package *released with the distribution*"
+So whatever version that ended up in the initial release of the
+distro. Not what is available upstream.
+
+> The thing about bugfix only releases is something that it
+> seems packagers have been doing implicitly as pterjan said before, and
+> needs to be added to the policy.
+
+Yes, but this then changes the policy drastically (for the better, so
+please change it)
+
+And when I write "whatever is against the policy" - I'm referring to
+what is written in the wiki, not what people actually do.
+If you don't care what is written, but do how you like, then there's
+no point in having written policy, and even less reason to point
+people to those policies to make them shut up/not ask questions.
+
+ciao
+Christian
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011299.html b/zarb-ml/mageia-dev/2012-January/011299.html new file mode 100644 index 000000000..56d33de91 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011299.html @@ -0,0 +1,161 @@ + + + + [Mageia-dev] Over-zealous rpmlint policy (rejecting rt) + + + + + + + + + +

[Mageia-dev] Over-zealous rpmlint policy (rejecting rt)

+ Michael Scherer + misc at zarb.org +
+ Thu Jan 12 20:28:31 CET 2012 +

+
+ +
Le jeudi 12 janvier 2012 à 11:12 +0200, Buchan Milne a écrit :
+> I am trying to get rt (3.8.11) into the distro (a package that I am using on a 
+> different distro in a production environment), to be followed up with the rt 
+> (4.0.4) I have queued (which I am testing in preparation for upgrading our 
+> production environment).
+> 
+> I would really like to get this package into the distro, but it is being 
+> rejected 
+> (http://pkgsubmit.mageia.org/uploads/rejected//cauldron/core/release/20120110140334.buchan.valstar.18287.youri) 
+> due to:
+> 
+> Submission errors, aborting:
+> - rt-3.8.11-1.mga2.noarch:
+>  - dir-or-file-in-usr-local /usr/local/lib/rt/plugins
+>  - dir-or-file-in-usr-local /usr/local/lib/rt
+>  - dir-or-file-in-usr-local /usr/local/lib/rt/po
+>  - dir-or-file-in-usr-local /usr/local/lib/rt/lib
+>  - dir-or-file-in-usr-local /usr/local/etc/rt
+>  - dir-or-file-in-usr-local /usr/local/lib/rt/html
+> 
+> The documented way for extending RT is by installing files in this location. 
+> We can either:
+> 1)Make it more difficult for users to extend RT with local plugins etc.
+> 2)Fix rpmlint
+> 3)Not have RT
+> 
+> misc, you have experience of both rt and rpmlint, can you provide an opinion?
+>
+> Would it be possible to separate 'dir-or-file-usr-local' into separate rules 
+> (one for files, one for dirs)? While I agree we shouldn't ship files in 
+> /usr/local, I don't see why we shouldn't ship dirs in /usr/local ...
+
+We shouldn't ship directories for the same reason that we shouldn't ship
+file, ie FHS.
+
+See :
+http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRLOCALLOCALHIERARCHY
+
+More specifically :
+"It needs to be safe from being overwritten when the system software is
+updated."
+
+So the question is whether someone who change directory permissions will
+see them overwritten or not when the software is updated, and wether
+that a FHS violation.
+
+Afaik, rpm would reset the permission ( the same goes for removal of the
+directory ). 
+
+See also :
+"No other directories, except those listed below, may be in /usr/local
+after first installing a FHS-compliant system."
+
+Again, that's not clear if we can modify it later or not ( ie, is
+instaling rt on installation part of "first installing" or not ).
+
+I guess we should get a opinion from FHS/LSB people on this.
+
+In the mean time, I guess the point 1 is the easiest way, it can be
+changed later once we clarified FHS (or if we decide that we do not care
+about following standards, but that's really something I would like to
+avoid ). 
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011300.html b/zarb-ml/mageia-dev/2012-January/011300.html new file mode 100644 index 000000000..108e04313 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011300.html @@ -0,0 +1,124 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Florian Hubold + doktor5000 at arcor.de +
+ Thu Jan 12 20:42:37 CET 2012 +

+
+ +
Am 12.01.2012 19:01, schrieb Christian Lohmaier:
+> Hi Juan Luis,
+>
+> On Wed, Jan 11, 2012 at 10:09 PM, Juan Luis Baptiste <juancho at mageia.org> wrote:
+>> [..]
+>> As I said, no one is talking about picking up a fix if there's a bug
+>> fix only release, it's for when it isn't and we need to reduce the
+>> chance of regressions by taking the modifications that *exactly* fix
+>> that bug.
+> I strongly disagree. The policy is stating the exact opposite. And
+> also Michael seems to defend the policy as it is written, and not your
+> interpretation here.
+>
+> That again you might have a different understanding of
+> bugfix-only-release. I think I stated mine often enough (increase in
+> micro version when package follows major.minor.micro versioning scheme
+> and no new features are introduced in micro releases).
+>
+> So please change the wording of the update policy accordingly
+> https://wiki.mageia.org/en/Updates_policy reads:
+> ##########
+> For the most part, an update should consist of a patched build of the
+> same version of the package released with the distribution, with a few
+> exceptions:
+>
+> * Software versions that are no longer supported upstream with updates
+> (firefox and thunderbird seem to fall into this category these days)
+> * Software that is version-bound to an online service (games, virus
+> scanners?) and will only work with the latest version.
+> * We will make exceptions for packages that did not make it into mga1
+> and are additions to the distribution, provided they do not impact any
+> other packages and can pass full QA.
+>
+> Updates are not the appropriate place for packages created to satisfy
+> certain user's urges for "the latest". These types of builds belong in
+> backports.
+> ##########
+> I read it as "no version bumb is allowed (except for the three
+> exception-cases listed) - bugs are only fixed using patches", and I
+> don't see the interpretational freedom to allow upstream's bugfix
+> releases. Updating from 1.3.2 to 1.3.3 would not be in compliance with
+> the policy (if not in one of the three exception cases) - this is what
+> I have called stupid policy (and still do).
+>
+> ciao
+> Christian
+>
+Actually you're right there, currently the only case where a bugfix-only update
+would be allowed would be as an exception. And as those should be rare
+(hence the term exception) i don't think that's the intent of the third point.
+
+So as some already stated this, as it seems to be allowed to ship bugfix-only
+releases as updates, where does the policy state that, and in the case
+where it doesn't, shouldn't we extent the policy if that is considered good
+practice?
+
+
+PS: Maybe next time you could improve on your wording, the policy may
+currently be incorrect, not reflecting good packaging practices, but as it's
+only a policy written by humans, it's not dumb. Just a hint. ;)
+
+ + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011301.html b/zarb-ml/mageia-dev/2012-January/011301.html new file mode 100644 index 000000000..dad8d5b6a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011301.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] Display manager + + + + + + + + + +

[Mageia-dev] Display manager

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Jan 12 20:47:45 CET 2012 +

+
+ +
'Twas brillig, and Paiiou at 10/01/12 19:22 did gyre and gimble:
+> The "Provides" most of the display manager shows "dm".
+> This is not the case of xdm and lxdm.
+> Should we not add?
+
+Probably, yes.
+
+Col
+
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011302.html b/zarb-ml/mageia-dev/2012-January/011302.html new file mode 100644 index 000000000..34bcd694d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011302.html @@ -0,0 +1,77 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Juan Luis Baptiste + juancho at mageia.org +
+ Thu Jan 12 20:53:32 CET 2012 +

+
+ +
On Thu, Jan 12, 2012 at 2:10 PM, Christian Lohmaier
+<lohmaier+mageia at googlemail.com> wrote:
+>> No, I'm doing exactly as the policy says, patch current stable
+>> version.
+>
+> But then you're *not* doing as the policy says, as policy says:
+> "same version of the package *released with the distribution*"
+> So whatever version that ended up in the initial release of the
+> distro. Not what is available upstream.
+>
+
+Were do you get that ? have you even went through the updates I have
+sent and found one that was a new version ? if you do will see that
+ALL of my updates are a patched mga 1 version.
+
+
+-- 
+Juancho
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011303.html b/zarb-ml/mageia-dev/2012-January/011303.html new file mode 100644 index 000000000..ce822babe --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011303.html @@ -0,0 +1,89 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Christian Lohmaier + lohmaier+mageia at googlemail.com +
+ Thu Jan 12 21:02:03 CET 2012 +

+
+ +
Hi Juan Luis,
+
+On Thu, Jan 12, 2012 at 8:53 PM, Juan Luis Baptiste <juancho at mageia.org> wrote:
+> On Thu, Jan 12, 2012 at 2:10 PM, Christian Lohmaier
+> <lohmaier+mageia at googlemail.com> wrote:
+>>> No, I'm doing exactly as the policy says, patch current stable
+>>> version.
+>>
+>> But then you're *not* doing as the policy says, as policy says:
+>> "same version of the package *released with the distribution*"
+>> So whatever version that ended up in the initial release of the
+>> distro. Not what is available upstream.
+>>
+>
+> Were do you get that ? have you even went through the updates I have
+> sent and found one that was a new version ? if you do will see that
+> ALL of my updates are a patched mga 1 version.
+
+You should learn to use unambiguous words then. Where I get that from
+is in this quote:
+"No, I'm doing exactly as the policy says, patch current stable version."
+
+To me "current stable version" = whatever is available upstream as the
+current stable version (=bugfixrelease) of the codeline that is in the
+distro.
+If distro has shipped 1.3.2 initially, and 1.3.4 is available in the
+meantime, then "current stable" is 1.3.4 in my world, not 1.3.2.
+
+ciao
+Christian
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011304.html b/zarb-ml/mageia-dev/2012-January/011304.html new file mode 100644 index 000000000..5875accdd --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011304.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] Mageia 2 Alpha 3 available for tests + + + + + + + + + +

[Mageia-dev] Mageia 2 Alpha 3 available for tests

+ Anne nicolas + ennael at mageia.org +
+ Thu Jan 12 21:04:35 CET 2012 +

+
+ +
Hi all
+
+Mageia 2 Alpha 3 is now available for tests:
+http://blog.mageia.org/en/2012/01/12/here-comes-mageia-2-alpha3/
+
+Please note that only DVDs isos are available for now. Live CDs will
+be uploaded next week, due to some issues with dracut migration.
+
+Thanks for all the hard work and enjoy it!
+
+-- 
+Anne
+http://www.mageia.org
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011305.html b/zarb-ml/mageia-dev/2012-January/011305.html new file mode 100644 index 000000000..5157ccd27 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011305.html @@ -0,0 +1,72 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Juan Luis Baptiste + juancho at mageia.org +
+ Thu Jan 12 21:05:27 CET 2012 +

+
+ +
On Thu, Jan 12, 2012 at 3:02 PM, Christian Lohmaier
+<lohmaier+mageia at googlemail.com> wrote:
+>
+> You should learn to use unambiguous words then. Where I get that from
+> is in this quote:
+> "No, I'm doing exactly as the policy says, patch current stable version."
+>
+
+Ahh ok, I meant "current stable version in Mageia", I thought that was
+implicit :P
+
+-- 
+Juancho
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011306.html b/zarb-ml/mageia-dev/2012-January/011306.html new file mode 100644 index 000000000..4dd8ebbc2 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011306.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Christian Lohmaier + lohmaier+mageia at googlemail.com +
+ Thu Jan 12 21:25:51 CET 2012 +

+
+ +
Hi Florian,
+
+On Thu, Jan 12, 2012 at 8:42 PM, Florian Hubold <doktor5000 at arcor.de> wrote:
+> Am 12.01.2012 19:01, schrieb Christian Lohmaier:
+>>> [..]
+> PS: Maybe next time you could improve on your wording, the policy may
+> currently be incorrect, not reflecting good packaging practices, but as it's
+> only a policy written by humans, it's not dumb. Just a hint. ;)
+
+No, I disagree. The policy as written is dumb in my opinion. But that
+doesn't mean I consider the people who edited the wiki to be dumb.
+That is a huge difference in my opinion. If I tell someone "Ugh,
+that's an ugly shirt you're wearing today" it is not the same as
+telling the person "you are ugly" - but people on this list do get it
+that way.
+
+If you publish a policy, and the policy is incorrect, the whole
+process of using policies is worthless. So I /have/ to assume that the
+policy reflects the decisions/conclusions from the discussions by
+people running the project.
+To me it stays a silly/stupid policy. Whether you like the word or
+not. It is not picking about typos or bad grammar or anything. It is
+the fundamental approach reflected by the policy that I consider so
+wrong that in my eyes it is stupid (and reason enough not to consider
+officially packing stuff for Mageia).
+I for myself prefer that people state what they really think, instead
+of being sarcastic or trying to be smart in other ways (what point is
+Johnny trying to make with his "hear, hear" for example?) . This just
+doesn't work when you don't have other info than the text on your
+screen (no facial expression, no tone of voice, ~no background
+knowledge on the person making the statement).
+
+It might be my lack of understanding the English language, but
+"stupid" just is a regular word - it is not like I'd be using
+something like "moth.*ker" here. Also my thesaurus only lists words
+that I consider more harsh (like retarded, brainless,...).
+
+So once again sorry if that did offend some people, feel free to
+suggest (via pm, no need to continue this on the list) a wording that
+still carries the same meaning, but is less "insulting".
+
+ciao
+Christian
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011307.html b/zarb-ml/mageia-dev/2012-January/011307.html new file mode 100644 index 000000000..351bf3c63 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011307.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Romain d'Alverny + rdalverny at gmail.com +
+ Thu Jan 12 22:00:16 CET 2012 +

+
+ +
On Thu, Jan 12, 2012 at 21:25, Christian Lohmaier
+<lohmaier+mageia at googlemail.com> wrote:
+> On Thu, Jan 12, 2012 at 8:42 PM, Florian Hubold <doktor5000 at arcor.de> wrote:
+>> Am 12.01.2012 19:01, schrieb Christian Lohmaier:
+>>>> [..]
+>> PS: Maybe next time you could improve on your wording, the policy may
+>> currently be incorrect, not reflecting good packaging practices, but as it's
+>> only a policy written by humans, it's not dumb. Just a hint. ;)
+>
+> No, I disagree. The policy as written is dumb in my opinion. But that
+> doesn't mean I consider the people who edited the wiki to be dumb.
+> That is a huge difference in my opinion. If I tell someone "Ugh,
+> that's an ugly shirt you're wearing today" it is not the same as
+> telling the person "you are ugly" - but people on this list do get it
+> that way.
+
+Agreed.
+
+Still, let's cut it short and to the point. Can someone rewrite it as
+it should be then (adding the missing exception if I understood
+correctly)?
+
+By the same time, could the document be written short and straightforward:
+ - start the document with the very policy (at this time, it's in the
+3rd sub-section);
+ - write it in a more assertive way (not "should do" but "does");
+ - all other subsections should be there to explain status, context, roles, etc.
+
+> It might be my lack of understanding the English language, but
+> "stupid" just is a regular word - it is not like I'd be using
+> something like "moth.*ker" here. Also my thesaurus only lists words
+> that I consider more harsh (like retarded, brainless,...).
+
+You could have said "misleading", "deceptive", "heartbreaking",
+"disheartening", "expectations breaking", "amusingly inaccurate" or
+"unusual". The fact is that this policy document starts with a warning
+that it is a "first pass" - so it may be improved.
+
+In short: let's behave a bit more like gentlemen this year, shall we? :)
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011308.html b/zarb-ml/mageia-dev/2012-January/011308.html new file mode 100644 index 000000000..856710735 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011308.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] "Hear, hear" usage + + + + + + + + + +

[Mageia-dev] "Hear, hear" usage

+ Johnny A. Solbu + cooker at solbu.net +
+ Thu Jan 12 22:17:31 CET 2012 +

+
+ +
On Thursday 12 January 2012 21:25, Christian Lohmaier wrote:
+> what point is Johnny trying to make with his "hear, hear" for example?
+
+As far as I understand, that is a common British thing to do when one agree with the current speaker.
+(Watch news reports involving the British government's debates, usually involving the Prime minister, for some examples)
+Another way I see people do the exact same thing is replying with "+1". "Hear, hear" is the same thing.
+
+Untill someone comes with valid claims that this have the exact opposite meaning or to be offensive in another other country, I intend to keep using it. :-)=
+
+-- 
+Johnny A. Solbu
+PGP key ID: 0xFA687324
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 189 bytes
+Desc: This is a digitally signed message part.
+URL: </pipermail/mageia-dev/attachments/20120112/cc4af99c/attachment.asc>
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011309.html b/zarb-ml/mageia-dev/2012-January/011309.html new file mode 100644 index 000000000..e5a8bc352 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011309.html @@ -0,0 +1,73 @@ + + + + [Mageia-dev] "Hear, hear" usage + + + + + + + + + +

[Mageia-dev] "Hear, hear" usage

+ Frank Griffin + ftg at roadrunner.com +
+ Thu Jan 12 22:28:47 CET 2012 +

+
+ +
On 01/12/2012 04:17 PM, Johnny A. Solbu wrote:
+> On Thursday 12 January 2012 21:25, Christian Lohmaier wrote:
+>> what point is Johnny trying to make with his "hear, hear" for example?
+> As far as I understand, that is a common British thing to do when one agree with the current speaker.
+> (Watch news reports involving the British government's debates, usually involving the Prime minister, for some examples)
+> Another way I see people do the exact same thing is replying with "+1". "Hear, hear" is the same thing.
+>
+> Untill someone comes with valid claims that this have the exact opposite meaning or to be offensive in another other country, I intend to keep using it. :-)=
+>
+Your usage is correct, and it's used in American English as well.  The 
+intended meaning is "Hear (i. e. listen to) the speaker, because I find 
+value in what he is saying".
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011310.html b/zarb-ml/mageia-dev/2012-January/011310.html new file mode 100644 index 000000000..8193c8389 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011310.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] "Hear, hear" usage + + + + + + + + + +

[Mageia-dev] "Hear, hear" usage

+ Florian Hubold + doktor5000 at arcor.de +
+ Thu Jan 12 22:43:54 CET 2012 +

+
+ +
Am 12.01.2012 22:28, schrieb Frank Griffin:
+> On 01/12/2012 04:17 PM, Johnny A. Solbu wrote:
+>> On Thursday 12 January 2012 21:25, Christian Lohmaier wrote:
+>>> what point is Johnny trying to make with his "hear, hear" for example?
+>> As far as I understand, that is a common British thing to do when one agree
+>> with the current speaker.
+>> (Watch news reports involving the British government's debates, usually
+>> involving the Prime minister, for some examples)
+>> Another way I see people do the exact same thing is replying with "+1".
+>> "Hear, hear" is the same thing.
+>>
+>> Untill someone comes with valid claims that this have the exact opposite
+>> meaning or to be offensive in another other country, I intend to keep using
+>> it. :-)=
+>>
+> Your usage is correct, and it's used in American English as well.  The
+> intended meaning is "Hear (i. e. listen to) the speaker, because I find value
+> in what he is saying".
+>
+Well, directly translating this phrase into german, it has another meaning.
+Used in colloquial language, it means something like ironically saying
+"well, look at that" or "enough with this nonsense" but also in the form
+Johnny used it.
+
+But at least understanding problems are cleared out now :)
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011311.html b/zarb-ml/mageia-dev/2012-January/011311.html new file mode 100644 index 000000000..e244f1a64 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011311.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] Mageia 2 Alpha 3 available for tests + + + + + + + + + +

[Mageia-dev] Mageia 2 Alpha 3 available for tests

+ Kamil Rytarowski + n54 at gmx.com +
+ Thu Jan 12 22:47:39 CET 2012 +

+
+ +
W dniu 12.01.2012 21:04, Anne nicolas pisze:
+> Hi all
+>
+> Mageia 2 Alpha 3 is now available for tests:
+> http://blog.mageia.org/en/2012/01/12/here-comes-mageia-2-alpha3/
+>
+> Please note that only DVDs isos are available for now. Live CDs will
+> be uploaded next week, due to some issues with dracut migration.
+>
+> Thanks for all the hard work and enjoy it!
+>
+Thanks!
+
+Can we now push bigger changes into BS?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011312.html b/zarb-ml/mageia-dev/2012-January/011312.html new file mode 100644 index 000000000..d5c626d51 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011312.html @@ -0,0 +1,77 @@ + + + + [Mageia-dev] packaging help required + + + + + + + + + +

[Mageia-dev] packaging help required

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Thu Jan 12 23:34:51 CET 2012 +

+
+ +
Le 12/01/2012 14:14, D.Morgan a écrit :
+> can you make a src.rpm available somewhere for us to look ? ( we
+> should be able to help with gil on the java packaging related issues )
+You can fetch spec and source files here:
+https://github.com/jenkinsci/jenkins/tree/master/rpm
+
+-- 
+BOFH excuse #258:
+
+That's easy to fix, but I can't be bothered.
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011313.html b/zarb-ml/mageia-dev/2012-January/011313.html new file mode 100644 index 000000000..df127a991 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011313.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Juan Luis Baptiste + juancho at mageia.org +
+ Thu Jan 12 23:35:35 CET 2012 +

+
+ +
On Thu, Jan 12, 2012 at 3:25 PM, Christian Lohmaier
+<lohmaier+mageia at googlemail.com> wrote:
+> Hi Florian,
+>
+> On Thu, Jan 12, 2012 at 8:42 PM, Florian Hubold <doktor5000 at arcor.de> wrote:
+>> Am 12.01.2012 19:01, schrieb Christian Lohmaier:
+>>>> [..]
+>> PS: Maybe next time you could improve on your wording, the policy may
+>> currently be incorrect, not reflecting good packaging practices, but as it's
+>> only a policy written by humans, it's not dumb. Just a hint. ;)
+>
+> No, I disagree. The policy as written is dumb in my opinion. But that
+> doesn't mean I consider the people who edited the wiki to be dumb.
+> That is a huge difference in my opinion. If I tell someone "Ugh,
+> that's an ugly shirt you're wearing today" it is not the same as
+> telling the person "you are ugly" - but people on this list do get it
+> that way.
+>
+
+Continuing with your example, yes, you aren't telling them that
+they're ugly, you are telling them that they have bad taste, and for
+some that can be insulting and for others not. You could have made
+your point by saying that *you* don't like that t-shirt because of x
+and y motives and if he had chosen another one with Y characteristics
+would look much better on him.
+
+Do you see the difference on wording ? you are expressing the same
+idea but in a more polite way. The same applies here. Your point about
+the problem in the policy is totally valid and needs to be addressed,
+but the way you expressed it is not, no matter you if you think it
+was. If it was, then no one had felt insulted on the first place ;)
+
+-- 
+Juancho
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011314.html b/zarb-ml/mageia-dev/2012-January/011314.html new file mode 100644 index 000000000..01cb73669 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011314.html @@ -0,0 +1,81 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Christian Lohmaier + lohmaier+mageia at googlemail.com +
+ Thu Jan 12 23:41:24 CET 2012 +

+
+ +
On Thu, Jan 12, 2012 at 11:35 PM, Juan Luis Baptiste <juancho at mageia.org> wrote:
+> On Thu, Jan 12, 2012 at 3:25 PM, Christian Lohmaier
+> <lohmaier+mageia at googlemail.com> wrote:
+> [...] You could have made
+> your point by saying that *you* don't like that t-shirt because of x
+> and y motives and if he had chosen another one with Y characteristics
+> would look much better on him.
+
+If you reread my posts, you'll notice that whenever I called it
+stupid, a "in my opinion" or equivalent is just around the corner. And
+you'll also see that I also wrote what I consider the better
+alternative (I wrote it so often that people surely are annoyed by
+now)
+
+ciao
+Christian
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011315.html b/zarb-ml/mageia-dev/2012-January/011315.html new file mode 100644 index 000000000..73706de48 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011315.html @@ -0,0 +1,111 @@ + + + + [Mageia-dev] Existing Cauldron VM users willing to test gnome-boxes? + + + + + + + + + +

[Mageia-dev] Existing Cauldron VM users willing to test gnome-boxes?

+ Scott Chevalley + avalon at osguru.org +
+ Fri Jan 13 00:14:46 CET 2012 +

+
+ +
On 01/12/2012 07:53 AM, Olav Vitters wrote:
+> Anyone making use of qemu + kvm for VMs on Cauldron?
+> 
+> Could you please install gnome-boxes, start it from the command line and
+> tell me if it works when you select some .iso file + create + start a
+> VM?
+> Please test on x86_64 (as host).
+> 
+> Note: It is not working for me, but I have solved all known problems. At
+> the moment I just like to know if perhaps it is my lack of VM knowledge
+> and/or a local problem.
+> 
+> Michael Hill has already done lots of testing + discussion with
+> upstream, but him+me fail to get a VM. Him due to a bug I think in
+> gnome-boxes on i586/i686, me.. no idea why it is failing.
+> 
+
+I'm using KVM for a windows 7 vm and I just tried to use gnome-boxes to create,
+I guess, a vm for a drbl live cd and it created it but when I launch it the app
+just shows a black screen and doesn't do anything.
+
+There's not much documentation so I'm not sure exactly what's supposed to happen
+versus what is happening.
+
+I'll be happy to do some more testing if you can give me some pointers as to
+what I'm looking for.
+
+Scott
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011316.html b/zarb-ml/mageia-dev/2012-January/011316.html new file mode 100644 index 000000000..e783b22f8 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011316.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases + + + + + + + + + +

[Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases

+ Maarten Vanraes + alien at rmail.be +
+ Fri Jan 13 02:20:19 CET 2012 +

+
+ +
see https://blog.mozilla.com/blog/2012/01/10/delivering-a-mozilla-firefox-
+extended-support-release/
+see https://wiki.mozilla.org/images/9/9d/Esr-release-overview.png
+
+ESR is a 1y extended supported release...
+
+looking at the image we'd be having supported versions for our 9month release 
+schedule every time... we should totally use this release and not go towards 
+FF11 for our release.
+
+We've been complaining about the too quick release schedule... this is our 
+chance!
+
+( i think if the FF maintainer wishes, he could also do backports of the 
+regular releases... )
+
+i'm hoping everyone agrees? including FF maintainer?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011317.html b/zarb-ml/mageia-dev/2012-January/011317.html new file mode 100644 index 000000000..047ddd530 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011317.html @@ -0,0 +1,113 @@ + + + + [Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases + + + + + + + + + +

[Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases

+ D.Morgan + dmorganec at gmail.com +
+ Fri Jan 13 02:22:20 CET 2012 +

+
+ +
On Fri, Jan 13, 2012 at 2:20 AM, Maarten Vanraes <alien at rmail.be> wrote:
+> see https://blog.mozilla.com/blog/2012/01/10/delivering-a-mozilla-firefox-
+> extended-support-release/
+> see https://wiki.mozilla.org/images/9/9d/Esr-release-overview.png
+>
+> ESR is a 1y extended supported release...
+>
+> looking at the image we'd be having supported versions for our 9month release
+> schedule every time... we should totally use this release and not go towards
+> FF11 for our release.
+>
+> We've been complaining about the too quick release schedule... this is our
+> chance!
+>
+> ( i think if the FF maintainer wishes, he could also do backports of the
+> regular releases... )
+>
+> i'm hoping everyone agrees? including FF maintainer?
+
+
+seems we should stuck to FF 10 as default release for mageia2.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011318.html b/zarb-ml/mageia-dev/2012-January/011318.html new file mode 100644 index 000000000..55530a317 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011318.html @@ -0,0 +1,127 @@ + + + + [Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases + + + + + + + + + +

[Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases

+ Sander Lepik + sander.lepik at eesti.ee +
+ Fri Jan 13 08:53:09 CET 2012 +

+
+ +
13.01.2012 03:20, Maarten Vanraes kirjutas:
+> see https://blog.mozilla.com/blog/2012/01/10/delivering-a-mozilla-firefox-
+> extended-support-release/
+> see https://wiki.mozilla.org/images/9/9d/Esr-release-overview.png
+>
+> ESR is a 1y extended supported release...
+>
+> looking at the image we'd be having supported versions for our 9month release
+> schedule every time... we should totally use this release and not go towards
+> FF11 for our release.
+>
+> We've been complaining about the too quick release schedule... this is our
+> chance!
+>
+> ( i think if the FF maintainer wishes, he could also do backports of the
+> regular releases... )
+>
+> i'm hoping everyone agrees? including FF maintainer?
+I don't agree. But i'm not the maintainer.
+
+Why not?
+* Since fx10 all non-binary extensions are compatible by default (so our 
+main problem goes away).
+* fx10 in 6 months is dead old for users POV. Many unhappy users. Lower 
+popularity for Mageia. (Ubuntu AFAIK is going with fast schedule).
+* We will miss too many new and cool features.
+* When we release
+
+But as i said.. up to maintainer.
+
+--
+Sander
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011319.html b/zarb-ml/mageia-dev/2012-January/011319.html new file mode 100644 index 000000000..f95555ca3 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011319.html @@ -0,0 +1,76 @@ + + + + [Mageia-dev] "Hear, hear" usage + + + + + + + + + +

[Mageia-dev] "Hear, hear" usage

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Fri Jan 13 09:01:11 CET 2012 +

+
+ +
Am Donnerstag, 12. Januar 2012, 22:43:54 schrieb Florian Hubold:
+> > On 01/12/2012 04:17 PM, Johnny A. Solbu wrote:
+> >> As far as I understand, that is a common British thing to do when one
+> >> agree
+> >> with the current speaker.
+> Well, directly translating this phrase into german, it has another meaning.
+> Used in colloquial language, it means something like ironically saying
+> "well, look at that" or "enough with this nonsense" but also in the form
+> Johnny used it.
+You must have a different dirct translation than me. Directly translating it 
+into German makes no sense at all :D
+
+But you should never translate anything directly between languages...
+
+Oliver
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011320.html b/zarb-ml/mageia-dev/2012-January/011320.html new file mode 100644 index 000000000..faf3bb3a1 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011320.html @@ -0,0 +1,131 @@ + + + + [Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases + + + + + + + + + +

[Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases

+ D.Morgan + dmorganec at gmail.com +
+ Fri Jan 13 09:05:02 CET 2012 +

+
+ +
On Fri, Jan 13, 2012 at 8:53 AM, Sander Lepik <sander.lepik at eesti.ee> wrote:
+> 13.01.2012 03:20, Maarten Vanraes kirjutas:
+>
+>> see https://blog.mozilla.com/blog/2012/01/10/delivering-a-mozilla-firefox-
+>> extended-support-release/
+>> see https://wiki.mozilla.org/images/9/9d/Esr-release-overview.png
+>>
+>> ESR is a 1y extended supported release...
+>>
+>> looking at the image we'd be having supported versions for our 9month
+>> release
+>> schedule every time... we should totally use this release and not go
+>> towards
+>> FF11 for our release.
+>>
+>> We've been complaining about the too quick release schedule... this is our
+>> chance!
+>>
+>> ( i think if the FF maintainer wishes, he could also do backports of the
+>> regular releases... )
+>>
+>> i'm hoping everyone agrees? including FF maintainer?
+>
+> I don't agree. But i'm not the maintainer.
+>
+> Why not?
+> * Since fx10 all non-binary extensions are compatible by default (so our
+> main problem goes away).
+> * fx10 in 6 months is dead old for users POV. Many unhappy users. Lower
+> popularity for Mageia. (Ubuntu AFAIK is going with fast schedule).
+> * We will miss too many new and cool features.
+> * When we release
+>
+> But as i said.. up to maintainer.
+
+A reason can be that a new version can need new versions of external
+stuffs ( like nss, nspr, sqlite3, ... )
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011321.html b/zarb-ml/mageia-dev/2012-January/011321.html new file mode 100644 index 000000000..efd22fca1 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011321.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Buchan Milne + bgmilne at zarb.org +
+ Fri Jan 13 09:29:17 CET 2012 +

+
+ +
On Thursday, 12 January 2012 22:25:51 Christian Lohmaier wrote:
+> Hi Florian,
+> 
+> On Thu, Jan 12, 2012 at 8:42 PM, Florian Hubold <doktor5000 at arcor.de> wrote:
+> > Am 12.01.2012 19:01, schrieb Christian Lohmaier:
+> >>> [..]
+> > 
+> > PS: Maybe next time you could improve on your wording, the policy may
+> > currently be incorrect, not reflecting good packaging practices, but as
+> > it's only a policy written by humans, it's not dumb. Just a hint. ;)
+> 
+> No, I disagree. The policy as written is dumb in my opinion.
+
+I wouldn't say it is dumb, I would say it is conservative.
+
+Can you off-hand provide a list of which of our ~10 000 packages have a 
+'maintained bugfix only branch with regular releases' policy?
+
+I would expect it is less than 5%. Granted, this may include a number of 
+large/important packages. But, I can also post some counter-examples:
+-samba (but, it may be useful to have some not-strictly-bugfix changes, as 
+some are 'compatability with the new SP of some other popular OS')
+-openldap
+
+> If you publish a policy, and the policy is incorrect, the whole
+> process of using policies is worthless. So I /have/ to assume that the
+> policy reflects the decisions/conclusions from the discussions by
+> people running the project.
+
+I think some of the existing policies may have been done in haste. IMHO, there 
+should be a policy on policies, covering how they are agreed upon, how 
+amendments are agreed up etc.
+
+> To me it stays a silly/stupid policy.
+
+Please provide a proposal for changes to the policy.
+
+Regards,
+Buchan
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011322.html b/zarb-ml/mageia-dev/2012-January/011322.html new file mode 100644 index 000000000..a1f731232 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011322.html @@ -0,0 +1,116 @@ + + + + [Mageia-dev] [changelog] [RPM] 1 core/updates_testing lives-1.4.9-1.mga1 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] 1 core/updates_testing lives-1.4.9-1.mga1

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Fri Jan 13 09:37:18 CET 2012 +

+
+ +
On 13 January 2012 02:30, dams <buildsystem-daemon at mageia.org> wrote:
+> dams <dams> 1.4.9-1.mga1:
+> + Revision: 195501
+> - Update BR to install libmjpegtools-devel instead of mjpegtools-devel
+
+why?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011323.html b/zarb-ml/mageia-dev/2012-January/011323.html new file mode 100644 index 000000000..d208469f1 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011323.html @@ -0,0 +1,139 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ andre999 + andre999mga at laposte.net +
+ Fri Jan 13 10:28:57 CET 2012 +

+
+ +
Christian Lohmaier a écrit :
+> On Thu, Jan 12, 2012 at 8:04 PM, Juan Luis Baptiste<juancho at mageia.org>  wrote:
+>    
+>> On Thu, Jan 12, 2012 at 1:01 PM, Christian Lohmaier
+>> <lohmaier+mageia at googlemail.com>  wrote:
+>>      
+>>> On Wed, Jan 11, 2012 at 10:09 PM, Juan Luis Baptiste<juancho at mageia.org>  wrote:
+>>>        
+>>>> [..]
+>>>> As I said, no one is talking about picking up a fix if there's a bug
+>>>> fix only release, it's for when it isn't and we need to reduce the
+>>>> chance of regressions by taking the modifications that *exactly* fix
+>>>> that bug.
+>>>>          
+>>> I strongly disagree. The policy is stating the exact opposite. And
+>>> also Michael seems to defend the policy as it is written, and not your
+>>> interpretation here.
+>>>        
+>> No, I'm doing exactly as the policy says, patch current stable
+>> version.
+>>      
+> But then you're *not* doing as the policy says, as policy says:
+> "same version of the package *released with the distribution*"
+> So whatever version that ended up in the initial release of the
+> distro. Not what is available upstream.
+>    
+
+To make things entirely clear, the agreed base policy (in various 
+meetings) was that updates should contain no new features.  Thus in 
+general, a (verified) bug fix only release from upstream would qualify 
+as an update.
+This being subject to exceptions, which were later agreed on after much 
+discussion.
+
+Of course, to conform with our base policy of no new features in 
+updates, if an upstream release contains any new features (and doesn't 
+qualify for the exceptions), then bug fixes obviously have to be applied 
+in patches.  (Which is probably why the editor of the wiki page erred.)
+(Other factors, such as version number dependancies, would have to be 
+considered as well.)
+In other respects, this page accords with agreed policy.
+
+I don't really see the point of doing all this arguing about a wiki page 
+that doesn't completely accord with update policy.  We just have to fix 
+the wiki page.
+
+>> The thing about bugfix only releases is something that it
+>> seems packagers have been doing implicitly as pterjan said before, and
+>> needs to be added to the policy.
+>>      
+> Yes, but this then changes the policy drastically (for the better, so
+> please change it)
+>    
+
+It is not that drastic a change.  The effect is essentially the same, 
+although it is of course much easier -- and generally safer -- to apply 
+a (verified) bug fix only release from upstream.
+As stated above, and mentioned by others posting to this thread, the 
+wiki page does not accurately affect the policy.  (It is focusing on a 
+means of complying with the policy, rather than the policy itself.)
+
+> And when I write "whatever is against the policy" - I'm referring to
+> what is written in the wiki, not what people actually do.
+>    
+
+Policy is what was agreed on, and not any errors that may exist in what 
+is written in the wiki.  We have corrected many similar errors in the wiki.
+
+Calling your understanding of the policy "stupid" is not necessarily the 
+most diplomatic approach.
+
+> ciao
+> Christian
+>    
+
+Regards
+
+-- 
+André
+
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011324.html b/zarb-ml/mageia-dev/2012-January/011324.html new file mode 100644 index 000000000..1d893ec87 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011324.html @@ -0,0 +1,125 @@ + + + + [Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases + + + + + + + + + +

[Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases

+ nicolas vigier + boklm at mars-attacks.org +
+ Fri Jan 13 10:36:36 CET 2012 +

+
+ +
On Fri, 13 Jan 2012, Sander Lepik wrote:
+
+> 13.01.2012 03:20, Maarten Vanraes kirjutas:
+>> see https://blog.mozilla.com/blog/2012/01/10/delivering-a-mozilla-firefox-
+>> extended-support-release/
+>> see https://wiki.mozilla.org/images/9/9d/Esr-release-overview.png
+>>
+>> ESR is a 1y extended supported release...
+>>
+>> looking at the image we'd be having supported versions for our 9month release
+>> schedule every time... we should totally use this release and not go towards
+>> FF11 for our release.
+>>
+>> We've been complaining about the too quick release schedule... this is our
+>> chance!
+>>
+>> ( i think if the FF maintainer wishes, he could also do backports of the
+>> regular releases... )
+>>
+>> i'm hoping everyone agrees? including FF maintainer?
+> I don't agree. But i'm not the maintainer.
+>
+> Why not?
+> * Since fx10 all non-binary extensions are compatible by default (so our 
+> main problem goes away).
+> * fx10 in 6 months is dead old for users POV. Many unhappy users. Lower 
+> popularity for Mageia. (Ubuntu AFAIK is going with fast schedule).
+> * We will miss too many new and cool features.
+> * When we release
+
+We could say the same about any other software. Firefox was an exception
+on updates policy because there was no other choice. But there's no
+reason to keep it as an exception when they provide a supported version.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011325.html b/zarb-ml/mageia-dev/2012-January/011325.html new file mode 100644 index 000000000..6e9fe1432 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011325.html @@ -0,0 +1,115 @@ + + + + [Mageia-dev] Existing Cauldron VM users willing to test gnome-boxes? + + + + + + + + + +

[Mageia-dev] Existing Cauldron VM users willing to test gnome-boxes?

+ Olav Vitters + olav at vitters.nl +
+ Fri Jan 13 10:47:39 CET 2012 +

+
+ +
On Thu, Jan 12, 2012 at 06:14:46PM -0500, Scott Chevalley wrote:
+> I'm using KVM for a windows 7 vm and I just tried to use gnome-boxes to create,
+> I guess, a vm for a drbl live cd and it created it but when I launch it the app
+> just shows a black screen and doesn't do anything.
+
+Thanks for testing!
+
+I'm getting the same black screen. So it seems it doesn't work anyone :-(
+
+Did you launch it from the terminal? Any debug output?
+
+> There's not much documentation so I'm not sure exactly what's supposed to happen
+> versus what is happening.
+
+You should be seeing the VM. It uses something new called 'splice'. I
+think that is where the error lies. The Fedora version of qemu 0.15 had
+some patches which they dropped in qemu 1.0. I'm hoping qemu 1.0 solves
+the issues, but wasn't able to compile it yesterday.
+
+"Splice" is pretty nice as you can e.g. share your USB somehow between
+the host and the VM (gnome-boxes has a checkbox, but no clue about the
+technical details).
+
+> I'll be happy to do some more testing if you can give me some pointers as to
+> what I'm looking for.
+
+The debug output from the terminal would be nice, as well as
+$HOME/.libvirt/qemu/log/*.
+
+I really want to get this working before the next Mageia testversion is
+released..
+
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011326.html b/zarb-ml/mageia-dev/2012-January/011326.html new file mode 100644 index 000000000..641476e99 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011326.html @@ -0,0 +1,79 @@ + + + + [Mageia-dev] "Hear, hear" usage + + + + + + + + + +

[Mageia-dev] "Hear, hear" usage

+ Donald Stewart + watersnowrock at gmail.com +
+ Fri Jan 13 10:53:26 CET 2012 +

+
+ +
On 13 January 2012 09:01, Oliver Burger <oliver.bgr at googlemail.com> wrote:
+> Am Donnerstag, 12. Januar 2012, 22:43:54 schrieb Florian Hubold:
+>> > On 01/12/2012 04:17 PM, Johnny A. Solbu wrote:
+>> >> As far as I understand, that is a common British thing to do when one
+>> >> agree
+>> >> with the current speaker.
+>> Well, directly translating this phrase into german, it has another meaning.
+>> Used in colloquial language, it means something like ironically saying
+>> "well, look at that" or "enough with this nonsense" but also in the form
+>> Johnny used it.
+> You must have a different dirct translation than me. Directly translating it
+> into German makes no sense at all :D
+>
+> But you should never translate anything directly between languages...
+>
+> Oliver
+
+It came about because you aren't allouud to clap in parliment, so to
+express your approve, hear hear is used.
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011327.html b/zarb-ml/mageia-dev/2012-January/011327.html new file mode 100644 index 000000000..2efa4bd86 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011327.html @@ -0,0 +1,78 @@ + + + + [Mageia-dev] "Hear, hear" usage + + + + + + + + + +

[Mageia-dev] "Hear, hear" usage

+ Thorsten van Lil + tvl83 at gmx.de +
+ Fri Jan 13 11:09:09 CET 2012 +

+
+ +
Am 13.01.2012 09:01, schrieb Oliver Burger:
+> Am Donnerstag, 12. Januar 2012, 22:43:54 schrieb Florian Hubold:
+>>> On 01/12/2012 04:17 PM, Johnny A. Solbu wrote:
+>>>> As far as I understand, that is a common British thing to do when one
+>>>> agree
+>>>> with the current speaker.
+>> Well, directly translating this phrase into german, it has another meaning.
+>> Used in colloquial language, it means something like ironically saying
+>> "well, look at that" or "enough with this nonsense" but also in the form
+>> Johnny used it.
+> You must have a different dirct translation than me. Directly translating it
+> into German makes no sense at all :D
+
+I would translate it with "Hört! Hört!", which isn't used anymore, but 
+is still understandable.
+
+Regards,
+Thorsten
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011328.html b/zarb-ml/mageia-dev/2012-January/011328.html new file mode 100644 index 000000000..7c388bc25 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011328.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] Mageia 2 Alpha 3 available for tests + + + + + + + + + +

[Mageia-dev] Mageia 2 Alpha 3 available for tests

+ EatDirt + dirteat at gmail.com +
+ Fri Jan 13 11:11:02 CET 2012 +

+
+ +
On 12/01/12 21:04, Anne nicolas wrote:
+> Hi all
+>
+> Mageia 2 Alpha 3 is now available for tests:
+> http://blog.mageia.org/en/2012/01/12/here-comes-mageia-2-alpha3/
+
+Hi,
+tested the boot.iso with network install; everything went fine.
+
+At boot however, systemd exhibited some failures (apparently they are 
+harmless though):
+
+UNIT                           LOAD   ACTIVE SUB    JOB DESCRIPTION
+fedora-loadmodules.service     loaded ESC[1;31mfailed failedESC[0m 
+Load legacy module configuration
+systemd-tmpfiles-clean.service loaded ESC[1;31mfailed failedESC[0m 
+Cleanup of Temporary Directories
+systemd-tmpfiles-setup.service loaded ESC[1;31mfailed failedESC[0m 
+Recreate Volatile Files and Directories
+udisksd.service                loaded ESC[1;31mfailed failedESC[0m 
+UDisks Daemon
+upowerd.service                loaded ESC[1;31mfailed failedESC[0m 
+UPower Daemon
+
+
+Cheers,
+Chris.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011329.html b/zarb-ml/mageia-dev/2012-January/011329.html new file mode 100644 index 000000000..fd88869b3 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011329.html @@ -0,0 +1,135 @@ + + + + [Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases + + + + + + + + + +

[Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases

+ Claire Robinson + eeeemail at gmail.com +
+ Fri Jan 13 12:21:12 CET 2012 +

+
+ +
On 13/01/12 09:36, nicolas vigier wrote:
+> On Fri, 13 Jan 2012, Sander Lepik wrote:
+>
+>> 13.01.2012 03:20, Maarten Vanraes kirjutas:
+>>> see https://blog.mozilla.com/blog/2012/01/10/delivering-a-mozilla-firefox-
+>>> extended-support-release/
+>>> see https://wiki.mozilla.org/images/9/9d/Esr-release-overview.png
+>>>
+>>> ESR is a 1y extended supported release...
+>>>
+>>> looking at the image we'd be having supported versions for our 9month release
+>>> schedule every time... we should totally use this release and not go towards
+>>> FF11 for our release.
+>>>
+>>> We've been complaining about the too quick release schedule... this is our
+>>> chance!
+>>>
+>>> ( i think if the FF maintainer wishes, he could also do backports of the
+>>> regular releases... )
+>>>
+>>> i'm hoping everyone agrees? including FF maintainer?
+>> I don't agree. But i'm not the maintainer.
+>>
+>> Why not?
+>> * Since fx10 all non-binary extensions are compatible by default (so our
+>> main problem goes away).
+>> * fx10 in 6 months is dead old for users POV. Many unhappy users. Lower
+>> popularity for Mageia. (Ubuntu AFAIK is going with fast schedule).
+>> * We will miss too many new and cool features.
+>> * When we release
+>
+> We could say the same about any other software. Firefox was an exception
+> on updates policy because there was no other choice. But there's no
+> reason to keep it as an exception when they provide a supported version.
+>
+
+With 12 months support more often than not it would need updating in the 
+lifespan of the Mageia 9 month release anyway.
+
+Firefox is one of those programs that people like to be bang up to date 
+with. It is 'bragging rights' to ship with the latest and something 
+reviewers always give version numbers of along with libreoffice, kde, gnome.
+
+I understand the arguments to go with the 12 months support but I think 
+for the reasons above we should stick with the normal release cycle or 
+maybe even offer both?
+
+Claire
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011330.html b/zarb-ml/mageia-dev/2012-January/011330.html new file mode 100644 index 000000000..a527a5277 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011330.html @@ -0,0 +1,162 @@ + + + + [Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases + + + + + + + + + +

[Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases

+ Michael Scherer + misc at zarb.org +
+ Fri Jan 13 12:37:01 CET 2012 +

+
+ +
Le vendredi 13 janvier 2012 à 11:21 +0000, Claire Robinson a écrit :
+> On 13/01/12 09:36, nicolas vigier wrote:
+> > On Fri, 13 Jan 2012, Sander Lepik wrote:
+> >
+> >> 13.01.2012 03:20, Maarten Vanraes kirjutas:
+> >>> see https://blog.mozilla.com/blog/2012/01/10/delivering-a-mozilla-firefox-
+> >>> extended-support-release/
+> >>> see https://wiki.mozilla.org/images/9/9d/Esr-release-overview.png
+> >>>
+> >>> ESR is a 1y extended supported release...
+> >>>
+> >>> looking at the image we'd be having supported versions for our 9month release
+> >>> schedule every time... we should totally use this release and not go towards
+> >>> FF11 for our release.
+> >>>
+> >>> We've been complaining about the too quick release schedule... this is our
+> >>> chance!
+> >>>
+> >>> ( i think if the FF maintainer wishes, he could also do backports of the
+> >>> regular releases... )
+> >>>
+> >>> i'm hoping everyone agrees? including FF maintainer?
+> >> I don't agree. But i'm not the maintainer.
+> >>
+> >> Why not?
+> >> * Since fx10 all non-binary extensions are compatible by default (so our
+> >> main problem goes away).
+> >> * fx10 in 6 months is dead old for users POV. Many unhappy users. Lower
+> >> popularity for Mageia. (Ubuntu AFAIK is going with fast schedule).
+> >> * We will miss too many new and cool features.
+> >> * When we release
+> >
+> > We could say the same about any other software. Firefox was an exception
+> > on updates policy because there was no other choice. But there's no
+> > reason to keep it as an exception when they provide a supported version.
+> >
+> 
+> With 12 months support more often than not it would need updating in the 
+> lifespan of the Mageia 9 month release anyway.
+> 
+> Firefox is one of those programs that people like to be bang up to date 
+> with. 
+
+All softwares are one of those programs. The only one that some non
+technical users do not want to be updated are those that they do not
+know, like glibc, python, perl. But still, there is people that want it
+up to date, so firefox is nothing special. 
+
+> It is 'bragging rights' to ship with the latest and something 
+> reviewers always give version numbers of along with libreoffice, kde, gnome.
+
+Sure, and we neither update libreoffice, kde, gnome or the linux kernel.
+Some people do ( kde is upated by Fedora, as well as the linux kernel ).
+So that's a consistency issue, about what we promise to users. 
+
+Stability is just that, stuff that do not have interface changes every 6
+weeks, stuff that do not have slight mistranslation everytime string
+change, stuff that do not risk breaking software after every updates.
+
+> I understand the arguments to go with the 12 months support but I think 
+> for the reasons above we should stick with the normal release cycle or 
+> maybe even offer both?
+
+Offering both would mean to double our workload of supporting firefox,
+and have no advantages by using the long supported release. 
+
+And that's rather useless from my point of view, if the goal is to
+reduce the workload. There is already enough work to support the
+distribution.
+
+
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011331.html b/zarb-ml/mageia-dev/2012-January/011331.html new file mode 100644 index 000000000..d93e4386f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011331.html @@ -0,0 +1,164 @@ + + + + [Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases + + + + + + + + + +

[Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases

+ Claire Robinson + eeeemail at gmail.com +
+ Fri Jan 13 12:45:00 CET 2012 +

+
+ +
On 13/01/12 11:37, Michael Scherer wrote:
+> Le vendredi 13 janvier 2012 à 11:21 +0000, Claire Robinson a écrit :
+>> On 13/01/12 09:36, nicolas vigier wrote:
+>>> On Fri, 13 Jan 2012, Sander Lepik wrote:
+>>>
+>>>> 13.01.2012 03:20, Maarten Vanraes kirjutas:
+>>>>> see https://blog.mozilla.com/blog/2012/01/10/delivering-a-mozilla-firefox-
+>>>>> extended-support-release/
+>>>>> see https://wiki.mozilla.org/images/9/9d/Esr-release-overview.png
+>>>>>
+>>>>> ESR is a 1y extended supported release...
+>>>>>
+>>>>> looking at the image we'd be having supported versions for our 9month release
+>>>>> schedule every time... we should totally use this release and not go towards
+>>>>> FF11 for our release.
+>>>>>
+>>>>> We've been complaining about the too quick release schedule... this is our
+>>>>> chance!
+>>>>>
+>>>>> ( i think if the FF maintainer wishes, he could also do backports of the
+>>>>> regular releases... )
+>>>>>
+>>>>> i'm hoping everyone agrees? including FF maintainer?
+>>>> I don't agree. But i'm not the maintainer.
+>>>>
+>>>> Why not?
+>>>> * Since fx10 all non-binary extensions are compatible by default (so our
+>>>> main problem goes away).
+>>>> * fx10 in 6 months is dead old for users POV. Many unhappy users. Lower
+>>>> popularity for Mageia. (Ubuntu AFAIK is going with fast schedule).
+>>>> * We will miss too many new and cool features.
+>>>> * When we release
+>>>
+>>> We could say the same about any other software. Firefox was an exception
+>>> on updates policy because there was no other choice. But there's no
+>>> reason to keep it as an exception when they provide a supported version.
+>>>
+>>
+>> With 12 months support more often than not it would need updating in the
+>> lifespan of the Mageia 9 month release anyway.
+>>
+>> Firefox is one of those programs that people like to be bang up to date
+>> with.
+>
+> All softwares are one of those programs. The only one that some non
+> technical users do not want to be updated are those that they do not
+> know, like glibc, python, perl. But still, there is people that want it
+> up to date, so firefox is nothing special.
+>
+>> It is 'bragging rights' to ship with the latest and something
+>> reviewers always give version numbers of along with libreoffice, kde, gnome.
+>
+> Sure, and we neither update libreoffice, kde, gnome or the linux kernel.
+> Some people do ( kde is upated by Fedora, as well as the linux kernel ).
+> So that's a consistency issue, about what we promise to users.
+>
+> Stability is just that, stuff that do not have interface changes every 6
+> weeks, stuff that do not have slight mistranslation everytime string
+> change, stuff that do not risk breaking software after every updates.
+>
+>> I understand the arguments to go with the 12 months support but I think
+>> for the reasons above we should stick with the normal release cycle or
+>> maybe even offer both?
+>
+> Offering both would mean to double our workload of supporting firefox,
+> and have no advantages by using the long supported release.
+>
+> And that's rather useless from my point of view, if the goal is to
+> reduce the workload. There is already enough work to support the
+> distribution.
+
+My meaning was that it isn't just general software. As I said, it is one 
+of those packages that reviewers quote version numbers and users expect 
+to be updated.
+
+IMO we should be on the latest version but I really do understand the 
+arguments against it so I understand why you disagree :)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011332.html b/zarb-ml/mageia-dev/2012-January/011332.html new file mode 100644 index 000000000..8732559cb --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011332.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] "Hear, hear" usage + + + + + + + + + +

[Mageia-dev] "Hear, hear" usage

+ Christian Lohmaier + lohmaier+mageia at googlemail.com +
+ Fri Jan 13 13:35:28 CET 2012 +

+
+ +
Hi Oliver, *,
+
+On Fri, Jan 13, 2012 at 9:01 AM, Oliver Burger
+<oliver.bgr at googlemail.com> wrote:
+> Am Donnerstag, 12. Januar 2012, 22:43:54 schrieb Florian Hubold:
+>> > On 01/12/2012 04:17 PM, Johnny A. Solbu wrote:
+>> >> As far as I understand, that is a common British thing to do when one
+>> >> agree
+>> >> with the current speaker.
+
+Thanks for the explanation :-)
+
+>> Well, directly translating this phrase into german, it has another meaning.
+>> Used in colloquial language, it means something like ironically saying
+>> "well, look at that" or "enough with this nonsense" but also in the form
+>> Johnny used it.
+> You must have a different dirct translation than me. Directly translating it
+> into German makes no sense at all :D
+
+It does make sense, as the exact same phrase "Hört, hört" exists in
+German - but just like Florian I know the double-meaning that can both
+mean full approval (as the English meaning), but is also used as "look
+at that guy, he is deconstructing his own argumentation/he is making a
+fool of himself/the topic".
+The double-meaning probably is depending on geographical region. (like
+for example "Matz" in regional dialect - I know it as a (positive)
+term for a self-confident, boldfaced/fresh/cheeky girl, while just
+50km westwards it is a rather harsh curse word for a "mean/angry
+bitch")
+
+> But you should never translate anything directly between languages...
+
+Sure - but if you don't understand a phrase/saying, all you can do is
+to directly translate it and see whether you can make sense of it. In
+this case it was ambiguous (at least for me), as the tone of the
+voice, the other sources of information were missing.
+It's like the phrase "Der Lehrer sagt mein Vater ist ein Esel" -
+without the missing punctuation this sentence can have two rather
+different meanings. No problem when you hear it, but when you read it
+like that you can only guess who called whom a donkey.
+
+And that was my point - what works perfectly fine in real life, in
+direct interaction - might not work as well when you only have text
+written on screen - so thanks again for clearing up the dust from this
+expression :-)
+
+ciao
+Christian
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011333.html b/zarb-ml/mageia-dev/2012-January/011333.html new file mode 100644 index 000000000..60ad57acb --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011333.html @@ -0,0 +1,126 @@ + + + + [Mageia-dev] Existing Cauldron VM users willing to test gnome-boxes? + + + + + + + + + +

[Mageia-dev] Existing Cauldron VM users willing to test gnome-boxes?

+ Buchan Milne + bgmilne at zarb.org +
+ Fri Jan 13 14:09:21 CET 2012 +

+
+ +
On Friday, 13 January 2012 11:47:39 Olav Vitters wrote:
+> On Thu, Jan 12, 2012 at 06:14:46PM -0500, Scott Chevalley wrote:
+> > I'm using KVM for a windows 7 vm and I just tried to use gnome-boxes to
+> > create, I guess, a vm for a drbl live cd and it created it but when I
+> > launch it the app just shows a black screen and doesn't do anything.
+> 
+> Thanks for testing!
+> 
+> I'm getting the same black screen.
+
+Have you tried connecting with spicec ?
+
+> So it seems it doesn't work anyone :-(
+> 
+> Did you launch it from the terminal? Any debug output?
+> 
+> > There's not much documentation so I'm not sure exactly what's supposed to
+> > happen versus what is happening.
+> 
+> You should be seeing the VM. It uses something new called 'splice'. I
+> think that is where the error lies. The Fedora version of qemu 0.15 had
+> some patches which they dropped in qemu 1.0. I'm hoping qemu 1.0 solves
+> the issues, but wasn't able to compile it yesterday.
+> 
+> "Splice" is pretty nice as you can e.g. share your USB somehow between
+> the host and the VM (gnome-boxes has a checkbox, but no clue about the
+> technical details).
+
+I think you mean 'spice', which is a remote desktop protocol, which covers 
+display, sound, device sharing, printing etc. (AFAIU).
+
+I am more interested in the spice support in the libvirt/virt-manager tools 
+... but I am not running cauldron.
+
+> > I'll be happy to do some more testing if you can give me some pointers as
+> > to what I'm looking for.
+> 
+> The debug output from the terminal would be nice, as well as
+> $HOME/.libvirt/qemu/log/*.
+> 
+> I really want to get this working before the next Mageia testversion is
+> released..
+
+I would like to see virt-manager with spice support, and support in the 
+distribution for spice when a VM under qemu with spice support (spice-vdagent 
+stuff).
+
+Regards,
+Buchan
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011334.html b/zarb-ml/mageia-dev/2012-January/011334.html new file mode 100644 index 000000000..2badc5d11 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011334.html @@ -0,0 +1,178 @@ + + + + [Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases + + + + + + + + + +

[Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases

+ Chris Evans + z3r0_k00l75 at yahoo.com +
+ Fri Jan 13 14:13:58 CET 2012 +

+
+ +
+
+
+
+________________________________
+ From: Claire Robinson <eeeemail at gmail.com>
+To: mageia-dev at mageia.org 
+Sent: Friday, January 13, 2012 6:45 AM
+Subject: Re: [Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases
+ 
+On 13/01/12 11:37, Michael Scherer wrote:
+> Le vendredi 13 janvier 2012 à 11:21 +0000, Claire Robinson a écrit :
+>> On 13/01/12 09:36, nicolas vigier wrote:
+>>> On Fri, 13 Jan 2012, Sander Lepik wrote:
+>>>
+>>>> 13.01.2012 03:20, Maarten Vanraes kirjutas:
+>>>>> see https://blog.mozilla.com/blog/2012/01/10/delivering-a-mozilla-firefox-
+>>>>> extended-support-release/
+>>>>> see https://wiki.mozilla.org/images/9/9d/Esr-release-overview.png
+>>>>>
+>>>>> ESR is a 1y extended supported release...
+>>>>>
+>>>>> looking at the image we'd be having supported versions for our 9month release
+>>>>> schedule every time... we should totally use this release and not go towards
+>>>>> FF11 for our release.
+>>>>>
+>>>>> We've been complaining about the too quick release schedule... this is our
+>>>>> chance!
+>>>>>
+>>>>> ( i think if the FF maintainer wishes, he could also do backports of the
+>>>>> regular releases... )
+>>>>>
+>>>>> i'm hoping everyone agrees? including FF maintainer?
+>>>> I don't agree. But i'm not the maintainer.
+>>>>
+>>>> Why not?
+>>>> * Since fx10 all non-binary extensions are compatible by default (so our
+>>>> main problem goes away).
+>>>> * fx10 in 6 months is dead old for users POV. Many unhappy users. Lower
+>>>> popularity for Mageia. (Ubuntu AFAIK is going with fast schedule).
+>>>> * We will miss too many new and cool features.
+>>>> * When we release
+>>>
+>>> We could say the same about any other software. Firefox was an exception
+>>> on updates policy because there was no other choice. But there's no
+>>> reason to keep it as an exception when they provide a supported version.
+>>>
+>>
+>> With 12 months support more often than not it would need updating in the
+>> lifespan of the Mageia 9 month release anyway.
+>>
+>> Firefox is one of those programs that people like to be bang up to date
+>> with.
+>
+> All softwares are one of those programs. The only one that some non
+> technical users do not want to be updated are those that they do not
+> know, like glibc, python, perl. But still, there is people that want it
+> up to date, so firefox is nothing special.
+>
+>> It is 'bragging rights' to ship with the latest and something
+>> reviewers always give version numbers of along with libreoffice, kde, gnome.
+>
+> Sure, and we neither update libreoffice, kde, gnome or the linux kernel.
+> Some people do ( kde is upated by Fedora, as well as the linux kernel ).
+> So that's a consistency issue, about what we promise to users.
+>
+> Stability is just that, stuff that do not have interface changes every 6
+> weeks, stuff that do not have slight mistranslation everytime string
+> change, stuff that do not risk breaking software after every updates.
+>
+>> I understand the arguments to go with the 12 months support but I think
+>> for the reasons above we should stick with the normal release cycle or
+>> maybe even offer both?
+>
+> Offering both would mean to double our workload of supporting firefox,
+> and have no advantages by using the long supported release.
+>
+> And that's rather useless from my point of view, if the goal is to
+> reduce the workload. There is already enough work to support the
+> distribution.
+
+My meaning was that it isn't just general software. As I said, it is one 
+of those packages that reviewers quote version numbers and users expect 
+to be updated.
+
+IMO we should be on the latest version but I really do understand the 
+arguments against it so I understand why you disagree :)
+
+This really doesn't make sense. The browser is our interface to the internet. I (as a user) feel a need to have the latest version of my browser complete with all security patches. I really couldn't care less if I have the latest gnome or kde. Surfing the net using a browser with known security issues bothers me. I think this is why so many people consider firefox to be an exception to the rule. Where most software that is older is considered to be more stable, when talking about a browser it is generally the opposite. It would be nice to at least give the users a choice, maybe have the LTR version as well as the latest release available. I have seen other distros provide chrome stable, testing, and unstable. Allowing the user to choose which version they are most comfortable with. 
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20120113/0247fcec/attachment-0001.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011335.html b/zarb-ml/mageia-dev/2012-January/011335.html new file mode 100644 index 000000000..b8b9fa459 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011335.html @@ -0,0 +1,206 @@ + + + + [Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases + + + + + + + + + +

[Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases

+ andre999 + andre999mga at laposte.net +
+ Fri Jan 13 14:27:51 CET 2012 +

+
+ +
Michael Scherer a écrit :
+> Le vendredi 13 janvier 2012 à 11:21 +0000, Claire Robinson a écrit :
+>    
+>> On 13/01/12 09:36, nicolas vigier wrote:
+>>      
+>>> On Fri, 13 Jan 2012, Sander Lepik wrote:
+>>>
+>>>        
+>>>> 13.01.2012 03:20, Maarten Vanraes kirjutas:
+>>>>          
+>>>>> see https://blog.mozilla.com/blog/2012/01/10/delivering-a-mozilla-firefox-
+>>>>> extended-support-release/
+>>>>> see https://wiki.mozilla.org/images/9/9d/Esr-release-overview.png
+>>>>>
+>>>>> ESR is a 1y extended supported release...
+>>>>>
+>>>>> looking at the image we'd be having supported versions for our 9month release
+>>>>> schedule every time... we should totally use this release and not go towards
+>>>>> FF11 for our release.
+>>>>>
+>>>>> We've been complaining about the too quick release schedule... this is our
+>>>>> chance!
+>>>>>
+>>>>> ( i think if the FF maintainer wishes, he could also do backports of the
+>>>>> regular releases... )
+>>>>>
+>>>>> i'm hoping everyone agrees? including FF maintainer?
+>>>>>            
+
+I'd say let's go for the long-term release, and let those wanting the 
+latest and greatest use the upstream version.
+
+1) Upstream will release probably at least a week before we could 
+release it as an update.  With a 6-week release cycle, we will always be 
+lagging.
+
+2) Mozilla (Firefox/Seamonkey/Thunderbird) is very conservative in their 
+requires, and their rpm for mdv (and thus mga) menus are well done, so 
+newer upstream versions are highly unlikely to have any problems on install.
+(Note that upstream Mozilla required libstdc++5 long after mdv had 
+migrated to libstdc++6 and had later dropped libstdc++5.)
+
+>>>> I don't agree. But i'm not the maintainer.
+>>>>
+>>>> Why not?
+>>>> * Since fx10 all non-binary extensions are compatible by default (so our
+>>>> main problem goes away).
+>>>> * fx10 in 6 months is dead old for users POV. Many unhappy users. Lower
+>>>> popularity for Mageia. (Ubuntu AFAIK is going with fast schedule).
+>>>> * We will miss too many new and cool features.
+>>>> * When we release
+>>>>          
+>>> We could say the same about any other software. Firefox was an exception
+>>> on updates policy because there was no other choice. But there's no
+>>> reason to keep it as an exception when they provide a supported version.
+>>>        
+
+Exactly.  The fewer such exceptions the better, where alternatives exist.
+
+>> With 12 months support more often than not it would need updating in the
+>> lifespan of the Mageia 9 month release anyway.
+>>      
+
+Sure, but not every 6 weeks whether there is a bug fix or not.
+On the average in the last few years, significant bug fixes in 
+Firefox/Seamonkey have been more like every 2 or 3 months.
+
+>> Firefox is one of those programs that people like to be bang up to date
+>> with.
+>>      
+> All softwares are one of those programs. The only one that some non
+> technical users do not want to be updated are those that they do not
+> know, like glibc, python, perl. But still, there is people that want it
+> up to date, so firefox is nothing special.
+>
+>    
+>> It is 'bragging rights' to ship with the latest and something
+>> reviewers always give version numbers of along with libreoffice, kde, gnome.
+>>      
+
+We will always be at least a week behind Firefox's latest release.
+So where do you think those really wanting the "latest and greatest" 
+will go ?
+
+> Sure, and we neither update libreoffice, kde, gnome or the linux kernel.
+> Some people do ( kde is upated by Fedora, as well as the linux kernel ).
+> So that's a consistency issue, about what we promise to users.
+>
+> Stability is just that, stuff that do not have interface changes every 6
+> weeks, stuff that do not have slight mistranslation everytime string
+> change, stuff that do not risk breaking software after every updates.
+>    
+
++1
+
+>> I understand the arguments to go with the 12 months support but I think
+>> for the reasons above we should stick with the normal release cycle or
+>> maybe even offer both?
+>>      
+> Offering both would mean to double our workload of supporting firefox,
+> and have no advantages by using the long supported release.
+>
+> And that's rather useless from my point of view, if the goal is to
+> reduce the workload. There is already enough work to support the
+> distribution.
+>    
+
+-- 
+
+André
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011336.html b/zarb-ml/mageia-dev/2012-January/011336.html new file mode 100644 index 000000000..5e919875a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011336.html @@ -0,0 +1,135 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ Christian Lohmaier + lohmaier+mageia at googlemail.com +
+ Fri Jan 13 14:36:03 CET 2012 +

+
+ +
On Fri, Jan 13, 2012 at 10:28 AM, andre999 <andre999mga at laposte.net> wrote:
+> Christian Lohmaier a écrit :
+>> On Thu, Jan 12, 2012 at 8:04 PM, Juan Luis Baptiste<juancho at mageia.org>
+>>  wrote:
+>>> On Thu, Jan 12, 2012 at 1:01 PM, Christian Lohmaier
+>>> <lohmaier+mageia at googlemail.com>  wrote:
+>>>> On Wed, Jan 11, 2012 at 10:09 PM, Juan Luis Baptiste<juancho at mageia.org>
+>>>>  wrote:
+>>>>
+>>>>> [..]
+> To make things entirely clear, the agreed base policy (in various meetings)
+> was that updates should contain no new features.  Thus in general, a
+> (verified) bug fix only release from upstream would qualify as an update.
+> This being subject to exceptions, which were later agreed on after much
+> discussion.
+
+Thanks - this is the first time this has been stated explicitly.
+
+> I don't really see the point of doing all this arguing about a wiki page
+> that doesn't completely accord with update policy.  We just have to fix the
+> wiki page.
+
+Well - if you don't bother whether your policies are correct, you
+should not bother to publish them in the first place but refer to
+"whatever was discussed on the mailinglists".
+Yes, you have to fix the wiki page. But judging from this discussion
+people did not know what really is correct. The arguing is not about
+the wiki-page, but about the policy that is reflected by that wiki
+page.
+
+You did now clarify the policy as it should be, and that is fine. But
+please understand that the written policy did reflect a completely
+different picture.
+
+>> Yes, but this then changes the policy drastically (for the better, so
+>> please change it)
+>
+> It is not that drastic a change.  The effect is essentially the same,
+
+No, It is a drastic change from what is written. It probably is no big
+difference compared to what people actually do today, but the policy
+is changed drastically by this change.
+
+> although it is of course much easier -- and generally safer -- to apply a
+> (verified) bug fix only release from upstream.
+> As stated above, and mentioned by others posting to this thread, the wiki
+> page does not accurately affect the policy.
+
+Well, you might have a different interpretation of this thread, but I
+see people strongly supporting the policy as is written on the wiki,
+so it is far from clear.
+
+>> And when I write "whatever is against the policy" - I'm referring to
+>> what is written in the wiki, not what people actually do.
+>
+> Policy is what was agreed on, and not any errors that may exist in what is
+> written in the wiki.  We have corrected many similar errors in the wiki.
+
+If things were so clear, than people could have written exactly what
+you did and not continue with this discussion for so long.
+
+> Calling your understanding of the policy "stupid" is not necessarily the
+> most diplomatic approach.
+
+Again: I did judge what is written in the wiki. When policies are
+published, I have no other choice than to assume that what is written
+reflects the policy that was discussed and decided upon.
+And while it might not be diplomatic, I for sure prefer people
+actually writing what they mean. I of course fully agree that just
+writing "foo sucks" without stating how foo could suck less is
+inappropriate/waste of time.
+
+But well - thanks for making a concrete statement of what the policy
+/actually/ is.
+
+ciao
+Christian
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011337.html b/zarb-ml/mageia-dev/2012-January/011337.html new file mode 100644 index 000000000..05809b3b5 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011337.html @@ -0,0 +1,147 @@ + + + + [Mageia-dev] Existing Cauldron VM users willing to test gnome-boxes? + + + + + + + + + +

[Mageia-dev] Existing Cauldron VM users willing to test gnome-boxes?

+ Olav Vitters + olav at vitters.nl +
+ Fri Jan 13 14:38:10 CET 2012 +

+
+ +
On Fri, Jan 13, 2012 at 03:09:21PM +0200, Buchan Milne wrote:
+> On Friday, 13 January 2012 11:47:39 Olav Vitters wrote:
+> > On Thu, Jan 12, 2012 at 06:14:46PM -0500, Scott Chevalley wrote:
+> > > I'm using KVM for a windows 7 vm and I just tried to use gnome-boxes to
+> > > create, I guess, a vm for a drbl live cd and it created it but when I
+> > > launch it the app just shows a black screen and doesn't do anything.
+> > 
+> > Thanks for testing!
+> > 
+> > I'm getting the same black screen.
+> 
+> Have you tried connecting with spicec ?
+
+I connected using the spice gtk client. Same black screen. So I guess it
+has to do with the server (qemu spice support). Fedora qemu package had
+a lot of spice patches, all merged in qemu 1.0. Upstream said it
+shouldn't be needed to apply the patches though (and I didn't).
+
+There was also some other spice client, maybe spicec, but that depended
+on yet another package (cegui or something), but an older version than
+what Cauldron had. Upstream said they'd replace it with a gtk version
+(which I already packaged), so I excluded the old client from the spice
+package.
+
+> > So it seems it doesn't work anyone :-(
+> > 
+> > Did you launch it from the terminal? Any debug output?
+> > 
+> > > There's not much documentation so I'm not sure exactly what's supposed to
+> > > happen versus what is happening.
+> > 
+> > You should be seeing the VM. It uses something new called 'splice'. I
+> > think that is where the error lies. The Fedora version of qemu 0.15 had
+> > some patches which they dropped in qemu 1.0. I'm hoping qemu 1.0 solves
+> > the issues, but wasn't able to compile it yesterday.
+> > 
+> > "Splice" is pretty nice as you can e.g. share your USB somehow between
+> > the host and the VM (gnome-boxes has a checkbox, but no clue about the
+> > technical details).
+> 
+> I think you mean 'spice', which is a remote desktop protocol, which covers 
+> display, sound, device sharing, printing etc. (AFAIU).
+
+Indeed :)
+
+> I am more interested in the spice support in the libvirt/virt-manager tools 
+> ... but I am not running cauldron.
+
+I think I changed libvirt to support spice, but not sure. I'm focussing
+on gnome-boxes and I had to package a lot of things to get it to
+actually run a VM. Virt-manager does work though (started Mageia 1 dvd
+in a VM).
+
+> > > I'll be happy to do some more testing if you can give me some pointers as
+> > > to what I'm looking for.
+> > 
+> > The debug output from the terminal would be nice, as well as
+> > $HOME/.libvirt/qemu/log/*.
+> > 
+> > I really want to get this working before the next Mageia testversion is
+> > released..
+> 
+> I would like to see virt-manager with spice support, and support in the 
+> distribution for spice when a VM under qemu with spice support (spice-vdagent 
+> stuff).
+
+Any pointers on how to add support in the distribution? I guess maybe I
+should try to make a VM in gnome-boxes and start a Fedora iso.
+
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011338.html b/zarb-ml/mageia-dev/2012-January/011338.html new file mode 100644 index 000000000..061cbf26d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011338.html @@ -0,0 +1,125 @@ + + + + [Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases + + + + + + + + + +

[Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases

+ Michael Scherer + misc at zarb.org +
+ Fri Jan 13 14:39:46 CET 2012 +

+
+ +
Le vendredi 13 janvier 2012 à 05:13 -0800, Chris Evans a écrit :
+
+
+> This really doesn't make sense. The browser is our interface to the 
+> internet. I (as a user) feel a need to have the latest version of my
+>  browser complete with all security patches. 
+
+What do you think that a long supported firefox be, if not a firefox
+with proper security patches ?
+
+And frankly, if Firefox is so important to people because, doesn't t
+warrant to be extra careful with it, and to not change it every day ?
+
+"that's important to me, so please risk breaking it every 6 week" is
+just non sense. And yet, that's basically what people seems to assume.
+
+> I really couldn't care less if I have the latest gnome or kde. Surfing
+> the net using a browser with known security issues bothers me. 
+
+Again, what do you think that Firefox ESR is ? 
+"let's distribute a tarball with know security holes" ?
+
+> I think this is why so many people consider firefox to be an exception
+> to the rule. Where most software that is older is considered to be
+> more stable, when talking about a browser it is generally the
+> opposite. It would be nice to at least give the users a choice, 
+
+There is already the choice. People can do the work themself, they can
+get the binary bundle from Mozilla, they can run cauldron.
+So please, stop using the choice argument when it doesn't correspond to
+reality.
+
+> maybe have the LTR version as well as the latest release available. I
+> have seen other distros provide chrome stable, testing, and unstable.
+> Allowing the user to choose which version they are most comfortable
+> with. 
+
+That's also a pain to have it updated every X weeks.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011339.html b/zarb-ml/mageia-dev/2012-January/011339.html new file mode 100644 index 000000000..5b4f04155 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011339.html @@ -0,0 +1,217 @@ + + + + [Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases + + + + + + + + + +

[Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases

+ andre999 + andre999mga at laposte.net +
+ Fri Jan 13 15:00:26 CET 2012 +

+
+ +
Chris Evans a écrit :
+>
+>
+> ------------------------------------------------------------------------
+> *From:* Claire Robinson <eeeemail at gmail.com>
+> *To:* mageia-dev at mageia.org
+> *Sent:* Friday, January 13, 2012 6:45 AM
+> *Subject:* Re: [Mageia-dev] FireFox ESR <= we should totally go for 
+> this wrt stable releases
+>
+> On 13/01/12 11:37, Michael Scherer wrote:
+> > Le vendredi 13 janvier 2012 à 11:21 +0000, Claire Robinson a écrit :
+> >> On 13/01/12 09:36, nicolas vigier wrote:
+> >>> On Fri, 13 Jan 2012, Sander Lepik wrote:
+> >>>
+> >>>> 13.01.2012 03:20, Maarten Vanraes kirjutas:
+> >>>>> see 
+> https://blog.mozilla.com/blog/2012/01/10/delivering-a-mozilla-firefox-
+> >>>>> extended-support-release/
+> >>>>> see https://wiki.mozilla.org/images/9/9d/Esr-release-overview.png
+> >>>>>
+> >>>>> ESR is a 1y extended supported release...
+> >>>>>
+> >>>>> looking at the image we'd be having supported versions for our 
+> 9month release
+> >>>>> schedule every time... we should totally use this release and 
+> not go towards
+> >>>>> FF11 for our release.
+> >>>>>
+> >>>>> We've been complaining about the too quick release schedule... 
+> this is our
+> >>>>> chance!
+> >>>>>
+> >>>>> ( i think if the FF maintainer wishes, he could also do 
+> backports of the
+> >>>>> regular releases... )
+> >>>>>
+> >>>>> i'm hoping everyone agrees? including FF maintainer?
+> >>>> I don't agree. But i'm not the maintainer.
+> >>>>
+> >>>> Why not?
+> >>>> * Since fx10 all non-binary extensions are compatible by default 
+> (so our
+> >>>> main problem goes away).
+> >>>> * fx10 in 6 months is dead old for users POV. Many unhappy users. 
+> Lower
+> >>>> popularity for Mageia. (Ubuntu AFAIK is going with fast schedule).
+> >>>> * We will miss too many new and cool features.
+> >>>> * When we release
+> >>>
+> >>> We could say the same about any other software. Firefox was an 
+> exception
+> >>> on updates policy because there was no other choice. But there's no
+> >>> reason to keep it as an exception when they provide a supported 
+> version.
+> >>>
+> >>
+> >> With 12 months support more often than not it would need updating 
+> in the
+> >> lifespan of the Mageia 9 month release anyway.
+> >>
+> >> Firefox is one of those programs that people like to be bang up to date
+> >> with.
+> >
+> > All softwares are one of those programs. The only one that some non
+> > technical users do not want to be updated are those that they do not
+> > know, like glibc, python, perl. But still, there is people that want it
+> > up to date, so firefox is nothing special.
+> >
+> >> It is 'bragging rights' to ship with the latest and something
+> >> reviewers always give version numbers of along with libreoffice, 
+> kde, gnome.
+> >
+> > Sure, and we neither update libreoffice, kde, gnome or the linux kernel.
+> > Some people do ( kde is upated by Fedora, as well as the linux kernel ).
+> > So that's a consistency issue, about what we promise to users.
+> >
+> > Stability is just that, stuff that do not have interface changes every 6
+> > weeks, stuff that do not have slight mistranslation everytime string
+> > change, stuff that do not risk breaking software after every updates.
+> >
+> >> I understand the arguments to go with the 12 months support but I think
+> >> for the reasons above we should stick with the normal release cycle or
+> >> maybe even offer both?
+> >
+> > Offering both would mean to double our workload of supporting firefox,
+> > and have no advantages by using the long supported release.
+> >
+> > And that's rather useless from my point of view, if the goal is to
+> > reduce the workload. There is already enough work to support the
+> > distribution.
+>
+> My meaning was that it isn't just general software. As I said, it is one
+> of those packages that reviewers quote version numbers and users expect
+> to be updated.
+>
+> IMO we should be on the latest version but I really do understand the
+> arguments against it so I understand why you disagree :)
+> ----(previous post)
+
+> This really doesn't make sense. The browser is our interface to the 
+> internet. I (as a user) feel a need to have the latest version of my 
+> browser complete with all security patches. I really couldn't care 
+> less if I have the latest gnome or kde. Surfing the net using a 
+> browser with known security issues bothers me. I think this is why so 
+> many people consider firefox to be an exception to the rule. Where 
+> most software that is older is considered to be more stable, when 
+> talking about a browser it is generally the opposite. It would be nice 
+> to at least give the users a choice, maybe have the LTR version as 
+> well as the latest release available. I have seen other distros 
+> provide chrome stable, testing, and unstable. Allowing the user to 
+> choose which version they are most comfortable with.
+
+Wait.
+A long-term release version is kept updated for bugs, particularly 
+security bugs, but doesn't add new features.
+Since it doesn't add new features, it is less likely to introduce new 
+bugs, and so would be more secure.
+(That is why, in case you haven't noticed, that Firefox has more 
+security issues than Seamonkey, which is one step behind Firefox in 
+adopting new features.)
+
+So if you want a stable, secure browser, prefer among Mozilla browsers 
+the Firefox long-term release, or for more stable, Seamonkey.
+
+For the minority of users who want the latest features, despite the 
+greater risk, like the cauldron of Mozilla, it is easy to download the 
+latest Firefox release, direct from upstream.  (It will be available 
+there at least a week sooner.)
+Upstream Firefox by default warns when the latest update is available.
+
+-- 
+André
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011340.html b/zarb-ml/mageia-dev/2012-January/011340.html new file mode 100644 index 000000000..bd56b5dd3 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011340.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] [changelog] [RPM] 1 core/updates_testing lives-1.4.9-1.mga1 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] 1 core/updates_testing lives-1.4.9-1.mga1

+ D.Morgan + dmorganec at gmail.com +
+ Fri Jan 13 15:05:21 CET 2012 +

+
+ +
On Fri, Jan 13, 2012 at 9:37 AM, Thierry Vignaud
+<thierry.vignaud at gmail.com> wrote:
+> On 13 January 2012 02:30, dams <buildsystem-daemon at mageia.org> wrote:
+>> dams <dams> 1.4.9-1.mga1:
+>> + Revision: 195501
+>> - Update BR to install libmjpegtools-devel instead of mjpegtools-devel
+>
+> why?
+
+Because in mageia 1 mjpegtools doesn't have a provide %name-devel
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011341.html b/zarb-ml/mageia-dev/2012-January/011341.html new file mode 100644 index 000000000..558d8514a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011341.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] Mageia 2 Alpha 3 available for tests + + + + + + + + + +

[Mageia-dev] Mageia 2 Alpha 3 available for tests

+ Manuel Hiebel + manuel at hiebel.eu +
+ Fri Jan 13 16:37:56 CET 2012 +

+
+ +
Le jeudi 12 janvier 2012 à 21:04 +0100, Anne nicolas a écrit :
+> Hi all
+> 
+> Mageia 2 Alpha 3 is now available for tests:
+> http://blog.mageia.org/en/2012/01/12/here-comes-mageia-2-alpha3/
+> 
+> Please note that only DVDs isos are available for now. Live CDs will
+> be uploaded next week, due to some issues with dracut migration.
+> 
+> Thanks for all the hard work and enjoy it!
+> 
+
+Hello, any news about the nonfree iso ? 
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011342.html b/zarb-ml/mageia-dev/2012-January/011342.html new file mode 100644 index 000000000..36de3fba5 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011342.html @@ -0,0 +1,83 @@ + + + + [Mageia-dev] Mageia 2 Alpha 3 available for tests + + + + + + + + + +

[Mageia-dev] Mageia 2 Alpha 3 available for tests

+ Pascal Terjan + pterjan at gmail.com +
+ Fri Jan 13 16:59:14 CET 2012 +

+
+ +
On Fri, Jan 13, 2012 at 15:37, Manuel Hiebel <manuel at hiebel.eu> wrote:
+> Hello, any news about the nonfree iso ?
+
+It is still non free, which means it was not released.
+
+(Sorry)
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011343.html b/zarb-ml/mageia-dev/2012-January/011343.html new file mode 100644 index 000000000..25f0b6457 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011343.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] [changelog] [RPM] 1 core/updates_testing lives-1.4.9-1.mga1 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] 1 core/updates_testing lives-1.4.9-1.mga1

+ Damien Lallement + mageia at damsweb.net +
+ Fri Jan 13 13:52:33 CET 2012 +

+
+ +
Le 13/01/2012 09:37, Thierry Vignaud a écrit :
+> On 13 January 2012 02:30, dams<buildsystem-daemon at mageia.org>  wrote:
+>> dams<dams>  1.4.9-1.mga1:
+>> + Revision: 195501
+>> - Update BR to install libmjpegtools-devel instead of mjpegtools-devel
+>
+> why?
+
+Because of: 
+http://pkgsubmit.mageia.org/uploads/failure/1/core/updates_testing/20120113010908.dams.valstar.28362/log/botcmd.1326417002.jonund.log
+-- 
+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/2012-January/011344.html b/zarb-ml/mageia-dev/2012-January/011344.html new file mode 100644 index 000000000..b1b9e9b67 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011344.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] [RFC] Moving various packages/codecs to tainted + + + + + + + + + +

[Mageia-dev] [RFC] Moving various packages/codecs to tainted

+ Maarten Vanraes + alien at rmail.be +
+ Fri Jan 13 19:49:35 CET 2012 +

+
+ +
Op donderdag 12 januari 2012 02:32:41 schreef Anssi Hannula:
+> On 11.01.2012 16:01, Pascal Terjan wrote:
+> > On Wed, Jan 11, 2012 at 12:56, Anssi Hannula <anssi at mageia.org> wrote:
+> >> On 10.01.2012 15:07, Pascal Terjan wrote:
+> >>> On Tue, Jan 10, 2012 at 03:20, Anssi Hannula <anssi at mageia.org> wrote:
+> >>>> The problem is that that "balance" was achieved by sticking packages
+> >>>> in PLF/main/contrib semi-randomly. For example, H.264 decoders and
+> >>>> MPEG-4 video encoders are in main/core, while e.g. AAC audio decoders
+> >>>> are in PLF/tainted. If one'd put them into an order, IMO H.264 and
+> >>>> MPEG-4 would be much more prominent and tainted candidates instead of
+> >>>> AAC decoding... Also, in e.g. MPEG-4 case we have encoders both in
+> >>>> core and in tainted, e.g. we have ffmpeg in core, but xvid in
+> >>>> tainted.
+> >>> 
+> >>> I agree we need rules, but "being covered with patents" does not make
+> >>> sense, as the patent owner may agree with using it in free software.
+> >>> I think something like "No actively enforced patent" in core would be
+> >>> good.
+> >> 
+> >> Possibly, but how do you define that, exactly?
+> >> 
+> >> Does a licensing program count as "enforcing" or do you mean something
+> >> else?
+> > 
+> > Yes, that's what I meant
+> 
+> So it doesn't change anything regarding my original post, since all the
+> codecs I talked about have licensing programs.
+
+A) either we move all those with licensing programs into tainted, and make 
+isos contain tainted (since all mirrors ship tainted as well...).
+
+B) we put only actively enforced patents into tainted and don't have tainted 
+on iso...
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011345.html b/zarb-ml/mageia-dev/2012-January/011345.html new file mode 100644 index 000000000..e874434d9 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011345.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] [changelog] [RPM] 1 core/updates_testing lives-1.4.9-1.mga1 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] 1 core/updates_testing lives-1.4.9-1.mga1

+ Florian Hubold + doktor5000 at arcor.de +
+ Fri Jan 13 20:07:08 CET 2012 +

+
+ +
Am 13.01.2012 15:05, schrieb D.Morgan:
+> On Fri, Jan 13, 2012 at 9:37 AM, Thierry Vignaud
+> <thierry.vignaud at gmail.com> wrote:
+>> On 13 January 2012 02:30, dams <buildsystem-daemon at mageia.org> wrote:
+>>> dams <dams> 1.4.9-1.mga1:
+>>> + Revision: 195501
+>>> - Update BR to install libmjpegtools-devel instead of mjpegtools-devel
+>> why?
+> Because in mageia 1 mjpegtools doesn't have a provide %name-devel
+>
+So we then use an incorrect non-arch-independent require?
+What about pkgconfig(mjpegtools) ?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011346.html b/zarb-ml/mageia-dev/2012-January/011346.html new file mode 100644 index 000000000..4cfef4e73 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011346.html @@ -0,0 +1,84 @@ + + + + [Mageia-dev] Mageia 2 Alpha 3 available for tests + + + + + + + + + +

[Mageia-dev] Mageia 2 Alpha 3 available for tests

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Fri Jan 13 20:29:53 CET 2012 +

+
+ +
2012/1/13 Pascal Terjan <pterjan at gmail.com>:
+> On Fri, Jan 13, 2012 at 15:37, Manuel Hiebel <manuel at hiebel.eu> wrote:
+>> Hello, any news about the nonfree iso ?
+>
+> It is still non free, which means it was not released.
+>
+It has to be tested further, but since tmb has quite enough on his
+plate with the LiveCDs right now, we should not forget it but wait
+another one or two weeks....
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011347.html b/zarb-ml/mageia-dev/2012-January/011347.html new file mode 100644 index 000000000..2f42b9872 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011347.html @@ -0,0 +1,126 @@ + + + + [Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases + + + + + + + + + +

[Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases

+ Jeff Robins + jeffrobinssae at gmail.com +
+ Fri Jan 13 20:59:19 CET 2012 +

+
+ +
On Fri, Jan 13, 2012 at 6:00 AM, andre999 <andre999mga at laposte.net> wrote:
+
+> Wait.
+> A long-term release version is kept updated for bugs, particularly
+> security bugs, but doesn't add new features.
+> Since it doesn't add new features, it is less likely to introduce new
+> bugs, and so would be more secure.
+> (That is why, in case you haven't noticed, that Firefox has more security
+> issues than Seamonkey, which is one step behind Firefox in adopting new
+> features.)
+>
+> So if you want a stable, secure browser, prefer among Mozilla browsers the
+> Firefox long-term release, or for more stable, Seamonkey.
+>
+> For the minority of users who want the latest features, despite the
+> greater risk, like the cauldron of Mozilla, it is easy to download the
+> latest Firefox release, direct from upstream.  (It will be available there
+> at least a week sooner.)
+> Upstream Firefox by default warns when the latest update is available.
+>
+> --
+> André
+>
+>
+I think André is entirely correct and the ESR should meet the requirements
+for a long-term Mageia.  The ESR will get all of the security updates, but
+not the new features so any argument about needing the latest to stay
+secure is invalid.  (
+http://www.anandtech.com/show/5378/mozilla-announces-firefox-extended-support-release
+)
+
+Also, the next upstream will be moving to quiet updates, unless Firefox
+hasn't been restarted in the last 12 hours.  So, users that want the latest
+can use the upstream and be automatically updated.
+(http://letsbytecode.com/general/10-firefox-will-be-updated-on-the-quiet/)
+
+My only concern is the difference in release times.  Mageia's is 9months
+and Mozilla is 1year.  Nine months from Mageia's 1st long-term release,
+Mozilla will still be on the same FF, and will update FF in the middle of
+the second Mageia long-term release.  This would create more work and a
+long-term Mageia, which will have a major component update during the
+long-term support period.
+
+--Jeff
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20120113/6db14fb3/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011348.html b/zarb-ml/mageia-dev/2012-January/011348.html new file mode 100644 index 000000000..fc0f3c3c1 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011348.html @@ -0,0 +1,127 @@ + + + + [Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases + + + + + + + + + +

[Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases

+ Maarten Vanraes + alien at rmail.be +
+ Fri Jan 13 22:20:12 CET 2012 +

+
+ +
Op vrijdag 13 januari 2012 20:59:19 schreef Jeff Robins:
+> On Fri, Jan 13, 2012 at 6:00 AM, andre999 <andre999mga at laposte.net> wrote:
+> > Wait.
+> > A long-term release version is kept updated for bugs, particularly
+> > security bugs, but doesn't add new features.
+> > Since it doesn't add new features, it is less likely to introduce new
+> > bugs, and so would be more secure.
+> > (That is why, in case you haven't noticed, that Firefox has more security
+> > issues than Seamonkey, which is one step behind Firefox in adopting new
+> > features.)
+> > 
+> > So if you want a stable, secure browser, prefer among Mozilla browsers
+> > the Firefox long-term release, or for more stable, Seamonkey.
+> > 
+> > For the minority of users who want the latest features, despite the
+> > greater risk, like the cauldron of Mozilla, it is easy to download the
+> > latest Firefox release, direct from upstream.  (It will be available
+> > there at least a week sooner.)
+> > Upstream Firefox by default warns when the latest update is available.
+> > 
+> > --
+> > André
+> 
+> I think André is entirely correct and the ESR should meet the requirements
+> for a long-term Mageia.  The ESR will get all of the security updates, but
+> not the new features so any argument about needing the latest to stay
+> secure is invalid.  (
+> http://www.anandtech.com/show/5378/mozilla-announces-firefox-extended-suppo
+> rt-release )
+> 
+> Also, the next upstream will be moving to quiet updates, unless Firefox
+> hasn't been restarted in the last 12 hours.  So, users that want the latest
+> can use the upstream and be automatically updated.
+> (http://letsbytecode.com/general/10-firefox-will-be-updated-on-the-quiet/)
+> 
+> My only concern is the difference in release times.  Mageia's is 9months
+> and Mozilla is 1year.  Nine months from Mageia's 1st long-term release,
+> Mozilla will still be on the same FF, and will update FF in the middle of
+> the second Mageia long-term release.  This would create more work and a
+> long-term Mageia, which will have a major component update during the
+> long-term support period.
+> 
+> --Jeff
+
+look at the picture for the support period, the 1y warranteed versions cross 
+over for 2 or 3 months
+
+so it's going to fit for as long as we have 9m release schedule
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011349.html b/zarb-ml/mageia-dev/2012-January/011349.html new file mode 100644 index 000000000..d10e8e28f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011349.html @@ -0,0 +1,89 @@ + + + + [Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases + + + + + + + + + +

[Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases

+ Sander Lepik + sander.lepik at eesti.ee +
+ Fri Jan 13 22:34:39 CET 2012 +

+
+ +
13.01.2012 23:20, Maarten Vanraes kirjutas:
+> look at the picture for the support period, the 1y warranteed versions cross
+> over for 2 or 3 months
+>
+> so it's going to fit for as long as we have 9m release schedule
+9m release schedule, but aren't we giving support for 18m?
+
+--
+Sander
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011350.html b/zarb-ml/mageia-dev/2012-January/011350.html new file mode 100644 index 000000000..67e7da70f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011350.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases + + + + + + + + + +

[Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases

+ Maarten Vanraes + alien at rmail.be +
+ Fri Jan 13 22:50:20 CET 2012 +

+
+ +
Op vrijdag 13 januari 2012 22:34:39 schreef Sander Lepik:
+> 13.01.2012 23:20, Maarten Vanraes kirjutas:
+> > look at the picture for the support period, the 1y warranteed versions
+> > cross over for 2 or 3 months
+> > 
+> > so it's going to fit for as long as we have 9m release schedule
+> 
+> 9m release schedule, but aren't we giving support for 18m?
+> 
+> --
+> Sander
+
+yes, but as maintainer told me: we do the same as we do now, just after 
+9months, instead of every month...
+
+just one big, instead of a lot of smaller ones
+
+plus, i think due to the merging time, we have more time to test the update 
+properly.
+
+i'm all for it, and for all people wanting to have the latest, i will not use 
+the new versions, i can guarantee that!
+
+not even for work and HTML5 related topics
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011351.html b/zarb-ml/mageia-dev/2012-January/011351.html new file mode 100644 index 000000000..b15b325d5 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011351.html @@ -0,0 +1,163 @@ + + + + [Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases + + + + + + + + + +

[Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases

+ Jeff Robins + jeffrobinssae at gmail.com +
+ Fri Jan 13 23:10:53 CET 2012 +

+
+ +
On Fri, Jan 13, 2012 at 1:20 PM, Maarten Vanraes <alien at rmail.be> wrote:
+
+> Op vrijdag 13 januari 2012 20:59:19 schreef Jeff Robins:
+> > On Fri, Jan 13, 2012 at 6:00 AM, andre999 <andre999mga at laposte.net>
+> wrote:
+> > > Wait.
+> > > A long-term release version is kept updated for bugs, particularly
+> > > security bugs, but doesn't add new features.
+> > > Since it doesn't add new features, it is less likely to introduce new
+> > > bugs, and so would be more secure.
+> > > (That is why, in case you haven't noticed, that Firefox has more
+> security
+> > > issues than Seamonkey, which is one step behind Firefox in adopting new
+> > > features.)
+> > >
+> > > So if you want a stable, secure browser, prefer among Mozilla browsers
+> > > the Firefox long-term release, or for more stable, Seamonkey.
+> > >
+> > > For the minority of users who want the latest features, despite the
+> > > greater risk, like the cauldron of Mozilla, it is easy to download the
+> > > latest Firefox release, direct from upstream.  (It will be available
+> > > there at least a week sooner.)
+> > > Upstream Firefox by default warns when the latest update is available.
+> > >
+> > > --
+> > > André
+> >
+> > I think André is entirely correct and the ESR should meet the
+> requirements
+> > for a long-term Mageia.  The ESR will get all of the security updates,
+> but
+> > not the new features so any argument about needing the latest to stay
+> > secure is invalid.  (
+> >
+> http://www.anandtech.com/show/5378/mozilla-announces-firefox-extended-suppo
+> > rt-release )
+> >
+> > Also, the next upstream will be moving to quiet updates, unless Firefox
+> > hasn't been restarted in the last 12 hours.  So, users that want the
+> latest
+> > can use the upstream and be automatically updated.
+> > (
+> http://letsbytecode.com/general/10-firefox-will-be-updated-on-the-quiet/)
+> >
+> > My only concern is the difference in release times.  Mageia's is 9months
+> > and Mozilla is 1year.  Nine months from Mageia's 1st long-term release,
+> > Mozilla will still be on the same FF, and will update FF in the middle of
+> > the second Mageia long-term release.  This would create more work and a
+> > long-term Mageia, which will have a major component update during the
+> > long-term support period.
+> >
+> > --Jeff
+>
+> look at the picture for the support period, the 1y warranteed versions
+> cross
+> over for 2 or 3 months
+>
+> so it's going to fit for as long as we have 9m release schedule
+>
+
+
+The 2-3 month overlap doesn't solve our problem.  Assuming that we both
+start on the same month of the same year, which we aren't, and call it
+January 2012:
+
+Jan 2012 (good):
+We do long-term 1 and Mozilla does ESR1.
+
+Sept 2012(good):
+We do long-term 2 and Mozilla has just released FF ESR2.
+
+June 2013(bad):
+We do long-term 3, but Mozilla won't release FF ESR3 until Sept 2013.  FF
+ESR2 is defunct as of Jan 2013. We only get 3 months of support on ESR2 for
+long-term 3.
+
+March 2014(good):
+We do long-term 4 and Mozilla released FF ESR3 in Sept.  We get support
+until Dec 2015, which is when we release long-term 5.
+
+--Jeff
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20120113/3c59db45/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011352.html b/zarb-ml/mageia-dev/2012-January/011352.html new file mode 100644 index 000000000..4df23fc73 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011352.html @@ -0,0 +1,206 @@ + + + + [Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases + + + + + + + + + +

[Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases

+ Maarten Vanraes + alien at rmail.be +
+ Fri Jan 13 23:58:16 CET 2012 +

+
+ +
Op vrijdag 13 januari 2012 23:10:53 schreef Jeff Robins:
+> On Fri, Jan 13, 2012 at 1:20 PM, Maarten Vanraes <alien at rmail.be> wrote:
+> > Op vrijdag 13 januari 2012 20:59:19 schreef Jeff Robins:
+> > > On Fri, Jan 13, 2012 at 6:00 AM, andre999 <andre999mga at laposte.net>
+> > 
+> > wrote:
+> > > > Wait.
+> > > > A long-term release version is kept updated for bugs, particularly
+> > > > security bugs, but doesn't add new features.
+> > > > Since it doesn't add new features, it is less likely to introduce new
+> > > > bugs, and so would be more secure.
+> > > > (That is why, in case you haven't noticed, that Firefox has more
+> > 
+> > security
+> > 
+> > > > issues than Seamonkey, which is one step behind Firefox in adopting
+> > > > new features.)
+> > > > 
+> > > > So if you want a stable, secure browser, prefer among Mozilla
+> > > > browsers the Firefox long-term release, or for more stable,
+> > > > Seamonkey.
+> > > > 
+> > > > For the minority of users who want the latest features, despite the
+> > > > greater risk, like the cauldron of Mozilla, it is easy to download
+> > > > the latest Firefox release, direct from upstream.  (It will be
+> > > > available there at least a week sooner.)
+> > > > Upstream Firefox by default warns when the latest update is
+> > > > available.
+> > > > 
+> > > > --
+> > > > André
+> > > 
+> > > I think André is entirely correct and the ESR should meet the
+> > 
+> > requirements
+> > 
+> > > for a long-term Mageia.  The ESR will get all of the security updates,
+> > 
+> > but
+> > 
+> > > not the new features so any argument about needing the latest to stay
+> > > secure is invalid.  (
+> > 
+> > http://www.anandtech.com/show/5378/mozilla-announces-firefox-extended-sup
+> > po
+> > 
+> > > rt-release )
+> > > 
+> > > Also, the next upstream will be moving to quiet updates, unless Firefox
+> > > hasn't been restarted in the last 12 hours.  So, users that want the
+> > 
+> > latest
+> > 
+> > > can use the upstream and be automatically updated.
+> > > (
+> > 
+> > http://letsbytecode.com/general/10-firefox-will-be-updated-on-the-quiet/)
+> > 
+> > > My only concern is the difference in release times.  Mageia's is
+> > > 9months and Mozilla is 1year.  Nine months from Mageia's 1st long-term
+> > > release, Mozilla will still be on the same FF, and will update FF in
+> > > the middle of the second Mageia long-term release.  This would create
+> > > more work and a long-term Mageia, which will have a major component
+> > > update during the long-term support period.
+> > > 
+> > > --Jeff
+> > 
+> > look at the picture for the support period, the 1y warranteed versions
+> > cross
+> > over for 2 or 3 months
+> > 
+> > so it's going to fit for as long as we have 9m release schedule
+> 
+> The 2-3 month overlap doesn't solve our problem.  Assuming that we both
+> start on the same month of the same year, which we aren't, and call it
+> January 2012:
+> 
+> Jan 2012 (good):
+> We do long-term 1 and Mozilla does ESR1.
+> 
+> Sept 2012(good):
+> We do long-term 2 and Mozilla has just released FF ESR2.
+> 
+> June 2013(bad):
+> We do long-term 3, but Mozilla won't release FF ESR3 until Sept 2013.  FF
+> ESR2 is defunct as of Jan 2013. We only get 3 months of support on ESR2 for
+> long-term 3.
+> 
+> March 2014(good):
+> We do long-term 4 and Mozilla released FF ESR3 in Sept.  We get support
+> until Dec 2015, which is when we release long-term 5.
+> 
+> --Jeff
+
+
+"your logic is flawed"
+
+
+we have version freeze and testing several months before release
+
+
+so, let's say mga2 ships with FF10.
+
+if mga2 is release june, mga3 would be march 2013, with FF17.
+
+mga4 would be released around dec 2013, with FF24
+mga5 would be released with FF33, etc..
+
+HOWEVER!
+
+mga1 continues support until at least release of mga3, and thus will also 
+carry FF10.
+
+mga2 has the same thing, when FF10 becomes EOL, mga2 will have to "update" to 
+FF17 as well... AND in advance of release of the new versions.
+
+but otoh, this is all speculation on the continuation of 9m release schedule, 
+and if it's strictly adhered or not, and if FF isn't going to deviate or 
+change...
+
+this is well enough in advance thinking imho, no need to think further than 
+this.
+
+first we should also note if WE ourselves need to have LTS versions and IF we 
+can support that... etc...
+
+in short, due to 3month overlap, the FF ERS cycle is 9m, just like mageia...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011353.html b/zarb-ml/mageia-dev/2012-January/011353.html new file mode 100644 index 000000000..35681519d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011353.html @@ -0,0 +1,115 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release gnome-mplayer-1.0.5-3.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release gnome-mplayer-1.0.5-3.mga2

+ JA Magallon + jamagallon at ono.com +
+ Sat Jan 14 01:10:13 CET 2012 +

+
+ +
On Fri, 13 Jan 2012 19:03:10 +0100 (CET)
+fwang <buildsystem-daemon at mageia.org> wrote:
+
+> Name        : gnome-mplayer                Relocations: (not relocatable)
+> Version     : 1.0.5                             Vendor: Mageia.Org
+> Release     : 3.mga2                        Build Date: Fri Jan 13 18:55:19 2012
+> Install Date: (not installed)               Build Host: ecosse
+> Group       : Video                         Source RPM: (none)
+> Size        : 1007661                          License: GPLv2+
+> Signature   : (none)
+> Packager    : fwang <fwang>
+> URL         : http://kdekorte.googlepages.com/gnomemplayer
+> Summary     : Simple GUI for MPlayer
+> Description :
+> GNOME MPlayer is a simple GUI for MPlayer. It is intended to be a
+> nice tight player and provide a simple and clean interface to
+> MPlayer. GNOME MPlayer has a rich API that is exposed via DBus.
+> Using DBus you can control a single or multiple instances of GNOME
+> MPlayer from a single command.
+> 
+> fwang <fwang> 1.0.5-3.mga2:
+> + Revision: 195758
+> - really disable gtk3
+> - disable nautilus ext, so that we do not need gtk3
+
+Why ? As its name says, it is a player for _GNOME_, and current Gnome
+in Mageia is based on GTK3.
+So, why ?
+(and I really don't know what does this imply..., but if it has to be run
+under KDE, let someone build kde-mplayer. this sounds like 'lets handicap
+it so it runs on every desktop'. Sorry if it is not the case...)
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011354.html b/zarb-ml/mageia-dev/2012-January/011354.html new file mode 100644 index 000000000..c22937359 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011354.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases + + + + + + + + + +

[Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases

+ Jeff Robins + jeffrobinssae at gmail.com +
+ Sat Jan 14 01:10:48 CET 2012 +

+
+ +
On Fri, Jan 13, 2012 at 2:58 PM, Maarten Vanraes <alien at rmail.be> wrote:
+
+>
+>
+> "your logic is flawed"
+>
+> Yes it was.
+
+When I read the text I was thinking of a new FF ESR every year, with an
+extra 2-3months of support, after the new one is released.  The graphic
+makes it pretty clear that it's a new FF ESR every 8-9months.  The sentence
+below is what caused my initial confusion:
+
+"The ESR will be updated to a new major version about once a year . . . "
+
+Sorry,
+
+Jeff
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20120113/5317a246/attachment-0001.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011355.html b/zarb-ml/mageia-dev/2012-January/011355.html new file mode 100644 index 000000000..1b3ba0449 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011355.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases + + + + + + + + + +

[Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases

+ Maarten Vanraes + alien at rmail.be +
+ Sat Jan 14 01:43:58 CET 2012 +

+
+ +
Op zaterdag 14 januari 2012 01:10:48 schreef Jeff Robins:
+> On Fri, Jan 13, 2012 at 2:58 PM, Maarten Vanraes <alien at rmail.be> wrote:
+> > "your logic is flawed"
+> > 
+> > Yes it was.
+> 
+> When I read the text I was thinking of a new FF ESR every year, with an
+> extra 2-3months of support, after the new one is released.  The graphic
+> makes it pretty clear that it's a new FF ESR every 8-9months.  The sentence
+> below is what caused my initial confusion:
+> 
+> "The ESR will be updated to a new major version about once a year . . . "
+> 
+> Sorry,
+> 
+> Jeff
+
+thanks for letting me be Spock :-D
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011356.html b/zarb-ml/mageia-dev/2012-January/011356.html new file mode 100644 index 000000000..c23e37f1e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011356.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases + + + + + + + + + +

[Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases

+ Jeff Robins + jeffrobinssae at gmail.com +
+ Sat Jan 14 02:03:49 CET 2012 +

+
+ +
On Fri, Jan 13, 2012 at 4:43 PM, Maarten Vanraes <alien at rmail.be> wrote:
+
+> Op zaterdag 14 januari 2012 01:10:48 schreef Jeff Robins:
+> > On Fri, Jan 13, 2012 at 2:58 PM, Maarten Vanraes <alien at rmail.be> wrote:
+> > > "your logic is flawed"
+> > >
+> > > Yes it was.
+> >
+> > When I read the text I was thinking of a new FF ESR every year, with an
+> > extra 2-3months of support, after the new one is released.  The graphic
+> > makes it pretty clear that it's a new FF ESR every 8-9months.  The
+> sentence
+> > below is what caused my initial confusion:
+> >
+> > "The ESR will be updated to a new major version about once a year . . . "
+> >
+> > Sorry,
+> >
+> > Jeff
+>
+> thanks for letting me be Spock :-D
+>
+Welcome
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20120113/942f3571/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011357.html b/zarb-ml/mageia-dev/2012-January/011357.html new file mode 100644 index 000000000..b3847f23f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011357.html @@ -0,0 +1,117 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release gnome-mplayer-1.0.5-3.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release gnome-mplayer-1.0.5-3.mga2

+ Funda Wang + fundawang at gmail.com +
+ Sat Jan 14 05:32:30 CET 2012 +

+
+ +
Well, we still have gecko-mediaplayer, which should be linked with
+gtk2. And I don't know whether it is possible a gtk2 plugin of gecko
+could involk a gtk3 app correctly.
+
+2012/1/14 JA Magallon <jamagallon at ono.com>:
+> On Fri, 13 Jan 2012 19:03:10 +0100 (CET)
+> fwang <buildsystem-daemon at mageia.org> wrote:
+>
+>> Name        : gnome-mplayer                Relocations: (not relocatable)
+>> Version     : 1.0.5                             Vendor: Mageia.Org
+>> Release     : 3.mga2                        Build Date: Fri Jan 13 18:55:19 2012
+>> Install Date: (not installed)               Build Host: ecosse
+>> Group       : Video                         Source RPM: (none)
+>> Size        : 1007661                          License: GPLv2+
+>> Signature   : (none)
+>> Packager    : fwang <fwang>
+>> URL         : http://kdekorte.googlepages.com/gnomemplayer
+>> Summary     : Simple GUI for MPlayer
+>> Description :
+>> GNOME MPlayer is a simple GUI for MPlayer. It is intended to be a
+>> nice tight player and provide a simple and clean interface to
+>> MPlayer. GNOME MPlayer has a rich API that is exposed via DBus.
+>> Using DBus you can control a single or multiple instances of GNOME
+>> MPlayer from a single command.
+>>
+>> fwang <fwang> 1.0.5-3.mga2:
+>> + Revision: 195758
+>> - really disable gtk3
+>> - disable nautilus ext, so that we do not need gtk3
+>
+> Why ? As its name says, it is a player for _GNOME_, and current Gnome
+> in Mageia is based on GTK3.
+> So, why ?
+> (and I really don't know what does this imply..., but if it has to be run
+> under KDE, let someone build kde-mplayer. this sounds like 'lets handicap
+> it so it runs on every desktop'. Sorry if it is not the case...)
+>
+>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011358.html b/zarb-ml/mageia-dev/2012-January/011358.html new file mode 100644 index 000000000..4e362ebe0 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011358.html @@ -0,0 +1,120 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release gnome-mplayer-1.0.5-3.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release gnome-mplayer-1.0.5-3.mga2

+ Funda Wang + fundawang at gmail.com +
+ Sat Jan 14 05:38:09 CET 2012 +

+
+ +
Mm... another problem is that gmtk currently does not build with gtk3 yet.
+
+2012/1/14 Funda Wang <fundawang at gmail.com>:
+> Well, we still have gecko-mediaplayer, which should be linked with
+> gtk2. And I don't know whether it is possible a gtk2 plugin of gecko
+> could involk a gtk3 app correctly.
+>
+> 2012/1/14 JA Magallon <jamagallon at ono.com>:
+>> On Fri, 13 Jan 2012 19:03:10 +0100 (CET)
+>> fwang <buildsystem-daemon at mageia.org> wrote:
+>>
+>>> Name        : gnome-mplayer                Relocations: (not relocatable)
+>>> Version     : 1.0.5                             Vendor: Mageia.Org
+>>> Release     : 3.mga2                        Build Date: Fri Jan 13 18:55:19 2012
+>>> Install Date: (not installed)               Build Host: ecosse
+>>> Group       : Video                         Source RPM: (none)
+>>> Size        : 1007661                          License: GPLv2+
+>>> Signature   : (none)
+>>> Packager    : fwang <fwang>
+>>> URL         : http://kdekorte.googlepages.com/gnomemplayer
+>>> Summary     : Simple GUI for MPlayer
+>>> Description :
+>>> GNOME MPlayer is a simple GUI for MPlayer. It is intended to be a
+>>> nice tight player and provide a simple and clean interface to
+>>> MPlayer. GNOME MPlayer has a rich API that is exposed via DBus.
+>>> Using DBus you can control a single or multiple instances of GNOME
+>>> MPlayer from a single command.
+>>>
+>>> fwang <fwang> 1.0.5-3.mga2:
+>>> + Revision: 195758
+>>> - really disable gtk3
+>>> - disable nautilus ext, so that we do not need gtk3
+>>
+>> Why ? As its name says, it is a player for _GNOME_, and current Gnome
+>> in Mageia is based on GTK3.
+>> So, why ?
+>> (and I really don't know what does this imply..., but if it has to be run
+>> under KDE, let someone build kde-mplayer. this sounds like 'lets handicap
+>> it so it runs on every desktop'. Sorry if it is not the case...)
+>>
+>>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011359.html b/zarb-ml/mageia-dev/2012-January/011359.html new file mode 100644 index 000000000..39ee9017a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011359.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] Working bug-buddy/abrt-like software? + + + + + + + + + +

[Mageia-dev] Working bug-buddy/abrt-like software?

+ Olav Vitters + olav at vitters.nl +
+ Sat Jan 14 11:05:28 CET 2012 +

+
+ +
In https://bugs.mageia.org/show_bug.cgi?id=4088, gnome-shell process
+crashes due to a bug in libcogl. I'm seeing the same on my machine.
+However, as this in gnome-shell, it is pretty difficult to catch this.
+
+I have ABRT installed, but it relies on yum.
+
+Bug-buddy wouldn't catch this, plus it is broken.
+
+Is there some Mageia software which catches these crashers and installs
+the debug symbols? Could also remove ABRT and hope that I get a coredump
+somewhere. That seems a bit nasty IMO.
+
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011360.html b/zarb-ml/mageia-dev/2012-January/011360.html new file mode 100644 index 000000000..a8d2d990b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011360.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] Working bug-buddy/abrt-like software? + + + + + + + + + +

[Mageia-dev] Working bug-buddy/abrt-like software?

+ Pascal Terjan + pterjan at gmail.com +
+ Sat Jan 14 14:15:21 CET 2012 +

+
+ +
On Sat, Jan 14, 2012 at 10:05, Olav Vitters <olav at vitters.nl> wrote:
+> In https://bugs.mageia.org/show_bug.cgi?id=4088, gnome-shell process
+> crashes due to a bug in libcogl. I'm seeing the same on my machine.
+> However, as this in gnome-shell, it is pretty difficult to catch this.
+>
+> I have ABRT installed, but it relies on yum.
+
+It seems to include patches we had made for Mandriva, adapted for
+Mageia, so I would expect it to work
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011361.html b/zarb-ml/mageia-dev/2012-January/011361.html new file mode 100644 index 000000000..67d0d7f95 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011361.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] Working bug-buddy/abrt-like software? + + + + + + + + + +

[Mageia-dev] Working bug-buddy/abrt-like software?

+ D.Morgan + dmorganec at gmail.com +
+ Sat Jan 14 16:19:15 CET 2012 +

+
+ +
On Sat, Jan 14, 2012 at 11:05 AM, Olav Vitters <olav at vitters.nl> wrote:
+> In https://bugs.mageia.org/show_bug.cgi?id=4088, gnome-shell process
+> crashes due to a bug in libcogl. I'm seeing the same on my machine.
+> However, as this in gnome-shell, it is pretty difficult to catch this.
+>
+> I have ABRT installed, but it relies on yum.
+>
+> Bug-buddy wouldn't catch this, plus it is broken.
+>
+> Is there some Mageia software which catches these crashers and installs
+> the debug symbols? Could also remove ABRT and hope that I get a coredump
+> somewhere. That seems a bit nasty IMO.
+>
+> --
+> Regards,
+> Olav
+
+strange, i tested it and it isntalled the needed rpms using rpm.
+
+I will take a look then ( i need to work to make it works with our
+bugzilla too )
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011362.html b/zarb-ml/mageia-dev/2012-January/011362.html new file mode 100644 index 000000000..55184899a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011362.html @@ -0,0 +1,185 @@ + + + + [Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu? + + + + + + + + + +

[Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?

+ Kamil Rytarowski + n54 at gmx.com +
+ Sat Jan 14 21:10:09 CET 2012 +

+
+ +
W dniu 14.11.2011 18:16, Michael Scherer pisze:
+> Le dimanche 13 novembre 2011 à 22:32 +0100, Kamil Rytarowski a écrit :
+>> On 13.11.2011 10:58, Michael Scherer wrote:
+>>> Le samedi 12 novembre 2011 à 21:11 +0100, Kamil Rytarowski a écrit :
+>>>> On 12.11.2011 20:20, Michael Scherer wrote:
+>>>>> Le samedi 12 novembre 2011 à 16:44 +0100, Kamil Rytarowski a écrit :
+>>>>>
+>>>>>> There is also one important patch missed in Mageia -
+>>>>>> http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00787.html it's
+>>>>>> dependency for the GNS3 simulator. OpenSUSE already includes it
+>>>>>> https://build.opensuse.org/package/files?package=qemu&project=openSUSE%3ATools
+>>>>>>
+>>>>>> If nobody is against I will do it and contact the maintainer (misc).
+>>>>> I prefer to wait on the stable release ( ie, no rc1 ).
+>>>>> We will wait on stable version of qemu.
+>>>> OK
+>>>>> And no patch unless it comes from upstream ( and even, I am not keen on
+>>>>> backporting feature, better wait for stable release ).
+>>>>>
+>>>> GNS3 is already in stable! This package is broken - no dynamips (=no
+>>>> router emulation at all...), no patched qemu (no virtualization support
+>>>> at all...) According to the developers and their online documentation
+>>>> for package maintainers http://forum.gns3.net/post11571.html UDP patched
+>>>> Qemu is dependency/very important.
+>>> The fact that someone pushed a broken package is not a good reason to
+>>> add patches to qemu.
+>> OK, but I don't understand this.
+>>
+>> Why to keep defunct packages (this could be at least "major+ issue"  on
+>> our bugzilla) in stable and don't even want to fix, ignore this academic
+>> software (with maybe overall 1 000 000* downloads and 100 000 regular
+>> users), and to support... the inadvisable opinion of Mageia around.. at
+>> least the GNS3 users.
+> Let me rephrase again. Everybody sooner or later think "that soft is
+> great, but why do not add just a small patch there". That's just one
+> patch, where is the problem ?
+>
+> The problem appear just after a few months, when the patch is still not
+> upstream, and that someone who do not know C, python whatever has to
+> take the software and maintain it. Or when someone who know how to
+> program lose time rediffing the patch instead of doing something more
+> useful. We face bugs that cannot be reproduced upstream, security
+> problem that could be added in non reviewed patch by devs. Fragmentation
+> in linux distributions are also caused by differents features, due to
+> patchs.
+>
+> All of this need to be avoided, and I think we have enough problems with
+> stuff that people do not want to take care of it to not add more burden,
+> be it under the form of a small patch. All big collections start by one
+> little stuff.
+>
+>
+>> * 799 968 Windows Downloads (just from the sourceforge mirrors) of the
+>> latest Windows binary of GNS3 (source
+>> http://sourceforge.net/projects/gns-3/files/GNS3/0.7.4/)
+>>
+>>> We have too many patches on a general scale, and I
+>>> do not want to end with a 2nd package like gdb.
+>>>
+>>> Patches make harder to upgrade, harder to make sure security is done
+>>> correctly, and harder to ensure stuff are working ( since we are on our
+>>> own when we patch something ).
+>>> So for the patches, make sure it is upstream
+>> It's not qemu upstream, it's GNS3 and its community upstream.
+> If you want to have a feature in qemu, the road is "push it upstream".
+> Once accepted upstream, it will sooner or later be in our packages.
+>
+>>>    ( and given the discussion
+>>> on ml, it should be soon )
+>> When I ask the developers, they don't know if qemu will include the
+>> patch at all and when (now or after one year) and they suggested to do
+>> the openSUSE way (today the most recommended and full featured Linux
+>> distro for GNS3).
+> Maybe we are not talking of the same patch, but I am talking of this
+> one :
+> http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00629.html
+>
+> AFAIK, the patch have been accepted, just not committed yet. The last
+> mail were from 1 week ago. The only issue is that they are in freeze for
+> now, and the git web interface is down, and I do see the commit in my
+> checkout about it so far.
+>
+>>> and then in a tarball ( again, given that's a
+>>> rc 1, that should be ok soon ).
+>>>
+>>>> We must fix the package and provide at least not so heavy broken ones...
+>>>>
+>>>> I've prepared new version of GNS3, included into svn dynamips and
+>>>> xdotool (this one suggested) - these I can maintain with my mentor, so I
+>>>> ask for patch qemu in stable versus UDP support.
+>>> Updates are not supposed to get new features,
+>> Well this is a special case - the bugfix provides the feature, or the
+>> feature provides the bugfix.
+> People will always tell "it is a special case". We can always say that
+> any feature is a bugfix, provided we say that the bug is "I cannot do
+> that".
+>
+>
+Hi!
+We have succeed to push the patch upstream 
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=0e0e7facc775e9bb020314f48751b3d09f316c8b 
+It took 2 months.. It will be shipped with the next version of Qemu so 
+no need to take care of the patch for next releases.
+Can I now patch the old Qemu in Mga1 to ship UDP support and therefore 
+be usable within GNS3? I will then fix GNS3 and its requirements too.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011363.html b/zarb-ml/mageia-dev/2012-January/011363.html new file mode 100644 index 000000000..f8176be2b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011363.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] Setting the clock during install + + + + + + + + + +

[Mageia-dev] Setting the clock during install

+ Pierre Jarillon + jarillon at abul.org +
+ Sat Jan 14 22:08:50 CET 2012 +

+
+ +
In MCC and during installation, the default time reference is pool.ntp.org 
+which is too wide. As the country has already been selected, it should be easy 
+to set the reference to XX.pool.ntp.org  with XX=country such as  
+fr.pool.ntp.org.
+
+-- 
+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/2012-January/011364.html b/zarb-ml/mageia-dev/2012-January/011364.html new file mode 100644 index 000000000..9287a4627 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011364.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] Setting the clock during install + + + + + + + + + +

[Mageia-dev] Setting the clock during install

+ Thomas Backlund + tmb at mageia.org +
+ Sat Jan 14 22:12:01 CET 2012 +

+
+ +
14.01.2012 23:08, Pierre Jarillon skrev:
+> In MCC and during installation, the default time reference is pool.ntp.org
+> which is too wide. As the country has already been selected, it should be easy
+> to set the reference to XX.pool.ntp.org  with XX=country such as
+> fr.pool.ntp.org.
+>
+
+It does exactly that if you during install select to activate ntp and 
+select region.
+
+--
+Thomas
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011365.html b/zarb-ml/mageia-dev/2012-January/011365.html new file mode 100644 index 000000000..ea142f027 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011365.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] Setting the clock during install + + + + + + + + + +

[Mageia-dev] Setting the clock during install

+ magnus + magnus.mud at googlemail.com +
+ Sat Jan 14 22:30:01 CET 2012 +

+
+ +
I think, Pierre means that after the first step chossing the timezone
+mcc should choose the right ntp-server.
+
+But that is for me a very small issue.
+In the moment Alpa3 forgets the ntp-settings and that is real bad.
+
+Magnus
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20120114/d3d20279/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011366.html b/zarb-ml/mageia-dev/2012-January/011366.html new file mode 100644 index 000000000..bd12d5bd8 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011366.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] Chemnitz + + + + + + + + + +

[Mageia-dev] Chemnitz

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Sat Jan 14 22:43:24 CET 2012 +

+
+ +
Hi Magnus,
+
+habe eine vorläufige Zusage für Chemnitz erhalten. Ich muss die
+nächsten Tage die Daten vervollständigen, dann sollte die endgültige
+Zusage kommen.
+Als Standbetreuer habe ich mal uns beide angegeben.
+Ich kann jedoch noch zwei weitere eintragen.
+Ich werde auf jeden Fall Thorsten fragen. Sonst fällt mir aus dem
+direkten Mageia-Umfeld gerade niemand ein.
+
+Der Stand läuft momentan auf Mageia.Org. Wir können jedoch natürlich
+auch MandrivaUser.de vertreten. Ich wollte aber warten, was jetzt mit
+Mandriva passiert. Wenn die morgen tatsächlich in Konkurs gehen, macht
+das wohl wenig Sinn.
+
+Ich schick Dir gleich mal die Mail von den CLT weiter. Schau dann
+bitte auch mal in das Anmeldeformular rein und sag mir, ob das ok so
+ist...
+
+Oliver
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011367.html b/zarb-ml/mageia-dev/2012-January/011367.html new file mode 100644 index 000000000..e94e67130 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011367.html @@ -0,0 +1,84 @@ + + + + [Mageia-dev] Chemnitz + + + + + + + + + +

[Mageia-dev] Chemnitz

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Sat Jan 14 22:44:02 CET 2012 +

+
+ +
Sorry, wrong address!
+
+Just ignore that!
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011368.html b/zarb-ml/mageia-dev/2012-January/011368.html new file mode 100644 index 000000000..d7341d44b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011368.html @@ -0,0 +1,131 @@ + + + + [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia + + + + + + + + + +

[Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia

+ Luc Menut + lmenut at free.fr +
+ Sun Jan 15 00:31:14 CET 2012 +

+
+ +
Le 09/01/2012 01:07, Kamil Rytarowski a écrit :
+> W dniu 08.01.2012 22:04, Luc Menut pisze:
+>> Le 08/01/2012 21:18, Kamil Rytarowski a écrit :
+[...]
+>>
+>>> And I'm against some
+>>> special versioning for directories, we don't really need it.
+>>
+>> sorry but I don't agree with you here.
+>> e.g. in coming days, we will fix firefox (and other mozilla apps) to
+>> use hunspell-dictionaries; we will update the link to
+>> /usr/lib64/firefox-9.0.1/dictionaries -> /usr/share/hunspell
+>> and change the requires to hunspell-dictionary.
+>>
+>> but hunspell-dictionaries "old generation" (mga1) provide
+>> hunspell-dictionary, and install dictionaries only in /usr/share/myspell.
+> Just a technical note:
+> Old Hunspell dictionaries don't provide anything additional. They are
+> just dangling without any special integration with the system, please
+> take a look:
+> http://svnweb.mageia.org/packages/cauldron/hunspell-fr/current/SPECS/hunspell-fr.spec?revision=134361&view=markup
+>
+>
+> $ urpmq --provides hunspell-nl
+> hunspell-nl[== 2.00-2.mga1]
+
+oops, sorry, my bad,  I had in mind that mga1 hunspell dictionaries 
+already provided hunspell-dictionary.
+so it can work, we will be able to require hunspell-dictionary to ensure 
+that at least one hunspell dictionary "new generation" is installed.
+
+>
+> New Hunspell dictionaries obsolete&provide Myspell packages and come
+> into the Myspell place. They also install dictionaries into the same
+> place as the predecessor - this is why I put it into the place of the
+> old enchant-dictionary=2 place.
+>
+> Gentoo uses common packages for Myspell and Hunspell dictionaries. So
+> this is additional argument to put Hunspell in the place of Myspell.
+>> how do you plan to handle that the fixed firefox will absolutly need
+>> hunspell-dictionaries "new generation",
+> Fix Mozilla packages (in Mga2) to use new generation dictionaries in
+> /usr/share/hunspell
+
+and add Requires: hunspell-dictionary
+
+>> and can't work with hunspell-dictionaries "old generation" ?
+>>
+> Is there need for anything needed in addition of just higher
+> version&release of every new generation hunspell-dictionary in Mga2,
+> then the one in Mga1? In Mga2 every hunspell-dictionary will be in the
+> new generation version.
+>
+
+when we know that a package needs a specific version of a library, we 
+add it in the requires.
+e.g. rpm -q --requires firefox |grep "sqlite\|nspr\|nss"
+lib64sqlite3_0 >= 3.7.9
+lib64nss3 >= 2:3.13.1
+lib64nspr4 >= 2:4.8.9
+
+by analogy, I think that we should ensure that the needed dictionary's 
+package is installed.
+
+
+PS: the directory /usr/share/hunspell is currently owned by no package
+cf. urpmf "^/usr/share/hunspell$"
+the best candidate is probably hunspell.
+
+
+regards,
+Luc
+
+-- 
+Luc Menut
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011369.html b/zarb-ml/mageia-dev/2012-January/011369.html new file mode 100644 index 000000000..93d644b13 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011369.html @@ -0,0 +1,82 @@ + + + + [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia + + + + + + + + + +

[Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia

+ Luc Menut + lmenut at free.fr +
+ Sun Jan 15 00:52:50 CET 2012 +

+
+ +
Le 09/01/2012 13:05, Kamil Rytarowski a écrit :
+> W dniu 08.01.2012 20:01, Anssi Hannula pisze:
+[...]
+>> IMO a better way to handle this would be
+>> Provides:    mozilla-dictionary
+>> Provides:    hunspell-dictionary
+>> Provides:    myspell-dictionary
+>>
+>> based on which directories are contained in the package, since other
+>> packages are generally interested in whether the package provides
+>> dictionaries in a specific location. (i.e. a package using dictionaries
+>> in /usr/share/hunspell doesn't care if there are some extra dictionaries
+>> provided in other directories).
+> I like this idea!
+> Luc what do you think? Maybe we can consider the providing
+> "mozilla-dictionary" and then even install symlinks into a specific
+> directory like /usr/share/mozilla-dictionary ?
+
+Whatever the directory, we will need to modify mozilla packages, so I 
+think that we can|should directly use /usr/share/hunspell.
+Personnally, I don't see any interest to create a new directory 
+/usr/share/mozilla-dictionary, and to install other links in this directory.
+But I don't maintain any mozilla packages !!!
+
+
+-- 
+Luc Menut
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011370.html b/zarb-ml/mageia-dev/2012-January/011370.html new file mode 100644 index 000000000..034921ccf --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011370.html @@ -0,0 +1,112 @@ + + + + [Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases + + + + + + + + + +

[Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases

+ Luc Menut + lmenut at free.fr +
+ Sun Jan 15 01:43:41 CET 2012 +

+
+ +
Le 13/01/2012 02:22, D.Morgan a écrit :
+> On Fri, Jan 13, 2012 at 2:20 AM, Maarten Vanraes<alien at rmail.be>  wrote:
+>> see https://blog.mozilla.com/blog/2012/01/10/delivering-a-mozilla-firefox-
+>> extended-support-release/
+>> see https://wiki.mozilla.org/images/9/9d/Esr-release-overview.png
+>>
+>> ESR is a 1y extended supported release...
+>>
+>> looking at the image we'd be having supported versions for our 9month release
+>> schedule every time... we should totally use this release and not go towards
+>> FF11 for our release.
+>>
+>> We've been complaining about the too quick release schedule... this is our
+>> chance!
+>>
+>> ( i think if the FF maintainer wishes, he could also do backports of the
+>> regular releases... )
+>>
+>> i'm hoping everyone agrees? including FF maintainer?
+>
+>
+> seems we should stuck to FF 10 as default release for mageia2.
+>
+
+I don't have strong opinion about this choice.
+
+some various points that we should take into account:
+- I didn't find recent official announcement about ESR for other mozilla 
+applications (Thunderbird, Seamonkey/Iceape, ...); I think that we 
+should have consistent versions, at least for Firefox and Thunderbird.
+- mozilla updates without security fixes are uncommon, so we will not 
+reduce the number of update with ESR; the update will only have less 
+changes, so less risk of regressions.
+- If we don't choose Firefox ESR, we should at least consider using ESR 
+for xulrunner.
+
+-- 
+Luc Menut
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011371.html b/zarb-ml/mageia-dev/2012-January/011371.html new file mode 100644 index 000000000..fbe18ed64 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011371.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] Chemnitz + + + + + + + + + +

[Mageia-dev] Chemnitz

+ andre999 + andre999mga at laposte.net +
+ Sun Jan 15 02:43:33 CET 2012 +

+
+ +
Oliver Burger a écrit :
+> Sorry, wrong address!
+>
+> Just ignore that!
+>
+>    
+ok :-)
+
+-- 
+André
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011372.html b/zarb-ml/mageia-dev/2012-January/011372.html new file mode 100644 index 000000000..5b766900f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011372.html @@ -0,0 +1,136 @@ + + + + [Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases + + + + + + + + + +

[Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases

+ andre999 + andre999mga at laposte.net +
+ Sun Jan 15 03:10:31 CET 2012 +

+
+ +
Luc Menut a écrit :
+> Le 13/01/2012 02:22, D.Morgan a écrit :
+>> On Fri, Jan 13, 2012 at 2:20 AM, Maarten Vanraes<alien at rmail.be>  wrote:
+>>> see 
+>>> https://blog.mozilla.com/blog/2012/01/10/delivering-a-mozilla-firefox-
+>>> extended-support-release/
+>>> see https://wiki.mozilla.org/images/9/9d/Esr-release-overview.png
+>>>
+>>> ESR is a 1y extended supported release...
+>>>
+>>> looking at the image we'd be having supported versions for our 
+>>> 9month release
+>>> schedule every time... we should totally use this release and not go 
+>>> towards
+>>> FF11 for our release.
+>>>
+>>> We've been complaining about the too quick release schedule... this 
+>>> is our
+>>> chance!
+>>>
+>>> ( i think if the FF maintainer wishes, he could also do backports of 
+>>> the
+>>> regular releases... )
+>>>
+>>> i'm hoping everyone agrees? including FF maintainer?
+>>
+>>
+>> seems we should stuck to FF 10 as default release for mageia2.
+>>
+>
+> I don't have strong opinion about this choice.
+>
+> some various points that we should take into account:
+> - I didn't find recent official announcement about ESR for other 
+> mozilla applications (Thunderbird, Seamonkey/Iceape, ...); I think 
+> that we should have consistent versions, at least for Firefox and 
+> Thunderbird.
+
+I'm almost certain that Seamonkey, which is more conservative in 
+introducing new features than Firefox, will effectively have a long-term 
+release.
+Thunderbird is generally more conservative than Seamonkey, on the email 
+side.
+
+> - mozilla updates without security fixes are uncommon, so we will not 
+> reduce the number of update with ESR; the update will only have less 
+> changes, so less risk of regressions.
+
+We probably will reduce the number of updates as well.  Before this 
+frenetic pace of a new version every 6 weeks, Firefox often went 2 or 3 
+months without an update, when there had been no bugs with security 
+implications.  I expect that the ESR version would likely follow the 
+same practice.
+Even if not, in addition to less risk of regressions, no new features 
+should be easier to test.  (The same tests every time.)
+> - If we don't choose Firefox ESR, we should at least consider using 
+> ESR for xulrunner.
+>
+-- 
+
+André
+
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011373.html b/zarb-ml/mageia-dev/2012-January/011373.html new file mode 100644 index 000000000..5c13bba6b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011373.html @@ -0,0 +1,113 @@ + + + + [Mageia-dev] [RFC] Moving various packages/codecs to tainted + + + + + + + + + +

[Mageia-dev] [RFC] Moving various packages/codecs to tainted

+ Anssi Hannula + anssi at mageia.org +
+ Sun Jan 15 06:06:06 CET 2012 +

+
+ +
On 10.01.2012 05:20, Anssi Hannula wrote:
+> Linux Mint provides a "No codecs" CD:
+> http://www.linuxmint.com/download.php
+> 
+> Ubuntu has a patent policy (which basically IIRC says "rights owner or
+> packager, please contact us if you think there is an infringement, we
+> will investgate"):
+> https://wiki.ubuntu.com/PatentPolicy
+> 
+> Note also that the Ubuntu Live CD and therefore the default Ubuntu
+> installation do not contain any codecs. By default Totem is installed,
+> however, and gstreamer is plugged into "gnome-codec-install" (which
+> seems really nice, do we use it?), so that wen you try to play an
+> unsupported video the first time, it will prompt to install the codecs
+> (it will also show a warning dialog about patents etc, but AFAICS this
+> comes from gnome-codec-install itself, not Ubuntu).
+
+Well, gnome-codec-install is apt-specific, but it should be relatively
+easy to adapt it or use some other similar program (not codeina).
+
+I'll try to look at it when I can.
+
+What is left is to figure out how would this specifically work then:
+
+- Tainted by default, yes/no?
+- Option in the installer, yes/no?
+- How should the codec installer tool handle tainted-disabled case:
+  a) Can install the codec from the disabled repo (with a warning)
+  b) Asks the user if tainted should be enabled
+  c) Error out, asking the user to enable tainted
+  d) No handling, standard "codec not found" error
+  (note: a,b,c require some way for the tool to know what codecs exist
+   in tainted - for that we need one of:
+      x) search tainted repo automatically, like rpmdrake for backports
+      y) as (x) but ask user first ("do you want to search in foobar")
+      z) list of tainted codecs, e.g. in an pcitable-like
+         semi-automatically maintained file, or in website
+  )
+- What is the proper way for the user to update his packages to tainted
+  versions - rpmdrake only considers updates from the /updates
+  repositories, so the user would get the fully enabled version of
+  package X only when an update is provided for it?
+  (I'm talking about GUI, "urpmi --auto-update" works in a terminal)
+
+
+> If the user installs a video player depending on ffmpeg, e.g. VLC via
+> the software center, the codecs in ffmpeg will be pulled "normally",
+> i.e. silently.
+> 
+> Linux Mint had also gstreamer plugged to gnome-codec-install, so the
+> codecs will be installed if the user tries to play such a video with
+> totem (again with warnings).
+> 
+
+
+-- 
+Anssi Hannula
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011374.html b/zarb-ml/mageia-dev/2012-January/011374.html new file mode 100644 index 000000000..20e287b0c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011374.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] [packages-commits] [196358] changed R lib64wnch with %%{_lib}wnck3_0 + + + + + + + + + +

[Mageia-dev] [packages-commits] [196358] changed R lib64wnch with %%{_lib}wnck3_0

+ Jani Välimaa + jani.valimaa at gmail.com +
+ Sun Jan 15 10:15:55 CET 2012 +

+
+ +
2012/1/15  <root at mageia.org>:
+> Revision 196358 Author gil Date 2012-01-15 10:07:19 +0100 (Sun, 15 Jan 2012)
+>
+> Log Message
+>
+> changed R lib64wnch with %%{_lib}wnck3_0
+> used %%{python_sitelib}
+>
+
+Please read https://www.zarb.org/pipermail/mageia-dev/2011-December/010840.html
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011375.html b/zarb-ml/mageia-dev/2012-January/011375.html new file mode 100644 index 000000000..fed6d3742 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011375.html @@ -0,0 +1,66 @@ + + + + [Mageia-dev] Fosdem 2012 - Mageia stand + + + + + + + + + +

[Mageia-dev] Fosdem 2012 - Mageia stand

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Sun Jan 15 11:38:54 CET 2012 +

+
+ +
Calling again...
+
+Until now we have 19 people coming to FOSDEM but only 5 who have
+volunteered to help for some time at the stand.
+
+So, if you are coming to FOSDEM, please consider helping us there, so
+it won't be a few people having to stay there the whole day.
+
+Oliver
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011376.html b/zarb-ml/mageia-dev/2012-January/011376.html new file mode 100644 index 000000000..9c9ddfe0b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011376.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] RATHER URGENT: Restaurant reservation limit for FOSDEM Saturday Night (READ THIS, even if you're unsure yet) + + + + + + + + + +

[Mageia-dev] RATHER URGENT: Restaurant reservation limit for FOSDEM Saturday Night (READ THIS, even if you're unsure yet)

+ Maarten Vanraes + alien at rmail.be +
+ Sun Jan 15 12:14:32 CET 2012 +

+
+ +
Hello,
+
+me and eatdirt are looking into good restaurants for us to reserve for the 
+Saturday evening dinner.
+
+To facilitate us in this task, I would ask that everyone who _MAYBE_ will 
+come, to note yourself on the wiki page: 
+https://wiki.mageia.org/en/Fosdem_2012#Dinner_Saturday_night
+
+(also you can still help for stands, if you're up for it)
+
+NOTE: it's easier to reserve for X people and later tell restaurant there's 
+gonna be X-4 people. so IF there is a *chance* that you'll be there, _PLEASE_ 
+note yourself on the wiki.
+
+Thanks in advance & See you then,
+
+AL13N
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011377.html b/zarb-ml/mageia-dev/2012-January/011377.html new file mode 100644 index 000000000..3721554ed --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011377.html @@ -0,0 +1,81 @@ + + + + [Mageia-dev] Chemnitz + + + + + + + + + +

[Mageia-dev] Chemnitz

+ Florian Hubold + doktor5000 at arcor.de +
+ Sun Jan 15 16:52:45 CET 2012 +

+
+ +
Am 14.01.2012 22:44, schrieb Oliver Burger:
+> Sorry, wrong address!
+>
+> Just ignore that!
+>
+Damn autocompletion :)
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011378.html b/zarb-ml/mageia-dev/2012-January/011378.html new file mode 100644 index 000000000..de83ff1d9 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011378.html @@ -0,0 +1,83 @@ + + + + [Mageia-dev] Chemnitz + + + + + + + + + +

[Mageia-dev] Chemnitz

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Sun Jan 15 16:54:39 CET 2012 +

+
+ +
2012/1/14 Oliver Burger <oliver.bgr at googlemail.com>:
+> Sorry, wrong address!
+>
+> Just ignore that!
+
+Ok, ignored.
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011379.html b/zarb-ml/mageia-dev/2012-January/011379.html new file mode 100644 index 000000000..2e5027029 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011379.html @@ -0,0 +1,116 @@ + + + + [Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases + + + + + + + + + +

[Mageia-dev] FireFox ESR <= we should totally go for this wrt stable releases

+ Florian Hubold + doktor5000 at arcor.de +
+ Sun Jan 15 16:57:27 CET 2012 +

+
+ +
Am 15.01.2012 01:43, schrieb Luc Menut:
+> Le 13/01/2012 02:22, D.Morgan a écrit :
+>> On Fri, Jan 13, 2012 at 2:20 AM, Maarten Vanraes<alien at rmail.be>  wrote:
+>>> see https://blog.mozilla.com/blog/2012/01/10/delivering-a-mozilla-firefox-
+>>> extended-support-release/
+>>> see https://wiki.mozilla.org/images/9/9d/Esr-release-overview.png
+>>>
+>>> ESR is a 1y extended supported release...
+>>>
+>>> looking at the image we'd be having supported versions for our 9month release
+>>> schedule every time... we should totally use this release and not go towards
+>>> FF11 for our release.
+>>>
+>>> We've been complaining about the too quick release schedule... this is our
+>>> chance!
+>>>
+>>> ( i think if the FF maintainer wishes, he could also do backports of the
+>>> regular releases... )
+>>>
+>>> i'm hoping everyone agrees? including FF maintainer?
+>>
+>>
+>> seems we should stuck to FF 10 as default release for mageia2.
+>>
+>
+> I don't have strong opinion about this choice.
+>
+> some various points that we should take into account:
+> - I didn't find recent official announcement about ESR for other mozilla
+> applications (Thunderbird, Seamonkey/Iceape, ...); I think that we should
+> have consistent versions, at least for Firefox and Thunderbird.
+This is not the case currently, we have latest stable Firefox, but Thunderbird
+3.1 series
+for mga1 as long as they're supported upstream (cf
+http://www.mozilla.org/en-US/thunderbird/all-older.html )
+and for Seamonkey we have a totally out-of-date rebranding called iceape,
+which nobody seems interested in for stable release, with many
+open security issues (cf other thread: "[Mageia-dev] Seamonkey package")
+> - mozilla updates without security fixes are uncommon, so we will not reduce
+> the number of update with ESR; the update will only have less changes, so
+> less risk of regressions.
+> - If we don't choose Firefox ESR, we should at least consider using ESR for
+> xulrunner.
+>
+
+
+ + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011380.html b/zarb-ml/mageia-dev/2012-January/011380.html new file mode 100644 index 000000000..b9843f76b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011380.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] Sources of RPM + + + + + + + + + +

[Mageia-dev] Sources of RPM

+ Pierre Jarillon + jarillon at abul.org +
+ Sun Jan 15 17:20:44 CET 2012 +

+
+ +
When the sources of RPM are installed, about 40 sources of rpm are installed.
+
+Now, the choice is only Updates/All. Few people want this. 
+Beginners said that it is too complicated and are afraid.
+
+IMO, il is necessary to have an "advanced mode" which install all and a 
+standard mode which install (and select) Core, nonfree, tainted, their updates 
+and unselect the CD/DVD.
+
+-- 
+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/2012-January/011381.html b/zarb-ml/mageia-dev/2012-January/011381.html new file mode 100644 index 000000000..a0806e0df --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011381.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] 32bits i586 still useful in x86_64 ? + + + + + + + + + +

[Mageia-dev] 32bits i586 still useful in x86_64 ?

+ Pierre Jarillon + jarillon at abul.org +
+ Sun Jan 15 17:38:08 CET 2012 +

+
+ +
After an install of a x86_64 Mageia, open harddrake2 (in MCC).
+Then a pop-up asks.
+
+The following packages need to be installed:
+nspluginwrapper, libalsa-plugins-pulseaudio
+
+I the anwer is Yes, a great bunch of i586 rpm's are installed.
+
+Either, they are needed (work well without) and the question is no more 
+necessary, either these packages must be installed during the original 
+installation.
+
+-- 
+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/2012-January/011382.html b/zarb-ml/mageia-dev/2012-January/011382.html new file mode 100644 index 000000000..bf9e43c0f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011382.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] MCC-sound configuration + + + + + + + + + +

[Mageia-dev] MCC-sound configuration

+ Pierre Jarillon + jarillon at abul.org +
+ Sun Jan 15 18:09:03 CET 2012 +

+
+ +
In MCC, hardware, sound, the advanced option says how to repare the sound if 
+it does not work.
+
+But thes instructions are now outdated. For example
+- chkconfig is now replaced by systemd
+- aumix is not provided (aumix-text still exists)
+- pavucontrol and pulseaudio are ignored
+
+There is no tests to find which part is defective, inserting a sound in 
+different points in the chain.
+
+-- 
+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/2012-January/011383.html b/zarb-ml/mageia-dev/2012-January/011383.html new file mode 100644 index 000000000..97ccdbc63 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011383.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] 32bits i586 still useful in x86_64 ? + + + + + + + + + +

[Mageia-dev] 32bits i586 still useful in x86_64 ?

+ Maarten Vanraes + alien at rmail.be +
+ Sun Jan 15 20:50:59 CET 2012 +

+
+ +
Op zondag 15 januari 2012 17:38:08 schreef Pierre Jarillon:
+> After an install of a x86_64 Mageia, open harddrake2 (in MCC).
+> Then a pop-up asks.
+> 
+> The following packages need to be installed:
+> nspluginwrapper, libalsa-plugins-pulseaudio
+> 
+> I the anwer is Yes, a great bunch of i586 rpm's are installed.
+> 
+> Either, they are needed (work well without) and the question is no more
+> necessary, either these packages must be installed during the original
+> installation.
+
+yes, noarch packages are in i586 and some programs still use 32bit stuff
+
+like: wine
+
+it's designed to use 32bit windows apps, thus needing 32bit libraries and stuff
+
+and nspluginwrapper (but that may become unnecessary next release)
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011384.html b/zarb-ml/mageia-dev/2012-January/011384.html new file mode 100644 index 000000000..bc187b141 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011384.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] Sources of RPM + + + + + + + + + +

[Mageia-dev] Sources of RPM

+ Maarten Vanraes + alien at rmail.be +
+ Sun Jan 15 20:53:28 CET 2012 +

+
+ +
Op zondag 15 januari 2012 17:20:44 schreef Pierre Jarillon:
+> When the sources of RPM are installed, about 40 sources of rpm are
+> installed.
+> 
+> Now, the choice is only Updates/All. Few people want this.
+> Beginners said that it is too complicated and are afraid.
+> 
+> IMO, il is necessary to have an "advanced mode" which install all and a
+> standard mode which install (and select) Core, nonfree, tainted, their
+> updates and unselect the CD/DVD.
+
+i don't really understand you, about this.
+
+choice is update/all? i don't understand? what choice? in which program?
+
+about "advanced mode" in the MCC, media sources, you can select whichever you 
+want?
+
+also, if you have feature request, you can use the bugzilla too, and select 
+"new feature"
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011385.html b/zarb-ml/mageia-dev/2012-January/011385.html new file mode 100644 index 000000000..683cee2c5 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011385.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] MCC-sound configuration + + + + + + + + + +

[Mageia-dev] MCC-sound configuration

+ Maarten Vanraes + alien at rmail.be +
+ Sun Jan 15 20:55:12 CET 2012 +

+
+ +
Op zondag 15 januari 2012 18:09:03 schreef Pierre Jarillon:
+> In MCC, hardware, sound, the advanced option says how to repare the sound
+> if it does not work.
+> 
+> But thes instructions are now outdated. For example
+> - chkconfig is now replaced by systemd
+> - aumix is not provided (aumix-text still exists)
+> - pavucontrol and pulseaudio are ignored
+> 
+> There is no tests to find which part is defective, inserting a sound in
+> different points in the chain.
+
+ic you're using cauldron or the alpha
+
+can you please make a bugreport for this? this sounds important to be fixed.
+
+=> https://bugs.mageia.org/
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011386.html b/zarb-ml/mageia-dev/2012-January/011386.html new file mode 100644 index 000000000..8f584d5c7 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011386.html @@ -0,0 +1,84 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release meta-task-2-21.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release meta-task-2-21.mga2

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Sun Jan 15 22:02:46 CET 2012 +

+
+ +
On 15 January 2012 19:41, tmb <buildsystem-daemon at mageia.org> wrote:
+> tmb <tmb> 1:2-21.mga2:
+> + Revision: 196531
+> - prefer dracut over mkinitrd
+
+This is wrong, you're just introducing two different behaviors:
+- new installations will got drakcut & systemd
+- updated ones will keep mkinitrd & sysvinit
+
+That defeats the purpose of having mkinitrd & sysvinit as fallbacks...
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011387.html b/zarb-ml/mageia-dev/2012-January/011387.html new file mode 100644 index 000000000..e6568bfb5 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011387.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release meta-task-2-21.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release meta-task-2-21.mga2

+ Thomas Backlund + tmb at mageia.org +
+ Sun Jan 15 22:49:49 CET 2012 +

+
+ +
Thierry Vignaud skrev 15.1.2012 23:02:
+> On 15 January 2012 19:41, tmb<buildsystem-daemon at mageia.org>  wrote:
+>> tmb<tmb>  1:2-21.mga2:
+>> + Revision: 196531
+>> - prefer dracut over mkinitrd
+>
+> This is wrong, you're just introducing two different behaviors:
+> - new installations will got drakcut&  systemd
+> - updated ones will keep mkinitrd&  sysvinit
+
+How about enhancing urpmi to read prefer.vendor.list during distro
+upgrade? That would solve this issue.
+either by a specific --upgrade flag,
+or automatically when mageia-release-common bumps version, would that
+work ?
+
+Or maybe we should add systemd and dracut as suggests to basesystem ?
+(and not the hard requires on systemd...), that would pull them in.
+
+>
+> That defeats the purpose of having mkinitrd&  sysvinit as fallbacks...
+
+Umm.
+
+If both dracut and mkinitrd provides mkinitrd, the prefer list must
+contain the one we want by default, wich is what I did here.
+
+--
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011388.html b/zarb-ml/mageia-dev/2012-January/011388.html new file mode 100644 index 000000000..4f059a3a5 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011388.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] [RFC] Draft of a wiki page for systemd + + + + + + + + + +

[Mageia-dev] [RFC] Draft of a wiki page for systemd

+ D.Morgan + dmorganec at gmail.com +
+ Mon Jan 16 00:45:28 CET 2012 +

+
+ +
Hi,
+
+
+i started a wiki page about systemd migration.
+
+Please if you migrate a package using old sysvinit to systemd, Please
+add it on this page on the Array
+Please add packages that i could have forgotten on this page.
+
+
+thank you in advance.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011389.html b/zarb-ml/mageia-dev/2012-January/011389.html new file mode 100644 index 000000000..20a4fc75c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011389.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] [RFC] Draft of a wiki page for systemd + + + + + + + + + +

[Mageia-dev] [RFC] Draft of a wiki page for systemd

+ D.Morgan + dmorganec at gmail.com +
+ Mon Jan 16 08:58:16 CET 2012 +

+
+ +
On Mon, Jan 16, 2012 at 12:45 AM, D.Morgan <dmorganec at gmail.com> wrote:
+> Hi,
+>
+>
+> i started a wiki page about systemd migration.
+>
+> Please if you migrate a package using old sysvinit to systemd, Please
+> add it on this page on the Array
+> Please add packages that i could have forgotten on this page.
+>
+>
+> thank you in advance.
+
+which is here:   https://wiki.mageia.org/en/Features/Systemd
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011390.html b/zarb-ml/mageia-dev/2012-January/011390.html new file mode 100644 index 000000000..5227b9992 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011390.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release meta-task-2-21.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release meta-task-2-21.mga2

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Mon Jan 16 10:18:56 CET 2012 +

+
+ +
On 15 January 2012 22:49, Thomas Backlund <tmb at mageia.org> wrote:
+>> This is wrong, you're just introducing two different behaviors:
+>> - new installations will got drakcut&  systemd
+>> - updated ones will keep mkinitrd&  sysvinit
+>
+> How about enhancing urpmi to read prefer.vendor.list during distro
+> upgrade? That would solve this issue.
+> either by a specific --upgrade flag,
+> or automatically when mageia-release-common bumps version, would that
+> work ?
+
+This is already done. But prefer choice only apply to initial package
+installation.
+Once a package is installed, what matters are the package tags (provides,
+obsoletes, ...)
+
+> Or maybe we should add systemd and dracut as suggests to basesystem ?
+> (and not the hard requires on systemd...), that would pull them in.
+
+Hard requires are not an issue:
+- for systemd if systemd-sysvinit isn't hard required, which was
+already the case
+- for drakcut, as alternatives are used
+
+> If both dracut and mkinitrd provides mkinitrd, the prefer list must
+> contain the one we want by default, wich is what I did here.
+
+Yes but you also remove all of the obsolete/provides tag, which prevents drakcut
+to replace mkinitrd on upgrade.
+
+What needs to be carefully tested is to bump sysvinit/mkinitrd
+provides in systemd/drakcut
+and check upgrade.
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011391.html b/zarb-ml/mageia-dev/2012-January/011391.html new file mode 100644 index 000000000..3b8bbf857 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011391.html @@ -0,0 +1,139 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release meta-task-2-21.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release meta-task-2-21.mga2

+ Thomas Backlund + tmb at mageia.org +
+ Mon Jan 16 10:37:01 CET 2012 +

+
+ +
Thierry Vignaud skrev 16.1.2012 11:18:
+> On 15 January 2012 22:49, Thomas Backlund<tmb at mageia.org>  wrote:
+>>> This is wrong, you're just introducing two different behaviors:
+>>> - new installations will got drakcut&    systemd
+>>> - updated ones will keep mkinitrd&    sysvinit
+>>
+>> How about enhancing urpmi to read prefer.vendor.list during distro
+>> upgrade? That would solve this issue.
+>> either by a specific --upgrade flag,
+>> or automatically when mageia-release-common bumps version, would that
+>> work ?
+>
+> This is already done. But prefer choice only apply to initial package
+> installation.
+
+Which is why I asked if it should do it during upgrade too ?
+
+> Once a package is installed, what matters are the package tags (provides,
+> obsoletes, ...)
+>
+>> Or maybe we should add systemd and dracut as suggests to basesystem ?
+>> (and not the hard requires on systemd...), that would pull them in.
+>
+> Hard requires are not an issue:
+> - for systemd if systemd-sysvinit isn't hard required, which was
+> already the case
+
+Doh, I forgot about that it was sysvinit vs systemd-sysvinit and not 
+systemd itself :(
+
+so systemd can/must be readded as requires.
+
+> - for drakcut, as alternatives are used
+
+Yep. useful as long as there is a mkinitrd on the mirrors.
+
+>
+>> If both dracut and mkinitrd provides mkinitrd, the prefer list must
+>> contain the one we want by default, wich is what I did here.
+>
+> Yes but you also remove all of the obsolete/provides tag, which prevents drakcut
+> to replace mkinitrd on upgrade.
+>
+
+Check again. I only removed Obsoletes, the Provides is still there:
+http://svnweb.mageia.org/packages/cauldron/dracut/current/SPECS/dracut.spec?r1=194858&r2=196541
+
+But I guess I need to bump rel on provides to be mkinitrd rel + 1
+
+And maybe readd the obsoletes with current mkinitrd rel - 1
+That way mkinitrd will stay on the mirrors, but an automatic
+upgrade to dracut will happend from Mageia 1.
+
+> What needs to be carefully tested is to bump sysvinit/mkinitrd
+> provides in systemd/drakcut
+> and check upgrade.
+
+Yeah, systemd-sysvinit provides (and maybe possible obsoletes)
+need to be checked
+
+
+I will recheck the EVRs and fix the "mess"
+
+--
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011392.html b/zarb-ml/mageia-dev/2012-January/011392.html new file mode 100644 index 000000000..a638841e2 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011392.html @@ -0,0 +1,175 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release meta-task-2-21.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release meta-task-2-21.mga2

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Mon Jan 16 11:41:34 CET 2012 +

+
+ +
On 16 January 2012 10:37, Thomas Backlund <tmb at mageia.org> wrote:
+>>>> This is wrong, you're just introducing two different behaviors:
+>>>> - new installations will got drakcut&    systemd
+>>>> - updated ones will keep mkinitrd&    sysvinit
+>>>
+>>>
+>>> How about enhancing urpmi to read prefer.vendor.list during distro
+>>> upgrade? That would solve this issue.
+>>> either by a specific --upgrade flag,
+>>> or automatically when mageia-release-common bumps version, would that
+>>> work ?
+>>
+>>
+>> This is already done. But prefer choice only apply to initial package
+>> installation.
+>
+>
+> Which is why I asked if it should do it during upgrade too ?
+
+OK, there's obviously some confusion here.
+
+There's two different things:
+- preferred apps (read: what is the default choice when several packages
+  answer the some "virtual" require)
+- provides & obsolete tags
+
+That's totally orthogonal and preferred apps just don't apply to upgrading...
+If you install a package requesting eg "web_server" which would provided
+by say both apache & nginx, whatever you choose one manually or through
+automatically (preferred apps) doesn't change that after inital install, only
+provides & obsolete tags matter for upgrading.
+
+What's more, even if that was possible, what you're asking is basically
+replace "forcing systemd & drakcut through requires/obsoletes tags" by
+"forcing them through adding special urpmi code".
+Either way, you would force them...
+
+Anyway, urpmi's  preferred packages is not a super obsolete/require
+tags as explained above.
+
+>> Hard requires are not an issue:
+>> - for systemd if systemd-sysvinit isn't hard required, which was
+>> already the case
+>
+> Doh, I forgot about that it was sysvinit vs systemd-sysvinit and not systemd
+> itself :(
+>
+> so systemd can/must be readded as requires.
+
+Indeed.
+
+
+>> - for drakcut, as alternatives are used
+>
+>
+> Yep. useful as long as there is a mkinitrd on the mirrors.
+
+I think the clean way to go would be to:
+1) rename mkinitrd & sysvinit as mkinitrd-old & sysvinit-old:
+2) having both sysvinit-old & systemd-sysvinit provides/obsoletes sysvinit
+   (dito for mkinitrd-old & dracut)
+
+Then on upgrade, as mkinitrd & sysvinit would be obsoleted by new packages
+(eg: systemd-sysvinit & sysvini-old), urpmi would have to choose one,
+choosing dracut & systemd by default due to prefered list.
+Thus we would achieve both:
+- having dracut & systemd on upgrade too
+- being able to fallback to mkinitrd and/or sysvinit by manually requesting
+  their installation.
+
+Other ways would be to:
+1) have mkinitrd & sysvinit requesting drakcut & systemd-sysvinit
+& adding alternatives to systemd/sysvinit :-(
+
+2) manually adding greater provides to systemd-sysvinit & mkinitrd
+  (error prone & fallback involves manually editing skip.list which may
+  break further upgrading from mga2 to mga3 when mkinitrd & sysvinit
+  will be really dead)
+
+>>> If both dracut and mkinitrd provides mkinitrd, the prefer list must
+>>> contain the one we want by default, wich is what I did here.
+>>
+>>
+>> Yes but you also remove all of the obsolete/provides tag, which prevents
+>> drakcut
+>> to replace mkinitrd on upgrade.
+>>
+>
+> Check again. I only removed Obsoletes, the Provides is still there:
+> http://svnweb.mageia.org/packages/cauldron/dracut/current/SPECS/dracut.spec?r1=194858&r2=196541
+
+Which is useless w/o the obsolete tag.
+Have you checked what happens on upgrade? Does drakcut replace mkinitrd if some
+repo still has mkinitrd?
+Anyway it won't work for systemd as its provide tag is smaller in
+systemd-sysvinit than sysvinit
+
+And it's error prone.
+Also see above, fallbacking involves playing with skip.list which may
+break next upgrade
+(mga2 -> mga3)
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011393.html b/zarb-ml/mageia-dev/2012-January/011393.html new file mode 100644 index 000000000..136af7ecf --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011393.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] [RFC] Draft of a wiki page for systemd + + + + + + + + + +

[Mageia-dev] [RFC] Draft of a wiki page for systemd

+ Florian Hubold + doktor5000 at arcor.de +
+ Mon Jan 16 11:46:16 CET 2012 +

+
+ +
Am 16.01.2012 08:58, schrieb D.Morgan:
+> On Mon, Jan 16, 2012 at 12:45 AM, D.Morgan <dmorganec at gmail.com> wrote:
+>> Hi,
+>>
+>>
+>> i started a wiki page about systemd migration.
+>>
+>> Please if you migrate a package using old sysvinit to systemd, Please
+>> add it on this page on the Array
+>> Please add packages that i could have forgotten on this page.
+>>
+>>
+>> thank you in advance.
+> which is here:   https://wiki.mageia.org/en/Features/Systemd
+>
+Maybe it would also be helpful to others if someone
+could do a short writeup of what the actual migration to
+systemd consists of, or some things to pay attention to,
+instead of just a list of packages?
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011394.html b/zarb-ml/mageia-dev/2012-January/011394.html new file mode 100644 index 000000000..252656bff --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011394.html @@ -0,0 +1,121 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release meta-task-2-21.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release meta-task-2-21.mga2

+ Thomas Backlund + tmb at mageia.org +
+ Mon Jan 16 12:07:21 CET 2012 +

+
+ +
Thierry Vignaud skrev 16.1.2012 12:41:
+> On 16 January 2012 10:37, Thomas Backlund<tmb at mageia.org>  wrote:
+>> so systemd can/must be readded as requires.
+>
+> Indeed.
+>
+
+done in basesystem-2-5.mga2
+
+>>
+>> Check again. I only removed Obsoletes, the Provides is still there:
+>> http://svnweb.mageia.org/packages/cauldron/dracut/current/SPECS/dracut.spec?r1=194858&r2=196541
+>
+> Which is useless w/o the obsolete tag.
+
+Not really. It needs to be there to satisfy the kernel deps on mkinitrd
+
+> Have you checked what happens on upgrade? Does drakcut replace mkinitrd if some
+> repo still has mkinitrd?
+
+I will start testing this out sometime this week.
+
+But thinking more on it:
+I think the proper way to fix the upgrade is to switch kernel requires 
+to dracut instead of mkinitrd (as it will be done for Mga 3 anyway).
+
+That way we get dracut installed without removing mkinitrd, and
+alternatives would make us use dracut by default (but keeping the
+"failsafe").
+
+and when we start Mga3 development we let dracut obsolete mkinitrd/nash
+and remove it completely.
+
+> Anyway it won't work for systemd as its provide tag is smaller in
+> systemd-sysvinit than sysvinit
+>
+
+Fixed in systemd-38-4.mga2
+
+And dracut-014-15.mga2 has higher mkinitrd provides than real mkinitrd
+
+> And it's error prone.
+
+True.
+
+--
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011395.html b/zarb-ml/mageia-dev/2012-January/011395.html new file mode 100644 index 000000000..44ffc935e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011395.html @@ -0,0 +1,82 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release meta-task-2-21.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release meta-task-2-21.mga2

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Mon Jan 16 13:34:27 CET 2012 +

+
+ +
Le 16/01/2012 11:41, Thierry Vignaud a écrit :
+> - preferred apps (read: what is the default choice when several packages
+>    answer the some "virtual" require)
+when several packages provide the same virtual package.
+
+-- 
+BOFH excuse #263:
+
+It's stuck in the Web.
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011396.html b/zarb-ml/mageia-dev/2012-January/011396.html new file mode 100644 index 000000000..d5f032c7c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011396.html @@ -0,0 +1,84 @@ + + + + [Mageia-dev] mga1 tainted/updates has exact same x264 packages as mga1 tainted/release + + + + + + + + + +

[Mageia-dev] mga1 tainted/updates has exact same x264 packages as mga1 tainted/release

+ Florian Hubold + doktor5000 at arcor.de +
+ Mon Jan 16 14:46:52 CET 2012 +

+
+ +
Just stumbled upon the fact that mga1 tainted/updates carries the
+exact same x264 packages as mga1 tainted/release. As we had
+no x264 updates for mga1 so far (IIRC fwang only wanted to
+push new x264 when trying to update ffmpeg for mga1 to 0.7)
+can someone take a look how those packages got there and why?
+
+And shouldn't they be removed from tainted/updates?
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011397.html b/zarb-ml/mageia-dev/2012-January/011397.html new file mode 100644 index 000000000..0c700a754 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011397.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] mga1 tainted/updates has exact same x264 packages as mga1 tainted/release + + + + + + + + + +

[Mageia-dev] mga1 tainted/updates has exact same x264 packages as mga1 tainted/release

+ Florian Hubold + doktor5000 at arcor.de +
+ Mon Jan 16 14:51:53 CET 2012 +

+
+ +
Am 16.01.2012 14:46, schrieb Florian Hubold:
+> Just stumbled upon the fact that mga1 tainted/updates carries the
+> exact same x264 packages as mga1 tainted/release. As we had
+> no x264 updates for mga1 so far (IIRC fwang only wanted to
+> push new x264 when trying to update ffmpeg for mga1 to 0.7)
+> can someone take a look how those packages got there and why?
+>
+> And shouldn't they be removed from tainted/updates?
+>
+Sorry for the noise, probably due to hardlinking from release/
+to /updates because of added dependencies in updates,
+cf https://bugs.mageia.org/show_bug.cgi?id=2317
+
+So please don't remove them!
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011398.html b/zarb-ml/mageia-dev/2012-January/011398.html new file mode 100644 index 000000000..14d1a0f4e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011398.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] mga1 tainted/updates has exact same x264 packages as mga1 tainted/release + + + + + + + + + +

[Mageia-dev] mga1 tainted/updates has exact same x264 packages as mga1 tainted/release

+ Thomas Backlund + tmb at mageia.org +
+ Mon Jan 16 14:53:27 CET 2012 +

+
+ +
Florian Hubold skrev 16.1.2012 15:46:
+> Just stumbled upon the fact that mga1 tainted/updates carries the
+> exact same x264 packages as mga1 tainted/release. As we had
+> no x264 updates for mga1 so far (IIRC fwang only wanted to
+> push new x264 when trying to update ffmpeg for mga1 to 0.7)
+> can someone take a look how those packages got there and why?
+
+It's intended.
+
+It's a fallout of https://bugs.mageia.org/show_bug.cgi?id=2317
+
+MageiaUpdate only checks for deps in update media, so anytime a package
+in /updates requires something from /release we will hardlink it.
+
+
+>
+> And shouldn't they be removed from tainted/updates?
+
+
+Nope.
+
+But we must fix bug 2317 before Mageia 2 is out.
+
+--
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011399.html b/zarb-ml/mageia-dev/2012-January/011399.html new file mode 100644 index 000000000..8cf49e490 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011399.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] [RFC] Draft of a wiki page for systemd + + + + + + + + + +

[Mageia-dev] [RFC] Draft of a wiki page for systemd

+ D.Morgan + dmorganec at gmail.com +
+ Mon Jan 16 14:58:42 CET 2012 +

+
+ +
On Mon, Jan 16, 2012 at 11:46 AM, Florian Hubold <doktor5000 at arcor.de> wrote:
+> Am 16.01.2012 08:58, schrieb D.Morgan:
+>> On Mon, Jan 16, 2012 at 12:45 AM, D.Morgan <dmorganec at gmail.com> wrote:
+>>> Hi,
+>>>
+>>>
+>>> i started a wiki page about systemd migration.
+>>>
+>>> Please if you migrate a package using old sysvinit to systemd, Please
+>>> add it on this page on the Array
+>>> Please add packages that i could have forgotten on this page.
+>>>
+>>>
+>>> thank you in advance.
+>> which is here:   https://wiki.mageia.org/en/Features/Systemd
+>>
+> Maybe it would also be helpful to others if someone
+> could do a short writeup of what the actual migration to
+> systemd consists of, or some things to pay attention to,
+> instead of just a list of packages?
+
+this is planned too ( in fact this is a reason i used the word draft :) )
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011400.html b/zarb-ml/mageia-dev/2012-January/011400.html new file mode 100644 index 000000000..6ec36d967 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011400.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] Draft wiki page for gimp plugins + + + + + + + + + +

[Mageia-dev] Draft wiki page for gimp plugins

+ Matteo + pasotti.matteo at gmail.com +
+ Mon Jan 16 15:58:45 CET 2012 +

+
+ +
-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
+Hi all,
+I started this page https://wiki.mageia.org/en/Gimp_plugins due to needs
+connected with bug # 3077 (https://bugs.mageia.org/show_bug.cgi?id=3077).
+
+Regards
+- -- 
+Matteo
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.11 (GNU/Linux)
+Comment: Using GnuPG with Mageia - http://enigmail.mozdev.org/
+
+iQEcBAEBAgAGBQJPFDsiAAoJED3LowjDDWbNC5oH/2BFPhK/9e1ln9FVTPo8+nL7
+u5v8is/qZNOjvd1T7Oc61mjhWcy/nkNaVZKf2PElCbsQE5OUeasNy3D8atZ3C6jb
+ve6CQzUi5wtZ23578tS6LvC2TbQY/mn6BSURW+Y/JB1m+3Kcsb+cKAo7K+NVH9LD
+kaNceg4lCP5vPjdAb9awoFxDqryeGmCWL2Zui7AqWDUKoN/Bfn29TcKVqWrfYFi9
+RCizSNqSpIW5sa7sDz0aYKrbJjrvRhS03Pgi7hHuSag0F7zZE3UFdNF0nQL9Acho
+PIl6JVPpeU20+HF1ygx2hcRYYfZH2R03udB+Zb8Q+lT4RwhrTmbb2NdogBmdyJE=
+=mURi
+-----END PGP SIGNATURE-----
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011401.html b/zarb-ml/mageia-dev/2012-January/011401.html new file mode 100644 index 000000000..7d7b40473 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011401.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] task-gnome-minimal: depend on X somehow? + + + + + + + + + +

[Mageia-dev] task-gnome-minimal: depend on X somehow?

+ Olav Vitters + olav at vitters.nl +
+ Mon Jan 16 17:14:17 CET 2012 +

+
+ +
In https://bugs.mageia.org/show_bug.cgi?id=4138, the reporter did a
+minimal installation, then opted for task-gnome-minimal.
+
+This doesn't install X apparently.
+
+Should it? In case of a really minimal installation, it could be that
+you're using everything remotely.
+
+I could have task-gnome-minimal have:
+  Suggests: task-x11
+
+I'm hoping is enough for a working X.
+
+Opinions?
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011402.html b/zarb-ml/mageia-dev/2012-January/011402.html new file mode 100644 index 000000000..ee8161d5b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011402.html @@ -0,0 +1,74 @@ + + + + [Mageia-dev] Security updates needing testing (please help) + + + + + + + + + +

[Mageia-dev] Security updates needing testing (please help)

+ David Walser + luigiwalser at yahoo.com +
+ Mon Jan 16 20:17:45 CET 2012 +

+
+ +
The QA team is doing a great job getting things tested.  A lot of new packages have been pushed to updates_testing recently, so more help is 
+still welcome to clear it out.  Most of them are security updates.  Just to highlight some...
+
+> Needs testing on i586:
+https://bugs.mageia.org/show_bug.cgi?id=3956 networkmanager
+
+> Needs testing on x86_64:
+https://bugs.mageia.org/show_bug.cgi?id=2064 krb5-appl
+https://bugs.mageia.org/show_bug.cgi?id=4158 libxml2
+
+If anyone is curious about the status of the PHP update, it is being redone to update to 5.3.9.
+
+> Already tested, needs pushed by sysadmins:
+https://bugs.mageia.org/show_bug.cgi?id=3955 cyrus-imapd
+
+And a reminder from your friendly QA team that all update candidates can be viewed at:
+https://bugs.mageia.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=waiting%20for%20QA%20test&sharer_id=22
+
+
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011403.html b/zarb-ml/mageia-dev/2012-January/011403.html new file mode 100644 index 000000000..0a705d104 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011403.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] [changelog] [RPM] 1 core/updates_testing terminator-0.96-2.mga1 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] 1 core/updates_testing terminator-0.96-2.mga1

+ Jani Välimaa + jani.valimaa at gmail.com +
+ Mon Jan 16 20:43:05 CET 2012 +

+
+ +
2012/1/16 lebedov <buildsystem-daemon at mageia.org>:
+> Name        : terminator                   Relocations: (not relocatable)
+> Version     : 0.96                              Vendor: Mageia.Org
+> Release     : 2.mga1                        Build Date: Mon Jan 16 19:26:23 2012
+> Install Date: (not installed)               Build Host: jonund
+> Group       : Terminals                     Source RPM: (none)
+> Size        : 266173                           License: GPLv2
+> Signature   : (none)
+> Packager    : lebedov <lebedov>
+> URL         : http://www.tenshu.net/terminator/
+> Summary     : A simple way to run multiple terminals in a single window
+> Description :
+> Terminator is an attempt to maximise useful space on a given desktop
+> for terminals. It is a simple Python script that places multiple vte
+> widgets (the same used by gnome-terminal) in a window. That's the same
+> widget used by gnome-terminal.
+>
+> lebedov <lebedov> 0.96-2.mga1:
+> + Revision: 196966
+> - Require pygtk2.0 on installation (#3612).
+> - Update to 0.96.
+
+You should use subrel when pushing updates to stable release.
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011404.html b/zarb-ml/mageia-dev/2012-January/011404.html new file mode 100644 index 000000000..75b0bf10b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011404.html @@ -0,0 +1,137 @@ + + + + [Mageia-dev] Over-zealous rpmlint policy (rejecting rt) + + + + + + + + + +

[Mageia-dev] Over-zealous rpmlint policy (rejecting rt)

+ David Walser + luigiwalser at yahoo.com +
+ Mon Jan 16 20:55:55 CET 2012 +

+
+ +
Michael Scherer wrote:
+> Le jeudi 12 janvier 2012 à 11:12 +0200, Buchan Milne a écrit :
+>> I am trying to get rt (3.8.11) into the distro (a package that I am using on a 
+>> different distro in a production environment), to be followed up with the rt 
+>> (4.0.4) I have queued (which I am testing in preparation for upgrading our 
+>> production environment).
+>> 
+>> I would really like to get this package into the distro, but it is being 
+>> rejected 
+>> (http://pkgsubmit.mageia.org/uploads/rejected//cauldron/core/release/20120110140334.buchan.valstar.18287.youri) 
+>> due to:
+>> 
+>> Submission errors, aborting:
+>> - rt-3.8.11-1.mga2.noarch:
+>>  - dir-or-file-in-usr-local /usr/local/lib/rt/plugins
+>>  - dir-or-file-in-usr-local /usr/local/lib/rt
+>>  - dir-or-file-in-usr-local /usr/local/lib/rt/po
+>>  - dir-or-file-in-usr-local /usr/local/lib/rt/lib
+>>  - dir-or-file-in-usr-local /usr/local/etc/rt
+>>  - dir-or-file-in-usr-local /usr/local/lib/rt/html
+>> 
+>> The documented way for extending RT is by installing files in this location. 
+>> We can either:
+>> 1)Make it more difficult for users to extend RT with local plugins etc.
+>> 2)Fix rpmlint
+>> 3)Not have RT
+>> 
+>> misc, you have experience of both rt and rpmlint, can you provide an opinion?
+>>
+>> Would it be possible to separate 'dir-or-file-usr-local' into separate rules 
+>> (one for files, one for dirs)? While I agree we shouldn't ship files in 
+>> /usr/local, I don't see why we shouldn't ship dirs in /usr/local ...
+> 
+> We shouldn't ship directories for the same reason that we shouldn't ship
+> file, ie FHS.
+> 
+> See :
+> http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRLOCALLOCALHIERARCHY
+> 
+> More specifically :
+> "It needs to be safe from being overwritten when the system software is
+> updated."
+> 
+> So the question is whether someone who change directory permissions will
+> see them overwritten or not when the software is updated, and wether
+> that a FHS violation.
+> 
+> Afaik, rpm would reset the permission ( the same goes for removal of the
+> directory ). 
+> 
+> See also :
+> "No other directories, except those listed below, may be in /usr/local
+> after first installing a FHS-compliant system."
+> 
+> Again, that's not clear if we can modify it later or not ( ie, is
+> instaling rt on installation part of "first installing" or not ).
+> 
+> I guess we should get a opinion from FHS/LSB people on this.
+> 
+> In the mean time, I guess the point 1 is the easiest way, it can be
+> changed later once we clarified FHS (or if we decide that we do not care
+> about following standards, but that's really something I would like to
+> avoid ). 
+
+Not to mention there may be installations where /usr/local is NFS shared across a network and having the package manager trying to write 
+there could cause problems.  Maybe another possible solution is to have the software create the needed directory at some point, but don't 
+have the package itself create or own it.  CUPS is already doing this with /usr/local/lib/printdriver and /usr/local/share/ppd (and 
+equivalents in /opt).
+
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011405.html b/zarb-ml/mageia-dev/2012-January/011405.html new file mode 100644 index 000000000..44036fc87 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011405.html @@ -0,0 +1,84 @@ + + + + [Mageia-dev] [changelog] [RPM] 1 core/updates_testing terminator-0.96-2.mga1 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] 1 core/updates_testing terminator-0.96-2.mga1

+ Juan Luis Baptiste + juancho at mageia.org +
+ Mon Jan 16 21:08:41 CET 2012 +

+
+ +
On Mon, Jan 16, 2012 at 2:43 PM, Jani Välimaa <jani.valimaa at gmail.com> wrote:
+> 2012/1/16 lebedov <buildsystem-daemon at mageia.org>:
+>> URL         : http://www.tenshu.net/terminator/
+
+And the URL is broken, the correct one is
+http://www.tenshu.net/p/terminator.html
+
+
+-- 
+Juancho
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011406.html b/zarb-ml/mageia-dev/2012-January/011406.html new file mode 100644 index 000000000..cdca4900e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011406.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] [changelog] [RPM] 1 core/updates_testing terminator-0.96-2.mga1 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] 1 core/updates_testing terminator-0.96-2.mga1

+ Florian Hubold + doktor5000 at arcor.de +
+ Mon Jan 16 21:35:50 CET 2012 +

+
+ +
Am 16.01.2012 20:43, schrieb Jani Välimaa:
+> 2012/1/16 lebedov <buildsystem-daemon at mageia.org>:
+>> Name        : terminator                   Relocations: (not relocatable)
+>> Version     : 0.96                              Vendor: Mageia.Org
+>> Release     : 2.mga1                        Build Date: Mon Jan 16 19:26:23 2012
+>> Install Date: (not installed)               Build Host: jonund
+>> Group       : Terminals                     Source RPM: (none)
+>> Size        : 266173                           License: GPLv2
+>> Signature   : (none)
+>> Packager    : lebedov <lebedov>
+>> URL         : http://www.tenshu.net/terminator/
+>> Summary     : A simple way to run multiple terminals in a single window
+>> Description :
+>> Terminator is an attempt to maximise useful space on a given desktop
+>> for terminals. It is a simple Python script that places multiple vte
+>> widgets (the same used by gnome-terminal) in a window. That's the same
+>> widget used by gnome-terminal.
+>>
+>> lebedov <lebedov> 0.96-2.mga1:
+>> + Revision: 196966
+>> - Require pygtk2.0 on installation (#3612).
+>> - Update to 0.96.
+> You should use subrel when pushing updates to stable release.
+>
+Well, not for the version update, but for the next commit:
+https://wiki.mageia.org/en/Updates_policy#Maintainer_.28or_any_interested_packager.29
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011407.html b/zarb-ml/mageia-dev/2012-January/011407.html new file mode 100644 index 000000000..533a94ce9 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011407.html @@ -0,0 +1,81 @@ + + + + [Mageia-dev] Mozilla is switching to MPLv2 + + + + + + + + + +

[Mageia-dev] Mozilla is switching to MPLv2

+ Kamil Rytarowski + n54 at gmx.com +
+ Tue Jan 17 01:20:35 CET 2012 +

+
+ +
Please be aware of licenses.
+
+http://tech.slashdot.org/story/12/01/06/1752240/mozilla-public-license-20-released
+https://www.mozilla.org/MPL/2.0/
+https://wiki.mozilla.org/MPL_Upgrade
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011408.html b/zarb-ml/mageia-dev/2012-January/011408.html new file mode 100644 index 000000000..9eb97e7a8 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011408.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu? + + + + + + + + + +

[Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?

+ Michael Scherer + misc at zarb.org +
+ Tue Jan 17 07:13:49 CET 2012 +

+
+ +
Le samedi 14 janvier 2012 à 21:10 +0100, Kamil Rytarowski a écrit :
+
+> Hi!
+> We have succeed to push the patch upstream 
+> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=0e0e7facc775e9bb020314f48751b3d09f316c8b 
+> It took 2 months.. It will be shipped with the next version of Qemu so 
+> no need to take care of the patch for next releases.
+
+> Can I now patch the old Qemu in Mga1 to ship UDP support and therefore 
+> be usable within GNS3? I will then fix GNS3 and its requirements too.
+
+That's a non bugfix update, so that doesn't fullfill the policy. 
+
+I am not opposed on having the patch in cauldron however.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011409.html b/zarb-ml/mageia-dev/2012-January/011409.html new file mode 100644 index 000000000..949cdf753 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011409.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] Mozilla is switching to MPLv2 + + + + + + + + + +

[Mageia-dev] Mozilla is switching to MPLv2

+ Florian Hubold + doktor5000 at arcor.de +
+ Tue Jan 17 09:10:03 CET 2012 +

+
+ +
Am 17.01.2012 01:20, schrieb Kamil Rytarowski:
+> Please be aware of licenses.
+>
+> http://tech.slashdot.org/story/12/01/06/1752240/mozilla-public-license-20-released
+>
+> https://www.mozilla.org/MPL/2.0/
+> https://wiki.mozilla.org/MPL_Upgrade
+>
+It essentially means that the current triple-licensing will
+be removed in favour of MPLv2 only, which in turn means mozilla
+stuff can't be linked anymore to GPL stuff, IIUC.
+But i may be totally off, all that licensing things are not
+my area of expertise.
+
+https://www.gnu.org/licenses/license-list.html#MPL
+http://www.mozilla.org/MPL/2.0/FAQ.html#mpl-and-lgpl
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011410.html b/zarb-ml/mageia-dev/2012-January/011410.html new file mode 100644 index 000000000..a376f16be --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011410.html @@ -0,0 +1,81 @@ + + + + [Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu? + + + + + + + + + +

[Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?

+ Olav Vitters + olav at vitters.nl +
+ Tue Jan 17 09:24:14 CET 2012 +

+
+ +
On Tue, Jan 17, 2012 at 07:13:49AM +0100, Michael Scherer wrote:
+> I am not opposed on having the patch in cauldron however.
+
+Qemu 1.0 on Cauldron doesn't build. I suspect some kind of gcc problem
+as it has built on other distributions (fedora, opensuse).
+
+Filed https://bugs.mageia.org/show_bug.cgi?id=4164 against gcc (probably
+wrong, but need an expert).
+
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011411.html b/zarb-ml/mageia-dev/2012-January/011411.html new file mode 100644 index 000000000..b7d33f0e6 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011411.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] Mozilla is switching to MPLv2 + + + + + + + + + +

[Mageia-dev] Mozilla is switching to MPLv2

+ Romain d'Alverny + rdalverny at gmail.com +
+ Tue Jan 17 09:45:33 CET 2012 +

+
+ +
On Tue, Jan 17, 2012 at 09:10, Florian Hubold <doktor5000 at arcor.de> wrote:
+> Am 17.01.2012 01:20, schrieb Kamil Rytarowski:
+>> Please be aware of licenses.
+>>
+>> http://tech.slashdot.org/story/12/01/06/1752240/mozilla-public-license-20-released
+>>
+>> https://www.mozilla.org/MPL/2.0/
+>> https://wiki.mozilla.org/MPL_Upgrade
+>>
+> It essentially means that the current triple-licensing will
+> be removed in favour of MPLv2 only, which in turn means mozilla
+> stuff can't be linked anymore to GPL stuff, IIUC.
+
+Yes it can. See
+https://wiki.mozilla.org/MPL_Upgrade#Why_is_it_better.3F and
+https://wiki.mozilla.org/MPL_Upgrade#What_will_be_the_difference_in_terms_of_forward_licence_compatibility.3F
+
+> https://www.gnu.org/licenses/license-list.html#MPL
+
+Beware, now, it's
+https://www.gnu.org/licenses/license-list.html#MPL-2.0 we're talking
+about.
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011412.html b/zarb-ml/mageia-dev/2012-January/011412.html new file mode 100644 index 000000000..906d932e5 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011412.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] [changelog] [RPM] 1 core/updates_testing terminator-0.96-2.mga1 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] 1 core/updates_testing terminator-0.96-2.mga1

+ Jani Välimaa + jani.valimaa at gmail.com +
+ Tue Jan 17 10:00:06 CET 2012 +

+
+ +
2012/1/16 Florian Hubold <doktor5000 at arcor.de>:
+> Am 16.01.2012 20:43, schrieb Jani Välimaa:
+>> 2012/1/16 lebedov <buildsystem-daemon at mageia.org>:
+>>> Name        : terminator                   Relocations: (not relocatable)
+>>> Version     : 0.96                              Vendor: Mageia.Org
+>>> Release     : 2.mga1                        Build Date: Mon Jan 16 19:26:23 2012
+>>> Install Date: (not installed)               Build Host: jonund
+>>> Group       : Terminals                     Source RPM: (none)
+>>> Size        : 266173                           License: GPLv2
+>>> Signature   : (none)
+>>> Packager    : lebedov <lebedov>
+>>> URL         : http://www.tenshu.net/terminator/
+>>> Summary     : A simple way to run multiple terminals in a single window
+>>> Description :
+>>> Terminator is an attempt to maximise useful space on a given desktop
+>>> for terminals. It is a simple Python script that places multiple vte
+>>> widgets (the same used by gnome-terminal) in a window. That's the same
+>>> widget used by gnome-terminal.
+>>>
+>>> lebedov <lebedov> 0.96-2.mga1:
+>>> + Revision: 196966
+>>> - Require pygtk2.0 on installation (#3612).
+>>> - Update to 0.96.
+>> You should use subrel when pushing updates to stable release.
+>>
+> Well, not for the version update, but for the next commit:
+> https://wiki.mageia.org/en/Updates_policy#Maintainer_.28or_any_interested_packager.29
+
+Well, this was not a version upgrade. :P
+
+Changelog is broken due to an old bug
+https://bugs.mageia.org/show_bug.cgi?id=3666
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011413.html b/zarb-ml/mageia-dev/2012-January/011413.html new file mode 100644 index 000000000..891edde4c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011413.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] [changelog] [RPM] 1 core/updates_testing terminator-0.96-2.mga1 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] 1 core/updates_testing terminator-0.96-2.mga1

+ Florian Hubold + doktor5000 at arcor.de +
+ Tue Jan 17 10:26:07 CET 2012 +

+
+ +
Am 17.01.2012 10:00, schrieb Jani Välimaa:
+> 2012/1/16 Florian Hubold <doktor5000 at arcor.de>:
+>> Am 16.01.2012 20:43, schrieb Jani Välimaa:
+>>> 2012/1/16 lebedov <buildsystem-daemon at mageia.org>:
+>>>> Name        : terminator                   Relocations: (not relocatable)
+>>>> Version     : 0.96                              Vendor: Mageia.Org
+>>>> Release     : 2.mga1                        Build Date: Mon Jan 16 19:26:23 2012
+>>>> Install Date: (not installed)               Build Host: jonund
+>>>> Group       : Terminals                     Source RPM: (none)
+>>>> Size        : 266173                           License: GPLv2
+>>>> Signature   : (none)
+>>>> Packager    : lebedov <lebedov>
+>>>> URL         : http://www.tenshu.net/terminator/
+>>>> Summary     : A simple way to run multiple terminals in a single window
+>>>> Description :
+>>>> Terminator is an attempt to maximise useful space on a given desktop
+>>>> for terminals. It is a simple Python script that places multiple vte
+>>>> widgets (the same used by gnome-terminal) in a window. That's the same
+>>>> widget used by gnome-terminal.
+>>>>
+>>>> lebedov <lebedov> 0.96-2.mga1:
+>>>> + Revision: 196966
+>>>> - Require pygtk2.0 on installation (#3612).
+>>>> - Update to 0.96.
+>>> You should use subrel when pushing updates to stable release.
+>>>
+>> Well, not for the version update, but for the next commit:
+>> https://wiki.mageia.org/en/Updates_policy#Maintainer_.28or_any_interested_packager.29
+> Well, this was not a version upgrade. :P
+>
+> Changelog is broken due to an old bug
+> https://bugs.mageia.org/show_bug.cgi?id=3666
+>
+Former commit was a version update ;)
+but anyways, release should never be bumped directly
+for stable release.
+
+ + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011414.html b/zarb-ml/mageia-dev/2012-January/011414.html new file mode 100644 index 000000000..656da6381 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011414.html @@ -0,0 +1,122 @@ + + + + [Mageia-dev] Mageia 2 Alpha 3 available for tests + + + + + + + + + +

[Mageia-dev] Mageia 2 Alpha 3 available for tests

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Jan 17 13:20:01 CET 2012 +

+
+ +
'Twas brillig, and EatDirt at 13/01/12 10:11 did gyre and gimble:
+> On 12/01/12 21:04, Anne nicolas wrote:
+>> Hi all
+>>
+>> Mageia 2 Alpha 3 is now available for tests:
+>> http://blog.mageia.org/en/2012/01/12/here-comes-mageia-2-alpha3/
+> 
+> Hi,
+> tested the boot.iso with network install; everything went fine.
+> 
+> At boot however, systemd exhibited some failures (apparently they are
+> harmless though):
+> 
+> UNIT                           LOAD   ACTIVE SUB    JOB DESCRIPTION
+> fedora-loadmodules.service     loaded ESC[1;31mfailed failedESC[0m Load
+> legacy module configuration
+
+Yeah I think we can maybe drop this one, but you are correct, it's harmless.
+
+> systemd-tmpfiles-clean.service loaded ESC[1;31mfailed failedESC[0m
+> Cleanup of Temporary Directories
+> systemd-tmpfiles-setup.service loaded ESC[1;31mfailed failedESC[0m
+> Recreate Volatile Files and Directories
+
+Likely due to missing "lock" group as a result of our lockdev package.
+It's a somewhat complicated issue and I've basically chickened out of
+fixing it thus far.
+
+Will get around it it soon, if no one pings me with a "I'll have a go at
+fixing it, do you have more details" type email (there are a few links
+I'd need to dig out).
+
+> udisksd.service                loaded ESC[1;31mfailed failedESC[0m
+> UDisks Daemon
+> upowerd.service                loaded ESC[1;31mfailed failedESC[0m
+> UPower Daemon
+
+Dunno why these two would be failing...
+
+Col
+
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011415.html b/zarb-ml/mageia-dev/2012-January/011415.html new file mode 100644 index 000000000..c9f50ef19 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011415.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] Issues with dracut + + + + + + + + + +

[Mageia-dev] Issues with dracut

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Jan 17 13:22:30 CET 2012 +

+
+ +
'Twas brillig, and David W. Hodgins at 19/12/11 21:48 did gyre and gimble:
+> On Sun, 18 Dec 2011 17:22:46 -0500, Colin Guthrie
+> <mageia at colin.guthr.ie> wrote:
+> 
+>> Can you run the attached?
+> 
+> It works.  It identifies /usr as being on 252:9,
+> which is on 8:12, which has the fs_type LVM2_member.
+> 
+> Regards, Dave Hodgins
+
+Sorry, missed the reply... if this attachment worked, then the main code
+should work for you too....
+
+Are things working OK for you now with dracut or is it still busted?
+
+Col
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011416.html b/zarb-ml/mageia-dev/2012-January/011416.html new file mode 100644 index 000000000..8b216c02a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011416.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] MANUAL FIX: ACL/permissions issues (i.e. sound devices) + + + + + + + + + +

[Mageia-dev] MANUAL FIX: ACL/permissions issues (i.e. sound devices)

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Jan 17 15:38:25 CET 2012 +

+
+ +
Hi,
+
+I messed up a %post script in the pam package which causes issues with
+systemd related authentication stuff. Sorry about that.
+
+It's a pain to fix with a script so I won't and thus a manual fix is needed.
+
+Simply edit the system-auth pam.d file, e.g.: sudo vi /etc/pam.d/system-auth
+
+and remove the last line which should say:
+
+-session    optional      pam_systemd.so
+
+
+This line should be a duplicate of an entry one or two lines above.
+
+You DO want one line with the above in it, you do NOT want more than one.
+
+pam package is fixed to not do this any more but you'll need to manually
+fix this up.
+
+Sorry for the inconvenience.
+
+Col
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011417.html b/zarb-ml/mageia-dev/2012-January/011417.html new file mode 100644 index 000000000..593300b65 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011417.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] MANUAL FIX: ACL/permissions issues (i.e. sound devices) + + + + + + + + + +

[Mageia-dev] MANUAL FIX: ACL/permissions issues (i.e. sound devices)

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Jan 17 17:44:04 CET 2012 +

+
+ +
On 17 January 2012 15:38, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+> Hi,
+>
+> I messed up a %post script in the pam package which causes issues with
+> systemd related authentication stuff. Sorry about that.
+>
+> It's a pain to fix with a script so I won't and thus a manual fix is needed.
+
+perl -pi -e 'if (/^-session\s+optional\s+pam_systemd.so\s*$/o) {
+$seen++; undef $_ if $seen > 1 }'  /etc/pam.d/system-authsystem-auth
+
+> Simply edit the system-auth pam.d file, e.g.: sudo vi /etc/pam.d/system-auth
+>
+> and remove the last line which should say:
+>
+> -session    optional      pam_systemd.so
+>
+>
+> This line should be a duplicate of an entry one or two lines above.
+>
+> You DO want one line with the above in it, you do NOT want more than one.
+>
+> pam package is fixed to not do this any more but you'll need to manually
+> fix this up.
+>
+> Sorry for the inconvenience.
+
+ + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011418.html b/zarb-ml/mageia-dev/2012-January/011418.html new file mode 100644 index 000000000..f4910422d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011418.html @@ -0,0 +1,76 @@ + + + + [Mageia-dev] MANUAL FIX: ACL/permissions issues (i.e. sound devices) + + + + + + + + + +

[Mageia-dev] MANUAL FIX: ACL/permissions issues (i.e. sound devices)

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Jan 17 17:44:58 CET 2012 +

+
+ +
On 17 January 2012 15:38, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+>
+> You DO want one line with the above in it, you do NOT want more than one.
+
+BTW what are the consequences?
+
+ + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011419.html b/zarb-ml/mageia-dev/2012-January/011419.html new file mode 100644 index 000000000..d3b303406 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011419.html @@ -0,0 +1,123 @@ + + + + [Mageia-dev] [packages-commits] [197459] - added xz as buildrequire + + + + + + + + + +

[Mageia-dev] [packages-commits] [197459] - added xz as buildrequire

+ Jani Välimaa + jani.valimaa at gmail.com +
+ Tue Jan 17 18:09:44 CET 2012 +

+
+ +
2012/1/17  <root at mageia.org>:
+> Revision 197459 Author matteo Date 2012-01-17 17:12:33 +0100 (Tue, 17 Jan
+> 2012)
+>
+> Log Message
+>
+> - added xz as buildrequire
+> - fixed release
+>
+> Modified Paths
+>
+> cauldron/axel/current/SPECS/axel.spec
+>
+> Modified: cauldron/axel/current/SPECS/axel.spec
+> ===================================================================
+> --- cauldron/axel/current/SPECS/axel.spec	2012-01-17 16:06:10 UTC (rev
+> 197458)
+> +++ cauldron/axel/current/SPECS/axel.spec	2012-01-17 16:12:33 UTC (rev
+> 197459)
+> @@ -1,7 +1,7 @@
+>  Name:		axel
+>  Summary:        A lightweight download accelerator by using multiple
+> connections
+>  Version:        2.4
+> -Release:        %mkrel 3
+> +Release:        %mkrel 2
+>  Source0:
+> http://alioth.debian.org/frs/download.php/3015/%{name}-%{version}.tar.gz
+>  URL:            http://axel.alioth.debian.org/
+>
+> @@ -11,6 +11,7 @@
+>  BuildRequires:	libtool
+>  BuildRequires:	gettext
+>  BuildRequires:	desktop-file-utils
+> +BuildRequires:	xz
+>
+>
+>  %description
+> @@ -30,21 +31,23 @@
+>  rm -rf %{buildroot}
+>  %makeinstall_std
+>  install -d -m 0755 %{buildroot}%{_datadir}/applications
+> -install -c -m 0755 gui/kapt/axel-kapt   %{buildroot}%{_bindir}/
+> -install -c -m 0644 gui/kapt/axel-kapt.1 %{buildroot}%{_datadir}/man/man1/
+> +install -c -m 0755 gui/kapt/%{name}-kapt   %{buildroot}%{_bindir}/
+> +install -c -m 0644 gui/kapt/%{name}-kapt.1
+> %{buildroot}%{_datadir}/man/man1/
+>
+> +xz -9 %{buildroot}%{_datadir}/man/man1/%{name}-kapt.1
+
+There's no need to compress man pages by hand, it's done automatically
+by the build process.
+
+ + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011420.html b/zarb-ml/mageia-dev/2012-January/011420.html new file mode 100644 index 000000000..8811fab8a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011420.html @@ -0,0 +1,126 @@ + + + + [Mageia-dev] [packages-commits] [197460] - axel-kapt man pages provided by axel-kapt package + + + + + + + + + +

[Mageia-dev] [packages-commits] [197460] - axel-kapt man pages provided by axel-kapt package

+ Jani Välimaa + jani.valimaa at gmail.com +
+ Tue Jan 17 18:15:34 CET 2012 +

+
+ +
2012/1/17  <root at mageia.org>:
+> Revision 197460 Author matteo Date 2012-01-17 17:27:19 +0100 (Tue, 17 Jan
+> 2012)
+>
+> Log Message
+>
+> - axel-kapt man pages provided by axel-kapt package
+>
+> Modified Paths
+>
+> cauldron/axel/current/SPECS/axel.spec
+>
+> Modified: cauldron/axel/current/SPECS/axel.spec
+> ===================================================================
+> --- cauldron/axel/current/SPECS/axel.spec	2012-01-17 16:12:33 UTC (rev
+> 197459)
+> +++ cauldron/axel/current/SPECS/axel.spec	2012-01-17 16:27:19 UTC (rev
+> 197460)
+> @@ -30,9 +30,9 @@
+>  %install
+>  rm -rf %{buildroot}
+>  %makeinstall_std
+> -install -d -m 0755 %{buildroot}%{_datadir}/applications
+> -install -c -m 0755 gui/kapt/%{name}-kapt   %{buildroot}%{_bindir}/
+> -install -c -m 0644 gui/kapt/%{name}-kapt.1
+> %{buildroot}%{_datadir}/man/man1/
+> +install -D -d -m 0755 %{buildroot}%{_datadir}/applications
+> +install -D -m 0755 gui/kapt/%{name}-kapt   %{buildroot}%{_bindir}/
+> +install -D -m 0644 gui/kapt/%{name}-kapt.1
+> %{buildroot}%{_datadir}/man/man1/
+>
+>  xz -9 %{buildroot}%{_datadir}/man/man1/%{name}-kapt.1
+>
+> @@ -48,7 +48,8 @@
+>  %doc API README COPYING CREDITS %{name}rc.example
+>  %{_bindir}/%{name}
+>  %config(noreplace) %{_sysconfdir}/%{name}rc
+> -%{_mandir}/*
+> +%{_mandir}/man1/%{name}.1.xz
+> +%{_mandir}/zh_CN/man1/%{name}.1.xz
+>
+>  %package kapt
+>  Summary:        GUI for axel
+> @@ -65,4 +66,4 @@
+>  %files kapt
+>  %{_bindir}/%{name}-kapt
+>  %{_datadir}/applications/%{name}-kapt.desktop
+> -
+> +%{_mandir}/man1/%{name}-kapt.1.xz
+>
+
+A little hint: don't hardcode man page extension as we could change
+the compression someday -> file extension changes -> you need to edit
+every .spec by hand where the extension is hardcoded. Use wildcards
+instead.
+
+ + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011421.html b/zarb-ml/mageia-dev/2012-January/011421.html new file mode 100644 index 000000000..0d07b23dd --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011421.html @@ -0,0 +1,130 @@ + + + + [Mageia-dev] [packages-commits] [197460] - axel-kapt man pages provided by axel-kapt package + + + + + + + + + +

[Mageia-dev] [packages-commits] [197460] - axel-kapt man pages provided by axel-kapt package

+ Funda Wang + fundawang at gmail.com +
+ Tue Jan 17 19:32:10 CET 2012 +

+
+ +
And I think due to files are being moved from one package to another,
+Conflicts tag should be added to ease upgrading.
+
+2012/1/18 Jani Välimaa <jani.valimaa at gmail.com>:
+> 2012/1/17  <root at mageia.org>:
+>> Revision 197460 Author matteo Date 2012-01-17 17:27:19 +0100 (Tue, 17 Jan
+>> 2012)
+>>
+>> Log Message
+>>
+>> - axel-kapt man pages provided by axel-kapt package
+>>
+>> Modified Paths
+>>
+>> cauldron/axel/current/SPECS/axel.spec
+>>
+>> Modified: cauldron/axel/current/SPECS/axel.spec
+>> ===================================================================
+>> --- cauldron/axel/current/SPECS/axel.spec     2012-01-17 16:12:33 UTC (rev
+>> 197459)
+>> +++ cauldron/axel/current/SPECS/axel.spec     2012-01-17 16:27:19 UTC (rev
+>> 197460)
+>> @@ -30,9 +30,9 @@
+>>  %install
+>>  rm -rf %{buildroot}
+>>  %makeinstall_std
+>> -install -d -m 0755 %{buildroot}%{_datadir}/applications
+>> -install -c -m 0755 gui/kapt/%{name}-kapt   %{buildroot}%{_bindir}/
+>> -install -c -m 0644 gui/kapt/%{name}-kapt.1
+>> %{buildroot}%{_datadir}/man/man1/
+>> +install -D -d -m 0755 %{buildroot}%{_datadir}/applications
+>> +install -D -m 0755 gui/kapt/%{name}-kapt   %{buildroot}%{_bindir}/
+>> +install -D -m 0644 gui/kapt/%{name}-kapt.1
+>> %{buildroot}%{_datadir}/man/man1/
+>>
+>>  xz -9 %{buildroot}%{_datadir}/man/man1/%{name}-kapt.1
+>>
+>> @@ -48,7 +48,8 @@
+>>  %doc API README COPYING CREDITS %{name}rc.example
+>>  %{_bindir}/%{name}
+>>  %config(noreplace) %{_sysconfdir}/%{name}rc
+>> -%{_mandir}/*
+>> +%{_mandir}/man1/%{name}.1.xz
+>> +%{_mandir}/zh_CN/man1/%{name}.1.xz
+>>
+>>  %package kapt
+>>  Summary:        GUI for axel
+>> @@ -65,4 +66,4 @@
+>>  %files kapt
+>>  %{_bindir}/%{name}-kapt
+>>  %{_datadir}/applications/%{name}-kapt.desktop
+>> -
+>> +%{_mandir}/man1/%{name}-kapt.1.xz
+>>
+>
+> A little hint: don't hardcode man page extension as we could change
+> the compression someday -> file extension changes -> you need to edit
+> every .spec by hand where the extension is hardcoded. Use wildcards
+> instead.
+
+ + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011422.html b/zarb-ml/mageia-dev/2012-January/011422.html new file mode 100644 index 000000000..8077f5990 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011422.html @@ -0,0 +1,76 @@ + + + + [Mageia-dev] Slow gnome-shell due to new cogl/clutter + + + + + + + + + +

[Mageia-dev] Slow gnome-shell due to new cogl/clutter

+ Olav Vitters + olav at vitters.nl +
+ Wed Jan 18 01:07:07 CET 2012 +

+
+ +
Suggest to not restart gnome-shell nor logout until upstream fixed it.
+Gnome-shell is unusably slow atm.
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011423.html b/zarb-ml/mageia-dev/2012-January/011423.html new file mode 100644 index 000000000..4e33869e1 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011423.html @@ -0,0 +1,82 @@ + + + + [Mageia-dev] Slow gnome-shell due to new cogl/clutter + + + + + + + + + +

[Mageia-dev] Slow gnome-shell due to new cogl/clutter

+ JA Magallon + jamagallon at ono.com +
+ Wed Jan 18 09:39:43 CET 2012 +

+
+ +
On Wed, 18 Jan 2012 01:07:07 +0100
+Olav Vitters <olav at vitters.nl> wrote:
+
+> Suggest to not restart gnome-shell nor logout until upstream fixed it.
+> Gnome-shell is unusably slow atm.
+
+Too late for me ;)
+
+Fallback mode works fine. So log in with 'Traditional Gnome' as a
+workaround...
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011424.html b/zarb-ml/mageia-dev/2012-January/011424.html new file mode 100644 index 000000000..4d267d8a8 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011424.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] [RFC] Draft of a wiki page for systemd + + + + + + + + + +

[Mageia-dev] [RFC] Draft of a wiki page for systemd

+ Glen Ogilvie + nelg at linuxsolutions.co.nz +
+ Wed Jan 18 12:56:26 CET 2012 +

+
+ +
On Tue, Jan 17, 2012 at 2:58 AM, D.Morgan <dmorganec at gmail.com> wrote:
+> On Mon, Jan 16, 2012 at 11:46 AM, Florian Hubold <doktor5000 at arcor.de> wrote:
+>> Am 16.01.2012 08:58, schrieb D.Morgan:
+>>> On Mon, Jan 16, 2012 at 12:45 AM, D.Morgan <dmorganec at gmail.com> wrote:
+>>>> i started a wiki page about systemd migration.
+>>>>
+>>>> Please if you migrate a package using old sysvinit to systemd, Please
+>>>> add it on this page on the Array
+>>>> Please add packages that i could have forgotten on this page.
+>>>>
+>>>> thank you in advance.
+>>> which is here:   https://wiki.mageia.org/en/Features/Systemd
+>>>
+>> Maybe it would also be helpful to others if someone
+>> could do a short writeup of what the actual migration to
+>> systemd consists of, or some things to pay attention to,
+>> instead of just a list of packages?
+>
+> this is planned too ( in fact this is a reason i used the word draft :) )
+
+Sounds good,  I've been working on packaging ajaxterm, which run's as
+a service. Should I add it to the list?  I'd be happy to adjust it's
+startup script when details are written up as to what needs changing.
+
+Regards
+Glen Ogilvie
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011425.html b/zarb-ml/mageia-dev/2012-January/011425.html new file mode 100644 index 000000000..6853bd768 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011425.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] Packaging MDS and Pulse2 + + + + + + + + + +

[Mageia-dev] Packaging MDS and Pulse2

+ Glen Ogilvie + nelg at linuxsolutions.co.nz +
+ Wed Jan 18 13:33:40 CET 2012 +

+
+ +
Hi,
+
+I've noticed that a project I work on, MDS (http://mds.mandriva.org)
+is not yet packaged for Mageia.
+
+I am wondering if Mageia can package it as Mandriva Directory Server,
+or if we need to change the name and
+fork the MDS project in order to package it.  Ref:
+https://wiki.mageia.org/en/Mandriva_packagers
+
+It's available for a number of other distributions, as can be seen on
+the opensuse build infrastructure, with the
+name unchanged.
+https://build.opensuse.org/package/show?package=mmc-core&project=home%3Aeonpatapon%3Amds
+
+I would also like to package Pulse2,  it does not have Mandriva in the
+package name, but is also developed by Mandriva.
+
+Regards
+Glen Ogilvie
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011426.html b/zarb-ml/mageia-dev/2012-January/011426.html new file mode 100644 index 000000000..2773ced7c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011426.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] Is mageia a bit slow? + + + + + + + + + +

[Mageia-dev] Is mageia a bit slow?

+ Michel Catudal + michelcatudal at gmail.com +
+ Wed Jan 18 13:53:15 CET 2012 +

+
+ +
Last night I compiled mips-sde-elf-gcc on Scientific Linux AMD64 and it took about 2hrs 10 minutes. When I compiled it on mageia it took close to 3 hours.
+gcc is told to use all 4 cores on both. Scientific Linux is version 6.0 with the latest updates. gcc is gcc-4.4.5-6.el6.x86_64.
+Mageia is the latest released version, not the beta.
+
+Any clue what is responsible for the speed issue on magia? Scientific Linux or Redhat Enterprise superior or newer gcc slower?
+I haven't tested on Fedora 15 or 16 yet. I will eventually test it on gentoo, I haven't used gentoo since my gnome update switched it to gnome 3.
+I need to find a way to install mate on it to make it usable again.
+
+Michel
+
+-- 
+For OS/2 and Linux Software visit
+http://home.comcast.net/~mcatudal
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011427.html b/zarb-ml/mageia-dev/2012-January/011427.html new file mode 100644 index 000000000..8e4eb3bce --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011427.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] Is mageia a bit slow? + + + + + + + + + +

[Mageia-dev] Is mageia a bit slow?

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Wed Jan 18 13:57:38 CET 2012 +

+
+ +
Le 18/01/2012 13:53, Michel Catudal a écrit :
+> Any clue what is responsible for the speed issue on magia? Scientific
+> Linux or Redhat Enterprise superior or newer gcc slower?
+Are you sure you're using a comparable build environement, meaning 
+similar harware and similar file system, and you're not comparing an 
+nfs-mounted homedir versus a local ssd, for instance ?
+-- 
+BOFH excuse #209:
+
+Only people with names beginning with 'A' are getting mail this week (a 
+la Microsoft)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011428.html b/zarb-ml/mageia-dev/2012-January/011428.html new file mode 100644 index 000000000..9f35ce360 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011428.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] Packaging MDS and Pulse2 + + + + + + + + + +

[Mageia-dev] Packaging MDS and Pulse2

+ Andres Kaaber + andres.kaaber at gmail.com +
+ Wed Jan 18 14:00:27 CET 2012 +

+
+ +
I would realy like to see MDS packaged for Mageia :)
+
+2012/1/18 Glen Ogilvie <nelg at linuxsolutions.co.nz>:
+> Hi,
+>
+> I've noticed that a project I work on, MDS (http://mds.mandriva.org)
+> is not yet packaged for Mageia.
+>
+> I am wondering if Mageia can package it as Mandriva Directory Server,
+> or if we need to change the name and
+> fork the MDS project in order to package it.  Ref:
+> https://wiki.mageia.org/en/Mandriva_packagers
+>
+> It's available for a number of other distributions, as can be seen on
+> the opensuse build infrastructure, with the
+> name unchanged.
+> https://build.opensuse.org/package/show?package=mmc-core&project=home%3Aeonpatapon%3Amds
+>
+> I would also like to package Pulse2,  it does not have Mandriva in the
+> package name, but is also developed by Mandriva.
+>
+> Regards
+> Glen Ogilvie
+
+
+
+-- 
+A. Kaaber
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011429.html b/zarb-ml/mageia-dev/2012-January/011429.html new file mode 100644 index 000000000..a8854df75 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011429.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] Packaging MDS and Pulse2 + + + + + + + + + +

[Mageia-dev] Packaging MDS and Pulse2

+ nicolas vigier + boklm at mars-attacks.org +
+ Wed Jan 18 14:05:46 CET 2012 +

+
+ +
On Thu, 19 Jan 2012, Glen Ogilvie wrote:
+
+> Hi,
+> 
+> I've noticed that a project I work on, MDS (http://mds.mandriva.org)
+> is not yet packaged for Mageia.
+> 
+> I am wondering if Mageia can package it as Mandriva Directory Server,
+> or if we need to change the name and
+> fork the MDS project in order to package it.  Ref:
+> https://wiki.mageia.org/en/Mandriva_packagers
+
+I don't think we should change the name, if we don't fork it. And I
+don't think we should fork it, unless we have a good reason to do it and
+we plan to maintain ou own fork separatly.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011430.html b/zarb-ml/mageia-dev/2012-January/011430.html new file mode 100644 index 000000000..95933e968 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011430.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] Is mageia a bit slow? + + + + + + + + + +

[Mageia-dev] Is mageia a bit slow?

+ Florian Hubold + doktor5000 at arcor.de +
+ Wed Jan 18 14:27:37 CET 2012 +

+
+ +
Am 18.01.2012 13:57, schrieb Guillaume Rousse:
+> Le 18/01/2012 13:53, Michel Catudal a écrit :
+>> Any clue what is responsible for the speed issue on magia? Scientific
+>> Linux or Redhat Enterprise superior or newer gcc slower?
+> Are you sure you're using a comparable build environement, meaning similar
+> harware and similar file system, and you're not comparing an nfs-mounted
+> homedir versus a local ssd, for instance ?
+Or totally different flags passed to the compiler?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011431.html b/zarb-ml/mageia-dev/2012-January/011431.html new file mode 100644 index 000000000..19e611b7e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011431.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] [RFC] Draft of a wiki page for systemd + + + + + + + + + +

[Mageia-dev] [RFC] Draft of a wiki page for systemd

+ D.Morgan + dmorganec at gmail.com +
+ Wed Jan 18 15:30:20 CET 2012 +

+
+ +
On Wed, Jan 18, 2012 at 12:56 PM, Glen Ogilvie
+<nelg at linuxsolutions.co.nz> wrote:
+> On Tue, Jan 17, 2012 at 2:58 AM, D.Morgan <dmorganec at gmail.com> wrote:
+>> On Mon, Jan 16, 2012 at 11:46 AM, Florian Hubold <doktor5000 at arcor.de> wrote:
+>>> Am 16.01.2012 08:58, schrieb D.Morgan:
+>>>> On Mon, Jan 16, 2012 at 12:45 AM, D.Morgan <dmorganec at gmail.com> wrote:
+>>>>> i started a wiki page about systemd migration.
+>>>>>
+>>>>> Please if you migrate a package using old sysvinit to systemd, Please
+>>>>> add it on this page on the Array
+>>>>> Please add packages that i could have forgotten on this page.
+>>>>>
+>>>>> thank you in advance.
+>>>> which is here:   https://wiki.mageia.org/en/Features/Systemd
+>>>>
+>>> Maybe it would also be helpful to others if someone
+>>> could do a short writeup of what the actual migration to
+>>> systemd consists of, or some things to pay attention to,
+>>> instead of just a list of packages?
+>>
+>> this is planned too ( in fact this is a reason i used the word draft :) )
+>
+> Sounds good,  I've been working on packaging ajaxterm, which run's as
+> a service. Should I add it to the list?  I'd be happy to adjust it's
+> startup script when details are written up as to what needs changing.
+>
+> Regards
+> Glen Ogilvie
+
+Yes please if you add a new rpm that have systemd ( or that have not
+systemd support yet ) add it on this page
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011432.html b/zarb-ml/mageia-dev/2012-January/011432.html new file mode 100644 index 000000000..73d657179 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011432.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] Drak3d & Compiz - Alpha 3 + + + + + + + + + +

[Mageia-dev] Drak3d & Compiz - Alpha 3

+ Robert Fox + list at foxconsult.net +
+ Wed Jan 18 15:32:19 CET 2012 +

+
+ +
Just installed Alpha 3 fresh on a machine - wanted to install and enable
+compiz, but Drak3d didn't seem to do the trick.  Is the Drak3d too not
+yet updated for the new X and Compiz??
+
+Thx,
+R.Fox
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011433.html b/zarb-ml/mageia-dev/2012-January/011433.html new file mode 100644 index 000000000..5d3efdfef --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011433.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] Drak3d & Compiz - Alpha 3 + + + + + + + + + +

[Mageia-dev] Drak3d & Compiz - Alpha 3

+ Manuel Hiebel + manuel at hiebel.eu +
+ Wed Jan 18 17:02:17 CET 2012 +

+
+ +
Le mercredi 18 janvier 2012 à 15:32 +0100, Robert Fox a écrit :
+> Just installed Alpha 3 fresh on a machine - wanted to install and enable
+> compiz, but Drak3d didn't seem to do the trick.  Is the Drak3d too not
+> yet updated for the new X and Compiz??
+> 
+> Thx,
+> R.Fox
+> 
+
+Yes it's a know bug
+https://bugs.mageia.org/buglist.cgi?quicksearch=cf_rpmpkg:drak3d
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011434.html b/zarb-ml/mageia-dev/2012-January/011434.html new file mode 100644 index 000000000..bed52e93b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011434.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] Drak3d & Compiz - Alpha 3 + + + + + + + + + +

[Mageia-dev] Drak3d & Compiz - Alpha 3

+ Julien + julien.moragny at laposte.net +
+ Wed Jan 18 18:50:04 CET 2012 +

+
+ +
Le Wed, 18 Jan 2012 17:02:17 +0100,
+Manuel Hiebel <manuel at hiebel.eu> a écrit :
+
+> Le mercredi 18 janvier 2012 à 15:32 +0100, Robert Fox a écrit :
+> > Just installed Alpha 3 fresh on a machine - wanted to install and enable
+> > compiz, but Drak3d didn't seem to do the trick.  Is the Drak3d too not
+> > yet updated for the new X and Compiz??
+> > 
+> > Thx,
+> > R.Fox
+> > 
+> 
+> Yes it's a know bug
+> https://bugs.mageia.org/buglist.cgi?quicksearch=cf_rpmpkg:drak3d
+> 
+> 
+
+Yes, and I don't understand why it doesn't work out of the box, as compiz
+provide compiz-fusion. Or is it another bug (i.e. compiz is installed but
+does not start ?)
+
+regards
+Julien
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011435.html b/zarb-ml/mageia-dev/2012-January/011435.html new file mode 100644 index 000000000..c842097c0 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011435.html @@ -0,0 +1,114 @@ + + + + [Mageia-dev] Drak3d & Compiz - Alpha 3 + + + + + + + + + +

[Mageia-dev] Drak3d & Compiz - Alpha 3

+ Robert Fox + list at foxconsult.net +
+ Wed Jan 18 19:20:37 CET 2012 +

+
+ +
On Wed, 2012-01-18 at 18:50 +0100, Julien wrote:
+> Le Wed, 18 Jan 2012 17:02:17 +0100,
+> Manuel Hiebel <manuel at hiebel.eu> a écrit :
+> 
+> > Le mercredi 18 janvier 2012 à 15:32 +0100, Robert Fox a écrit :
+> > > Just installed Alpha 3 fresh on a machine - wanted to install and enable
+> > > compiz, but Drak3d didn't seem to do the trick.  Is the Drak3d too not
+> > > yet updated for the new X and Compiz??
+> > > 
+> > > Thx,
+> > > R.Fox
+> > > 
+> > 
+> > Yes it's a know bug
+> > https://bugs.mageia.org/buglist.cgi?quicksearch=cf_rpmpkg:drak3d
+> > 
+> > 
+> 
+> Yes, and I don't understand why it doesn't work out of the box, as compiz
+> provide compiz-fusion. Or is it another bug (i.e. compiz is installed but
+> does not start ?)
+> 
+> regards
+> Julien
+
+Compiz appears to install but does not work properly.
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011436.html b/zarb-ml/mageia-dev/2012-January/011436.html new file mode 100644 index 000000000..4bf4db616 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011436.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] Tonight's meeting + + + + + + + + + +

[Mageia-dev] Tonight's meeting

+ Anne Nicolas + ennael1 at gmail.com +
+ Wed Jan 18 20:34:28 CET 2012 +

+
+ +
Hi there
+
+Quite late but we will have a meeting tonight mainly about end of Mageia
+2 development planning and how we can organize work.
+
+As usual you can add other topics
+
+Cheers
+
+-- 
+Anne
+http://mageia.org
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011437.html b/zarb-ml/mageia-dev/2012-January/011437.html new file mode 100644 index 000000000..47b680e1c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011437.html @@ -0,0 +1,124 @@ + + + + [Mageia-dev] Packaging MDS and Pulse2 + + + + + + + + + +

[Mageia-dev] Packaging MDS and Pulse2

+ andre999 + andre999mga at laposte.net +
+ Wed Jan 18 23:31:09 CET 2012 +

+
+ +
Glen Ogilvie a écrit :
+> Hi,
+>
+> I've noticed that a project I work on, MDS (http://mds.mandriva.org)
+> is not yet packaged for Mageia.
+>
+> I am wondering if Mageia can package it as Mandriva Directory Server,
+> or if we need to change the name and
+> fork the MDS project in order to package it.  Ref:
+> https://wiki.mageia.org/en/Mandriva_packagers
+>    
+
+No problem as part of the package name.
+It is just references to Mandriva as the packaging or supporting distro 
+that must be changed to Mageia.
+Since you want to support it, it is great that you want to import it.
+It would be a update to cauldron (becoming part of mga2).
+
+> It's available for a number of other distributions, as can be seen on
+> the opensuse build infrastructure, with the
+> name unchanged.
+> https://build.opensuse.org/package/show?package=mmc-core&project=home%3Aeonpatapon%3Amds
+>
+> I would also like to package Pulse2,  it does not have Mandriva in the
+> package name, but is also developed by Mandriva.
+>    
+
+Almost all of our packages were in Mandriva.  We just have to make sure 
+that its' licence permits redistribution, which is generally the case.
+And that if it is non-free, that it doesn't have any components that are 
+contrained by patent claims or similar considerations.  (At least for 
+the moment.)
+If the package was in mdv2010.1/2 (main/contrib/non-free), then it can 
+be imported as an update to mga1 as well as cauldron.
+If it wasn't, it would be a backport for mga1.  (But backports aren't 
+open yet, unless I missed it.)
+> Regards
+> Glen Ogilvie
+>
+>    
+Regards
+
+-- 
+André
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011438.html b/zarb-ml/mageia-dev/2012-January/011438.html new file mode 100644 index 000000000..a09ee7494 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011438.html @@ -0,0 +1,110 @@ + + + + [Mageia-dev] Is mageia a bit slow? + + + + + + + + + +

[Mageia-dev] Is mageia a bit slow?

+ Michel Catudal + michelcatudal at gmail.com +
+ Thu Jan 19 00:17:42 CET 2012 +

+
+ +
Le 18/01/2012 07:57, Guillaume Rousse a écrit :
+> Le 18/01/2012 13:53, Michel Catudal a écrit :
+>> Any clue what is responsible for the speed issue on magia? Scientific
+>> Linux or Redhat Enterprise superior or newer gcc slower?
+> Are you sure you're using a comparable build environement, meaning similar harware and similar file system, and you're not comparing an nfs-mounted homedir versus a local ssd, for instance ?
+
+Same hard disk, same PC
+
+spec file almost identical except that I have --with-system-zlib configure section on Scientific Linux and
+Release:       1%{?dist}  instead of Release:       %mkrel 2
+Both are 64 bits and on ext4, boot is on ext2 for both.
+
+I have 3 2TB hard disk. 2 for Linux distributions and 1 for eComStation (OS/2)
+The only thing I run in virtualbox is windows XP when I have to do some work at home for the company I work for (a French company in Indiana)
+
+
+Sys. de fichiers      1K-blocs   Utilisé    Dispo. Uti% Monté sur
+/dev/sdb7            516061624 226114608 263732616  47% /
+tmpfs                  1962500       336   1962164   1% /dev/shm
+/dev/sdb1               138829    119378     12283  91% /boot
+/dev/sdb10           371009560  27798300 324365048   8% /home/michel/vm_files
+/dev/sdb9            516061624 379803884 110043340  78% /mageia
+
+Michel
+
+
+-- 
+For OS/2 and Linux Software visit
+http://home.comcast.net/~mcatudal
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011439.html b/zarb-ml/mageia-dev/2012-January/011439.html new file mode 100644 index 000000000..e8859d996 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011439.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] Is mageia a bit slow? + + + + + + + + + +

[Mageia-dev] Is mageia a bit slow?

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Thu Jan 19 09:37:50 CET 2012 +

+
+ +
2012/1/19 Michel Catudal <michelcatudal at gmail.com>:
+>> Are you sure you're using a comparable build environement, meaning similar
+>> harware and similar file system, and you're not comparing an nfs-mounted
+>> homedir versus a local ssd, for instance ?
+>
+> Same hard disk, same PC
+>
+> spec file almost identical except that I have --with-system-zlib configure
+> section on Scientific Linux and
+> Release:       1%{?dist}  instead of Release:       %mkrel 2
+
+But the compilation flags are obviously different.
+(set by rpm-mageia-setup-build on mga)
+What ar those on the 2 differents OS?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011440.html b/zarb-ml/mageia-dev/2012-January/011440.html new file mode 100644 index 000000000..8b261416b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011440.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] Is mageia a bit slow? + + + + + + + + + +

[Mageia-dev] Is mageia a bit slow?

+ Donald Stewart + watersnowrock at gmail.com +
+ Thu Jan 19 10:00:46 CET 2012 +

+
+ +
On 19 January 2012 08:37, Thierry Vignaud <thierry.vignaud at gmail.com> wrote:
+> 2012/1/19 Michel Catudal <michelcatudal at gmail.com>:
+>>> Are you sure you're using a comparable build environement, meaning similar
+>>> harware and similar file system, and you're not comparing an nfs-mounted
+>>> homedir versus a local ssd, for instance ?
+>>
+>> Same hard disk, same PC
+>>
+>> spec file almost identical except that I have --with-system-zlib configure
+>> section on Scientific Linux and
+>> Release:       1%{?dist}  instead of Release:       %mkrel 2
+>
+> But the compilation flags are obviously different.
+> (set by rpm-mageia-setup-build on mga)
+> What ar those on the 2 differents OS?
+
+I cant say how much of a significant baring it will have, but my hdd
+has vastly varying read speeds depending on where the system is. The
+space at the end of the drive is far far slower that the space at the
+start. I guess that this could lead to some discrepancies.
+
+But as others say, the flags are more likely.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011441.html b/zarb-ml/mageia-dev/2012-January/011441.html new file mode 100644 index 000000000..e68df6e96 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011441.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] KDE 4.8.0 & Qt 4.8.0 soon on cauldron + + + + + + + + + +

[Mageia-dev] KDE 4.8.0 & Qt 4.8.0 soon on cauldron

+ Balcaen John + mikala at mageia.org +
+ Thu Jan 19 11:00:11 CET 2012 +

+
+ +
Hello,
+
+Just to let you know that in order to push KDE 4.8.0, i'll also push before Qt 
+4.8.0 so some others packages might need a rebuild since the qt prefix was 
+change to follow %{_libdir} (like it's done in fedora) instead of being 
+harcoded to /usr/lib, the qt4includedir macro was also fixed previously by 
+dmorgan.
+KDE 4.8.0 should follow soon after Qt 4.8.0 because from local test done with 
+the 4.7.90, KDE can be *really* slow until kdelibs,kde-runtime & kde-workspace 
+has been rebuild against Qt 4.8.0.
+
+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/2012-January/011442.html b/zarb-ml/mageia-dev/2012-January/011442.html new file mode 100644 index 000000000..370cdd792 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011442.html @@ -0,0 +1,121 @@ + + + + [Mageia-dev] Is mageia a bit slow? + + + + + + + + + +

[Mageia-dev] Is mageia a bit slow?

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Jan 19 13:39:10 CET 2012 +

+
+ +
'Twas brillig, and Donald Stewart at 19/01/12 09:00 did gyre and gimble:
+> On 19 January 2012 08:37, Thierry Vignaud <thierry.vignaud at gmail.com> wrote:
+>> 2012/1/19 Michel Catudal <michelcatudal at gmail.com>:
+>>>> Are you sure you're using a comparable build environement, meaning similar
+>>>> harware and similar file system, and you're not comparing an nfs-mounted
+>>>> homedir versus a local ssd, for instance ?
+>>>
+>>> Same hard disk, same PC
+>>>
+>>> spec file almost identical except that I have --with-system-zlib configure
+>>> section on Scientific Linux and
+>>> Release:       1%{?dist}  instead of Release:       %mkrel 2
+>>
+>> But the compilation flags are obviously different.
+>> (set by rpm-mageia-setup-build on mga)
+>> What ar those on the 2 differents OS?
+> 
+> I cant say how much of a significant baring it will have, but my hdd
+> has vastly varying read speeds depending on where the system is. The
+> space at the end of the drive is far far slower that the space at the
+> start. I guess that this could lead to some discrepancies.
+> 
+> But as others say, the flags are more likely.
+
+Things like ccache from previous compilations can also make a *huge*
+difference to compile times.
+
+Col
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011443.html b/zarb-ml/mageia-dev/2012-January/011443.html new file mode 100644 index 000000000..9e4302324 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011443.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] Slow gnome-shell due to new cogl/clutter + + + + + + + + + +

[Mageia-dev] Slow gnome-shell due to new cogl/clutter

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Jan 19 13:41:14 CET 2012 +

+
+ +
'Twas brillig, and JA Magallon at 18/01/12 08:39 did gyre and gimble:
+> On Wed, 18 Jan 2012 01:07:07 +0100
+> Olav Vitters <olav at vitters.nl> wrote:
+> 
+>> Suggest to not restart gnome-shell nor logout until upstream fixed it.
+>> Gnome-shell is unusably slow atm.
+> 
+> Too late for me ;)
+> 
+> Fallback mode works fine. So log in with 'Traditional Gnome' as a
+> workaround...
+
+Any news on this? I noticed a problem with mutexes but couldn't really
+trace it.
+
+Col
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011444.html b/zarb-ml/mageia-dev/2012-January/011444.html new file mode 100644 index 000000000..5020a60dc --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011444.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] Slow gnome-shell due to new cogl/clutter + + + + + + + + + +

[Mageia-dev] Slow gnome-shell due to new cogl/clutter

+ Olav Vitters + olav at vitters.nl +
+ Thu Jan 19 13:55:17 CET 2012 +

+
+ +
On Thu, Jan 19, 2012 at 12:41:14PM +0000, Colin Guthrie wrote:
+> 'Twas brillig, and JA Magallon at 18/01/12 08:39 did gyre and gimble:
+> > On Wed, 18 Jan 2012 01:07:07 +0100
+> > Olav Vitters <olav at vitters.nl> wrote:
+> > 
+> >> Suggest to not restart gnome-shell nor logout until upstream fixed it.
+> >> Gnome-shell is unusably slow atm.
+> > 
+> > Too late for me ;)
+> > 
+> > Fallback mode works fine. So log in with 'Traditional Gnome' as a
+> > workaround...
+> 
+> Any news on this? I noticed a problem with mutexes but couldn't really
+> trace it.
+
+On Tue, learned that Fedora will roll back the cogl. Cogl/clutter
+maintainer is looking at gnome-shell, but the changes shouldn't have
+affected the module. Or in other words: difficult to investigate.
+
+I haven't followed the discussion yesterday as my machine is unusable
+and I already broke my backup machine. I should have IRC logs though.
+
+Note: Didn't see any relevant fix/commit to gnome-shell/mutter.
+
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011445.html b/zarb-ml/mageia-dev/2012-January/011445.html new file mode 100644 index 000000000..24f5448bb --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011445.html @@ -0,0 +1,89 @@ + + + + [Mageia-dev] Slow gnome-shell due to new cogl/clutter + + + + + + + + + +

[Mageia-dev] Slow gnome-shell due to new cogl/clutter

+ Olav Vitters + olav at vitters.nl +
+ Thu Jan 19 13:59:07 CET 2012 +

+
+ +
On Thu, Jan 19, 2012 at 01:55:16PM +0100, Olav Vitters wrote:
+> Note: Didn't see any relevant fix/commit to gnome-shell/mutter.
+
+>From IRC just 30min ago:
+
+ <ebassi>        Window manager warning: Log level 16: value "nan" of
+ type `gfloat' is invalid or out of range for property `y' of type
+ `gfloat' -- this is interesting
+ <ebassi>        yey
+ <ebassi>        was able to run gnome-shell with clutter master without
+ changing mutter/gnome-shell
+ <ebassi>        obviously, it crashed
+ <ebassi>        but the layout loop seems to have been fixed
+
+
+Layout loop probably refers to the 100% CPU hog.
+
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011446.html b/zarb-ml/mageia-dev/2012-January/011446.html new file mode 100644 index 000000000..bcf668d55 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011446.html @@ -0,0 +1,137 @@ + + + + [Mageia-dev] Is mageia a bit slow? + + + + + + + + + +

[Mageia-dev] Is mageia a bit slow?

+ Michel Catudal + michelcatudal at gmail.com +
+ Thu Jan 19 13:59:31 CET 2012 +

+
+ +
Le 19/01/2012 04:00, Donald Stewart a écrit :
+> On 19 January 2012 08:37, Thierry Vignaud<thierry.vignaud at gmail.com>  wrote:
+>> 2012/1/19 Michel Catudal<michelcatudal at gmail.com>:
+>>>> Are you sure you're using a comparable build environement, meaning similar
+>>>> harware and similar file system, and you're not comparing an nfs-mounted
+>>>> homedir versus a local ssd, for instance ?
+>>> Same hard disk, same PC
+>>>
+>>> spec file almost identical except that I have --with-system-zlib configure
+>>> section on Scientific Linux and
+>>> Release:       1%{?dist}  instead of Release:       %mkrel 2
+>> But the compilation flags are obviously different.
+>> (set by rpm-mageia-setup-build on mga)
+>> What ar those on the 2 differents OS?
+> I cant say how much of a significant baring it will have, but my hdd
+> has vastly varying read speeds depending on where the system is. The
+> space at the end of the drive is far far slower that the space at the
+> start. I guess that this could lead to some discrepancies.
+>
+> But as others say, the flags are more likely.
+>
+On Scientific Linux
+
+gcc -c   -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings 
+-Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc -I../../gcc/build -I../../gcc/../include -I../../gcc/../libcpp/include  -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/dpd -I../libdecnumber    \
+         -o build/print-rtl.o ../../gcc/print-rtl.c
+
+gcc     -->   gcc-4.4.5-6.el6.x86_64
+binutils -->  binutils-2.20.51.0.2-5.20.el6.x86_64
+
+For Mageia I ran it on the latest release so you could evaluate that by compiling using my source file from my web site. I didn't make any change to the setup build  except that my directory is  /home/michel/packages
+
+in .rpmbuild on SL6
+
+%_topdir %(echo $HOME)/packages
+
+in .rpmbuild on mageia
+
+%_topdir %(echo $HOME)/packages
+%_tmppath %(echo $HOME)/packages/tmp
+
+plus the information on the key
+
+To compile it you need to have mpfr, gmp and mpc installed. Codesourcery, Atmel and Microchip add those with their proprietary versions of gcc but I do not.
+I think that they would conflict with the local ones and they make it longer to compile the compiler anyway.
+
+If you get the idea to compile the PIC32 stuff remember that it looks for a particular include file that Microchip didn't bother to have with their source code.
+You need to install Microchip's compiler and make a link to the include files
+
+lrwxrwxrwx 1 root root 45 17 janv. 23:25 /usr/pic32mx/include -> /opt/microchip/mplabc32/v2.02/pic32mx/include
+
+MIPS and ARM code are not fully tested yet so if you have issues with them feel free to complain to me for fixes. Testing is in progress on ARM version.
+As for the MIPS stuff the idea is to get the debugger for PIC32 so for kicks I generated the other binaries.
+
+Michel
+
+
+-- 
+For OS/2 and Linux Software visit
+http://home.comcast.net/~mcatudal
+
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011447.html b/zarb-ml/mageia-dev/2012-January/011447.html new file mode 100644 index 000000000..5ee117a59 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011447.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] [RFC] prefer dma rather than postfix in prefer.vendor.list for msec mga1 -> mga2 upgrade + + + + + + + + + +

[Mageia-dev] [RFC] prefer dma rather than postfix in prefer.vendor.list for msec mga1 -> mga2 upgrade

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Thu Jan 19 14:40:41 CET 2012 +

+
+ +
On 10 November 2011 11:09, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+>> as Anssi made me aware msec currently has a Requires on
+>> sendmail-command for cauldron, this was the outcome of the
+>> last discussion about msec / MTA.
+>> However, currently in /etc/urpmi/prefer.vendor.list postfix
+>> is preferred as sendmail-command and mail-server.
+>
+>
+> Personally I vote to change the sendmail-command and mail-server to dma
+> as stated.
+>
+> But I also vote to not require sendmail-command for msec.
+>
+> It's an optional dependency of msec - some people want mail by default
+> and some don't. My vote is don't. I generally install MTAs anyway for
+> other reasons, so that's fine.
+
+Indeed and it's bloating the install with uneeded stuff.
+This require should be reverted.
+
+> Miscs suggestion of "enter an email address for who should get roots
+> mail" and then install an mta to deliver it is IMO a good compromise for
+> everyone.
+
+That should be the way
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011448.html b/zarb-ml/mageia-dev/2012-January/011448.html new file mode 100644 index 000000000..e30630af3 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011448.html @@ -0,0 +1,77 @@ + + + + [Mageia-dev] Slow gnome-shell due to new cogl/clutter + + + + + + + + + +

[Mageia-dev] Slow gnome-shell due to new cogl/clutter

+ Olav Vitters + olav at vitters.nl +
+ Thu Jan 19 15:09:10 CET 2012 +

+
+ +
On Thu, Jan 19, 2012 at 01:59:07PM +0100, Olav Vitters wrote:
+>  <ebassi>        but the layout loop seems to have been fixed
+
+He uploaded a new clutter, so I assume that fixes it. I've submitted it.
+
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011449.html b/zarb-ml/mageia-dev/2012-January/011449.html new file mode 100644 index 000000000..c6d73de01 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011449.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] [soft-commits] [2494] Port stage2 to use udev. + + + + + + + + + +

[Mageia-dev] [soft-commits] [2494] Port stage2 to use udev.

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Thu Jan 19 17:56:59 CET 2012 +

+
+ +
On 19 December 2011 23:47,  <root at mageia.org> wrote:
+> Revision 2494 Author colin Date 2011-12-19 23:47:15 +0100 (Mon, 19 Dec 2011)
+>
+> Log Message
+>
+> Port stage2 to use udev.
+
+BTW I think you broke LVM installs (lvm2 being stuck maybe due to missing
+/dev nodes: there's no /dev/vg* anymore)...
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011450.html b/zarb-ml/mageia-dev/2012-January/011450.html new file mode 100644 index 000000000..1635ed18e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011450.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] [soft-commits] [2494] Port stage2 to use udev. + + + + + + + + + +

[Mageia-dev] [soft-commits] [2494] Port stage2 to use udev.

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Jan 19 18:03:47 CET 2012 +

+
+ +
'Twas brillig, and Thierry Vignaud at 19/01/12 16:56 did gyre and gimble:
+> On 19 December 2011 23:47,  <root at mageia.org> wrote:
+>> Revision 2494 Author colin Date 2011-12-19 23:47:15 +0100 (Mon, 19 Dec 2011)
+>>
+>> Log Message
+>>
+>> Port stage2 to use udev.
+> 
+> BTW I think you broke LVM installs (lvm2 being stuck maybe due to missing
+> /dev nodes: there's no /dev/vg* anymore)...
+
+Nah, I don't think so as I tested LVM installs with /usr on LVM + ext2
+or btrfs and both seems fine...
+
+I'll check again tho'.
+
+
+Col
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011451.html b/zarb-ml/mageia-dev/2012-January/011451.html new file mode 100644 index 000000000..2d0f49f9b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011451.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] [soft-commits] [2494] Port stage2 to use udev. + + + + + + + + + +

[Mageia-dev] [soft-commits] [2494] Port stage2 to use udev.

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Thu Jan 19 18:36:29 CET 2012 +

+
+ +
On 19 January 2012 18:03, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+>>> Port stage2 to use udev.
+>>
+>> BTW I think you broke LVM installs (lvm2 being stuck maybe due to missing
+>> /dev nodes: there's no /dev/vg* anymore)...
+>
+> Nah, I don't think so as I tested LVM installs with /usr on LVM + ext2
+> or btrfs and both seems fine...
+
+Well It _does_ fail here.
+I think we miss /lib/udev/rules.d/10-dm.rules
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011452.html b/zarb-ml/mageia-dev/2012-January/011452.html new file mode 100644 index 000000000..8e41b5ae7 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011452.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] [soft-commits] [2494] Port stage2 to use udev. + + + + + + + + + +

[Mageia-dev] [soft-commits] [2494] Port stage2 to use udev.

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Thu Jan 19 18:56:27 CET 2012 +

+
+ +
On 19 January 2012 18:36, Thierry Vignaud <thierry.vignaud at gmail.com> wrote:
+>>>> Port stage2 to use udev.
+>>>
+>>> BTW I think you broke LVM installs (lvm2 being stuck maybe due to missing
+>>> /dev nodes: there's no /dev/vg* anymore)...
+>>
+>> Nah, I don't think so as I tested LVM installs with /usr on LVM + ext2
+>> or btrfs and both seems fine...
+>
+> Well It _does_ fail here.
+> I think we miss /lib/udev/rules.d/10-dm.rules
+
+We need all of:
+/lib/udev/rules.d/10-dm.rules
+/lib/udev/rules.d/13-dm-disk.rules
+/lib/udev/rules.d/11-dm-lvm.rules
+/lib/udev/rules.d/95-dm-notify.rules
+
+I'll dcommit & upload drakx with those
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011453.html b/zarb-ml/mageia-dev/2012-January/011453.html new file mode 100644 index 000000000..a51a4625e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011453.html @@ -0,0 +1,118 @@ + + + + [Mageia-dev] [soft-commits] [2494] Port stage2 to use udev. + + + + + + + + + +

[Mageia-dev] [soft-commits] [2494] Port stage2 to use udev.

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Jan 19 23:47:00 CET 2012 +

+
+ +
'Twas brillig, and Thierry Vignaud at 19/01/12 17:56 did gyre and gimble:
+> On 19 January 2012 18:36, Thierry Vignaud <thierry.vignaud at gmail.com> wrote:
+>>>>> Port stage2 to use udev.
+>>>>
+>>>> BTW I think you broke LVM installs (lvm2 being stuck maybe due to missing
+>>>> /dev nodes: there's no /dev/vg* anymore)...
+>>>
+>>> Nah, I don't think so as I tested LVM installs with /usr on LVM + ext2
+>>> or btrfs and both seems fine...
+>>
+>> Well It _does_ fail here.
+>> I think we miss /lib/udev/rules.d/10-dm.rules
+> 
+> We need all of:
+> /lib/udev/rules.d/10-dm.rules
+> /lib/udev/rules.d/13-dm-disk.rules
+> /lib/udev/rules.d/11-dm-lvm.rules
+> /lib/udev/rules.d/95-dm-notify.rules
+> 
+> I'll dcommit & upload drakx with those
+
+Awesome, thanks! I guess it worked as I created a *new* lvm? Perhaps if
+I'd tried to detect and modify an existing one it would have failed? Or
+maybe my testing just sucked?
+
+All the same, thanks for the fixes :)
+
+Col
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011454.html b/zarb-ml/mageia-dev/2012-January/011454.html new file mode 100644 index 000000000..c107dd202 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011454.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] [soft-commits] [2494] Port stage2 to use udev. + + + + + + + + + +

[Mageia-dev] [soft-commits] [2494] Port stage2 to use udev.

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Thu Jan 19 23:51:25 CET 2012 +

+
+ +
On 19 January 2012 23:47, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+>> We need all of:
+>> /lib/udev/rules.d/10-dm.rules
+>> /lib/udev/rules.d/13-dm-disk.rules
+>> /lib/udev/rules.d/11-dm-lvm.rules
+>> /lib/udev/rules.d/95-dm-notify.rules
+>>
+>> I'll dcommit & upload drakx with those
+>
+> Awesome, thanks! I guess it worked as I created a *new* lvm? Perhaps if
+> I'd tried to detect and modify an existing one it would have failed? Or
+> maybe my testing just sucked?
+>
+> All the same, thanks for the fixes :)
+
+BTW do you think we would need other rules for other cases?
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011455.html b/zarb-ml/mageia-dev/2012-January/011455.html new file mode 100644 index 000000000..ea05f105e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011455.html @@ -0,0 +1,113 @@ + + + + [Mageia-dev] [soft-commits] [2494] Port stage2 to use udev. + + + + + + + + + +

[Mageia-dev] [soft-commits] [2494] Port stage2 to use udev.

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Fri Jan 20 00:02:16 CET 2012 +

+
+ +
'Twas brillig, and Thierry Vignaud at 19/01/12 22:51 did gyre and gimble:
+> On 19 January 2012 23:47, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+>>> We need all of:
+>>> /lib/udev/rules.d/10-dm.rules
+>>> /lib/udev/rules.d/13-dm-disk.rules
+>>> /lib/udev/rules.d/11-dm-lvm.rules
+>>> /lib/udev/rules.d/95-dm-notify.rules
+>>>
+>>> I'll dcommit & upload drakx with those
+>>
+>> Awesome, thanks! I guess it worked as I created a *new* lvm? Perhaps if
+>> I'd tried to detect and modify an existing one it would have failed? Or
+>> maybe my testing just sucked?
+>>
+>> All the same, thanks for the fixes :)
+> 
+> BTW do you think we would need other rules for other cases?
+
+Maybe but they should probably already be listed in dracut modules I
+would have guessed? So maybe a quick grep there would be sufficient to
+cover most bases?
+
+Col
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011456.html b/zarb-ml/mageia-dev/2012-January/011456.html new file mode 100644 index 000000000..033caa94f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011456.html @@ -0,0 +1,121 @@ + + + + [Mageia-dev] [soft-commits] [2494] Port stage2 to use udev. + + + + + + + + + +

[Mageia-dev] [soft-commits] [2494] Port stage2 to use udev.

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Fri Jan 20 00:12:49 CET 2012 +

+
+ +
On 20 January 2012 00:02, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+>>>> We need all of:
+>>>> /lib/udev/rules.d/10-dm.rules
+>>>> /lib/udev/rules.d/13-dm-disk.rules
+>>>> /lib/udev/rules.d/11-dm-lvm.rules
+>>>> /lib/udev/rules.d/95-dm-notify.rules
+>>>>
+>>>> I'll dcommit & upload drakx with those
+>>>
+>>> Awesome, thanks! I guess it worked as I created a *new* lvm? Perhaps if
+>>> I'd tried to detect and modify an existing one it would have failed? Or
+>>> maybe my testing just sucked?
+>>>
+>>> All the same, thanks for the fixes :)
+>>
+>> BTW do you think we would need other rules for other cases?
+>
+> Maybe but they should probably already be listed in dracut modules I
+> would have guessed? So maybe a quick grep there would be sufficient to
+> cover most bases?
+
+It includes more :
+
+# lsinitrd /boot/initrd-3.2.1-desktop-1.mga2.img |fgrep .rules
+-rw-r--r--   1 root     root           68 Dec 15 09:19
+etc/udev/rules.d/01-ignore.rules
+-rw-r--r--   1 root     root          914 Dec 15 09:19
+etc/udev/rules.d/61-persistent-storage.rules
+-rw-r--r--   1 root     root          107 Dec 15 09:19
+etc/udev/rules.d/10-console.rules
+-rw-r--r--   1 root     root         1409 Dec 15 09:19
+etc/udev/rules.d/59-persistent-storage.rules
+-rw-r--r--   1 root     root         1060 Dec 20 14:29
+lib/udev/rules.d/60-pcmcia.rules
+-rw-r--r--   1 root     root          155 Jan 15 03:56
+lib/udev/rules.d/95-udev-late.rules
+-rw-r--r--   1 root     root         6056 Jan 15 03:56
+lib/udev/rules.d/60-persistent-storage.rules
+-rw-r--r--   1 root     root         1193 Jan 15 03:56
+lib/udev/rules.d/80-drivers.rules
+-rw-r--r--   1 root     root         3615 Jan 15 03:56
+lib/udev/rules.d/50-udev-default.rules
+-rw-r--r--   1 root     root          219 Jan 15 03:56
+lib/udev/rules.d/50-firmware.rules
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011457.html b/zarb-ml/mageia-dev/2012-January/011457.html new file mode 100644 index 000000000..839def2b5 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011457.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] Adding a new license to rpmlint + + + + + + + + + +

[Mageia-dev] Adding a new license to rpmlint

+ Juan Luis Baptiste + juancho at mageia.org +
+ Fri Jan 20 07:07:09 CET 2012 +

+
+ +
Hi,
+
+I have packaged Warsow[1], which it's engine is open source but as
+with other games I have packaged, the data files are licensed with a
+non-free license called "Warsow Content License" [2], which allows
+unmodified distribution of the data files in different formats like
+rpm, deb, etc (clause 3). I have imported the warsow and warsow-data
+packages to subversion but I haven't pushed them to the BS (to
+nonfree/release of course) because the data package will be rejected
+because of the license. It's feasible to add this license to rpmlint
+checks ? the other solution would be to make the game use
+autodownloader for the data files as I did for other games.
+
+Thanks,
+
+[1] http://www.warsow.net/
+[2] http://www.calculate-linux.org/packages/licenses/warsow
+
+-- 
+Juancho
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011458.html b/zarb-ml/mageia-dev/2012-January/011458.html new file mode 100644 index 000000000..39f12876d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011458.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] Adding a new license to rpmlint + + + + + + + + + +

[Mageia-dev] Adding a new license to rpmlint

+ Anssi Hannula + anssi at mageia.org +
+ Fri Jan 20 08:23:24 CET 2012 +

+
+ +
On 20.01.2012 08:07, Juan Luis Baptiste wrote:
+> Hi,
+> 
+> I have packaged Warsow[1], which it's engine is open source but as
+> with other games I have packaged, the data files are licensed with a
+> non-free license called "Warsow Content License" [2], which allows
+> unmodified distribution of the data files in different formats like
+> rpm, deb, etc (clause 3). I have imported the warsow and warsow-data
+> packages to subversion but I haven't pushed them to the BS (to
+> nonfree/release of course) because the data package will be rejected
+> because of the license. It's feasible to add this license to rpmlint
+> checks ? the other solution would be to make the game use
+> autodownloader for the data files as I did for other games.
+> 
+> Thanks,
+> 
+> [1] http://www.warsow.net/
+> [2] http://www.calculate-linux.org/packages/licenses/warsow
+> 
+
+It is a non-free redistributable license and should thus use the
+"Freeware" license tag, see:
+https://wiki.mageia.org/en/Licensing_policy
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011459.html b/zarb-ml/mageia-dev/2012-January/011459.html new file mode 100644 index 000000000..ce47eb74a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011459.html @@ -0,0 +1,89 @@ + + + + [Mageia-dev] Adding a new license to rpmlint + + + + + + + + + +

[Mageia-dev] Adding a new license to rpmlint

+ Juan Luis Baptiste + juancho at mageia.org +
+ Fri Jan 20 15:06:44 CET 2012 +

+
+ +
On Fri, Jan 20, 2012 at 2:23 AM, Anssi Hannula <anssi at mageia.org> wrote:
+>
+> It is a non-free redistributable license and should thus use the
+> "Freeware" license tag, see:
+> https://wiki.mageia.org/en/Licensing_policy
+>
+
+Ahh ok thanks, I'll fix and push to the BS then :)
+
+
+-- 
+Juancho
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011460.html b/zarb-ml/mageia-dev/2012-January/011460.html new file mode 100644 index 000000000..0b0cb560d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011460.html @@ -0,0 +1,111 @@ + + + + [Mageia-dev] Adding a new license to rpmlint + + + + + + + + + +

[Mageia-dev] Adding a new license to rpmlint

+ Juan Luis Baptiste + juancho at mageia.org +
+ Fri Jan 20 16:39:18 CET 2012 +

+
+ +
hmmmm pushed the first package, warsow, and got this build error but
+the message doesn't say much:
+
+Done. As root, type make install to install the library.
+make[1]: Leaving directory
+`/home/iurt/rpm/BUILD/warsow-0.61/libsrcs/angelscript/angelSVN/sdk/angelscript/projects/gnuc'
+> * Done building angelscript library.
+> *********************************************************
+> * Continuing angelwrap building...
+error: Bad exit status from /home/iurt/rpm/tmp/rpm-tmp.BsF5my (%build)
+
+Here is the build output:
+
+http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20120120142833.juancho.valstar.14706/log/botcmd.1327069742.jonund.log
+
+Any ideas ? I suppose I'm missing a BR but locally it builds fine.
+
+-- 
+Juancho
+
+
+On Fri, Jan 20, 2012 at 9:06 AM, Juan Luis Baptiste <juancho at mageia.org> wrote:
+> On Fri, Jan 20, 2012 at 2:23 AM, Anssi Hannula <anssi at mageia.org> wrote:
+>>
+>> It is a non-free redistributable license and should thus use the
+>> "Freeware" license tag, see:
+>> https://wiki.mageia.org/en/Licensing_policy
+>>
+>
+> Ahh ok thanks, I'll fix and push to the BS then :)
+>
+>
+> --
+> Juancho
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011461.html b/zarb-ml/mageia-dev/2012-January/011461.html new file mode 100644 index 000000000..a25dd885d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011461.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] Adding a new license to rpmlint + + + + + + + + + +

[Mageia-dev] Adding a new license to rpmlint

+ Balcaen John + mikala at mageia.org +
+ Fri Jan 20 17:13:17 CET 2012 +

+
+ +
On Friday 20 January 2012 10:39:18 Juan Luis Baptiste wrote :
+> hmmmm pushed the first package, warsow, and got this build error but
+> the message doesn't say much:
+> 
+> Done. As root, type make install to install the library.
+> make[1]: Leaving directory
+> `/home/iurt/rpm/BUILD/warsow-0.61/libsrcs/angelscript/angelSVN/sdk/angelscri
+> pt/projects/gnuc'
+> > * Done building angelscript library.
+> > *********************************************************
+> > * Continuing angelwrap building...
+> 
+> error: Bad exit status from /home/iurt/rpm/tmp/rpm-tmp.BsF5my (%build)
+> 
+g++: error: 
+../libsrcs/angelscript/angelSVN/sdk/angelscript/lib/libangelscript.a: No such 
+file or directory
+make: *** [release/libs/angelwrap_x86_64.so] Error 1
+
+The error seems to be here.
+
+
+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/2012-January/011462.html b/zarb-ml/mageia-dev/2012-January/011462.html new file mode 100644 index 000000000..c4dc68b65 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011462.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] Slow gnome-shell due to new cogl/clutter + + + + + + + + + +

[Mageia-dev] Slow gnome-shell due to new cogl/clutter

+ JA Magallón + jamagallon at ono.com +
+ Sat Jan 21 00:26:57 CET 2012 +

+
+ +
On 01/19/2012 03:09 PM, Olav Vitters wrote:
+> On Thu, Jan 19, 2012 at 01:59:07PM +0100, Olav Vitters wrote:
+>>   <ebassi>         but the layout loop seems to have been fixed
+>
+> He uploaded a new clutter, so I assume that fixes it. I've submitted it.
+>
+
+This did not fix the problem, but it looks that got fixed in gnome-shell GIT:
+
+http://ubuntuforums.org/showthread.php?t=1910576
+
+I lokeed at GIT repo for gnome-shell, and the latest commit is to require
+updated GTK3 and GLIB. Latest are glib-2.31.12 and gtk+-3.3.10 (se have
+2.31.10 and 3.3.8 in Cauldron now).
+As next gnone-shell version will require them, I think it is a good time to
+update, and looks safe wrt rest of apps....
+
+
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011463.html b/zarb-ml/mageia-dev/2012-January/011463.html new file mode 100644 index 000000000..e47832982 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011463.html @@ -0,0 +1,124 @@ + + + + [Mageia-dev] Adding a new license to rpmlint + + + + + + + + + +

[Mageia-dev] Adding a new license to rpmlint

+ andre999 + andre999mga at laposte.net +
+ Sat Jan 21 00:36:43 CET 2012 +

+
+ +
Anssi Hannula a écrit :
+> On 20.01.2012 08:07, Juan Luis Baptiste wrote:
+>    
+>> Hi,
+>>
+>> I have packaged Warsow[1], which it's engine is open source but as
+>> with other games I have packaged, the data files are licensed with a
+>> non-free license called "Warsow Content License" [2], which allows
+>> unmodified distribution of the data files in different formats like
+>> rpm, deb, etc (clause 3). I have imported the warsow and warsow-data
+>> packages to subversion but I haven't pushed them to the BS (to
+>> nonfree/release of course) because the data package will be rejected
+>> because of the license. It's feasible to add this license to rpmlint
+>> checks ? the other solution would be to make the game use
+>> autodownloader for the data files as I did for other games.
+>>
+>> Thanks,
+>>
+>> [1]http://www.warsow.net/
+>> [2]http://www.calculate-linux.org/packages/licenses/warsow
+>>
+>>      
+> It is a non-free redistributable license and should thus use the
+> "Freeware" license tag, see:
+> https://wiki.mageia.org/en/Licensing_policy
+>
+>    
+Note that the definition given for "Shareware" doesn't seem to include 
+the usual case where the entire software is distributed for usage for a 
+limited time.  After paying a fee, the user is given a code which 
+permits longer-term usage, and often activates additional functions.
+
+So I would suggest changing the wording from :
+"Shareware refers to software of which only a subsidiary portion can be 
+redistributed without charge; access to the complete package requires 
+payment to the copyright holder or another body."
+
+to :
+"Shareware refers to software redistibutable without charge, which 
+requires payment to the copyright holder or another body in order to use 
+beyond a trial period and/or to obtain additional functionality."
+
+Does that sound ok ?
+
+-- 
+André
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011464.html b/zarb-ml/mageia-dev/2012-January/011464.html new file mode 100644 index 000000000..0b2b79f32 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011464.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] HAL daemon required for Mageia 2 alpha 3 + + + + + + + + + +

[Mageia-dev] HAL daemon required for Mageia 2 alpha 3

+ Pierre Jarillon + jarillon at abul.org +
+ Sat Jan 21 01:28:38 CET 2012 +

+
+ +
I have burn a DVD and make a fresh install in french.
+
+At the end of installation, I have asked yes for the updates.
+The bunch of hdlists was installed, bu nothing was updated.
+
+After the reboot, any urpmi fails with "Daemon HAL (hald) not ready or 
+available" (free translation)
+
+I have manualy downloaded hal and its dependances (crypsetup, usbutils, hal-
+info, lib64hal1, lib64crypsetup4) and start hald. Then update was possible  
+for more than 300 rpm.
+
+Upgrade from a previous alpha release seems to have no problem because hal is 
+already installed. 
+
+I thought that hal was no longer needed... Am I wrong?
+
+-- 
+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/2012-January/011465.html b/zarb-ml/mageia-dev/2012-January/011465.html new file mode 100644 index 000000000..1a456e3b3 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011465.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] HAL daemon required for Mageia 2 alpha 3 + + + + + + + + + +

[Mageia-dev] HAL daemon required for Mageia 2 alpha 3

+ Pascal Terjan + pterjan at gmail.com +
+ Sat Jan 21 02:06:14 CET 2012 +

+
+ +
On Sat, Jan 21, 2012 at 00:28, Pierre Jarillon <jarillon at abul.org> wrote:
+> I have burn a DVD and make a fresh install in french.
+>
+> At the end of installation, I have asked yes for the updates.
+> The bunch of hdlists was installed, bu nothing was updated.
+>
+> After the reboot, any urpmi fails with "Daemon HAL (hald) not ready or
+> available" (free translation)
+>
+> I have manualy downloaded hal and its dependances (crypsetup, usbutils, hal-
+> info, lib64hal1, lib64crypsetup4) and start hald. Then update was possible
+> for more than 300 rpm.
+>
+> Upgrade from a previous alpha release seems to have no problem because hal is
+> already installed.
+>
+> I thought that hal was no longer needed... Am I wrong?
+
+It is still used by urpmi to search cd drive :(
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011466.html b/zarb-ml/mageia-dev/2012-January/011466.html new file mode 100644 index 000000000..299edebab --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011466.html @@ -0,0 +1,111 @@ + + + + [Mageia-dev] [packages-commits] [198909] SILENT : fix post&postun + + + + + + + + + +

[Mageia-dev] [packages-commits] [198909] SILENT : fix post&postun

+ D.Morgan + dmorganec at gmail.com +
+ Sat Jan 21 03:21:42 CET 2012 +

+
+ +
On Sat, Jan 21, 2012 at 3:14 AM,  <root at mageia.org> wrote:
+> Revision 198909 Author kamil Date 2012-01-21 03:14:08 +0100 (Sat, 21 Jan
+> 2012)
+>
+> Log Message
+>
+> SILENT : fix post&postun
+>
+> Modified Paths
+>
+> cauldron/libserializer/current/SPECS/libserializer.spec
+>
+> Modified: cauldron/libserializer/current/SPECS/libserializer.spec
+> ===================================================================
+> --- cauldron/libserializer/current/SPECS/libserializer.spec	2012-01-21
+> 02:09:25 UTC (rev 198908)
+> +++ cauldron/libserializer/current/SPECS/libserializer.spec	2012-01-21
+> 02:14:08 UTC (rev 198909)
+> @@ -69,16 +69,16 @@
+>  %{_bindir}/aot-compile-rpm
+>  %endif
+>
+> +%if %{with_gcj}
+>  %post
+> -%if %{with_gcj}
+>  if [ -x %{_bindir}/rebuild-gcj-db ]
+>  then
+>    %{_bindir}/rebuild-gcj-db
+>  fi
+>  %endif
+>
+
+i think you can remove gcj support ( as fedora does )
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011467.html b/zarb-ml/mageia-dev/2012-January/011467.html new file mode 100644 index 000000000..db528996c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011467.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] Adding a new license to rpmlint + + + + + + + + + +

[Mageia-dev] Adding a new license to rpmlint

+ Johnny A. Solbu + cooker at solbu.net +
+ Sat Jan 21 03:45:21 CET 2012 +

+
+ +
On Saturday 21 January 2012 00:36, andre999 wrote:
+> Does that sound ok ?
+
+In my opinion, yes.
+It is more accurate then the current text.
+
+-- 
+Johnny A. Solbu
+PGP key ID: 0xFA687324
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 189 bytes
+Desc: This is a digitally signed message part.
+URL: </pipermail/mageia-dev/attachments/20120121/3274dba0/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011468.html b/zarb-ml/mageia-dev/2012-January/011468.html new file mode 100644 index 000000000..06984c817 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011468.html @@ -0,0 +1,82 @@ + + + + [Mageia-dev] [packages-commits] [198909] SILENT : fix post&postun + + + + + + + + + +

[Mageia-dev] [packages-commits] [198909] SILENT : fix post&postun

+ Kamil Rytarowski + n54 at gmx.com +
+ Sat Jan 21 04:20:10 CET 2012 +

+
+ +
W dniu 21.01.2012 03:21, D.Morgan pisze:
+> On Sat, Jan 21, 2012 at 3:14 AM,<root at mageia.org>  wrote:
+> i think you can remove gcj support ( as fedora does )
+done!
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011469.html b/zarb-ml/mageia-dev/2012-January/011469.html new file mode 100644 index 000000000..e42a0b503 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011469.html @@ -0,0 +1,84 @@ + + + + [Mageia-dev] BS down or distrib-coffee down？ + + + + + + + + + +

[Mageia-dev] BS down or distrib-coffee down？

+ Funda Wang + fundawang at gmail.com +
+ Sat Jan 21 08:23:31 CET 2012 +

+
+ +
It seems that packages marked as uploaded won't appear in distrib-coffee,
+for at least two hours. Is it the problem with newly introduced youri
+peroid, or just distrib-coffee was lazy now?
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20120121/17eed097/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011470.html b/zarb-ml/mageia-dev/2012-January/011470.html new file mode 100644 index 000000000..af3ede42f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011470.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] BS down or distrib-coffee down？ + + + + + + + + + +

[Mageia-dev] BS down or distrib-coffee down？

+ Pascal Terjan + pterjan at gmail.com +
+ Sat Jan 21 09:33:01 CET 2012 +

+
+ +
On Sat, Jan 21, 2012 at 07:23, Funda Wang <fundawang at gmail.com> wrote:
+> It seems that packages marked as uploaded won't appear in distrib-coffee,
+> for at least two hours. Is it the problem with newly introduced youri
+> peroid, or just distrib-coffee was lazy now?
+
+This "youri" is just some more information on the web interface, as it
+was marked uploaded too early.
+Upload process did not change.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011471.html b/zarb-ml/mageia-dev/2012-January/011471.html new file mode 100644 index 000000000..a7be2e51a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011471.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] Slow gnome-shell due to new cogl/clutter + + + + + + + + + +

[Mageia-dev] Slow gnome-shell due to new cogl/clutter

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Sat Jan 21 09:55:09 CET 2012 +

+
+ +
'Twas brillig, and JA Magallón at 20/01/12 23:26 did gyre and gimble:
+> On 01/19/2012 03:09 PM, Olav Vitters wrote:
+>> On Thu, Jan 19, 2012 at 01:59:07PM +0100, Olav Vitters wrote:
+>>>   <ebassi>         but the layout loop seems to have been fixed
+>>
+>> He uploaded a new clutter, so I assume that fixes it. I've submitted it.
+>>
+> 
+> This did not fix the problem, but it looks that got fixed in gnome-shell
+> GIT:
+> 
+> http://ubuntuforums.org/showthread.php?t=1910576
+> 
+> I lokeed at GIT repo for gnome-shell, and the latest commit is to require
+> updated GTK3 and GLIB. Latest are glib-2.31.12 and gtk+-3.3.10 (se have
+> 2.31.10 and 3.3.8 in Cauldron now).
+> As next gnone-shell version will require them, I think it is a good time to
+> update, and looks safe wrt rest of apps....
+
+Yup, now seems like a good time to push this.
+
+Col
+
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011472.html b/zarb-ml/mageia-dev/2012-January/011472.html new file mode 100644 index 000000000..83f82c740 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011472.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] HAL daemon required for Mageia 2 alpha 3 + + + + + + + + + +

[Mageia-dev] HAL daemon required for Mageia 2 alpha 3

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Sat Jan 21 10:57:23 CET 2012 +

+
+ +
2012/1/21 Pascal Terjan <pterjan at gmail.com>:
+> On Sat, Jan 21, 2012 at 00:28, Pierre Jarillon <jarillon at abul.org> wrote:
+>> I have burn a DVD and make a fresh install in french.
+>>
+>> At the end of installation, I have asked yes for the updates.
+>> The bunch of hdlists was installed, bu nothing was updated.
+>>
+>> After the reboot, any urpmi fails with "Daemon HAL (hald) not ready or
+>> available" (free translation)
+>>
+>> I have manualy downloaded hal and its dependances (crypsetup, usbutils, hal-
+>> info, lib64hal1, lib64crypsetup4) and start hald. Then update was possible
+>> for more than 300 rpm.
+>>
+>> Upgrade from a previous alpha release seems to have no problem because hal is
+>> already installed.
+>>
+>> I thought that hal was no longer needed... Am I wrong?
+>
+> It is still used by urpmi to search cd drive :(
+
+This is also a bug in the error message. You also get this message,
+when you have _no_ repos configured (not even a local cd or dvd)
+instead of saying "You have to configure your repos first".
+
+Oliver
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011473.html b/zarb-ml/mageia-dev/2012-January/011473.html new file mode 100644 index 000000000..9c307641f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011473.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] Upgrade to KDE 4.7.95 breaks the desktop + + + + + + + + + +

[Mageia-dev] Upgrade to KDE 4.7.95 breaks the desktop

+ Balcaen John + mikala at mageia.org +
+ Sat Jan 21 13:09:36 CET 2012 +

+
+ +
On Wednesday 28 December 2011 12:21:21 Balcaen John wrote :
+[...]
+> 
+> Currently i don't know, i don't know why it did not happens during the
+> 4.7.90 transition :/
+> Anyway of course we'll look & check how it could be fixed.
+> (It could be related in fact to some configuration changes like for dolphin
+> for example).
+Ok just for memory  it should be fixed with our  kdelibs 4.8.0 package , 
+reverting a specific commit allows now plasma to read again plasma-applets-
+desktoprc so panel won't disapear but as usual there's a side effects : if you 
+did fix this issue by simply adding a *new* panel (& not removing the 
+~/.kde4/share/config/plasma* files) you'll get a bonus panel :p
+This issue is a specific cauldron one.
+
+
+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/2012-January/011474.html b/zarb-ml/mageia-dev/2012-January/011474.html new file mode 100644 index 000000000..2818889e3 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011474.html @@ -0,0 +1,81 @@ + + + + [Mageia-dev] Slow gnome-shell due to new cogl/clutter + + + + + + + + + +

[Mageia-dev] Slow gnome-shell due to new cogl/clutter

+ Olav Vitters + olav at vitters.nl +
+ Sat Jan 21 13:16:53 CET 2012 +

+
+ +
On Sat, Jan 21, 2012 at 12:26:57AM +0100, JA Magallón wrote:
+> This did not fix the problem, but it looks that got fixed in gnome-shell GIT:
+> 
+> http://ubuntuforums.org/showthread.php?t=1910576
+
+Please test for me, atm unable to do so :-(
+
+Newer stuff has been packaged..
+
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011475.html b/zarb-ml/mageia-dev/2012-January/011475.html new file mode 100644 index 000000000..3b7405465 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011475.html @@ -0,0 +1,89 @@ + + + + [Mageia-dev] Upgrade to KDE 4.7.95 breaks the desktop + + + + + + + + + +

[Mageia-dev] Upgrade to KDE 4.7.95 breaks the desktop

+ Rémi Verschelde + remi at verschelde.fr +
+ Sat Jan 21 13:43:49 CET 2012 +

+
+ +
2012/1/21 Balcaen John <mikala at mageia.org>:
+> Ok just for memory  it should be fixed with our  kdelibs 4.8.0 package ,
+> reverting a specific commit allows now plasma to read again plasma-applets-
+> desktoprc so panel won't disapear but as usual there's a side effects : if you
+> did fix this issue by simply adding a *new* panel (& not removing the
+> ~/.kde4/share/config/plasma* files) you'll get a bonus panel :p
+> This issue is a specific cauldron one.
+>
+Indeed, I just got my previous desktop back. I was wondering why my 4
+desktops were displayed in one line today whereas I had them in a 2x2
+square lately. Now I have the answer, these are my previous settings.
+:)
+
+Rémi / Akien
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011476.html b/zarb-ml/mageia-dev/2012-January/011476.html new file mode 100644 index 000000000..5eb15ec77 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011476.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] Upgrade to KDE 4.7.95 breaks the desktop + + + + + + + + + +

[Mageia-dev] Upgrade to KDE 4.7.95 breaks the desktop

+ Balcaen John + mikala at mageia.org +
+ Sat Jan 21 14:01:10 CET 2012 +

+
+ +
On Saturday 21 January 2012 13:43:49 Rémi Verschelde wrote :
+> 2012/1/21 Balcaen John <mikala at mageia.org>:
+> > Ok just for memory  it should be fixed with our  kdelibs 4.8.0 package ,
+> > reverting a specific commit allows now plasma to read again
+> > plasma-applets-
+> > desktoprc so panel won't disapear but as usual there's a side effects : if
+> > you did fix this issue by simply adding a *new* panel (& not removing the
+> > ~/.kde4/share/config/plasma* files) you'll get a bonus panel :p
+> > This issue is a specific cauldron one.
+> 
+> Indeed, I just got my previous desktop back. I was wondering why my 4
+> desktops were displayed in one line today whereas I had them in a 2x2
+> square lately. Now I have the answer, these are my previous settings.
+> 
+hum ?
+this strange here  because i did not push kde at all or maybe you did already 
+build kde from svn ? :)
+Here i'm talking about an additional panel not about some options on the 
+current panel.
+
+
+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/2012-January/011477.html b/zarb-ml/mageia-dev/2012-January/011477.html new file mode 100644 index 000000000..0854d6c5d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011477.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] Upgrade to KDE 4.7.95 breaks the desktop + + + + + + + + + +

[Mageia-dev] Upgrade to KDE 4.7.95 breaks the desktop

+ Rémi Verschelde + remi at verschelde.fr +
+ Sat Jan 21 14:15:00 CET 2012 +

+
+ +
2012/1/21 Balcaen John <mikala at mageia.org>:
+> On Saturday 21 January 2012 13:43:49 Rémi Verschelde wrote :
+>> Indeed, I just got my previous desktop back. I was wondering why my 4
+>> desktops were displayed in one line today whereas I had them in a 2x2
+>> square lately. Now I have the answer, these are my previous settings.
+>>
+> hum ?
+> this strange here  because i did not push kde at all or maybe you did already
+> build kde from svn ? :)
+> Here i'm talking about an additional panel not about some options on the
+> current panel.
+>
+Ah? I must be mistaken then. I only do the updates as soon as they are
+pushed for Cauldron, so I did not build anything. I just had this
+strange feeling about having my desktops previously in a 4x4 square
+and in line today, so I thought this was the explanation. But then it
+must come from something else (or I am totally making memories up ^^).
+
+Regards,
+Rémi / Akien
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011478.html b/zarb-ml/mageia-dev/2012-January/011478.html new file mode 100644 index 000000000..e53cef69f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011478.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] Too many tmp directories + + + + + + + + + +

[Mageia-dev] Too many tmp directories

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Sat Jan 21 18:21:14 CET 2012 +

+
+ +
Hi,
+
+while searching for some strange KDE behaviour (see bug 107 about
+those icons), I found at least three different tmp directories:
+/tmp/
+/var/tmp/
+~/tmp/ (one for every user)
+
+Now I can understand the reason behind having the user's tmp
+separately, but why do we have two system wide separate tmp
+directories?
+This get's even more complicated by the fact that there are symbolic
+links in .kde4/ to both:
+lrwxrwxrwx 1 oli oli   21 Okt  7 10:34 cache-beteigeuze.oli-home ->
+/var/tmp/kdecache-oli/
+lrwxrwxrwx 1 oli oli   16 Okt  7 10:34 socket-beteigeuze.oli-home ->
+/tmp/ksocket-oli/
+lrwxrwxrwx 1 oli oli   12 Okt  7 10:34 tmp-beteigeuze.oli-home -> /tmp/kde-oli/
+
+Can't we do something about that?
+
+Thanks, Oliver
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011479.html b/zarb-ml/mageia-dev/2012-January/011479.html new file mode 100644 index 000000000..76b1d4bbd --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011479.html @@ -0,0 +1,134 @@ + + + + [Mageia-dev] Too many tmp directories + + + + + + + + + +

[Mageia-dev] Too many tmp directories

+ eatdirt + dirteat at gmail.com +
+ Sat Jan 21 18:35:27 CET 2012 +

+
+ +
On 21/01/12 18:21, Oliver Burger wrote:
+>I found at least three different tmp directories:
+> /tmp/
+> /var/tmp/
+> ~/tmp/ (one for every user)
+
+
+Hi,
+I am taking the opportunity of this thread to also mention the 
+incredible number of shit mounted by systemd that completely render the 
+output of a mount command unreadable :)
+
+ > mount
+
+
+rootfs on / type rootfs (rw)
+proc on /proc type proc (rw,relatime)
+sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
+devtmpfs on /dev type devtmpfs 
+(rw,nosuid,relatime,size=1018236k,nr_inodes=254559,mode=755)
+devpts on /dev/pts type devpts 
+(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
+tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,relatime)
+/dev/sda1 on / type ext4 (rw,relatime,user_xattr,acl,barrier=1,data=ordered)
+/dev/sda7 on /usr type ext4 
+(rw,relatime,user_xattr,acl,barrier=1,data=ordered)
+tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
+tmpfs on /sys/fs/cgroup type tmpfs 
+(rw,nosuid,nodev,noexec,relatime,mode=755)
+cgroup on /sys/fs/cgroup/systemd type cgroup 
+(rw,nosuid,nodev,noexec,relatime,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
+cgroup on /sys/fs/cgroup/cpuset type cgroup 
+(rw,nosuid,nodev,noexec,relatime,cpuset)
+cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup 
+(rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
+cgroup on /sys/fs/cgroup/memory type cgroup 
+(rw,nosuid,nodev,noexec,relatime,memory)
+cgroup on /sys/fs/cgroup/devices type cgroup 
+(rw,nosuid,nodev,noexec,relatime,devices)
+cgroup on /sys/fs/cgroup/freezer type cgroup 
+(rw,nosuid,nodev,noexec,relatime,freezer)
+cgroup on /sys/fs/cgroup/net_cls type cgroup 
+(rw,nosuid,nodev,noexec,relatime,net_cls)
+cgroup on /sys/fs/cgroup/blkio type cgroup 
+(rw,nosuid,nodev,noexec,relatime,blkio)
+systemd-1 on /proc/sys/fs/binfmt_misc type autofs 
+(rw,relatime,fd=26,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
+mqueue on /dev/mqueue type mqueue (rw,relatime)
+hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
+debugfs on /sys/kernel/debug type debugfs (rw,relatime)
+securityfs on /sys/kernel/security type securityfs (rw,relatime)
+tmpfs on /media type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)
+/dev/sda8 on /opt type ext4 
+(rw,relatime,user_xattr,acl,barrier=1,data=ordered)
+/dev/sda6 on /home type ext3 
+(rw,relatime,errors=continue,user_xattr,acl,commit=5,barrier=1,data=ordered)
+fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
+
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011480.html b/zarb-ml/mageia-dev/2012-January/011480.html new file mode 100644 index 000000000..dd961543e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011480.html @@ -0,0 +1,117 @@ + + + + [Mageia-dev] Too many tmp directories + + + + + + + + + +

[Mageia-dev] Too many tmp directories

+ Balcaen John + mikala at mageia.org +
+ Sat Jan 21 18:35:39 CET 2012 +

+
+ +
On Saturday 21 January 2012 18:21:14 Oliver Burger wrote :
+> Hi,
+> 
+> while searching for some strange KDE behaviour (see bug 107 about
+> those icons), I found at least three different tmp directories:
+> /tmp/
+> /var/tmp/
+> ~/tmp/ (one for every user)
+> 
+> Now I can understand the reason behind having the user's tmp
+> separately, but why do we have two system wide separate tmp
+> directories?
+> This get's even more complicated by the fact that there are symbolic
+> links in .kde4/ to both:
+> lrwxrwxrwx 1 oli oli   21 Okt  7 10:34 cache-beteigeuze.oli-home ->
+> /var/tmp/kdecache-oli/
+> lrwxrwxrwx 1 oli oli   16 Okt  7 10:34 socket-beteigeuze.oli-home ->
+> /tmp/ksocket-oli/
+> lrwxrwxrwx 1 oli oli   12 Okt  7 10:34 tmp-beteigeuze.oli-home ->
+> /tmp/kde-oli/
+> 
+> Can't we do something about that?
+Probably
+in fact it simply follow 
+http://techbase.kde.org/KDE_System_Administration/KDE_Filesystem_Hierarchy.
+
+However i don't know if it's wise to setup the same path for thoses variables 
+(it's possible).
+
+
+
+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/2012-January/011481.html b/zarb-ml/mageia-dev/2012-January/011481.html new file mode 100644 index 000000000..b1b1b1de4 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011481.html @@ -0,0 +1,82 @@ + + + + [Mageia-dev] [packages-commits] [198909] SILENT : fix post&postun + + + + + + + + + +

[Mageia-dev] [packages-commits] [198909] SILENT : fix post&postun

+ D.Morgan + dmorganec at gmail.com +
+ Sat Jan 21 19:19:58 CET 2012 +

+
+ +
On Sat, Jan 21, 2012 at 4:20 AM, Kamil Rytarowski <n54 at gmx.com> wrote:
+> W dniu 21.01.2012 03:21, D.Morgan pisze:
+>>
+>> On Sat, Jan 21, 2012 at 3:14 AM,<root at mageia.org>  wrote:
+>> i think you can remove gcj support ( as fedora does )
+>
+> done!
+
+thank you a lot
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011482.html b/zarb-ml/mageia-dev/2012-January/011482.html new file mode 100644 index 000000000..b6fbaa0ab --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011482.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] Too many tmp directories + + + + + + + + + +

[Mageia-dev] Too many tmp directories

+ andre999 + andre999mga at laposte.net +
+ Sat Jan 21 19:59:28 CET 2012 +

+
+ +
Oliver Burger a écrit :
+> Hi,
+>
+> while searching for some strange KDE behaviour (see bug 107 about
+> those icons), I found at least three different tmp directories:
+> /tmp/
+> /var/tmp/
+> ~/tmp/ (one for every user)
+>
+>    
+[...]
+
+> Can't we do something about that?
+>
+> Thanks, Oliver
+>    
+
+Sounds like a good idea.
+It might be better to get rid of /tmp if we can, since systems would 
+always have a read-write /var and thus /var/tmp, even if they have a 
+read-only /.
+
+-- 
+André
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011483.html b/zarb-ml/mageia-dev/2012-January/011483.html new file mode 100644 index 000000000..fbc46d14f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011483.html @@ -0,0 +1,176 @@ + + + + [Mageia-dev] Too many tmp directories + + + + + + + + + +

[Mageia-dev] Too many tmp directories

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Sat Jan 21 20:06:54 CET 2012 +

+
+ +
'Twas brillig, and eatdirt at 21/01/12 17:35 did gyre and gimble:
+> On 21/01/12 18:21, Oliver Burger wrote:
+>> I found at least three different tmp directories:
+>> /tmp/
+>> /var/tmp/
+>> ~/tmp/ (one for every user)
+> 
+> 
+> Hi,
+> I am taking the opportunity of this thread to also mention the
+> incredible number of shit mounted by systemd that completely render the
+> output of a mount command unreadable :)
+> 
+>> mount
+> 
+> 
+> rootfs on / type rootfs (rw)
+> proc on /proc type proc (rw,relatime)
+> sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
+> devtmpfs on /dev type devtmpfs
+> (rw,nosuid,relatime,size=1018236k,nr_inodes=254559,mode=755)
+> devpts on /dev/pts type devpts
+> (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
+> tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,relatime)
+> /dev/sda1 on / type ext4
+> (rw,relatime,user_xattr,acl,barrier=1,data=ordered)
+> /dev/sda7 on /usr type ext4
+> (rw,relatime,user_xattr,acl,barrier=1,data=ordered)
+> tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
+> tmpfs on /sys/fs/cgroup type tmpfs
+> (rw,nosuid,nodev,noexec,relatime,mode=755)
+> cgroup on /sys/fs/cgroup/systemd type cgroup
+> (rw,nosuid,nodev,noexec,relatime,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
+> 
+> cgroup on /sys/fs/cgroup/cpuset type cgroup
+> (rw,nosuid,nodev,noexec,relatime,cpuset)
+> cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup
+> (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
+> cgroup on /sys/fs/cgroup/memory type cgroup
+> (rw,nosuid,nodev,noexec,relatime,memory)
+> cgroup on /sys/fs/cgroup/devices type cgroup
+> (rw,nosuid,nodev,noexec,relatime,devices)
+> cgroup on /sys/fs/cgroup/freezer type cgroup
+> (rw,nosuid,nodev,noexec,relatime,freezer)
+> cgroup on /sys/fs/cgroup/net_cls type cgroup
+> (rw,nosuid,nodev,noexec,relatime,net_cls)
+> cgroup on /sys/fs/cgroup/blkio type cgroup
+> (rw,nosuid,nodev,noexec,relatime,blkio)
+> systemd-1 on /proc/sys/fs/binfmt_misc type autofs
+> (rw,relatime,fd=26,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
+> mqueue on /dev/mqueue type mqueue (rw,relatime)
+> hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
+> debugfs on /sys/kernel/debug type debugfs (rw,relatime)
+> securityfs on /sys/kernel/security type securityfs (rw,relatime)
+> tmpfs on /media type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)
+> /dev/sda8 on /opt type ext4
+> (rw,relatime,user_xattr,acl,barrier=1,data=ordered)
+> /dev/sda6 on /home type ext3
+> (rw,relatime,errors=continue,user_xattr,acl,commit=5,barrier=1,data=ordered)
+> 
+> fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
+
+
+What's wrong with this? It's showing you the mounts that are active...
+would you rather it filtered out e.g. /sys etc?
+
+There are other commands you can use other than mount... e.g. df
+
+[colin at jimmy ~]$ df
+Filesystem                                 Size  Used Avail Use% Mounted on
+rootfs                                      15G   12G  2.1G  85% /
+devtmpfs                                   1.6G     0  1.6G   0% /dev
+tmpfs                                      1.6G  804K  1.6G   1% /dev/shm
+/dev/mapper/solidstate-slash                15G   12G  2.1G  85% /
+tmpfs                                      1.6G  3.2M  1.6G   1% /run
+tmpfs                                      1.6G     0  1.6G   0%
+/sys/fs/cgroup
+tmpfs                                      1.6G     0  1.6G   0% /media
+/dev/mapper/solidstate-home                130G  128G  1.6G  99% /home
+/dev/sda2                                   85M   47M   34M  59% /boot
+
+
+Generally speaking df is a more useful command than mount IMO anyway,
+and it's always been the command I use when I'm just wanting a quick
+overview.
+
+Col
+
+
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011484.html b/zarb-ml/mageia-dev/2012-January/011484.html new file mode 100644 index 000000000..16e629b23 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011484.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] Too many tmp directories + + + + + + + + + +

[Mageia-dev] Too many tmp directories

+ Sander Lepik + sander.lepik at eesti.ee +
+ Sat Jan 21 20:06:18 CET 2012 +

+
+ +
21.01.2012 20:59, andre999 kirjutas:
+>
+> Sounds like a good idea.
+> It might be better to get rid of /tmp if we can, since systems would always have a 
+> read-write /var and thus /var/tmp, even if they have a read-only /.
+>
+AFAIK even Flash Player uses /tmp to download content. Probably some other external programs 
+too. IMHO it's not good idea to remove longstanding system directories.
+
+--
+Sander
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011485.html b/zarb-ml/mageia-dev/2012-January/011485.html new file mode 100644 index 000000000..a497d043d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011485.html @@ -0,0 +1,118 @@ + + + + [Mageia-dev] Too many tmp directories + + + + + + + + + +

[Mageia-dev] Too many tmp directories

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Sat Jan 21 20:07:54 CET 2012 +

+
+ +
'Twas brillig, and Oliver Burger at 21/01/12 17:21 did gyre and gimble:
+> Hi,
+> 
+> while searching for some strange KDE behaviour (see bug 107 about
+> those icons), I found at least three different tmp directories:
+> /tmp/
+> /var/tmp/
+> ~/tmp/ (one for every user)
+> 
+> Now I can understand the reason behind having the user's tmp
+> separately, but why do we have two system wide separate tmp
+> directories?
+> This get's even more complicated by the fact that there are symbolic
+> links in .kde4/ to both:
+> lrwxrwxrwx 1 oli oli   21 Okt  7 10:34 cache-beteigeuze.oli-home ->
+> /var/tmp/kdecache-oli/
+> lrwxrwxrwx 1 oli oli   16 Okt  7 10:34 socket-beteigeuze.oli-home ->
+> /tmp/ksocket-oli/
+> lrwxrwxrwx 1 oli oli   12 Okt  7 10:34 tmp-beteigeuze.oli-home -> /tmp/kde-oli/
+
+Can you not just symlink /tmp to /var/tmp?
+
+Col
+
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011486.html b/zarb-ml/mageia-dev/2012-January/011486.html new file mode 100644 index 000000000..1bd1a61d0 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011486.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] Slow gnome-shell due to new cogl/clutter + + + + + + + + + +

[Mageia-dev] Slow gnome-shell due to new cogl/clutter

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Sat Jan 21 20:21:37 CET 2012 +

+
+ +
'Twas brillig, and Olav Vitters at 21/01/12 12:16 did gyre and gimble:
+> On Sat, Jan 21, 2012 at 12:26:57AM +0100, JA Magallón wrote:
+>> This did not fix the problem, but it looks that got fixed in gnome-shell GIT:
+>>
+>> http://ubuntuforums.org/showthread.php?t=1910576
+> 
+> Please test for me, atm unable to do so :-(
+> 
+> Newer stuff has been packaged..
+
+Do I need to rebuild anything locally for testing? Tried a fully updated
+system (new gtk, new g-s) and it's still busted :(
+
+Col
+
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011487.html b/zarb-ml/mageia-dev/2012-January/011487.html new file mode 100644 index 000000000..ec9af5a8a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011487.html @@ -0,0 +1,112 @@ + + + + [Mageia-dev] Too many tmp directories + + + + + + + + + +

[Mageia-dev] Too many tmp directories

+ andre999 + andre999mga at laposte.net +
+ Sat Jan 21 20:21:43 CET 2012 +

+
+ +
Colin Guthrie a écrit :
+> 'Twas brillig, and Oliver Burger at 21/01/12 17:21 did gyre and gimble:
+>    
+>> Hi,
+>>
+>> while searching for some strange KDE behaviour (see bug 107 about
+>> those icons), I found at least three different tmp directories:
+>> /tmp/
+>> /var/tmp/
+>> ~/tmp/ (one for every user)
+>>
+>> Now I can understand the reason behind having the user's tmp
+>> separately, but why do we have two system wide separate tmp
+>> directories?
+>> This get's even more complicated by the fact that there are symbolic
+>> links in .kde4/ to both:
+>> lrwxrwxrwx 1 oli oli   21 Okt  7 10:34 cache-beteigeuze.oli-home ->
+>> /var/tmp/kdecache-oli/
+>> lrwxrwxrwx 1 oli oli   16 Okt  7 10:34 socket-beteigeuze.oli-home ->
+>> /tmp/ksocket-oli/
+>> lrwxrwxrwx 1 oli oli   12 Okt  7 10:34 tmp-beteigeuze.oli-home ->  /tmp/kde-oli/
+>>      
+> Can you not just symlink /tmp to /var/tmp?
+>
+> Col
+>    
+
++1
+
+-- 
+André
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011488.html b/zarb-ml/mageia-dev/2012-January/011488.html new file mode 100644 index 000000000..fd20b7f75 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011488.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] Too many tmp directories + + + + + + + + + +

[Mageia-dev] Too many tmp directories

+ Dick Gevers + dvgevers at xs4all.nl +
+ Sat Jan 21 20:15:30 CET 2012 +

+
+ +
On Sat, 21 Jan 2012 18:21:14 +0100, Oliver Burger wrote about [Mageia-dev]
+Too many tmp directories:
+
+>Hi,
+>
+>while searching for some strange KDE behaviour (see bug 107 about
+>those icons), I found at least three different tmp directories:
+>/tmp/
+>/var/tmp/
+>~/tmp/ (one for every user)
+
+and:
+
+/home/<uid>/.java/deployment/tmp
+/home/<uid>/.libreoffice/3/user/extensions/tmp
+/var/lib/rkhunter/tmp
+...
+
+Ciao,
+=Dick Gevers=
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011489.html b/zarb-ml/mageia-dev/2012-January/011489.html new file mode 100644 index 000000000..203f29889 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011489.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] Too many tmp directories + + + + + + + + + +

[Mageia-dev] Too many tmp directories

+ Maarten Vanraes + alien at rmail.be +
+ Sat Jan 21 20:39:10 CET 2012 +

+
+ +
Op zaterdag 21 januari 2012 20:06:54 schreef Colin Guthrie:
+> There are other commands you can use other than mount... e.g. df
+> 
+> [colin at jimmy ~]$ df
+> Filesystem                                 Size  Used Avail Use% Mounted on
+> rootfs                                      15G   12G  2.1G  85% /
+> devtmpfs                                   1.6G     0  1.6G   0% /dev
+> tmpfs                                      1.6G  804K  1.6G   1% /dev/shm
+> /dev/mapper/solidstate-slash                15G   12G  2.1G  85% /
+> tmpfs                                      1.6G  3.2M  1.6G   1% /run
+> tmpfs                                      1.6G     0  1.6G   0%
+> /sys/fs/cgroup
+> tmpfs                                      1.6G     0  1.6G   0% /media
+> /dev/mapper/solidstate-home                130G  128G  1.6G  99% /home
+> /dev/sda2                                   85M   47M   34M  59% /boot
+> 
+> 
+> Generally speaking df is a more useful command than mount IMO anyway,
+> and it's always been the command I use when I'm just wanting a quick
+> overview.
+> 
+> Col
+
+but shows / mounted twice, in mga1, the stage1 mounts were not visible, why 
+not anymore?
+
+and for mount, it's primarily the cgroups, and that's due to new kernel
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011490.html b/zarb-ml/mageia-dev/2012-January/011490.html new file mode 100644 index 000000000..0c189235f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011490.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] Too many tmp directories + + + + + + + + + +

[Mageia-dev] Too many tmp directories

+ Christian Lohmaier + lohmaier+mageia at googlemail.com +
+ Sat Jan 21 23:59:35 CET 2012 +

+
+ +
On Sat, Jan 21, 2012 at 6:21 PM, Oliver Burger
+<oliver.bgr at googlemail.com> wrote:
+>
+> while searching for some strange KDE behaviour (see bug 107 about
+> those icons), I found at least three different tmp directories:
+> /tmp/
+> /var/tmp/
+
+Those are historically grown ... /tmp is the really temporary one,
+discarded when rebooting, while /var/tmp is for stuff that is to be
+preserved after a reboot.
+
+So while /tmp nowadays frequently is on a ramdisk, /var/tmp is not.
+
+ciao
+Christian
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011491.html b/zarb-ml/mageia-dev/2012-January/011491.html new file mode 100644 index 000000000..3754c0915 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011491.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] Too many tmp directories + + + + + + + + + +

[Mageia-dev] Too many tmp directories

+ Maarten Vanraes + alien at rmail.be +
+ Sun Jan 22 07:45:23 CET 2012 +

+
+ +
Op zaterdag 21 januari 2012 23:59:35 schreef Christian Lohmaier:
+> On Sat, Jan 21, 2012 at 6:21 PM, Oliver Burger
+> 
+> <oliver.bgr at googlemail.com> wrote:
+> > while searching for some strange KDE behaviour (see bug 107 about
+> > those icons), I found at least three different tmp directories:
+> > /tmp/
+> > /var/tmp/
+> 
+> Those are historically grown ... /tmp is the really temporary one,
+> discarded when rebooting, while /var/tmp is for stuff that is to be
+> preserved after a reboot.
+> 
+> So while /tmp nowadays frequently is on a ramdisk, /var/tmp is not.
+> 
+> ciao
+> Christian
+
+ah yes, that is true, thinking of amavisd, for example...
+
+it may be temporary, but after reboot the email will continue to be checked...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011492.html b/zarb-ml/mageia-dev/2012-January/011492.html new file mode 100644 index 000000000..1852da563 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011492.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] repository cleanup + + + + + + + + + +

[Mageia-dev] repository cleanup

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Sun Jan 22 15:51:14 CET 2012 +

+
+ +
Hello.
+
+I need an admin to remove the following packages from the package 
+repository:
+- fusioninventory-agent-plugin-snmpquery source and binary packages (it 
+has been renamed to fusioninventory-agent-plugin-netdiscovery)
+- fusioninventory-agent-plugin-ocsdeploy source and binary packages (it 
+is not compatible with new agent version)
+- apache-mod_php and php-ini source packages (they have been merged into 
+php package)
+- apache-doc souce package (it has been merged into apache package)
+
+Also, despite latest change from Anssi, there is still a dependency 
+issue between dsniff and dsniff-webspy packages according to the hdlists.
+
+-- 
+BOFH excuse #78:
+
+Yes, yes, its called a design limitation
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011493.html b/zarb-ml/mageia-dev/2012-January/011493.html new file mode 100644 index 000000000..70756aa34 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011493.html @@ -0,0 +1,117 @@ + + + + [Mageia-dev] repository cleanup + + + + + + + + + +

[Mageia-dev] repository cleanup

+ Pascal Terjan + pterjan at gmail.com +
+ Sun Jan 22 16:10:50 CET 2012 +

+
+ +
On Sun, Jan 22, 2012 at 14:51, Guillaume Rousse <guillomovitch at gmail.com> wrote:
+> Hello.
+>
+> I need an admin to remove the following packages from the package
+> repository:
+> - fusioninventory-agent-plugin-snmpquery source and binary packages (it has
+> been renamed to fusioninventory-agent-plugin-netdiscovery)
+Souldn't it be obsoleted then?
+
+> - fusioninventory-agent-plugin-ocsdeploy source and binary packages (it is
+> not compatible with new agent version)
+Same, it will remain on people's machine
+
+> - apache-mod_php and php-ini source packages (they have been merged into php
+> package)
+done
+
+> - apache-doc souce package (it has been merged into apache package)
+done
+
+> Also, despite latest change from Anssi, there is still a dependency issue
+> between dsniff and dsniff-webspy packages according to the hdlists.
+
+Yes, dsniff-webspy requires dnsiff without epoch
+
+$ rpm -qp --requires
+/distrib/bootstrap/distrib/cauldron/i586/media/core/release/dsniff-webspy-2.4-0.b1.2.mga2.i586.rpm
+| grep dsniff
+dsniff = 2.4
+
+$ rpm -qp --provides
+/distrib/bootstrap/distrib/cauldron/i586/media/core/release/dsniff-2.4-0.b1.2.mga2.i586.rpm
+dsniff = 2:2.4-0.b1.2.mga2
+dsniff(x86-32) = 2:2.4-0.b1.2.mga2
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011494.html b/zarb-ml/mageia-dev/2012-January/011494.html new file mode 100644 index 000000000..bf8820277 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011494.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] "Uploaded" status on the web page + + + + + + + + + +

[Mageia-dev] "Uploaded" status on the web page

+ Pascal Terjan + pterjan at gmail.com +
+ Sun Jan 22 16:51:28 CET 2012 +

+
+ +
I did some minor changes in the build system meaning that "uploaded"
+now really mean uploaded (the package is guaranteed to be in the
+hdlists), and you can safely submit anything depending on it.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011495.html b/zarb-ml/mageia-dev/2012-January/011495.html new file mode 100644 index 000000000..e4b5b8a06 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011495.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] Too many tmp directories + + + + + + + + + +

[Mageia-dev] Too many tmp directories

+ Anssi Hannula + anssi at mageia.org +
+ Sun Jan 22 16:53:28 CET 2012 +

+
+ +
On 22.01.2012 00:59, Christian Lohmaier wrote:
+> On Sat, Jan 21, 2012 at 6:21 PM, Oliver Burger
+> <oliver.bgr at googlemail.com> wrote:
+>>
+>> while searching for some strange KDE behaviour (see bug 107 about
+>> those icons), I found at least three different tmp directories:
+>> /tmp/
+>> /var/tmp/
+> 
+> Those are historically grown ... /tmp is the really temporary one,
+> discarded when rebooting, while /var/tmp is for stuff that is to be
+> preserved after a reboot.
+> 
+> So while /tmp nowadays frequently is on a ramdisk, /var/tmp is not.
+
+Exactly, e.g. KDE has its cache files in /var/tmp so that the startup of
+KDE is not slowed down when /tmp is cleared on system boot (tmpfs).
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011496.html b/zarb-ml/mageia-dev/2012-January/011496.html new file mode 100644 index 000000000..66984baf8 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011496.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] "Uploaded" status on the web page + + + + + + + + + +

[Mageia-dev] "Uploaded" status on the web page

+ Balcaen John + mikala at mageia.org +
+ Sun Jan 22 16:55:44 CET 2012 +

+
+ +
On Sunday 22 January 2012 15:51:28 Pascal Terjan wrote :
+> I did some minor changes in the build system meaning that "uploaded"
+> now really mean uploaded (the package is guaranteed to be in the
+> hdlists), and you can safely submit anything depending on it.
+Nice :)
+
+
+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/2012-January/011497.html b/zarb-ml/mageia-dev/2012-January/011497.html new file mode 100644 index 000000000..18d40a67d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011497.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] Too many tmp directories + + + + + + + + + +

[Mageia-dev] Too many tmp directories

+ David W. Hodgins + davidwhodgins at gmail.com +
+ Sun Jan 22 19:22:14 CET 2012 +

+
+ +
On Sat, 21 Jan 2012 12:35:39 -0500, Balcaen John <mikala at mageia.org> wrote:
+
+>> while searching for some strange KDE behaviour (see bug 107 about
+>> those icons), I found at least three different tmp directories:
+>> /tmp/
+>> /var/tmp/
+>> ~/tmp/ (one for every user)
+
+http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#Directory_structure
+
+/tmp     - files may not survive reboot.
+/var/tmp - files may survive reboot
+~/tmp    - files may survive reboot, also subject to things like quotas, for
+            regular users.
+
+Regards, Dave Hodgins
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011498.html b/zarb-ml/mageia-dev/2012-January/011498.html new file mode 100644 index 000000000..eb6f8b0ff --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011498.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] Slow gnome-shell due to new cogl/clutter + + + + + + + + + +

[Mageia-dev] Slow gnome-shell due to new cogl/clutter

+ Olav Vitters + olav at vitters.nl +
+ Sun Jan 22 21:16:37 CET 2012 +

+
+ +
On Sat, Jan 21, 2012 at 07:21:37PM +0000, Colin Guthrie wrote:
+> 'Twas brillig, and Olav Vitters at 21/01/12 12:16 did gyre and gimble:
+> > On Sat, Jan 21, 2012 at 12:26:57AM +0100, JA Magallón wrote:
+> >> This did not fix the problem, but it looks that got fixed in gnome-shell GIT:
+> >>
+> >> http://ubuntuforums.org/showthread.php?t=1910576
+> > 
+> > Please test for me, atm unable to do so :-(
+> > 
+> > Newer stuff has been packaged..
+> 
+> Do I need to rebuild anything locally for testing? Tried a fully updated
+> system (new gtk, new g-s) and it's still busted :(
+
+Some assistance would be very welcome yeah. Suggest to contact ebassi.
+We've replaced (upgraded) clutter, gnome-shell and mutter by now. I
+guess something needs to be rebuild.
+
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011499.html b/zarb-ml/mageia-dev/2012-January/011499.html new file mode 100644 index 000000000..56a1867e0 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011499.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] Too many tmp directories + + + + + + + + + +

[Mageia-dev] Too many tmp directories

+ Kamil Rytarowski + n54 at gmx.com +
+ Sun Jan 22 21:51:20 CET 2012 +

+
+ +
W dniu 22.01.2012 16:53, Anssi Hannula pisze:
+> On 22.01.2012 00:59, Christian Lohmaier wrote:
+>> On Sat, Jan 21, 2012 at 6:21 PM, Oliver Burger
+>> <oliver.bgr at googlemail.com>  wrote:
+>>> while searching for some strange KDE behaviour (see bug 107 about
+>>> those icons), I found at least three different tmp directories:
+>>> /tmp/
+>>> /var/tmp/
+>> Those are historically grown ... /tmp is the really temporary one,
+>> discarded when rebooting, while /var/tmp is for stuff that is to be
+>> preserved after a reboot.
+>>
+>> So while /tmp nowadays frequently is on a ramdisk, /var/tmp is not.
+> Exactly, e.g. KDE has its cache files in /var/tmp so that the startup of
+> KDE is not slowed down when /tmp is cleared on system boot (tmpfs).
+>
+Really? I use /tmp for packaging and patching - and these files stay 
+there untouched after several reboots.
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011500.html b/zarb-ml/mageia-dev/2012-January/011500.html new file mode 100644 index 000000000..ae4123b98 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011500.html @@ -0,0 +1,106 @@ + + + + [Mageia-dev] repository cleanup + + + + + + + + + +

[Mageia-dev] repository cleanup

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Mon Jan 23 00:21:07 CET 2012 +

+
+ +
Le 22/01/2012 16:10, Pascal Terjan a écrit :
+> On Sun, Jan 22, 2012 at 14:51, Guillaume Rousse<guillomovitch at gmail.com>  wrote:
+>> Hello.
+>>
+>> I need an admin to remove the following packages from the package
+>> repository:
+>> - fusioninventory-agent-plugin-snmpquery source and binary packages (it has
+>> been renamed to fusioninventory-agent-plugin-netdiscovery)
+> Souldn't it be obsoleted then?
+It is. But it seems to be unsufficient for automatic repository cleanup.
+
+>> - fusioninventory-agent-plugin-ocsdeploy source and binary packages (it is
+>> not compatible with new agent version)
+> Same, it will remain on people's machine
+Doesn't matter very much, it won't be used anyway. A new plugin should 
+obsolete it as soon at it will be packaged, but it doesn't seems to be 
+very effective.
+
+[..]
+>> Also, despite latest change from Anssi, there is still a dependency issue
+>> between dsniff and dsniff-webspy packages according to the hdlists.
+>
+> Yes, dsniff-webspy requires dnsiff without epoch
+Arf, back to my initial submission :)
+
+-- 
+BOFH excuse #69:
+
+knot in cables caused data stream to become twisted and kinked
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011501.html b/zarb-ml/mageia-dev/2012-January/011501.html new file mode 100644 index 000000000..9800dfa94 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011501.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] Too many tmp directories + + + + + + + + + +

[Mageia-dev] Too many tmp directories

+ Anssi Hannula + anssi at mageia.org +
+ Mon Jan 23 01:33:52 CET 2012 +

+
+ +
On 22.01.2012 22:51, Kamil Rytarowski wrote:
+> W dniu 22.01.2012 16:53, Anssi Hannula pisze:
+>> On 22.01.2012 00:59, Christian Lohmaier wrote:
+>>> On Sat, Jan 21, 2012 at 6:21 PM, Oliver Burger
+>>> <oliver.bgr at googlemail.com>  wrote:
+>>>> while searching for some strange KDE behaviour (see bug 107 about
+>>>> those icons), I found at least three different tmp directories:
+>>>> /tmp/
+>>>> /var/tmp/
+>>> Those are historically grown ... /tmp is the really temporary one,
+>>> discarded when rebooting, while /var/tmp is for stuff that is to be
+>>> preserved after a reboot.
+>>>
+>>> So while /tmp nowadays frequently is on a ramdisk, /var/tmp is not.
+>> Exactly, e.g. KDE has its cache files in /var/tmp so that the startup of
+>> KDE is not slowed down when /tmp is cleared on system boot (tmpfs).
+>>
+> Really? I use /tmp for packaging and patching - and these files stay
+> there untouched after several reboots.
+
+I didn't say it gets cleared on all systems, obviously it depends on
+your configuration.
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011502.html b/zarb-ml/mageia-dev/2012-January/011502.html new file mode 100644 index 000000000..28100ba3f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011502.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] Too many tmp directories + + + + + + + + + +

[Mageia-dev] Too many tmp directories

+ P. Christeas + xrg at linux.gr +
+ Mon Jan 23 09:19:05 CET 2012 +

+
+ +
On Sunday 22 January 2012, David W. Hodgins wrote:
+> http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#Directory_struct
+> ure
+> 
+> /tmp     - files may not survive reboot.
+> /var/tmp - files may survive reboot
+> ~/tmp    - files may survive reboot, also subject to things like quotas,
+> for regular users.
+> 
+
+Add to that:
+ /tmp may be the fastest (ramfs)
+ /var/tmp is machine-local, quite fast
+ ~/tmp may be network-mapped (nfs), will be slower
+
+it is a speed vs. longevity tradeoff
+
+and also good reason to have all these choices.
+
+
+-- 
+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/2012-January/011503.html b/zarb-ml/mageia-dev/2012-January/011503.html new file mode 100644 index 000000000..76f347a25 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011503.html @@ -0,0 +1,130 @@ + + + + [Mageia-dev] Too many tmp directories + + + + + + + + + +

[Mageia-dev] Too many tmp directories

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Mon Jan 23 10:22:24 CET 2012 +

+
+ +
'Twas brillig, and Maarten Vanraes at 21/01/12 19:39 did gyre and gimble:
+> Op zaterdag 21 januari 2012 20:06:54 schreef Colin Guthrie:
+>> There are other commands you can use other than mount... e.g. df
+>>
+>> [colin at jimmy ~]$ df
+>> Filesystem                                 Size  Used Avail Use% Mounted on
+>> rootfs                                      15G   12G  2.1G  85% /
+>> devtmpfs                                   1.6G     0  1.6G   0% /dev
+>> tmpfs                                      1.6G  804K  1.6G   1% /dev/shm
+>> /dev/mapper/solidstate-slash                15G   12G  2.1G  85% /
+>> tmpfs                                      1.6G  3.2M  1.6G   1% /run
+>> tmpfs                                      1.6G     0  1.6G   0%
+>> /sys/fs/cgroup
+>> tmpfs                                      1.6G     0  1.6G   0% /media
+>> /dev/mapper/solidstate-home                130G  128G  1.6G  99% /home
+>> /dev/sda2                                   85M   47M   34M  59% /boot
+>>
+>>
+>> Generally speaking df is a more useful command than mount IMO anyway,
+>> and it's always been the command I use when I'm just wanting a quick
+>> overview.
+>>
+>> Col
+> 
+> but shows / mounted twice, in mga1, the stage1 mounts were not visible, why 
+> not anymore?
+
+Basically we used to "fake" the mount state with a file in /etc/mtab.
+This is now a symlink to /proc/mounts which, IMO is much safer. This is
+why the "mount" output has gotten bigger.
+
+As for rootfs staying mounted, I believe this is in some way due to the
+ability to re-enter the initrd on shutdown/reboot. This allows for nice
+things such as unmounting / and shutting down lvm properly before
+poweroff/reboot which was not possible before. So IMO this is an
+improvement, albeit I agree it's a bit ugly.
+
+If it's not that, then it's maybe to do with the /dev mount which must
+be preserved between initrd and proper / in order to transfer important
+udev metadata.
+
+Col
+
+
+
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011504.html b/zarb-ml/mageia-dev/2012-January/011504.html new file mode 100644 index 000000000..aca0426ce --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011504.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] "Uploaded" status on the web page + + + + + + + + + +

[Mageia-dev] "Uploaded" status on the web page

+ Olav Vitters + olav at vitters.nl +
+ Mon Jan 23 13:41:27 CET 2012 +

+
+ +
On Sun, Jan 22, 2012 at 03:51:28PM +0000, Pascal Terjan wrote:
+> I did some minor changes in the build system meaning that "uploaded"
+> now really mean uploaded (the package is guaranteed to be in the
+> hdlists), and you can safely submit anything depending on it.
+
+Nice!
+
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011505.html b/zarb-ml/mageia-dev/2012-January/011505.html new file mode 100644 index 000000000..6d019ba7f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011505.html @@ -0,0 +1,124 @@ + + + + [Mageia-dev] ConsoleKit vs systemd session tracking for Mageia 2 + + + + + + + + + +

[Mageia-dev] ConsoleKit vs systemd session tracking for Mageia 2

+ Olav Vitters + olav at vitters.nl +
+ Mon Jan 23 15:51:25 CET 2012 +

+
+ +
FYI,
+
+A bunch of GNOME modules now have --enable-systemd configure flags. This
+will make them use systemd instead of (deprecated ConsoleKit) to track
+login sessions.
+
+I made a tracker bug on GNOME Bugzilla:
+https://bugzilla.gnome.org/show_bug.cgi?id=systemd
+
+Modules I noticed (and added to the tracker bug):
+ - NetworkManager
+ - gnome-settings-daemon
+ - gnome-session
+ - gnome-control-center
+ - gnome-packagekit
+ - system-monitor
+
+And related to systemd:
+ - gnome-control-center (timedated)
+   This just relies on the daemon to be there; systemd doesn't need to
+   be running (99% sure of this), the daemon is part in the systemd
+   tarball.
+   We do need to ensure Mageia 2 always has timedated. This is used to
+   change the timezone and so on btw.
+
+
+These seem to be compile time checks. Meaning: if --enable-systemd is
+added to ./configure, the functionality won't work on sysvinit. I am not
+sure exactly what will break under sysvinit. The bugreports to contain
+some discussion though.
+
+
+Could a systemd expert look into this and suggest what is best for
+Mageia 2?
+
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011506.html b/zarb-ml/mageia-dev/2012-January/011506.html new file mode 100644 index 000000000..2412da735 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011506.html @@ -0,0 +1,111 @@ + + + + [Mageia-dev] ConsoleKit vs systemd session tracking for Mageia 2 + + + + + + + + + +

[Mageia-dev] ConsoleKit vs systemd session tracking for Mageia 2

+ Michael Scherer + misc at zarb.org +
+ Mon Jan 23 16:12:17 CET 2012 +

+
+ +
Le lundi 23 janvier 2012 à 15:51 +0100, Olav Vitters a écrit :
+> FYI,
+
+> These seem to be compile time checks. Meaning: if --enable-systemd is
+> added to ./configure, the functionality won't work on sysvinit. I am not
+> sure exactly what will break under sysvinit. The bugreports to contain
+> some discussion though.
+> 
+> 
+> Could a systemd expert look into this and suggest what is best for
+> Mageia 2?
+
+Since we decided to keep non systemd boot as fully supported for mageia
+2 : https://www.mageia.org/pipermail/mageia-dev/2011-July/006532.html
+
+and to have both usable side by side : 
+https://bugs.mageia.org/show_bug.cgi?id=2120
+
+I guess it is best to keep the old system for the time being.
+So do not use --enable-systemd until mageia 3.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011507.html b/zarb-ml/mageia-dev/2012-January/011507.html new file mode 100644 index 000000000..1ca73ea2f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011507.html @@ -0,0 +1,81 @@ + + + + [Mageia-dev] "Uploaded" status on the web page + + + + + + + + + +

[Mageia-dev] "Uploaded" status on the web page

+ Kamil Rytarowski + n54 at gmx.com +
+ Mon Jan 23 16:24:29 CET 2012 +

+
+ +
W dniu 22.01.2012 16:51, Pascal Terjan pisze:
+> I did some minor changes in the build system meaning that "uploaded"
+> now really mean uploaded (the package is guaranteed to be in the
+> hdlists), and you can safely submit anything depending on it.
+Perfect!
+Thank you!
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011508.html b/zarb-ml/mageia-dev/2012-January/011508.html new file mode 100644 index 000000000..0c25635d9 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011508.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] Too many tmp directories + + + + + + + + + +

[Mageia-dev] Too many tmp directories

+ EatDirt + dirteat at gmail.com +
+ Mon Jan 23 16:57:35 CET 2012 +

+
+ +
On 21/01/12 20:06, Colin Guthrie wrote:
+
+> What's wrong with this? It's showing you the mounts that are active...
+> would you rather it filtered out e.g. /sys etc?
+>
+> Generally speaking df is a more useful command than mount IMO anyway,
+> and it's always been the command I use when I'm just wanting a quick
+> overview.
+
+Nothing wrong, just unusual and not very informative. I have always used 
+mount to see what was actually mounted as disk or media. Now, it looks 
+more informative of kernel and system stuff than user stuff; but df 
+still fine indeed!
+
+Chris.
+
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011509.html b/zarb-ml/mageia-dev/2012-January/011509.html new file mode 100644 index 000000000..f22645207 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011509.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] Spelling error in screen announcement for Dracut + + + + + + + + + +

[Mageia-dev] Spelling error in screen announcement for Dracut

+ David + dgboles at gmail.com +
+ Mon Jan 23 17:21:50 CET 2012 +

+
+ +
The word "really' is spelled "relly".
+
+Picture here:
+
+<http://www.box.com/s/o1hdl0c1ob8i3m2fbg7m>
+-- 
+
+  David
+
+"May your road lead you to warm sands."
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011510.html b/zarb-ml/mageia-dev/2012-January/011510.html new file mode 100644 index 000000000..82aade267 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011510.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] Spelling error in screen announcement for Dracut + + + + + + + + + +

[Mageia-dev] Spelling error in screen announcement for Dracut

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Mon Jan 23 18:13:49 CET 2012 +

+
+ +
'Twas brillig, and David at 23/01/12 16:21 did gyre and gimble:
+> The word "really' is spelled "relly".
+> 
+> Picture here:
+
+Fixed in svn. Depending on how things go, this whole message may get
+nuked anyway, but if not, it'll at least be spelled correctly!
+
+Col
+
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011511.html b/zarb-ml/mageia-dev/2012-January/011511.html new file mode 100644 index 000000000..a977d85ce --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011511.html @@ -0,0 +1,89 @@ + + + + [Mageia-dev] Too many tmp directories + + + + + + + + + +

[Mageia-dev] Too many tmp directories

+ Johnny A. Solbu + cooker at solbu.net +
+ Mon Jan 23 19:08:48 CET 2012 +

+
+ +
On Monday 23 January 2012 16:57, EatDirt wrote:
+> I have always used 
+> mount to see what was actually mounted as disk or media.
+
+Mount also list how it is mounted, not just where. (e.g. ro, rw, noexec etc.)
+df can't do this.
+
+-- 
+Johnny A. Solbu
+PGP key ID: 0xFA687324
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 189 bytes
+Desc: This is a digitally signed message part.
+URL: </pipermail/mageia-dev/attachments/20120123/53f43ba3/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011512.html b/zarb-ml/mageia-dev/2012-January/011512.html new file mode 100644 index 000000000..3bc70eead --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011512.html @@ -0,0 +1,82 @@ + + + + [Mageia-dev] Too many tmp directories + + + + + + + + + +

[Mageia-dev] Too many tmp directories

+ Maarten Vanraes + alien at rmail.be +
+ Mon Jan 23 20:13:08 CET 2012 +

+
+ +
Op maandag 23 januari 2012 19:08:48 schreef Johnny A. Solbu:
+> On Monday 23 January 2012 16:57, EatDirt wrote:
+> > I have always used
+> > mount to see what was actually mounted as disk or media.
+> 
+> Mount also list how it is mounted, not just where. (e.g. ro, rw, noexec
+> etc.) df can't do this.
+
+Can someone find out how other distro's who symlink mtab to /proc/mounts do 
+this? do they also show all the cgroups and double / or do they have a diff 
+solution?
+
+ + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011513.html b/zarb-ml/mageia-dev/2012-January/011513.html new file mode 100644 index 000000000..3b194bcc4 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011513.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] RPM filetrigger doesn't take effect on icon changes + + + + + + + + + +

[Mageia-dev] RPM filetrigger doesn't take effect on icon changes

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Tue Jan 24 10:18:47 CET 2012 +

+
+ +
Hi there,
+while working on https://bugs.mageia.org/show_bug.cgi?id=107 we
+noticed, our file triggers don't sometimes take effect on changes
+directly in /usr/share/icons.
+
+This is a problem that does affect KDE only as far as I can see it.
+
+The result is, when an icon in /usr/share/icons changes, the kde icon
+cache of the existing users isn't updated. So my fix to Bug 107
+(replacing those wrong icons) doesn't work on KDE (while it does on
+other desktops).
+
+Can this be fixed somehow?
+
+Oliver
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011514.html b/zarb-ml/mageia-dev/2012-January/011514.html new file mode 100644 index 000000000..64e2bae95 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011514.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] RPM filetrigger doesn't take effect on icon changes + + + + + + + + + +

[Mageia-dev] RPM filetrigger doesn't take effect on icon changes

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Tue Jan 24 10:23:08 CET 2012 +

+
+ +
Le 24/01/2012 10:18, Oliver Burger a écrit :
+> Hi there,
+> while working on https://bugs.mageia.org/show_bug.cgi?id=107 we
+> noticed, our file triggers don't sometimes take effect on changes
+> directly in /usr/share/icons.
+"sometimes" is problematic here: without a reproducible test case, a bug 
+is quite difficult to understand.
+
+-- 
+BOFH excuse #439:
+
+Hot Java has gone cold
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011515.html b/zarb-ml/mageia-dev/2012-January/011515.html new file mode 100644 index 000000000..42cd40d6c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011515.html @@ -0,0 +1,123 @@ + + + + [Mageia-dev] ConsoleKit vs systemd session tracking for Mageia 2 + + + + + + + + + +

[Mageia-dev] ConsoleKit vs systemd session tracking for Mageia 2

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Jan 24 10:26:20 CET 2012 +

+
+ +
'Twas brillig, and Michael Scherer at 23/01/12 15:12 did gyre and gimble:
+> Le lundi 23 janvier 2012 à 15:51 +0100, Olav Vitters a écrit :
+>> FYI,
+> 
+>> These seem to be compile time checks. Meaning: if --enable-systemd is
+>> added to ./configure, the functionality won't work on sysvinit. I am not
+>> sure exactly what will break under sysvinit. The bugreports to contain
+>> some discussion though.
+>>
+>>
+>> Could a systemd expert look into this and suggest what is best for
+>> Mageia 2?
+> 
+> Since we decided to keep non systemd boot as fully supported for mageia
+> 2 : https://www.mageia.org/pipermail/mageia-dev/2011-July/006532.html
+> 
+> and to have both usable side by side : 
+> https://bugs.mageia.org/show_bug.cgi?id=2120
+> 
+> I guess it is best to keep the old system for the time being.
+> So do not use --enable-systemd until mageia 3.
+
+Yeah, I've deliberately left in traditional udev ACL handling for now
+too in udev, such that sysvinit systems still work.
+
+So my reply is just pretty much what misc said.
+
+Col
+
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011516.html b/zarb-ml/mageia-dev/2012-January/011516.html new file mode 100644 index 000000000..6e433a288 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011516.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] RPM filetrigger doesn't take effect on icon changes + + + + + + + + + +

[Mageia-dev] RPM filetrigger doesn't take effect on icon changes

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Tue Jan 24 10:43:22 CET 2012 +

+
+ +
2012/1/24 Guillaume Rousse <guillomovitch at gmail.com>:
+> Le 24/01/2012 10:18, Oliver Burger a écrit :
+>
+>> Hi there,
+>> while working on https://bugs.mageia.org/show_bug.cgi?id=107 we
+>> noticed, our file triggers don't sometimes take effect on changes
+>> directly in /usr/share/icons.
+>
+> "sometimes" is problematic here: without a reproducible test case, a bug is
+> quite difficult to understand.
+>
+Sometimes means:
+when changing an icon in /usr/share/icons/ and you are using KDE, you
+won't ever notice that change unless you delete the KDE icon cache
+manually.
+If you are using any other desktop you won't have any problems.
+So perhaps "sometimes" was not the best description here:
+As a test case:
+- with the old version of desktop-common-data (< 2-3.mga2 or <
+1-12.1.mga1 ) you will have the multimedia icon used for the graphics
+section as well. With the new version version, you will see the
+correct icon for the graphics section in all desktops != KDE and on a
+new user account with KDE but not on an existing KDE account
+
+Oliver
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011517.html b/zarb-ml/mageia-dev/2012-January/011517.html new file mode 100644 index 000000000..776da7c68 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011517.html @@ -0,0 +1,106 @@ + + + + [Mageia-dev] RPM filetrigger doesn't take effect on icon changes + + + + + + + + + +

[Mageia-dev] RPM filetrigger doesn't take effect on icon changes

+ Balcaen John + mikala at mageia.org +
+ Tue Jan 24 10:49:02 CET 2012 +

+
+ +
On Tuesday 24 January 2012 10:18:47 Oliver Burger wrote :
+> Hi there,
+> while working on https://bugs.mageia.org/show_bug.cgi?id=107 we
+> noticed, our file triggers don't sometimes take effect on changes
+> directly in /usr/share/icons.
+> 
+> This is a problem that does affect KDE only as far as I can see it.
+> 
+> The result is, when an icon in /usr/share/icons changes, the kde icon
+> cache of the existing users isn't updated. So my fix to Bug 107
+> (replacing those wrong icons) doesn't work on KDE (while it does on
+> other desktops).
+> 
+> Can this be fixed somehow?
+There is this bug report 
+https://bugs.kde.org/show_bug.cgi?id=251288
+
+which seems quite similar to this current situation : changing one icons.
+
+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/2012-January/011518.html b/zarb-ml/mageia-dev/2012-January/011518.html new file mode 100644 index 000000000..82087a7ab --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011518.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] RPM filetrigger doesn't take effect on icon changes + + + + + + + + + +

[Mageia-dev] RPM filetrigger doesn't take effect on icon changes

+ Florian Hubold + doktor5000 at arcor.de +
+ Tue Jan 24 11:48:43 CET 2012 +

+
+ +
Am 24.01.2012 10:23, schrieb Guillaume Rousse:
+> Le 24/01/2012 10:18, Oliver Burger a écrit :
+>> Hi there,
+>> while working on https://bugs.mageia.org/show_bug.cgi?id=107 we
+>> noticed, our file triggers don't sometimes take effect on changes
+>> directly in /usr/share/icons.
+> "sometimes" is problematic here: without a reproducible test case, a bug is
+> quite difficult to understand.
+>
+No filetriger currently fires when updating icons, which reside in
+/usr/share/icons, only for hicolor, gnome and oxygen subdirectories.
+You can check via grep -R '/usr/share/icons' /var/lib/rpm/filetriggers/
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011519.html b/zarb-ml/mageia-dev/2012-January/011519.html new file mode 100644 index 000000000..88ba07ff2 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011519.html @@ -0,0 +1,129 @@ + + + + [Mageia-dev] [ANN] unbloated installer stage1 + + + + + + + + + +

[Mageia-dev] [ANN] unbloated installer stage1

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Jan 24 13:09:02 CET 2012 +

+
+ +
Hi
+
+Over the years, stage1 (both  all.rdz, boot.iso, ...) got bigger & bigger:
+10.0-10.1: 8Mo
+10.2-2005: 15M      <=======
+2006.0: 13M
+2007.0: 14M
+2007.1: 10M
+2008.0-2008.1: 12M
+2009.0: 26M      <=======
+2009.1: 32M      <=======
+2010.0: 33M
+2010.1: 36M (37M on 64 bit)
+2011   : 44M
+mga1  : 39M (40M on 64bit) (NEW: 53M on non-free 64 bit...)
+
+I've reduced this by:
+- removing alt1 (x86_64 only for now):
+- removing busybox
+- compressing initrd with XZ instead of gzip: only good on firmware
+- re compressing kernel modules with XZ instead of gzip:
+
+Removing alt1 (x86_64 only for now) saved 20Mb on boot.iso (50%)
+and on boot-nonfree.iso (43%).
+
+Removing busybox saved 1B (5.7% of all.rdz, 5% of boot.iso,
+3.7% of boot-nonfree.iso)
+
+Compressing initrd with XZ instead of gzip saved 2Mo (7.7%) on
+boot-nonfree.iso (better compressed firmwares).
+
+Re-compressing kernel modules with XZ instead of gzip saved -2.4Mb (15.9%)
+on all.rdz, -2Mb (10.5%) on boot.iso, -2mb on boot-nonfree.iso (8.3%)
+
+Total gain on boot.iso: -23Mb (57.5%) on x86_64 (less on i586)
+
+This should save space on ISOs too (we could save more by
+not including install/images on ISOs btw)
+
+There's a minor drawback: KA install won't work anymore but
+it's a niche. Is there someone using that feature?
+The proper way to support it would be to either:
+- have a stage1.5 for KA with busybox
+- include a static mke2fs (compiled against dietlibc)
+- disable KA support
+
+See you
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011520.html b/zarb-ml/mageia-dev/2012-January/011520.html new file mode 100644 index 000000000..fa82d32a7 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011520.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] [ANN] unbloated installer stage1 + + + + + + + + + +

[Mageia-dev] [ANN] unbloated installer stage1

+ zezinho + lists.jjorge at free.fr +
+ Tue Jan 24 13:21:00 CET 2012 +

+
+ +
Le mardi 24 janvier 2012 13:09:02, Thierry Vignaud a écrit :
+> Total gain on boot.iso: -23Mb (57.5%) on x86_64 (less on i586)
+
+Nice!
+
+> There's a minor drawback: KA install won't work anymore but
+> it's a niche. Is there someone using that feature?
+> The proper way to support it would be to either:
+> - have a stage1.5 for KA with busybox
+> - include a static mke2fs (compiled against dietlibc)
+> - disable KA support
+> 
+Well, what is KA install?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011521.html b/zarb-ml/mageia-dev/2012-January/011521.html new file mode 100644 index 000000000..67b426249 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011521.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] [ANN] unbloated installer stage1 + + + + + + + + + +

[Mageia-dev] [ANN] unbloated installer stage1

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Jan 24 14:48:17 CET 2012 +

+
+ +
On 24 January 2012 13:21, zezinho <lists.jjorge at free.fr> wrote:
+>> There's a minor drawback: KA install won't work anymore but
+>> it's a niche. Is there someone using that feature?
+>> The proper way to support it would be to either:
+>> - have a stage1.5 for KA with busybox
+>> - include a static mke2fs (compiled against dietlibc)
+>> - disable KA support
+>>
+> Well, what is KA install?
+
+Then you don't need it :-)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011522.html b/zarb-ml/mageia-dev/2012-January/011522.html new file mode 100644 index 000000000..eb35661c5 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011522.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] [ANN] unbloated installer stage1 + + + + + + + + + +

[Mageia-dev] [ANN] unbloated installer stage1

+ Olav Vitters + olav at vitters.nl +
+ Tue Jan 24 14:55:06 CET 2012 +

+
+ +
On Tue, Jan 24, 2012 at 01:09:02PM +0100, Thierry Vignaud wrote:
+> Total gain on boot.iso: -23Mb (57.5%) on x86_64 (less on i586)
+
+Yay, more space for GNOME! (my interest :P)
+
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011523.html b/zarb-ml/mageia-dev/2012-January/011523.html new file mode 100644 index 000000000..0818de540 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011523.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] Boot on Mageia Cauldron is damn slow! RFC + + + + + + + + + +

[Mageia-dev] Boot on Mageia Cauldron is damn slow! RFC

+ Damien Lallement + mageia at damsweb.net +
+ Tue Jan 24 15:06:56 CET 2012 +

+
+ +
Hi,
+
+Since my laptop (HDD) is running Cauldron, it needs 5 minutes to boot 
+whereas it was taking 1 minute under Mageia 1.
+And on my working desktop (SSD), Mageia 1 was booting in 3 seconds and 
+now it takes 1 minute.
+
+Here are my bootcharts:
+- Lenovo X220 with HDD :
+http://damsweb.net/trash/bootchart-mga_cauldron-lenovo_x220.png
+
+- Homemade core i3 + SSD :
+http://damsweb.net/trash/bootchart-mga_cauldron-ssd.png
+
+Does anyone encounter the same issue?
+Any advice on this and how to fix it?
+
+Thanks,
+-- 
+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/2012-January/011524.html b/zarb-ml/mageia-dev/2012-January/011524.html new file mode 100644 index 000000000..8e97a0dca --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011524.html @@ -0,0 +1,112 @@ + + + + [Mageia-dev] [ANN] unbloated installer stage1 + + + + + + + + + +

[Mageia-dev] [ANN] unbloated installer stage1

+ John Balcaen + mikala at mageia.org +
+ Tue Jan 24 15:38:25 CET 2012 +

+
+ +
2012/1/24 Olav Vitters <olav at vitters.nl>:
+> On Tue, Jan 24, 2012 at 01:09:02PM +0100, Thierry Vignaud wrote:
+>> Total gain on boot.iso: -23Mb (57.5%) on x86_64 (less on i586)
+>
+> Yay, more space for GNOME! (my interest :P)
+:)
+Currently we also need a way to fix our iso creation :
+for example on Mageia DVD 1 there's 4703 packages available for a size
+of 3.7 Giga while Alpha 3 is providing only 4208 packages for a size
+of 4Gb ... so we're using more space for less packages.
+For kde's part we've got already some bug reports reporting missing
+packages that where only suggests before (yes misc  i agree that
+suggests is not the right way to add stuff but since they are not
+*required* to work a kde session there's no reason to add them as
+requires) & available in previous Mageia 1.
+I can of course add them as requires on the task-kde package but i
+think we should first start what we want to provides by default with
+our task.
+What should task-minimal requires ? just the desktop ? an irc client ?
+a web client  (well here firefox is the default one) a mail client ?
+etc etc
+Enabling suggests on bcd configuration is certainly a no go because
+we're already @ 4Go for dvd iso so part of the problem could probably
+be fixed in the task- packages & after we can probably still add some
+packages on the configuration.
+
+
+-- 
+Balcaen John
+Jabber-id: mikala at jabber.littleboboy.net
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011525.html b/zarb-ml/mageia-dev/2012-January/011525.html new file mode 100644 index 000000000..f9c966b75 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011525.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] Boot on Mageia Cauldron is damn slow! RFC + + + + + + + + + +

[Mageia-dev] Boot on Mageia Cauldron is damn slow! RFC

+ Frank Griffin + ftg at roadrunner.com +
+ Tue Jan 24 16:08:15 CET 2012 +

+
+ +
On 01/24/2012 09:06 AM, Damien Lallement wrote:
+> Hi,
+>
+> Since my laptop (HDD) is running Cauldron, it needs 5 minutes to boot 
+> whereas it was taking 1 minute under Mageia 1.
+> And on my working desktop (SSD), Mageia 1 was booting in 3 seconds and 
+> now it takes 1 minute.
+I've seen this on the first boot or two of fresh cauldron installs, but 
+not on later ones.  IIRC it is at least in part due to systemd timing 
+out waiting for plymouth to come down.  Also, I notivce that GDM takes a 
+horrific time to initialize itself, and the GUI response at the login 
+panel is very choppy.  I seem to remember seeing a bug report about GDM 
+pinning the CPU before it finally gets around to starting the DE.  HTH.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011526.html b/zarb-ml/mageia-dev/2012-January/011526.html new file mode 100644 index 000000000..5e4c6d4fc --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011526.html @@ -0,0 +1,164 @@ + + + + [Mageia-dev] [ANN] unbloated installer stage1 + + + + + + + + + +

[Mageia-dev] [ANN] unbloated installer stage1

+ andre999 + andre999mga at laposte.net +
+ Tue Jan 24 16:33:47 CET 2012 +

+
+ +
John Balcaen a écrit :
+> 2012/1/24 Olav Vitters<olav at vitters.nl>:
+>    
+>> On Tue, Jan 24, 2012 at 01:09:02PM +0100, Thierry Vignaud wrote:
+>>      
+>>> Total gain on boot.iso: -23Mb (57.5%) on x86_64 (less on i586)
+>>>        
+>> Yay, more space for GNOME! (my interest :P)
+>>      
+
+Nice work :)
+
+> :)
+> Currently we also need a way to fix our iso creation :
+> for example on Mageia DVD 1 there's 4703 packages available for a size
+> of 3.7 Giga while Alpha 3 is providing only 4208 packages for a size
+> of 4Gb ... so we're using more space for less packages.
+> For kde's part we've got already some bug reports reporting missing
+> packages that where only suggests before (yes misc  i agree that
+> suggests is not the right way to add stuff but since they are not
+> *required* to work a kde session there's no reason to add them as
+> requires)&  available in previous Mageia 1.
+> I can of course add them as requires on the task-kde package but i
+> think we should first start what we want to provides by default with
+> our task.
+> What should task-minimal requires ? just the desktop ? an irc client ?
+> a web client  (well here firefox is the default one) a mail client ?
+> etc etc
+> Enabling suggests on bcd configuration is certainly a no go because
+> we're already @ 4Go for dvd iso so part of the problem could probably
+> be fixed in the task- packages&  after we can probably still add some
+> packages on the configuration.
+>
+>    
+for task packages, I think a good presentation on installation would be 
+something like this :
+
+[]-+-- () all required packages
+    ()-internet
+    |  [] firefox - description
+    |  [] browser2 - desc
+    |  [] thunderbird - desc
+    |  [] email client2 - desc
+    |  [] iceape/seamonkey - desc
+    ()-office suites
+    |  [] libreoffice - desc
+    |  [] office suite2 - desc
+    []-other group 1 (can be all selected)
+    |  [] option1 - desc
+    |  [] option2 - desc
+    ()-other group 2 (selectable one at a time)
+       [] option1 - desc
+       [] option2 - desc
+     ...
+
+Notes:
+- each package not on the dvd would be noted as such.
+This should make it easier to deal with more limited space on the dvd.
+- () is to open to see more detail, but not a point of selection.
+- [] is a check box for selection, which includes the options to the 
+right/below.
+So clicking the top/left box would select everything.
+- packages already installed would be shown dim (if shown at all).
+- the optional packages would be "suggests".
+
+The idea is that any time a task package is selected, the same 
+presentation would appear, showing what is already installed, and that 
+deselecting an installed item would lead to its' uninstallation.
+
+Not an original idea, since some larger Ms-based apps (at least used to) 
+do this.
+Except that in Linux, packages are generally less self-contained and 
+more interdependant, so this schema would be more advantageous here.
+It would give users a lot easier control over what is installed.
+It could be applied to some non-task packages as well.
+
+One advantage of this is that we could have only one task-kde, one 
+task-gnome, etc.
+
+-- 
+André
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011527.html b/zarb-ml/mageia-dev/2012-January/011527.html new file mode 100644 index 000000000..c7dbf2589 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011527.html @@ -0,0 +1,146 @@ + + + + [Mageia-dev] Automount of CD/DVD seems broken + + + + + + + + + +

[Mageia-dev] Automount of CD/DVD seems broken

+ Frank Griffin + ftg at roadrunner.com +
+ Tue Jan 24 17:43:50 CET 2012 +

+
+ +
Sometime over the last couple of days, loaded DVDs are no longer being 
+mounted under /media.
+
+KDE recognizes the loaded DVD, and brings up the panel popup that gives 
+you suggested actions.  However, neither "df" nor "mount" shows the disk 
+to be mounted.
+
+LXDE does not seem to recognize the disk at all, and does not launch 
+either the "what should I do" prompt or the file manager display of the 
+folders on the disk.
+
+This system is updated with cauldron several times a day, and automount 
+was working last Thursday/Friday (Jan19/Jan20).  It was not working on 
+Jan23.
+
+No messages in syslog or messages reacting to the load of the disk at 
+all.  This was not the case on Jan19.:
+
+Jan 19 16:14:08 localhost halevt: halevt 0.1.6.2, 
+http://www.environnement.ens.fr/perso/dumas/halevt.html
+Jan 19 16:14:08 localhost halevt: No pid file used
+Jan 19 16:14:08 localhost halevt: Running: halevt-mount -u 
+/org/freedesktop/Hal/devices/volume_label_CSI_NY_S6_D4 -o flush
+Jan 19 16:14:12 localhost kernel: fuse init (API version 7.17)
+Jan 19 16:14:12 localhost multipathd: no /block/ in '/module/fuse'
+Jan 19 16:14:12 localhost multipathd: no /block/ in 
+'/devices/virtual/misc/fuse'
+Jan 19 16:14:12 localhost multipathd: no /block/ in 
+'/kernel/slab/fuse_inode'
+Jan 19 16:14:12 localhost multipathd: no /block/ in 
+'/kernel/slab/:t-0000608'
+Jan 19 16:14:12 localhost dbus[3068]: [system] Activating service 
+name='org.freedesktop.UDisks' (using servicehelper)
+Jan 19 16:14:12 localhost multipathd: no /block/ in 
+'/devices/virtual/bdi/0:30'
+Jan 19 16:14:13 localhost dbus[3068]: [system] Successfully activated 
+service 'org.freedesktop.UDisks'
+Jan 19 16:14:13 localhost multipathd: no /block/ in '/module/crc_itu_t'
+Jan 19 16:14:13 localhost multipathd: no /block/ in '/module/udf'
+Jan 19 16:14:13 localhost multipathd: no /block/ in 
+'/kernel/slab/udf_inode_cache'
+Jan 19 16:14:13 localhost multipathd: no /block/ in '/module/nls_utf8'
+Jan 19 16:14:14 localhost kernel: UDF-fs: Partition marked readonly; 
+forcing readonly mount
+Jan 19 16:14:14 localhost kernel: UDF-fs: INFO Mounting volume 
+'CSI_NY_S6_D4', timestamp 2010/08/16 16:11 (1ed4)
+Jan 19 16:14:14 localhost halevt: Running: /usr/bin/halevt-explore-mount 
+"/media/CSI_NY_S6_D4"
+Jan 19 16:14:14 localhost halevt: Running: halevt-mount -s
+
+Just to be certain, I updated cauldron just before sending this, and 
+rebooted.  Same problem.
+
+Any idea what happened ?
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011528.html b/zarb-ml/mageia-dev/2012-January/011528.html new file mode 100644 index 000000000..de58d85b0 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011528.html @@ -0,0 +1,130 @@ + + + + [Mageia-dev] Boot on Mageia Cauldron is damn slow! RFC + + + + + + + + + +

[Mageia-dev] Boot on Mageia Cauldron is damn slow! RFC

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Jan 24 17:54:43 CET 2012 +

+
+ +
'Twas brillig, and Damien Lallement at 24/01/12 14:06 did gyre and gimble:
+> Hi,
+> 
+> Since my laptop (HDD) is running Cauldron, it needs 5 minutes to boot
+> whereas it was taking 1 minute under Mageia 1.
+> And on my working desktop (SSD), Mageia 1 was booting in 3 seconds and
+> now it takes 1 minute.
+> 
+> Here are my bootcharts:
+> - Lenovo X220 with HDD :
+> http://damsweb.net/trash/bootchart-mga_cauldron-lenovo_x220.png
+> 
+> - Homemade core i3 + SSD :
+> http://damsweb.net/trash/bootchart-mga_cauldron-ssd.png
+> 
+> Does anyone encounter the same issue?
+> Any advice on this and how to fix it?
+
+One obvious issue (which is on my todo list) is that prefdm.service
+currently has a hard dep on network-up. We need this if the user has
+network based auth (e.g. ldap, NIS etc.)
+
+In your SSD case, this accounts for at least 25s delay.
+
+We need to have a little service (or something in drakauth) that
+adds/removes the dependency on network-up when a network authentication
+mechanism is detected.
+
+Not sure how we handled this in mga1 (possibly not at all!).
+
+Col
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011529.html b/zarb-ml/mageia-dev/2012-January/011529.html new file mode 100644 index 000000000..5895f6522 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011529.html @@ -0,0 +1,125 @@ + + + + [Mageia-dev] Boot on Mageia Cauldron is damn slow! RFC + + + + + + + + + +

[Mageia-dev] Boot on Mageia Cauldron is damn slow! RFC

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Tue Jan 24 18:01:48 CET 2012 +

+
+ +
Le 24/01/2012 17:54, Colin Guthrie a écrit :
+> 'Twas brillig, and Damien Lallement at 24/01/12 14:06 did gyre and gimble:
+>> Hi,
+>>
+>> Since my laptop (HDD) is running Cauldron, it needs 5 minutes to boot
+>> whereas it was taking 1 minute under Mageia 1.
+>> And on my working desktop (SSD), Mageia 1 was booting in 3 seconds and
+>> now it takes 1 minute.
+>>
+>> Here are my bootcharts:
+>> - Lenovo X220 with HDD :
+>> http://damsweb.net/trash/bootchart-mga_cauldron-lenovo_x220.png
+>>
+>> - Homemade core i3 + SSD :
+>> http://damsweb.net/trash/bootchart-mga_cauldron-ssd.png
+>>
+>> Does anyone encounter the same issue?
+>> Any advice on this and how to fix it?
+>
+> One obvious issue (which is on my todo list) is that prefdm.service
+> currently has a hard dep on network-up. We need this if the user has
+> network based auth (e.g. ldap, NIS etc.)
+>
+> In your SSD case, this accounts for at least 25s delay.
+>
+> We need to have a little service (or something in drakauth) that
+> adds/removes the dependency on network-up when a network authentication
+> mechanism is detected.
+>
+> Not sure how we handled this in mga1 (possibly not at all!).
+People using network authentication are supposed to be a bit more 
+knowledgeful than average joe user. I'd let them manage this issue 
+manually, provided it is documented somewhere, rather than bloat 
+installation with any kind of "smart logic".
+
+-- 
+BOFH excuse #434:
+
+Please state the nature of the technical emergency
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011530.html b/zarb-ml/mageia-dev/2012-January/011530.html new file mode 100644 index 000000000..3ba9af71a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011530.html @@ -0,0 +1,119 @@ + + + + [Mageia-dev] Boot on Mageia Cauldron is damn slow! RFC + + + + + + + + + +

[Mageia-dev] Boot on Mageia Cauldron is damn slow! RFC

+ Pascal Terjan + pterjan at gmail.com +
+ Tue Jan 24 18:25:09 CET 2012 +

+
+ +
On Tue, Jan 24, 2012 at 16:54, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+> 'Twas brillig, and Damien Lallement at 24/01/12 14:06 did gyre and gimble:
+>> Hi,
+>>
+>> Since my laptop (HDD) is running Cauldron, it needs 5 minutes to boot
+>> whereas it was taking 1 minute under Mageia 1.
+>> And on my working desktop (SSD), Mageia 1 was booting in 3 seconds and
+>> now it takes 1 minute.
+>>
+>> Here are my bootcharts:
+>> - Lenovo X220 with HDD :
+>> http://damsweb.net/trash/bootchart-mga_cauldron-lenovo_x220.png
+>>
+>> - Homemade core i3 + SSD :
+>> http://damsweb.net/trash/bootchart-mga_cauldron-ssd.png
+>>
+>> Does anyone encounter the same issue?
+>> Any advice on this and how to fix it?
+>
+> One obvious issue (which is on my todo list) is that prefdm.service
+> currently has a hard dep on network-up. We need this if the user has
+> network based auth (e.g. ldap, NIS etc.)
+>
+> In your SSD case, this accounts for at least 25s delay.
+>
+> We need to have a little service (or something in drakauth) that
+> adds/removes the dependency on network-up when a network authentication
+> mechanism is detected.
+>
+> Not sure how we handled this in mga1 (possibly not at all!).
+
+There is /etc/init.d/network-auth which is enabled if needed (probably
+in drakauth code)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011531.html b/zarb-ml/mageia-dev/2012-January/011531.html new file mode 100644 index 000000000..50e29371e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011531.html @@ -0,0 +1,146 @@ + + + + [Mageia-dev] eth0 no longer interacts with DHCP at boot ? + + + + + + + + + +

[Mageia-dev] eth0 no longer interacts with DHCP at boot ?

+ Frank Griffin + ftg at roadrunner.com +
+ Tue Jan 24 18:36:26 CET 2012 +

+
+ +
Yet another recent strangeness that started sometime last week...
+
+My system has a single, wired NIC (eth0) configured to be started at 
+boot.  It is also configured to use DHCP and to get its hostname from 
+the DHCP server.
+
+For the last few days, when I boot, the interface comes up, but the 
+hostname is set to localhost.localdomain, and there are no messages in 
+syslog indicating that any DHCP requests are being sent.  I get to the 
+network just fine, but ifconfig shows:
+
+eth0      Link encap:Ethernet  HWaddr 00:0C:41:EE:E2:E1
+           inet6 addr: fe80::20c:41ff:feee:e2e1/64 Scope:Link
+           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
+           RX packets:25770 errors:0 dropped:0 overruns:0 frame:0
+           TX packets:24117 errors:0 dropped:0 overruns:0 carrier:0
+           collisions:0 txqueuelen:1000
+           RX bytes:8936889 (8.5 MiB)  TX bytes:3339309 (3.1 MiB)
+           Interrupt:21 Base address:0xe800
+
+i. e. eth0 has no ipv4 IP address.  However, syslog *does* contain the line:
+
+Jan 24 11:10:55 localhost kernel: eth0: no IPv6 routers present
+
+So to whom is he talking ?  Moreover, looking at ifcfg-eth0:
+
+DEVICE=eth0
+BOOTPROTO=dhcp
+ONBOOT=yes
+METRIC=10
+MII_NOT_SUPPORTED=no
+USERCTL=no
+RESOLV_MODS=no
+IPV6INIT=no
+IPV6TO4INIT=no
+ACCOUNTING=no
+NM_CONTROLLED=no
+DHCP_CLIENT=dhclient
+NEEDHOSTNAME=yes
+PEERDNS=yes
+PEERYP=yes
+PEERNTPD=no
+
+IPv6 seems to be disabled completely.
+
+If I ifdown/ifup eth0, things go back to normal:
+
+eth0      Link encap:Ethernet  HWaddr 00:0C:41:EE:E2:E1
+           inet addr:192.168.3.102  Bcast:192.168.3.255  Mask:255.255.255.0
+           inet6 addr: fe80::20c:41ff:feee:e2e1/64 Scope:Link
+           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
+           RX packets:25979 errors:0 dropped:0 overruns:0 frame:0
+           TX packets:24333 errors:0 dropped:0 overruns:0 carrier:0
+           collisions:0 txqueuelen:1000
+           RX bytes:8971923 (8.5 MiB)  TX bytes:3392939 (3.2 MiB)
+           Interrupt:21 Base address:0xe800
+
+So what has changed in the boot-time interface starting procedure ?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011532.html b/zarb-ml/mageia-dev/2012-January/011532.html new file mode 100644 index 000000000..0838dc2a1 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011532.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] Automount of CD/DVD seems broken + + + + + + + + + +

[Mageia-dev] Automount of CD/DVD seems broken

+ Frank Griffin + ftg at roadrunner.com +
+ Tue Jan 24 18:46:33 CET 2012 +

+
+ +
On 01/24/2012 11:43 AM, Frank Griffin wrote:
+> Sometime over the last couple of days, loaded DVDs are no longer being 
+> mounted under /media.
+
+BTW, this is interfering with several things.  Wine apps can't "see" a 
+disk unless its mounted, and neither can Brasero running under KDE.  
+Previously, you could start Brasero to burn an ISO while the drive was 
+empty, and it would come up telling you to load a disk.  When you did, 
+and the KDE device notification appeared, the Brasero window would 
+change to select that disk as the target.  Now it does not.  Nor does it 
+if you start it after KDE has recognized the blank disk.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011533.html b/zarb-ml/mageia-dev/2012-January/011533.html new file mode 100644 index 000000000..b6f30de53 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011533.html @@ -0,0 +1,137 @@ + + + + [Mageia-dev] Boot on Mageia Cauldron is damn slow! RFC + + + + + + + + + +

[Mageia-dev] Boot on Mageia Cauldron is damn slow! RFC

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Jan 24 21:13:40 CET 2012 +

+
+ +
'Twas brillig, and Pascal Terjan at 24/01/12 17:25 did gyre and gimble:
+> On Tue, Jan 24, 2012 at 16:54, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+>> 'Twas brillig, and Damien Lallement at 24/01/12 14:06 did gyre and gimble:
+>>> Hi,
+>>>
+>>> Since my laptop (HDD) is running Cauldron, it needs 5 minutes to boot
+>>> whereas it was taking 1 minute under Mageia 1.
+>>> And on my working desktop (SSD), Mageia 1 was booting in 3 seconds and
+>>> now it takes 1 minute.
+>>>
+>>> Here are my bootcharts:
+>>> - Lenovo X220 with HDD :
+>>> http://damsweb.net/trash/bootchart-mga_cauldron-lenovo_x220.png
+>>>
+>>> - Homemade core i3 + SSD :
+>>> http://damsweb.net/trash/bootchart-mga_cauldron-ssd.png
+>>>
+>>> Does anyone encounter the same issue?
+>>> Any advice on this and how to fix it?
+>>
+>> One obvious issue (which is on my todo list) is that prefdm.service
+>> currently has a hard dep on network-up. We need this if the user has
+>> network based auth (e.g. ldap, NIS etc.)
+>>
+>> In your SSD case, this accounts for at least 25s delay.
+>>
+>> We need to have a little service (or something in drakauth) that
+>> adds/removes the dependency on network-up when a network authentication
+>> mechanism is detected.
+>>
+>> Not sure how we handled this in mga1 (possibly not at all!).
+> 
+> There is /etc/init.d/network-auth which is enabled if needed (probably
+> in drakauth code)
+
+Yeah this would be fine I think... a simple "After=network-auth.service"
+should do as if it's not enabled, then the After should be a noop.
+
+Col
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011534.html b/zarb-ml/mageia-dev/2012-January/011534.html new file mode 100644 index 000000000..142fd53c6 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011534.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] Trying to find a mentor + + + + + + + + + +

[Mageia-dev] Trying to find a mentor

+ Jaromír Cápík + tavvva at seznam.cz +
+ Tue Jan 24 21:09:45 CET 2012 +

+
+ +
Hello guys.
+
+I'm trying to find a mentor.
+I already have some experience with packaging
+since I own 60 Fedora packages and 20 more
+are comaintained by me.
+I have also some packaging experience with
+two ArchLinux based distros for old computers. 
+One of them is exclusively supervised by me
+and I maintain almost all it's packages.
+I believe I wouldn't steal much time from my mentor.
+Please, let me know if You'd like to help me
+with that.
+
+Thanks in advance.
+
+Regards,
+Jaromir.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011535.html b/zarb-ml/mageia-dev/2012-January/011535.html new file mode 100644 index 000000000..6df705509 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011535.html @@ -0,0 +1,112 @@ + + + + [Mageia-dev] Build tip welcome + + + + + + + + + +

[Mageia-dev] Build tip welcome

+ Zézinho + lists.jjorge at free.fr +
+ Tue Jan 24 21:35:40 CET 2012 +

+
+ +
I am trying to update IceWM to 1.3.7 as Fedora did.
+It does not build on Cauldron :
+http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20120124202332.zezinho.valstar.28538
+
+Even the current version 1.3.3 does not build in Cauldron. I welcome 
+any hint about this :
+
+In file included from /usr/include/glib-2.0/glib/gthread.h:34:0,
+                 from /usr/include/glib-2.0/glib/gasyncqueue.h:34,
+                 from /usr/include/glib-2.0/glib.h:34,
+                 from /usr/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixbuf.h:31,
+                 from /usr/include/gdk-pixbuf-2.0/gdk-pixbuf-xlib/gdk-pixbuf-
+xlib.h:24,
+                 from yimage.cc:17:
+/usr/include/glib-2.0/glib/gatomic.h:65:1: error: ‘deprecated’ was not 
+declared in this scope
+/usr/include/glib-2.0/glib/gatomic.h:65:1: error: expected ‘)’ before ‘(’ 
+token
+/usr/include/glib-2.0/glib/gatomic.h:65:1: error: expected ‘)’ before ‘(’ 
+token
+/usr/include/glib-2.0/glib/gatomic.h:65:1: error: expected unqualified-id 
+before string constant
+/usr/include/glib-2.0/glib/gatomic.h:65:1: error: expected ‘)’ before 
+string constant
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011536.html b/zarb-ml/mageia-dev/2012-January/011536.html new file mode 100644 index 000000000..d0e3ac750 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011536.html @@ -0,0 +1,111 @@ + + + + [Mageia-dev] Trying to find a mentor + + + + + + + + + +

[Mageia-dev] Trying to find a mentor

+ D.Morgan + dmorganec at gmail.com +
+ Tue Jan 24 21:40:59 CET 2012 +

+
+ +
On Tue, Jan 24, 2012 at 9:09 PM, Jaromír Cápík <tavvva at seznam.cz> wrote:
+> Hello guys.
+>
+> I'm trying to find a mentor.
+> I already have some experience with packaging
+> since I own 60 Fedora packages and 20 more
+> are comaintained by me.
+> I have also some packaging experience with
+> two ArchLinux based distros for old computers.
+> One of them is exclusively supervised by me
+> and I maintain almost all it's packages.
+> I believe I wouldn't steal much time from my mentor.
+> Please, let me know if You'd like to help me
+> with that.
+>
+> Thanks in advance.
+>
+> Regards,
+> Jaromir.
+
+Hi,
+
+i can take you as apprentice as this may be for a short time ;)
+
+please create an account on identity.mageia.org and create a bugreport
+to ask for an account with you public ssh key inside
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011537.html b/zarb-ml/mageia-dev/2012-January/011537.html new file mode 100644 index 000000000..f92479f95 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011537.html @@ -0,0 +1,89 @@ + + + + [Mageia-dev] KDE 4.8.0 & Qt 4.8.0 soon on cauldron + + + + + + + + + +

[Mageia-dev] KDE 4.8.0 & Qt 4.8.0 soon on cauldron

+ Balcaen John + mikala at mageia.org +
+ Tue Jan 24 21:54:35 CET 2012 +

+
+ +
On Thursday 19 January 2012 07:00:11 Balcaen John wrote :
+> Hello,
+> 
+> Just to let you know that in order to push KDE 4.8.0, i'll also push before
+> Qt 4.8.0 so some others packages might need a rebuild since the qt prefix
+> was change to follow %{_libdir} (like it's done in fedora) instead of being
+> harcoded to /usr/lib, the qt4includedir macro was also fixed previously by
+> dmorgan.
+> KDE 4.8.0 should follow soon after Qt 4.8.0 because from local test done
+> with the 4.7.90, KDE can be *really* slow until kdelibs,kde-runtime &
+> kde-workspace has been rebuild against Qt 4.8.0.
+Since kde 4.8.0 should be released on 25th i'll start to push Qt 4.8 & some Qt 
+related software tonight so for the 10 users of cauldron's kde it could be 
+wise to wait for the end of kde's update before updating :)
+
+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/2012-January/011538.html b/zarb-ml/mageia-dev/2012-January/011538.html new file mode 100644 index 000000000..aae66cbae --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011538.html @@ -0,0 +1,153 @@ + + + + [Mageia-dev] [ANN] unbloated installer stage1 + + + + + + + + + +

[Mageia-dev] [ANN] unbloated installer stage1

+ Per Øyvind Karlsen + peroyvind at mandriva.org +
+ Tue Jan 24 22:03:06 CET 2012 +

+
+ +
Den 13:09 24. januar 2012 skrev Thierry Vignaud
+<thierry.vignaud at gmail.com> følgende:
+> Hi
+>
+> Over the years, stage1 (both  all.rdz, boot.iso, ...) got bigger & bigger:
+> 10.0-10.1: 8Mo
+> 10.2-2005: 15M      <=======
+> 2006.0: 13M
+> 2007.0: 14M
+> 2007.1: 10M
+> 2008.0-2008.1: 12M
+> 2009.0: 26M      <=======
+> 2009.1: 32M      <=======
+> 2010.0: 33M
+> 2010.1: 36M (37M on 64 bit)
+> 2011   : 44M
+> mga1  : 39M (40M on 64bit) (NEW: 53M on non-free 64 bit...)
+>
+> I've reduced this by:
+> - removing alt1 (x86_64 only for now):
+> - removing busybox
+> - compressing initrd with XZ instead of gzip: only good on firmware
+> - re compressing kernel modules with XZ instead of gzip:
+lzma supports much bigger dictionaries than zlib, so in stead of
+compressing the kernel modules individually, you'd achieve much better
+compression by just letting them be compressed once as part
+of the initrd as they'd all share one big dictionary. :)
+lzma also has several options you may tune to improve compression even
+further.
+>
+> Removing alt1 (x86_64 only for now) saved 20Mb on boot.iso (50%)
+> and on boot-nonfree.iso (43%).
+>
+> Removing busybox saved 1B (5.7% of all.rdz, 5% of boot.iso,
+> 3.7% of boot-nonfree.iso)
+Why not replace all the programs possible with busybox alternatives
+and link everything against uClibc rather than glibc?
+>
+> Compressing initrd with XZ instead of gzip saved 2Mo (7.7%) on
+> boot-nonfree.iso (better compressed firmwares).
+avoiding compression of any individual files (not just kernel modules) and just
+compress them all together once will help increase compression ratio.
+>
+> Re-compressing kernel modules with XZ instead of gzip saved -2.4Mb (15.9%)
+> on all.rdz, -2Mb (10.5%) on boot.iso, -2mb on boot-nonfree.iso (8.3%)
+>
+> Total gain on boot.iso: -23Mb (57.5%) on x86_64 (less on i586)
+>
+> This should save space on ISOs too (we could save more by
+> not including install/images on ISOs btw)
+>
+> There's a minor drawback: KA install won't work anymore but
+> it's a niche. Is there someone using that feature?
+> The proper way to support it would be to either:
+> - have a stage1.5 for KA with busybox
+> - include a static mke2fs (compiled against dietlibc)
+compile everything against shared uClibc libraries in stead! :)
+There might also be a gain in using the new x32abi introduced in
+latest kernels..
+> - disable KA support
+
+To give an example, by applying these "tricks" to mkinitrd in the
+past, I managed
+to reduce it's size all the way down to just below 1MB (which also
+added a full-featured
+busybox build for rescue environment, going further and using a
+minimal busybox build
+and dropping plymouth I managed to push it further down to 100KB! :).
+
+--
+Regards,
+Per Øyvind
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011539.html b/zarb-ml/mageia-dev/2012-January/011539.html new file mode 100644 index 000000000..920c31290 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011539.html @@ -0,0 +1,85 @@ + + + + [Mageia-dev] [ANN] unbloated installer stage1 + + + + + + + + + +

[Mageia-dev] [ANN] unbloated installer stage1

+ Per Øyvind Karlsen + peroyvind at mandriva.org +
+ Tue Jan 24 22:16:20 CET 2012 +

+
+ +
Den 22:03 24. januar 2012 skrev Per Øyvind Karlsen
+<peroyvind at mandriva.org> følgende:
+> Den 13:09 24. januar 2012 skrev Thierry Vignaud
+>> - include a static mke2fs (compiled against dietlibc)
+busybox has a mke2fs implementation  btw. ;)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011540.html b/zarb-ml/mageia-dev/2012-January/011540.html new file mode 100644 index 000000000..8590c1185 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011540.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] Boot on Mageia Cauldron is damn slow! RFC + + + + + + + + + +

[Mageia-dev] Boot on Mageia Cauldron is damn slow! RFC

+ Damien Lallement + mageia at damsweb.net +
+ Tue Jan 24 18:17:07 CET 2012 +

+
+ +
Le 24/01/2012 16:08, Frank Griffin a écrit :
+> On 01/24/2012 09:06 AM, Damien Lallement wrote:
+>> Hi,
+>>
+>> Since my laptop (HDD) is running Cauldron, it needs 5 minutes to boot
+>> whereas it was taking 1 minute under Mageia 1.
+>> And on my working desktop (SSD), Mageia 1 was booting in 3 seconds and
+>> now it takes 1 minute.
+> I've seen this on the first boot or two of fresh cauldron installs, but
+> not on later ones. IIRC it is at least in part due to systemd timing out
+> waiting for plymouth to come down. Also, I notivce that GDM takes a
+> horrific time to initialize itself, and the GUI response at the login
+> panel is very choppy. I seem to remember seeing a bug report about GDM
+> pinning the CPU before it finally gets around to starting the DE. HTH.
+
+For my part, I'm in Cauldron for 8 months... So I have more than 2 or 3 
+boots.
+-- 
+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/2012-January/011541.html b/zarb-ml/mageia-dev/2012-January/011541.html new file mode 100644 index 000000000..304a1fd3e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011541.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] Boot on Mageia Cauldron is damn slow! RFC + + + + + + + + + +

[Mageia-dev] Boot on Mageia Cauldron is damn slow! RFC

+ Balcaen John + mikala at mageia.org +
+ Tue Jan 24 23:09:45 CET 2012 +

+
+ +
On Tuesday 24 January 2012 18:17:07 Damien Lallement wrote :
+[...]
+> For my part, I'm in Cauldron for 8 months... So I have more than 2 or 3
+> boots.
+Oh you're rebooting ? ;o)
+
+
+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/2012-January/011542.html b/zarb-ml/mageia-dev/2012-January/011542.html new file mode 100644 index 000000000..b9e384c8f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011542.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] Slow gnome-shell due to new cogl/clutter + + + + + + + + + +

[Mageia-dev] Slow gnome-shell due to new cogl/clutter

+ JA Magallón + jamagallon at ono.com +
+ Tue Jan 24 23:44:24 CET 2012 +

+
+ +
On 01/22/2012 09:16 PM, Olav Vitters wrote:
+> On Sat, Jan 21, 2012 at 07:21:37PM +0000, Colin Guthrie wrote:
+>> 'Twas brillig, and Olav Vitters at 21/01/12 12:16 did gyre and gimble:
+>>> On Sat, Jan 21, 2012 at 12:26:57AM +0100, JA Magallón wrote:
+>>>> This did not fix the problem, but it looks that got fixed in gnome-shell GIT:
+>>>>
+>>>> http://ubuntuforums.org/showthread.php?t=1910576
+>>>
+>>> Please test for me, atm unable to do so :-(
+>>>
+>>> Newer stuff has been packaged..
+>>
+>> Do I need to rebuild anything locally for testing? Tried a fully updated
+>> system (new gtk, new g-s) and it's still busted :(
+> 
+> Some assistance would be very welcome yeah. Suggest to contact ebassi.
+> We've replaced (upgraded) clutter, gnome-shell and mutter by now. I
+> guess something needs to be rebuild.
+> 
+
+Yeaaahh!
+New clutter 1.9.8 fixed this. G-S is back to good speed again...
+
+Just a little minor bug(?): in GDM, when you click on the password text
+field, you have no cursor until you begin to write, so you are not sure
+if you are typing in the correct place... but I can live with that.
+
+-- 
+J.A. Magallon <jamagallon()ono!com>        \               Winter is coming...
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011543.html b/zarb-ml/mageia-dev/2012-January/011543.html new file mode 100644 index 000000000..6e3cb2a2f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011543.html @@ -0,0 +1,85 @@ + + + + [Mageia-dev] "Uploaded" status on the web page + + + + + + + + + +

[Mageia-dev] "Uploaded" status on the web page

+ Balcaen John + mikala at mageia.org +
+ Wed Jan 25 04:07:14 CET 2012 +

+
+ +
On Sunday 22 January 2012 15:51:28 Pascal Terjan wrote :
+> I did some minor changes in the build system meaning that "uploaded"
+> now really mean uploaded (the package is guaranteed to be in the
+> hdlists), and you can safely submit anything depending on it.
+Hum in fact it seems not « perfect » :/
+I had tonight qtsingleapplication failing while it should not since the 
+correct qtlockedfile was « uploaded ».
+Anyway  the delay is far shorter than it was before so that's enough, i'll add 
+a little delay on my bash script ;o).
+
+
+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/2012-January/011544.html b/zarb-ml/mageia-dev/2012-January/011544.html new file mode 100644 index 000000000..072f7e6c4 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011544.html @@ -0,0 +1,78 @@ + + + + [Mageia-dev] Fosdem 2012 - Mageia stand + + + + + + + + + +

[Mageia-dev] Fosdem 2012 - Mageia stand

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Wed Jan 25 09:21:41 CET 2012 +

+
+ +
Am Sonntag, den 15.01.2012, 11:38 +0100 schrieb Oliver Burger:
+> Calling again...
+> 
+> Until now we have 19 people coming to FOSDEM but only 5 who have
+> volunteered to help for some time at the stand.
+> 
+> So, if you are coming to FOSDEM, please consider helping us there, so
+> it won't be a few people having to stay there the whole day.
+
+It's always great to have so many people reacting...
+
+We are about 20 people at Fosdem and only five of them do volunteer to
+help at the stand, meaning those five will have actually not time left
+to attend any sessions?
+I don't really believe this.
+
+Or am I just too German in my organisation and the way to go is to just
+wait who will honour us with his presence? And I can throw the whole
+organisation out of the window?
+
+Oliver
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011545.html b/zarb-ml/mageia-dev/2012-January/011545.html new file mode 100644 index 000000000..76d9ef5ff --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011545.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] Fosdem 2012 - Mageia stand + + + + + + + + + +

[Mageia-dev] Fosdem 2012 - Mageia stand

+ Remco Rijnders + remco at webconquest.com +
+ Wed Jan 25 09:26:21 CET 2012 +

+
+ +
On Wed, Jan 25, 2012 at 09:21:41AM +0100, Oliver wrote in 
+<1327479701.21166.4.camel at beteigeuze.oli-home>:
+>Am Sonntag, den 15.01.2012, 11:38 +0100 schrieb Oliver Burger:
+>> Calling again...
+>>
+>> Until now we have 19 people coming to FOSDEM but only 5 who have
+>> volunteered to help for some time at the stand.
+>>
+>> So, if you are coming to FOSDEM, please consider helping us there, so
+>> it won't be a few people having to stay there the whole day.
+>
+>It's always great to have so many people reacting...
+>
+>We are about 20 people at Fosdem and only five of them do volunteer to
+>help at the stand, meaning those five will have actually not time left
+>to attend any sessions?
+>I don't really believe this.
+>
+>Or am I just too German in my organisation and the way to go is to just
+>wait who will honour us with his presence? And I can throw the whole
+>organisation out of the window?
+
+Speaking only for myself here... I had the distinct impression when I 
+looked at the FOSDEM site a few weeks back that the list of talks was not 
+complete yet. I was kind of waiting on that to see what talks I really 
+wanted to attend, and then see what times that'd leave me to help at the 
+stand.
+
+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/20120125/aac479d5/attachment.asc>
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011546.html b/zarb-ml/mageia-dev/2012-January/011546.html new file mode 100644 index 000000000..bf1c12911 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011546.html @@ -0,0 +1,83 @@ + + + + [Mageia-dev] "Uploaded" status on the web page + + + + + + + + + +

[Mageia-dev] "Uploaded" status on the web page

+ Pascal Terjan + pterjan at gmail.com +
+ Wed Jan 25 09:54:49 CET 2012 +

+
+ +
On Wed, Jan 25, 2012 at 03:07, Balcaen John <mikala at mageia.org> wrote:
+> On Sunday 22 January 2012 15:51:28 Pascal Terjan wrote :
+>> I did some minor changes in the build system meaning that "uploaded"
+>> now really mean uploaded (the package is guaranteed to be in the
+>> hdlists), and you can safely submit anything depending on it.
+> Hum in fact it seems not « perfect » :/
+> I had tonight qtsingleapplication failing while it should not since the
+> correct qtlockedfile was « uploaded ».
+> Anyway  the delay is far shorter than it was before so that's enough, i'll add
+> a little delay on my bash script ;o).
+
+Really there should not be any delay at all
+The website will only display uploaded after youri-submit has finished
+running for all packages for this target, that includes running
+genhdlist2 and rsync to reference mirror
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011547.html b/zarb-ml/mageia-dev/2012-January/011547.html new file mode 100644 index 000000000..eeecfeaaa --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011547.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] Fosdem 2012 - Mageia stand + + + + + + + + + +

[Mageia-dev] Fosdem 2012 - Mageia stand

+ Claire REVILLET + grenoya at zarb.org +
+ Wed Jan 25 09:57:18 CET 2012 +

+
+ +
Le 25/01/2012 09:21, Oliver Burger a écrit :
+> Am Sonntag, den 15.01.2012, 11:38 +0100 schrieb Oliver Burger:
+>> Calling again...
+>>
+>> Until now we have 19 people coming to FOSDEM but only 5 who have
+>> volunteered to help for some time at the stand.
+>>
+>> So, if you are coming to FOSDEM, please consider helping us there, so
+>> it won't be a few people having to stay there the whole day.
+> It's always great to have so many people reacting...
+>
+> We are about 20 people at Fosdem and only five of them do volunteer to
+> help at the stand, meaning those five will have actually not time left
+> to attend any sessions?
+> I don't really believe this.
+>
+> Or am I just too German in my organisation and the way to go is to just
+> wait who will honour us with his presence? And I can throw the whole
+> organisation out of the window?
+>
+> Oliver
+>
+
+Hi
+I'll be happy to help for the booth :)
+I just did not yet took the time to look at the talk planning...I'll 
+fill the wiki as soon as I do it.
+
+Claire
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011548.html b/zarb-ml/mageia-dev/2012-January/011548.html new file mode 100644 index 000000000..eecc70b3a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011548.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] KDE 4.8 updates and panel issues + + + + + + + + + +

[Mageia-dev] KDE 4.8 updates and panel issues

+ Robert Fox + list at foxconsult.net +
+ Wed Jan 25 10:47:07 CET 2012 +

+
+ +
I just updated two systems to the latest Cauldron with KDE 4.8 packages
+- looking good, except that the panel is now in "Classic Menu" mode and
+there is no longer the option to switch to "Application Launcher Menu" 
+
+Am I missing something?
+
+Thx,
+R.Fox
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011549.html b/zarb-ml/mageia-dev/2012-January/011549.html new file mode 100644 index 000000000..d91ab2c38 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011549.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] KDE 4.8 updates and panel issues + + + + + + + + + +

[Mageia-dev] KDE 4.8 updates and panel issues

+ Balcaen John + mikala at mageia.org +
+ Wed Jan 25 11:34:19 CET 2012 +

+
+ +
On Wednesday 25 January 2012 10:47:07 Robert Fox wrote :
+> I just updated two systems to the latest Cauldron with KDE 4.8 packages
+> - looking good, except that the panel is now in "Classic Menu" mode and
+> there is no longer the option to switch to "Application Launcher Menu"
+> 
+> Am I missing something?
+Yep,  you probably missed my previous mail regarding the fix for plasmarc 
+reading files ( https://www.mageia.org/pipermail/mageia-dev/2012-
+January/011473.html which is fact might be wrong because even people removing 
+the ~/.kde4/ will probably encounter this bug )
+So here i would say that you're running 2 pannels (the one that was available 
+before the commit after 4.7.90) & the one you probably added to fix this issue.
+
+You should removed this panel.
+
+One more point is that the kde update is of course not complete so far (& 
+since the BS is currently under a perl flood i don't know when it will be fixed 
+:p )
+
+
+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/2012-January/011550.html b/zarb-ml/mageia-dev/2012-January/011550.html new file mode 100644 index 000000000..d069af10a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011550.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] "Uploaded" status on the web page + + + + + + + + + +

[Mageia-dev] "Uploaded" status on the web page

+ Balcaen John + mikala at mageia.org +
+ Wed Jan 25 11:47:09 CET 2012 +

+
+ +
On Wednesday 25 January 2012 08:54:49 Pascal Terjan wrote :
+> On Wed, Jan 25, 2012 at 03:07, Balcaen John <mikala at mageia.org> wrote:
+> > On Sunday 22 January 2012 15:51:28 Pascal Terjan wrote :
+> >> I did some minor changes in the build system meaning that "uploaded"
+> >> now really mean uploaded (the package is guaranteed to be in the
+> >> hdlists), and you can safely submit anything depending on it.
+> > 
+> > Hum in fact it seems not « perfect » :/
+> > I had tonight qtsingleapplication failing while it should not since the
+> > correct qtlockedfile was « uploaded ».
+> > Anyway  the delay is far shorter than it was before so that's enough, i'll
+> > add a little delay on my bash script ;o).
+> 
+> Really there should not be any delay at all
+> The website will only display uploaded after youri-submit has finished
+> running for all packages for this target, that includes running
+> genhdlist2 and rsync to reference mirror
+I don't know here :/
+the only reason for not building  ( 
+http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20120125021624.mikala.valstar.14674/ 
+) of qtsingleapplication, was to use a non rebuild qtlockedfile (so the 
+qtlockedfile.h was not in the correct place when qtsingleapplication need it).
+A simple wait & pushing it few minutes after fix it.
+
+For memory i'm using this https://gitorious.org/~jbalcaen/mgaqueue/jbalcaen-
+mgaqueue to push package only when the previous is uploaded (with the support 
+of the build throttle so maybe more people can you use 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/2012-January/011551.html b/zarb-ml/mageia-dev/2012-January/011551.html new file mode 100644 index 000000000..75bec65e9 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011551.html @@ -0,0 +1,110 @@ + + + + [Mageia-dev] Slow gnome-shell due to new cogl/clutter + + + + + + + + + +

[Mageia-dev] Slow gnome-shell due to new cogl/clutter

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Wed Jan 25 12:21:42 CET 2012 +

+
+ +
'Twas brillig, and JA Magallón at 24/01/12 22:44 did gyre and gimble:
+> On 01/22/2012 09:16 PM, Olav Vitters wrote:
+>> On Sat, Jan 21, 2012 at 07:21:37PM +0000, Colin Guthrie wrote:
+>>> 'Twas brillig, and Olav Vitters at 21/01/12 12:16 did gyre and gimble:
+>>>> On Sat, Jan 21, 2012 at 12:26:57AM +0100, JA Magallón wrote:
+>>>>> This did not fix the problem, but it looks that got fixed in gnome-shell GIT:
+>>>>>
+>>>>> http://ubuntuforums.org/showthread.php?t=1910576
+>>>>
+>>>> Please test for me, atm unable to do so :-(
+>>>>
+>>>> Newer stuff has been packaged..
+>>>
+>>> Do I need to rebuild anything locally for testing? Tried a fully updated
+>>> system (new gtk, new g-s) and it's still busted :(
+>>
+>> Some assistance would be very welcome yeah. Suggest to contact ebassi.
+>> We've replaced (upgraded) clutter, gnome-shell and mutter by now. I
+>> guess something needs to be rebuild.
+>>
+> 
+> Yeaaahh!
+> New clutter 1.9.8 fixed this. G-S is back to good speed again...
+> 
+> Just a little minor bug(?): in GDM, when you click on the password text
+> field, you have no cursor until you begin to write, so you are not sure
+> if you are typing in the correct place... but I can live with that.
+
+Yup working here too :)
+
+Col
+
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011552.html b/zarb-ml/mageia-dev/2012-January/011552.html new file mode 100644 index 000000000..6e89a60bd --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011552.html @@ -0,0 +1,106 @@ + + + + [Mageia-dev] Build tip welcome + + + + + + + + + +

[Mageia-dev] Build tip welcome

+ Michael Scherer + misc at zarb.org +
+ Wed Jan 25 13:18:34 CET 2012 +

+
+ +
Le mardi 24 janvier 2012 à 21:35 +0100, Zézinho a écrit :
+> I am trying to update IceWM to 1.3.7 as Fedora did.
+> It does not build on Cauldron :
+> http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20120124202332.zezinho.valstar.28538
+> 
+> Even the current version 1.3.3 does not build in Cauldron. I welcome 
+> any hint about this :
+> 
+> In file included from /usr/include/glib-2.0/glib/gthread.h:34:0,
+>                  from /usr/include/glib-2.0/glib/gasyncqueue.h:34,
+>                  from /usr/include/glib-2.0/glib.h:34,
+>                  from /usr/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixbuf.h:31,
+>                  from /usr/include/gdk-pixbuf-2.0/gdk-pixbuf-xlib/gdk-pixbuf-
+> xlib.h:24,
+>                  from yimage.cc:17:
+> /usr/include/glib-2.0/glib/gatomic.h:65:1: error: ‘deprecated’ was not 
+> declared in this scope
+> /usr/include/glib-2.0/glib/gatomic.h:65:1: error: expected ‘)’ before ‘(’ 
+> token
+> /usr/include/glib-2.0/glib/gatomic.h:65:1: error: expected ‘)’ before ‘(’ 
+> token
+> /usr/include/glib-2.0/glib/gatomic.h:65:1: error: expected unqualified-id 
+> before string constant
+> /usr/include/glib-2.0/glib/gatomic.h:65:1: error: expected ‘)’ before 
+> string constant
+
+You should take a look at yimage.cc, around line 17 in icewm source
+code.
+Likely a macro that was incorrectly used.
+
+-- 
+Michael Scherer
+
+
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011553.html b/zarb-ml/mageia-dev/2012-January/011553.html new file mode 100644 index 000000000..c354a349f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011553.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] "Uploaded" status on the web page + + + + + + + + + +

[Mageia-dev] "Uploaded" status on the web page

+ Balcaen John + mikala at mageia.org +
+ Wed Jan 25 14:25:56 CET 2012 +

+
+ +
On Wednesday 25 January 2012 07:47:09 Balcaen John wrote :
+> On Wednesday 25 January 2012 08:54:49 Pascal Terjan wrote :
+> > On Wed, Jan 25, 2012 at 03:07, Balcaen John <mikala at mageia.org> wrote:
+> > > On Sunday 22 January 2012 15:51:28 Pascal Terjan wrote :
+> > >> I did some minor changes in the build system meaning that "uploaded"
+> > >> now really mean uploaded (the package is guaranteed to be in the
+> > >> hdlists), and you can safely submit anything depending on it.
+> > > 
+> > > Hum in fact it seems not « perfect » :/
+> > > I had tonight qtsingleapplication failing while it should not since the
+> > > correct qtlockedfile was « uploaded ».
+> > > Anyway  the delay is far shorter than it was before so that's enough,
+> > > i'll
+> > > add a little delay on my bash script ;o).
+> > 
+> > Really there should not be any delay at all
+> > The website will only display uploaded after youri-submit has finished
+> > running for all packages for this target, that includes running
+> > genhdlist2 and rsync to reference mirror
+[...]
+Ok i was able to reproduce here with kdenetwork4 where submit failed directly 
+since i have versionned buildrequires
+
+Submission errors, aborting:
+- kdenetwork4-4.8.0-1.mga2.src:
+ - Unresolved dep on kdebase4-devel >= 1:4.8.0
+
+kdebase4 4.8.0 is marked as uploaded  & kdenetwork4 was right after it on the 
+build order with my script.  
+
+
+
+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/2012-January/011554.html b/zarb-ml/mageia-dev/2012-January/011554.html new file mode 100644 index 000000000..23b6009ba --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011554.html @@ -0,0 +1,110 @@ + + + + [Mageia-dev] "Uploaded" status on the web page + + + + + + + + + +

[Mageia-dev] "Uploaded" status on the web page

+ Pascal Terjan + pterjan at gmail.com +
+ Wed Jan 25 15:45:33 CET 2012 +

+
+ +
On Wed, Jan 25, 2012 at 13:25, Balcaen John <mikala at mageia.org> wrote:
+> On Wednesday 25 January 2012 07:47:09 Balcaen John wrote :
+>> On Wednesday 25 January 2012 08:54:49 Pascal Terjan wrote :
+>> > On Wed, Jan 25, 2012 at 03:07, Balcaen John <mikala at mageia.org> wrote:
+>> > > On Sunday 22 January 2012 15:51:28 Pascal Terjan wrote :
+>> > >> I did some minor changes in the build system meaning that "uploaded"
+>> > >> now really mean uploaded (the package is guaranteed to be in the
+>> > >> hdlists), and you can safely submit anything depending on it.
+>> > >
+>> > > Hum in fact it seems not « perfect » :/
+>> > > I had tonight qtsingleapplication failing while it should not since the
+>> > > correct qtlockedfile was « uploaded ».
+>> > > Anyway  the delay is far shorter than it was before so that's enough,
+>> > > i'll
+>> > > add a little delay on my bash script ;o).
+>> >
+>> > Really there should not be any delay at all
+>> > The website will only display uploaded after youri-submit has finished
+>> > running for all packages for this target, that includes running
+>> > genhdlist2 and rsync to reference mirror
+> [...]
+> Ok i was able to reproduce here with kdenetwork4 where submit failed directly
+> since i have versionned buildrequires
+>
+> Submission errors, aborting:
+> - kdenetwork4-4.8.0-1.mga2.src:
+>  - Unresolved dep on kdebase4-devel >= 1:4.8.0
+>
+> kdebase4 4.8.0 is marked as uploaded  & kdenetwork4 was right after it on the
+> build order with my script.
+
+-rw-r--r-- 1 schedbot schedbot      0 2012-01-25 14:21:31.419836918
++0100 /var/lib/schedbot/uploads/done/cauldron/core/release/20120125110518.mikala.valstar.32692.upload
+-rw-r--r-- 1 schedbot schedbot 133390 2012-01-25 14:21:28.900197456
++0100 /var/lib/schedbot/uploads/done/cauldron/core/release/20120125110518.mikala.valstar.32692.youri
+
+The .upload (used to decided if we display it as uploaded) was created
+3s after the upload finished (the .youri)
+Looking at the .youri, it correctly updates the hdlists (to
+20120125-132029-synthesis.hdlist.cz) and runs the "mirror" post which
+rsync to the reference mirror, which is then directly used by the
+build system.
+
+I have no idea why it was not available.
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011555.html b/zarb-ml/mageia-dev/2012-January/011555.html new file mode 100644 index 000000000..57347053e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011555.html @@ -0,0 +1,84 @@ + + + + [Mageia-dev] "Uploaded" status on the web page + + + + + + + + + +

[Mageia-dev] "Uploaded" status on the web page

+ Balcaen John + mikala at mageia.org +
+ Wed Jan 25 16:15:51 CET 2012 +

+
+ +
On Wednesday 25 January 2012 14:45:33 Pascal Terjan wrote :
+[...]
+> 
+> The .upload (used to decided if we display it as uploaded) was created
+> 3s after the upload finished (the .youri)
+> Looking at the .youri, it correctly updates the hdlists (to
+> 20120125-132029-synthesis.hdlist.cz) and runs the "mirror" post which
+> rsync to the reference mirror, which is then directly used by the
+> build system.
+> 
+> I have no idea why it was not available.
+the rsync delay maybe ?
+
+
+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/2012-January/011556.html b/zarb-ml/mageia-dev/2012-January/011556.html new file mode 100644 index 000000000..a3ec7f2da --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011556.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] Official VM images for Mageia 2? + + + + + + + + + +

[Mageia-dev] Official VM images for Mageia 2?

+ Romain d'Alverny + rdalverny at gmail.com +
+ Wed Jan 25 16:30:23 CET 2012 +

+
+ +
Hi there,
+
+I'd like to discuss/plan how we can build and distribute ready to use
+VM images of Mageia 2 along with original ISOs, from our download
+pages.
+
+Target VMs: Xen, VMWare, Virtualbox, Vagrant (with a minimal install +
+specific config), other, you name it, as long as it can be managed
+(best would be to have these build automatically from source ISOs +
+ad-hoc auto_install.cfg + post install conf).
+
+Uses can be: evaluation, development/staging environments, you name it too.
+
+hurdman has some experience and is a first volunteer to work on this;
+others? (input, recipes, hands).
+
+ + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011557.html b/zarb-ml/mageia-dev/2012-January/011557.html new file mode 100644 index 000000000..0ad222eee --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011557.html @@ -0,0 +1,81 @@ + + + + [Mageia-dev] "Uploaded" status on the web page + + + + + + + + + +

[Mageia-dev] "Uploaded" status on the web page

+ Pascal Terjan + pterjan at gmail.com +
+ Wed Jan 25 16:37:40 CET 2012 +

+
+ +
On Wed, Jan 25, 2012 at 15:15, Balcaen John <mikala at mageia.org> wrote:
+> On Wednesday 25 January 2012 14:45:33 Pascal Terjan wrote :
+> [...]
+>>
+>> The .upload (used to decided if we display it as uploaded) was created
+>> 3s after the upload finished (the .youri)
+>> Looking at the .youri, it correctly updates the hdlists (to
+>> 20120125-132029-synthesis.hdlist.cz) and runs the "mirror" post which
+>> rsync to the reference mirror, which is then directly used by the
+>> build system.
+>>
+>> I have no idea why it was not available.
+> the rsync delay maybe ?
+
+No, as I said the rsync is finished when this file is written
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011558.html b/zarb-ml/mageia-dev/2012-January/011558.html new file mode 100644 index 000000000..a7766427f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011558.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] "Uploaded" status on the web page + + + + + + + + + +

[Mageia-dev] "Uploaded" status on the web page

+ Balcaen John + mikala at mageia.org +
+ Wed Jan 25 16:52:46 CET 2012 +

+
+ +
On Wednesday 25 January 2012 15:37:40 Pascal Terjan wrote :
+> On Wed, Jan 25, 2012 at 15:15, Balcaen John <mikala at mageia.org> wrote:
+> > On Wednesday 25 January 2012 14:45:33 Pascal Terjan wrote :
+> > [...]
+> > 
+> >> The .upload (used to decided if we display it as uploaded) was created
+> >> 3s after the upload finished (the .youri)
+> >> Looking at the .youri, it correctly updates the hdlists (to
+> >> 20120125-132029-synthesis.hdlist.cz) and runs the "mirror" post which
+> >> rsync to the reference mirror, which is then directly used by the
+> >> build system.
+> >> 
+> >> I have no idea why it was not available.
+> > 
+> > the rsync delay maybe ?
+> 
+> No, as I said the rsync is finished when this file is written
+Sorry i misread :/
+
+
+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/2012-January/011559.html b/zarb-ml/mageia-dev/2012-January/011559.html new file mode 100644 index 000000000..842a5de21 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011559.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] "Uploaded" status on the web page + + + + + + + + + +

[Mageia-dev] "Uploaded" status on the web page

+ Pascal Terjan + pterjan at gmail.com +
+ Wed Jan 25 17:14:22 CET 2012 +

+
+ +
On Wed, Jan 25, 2012 at 10:47, Balcaen John <mikala at mageia.org> wrote:
+> On Wednesday 25 January 2012 08:54:49 Pascal Terjan wrote :
+>> On Wed, Jan 25, 2012 at 03:07, Balcaen John <mikala at mageia.org> wrote:
+>> > On Sunday 22 January 2012 15:51:28 Pascal Terjan wrote :
+>> >> I did some minor changes in the build system meaning that "uploaded"
+>> >> now really mean uploaded (the package is guaranteed to be in the
+>> >> hdlists), and you can safely submit anything depending on it.
+>> >
+>> > Hum in fact it seems not « perfect » :/
+>> > I had tonight qtsingleapplication failing while it should not since the
+>> > correct qtlockedfile was « uploaded ».
+>> > Anyway  the delay is far shorter than it was before so that's enough, i'll
+>> > add a little delay on my bash script ;o).
+>>
+>> Really there should not be any delay at all
+>> The website will only display uploaded after youri-submit has finished
+>> running for all packages for this target, that includes running
+>> genhdlist2 and rsync to reference mirror
+> I don't know here :/
+> the only reason for not building  (
+> http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20120125021624.mikala.valstar.14674/
+> ) of qtsingleapplication, was to use a non rebuild qtlockedfile (so the
+> qtlockedfile.h was not in the correct place when qtsingleapplication need it).
+> A simple wait & pushing it few minutes after fix it.
+>
+> For memory i'm using this https://gitorious.org/~jbalcaen/mgaqueue/jbalcaen-
+> mgaqueue to push package only when the previous is uploaded (with the support
+> of the build throttle so maybe more people can you use it)
+
+Hmm this one looks wrong.
+The build of qtsingleapplication was requested at 02:16 while
+qtsingleapplication was marked as uploaded at 02:19
+
+Aaaaaah I see :)
+You are using the index2.php that I had created as a test and have not
+yet integrated to the main page. It did not get updated to display
+correct information...
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011560.html b/zarb-ml/mageia-dev/2012-January/011560.html new file mode 100644 index 000000000..9c623cd0e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011560.html @@ -0,0 +1,81 @@ + + + + [Mageia-dev] "Uploaded" status on the web page + + + + + + + + + +

[Mageia-dev] "Uploaded" status on the web page

+ Balcaen John + mikala at mageia.org +
+ Wed Jan 25 17:18:10 CET 2012 +

+
+ +
On Wednesday 25 January 2012 16:14:22 Pascal Terjan wrote :
+[...]
+> Aaaaaah I see :)
+> You are using the index2.php that I had created as a test and have not
+> yet integrated to the main page. It did not get updated to display
+> correct information...
+
+Oh, thanks :)
+I'll fix it asap (& i need to merge my changes in master too btw :p)
+
+
+
+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/2012-January/011561.html b/zarb-ml/mageia-dev/2012-January/011561.html new file mode 100644 index 000000000..758020266 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011561.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] Packagers meeting + + + + + + + + + +

[Mageia-dev] Packagers meeting

+ Anne nicolas + ennael at mageia.org +
+ Wed Jan 25 18:12:35 CET 2012 +

+
+ +
Hi there
+
+Could we have our weekly meeting tomorrow, same time, same place? Misc
+is not available at the moment and I will be in another meeting and
+late for sure.
+
+For tomorrow's meeting:
+
+- FOSDEM reminder
+- isos content: define DVD iso content
+- Define focus until end of Mageia 2 development cycle
+
+Cheers
+
+-- 
+Anne
+http://www.mageia.org
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011562.html b/zarb-ml/mageia-dev/2012-January/011562.html new file mode 100644 index 000000000..59712f59c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011562.html @@ -0,0 +1,74 @@ + + + + [Mageia-dev] Official VM images for Mageia 2? + + + + + + + + + +

[Mageia-dev] Official VM images for Mageia 2?

+ zezinho + lists.jjorge at free.fr +
+ Wed Jan 25 18:35:20 CET 2012 +

+
+ +
Le mercredi 25 janvier 2012 16:30:23, Romain d'Alverny a écrit :
+> I'd like to discuss/plan how we can build and distribute ready to use
+> VM images of Mageia 2 along with original ISOs, from our download
+> pages.
+
+I use LiveCD for this kinds of tests. It takes only a few seconds to install 
+it in a VM. Is it really usefull to work on another media?
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011563.html b/zarb-ml/mageia-dev/2012-January/011563.html new file mode 100644 index 000000000..6f262886d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011563.html @@ -0,0 +1,112 @@ + + + + [Mageia-dev] size of iso dvds (unbloated installer stage 1) + + + + + + + + + +

[Mageia-dev] size of iso dvds (unbloated installer stage 1)

+ Juergen Harms + Juergen.Harms at unige.ch +
+ Wed Jan 25 21:21:40 CET 2012 +

+
+ +
I just joined this list - therefore top-posting rather than replying.
+
+Seeing the discussion on space on isos, I checked how much space 
+documentation files occupy on the alpha 3 iso: looks like there is quite 
+some potential for space saving. Some examples of bigger doc files
+
+gawk-doc         0.9 Mb
+lilo-doc         0.8 Mb
+javadoc-1.6.0    11  Mb
+javadoc-1.7.0    12  Mb
+python-docs       4  Mb
+qt4-doc         126  Mb
+and so on
+
+Some space can easily be gained by removing doc packages of low interest 
+(e.g. lilo, only one java version), much more could be gained by sorting 
+the doc according to some criteria (my suggestion: highest priority = 
+doc for non-advanced users who want to get a running out-of-the-box 
+system with basic doc; second priority = doc for advanced users/users 
+who do development and might have bandwidth problems; low priority: 
+things like kernel-doc which are normally used by people who anyhow have 
+made an effort to have bandwidth in support of fetching the code they 
+are working on, and who can easily fetch the doc packages from the core 
+repositories).
+
+A more radical approach might be to simply create an additional "doc 
+dvd" - move all doc packages from the present iso there, with the 
+benefit to have lots of place for offering some of the more popuplar doc 
+packages on a dvd - which presently must be fetched from the repository 
+(probably attractive for users with bandwidth problems). That would 
+immediately free about 180 Mb of the alpha iso (and avoid - well, 
+postpone - the headache which programme packages can be kept on the iso, 
+and which not).
+
+Juergen
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011564.html b/zarb-ml/mageia-dev/2012-January/011564.html new file mode 100644 index 000000000..8b2061278 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011564.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] Fosdem 2012 - Mageia stand + + + + + + + + + +

[Mageia-dev] Fosdem 2012 - Mageia stand

+ Sebastian sebsebseb + sebsebseb_mageia at gmx.com +
+ Thu Jan 26 02:20:26 CET 2012 +

+
+ +
On 25/01/12 08:26, Remco Rijnders wrote:
+> On Wed, Jan 25, 2012 at 09:21:41AM +0100, Oliver wrote in 
+> <1327479701.21166.4.camel at beteigeuze.oli-home>:
+>> Am Sonntag, den 15.01.2012, 11:38 +0100 schrieb Oliver Burger:
+>>> Calling again...
+>>>
+>>> Until now we have 19 people coming to FOSDEM but only 5 who have
+>>> volunteered to help for some time at the stand.
+>>>
+>>> So, if you are coming to FOSDEM, please consider helping us there, so
+>>> it won't be a few people having to stay there the whole day.
+>>
+>> It's always great to have so many people reacting...
+>>
+>> We are about 20 people at Fosdem and only five of them do volunteer to
+>> help at the stand, meaning those five will have actually not time left
+>> to attend any sessions?
+>> I don't really believe this.
+>>
+>> Or am I just too German in my organisation and the way to go is to just
+>> wait who will honour us with his presence? And I can throw the whole
+>> organisation out of the window?
+>
+> Speaking only for myself here... I had the distinct impression when I 
+> looked at the FOSDEM site a few weeks back that the list of talks was 
+> not complete yet. I was kind of waiting on that to see what talks I 
+> really wanted to attend, and then see what times that'd leave me to 
+> help at the stand.
+>
+> Remco
+It's a bit like this for me as well. I would like to help on the 
+Saturday and Sunday at the Mageia stand however I do not know when 
+exactly, because I haven't been to FOSDEM before. In fact I haven't been 
+to any Linux/opensource/freesoftware event before.
+
+ From Sebastian sebsebseb
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011565.html b/zarb-ml/mageia-dev/2012-January/011565.html new file mode 100644 index 000000000..cf44ca301 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011565.html @@ -0,0 +1,82 @@ + + + + [Mageia-dev] Build system currently broken + + + + + + + + + +

[Mageia-dev] Build system currently broken

+ Pascal Terjan + pterjan at gmail.com +
+ Thu Jan 26 10:03:09 CET 2012 +

+
+ +
Hi everyone,
+I don't have time to restore previous systemd package currently, but
+the new one broke the build system:
+
+Installation failed:
+	lockdev is needed by systemd-39-2.mga2.x86_64
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011566.html b/zarb-ml/mageia-dev/2012-January/011566.html new file mode 100644 index 000000000..65b13c652 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011566.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] Official VM images for Mageia 2? + + + + + + + + + +

[Mageia-dev] Official VM images for Mageia 2?

+ Romain d'Alverny + rdalverny at gmail.com +
+ Thu Jan 26 10:17:46 CET 2012 +

+
+ +
On Wed, Jan 25, 2012 at 18:35, zezinho <lists.jjorge at free.fr> wrote:
+> Le mercredi 25 janvier 2012 16:30:23, Romain d'Alverny a écrit :
+>> I'd like to discuss/plan how we can build and distribute ready to use
+>> VM images of Mageia 2 along with original ISOs, from our download
+>> pages.
+>
+> I use LiveCD for this kinds of tests.
+> It takes only a few seconds to install it in a VM.
+
+This is an option, but LiveCDs do not provide a minimal system, and
+their intended use is more for a graphical user desktop.
+
+VMs can be used for scriptable config and deployment of
+test/staging/prod platforms, using shared recipes (chef, puppet,
+other). Providing a pre-installed, predictable minimal system is
+helpful in this case. I'm especially thinking about Vagrant boxes, but
+other images can be used for the same goals.
+
+It's not about changing/diminishing the current dev/packaging focus
+for Mageia 2 of course (not the same priority), it's to complement the
+build chain with an alternative way to use the platform in the end.
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011567.html b/zarb-ml/mageia-dev/2012-January/011567.html new file mode 100644 index 000000000..4aeb41e49 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011567.html @@ -0,0 +1,120 @@ + + + + [Mageia-dev] Official VM images for Mageia 2? + + + + + + + + + +

[Mageia-dev] Official VM images for Mageia 2?

+ Buchan Milne + bgmilne at staff.telkomsa.net +
+ Thu Jan 26 11:16:43 CET 2012 +

+
+ +
On Wednesday, 25 January 2012 17:30:23 Romain d'Alverny wrote:
+> Hi there,
+> 
+> I'd like to discuss/plan how we can build and distribute ready to use
+> VM images of Mageia 2 along with original ISOs, from our download
+> pages.
+
+Generic VM images, or ones targetted at specific uses? If specific uses, it 
+might be worthwhile considering live ISOs targetted at the use case with 
+installation support.
+
+In my case, I would consider looking at a minimal XBMC-based (possibly with 
+samba and a few other tools as well) live ISO/USB.
+
+> Target VMs: Xen, VMWare, Virtualbox, Vagrant (with a minimal install +
+> specific config), other, you name it, as long as it can be managed
+> (best would be to have these build automatically from source ISOs +
+> ad-hoc auto_install.cfg + post install conf).
+
+Most of these tools support OVF, so do we have tools that can generate OVF 
+easily?
+
+BTW., I have access to a VMWare vSphere environment with capaticy to run a few 
+extra VMs (for testing images). For images for VMWare, it may also be 
+worthwhile including some of the VMWare tools (there are open-source versions, 
+and I believe Ubuntu ships these):
+
+http://sourceforge.net/projects/open-vm-tools/
+
+(We have X11 driver and mouse input driver, but these should provide drag 'n' 
+drop, window resize, memory ballooning, guest shutdown etc.).
+
+What about publishing official images to Amazon EC2?
+
+> Uses can be: evaluation, development/staging environments, you name it too.
+> 
+> hurdman has some experience and is a first volunteer to work on this;
+> others? (input, recipes, hands).
+
+I don't know if there is that much value in providing specific VM images, when 
+instead we may want to look at providing good tools for sharing VM configs and 
+tools for easily generating images from those configs.
+
+Some interesting tools which we don't seem to have yet:
+http://libguestfs.org/
+http://libguestfs.org/virt-v2v/
+
+http://libguestfs.org/virt-copy-in.1.html
+http://libguestfs.org/virt-tar-in.1.html
+http://libguestfs.org/febootstrap.8.html
+
+Regards,
+Buchan
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011568.html b/zarb-ml/mageia-dev/2012-January/011568.html new file mode 100644 index 000000000..877f4e495 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011568.html @@ -0,0 +1,84 @@ + + + + [Mageia-dev] Build system currently broken + + + + + + + + + +

[Mageia-dev] Build system currently broken

+ Buchan Milne + bgmilne at staff.telkomsa.net +
+ Thu Jan 26 11:19:36 CET 2012 +

+
+ +
On Thursday, 26 January 2012 11:03:09 Pascal Terjan wrote:
+> Hi everyone,
+> I don't have time to restore previous systemd package currently, but
+> the new one broke the build system:
+> 
+> Installation failed:
+> 	lockdev is needed by systemd-39-2.mga2.x86_64
+
+Do we need more validation on packages that are dependencies of the build 
+system?
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011569.html b/zarb-ml/mageia-dev/2012-January/011569.html new file mode 100644 index 000000000..a2f86cd1d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011569.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] Build system currently broken + + + + + + + + + +

[Mageia-dev] Build system currently broken

+ Pascal Terjan + pterjan at gmail.com +
+ Thu Jan 26 11:24:40 CET 2012 +

+
+ +
On Thu, Jan 26, 2012 at 10:19, Buchan Milne <bgmilne at staff.telkomsa.net> wrote:
+> On Thursday, 26 January 2012 11:03:09 Pascal Terjan wrote:
+>> Hi everyone,
+>> I don't have time to restore previous systemd package currently, but
+>> the new one broke the build system:
+>>
+>> Installation failed:
+>>       lockdev is needed by systemd-39-2.mga2.x86_64
+>
+> Do we need more validation on packages that are dependencies of the build
+> system?
+
+There is an open bug for an easy improvement : Do not delete old
+chroot tarball if we fail to generate a new one
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011570.html b/zarb-ml/mageia-dev/2012-January/011570.html new file mode 100644 index 000000000..b2abef61d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011570.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] Build system currently broken + + + + + + + + + +

[Mageia-dev] Build system currently broken

+ Pascal Terjan + pterjan at gmail.com +
+ Thu Jan 26 11:28:07 CET 2012 +

+
+ +
On Thu, Jan 26, 2012 at 10:24, Pascal Terjan <pterjan at gmail.com> wrote:
+> On Thu, Jan 26, 2012 at 10:19, Buchan Milne <bgmilne at staff.telkomsa.net> wrote:
+>> On Thursday, 26 January 2012 11:03:09 Pascal Terjan wrote:
+>>> Hi everyone,
+>>> I don't have time to restore previous systemd package currently, but
+>>> the new one broke the build system:
+>>>
+>>> Installation failed:
+>>>       lockdev is needed by systemd-39-2.mga2.x86_64
+>>
+>> Do we need more validation on packages that are dependencies of the build
+>> system?
+>
+> There is an open bug for an easy improvement : Do not delete old
+> chroot tarball if we fail to generate a new one
+
+https://bugs.mageia.org/show_bug.cgi?id=909
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011571.html b/zarb-ml/mageia-dev/2012-January/011571.html new file mode 100644 index 000000000..dc85bc575 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011571.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] Official VM images for Mageia 2? + + + + + + + + + +

[Mageia-dev] Official VM images for Mageia 2?

+ Michael Scherer + misc at zarb.org +
+ Thu Jan 26 12:09:42 CET 2012 +

+
+ +
Le jeudi 26 janvier 2012 à 12:16 +0200, Buchan Milne a écrit :
+> On Wednesday, 25 January 2012 17:30:23 Romain d'Alverny wrote:
+
+> > Uses can be: evaluation, development/staging environments, you name it too.
+> > 
+> > hurdman has some experience and is a first volunteer to work on this;
+> > others? (input, recipes, hands).
+> 
+> I don't know if there is that much value in providing specific VM images, when 
+> instead we may want to look at providing good tools for sharing VM configs and 
+> tools for easily generating images from those configs.
+> 
+> Some interesting tools which we don't seem to have yet:
+> http://libguestfs.org/
+> http://libguestfs.org/virt-v2v/
+
+You can add oz, boxgrinder.
+
+And there is the script based on virt-install that i sent a few months
+ago ( still no release of virt-install, so no mageia integration, maybe
+I should start to poke maintainer for a release ).
+
+It should be fairly easy to generate vm as well as iso.
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011572.html b/zarb-ml/mageia-dev/2012-January/011572.html new file mode 100644 index 000000000..c3ee2d5e2 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011572.html @@ -0,0 +1,122 @@ + + + + [Mageia-dev] Official VM images for Mageia 2? + + + + + + + + + +

[Mageia-dev] Official VM images for Mageia 2?

+ Romain d'Alverny + rdalverny at gmail.com +
+ Thu Jan 26 12:37:38 CET 2012 +

+
+ +
On Thu, Jan 26, 2012 at 11:16, Buchan Milne <bgmilne at staff.telkomsa.net> wrote:
+> On Wednesday, 25 January 2012 17:30:23 Romain d'Alverny wrote:
+> Generic VM images, or ones targetted at specific uses? If specific uses, it
+> might be worthwhile considering live ISOs targetted at the use case with
+> installation support.
+>
+> In my case, I would consider looking at a minimal XBMC-based (possibly with
+> samba and a few other tools as well) live ISO/USB.
+
+I would consider at least those 3:
+ - a generic minimal system install ISO (quick to download and base
+from which we can generate more elaborate images)
+ - equivalent generic minimal system VM
+ - derivatives:
+   - a Vagrant image (same as above + a specific user/packages setup)
+   - your XBMC-based one
+
+I started playing with a boot.iso + auto_inst.cfg (this is really
+great, we ought to document it better somewhere about it) + Vagrant a
+few weeks ago, but didn't make it yet. Will clean this up and post it
+somewhere.
+
+>> Target VMs: Xen, VMWare, Virtualbox, Vagrant (with a minimal install +
+>> specific config), other, you name it, as long as it can be managed
+>> (best would be to have these build automatically from source ISOs +
+>> ad-hoc auto_install.cfg + post install conf).
+>
+> Most of these tools support OVF, so do we have tools that can generate OVF
+> easily?
+
+No idea.
+
+> What about publishing official images to Amazon EC2?
+
+Yes!
+
+> I don't know if there is that much value in providing specific VM images, when
+> instead we may want to look at providing good tools for sharing VM configs and
+> tools for easily generating images from those configs.
+
+I'd say both. Sharing configs and tools is great, having a few small
+images available is great too for those that prefer to focus on using
+it at once (and for cloud hosts too).
+
+If we were to automate the process, could we chain somehow this:
+ - bcd with a minimal system image
+ - isocheck
+ - vmbuild? foreach each vm config provided (we can store all this in
+svn), does:
+   - push specific auto_inst script into the install ISO
+   - run the ISO into the virtual environment
+   - package the VM
+   - checks
+   - deliver to download
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011573.html b/zarb-ml/mageia-dev/2012-January/011573.html new file mode 100644 index 000000000..a5f3754c3 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011573.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] Official VM images for Mageia 2? + + + + + + + + + +

[Mageia-dev] Official VM images for Mageia 2?

+ Christian Lohmaier + lohmaier+mageia at googlemail.com +
+ Thu Jan 26 13:50:59 CET 2012 +

+
+ +
Hi *,
+
+On Thu, Jan 26, 2012 at 10:17 AM, Romain d'Alverny <rdalverny at gmail.com> wrote:
+> On Wed, Jan 25, 2012 at 18:35, zezinho <lists.jjorge at free.fr> wrote:
+>> Le mercredi 25 janvier 2012 16:30:23, Romain d'Alverny a écrit :
+>
+> VMs can be used for scriptable config and deployment of
+> test/staging/prod platforms, using shared recipes (chef, puppet,
+> other). Providing a pre-installed, predictable minimal system is
+> helpful in this case.
+
+Why not provide a kickstart image then? Or is kickstart
+auto-installation no longer supported by Mageia? I used it a while
+back with mandriva, and while a little hard to discover that feature,
+it worked quite well.
+This is then much easier to distribute (regular install-media +
+kickstart configuration) and can be installed unattended in any VM of
+the user's choice...
+
+ciao
+Christian
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011574.html b/zarb-ml/mageia-dev/2012-January/011574.html new file mode 100644 index 000000000..ce7b21ed3 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011574.html @@ -0,0 +1,84 @@ + + + + [Mageia-dev] Official VM images for Mageia 2? + + + + + + + + + +

[Mageia-dev] Official VM images for Mageia 2?

+ Kamil Rytarowski + n54 at gmx.com +
+ Thu Jan 26 14:02:18 CET 2012 +

+
+ +
W dniu 25.01.2012 16:30, Romain d'Alverny pisze:
+> Hi there,
+>
+> I'd like to discuss/plan how we can build and distribute ready to use
+> VM images of Mageia 2 along with original ISOs, from our download
+> pages.
+>
+> Target VMs: (...), Virtualbox, (...)
+Please take a note here 
+https://forums.virtualbox.org/viewtopic.php?f=10&t=46798
+
+Quote:
+Unattended Guest OS Install - vbox-unattended
+(a.k.a. coffee break system installation)
+Good news !
+I have finally achieved first milestone - first working version !
+This project lets you to install any supported guest OS in 10 minutes !
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011575.html b/zarb-ml/mageia-dev/2012-January/011575.html new file mode 100644 index 000000000..16b2e891b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011575.html @@ -0,0 +1,136 @@ + + + + [Mageia-dev] Official VM images for Mageia 2? + + + + + + + + + +

[Mageia-dev] Official VM images for Mageia 2?

+ Buchan Milne + bgmilne at staff.telkomsa.net +
+ Thu Jan 26 15:28:47 CET 2012 +

+
+ +
On Thursday, 26 January 2012 13:37:38 Romain d'Alverny wrote:
+> On Thu, Jan 26, 2012 at 11:16, Buchan Milne <bgmilne at staff.telkomsa.net> 
+wrote:
+> > On Wednesday, 25 January 2012 17:30:23 Romain d'Alverny wrote:
+> > Generic VM images, or ones targetted at specific uses? If specific uses,
+> > it might be worthwhile considering live ISOs targetted at the use case
+> > with installation support.
+> > 
+> > In my case, I would consider looking at a minimal XBMC-based (possibly
+> > with samba and a few other tools as well) live ISO/USB.
+> 
+> I would consider at least those 3:
+>  - a generic minimal system install ISO (quick to download and base
+> from which we can generate more elaborate images)
+>  - equivalent generic minimal system VM
+>  - derivatives:
+>    - a Vagrant image (same as above + a specific user/packages setup)
+>    - your XBMC-based one
+> 
+> I started playing with a boot.iso + auto_inst.cfg (this is really
+> great, we ought to document it better somewhere about it) + Vagrant a
+> few weeks ago, but didn't make it yet. Will clean this up and post it
+> somewhere.
+> 
+> >> Target VMs: Xen, VMWare, Virtualbox, Vagrant (with a minimal install +
+> >> specific config), other, you name it, as long as it can be managed
+> >> (best would be to have these build automatically from source ISOs +
+> >> ad-hoc auto_install.cfg + post install conf).
+> > 
+> > Most of these tools support OVF, so do we have tools that can generate
+> > OVF easily?
+> 
+> No idea.
+> 
+> > What about publishing official images to Amazon EC2?
+> 
+> Yes!
+> 
+> > I don't know if there is that much value in providing specific VM images,
+> > when instead we may want to look at providing good tools for sharing VM
+> > configs and tools for easily generating images from those configs.
+> 
+> I'd say both. Sharing configs and tools is great, having a few small
+> images available is great too for those that prefer to focus on using
+> it at once (and for cloud hosts too).
+> 
+> If we were to automate the process, could we chain somehow this:
+>  - bcd with a minimal system image
+
+Why? Do you want to provide an installable (ie, drakx) ISO, that requires the 
+user to click through the installation? If not, skip this.
+
+>  - isocheck
+>  - vmbuild? foreach each vm config provided (we can store all this in
+> svn), does:
+>    - push specific auto_inst script into the install ISO
+
+Rather:
+1)Install
+-use virt-install to boot a VM with auto_install pointing to official repo
+or
+-modify draklive to install into raw volumes (which also uses auto_install)
+2)Convert raw volumes to OVF
+
+>    - run the ISO into the virtual environment
+>    - package the VM
+>    - checks
+>    - deliver to download
+
+Regards,
+Buchan
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011576.html b/zarb-ml/mageia-dev/2012-January/011576.html new file mode 100644 index 000000000..63b3265ea --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011576.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] Official VM images for Mageia 2? + + + + + + + + + +

[Mageia-dev] Official VM images for Mageia 2?

+ Buchan Milne + bgmilne at staff.telkomsa.net +
+ Thu Jan 26 16:43:28 CET 2012 +

+
+ +
On Thursday, 26 January 2012 15:02:18 Kamil Rytarowski wrote:
+> W dniu 25.01.2012 16:30, Romain d'Alverny pisze:
+> > Hi there,
+> > 
+> > I'd like to discuss/plan how we can build and distribute ready to use
+> > VM images of Mageia 2 along with original ISOs, from our download
+> > pages.
+> > 
+> > Target VMs: (...), Virtualbox, (...)
+> 
+> Please take a note here
+> https://forums.virtualbox.org/viewtopic.php?f=10&t=46798
+> 
+> Quote:
+> Unattended Guest OS Install - vbox-unattended
+> (a.k.a. coffee break system installation)
+> Good news !
+> I have finally achieved first milestone - first working version !
+> This project lets you to install any supported guest OS in 10 minutes !
+
+While it might be a nice UI, all the aspects it has in scope for us are 
+achievable with virt-install (or virt-manager's 'New' button).
+
+Regards,
+Buchan
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011577.html b/zarb-ml/mageia-dev/2012-January/011577.html new file mode 100644 index 000000000..72cdb0aeb --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011577.html @@ -0,0 +1,79 @@ + + + + [Mageia-dev] Official VM images for Mageia 2? + + + + + + + + + +

[Mageia-dev] Official VM images for Mageia 2?

+ Luis Daniel Lucio Quiroz + dlucio at okay.com.mx +
+ Wed Jan 25 18:53:06 CET 2012 +

+
+ +
Le mercredi 25 janvier 2012 18:35:20 zezinho a écrit :
+> Le mercredi 25 janvier 2012 16:30:23, Romain d'Alverny a écrit :
+> > I'd like to discuss/plan how we can build and distribute ready to use
+> > VM images of Mageia 2 along with original ISOs, from our download
+> > pages.
+> 
+> I use LiveCD for this kinds of tests. It takes only a few seconds to install
+> it in a VM. Is it really usefull to work on another media?
+> Email Shield provided by NOCWorldWide.com
+
+I've sucessfuly place openvz templates for mandriva 2010.2 and 2011. when 
+ready i will publish template for Mga2. Sorry Mga1 not good enought for server 
+use, it misses to  many packages.
+
+LD
+
+ + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011578.html b/zarb-ml/mageia-dev/2012-January/011578.html new file mode 100644 index 000000000..e185e2c37 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011578.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] size of iso dvds + + + + + + + + + +

[Mageia-dev] size of iso dvds

+ Luc Menut + lmenut at free.fr +
+ Thu Jan 26 20:56:35 CET 2012 +

+
+ +
Le 25/01/2012 21:21, Juergen Harms a écrit :
+> I just joined this list - therefore top-posting rather than replying.
+>
+> Seeing the discussion on space on isos,
+
+some data about differences between mageia 1 x86_64 DVD and mageia 2a3 
+x86_64 DVD:
+mageia 1 : 3730 Mo - 4630 packages
+mageia 2 : 4139 Mo - 4209 packages
+
+some new "big" packages in mga 2:
+- *eclipse* ->        + 67 packages -> +302 Mo
+   + lots of new java packages (ant, maven, ...)
+- celtx* ->           +  7 packages -> +132 Mo
+- e, e17_themes ->    +  2 packages ->  +36 Mo
+- chromium-browser -> +  2 packages ->  +23 Mo
+
+some packages bigger than in mga 1:
+- texlive* -> + 95Mo (mga1 306Mo, mga2 401Mo)
+
+packages that we will be able to remove in mga2:
+- myspell* 39Mo (after hunspell migration)
+
+
+some major missing packages in mga2 DVD ISO:
+- lots of kde packages,
+- gstreamer0.10-pulse,
+- kernel-desktop-devel-latest,
+- kernel-server-devel-latest,
+- perhaps others :'(
+
+regards,
+Luc
+
+-- 
+Luc Menut
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011579.html b/zarb-ml/mageia-dev/2012-January/011579.html new file mode 100644 index 000000000..ed96e40ca --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011579.html @@ -0,0 +1,82 @@ + + + + [Mageia-dev] Fwd: GNOME 3.4 will rely on hostnamed, localed, timedated D-Bus API + + + + + + + + + +

[Mageia-dev] Fwd: GNOME 3.4 will rely on hostnamed, localed, timedated D-Bus API

+ Olav Vitters + olav at vitters.nl +
+ Fri Jan 27 01:00:37 CET 2012 +

+
+ +
Should either split these daemons out from systemd, or always have
+systemd installed. In any case, I'm going to add requires on this in
+gnome-control-center.
+
+Daemons will work under sysvinit. Just need to be installed.
+-- 
+Regards,
+Olav
+-------------- next part --------------
+An embedded message was scrubbed...
+From: Olav Vitters <olav at vitters.nl>
+Subject: GNOME 3.4 will rely on hostnamed, localed, timedated D-Bus API
+Date: Fri, 27 Jan 2012 00:56:24 +0100
+Size: 2158
+URL: </pipermail/mageia-dev/attachments/20120127/027d9fd7/attachment-0001.mht>
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011580.html b/zarb-ml/mageia-dev/2012-January/011580.html new file mode 100644 index 000000000..7abd02bfb --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011580.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] mkinitrd and Mageia2 + + + + + + + + + +

[Mageia-dev] mkinitrd and Mageia2

+ Charles A Edwards + CAE at eslrahc.com +
+ Fri Jan 27 02:06:39 CET 2012 +

+
+ +
It was my understanding that mkinitrd would continue to be supported in
+Mageia2 and then be phased out during the Mageia3 development.
+
+If this is the case, why is it that all 'current' kernels now
+require dracut?
+
+
+    Charles
+
+-- 
+Your motives for doing whatever good deed you may have in mind will be
+misinterpreted by somebody.
+----------------------
+Mageia release 2 (Cauldron) for x86_64$
+On SuperSize....http://www.eslrahc.com
+Registered Linux user #182463
+3.2.1-tmb-server-1.mga2 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/20120126/d81e501f/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011581.html b/zarb-ml/mageia-dev/2012-January/011581.html new file mode 100644 index 000000000..8c79a649c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011581.html @@ -0,0 +1,135 @@ + + + + [Mageia-dev] mentors + apprentices + + + + + + + + + +

[Mageia-dev] mentors + apprentices

+ andre999 + andre999mga at laposte.net +
+ Fri Jan 27 07:08:48 CET 2012 +

+
+ +
Hi everyone,
+
+Currently we have 4 apprentice candidates looking for a mentor.
+
+am2605 (Andrew Myers), has been waiting now about 2 months.
+He is a longtime Fedora, a web developer, interested in packaging related to 
+Gnome, Java, Eclipse among others, teaching himself Mageia packaging basics.
+dmorgan has offered to mentor him when his next apprentice graduates.
+
+cddesjar (Christopher Desjardins), has been waiting about 6 weeks.
+He has basic .deb and .rpm packaging experience, including doing texworks and 
+jags on Mageia for himself.  Would like to maintain these and R-base.
+
+tuxta (Steve Tucker)
+He is an associate lecturer in C/C++ and Java, and an IT school sys admin, who 
+wants to start giving back to the FOSS community that has given him so much.
+
+edge226 (Edward)
+He has learned html, C, C++, Java, and Assembly in a business-oriented computer 
+program in college a few years back, and has recently been learning Python.  A 
+user of Linux for over 10 years, he would like to give something back.
+
+Note that those who have been waiting the longest are at the top of the list.
+
+You can find more details at:
+https://wiki.mageia.org/en/Becoming_a_Mageia_Packager#Packager_apprentice_candidates
+
+Mentors, let me know who you take on, and I'll update the tables for you.
+And if you feel that you can take on another apprentice, don't hesitate to post 
+to this thread.
+
+Thanks :-)
+
+----
+
+Anyone else looking for a mentor, let me know so I can add your name as an 
+apprentice candidate -- or you can do it yourself.
+https://wiki.mageia.org/en/Becoming_a_Mageia_Packager#Packager_apprentice_candidates 
+
+
+See also the previous sections, on becoming a Mageia packager :
+https://wiki.mageia.org/mw-en/index.php?title=Becoming_a_Mageia_Packager&action=submit#What_is_needed_to_become_a_Mageia_packager
+
+To find a mentor, it helps to also post to this list (mageia-dev), or hang out 
+on IRC at freenode #mageia-mentoring.
+Don't forget that if you contact a mentor directly, they know that you are 
+actively interested.
+
+Regards :-)
+
+-- 
+André
+(Packager mentoring program coordinator)
+
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011582.html b/zarb-ml/mageia-dev/2012-January/011582.html new file mode 100644 index 000000000..fdf5a1072 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011582.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] Fwd: Impact of ConsoleKit deprecation + + + + + + + + + +

[Mageia-dev] Fwd: Impact of ConsoleKit deprecation

+ Olav Vitters + olav at vitters.nl +
+ Fri Jan 27 09:36:30 CET 2012 +

+
+ +
 [ resending with correct From ]
+
+Just a FYI. Simple summary: We need to switch to systemd in Mageia 3.
+
+-- 
+Regards,
+Olav
+-------------- next part --------------
+An embedded message was scrubbed...
+From: Olav Vitters <ovitters at gmail.com>
+Subject: Impact of ConsoleKit deprecation
+Date: Fri, 27 Jan 2012 00:51:09 +0100
+Size: 2570
+URL: </pipermail/mageia-dev/attachments/20120127/0a22f6ba/attachment.mht>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011583.html b/zarb-ml/mageia-dev/2012-January/011583.html new file mode 100644 index 000000000..e83be62ea --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011583.html @@ -0,0 +1,127 @@ + + + + [Mageia-dev] mkinitrd and Mageia2 + + + + + + + + + +

[Mageia-dev] mkinitrd and Mageia2

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Fri Jan 27 11:02:25 CET 2012 +

+
+ +
'Twas brillig, and Charles A Edwards at 27/01/12 01:06 did gyre and gimble:
+> It was my understanding that mkinitrd would continue to be supported in
+> Mageia2 and then be phased out during the Mageia3 development.
+> 
+> If this is the case, why is it that all 'current' kernels now
+> require dracut?
+
+Basically, if you want to use mkinitrd in mga2, you'll also have to use
+sysvinit. I will not be supporting a systemd system with an mkinitrd initrd.
+
+This is because systemd is fully hotplug, and thus does not just "try
+and do things" and hope for the best. It waits until it knows devices
+are available before using them. It does this via udev. If anything
+mildly exotic is used (e.g. LVM, RAID etc.) then it is the initrd's job
+to start these. If it's done in an mkinitrd, the metadata generated from
+activating these devices is lost as udev is not running at the time. In
+dracut, udev is running and critical metadata is saved and preserved for
+systemd to use later.
+
+So, with the background of why I will not support systemd+mkinitrd out
+of the way, we have to look at the kernels themselves. We require dracut
+now, but it's still perfectly possible to install mkinitrd and set the
+alternatives up correctly such that it is used (update-alternatives
+--display mkinitrd). If you do this, you are on your own - you need to
+remember to install sysvinit and not let systemd be your init.
+
+
+
+The original question is "why does the kernel require dracut?" Well,
+it's our preferred initrd but, as mentioned above, you can still use
+mkinitrd if you absolutely must, but you have to know the consequences
+and repercussions. I originally made dracut fully obsolete mkinitrd,
+giving no choice in the matter. This is still my preferred option for
+mga2 if at all possible, but as I believe others want to keep it for
+now, I'm fine with it. The kernel requires dracut to make sure that the
+default init system (systemd) and the kernel initrd (made with dracut)
+are paired.
+
+Hope that answers your question.
+
+Col
+
+
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011584.html b/zarb-ml/mageia-dev/2012-January/011584.html new file mode 100644 index 000000000..1294643ac --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011584.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] Fwd: GNOME 3.4 will rely on hostnamed, localed, timedated D-Bus API + + + + + + + + + +

[Mageia-dev] Fwd: GNOME 3.4 will rely on hostnamed, localed, timedated D-Bus API

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Fri Jan 27 11:07:48 CET 2012 +

+
+ +
'Twas brillig, and Olav Vitters at 27/01/12 00:00 did gyre and gimble:
+> Daemons will work under sysvinit. Just need to be installed
+
+Cool, I'll keep it in mind. They shouldn't need anything special to be
+honest and I think systemd is required by basesystem anyway so these
+daemons will always be installed and thus activateable over dbus. With
+that in mind, I'm not sure we actually need to do much? (although I'm
+just "thinking" about the problem rather than really looking at it -
+gnome-control-center coredumps here right now so can't really test
+things too much - will have to look into it at some point!).
+
+Col
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011585.html b/zarb-ml/mageia-dev/2012-January/011585.html new file mode 100644 index 000000000..2b474e5c8 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011585.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] Fwd: gnome-boxes/distro integration + + + + + + + + + +

[Mageia-dev] Fwd: gnome-boxes/distro integration

+ Olav Vitters + olav at vitters.nl +
+ Fri Jan 27 11:50:47 CET 2012 +

+
+ +
gnome-boxes maintainer asking that distributions add automatic
+installation support for their distro to the relevant components
+(gnome-boxes + other parts of the stack)
+
+-- 
+Regards,
+Olav
+-------------- next part --------------
+An embedded message was scrubbed...
+From: Christophe Fergeau <cfergeau at redhat.com>
+Subject: gnome-boxes/distro integration
+Date: Fri, 27 Jan 2012 11:46:16 +0100
+Size: 5237
+URL: </pipermail/mageia-dev/attachments/20120127/b9254087/attachment.mht>
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011586.html b/zarb-ml/mageia-dev/2012-January/011586.html new file mode 100644 index 000000000..45728707a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011586.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] Fwd: gnome-boxes/distro integration + + + + + + + + + +

[Mageia-dev] Fwd: gnome-boxes/distro integration

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Fri Jan 27 11:59:17 CET 2012 +

+
+ +
'Twas brillig, and Olav Vitters at 27/01/12 10:50 did gyre and gimble:
+> gnome-boxes maintainer asking that distributions add automatic
+> installation support for their distro to the relevant components
+> (gnome-boxes + other parts of the stack)
+
+Go Teuf!!! :)
+
+If no one else does this, I'll certainly give it a pop (tho' I'm not
+sure Zeeshan has fixed my last libosinfo bug I reported :D)
+
+Col
+
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011587.html b/zarb-ml/mageia-dev/2012-January/011587.html new file mode 100644 index 000000000..dd8cd2c24 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011587.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] Fosdem 2012 - Mageia stand + + + + + + + + + +

[Mageia-dev] Fosdem 2012 - Mageia stand

+ Marja van Waes + marja11 at xs4all.nl +
+ Fri Jan 27 12:56:10 CET 2012 +

+
+ +
On 26/01/12 02:20, Sebastian sebsebseb wrote:
+> On 25/01/12 08:26, Remco Rijnders wrote:
+>> On Wed, Jan 25, 2012 at 09:21:41AM +0100, Oliver wrote in 
+>> <1327479701.21166.4.camel at beteigeuze.oli-home>:
+>>> Am Sonntag, den 15.01.2012, 11:38 +0100 schrieb Oliver Burger:
+>>>> Calling again...
+>>>>
+>>>> Until now we have 19 people coming to FOSDEM but only 5 who have
+>>>> volunteered to help for some time at the stand.
+>>>>
+>>>> So, if you are coming to FOSDEM, please consider helping us there, so
+>>>> it won't be a few people having to stay there the whole day.
+>>>
+>>> It's always great to have so many people reacting...
+>>>
+>>> We are about 20 people at Fosdem and only five of them do volunteer to
+>>> help at the stand, meaning those five will have actually not time left
+>>> to attend any sessions?
+>>> I don't really believe this.
+>>>
+>>> Or am I just too German in my organisation and the way to go is to just
+>>> wait who will honour us with his presence? And I can throw the whole
+>>> organisation out of the window?
+>>
+>> Speaking only for myself here... I had the distinct impression when I 
+>> looked at the FOSDEM site a few weeks back that the list of talks was 
+>> not complete yet. I was kind of waiting on that to see what talks I 
+>> really wanted to attend, and then see what times that'd leave me to 
+>> help at the stand.
+>>
+>> Remco
+> It's a bit like this for me as well. I would like to help on the 
+> Saturday and Sunday at the Mageia stand however I do not know when 
+> exactly, because I haven't been to FOSDEM before. In fact I haven't 
+> been to any Linux/opensource/freesoftware event before.
+>
+> From Sebastian sebsebseb
+Nor have I, but I don't mind seeing the talks on youtube afterwards. 
+Will all talks be recorded?
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011588.html b/zarb-ml/mageia-dev/2012-January/011588.html new file mode 100644 index 000000000..eefb68466 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011588.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] mkinitrd and Mageia2 + + + + + + + + + +

[Mageia-dev] mkinitrd and Mageia2

+ Frank Griffin + ftg at roadrunner.com +
+ Fri Jan 27 14:16:05 CET 2012 +

+
+ +
On 01/27/2012 05:02 AM, Colin Guthrie wrote:
+> In dracut, udev is running and critical metadata is saved and 
+> preserved for systemd to use later.
+Col,
+
+Just as an aside, does this increased role of udev have anything to do 
+with the automount breakage I posted about a few days back ?  From the 
+syslog messages in the working case (all hal-related), it occurred to me 
+that perhaps hal has been dropped and whatever replaced it is dropping 
+the ball.
+
+cf.:
+> Sometime over the last couple of days, loaded DVDs are no longer being 
+> mounted under /media.
+>
+> KDE recognizes the loaded DVD, and brings up the panel popup that 
+> gives you suggested actions.  However, neither "df" nor "mount" shows 
+> the disk to be mounted.
+>
+> LXDE does not seem to recognize the disk at all, and does not launch 
+> either the "what should I do" prompt or the file manager display of 
+> the folders on the disk.
+
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011589.html b/zarb-ml/mageia-dev/2012-January/011589.html new file mode 100644 index 000000000..28b178f88 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011589.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] Fwd: gnome-boxes/distro integration + + + + + + + + + +

[Mageia-dev] Fwd: gnome-boxes/distro integration

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Fri Jan 27 14:59:26 CET 2012 +

+
+ +
'Twas brillig, and Colin Guthrie at 27/01/12 10:59 did gyre and gimble:
+> 'Twas brillig, and Olav Vitters at 27/01/12 10:50 did gyre and gimble:
+>> gnome-boxes maintainer asking that distributions add automatic
+>> installation support for their distro to the relevant components
+>> (gnome-boxes + other parts of the stack)
+> 
+> Go Teuf!!! :)
+> 
+> If no one else does this, I'll certainly give it a pop (tho' I'm not
+> sure Zeeshan has fixed my last libosinfo bug I reported :D)
+
+For reference I was referring to this post:
+
+https://plus.google.com/109973678654056732542/posts/PbSBPnh2bTJ
+
+and this:
+http://git.fedorahosted.org/git/?p=libosinfo.git;a=commit;h=829c6fd86b3c7e4973e520bc78e7c1f0ee2071e7
+
+is the fix by Christophe Fergeau today :)
+
+Col
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011590.html b/zarb-ml/mageia-dev/2012-January/011590.html new file mode 100644 index 000000000..82d76533a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011590.html @@ -0,0 +1,106 @@ + + + + [Mageia-dev] mkinitrd and Mageia2 + + + + + + + + + +

[Mageia-dev] mkinitrd and Mageia2

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Fri Jan 27 15:45:18 CET 2012 +

+
+ +
'Twas brillig, and Frank Griffin at 27/01/12 13:16 did gyre and gimble:
+> On 01/27/2012 05:02 AM, Colin Guthrie wrote:
+>> In dracut, udev is running and critical metadata is saved and
+>> preserved for systemd to use later.
+> Col,
+> 
+> Just as an aside, does this increased role of udev have anything to do
+> with the automount breakage I posted about a few days back ?  From the
+> syslog messages in the working case (all hal-related), it occurred to me
+> that perhaps hal has been dropped and whatever replaced it is dropping
+> the ball.
+
+Well it's complicated. The different DE's do things differently. AFAIK,
+GNOME has used udev for a long time, and I had it in my head that KDE
+did also, but they are totally separate implementations.
+
+But I do see here, that my USB stick is not showing up in GNOME now.
+I'll try later in KDE and try and pinpoint where the weak link is.
+
+The urpmi stuff does still use HAL and should really be ported as HAL
+shouldn't be used now (I've got it disabled on all my mga1 machines
+anyway as I don't use urpmi+CD/DVD media).
+
+Col
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011591.html b/zarb-ml/mageia-dev/2012-January/011591.html new file mode 100644 index 000000000..ba8058346 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011591.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] mkinitrd and Mageia2 + + + + + + + + + +

[Mageia-dev] mkinitrd and Mageia2

+ Frank Griffin + ftg at roadrunner.com +
+ Fri Jan 27 16:17:10 CET 2012 +

+
+ +
On 01/27/2012 09:45 AM, Colin Guthrie wrote:
+> Well it's complicated. The different DE's do things differently. 
+> AFAIK, GNOME has used udev for a long time, and I had it in my head 
+> that KDE did also, but they are totally separate implementations. But 
+> I do see here, that my USB stick is not showing up in GNOME now. I'll 
+> try later in KDE and try and pinpoint where the weak link is. The 
+> urpmi stuff does still use HAL and should really be ported as HAL 
+> shouldn't be used now (I've got it disabled on all my mga1 machines 
+> anyway as I don't use urpmi+CD/DVD media). Col 
+
+Just for the record, this doesn't involve urpmi.  This is just things 
+like brasero and wine apps not being able to "see" loaded media that 
+aren't mounted.
+
+KDE detects that it's there, and reads the volume label to display in 
+the Devices popup, but doesn't mount it, probably because k3b doesn't 
+use mounted media anyway (the first thing it does is umount the disk).  
+Things like VLC, "Play disk" which take the /dev/srX device address work 
+as well.
+
+Sounds like several things are still relying on what hal does.  Is there 
+some intentional reason why volumes are no longer automounted ?
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011592.html b/zarb-ml/mageia-dev/2012-January/011592.html new file mode 100644 index 000000000..dbbf4b70d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011592.html @@ -0,0 +1,123 @@ + + + + [Mageia-dev] mkinitrd and Mageia2 + + + + + + + + + +

[Mageia-dev] mkinitrd and Mageia2

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Fri Jan 27 16:21:04 CET 2012 +

+
+ +
'Twas brillig, and Frank Griffin at 27/01/12 15:17 did gyre and gimble:
+> On 01/27/2012 09:45 AM, Colin Guthrie wrote:
+>> Well it's complicated. The different DE's do things differently.
+>> AFAIK, GNOME has used udev for a long time, and I had it in my head
+>> that KDE did also, but they are totally separate implementations. But
+>> I do see here, that my USB stick is not showing up in GNOME now. I'll
+>> try later in KDE and try and pinpoint where the weak link is. The
+>> urpmi stuff does still use HAL and should really be ported as HAL
+>> shouldn't be used now (I've got it disabled on all my mga1 machines
+>> anyway as I don't use urpmi+CD/DVD media). Col 
+> 
+> Just for the record, this doesn't involve urpmi.  This is just things
+> like brasero and wine apps not being able to "see" loaded media that
+> aren't mounted.
+> 
+> KDE detects that it's there, and reads the volume label to display in
+> the Devices popup, but doesn't mount it, probably because k3b doesn't
+> use mounted media anyway (the first thing it does is umount the disk). 
+> Things like VLC, "Play disk" which take the /dev/srX device address work
+> as well.
+> 
+> Sounds like several things are still relying on what hal does.  Is there
+> some intentional reason why volumes are no longer automounted ?
+
+I really don't think it's anything to do with HAL here. As I said, it's
+only urpmi stuff that uses HAL and I'm pretty certain the DE's long ago
+stopped doing that.
+
+I'll just be some regular bug.
+
+The info comes up in udev when querying /dev/sdb and /dev/sdb1 for
+example, but I'm not 100% sure all the UDISKS_* variables are totally
+correct. The metadata doesn't seem to suggest it is a removable device
+and hence it might not show up properly. I suspect this is the cause of
+that particular problem, but like I say I (or someone) will have to look
+into it a in a bit more detail.
+
+I wouldn't go down the HAL route tho'. I've never had it enabled on my
+machine for >1 year and automounting has worked fine.
+
+Col
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011593.html b/zarb-ml/mageia-dev/2012-January/011593.html new file mode 100644 index 000000000..3d50c8c86 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011593.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] mkinitrd and Mageia2 + + + + + + + + + +

[Mageia-dev] mkinitrd and Mageia2

+ Frank Griffin + ftg at roadrunner.com +
+ Fri Jan 27 16:35:54 CET 2012 +

+
+ +
On 01/27/2012 10:21 AM, Colin Guthrie wrote:
+> I really don't think it's anything to do with HAL here. As I said, 
+> it's only urpmi stuff that uses HAL and I'm pretty certain the DE's 
+> long ago stopped doing that.
+
+OK, some updated testing:
+
+In KDELoad a DVD, get the device popup, and dismiss it.  Do a "df", and 
+see that there is no munt under /media.  If you bring up the Device 
+popup and select "Open with File Manager", Konqueror opens and displays 
+the AUDIO_TS and VIDEO_TS folders.  If you then do a "df", the volume 
+*has* been mounted under /media and stays mounted after you close 
+Konqueror, and now syslog shows:
+
+Jan 27 10:18:46 localhost kernel: VFS: busy inodes on changed media or 
+resized disk sr1
+Jan 27 10:20:23 localhost kernel: UDF-fs: Partition marked readonly; 
+forcing readonly mount
+Jan 27 10:20:23 localhost kernel: UDF-fs: INFO Mounting volume 
+'CSI_NY_S7_D1', timestamp 2011/08/01 22:55 (1ed4)
+
+
+So it appears that KDE is now delaying the mount until you tell it 
+through the device popup that you want to run something it (KDE) "knows" 
+requires the mount ?  That is certainly going to screw up direct 
+invocation (not using the device popup) of any such application.
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011594.html b/zarb-ml/mageia-dev/2012-January/011594.html new file mode 100644 index 000000000..abc953a6e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011594.html @@ -0,0 +1,82 @@ + + + + [Mageia-dev] Fwd: GNOME 3.4 will rely on hostnamed, localed, timedated D-Bus API + + + + + + + + + +

[Mageia-dev] Fwd: GNOME 3.4 will rely on hostnamed, localed, timedated D-Bus API

+ Michael Scherer + misc at zarb.org +
+ Fri Jan 27 16:52:50 CET 2012 +

+
+ +
Le vendredi 27 janvier 2012 à 10:07 +0000, Colin Guthrie a écrit :
+> 'Twas brillig, and Olav Vitters at 27/01/12 00:00 did gyre and gimble:
+> > Daemons will work under sysvinit. Just need to be installed
+> 
+> Cool, I'll keep it in mind. They shouldn't need anything special to be
+> honest and I think systemd is required by basesystem anyway
+
+I fear some people may not like this, can we avoid adding a hard
+requires, and in this case, split the package ?
+
+( or at least, if we cannot do otherwise, we need to document it, and
+how to disable systemd in the release notes, with clear instruction.
+People will complain, but we will answer "this is documented" ).
+
+-- 
+Michael scherer
+
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011595.html b/zarb-ml/mageia-dev/2012-January/011595.html new file mode 100644 index 000000000..60f98ced5 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011595.html @@ -0,0 +1,84 @@ + + + + [Mageia-dev] Fwd: gnome-boxes/distro integration + + + + + + + + + +

[Mageia-dev] Fwd: gnome-boxes/distro integration

+ Michael Scherer + misc at zarb.org +
+ Fri Jan 27 16:57:45 CET 2012 +

+
+ +
Le vendredi 27 janvier 2012 à 11:50 +0100, Olav Vitters a écrit :
+> gnome-boxes maintainer asking that distributions add automatic
+> installation support for their distro to the relevant components
+> (gnome-boxes + other parts of the stack)
+
+first step is just to copy mandriva.xml and clean it ( did already for
+python-virtinstall but there is still no release ), should be rather
+simple ( likely done before the end of the day ).
+
+On the other hand, the vala part in boxes is more tricky to do.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011596.html b/zarb-ml/mageia-dev/2012-January/011596.html new file mode 100644 index 000000000..288735703 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011596.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] Fwd: GNOME 3.4 will rely on hostnamed, localed, timedated D-Bus API + + + + + + + + + +

[Mageia-dev] Fwd: GNOME 3.4 will rely on hostnamed, localed, timedated D-Bus API

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Fri Jan 27 17:14:49 CET 2012 +

+
+ +
'Twas brillig, and Michael Scherer at 27/01/12 15:52 did gyre and gimble:
+> Le vendredi 27 janvier 2012 à 10:07 +0000, Colin Guthrie a écrit :
+>> 'Twas brillig, and Olav Vitters at 27/01/12 00:00 did gyre and gimble:
+>>> Daemons will work under sysvinit. Just need to be installed
+>>
+>> Cool, I'll keep it in mind. They shouldn't need anything special to be
+>> honest and I think systemd is required by basesystem anyway
+> 
+> I fear some people may not like this, can we avoid adding a hard
+> requires, and in this case, split the package ?
+> 
+> ( or at least, if we cannot do otherwise, we need to document it, and
+> how to disable systemd in the release notes, with clear instruction.
+> People will complain, but we will answer "this is documented" ).
+
+Systemd is just installed, it doesn't mean it's used. You need to
+install systemd-sysvinit for it to replace sysvinit.
+
+While I'm sure we could split the package up, I'm not really sure how
+much it gains in practice other than a few kb of disk space.
+
+Col
+
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011597.html b/zarb-ml/mageia-dev/2012-January/011597.html new file mode 100644 index 000000000..5020526a4 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011597.html @@ -0,0 +1,84 @@ + + + + [Mageia-dev] mkinitrd and Mageia2 + + + + + + + + + +

[Mageia-dev] mkinitrd and Mageia2

+ Florian Hubold + doktor5000 at arcor.de +
+ Fri Jan 27 19:38:02 CET 2012 +

+
+ +
Am 27.01.2012 16:35, schrieb Frank Griffin:
+> On 01/27/2012 10:21 AM, Colin Guthrie wrote:
+>> I really don't think it's anything to do with HAL here. As I said, it's only
+>> urpmi stuff that uses HAL and I'm pretty certain the DE's long ago stopped
+>> doing that.
+>
+>
+>
+> So it appears that KDE is now delaying the mount until you tell it through
+> the device popup that you want to run something it (KDE) "knows" requires the
+> mount ?  That is certainly going to screw up direct invocation (not using the
+> device popup) of any such application.
+
+For reference, with a default setup KDE doesn't automatically mount
+removable media like GNOME does, this is the case since quite some
+time, IIRC it goes back to 4.0.
+
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011598.html b/zarb-ml/mageia-dev/2012-January/011598.html new file mode 100644 index 000000000..51b25cf98 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011598.html @@ -0,0 +1,106 @@ + + + + [Mageia-dev] mkinitrd and Mageia2 + + + + + + + + + +

[Mageia-dev] mkinitrd and Mageia2

+ Frank Griffin + ftg at roadrunner.com +
+ Fri Jan 27 20:13:27 CET 2012 +

+
+ +
On 01/27/2012 01:38 PM, Florian Hubold wrote:
+> For reference, with a default setup KDE doesn't automatically mount 
+> removable media like GNOME does, this is the case since quite some 
+> time, IIRC it goes back to 4.0. 
+
+As I said in my initial post about automounting, a week or so ago it was 
+working, and whatever was mounting the disk looked like it was using hal 
+to do it:
+
+Jan 19 16:14:08 localhost halevt: halevt 0.1.6.2, 
+http://www.environnement.ens.fr/perso/dumas/halevt.html
+Jan 19 16:14:08 localhost halevt: No pid file used
+Jan 19 16:14:08 localhost halevt: Running: halevt-mount -u 
+/org/freedesktop/Hal/devices/volume_label_CSI_NY_S6_D4 -o flush
+
+Also, I've been burning ISOs to disk under KDE for months using brasero, 
+and if you loaded a blank disk and did an "OpenWith..." (brasero) on the 
+ISO file before KDE had recognized the blank disk, you got a brasero 
+dialog telling you to mount a blank disk for it; as soon as the blank 
+was detected and the KDE Device popup came up showing it, brasero 
+immediately switched its dialog to ready-to-burn.  Now, it just sits 
+there waiting.
+
+All of this started sometime after Jan19/Jan20, and worked fine prior to 
+that.
+
+But I tend to think you're right about KDE, as I've had 
+https://bugs.kde.org/show_bug.cgi?id=287170 opened for awhile, and that 
+would explain it.  Wine apps can't access unmounted disks, and my Wine 
+apps that use DVDs haven't worked under KDE for a long time.
+
+And then there's the issue that automount had been working in LXDE and 
+stopped working at the same time.  So, it may be that KDE has not been 
+automounting all along, but something else was whether KDE was active or 
+not.
+
+Whatever changed (and *something* did), the effect is that a lot of 
+stuff that was working no longer does, and I wanted to raise the issue 
+while whatever changed might be fresh enough in folks' minds to ring a bell.
+
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011599.html b/zarb-ml/mageia-dev/2012-January/011599.html new file mode 100644 index 000000000..6a1217d54 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011599.html @@ -0,0 +1,64 @@ + + + + [Mageia-dev] Fosdem 2012 - Mageia stand + + + + + + + + + +

[Mageia-dev] Fosdem 2012 - Mageia stand

+ Maarten Vanraes + alien at rmail.be +
+ Fri Jan 27 21:06:16 CET 2012 +

+
+ +
Op vrijdag 27 januari 2012 12:56:10 schreef Marja van Waes:
+> Nor have I, but I don't mind seeing the talks on youtube afterwards.
+> Will all talks be recorded?
+
+i think only the bigger ones...
+
+but we may have a problem when the general assembly is there, because likely 
+everyone will want to be there...
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011600.html b/zarb-ml/mageia-dev/2012-January/011600.html new file mode 100644 index 000000000..0174ab8cc --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011600.html @@ -0,0 +1,67 @@ + + + + [Mageia-dev] Fosdem 2012 - Mageia stand + + + + + + + + + +

[Mageia-dev] Fosdem 2012 - Mageia stand

+ Marja van Waes + marja11 at xs4all.nl +
+ Fri Jan 27 21:16:27 CET 2012 +

+
+ +
On 27/01/12 21:06, Maarten Vanraes wrote:
+> Op vrijdag 27 januari 2012 12:56:10 schreef Marja van Waes:
+>> Nor have I, but I don't mind seeing the talks on youtube afterwards.
+>> Will all talks be recorded?
+> i think only the bigger ones...
+>
+> but we may have a problem when the general assembly is there, because likely
+> everyone will want to be there...
+
+I suppose I was the last one to start contributing (september 1st 2011), 
+so I think I should take care of the Mageia stand during the assembly.
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011601.html b/zarb-ml/mageia-dev/2012-January/011601.html new file mode 100644 index 000000000..c9d364440 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011601.html @@ -0,0 +1,75 @@ + + + + [Mageia-dev] Fosdem 2012 - Mageia stand + + + + + + + + + +

[Mageia-dev] Fosdem 2012 - Mageia stand

+ Maarten Vanraes + alien at rmail.be +
+ Fri Jan 27 21:24:19 CET 2012 +

+
+ +
Op vrijdag 27 januari 2012 21:16:27 schreef Marja van Waes:
+> On 27/01/12 21:06, Maarten Vanraes wrote:
+> > Op vrijdag 27 januari 2012 12:56:10 schreef Marja van Waes:
+> >> Nor have I, but I don't mind seeing the talks on youtube afterwards.
+> >> Will all talks be recorded?
+> > 
+> > i think only the bigger ones...
+> > 
+> > but we may have a problem when the general assembly is there, because
+> > likely everyone will want to be there...
+> 
+> I suppose I was the last one to start contributing (september 1st 2011),
+> so I think I should take care of the Mageia stand during the assembly.
+
+oh, come on, we are all equal...
+
+maybe we can find some people from stands next to us to look after it for just 
+one hour and stick a paper on it, that we're at general assembly in room XX 
+and that they could reach us there...
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011602.html b/zarb-ml/mageia-dev/2012-January/011602.html new file mode 100644 index 000000000..74f84fa47 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011602.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] Fwd: GNOME 3.4 will rely on hostnamed, localed, timedated D-Bus API + + + + + + + + + +

[Mageia-dev] Fwd: GNOME 3.4 will rely on hostnamed, localed, timedated D-Bus API

+ Michael Scherer + misc at zarb.org +
+ Fri Jan 27 22:25:13 CET 2012 +

+
+ +
Le vendredi 27 janvier 2012 à 16:14 +0000, Colin Guthrie a écrit :
+> 'Twas brillig, and Michael Scherer at 27/01/12 15:52 did gyre and gimble:
+> > Le vendredi 27 janvier 2012 à 10:07 +0000, Colin Guthrie a écrit :
+> >> 'Twas brillig, and Olav Vitters at 27/01/12 00:00 did gyre and gimble:
+> >>> Daemons will work under sysvinit. Just need to be installed
+> >>
+> >> Cool, I'll keep it in mind. They shouldn't need anything special to be
+> >> honest and I think systemd is required by basesystem anyway
+> > 
+> > I fear some people may not like this, can we avoid adding a hard
+> > requires, and in this case, split the package ?
+> > 
+> > ( or at least, if we cannot do otherwise, we need to document it, and
+> > how to disable systemd in the release notes, with clear instruction.
+> > People will complain, but we will answer "this is documented" ).
+> 
+> Systemd is just installed, it doesn't mean it's used. You need to
+> install systemd-sysvinit for it to replace sysvinit.
+
+Yes, I know this is just installed and not used, but I am pretty sure
+that some people will complain. 
+
+> While I'm sure we could split the package up, I'm not really sure how
+> much it gains in practice other than a few kb of disk space.
+
+Disk space is not the concern. Making sure I do not start to kill people
+who complain "systemd cannot be removed, this is an outrage !!" is the
+concern :)
+
+But if this cannot be done or too hard, no problem.
+-- 
+Michael Scherer
+
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011603.html b/zarb-ml/mageia-dev/2012-January/011603.html new file mode 100644 index 000000000..5887a1a4d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011603.html @@ -0,0 +1,79 @@ + + + + [Mageia-dev] Fosdem 2012 - Mageia stand + + + + + + + + + +

[Mageia-dev] Fosdem 2012 - Mageia stand

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Sat Jan 28 00:49:05 CET 2012 +

+
+ +
2012/1/27 Maarten Vanraes <alien at rmail.be>:
+> Op vrijdag 27 januari 2012 21:16:27 schreef Marja van Waes:
+>> > but we may have a problem when the general assembly is there, because
+>> > likely everyone will want to be there...
+I personally will want to be there, of course...
+>>
+>> I suppose I was the last one to start contributing (september 1st 2011),
+>> so I think I should take care of the Mageia stand during the assembly.
+>
+> oh, come on, we are all equal...
+>
+> maybe we can find some people from stands next to us to look after it for just
+> one hour and stick a paper on it, that we're at general assembly in room XX
+> and that they could reach us there...
+That is a really good idea and I think the FOSDEM people won't have
+anything against it, we are not in Germany after all where some events
+do really tell us, we have to be at the stand every minute.
+Germans and their organisation talent :/
+
+/me included, so I would really like to see more people in the wiki
+planing. There's some kind of cultural genetic inheritance after all
+:D
+
+Oliver
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011604.html b/zarb-ml/mageia-dev/2012-January/011604.html new file mode 100644 index 000000000..f1ddfaa2b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011604.html @@ -0,0 +1,83 @@ + + + + [Mageia-dev] Fwd: GNOME 3.4 will rely on hostnamed, localed, timedated D-Bus API + + + + + + + + + +

[Mageia-dev] Fwd: GNOME 3.4 will rely on hostnamed, localed, timedated D-Bus API

+ Maarten Vanraes + alien at rmail.be +
+ Sat Jan 28 08:25:51 CET 2012 +

+
+ +
Op vrijdag 27 januari 2012 22:25:13 schreef Michael Scherer:
+[...]
+> > Systemd is just installed, it doesn't mean it's used. You need to
+> > install systemd-sysvinit for it to replace sysvinit.
+> 
+> Yes, I know this is just installed and not used, but I am pretty sure
+> that some people will complain.
+> 
+> > While I'm sure we could split the package up, I'm not really sure how
+> > much it gains in practice other than a few kb of disk space.
+> 
+> Disk space is not the concern. Making sure I do not start to kill people
+> who complain "systemd cannot be removed, this is an outrage !!" is the
+> concern :)
+> 
+> But if this cannot be done or too hard, no problem.
+
+I agree with Michael's sentiments.
+
+my first thoughts were: "systemd cannot be removed, this is an outrage !!", but 
+after reading, i saw that only systemd-sysvinit would actually replace 
+sysvinit, i was at ease. Except, i don't think alot of impatient people will 
+read on...
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011605.html b/zarb-ml/mageia-dev/2012-January/011605.html new file mode 100644 index 000000000..7a65c7c18 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011605.html @@ -0,0 +1,81 @@ + + + + [Mageia-dev] virtuoso-t (nepomuk?) takes too much memory (and CPU) + + + + + + + + + +

[Mageia-dev] virtuoso-t (nepomuk?) takes too much memory (and CPU)

+ Maarten Vanraes + alien at rmail.be +
+ Sat Jan 28 09:48:08 CET 2012 +

+
+ +
on my cauldron virtual machine (updated and rebooted as of yesterday), 
+virtuoso-t takes more than 200MB in ram taking by far the first position on 
+this 1GB virtual machine. It also uses about 75% of a CPU core all the time.
+
+what does it actually do? is this even needed? and why is it leaking so much 
+memory?
+
+even firefox is taking only 60MB, mysqld (from akonadi) taking only 80MB, and X 
+taking 36MB and plasma 12MB...
+
+after killing it, in less than 10min, it's back up there using already 100MB 
+and 75% CPU of a core.
+
+on such a mostly idle VM, i don't see the benefit...
+
+i note that it doesn't always use 75% CPU, sometimes it doesn't use any CPU, 
+but the next minute it's back to use 75% .
+
+just wondering if there's a good reason for this?
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011606.html b/zarb-ml/mageia-dev/2012-January/011606.html new file mode 100644 index 000000000..fd434a37f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011606.html @@ -0,0 +1,71 @@ + + + + [Mageia-dev] Fosdem 2012 - Mageia stand + + + + + + + + + +

[Mageia-dev] Fosdem 2012 - Mageia stand

+ Bernard Siaud alias Troumad + liste at siaud.org +
+ Sat Jan 28 09:39:18 CET 2012 +

+
+ +
Hello
+
+I don't write often because I don't speake english...
+
+Have you see 
+http://foundation.zarb.org/wiki/index.php/Foundation/FOSDEM2012 ?
+Is it possible to work together again?
+
+
+-- 
+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/2012-January/011607.html b/zarb-ml/mageia-dev/2012-January/011607.html new file mode 100644 index 000000000..f72c6b2d8 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011607.html @@ -0,0 +1,78 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release netpbm-10.47.35-2.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release netpbm-10.47.35-2.mga2

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Sat Jan 28 16:30:42 CET 2012 +

+
+ +
On 28 January 2012 16:00, fwang <buildsystem-daemon at mageia.org> wrote:
+> fwang <fwang> 10.47.35-2.mga2:
+> + Revision: 202632
+> - force use png12
+
+Why? this should be explained in the log
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011608.html b/zarb-ml/mageia-dev/2012-January/011608.html new file mode 100644 index 000000000..71b021e88 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011608.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release netpbm-10.47.35-2.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release netpbm-10.47.35-2.mga2

+ Funda Wang + fundawang at gmail.com +
+ Sat Jan 28 16:46:19 CET 2012 +

+
+ +
Well, I'll be happy if we could switch to advanced branch of netpbm,
+instead of current stable branch. Without huge patch (and maybe
+useless), stable branch of netpbm could be compiled with libpng 1.5.
+
+But netpbm does not have a maintainer now, and I don't want become the
+maintainer of it, since I rarely use it nor now about it. Plus,
+switching branch will likely causing our huge number of patches be
+rediffed, which is a pain for me :(
+
+2012/1/28 Thierry Vignaud <thierry.vignaud at gmail.com>:
+> On 28 January 2012 16:00, fwang <buildsystem-daemon at mageia.org> wrote:
+>> fwang <fwang> 10.47.35-2.mga2:
+>> + Revision: 202632
+>> - force use png12
+>
+> Why? this should be explained in the log
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011609.html b/zarb-ml/mageia-dev/2012-January/011609.html new file mode 100644 index 000000000..68491c559 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011609.html @@ -0,0 +1,85 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release netpbm-10.47.35-2.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release netpbm-10.47.35-2.mga2

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Sat Jan 28 17:46:33 CET 2012 +

+
+ +
On 28 January 2012 16:46, Funda Wang <fundawang at gmail.com> wrote:
+> Well, I'll be happy if we could switch to advanced branch of netpbm,
+> instead of current stable branch. Without huge patch (and maybe
+> useless), stable branch of netpbm could be compiled with libpng 1.5.
+>
+> But netpbm does not have a maintainer now, and I don't want become the
+> maintainer of it, since I rarely use it nor now about it. Plus,
+> switching branch will likely causing our huge number of patches be
+> rediffed, which is a pain for me :(
+
+Fair enough but can you just edit the changelog?
+Though I guess we can guess from now that any such "force building
+with libpng12" means "this doesn't support libpng15"...
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011610.html b/zarb-ml/mageia-dev/2012-January/011610.html new file mode 100644 index 000000000..1541f8e92 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011610.html @@ -0,0 +1,66 @@ + + + + [Mageia-dev] Fosdem 2012 - Mageia stand + + + + + + + + + +

[Mageia-dev] Fosdem 2012 - Mageia stand

+ Romain d'Alverny + rdalverny at gmail.com +
+ Sat Jan 28 17:56:27 CET 2012 +

+
+ +
On Sat, Jan 28, 2012 at 09:39, Bernard Siaud alias Troumad
+<liste at siaud.org> wrote:
+> Is it possible to work together again?
+
+The right question is: do we go the same road? partial answer is: we
+don't know about theirs at this time.
+
+If they take the time to build such an alternative, it might be that
+they are not satisfied with how Mageia governance and/or plans are
+designed.
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011611.html b/zarb-ml/mageia-dev/2012-January/011611.html new file mode 100644 index 000000000..470955eee --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011611.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] virtuoso-t (nepomuk?) takes too much memory (and CPU) + + + + + + + + + +

[Mageia-dev] virtuoso-t (nepomuk?) takes too much memory (and CPU)

+ Florian Hubold + doktor5000 at arcor.de +
+ Sat Jan 28 18:56:35 CET 2012 +

+
+ +
Am 28.01.2012 09:48, schrieb Maarten Vanraes:
+> on my cauldron virtual machine (updated and rebooted as of yesterday), 
+> virtuoso-t takes more than 200MB in ram taking by far the first position on 
+> this 1GB virtual machine. It also uses about 75% of a CPU core all the time.
+>
+> what does it actually do? is this even needed? and why is it leaking so much 
+> memory?
+It's the database backend for Nepomuk, and i assume that it does the
+initial indexing of your /home. It does not leak memory, and it's not really
+needed,
+you might want to disable Nepomuk/Strigi altogether.
+
+You might want to look at
+http://trueg.wordpress.com/2009/10/22/virtuoso-once-more-with-feeling/
+for some context information and https://bugs.kde.org/show_bug.cgi?id=246678
+or https://bugs.kde.org/show_bug.cgi?id=281653 for bug information.
+
+> even firefox is taking only 60MB, mysqld (from akonadi) taking only 80MB, and X 
+> taking 36MB and plasma 12MB...
+>
+> after killing it, in less than 10min, it's back up there using already 100MB 
+> and 75% CPU of a core.
+>
+> on such a mostly idle VM, i don't see the benefit...
+>
+> i note that it doesn't always use 75% CPU, sometimes it doesn't use any CPU, 
+> but the next minute it's back to use 75% .
+>
+> just wondering if there's a good reason for this?
+>
+
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011612.html b/zarb-ml/mageia-dev/2012-January/011612.html new file mode 100644 index 000000000..1d10c7481 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011612.html @@ -0,0 +1,78 @@ + + + + [Mageia-dev] crond was not set to start + + + + + + + + + +

[Mageia-dev] crond was not set to start

+ Olav Vitters + olav at vitters.nl +
+ Sat Jan 28 19:59:54 CET 2012 +

+
+ +
I noticed crond wasn't running, nor enabled to start. Enabled it now,
+but are others seeing the same? I'm very sure it used to work after
+switching to systemd. Something after I switched to systemd broke it I
+think.
+
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011613.html b/zarb-ml/mageia-dev/2012-January/011613.html new file mode 100644 index 000000000..b2f15818c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011613.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] crond was not set to start + + + + + + + + + +

[Mageia-dev] crond was not set to start

+ Barry Jackson + zen25000 at zen.co.uk +
+ Sat Jan 28 20:57:25 CET 2012 +

+
+ +
On 28/01/12 18:59, Olav Vitters wrote:
+> I noticed crond wasn't running, nor enabled to start. Enabled it now,
+> but are others seeing the same? I'm very sure it used to work after
+> switching to systemd. Something after I switched to systemd broke it I
+> think.
+>
+Yes - I just realised earlier today that my nightly backups have not 
+been running - since Jan 9th. !!
+
+After:-
+systemctl enable crond.service
+systemctl start crond.service
+
+It's now running and survives a reboot.
+
+I think this must have happened around the time that there were many 
+systemd changes taking place.
+
+The status/settings shown in mcc->system->services are still incorrect 
+but this is a known issue.
+
+Best to check using :-
+systemctl status <servicename>.service
+
+
+ + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011614.html b/zarb-ml/mageia-dev/2012-January/011614.html new file mode 100644 index 000000000..961a02d76 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011614.html @@ -0,0 +1,78 @@ + + + + [Mageia-dev] java-rpmbuild-1.7.5-15.mga2.x86_64 won't install + + + + + + + + + +

[Mageia-dev] java-rpmbuild-1.7.5-15.mga2.x86_64 won't install

+ Barry Jackson + zen25000 at zen.co.uk +
+ Sat Jan 28 21:01:56 CET 2012 +

+
+ +
Since update today:-
+A requested package cannot be installed:
+java-rpmbuild-1.7.5-15.mga2.x86_64 (due to unsatisfied jpackage-utils[== 
+1.7.5])
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011615.html b/zarb-ml/mageia-dev/2012-January/011615.html new file mode 100644 index 000000000..e57962400 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011615.html @@ -0,0 +1,81 @@ + + + + [Mageia-dev] crond was not set to start + + + + + + + + + +

[Mageia-dev] crond was not set to start

+ Anssi Hannula + anssi at mageia.org +
+ Sat Jan 28 21:16:35 CET 2012 +

+
+ +
On 28.01.2012 20:59, Olav Vitters wrote:
+> I noticed crond wasn't running, nor enabled to start. Enabled it now,
+> but are others seeing the same? I'm very sure it used to work after
+> switching to systemd. Something after I switched to systemd broke it I
+> think.
+
+Yes, services get disabled when migrating to systemd. Some others I
+noticed on my system were ntpd and avahi...
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011616.html b/zarb-ml/mageia-dev/2012-January/011616.html new file mode 100644 index 000000000..6264b54e7 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011616.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] crond was not set to start + + + + + + + + + +

[Mageia-dev] crond was not set to start

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Sat Jan 28 22:35:33 CET 2012 +

+
+ +
'Twas brillig, and Anssi Hannula at 28/01/12 20:16 did gyre and gimble:
+> On 28.01.2012 20:59, Olav Vitters wrote:
+>> I noticed crond wasn't running, nor enabled to start. Enabled it now,
+>> but are others seeing the same? I'm very sure it used to work after
+>> switching to systemd. Something after I switched to systemd broke it I
+>> think.
+> 
+> Yes, services get disabled when migrating to systemd. Some others I
+> noticed on my system were ntpd and avahi...
+
+Yeah, but this is something Olav specifically reckons isn't actually the
+problem in his case (FWIW, I was talking to dmorgan about it on Friday.
+I reckon I can fix in the rpm-helper script)
+
+My crond.service was disabled, but I can't specifically remember
+enabling it on this machine, so that doesn't really help much.
+
+Col
+
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011617.html b/zarb-ml/mageia-dev/2012-January/011617.html new file mode 100644 index 000000000..acceba100 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011617.html @@ -0,0 +1,75 @@ + + + + [Mageia-dev] Fosdem 2012 - Mageia stand + + + + + + + + + +

[Mageia-dev] Fosdem 2012 - Mageia stand

+ Bernard Siaud alias Troumad + liste at siaud.org +
+ Sat Jan 28 21:36:22 CET 2012 +

+
+ +
Le 28/01/2012 17:56, Romain d'Alverny a écrit :
+> On Sat, Jan 28, 2012 at 09:39, Bernard Siaud alias Troumad
+> <liste at siaud.org>  wrote:
+>> Is it possible to work together again?
+> The right question is: do we go the same road? partial answer is: we
+> don't know about theirs at this time.
+Can someone from mageia go to this meeting for speak with the developer 
+of Mandriva ?
+> If they take the time to build such an alternative, it might be that
+> they are not satisfied with how Mageia governance and/or plans are
+> designed.
+Probably not all, maybe one or two that are currently running Mandriva.
+
+-- 
+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/2012-January/011618.html b/zarb-ml/mageia-dev/2012-January/011618.html new file mode 100644 index 000000000..0c8c80848 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011618.html @@ -0,0 +1,79 @@ + + + + [Mageia-dev] java-rpmbuild-1.7.5-15.mga2.x86_64 won't install + + + + + + + + + +

[Mageia-dev] java-rpmbuild-1.7.5-15.mga2.x86_64 won't install

+ Barry Jackson + zen25000 at zen.co.uk +
+ Sun Jan 29 00:21:42 CET 2012 +

+
+ +
On 28/01/12 20:01, Barry Jackson wrote:
+> Since update today:-
+> A requested package cannot be installed:
+> java-rpmbuild-1.7.5-15.mga2.x86_64 (due to unsatisfied jpackage-utils[==
+> 1.7.5])
+>
+
+tv - thanks for fixing it :)
+
+ + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011619.html b/zarb-ml/mageia-dev/2012-January/011619.html new file mode 100644 index 000000000..ca588b71a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011619.html @@ -0,0 +1,85 @@ + + + + [Mageia-dev] Some changes to lang.pm of drakx + + + + + + + + + +

[Mageia-dev] Some changes to lang.pm of drakx

+ You-Cheng Hsieh + yochenhsieh at gmail.com +
+ Sun Jan 29 14:50:41 CET 2012 +

+
+ +
Hello,
+
+I've just committed some changes to lang.pm of drakx:
+- add hime, a fork of gcin by some of its contributors. the package of
+hime has been imported to cauldron. Since hime is a new package,
+adding it to lang.pm is necessary to make it available in localedrake.
+
+- remove chinput, kinput2, oxim, xcin. These ime have no packages in
+Mageia and are not maintained upstream long ago. So I just comment out
+their lines.
+These changes will only affect how users select ime in localedrake.
+
+Thanks.
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011620.html b/zarb-ml/mageia-dev/2012-January/011620.html new file mode 100644 index 000000000..2828e8a02 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011620.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] [soft-commits] [2851] Add hime; remove chinput, kinput2, oxim, xcin. + + + + + + + + + +

[Mageia-dev] [soft-commits] [2851] Add hime; remove chinput, kinput2, oxim, xcin.

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Sun Jan 29 14:54:13 CET 2012 +

+
+ +
On 29 January 2012 13:58,  <root at mageia.org> wrote:
+> Revision 2851 Author yochenhsieh Date 2012-01-29 13:58:01 +0100 (Sun, 29 Jan
+> 2012)
+>
+> Log Message
+>
+> Add hime; remove chinput, kinput2, oxim, xcin.
+
+why 3 commits with the same changelog?
+If you wanted to revert only the locale list changes, then just do
+that next time,
+with a proper changelog.
+Thanks.
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011621.html b/zarb-ml/mageia-dev/2012-January/011621.html new file mode 100644 index 000000000..83ec137d3 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011621.html @@ -0,0 +1,67 @@ + + + + [Mageia-dev] Fosdem 2012 - Mageia stand + + + + + + + + + +

[Mageia-dev] Fosdem 2012 - Mageia stand

+ Romain d'Alverny + rdalverny at gmail.com +
+ Sun Jan 29 14:57:51 CET 2012 +

+
+ +
On Sat, Jan 28, 2012 at 21:36, Bernard Siaud alias Troumad
+<liste at siaud.org> wrote:
+> Can someone from mageia go to this meeting for speak with the developer of
+> Mandriva ?
+
+Of course, if welcome *. But there's no time/place/invitation set and
+apart from this wiki page, no one heard of this meeting.
+
+* we will be 20+ people from Mageia (among which all Board and almost
+all Council members) at FOSDEM
+(https://wiki.mageia.org/en/Fosdem_2012#Who_will_be_there), so we will
+be available.
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011622.html b/zarb-ml/mageia-dev/2012-January/011622.html new file mode 100644 index 000000000..60d5b7edb --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011622.html @@ -0,0 +1,89 @@ + + + + [Mageia-dev] [soft-commits] [2851] Add hime; remove chinput, kinput2, oxim, xcin. + + + + + + + + + +

[Mageia-dev] [soft-commits] [2851] Add hime; remove chinput, kinput2, oxim, xcin.

+ You-Cheng Hsieh + yochenhsieh at gmail.com +
+ Sun Jan 29 15:09:14 CET 2012 +

+
+ +
2012/1/29 Thierry Vignaud <thierry.vignaud at gmail.com>:
+> On 29 January 2012 13:58,  <root at mageia.org> wrote:
+>> Revision 2851 Author yochenhsieh Date 2012-01-29 13:58:01 +0100 (Sun, 29 Jan
+>> 2012)
+>>
+>> Log Message
+>>
+>> Add hime; remove chinput, kinput2, oxim, xcin.
+>
+> why 3 commits with the same changelog?
+> If you wanted to revert only the locale list changes, then just do
+> that next time,
+> with a proper changelog.
+> Thanks.
+Sorry, I will be more careful about that next time.
+My apology for any confusion and inconvenience.
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011623.html b/zarb-ml/mageia-dev/2012-January/011623.html new file mode 100644 index 000000000..2fd6f3402 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011623.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release kdenetwork4-4.8.0-2.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release kdenetwork4-4.8.0-2.mga2

+ Balcaen John + mikala at mageia.org +
+ Sun Jan 29 17:16:21 CET 2012 +

+
+ +
On Sunday 29 January 2012 16:03:19 kamil wrote :
+> Name        : kdenetwork4                  Relocations: (not relocatable)
+> Version     : 4.8.0                             Vendor: Mageia.Org
+> Release     : 2.mga2                        Build Date: Sun Jan 29 15:40:14
+> 2012 Install Date: (not installed)               Build Host: ecosse
+> Group       : Graphical desktop/KDE         Source RPM: (none)
+> Size        : 10008730                         License: GPLv2 LGPLv2 GFDL
+> Signature   : (none)
+> Packager    : kamil <kamil>
+> URL         : http://www.kde.org
+> Summary     : K Desktop Environment - Network Applications
+> Description :
+> Networking applications for the KDE 4.
+> 
+> - kdict: graphical client for the DICT protocol
+> - kit: AOL instant messenger client, using the TOC protocol
+> - kpf: public fileserver applet
+> - krfb: Desktop Sharing server, allow others to access your desktop via VNC
+> - krdc: a client for Desktop Sharing and other VNC servers.
+> 
+> kamil <kamil> 3:4.8.0-2.mga2:
+> + Revision: 202900
+> - rebuild against new libgadu-1.11.1
+
+Since gadu did not change his major, did you notice specific issue with the new  
+libgadu & kopete or did you simply rebuild the package because you did upgrade 
+libgadu ?
+
+
+
+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/2012-January/011624.html b/zarb-ml/mageia-dev/2012-January/011624.html new file mode 100644 index 000000000..87f3d8404 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011624.html @@ -0,0 +1,110 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release kdenetwork4-4.8.0-2.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release kdenetwork4-4.8.0-2.mga2

+ Kamil Rytarowski + n54 at gmx.com +
+ Sun Jan 29 18:08:28 CET 2012 +

+
+ +
W dniu 29.01.2012 17:16, Balcaen John pisze:
+> On Sunday 29 January 2012 16:03:19 kamil wrote :
+>> Name        : kdenetwork4                  Relocations: (not relocatable)
+>> Version     : 4.8.0                             Vendor: Mageia.Org
+>> Release     : 2.mga2                        Build Date: Sun Jan 29 15:40:14
+>> 2012 Install Date: (not installed)               Build Host: ecosse
+>> Group       : Graphical desktop/KDE         Source RPM: (none)
+>> Size        : 10008730                         License: GPLv2 LGPLv2 GFDL
+>> Signature   : (none)
+>> Packager    : kamil<kamil>
+>> URL         : http://www.kde.org
+>> Summary     : K Desktop Environment - Network Applications
+>> Description :
+>> Networking applications for the KDE 4.
+>>
+>> - kdict: graphical client for the DICT protocol
+>> - kit: AOL instant messenger client, using the TOC protocol
+>> - kpf: public fileserver applet
+>> - krfb: Desktop Sharing server, allow others to access your desktop via VNC
+>> - krdc: a client for Desktop Sharing and other VNC servers.
+>>
+>> kamil<kamil>  3:4.8.0-2.mga2:
+>> + Revision: 202900
+>> - rebuild against new libgadu-1.11.1
+> Since gadu did not change his major, did you notice specific issue with the new
+> libgadu&  kopete or did you simply rebuild the package because you did upgrade
+> libgadu ?
+Hello!
+I've simply rebuilt new release of the library for kopete.
+
+http://toxygen.net/libgadu/releases/1.11.1.html
+The change-log says that there is better handling for libraries, macros, 
+unicode. There were not any specific issue.
+>
+>
+> Regards,
+
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011625.html b/zarb-ml/mageia-dev/2012-January/011625.html new file mode 100644 index 000000000..e1ecaed53 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011625.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release kdenetwork4-4.8.0-2.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release kdenetwork4-4.8.0-2.mga2

+ Balcaen John + mikala at mageia.org +
+ Sun Jan 29 18:13:06 CET 2012 +

+
+ +
On Sunday 29 January 2012 18:08:28 Kamil Rytarowski wrote :
+[...]
+> 
+> Hello!
+> I've simply rebuilt new release of the library for kopete.
+So since there's no specific issue (like for boost changes) & no change in the 
+soname major version, you don't have to rebuild all packages like this.
+Could you also check your personal email (kamil at mageia.org) regarding your 
+changes about the spec layout...
+
+
+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/2012-January/011626.html b/zarb-ml/mageia-dev/2012-January/011626.html new file mode 100644 index 000000000..54ce3c5ca --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011626.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release kdenetwork4-4.8.0-2.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release kdenetwork4-4.8.0-2.mga2

+ Kamil Rytarowski + n54 at gmx.com +
+ Sun Jan 29 18:14:37 CET 2012 +

+
+ +
W dniu 29.01.2012 18:13, Balcaen John pisze:
+> On Sunday 29 January 2012 18:08:28 Kamil Rytarowski wrote :
+> [...]
+>> Hello!
+>> I've simply rebuilt new release of the library for kopete.
+> So since there's no specific issue (like for boost changes)&  no change in the
+> soname major version, you don't have to rebuild all packages like this.
+> Could you also check your personal email (kamil at mageia.org) regarding your
+> changes about the spec layout...
+I see, thank you for your tip!
+>
+> Regards,
+
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011627.html b/zarb-ml/mageia-dev/2012-January/011627.html new file mode 100644 index 000000000..4105d5eb2 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011627.html @@ -0,0 +1,79 @@ + + + + [Mageia-dev] virtuoso-t (nepomuk?) takes too much memory (and CPU) + + + + + + + + + +

[Mageia-dev] virtuoso-t (nepomuk?) takes too much memory (and CPU)

+ Maarten Vanraes + alien at rmail.be +
+ Sun Jan 29 18:45:18 CET 2012 +

+
+ +
Op zaterdag 28 januari 2012 18:56:35 schreef Florian Hubold:
+> Am 28.01.2012 09:48, schrieb Maarten Vanraes:
+[...]
+> > what does it actually do? is this even needed? and why is it leaking so
+> > much memory?
+> 
+> It's the database backend for Nepomuk, and i assume that it does the
+> initial indexing of your /home. It does not leak memory, and it's not
+> really needed,
+> you might want to disable Nepomuk/Strigi altogether.
+> 
+> You might want to look at
+> http://trueg.wordpress.com/2009/10/22/virtuoso-once-more-with-feeling/
+> for some context information and
+> https://bugs.kde.org/show_bug.cgi?id=246678 or
+> https://bugs.kde.org/show_bug.cgi?id=281653 for bug information.
+[...]
+> > just wondering if there's a good reason for this?
+
+well, i was thinking if it's here by default, there must be a good reason...
+
+but imho it takes way too much resources.
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011628.html b/zarb-ml/mageia-dev/2012-January/011628.html new file mode 100644 index 000000000..9beb5b78e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011628.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] virtuoso-t (nepomuk?) takes too much memory (and CPU) + + + + + + + + + +

[Mageia-dev] virtuoso-t (nepomuk?) takes too much memory (and CPU)

+ Balcaen John + mikala at mageia.org +
+ Sun Jan 29 19:00:41 CET 2012 +

+
+ +
On Sunday 29 January 2012 18:45:18 Maarten Vanraes wrote :
+> Op zaterdag 28 januari 2012 18:56:35 schreef Florian Hubold:
+> > Am 28.01.2012 09:48, schrieb Maarten Vanraes:
+> [...]
+> 
+> > > what does it actually do? is this even needed? and why is it leaking so
+> > > much memory?
+> > 
+> > It's the database backend for Nepomuk, and i assume that it does the
+> > initial indexing of your /home. It does not leak memory, and it's not
+> > really needed,
+> > you might want to disable Nepomuk/Strigi altogether.
+> > 
+> > You might want to look at
+> > http://trueg.wordpress.com/2009/10/22/virtuoso-once-more-with-feeling/
+> > for some context information and
+> > https://bugs.kde.org/show_bug.cgi?id=246678 or
+> > https://bugs.kde.org/show_bug.cgi?id=281653 for bug information.
+> 
+> [...]
+> 
+> > > just wondering if there's a good reason for this?
+> 
+> well, i was thinking if it's here by default, there must be a good reason...
+> 
+> but imho it takes way too much resources.
+Nepomuk (& so virtuoso) is only required by a few packages (like kmail or 
+bangarang for example), so you can of course remove/disable it if you don't 
+want to use 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/2012-January/011629.html b/zarb-ml/mageia-dev/2012-January/011629.html new file mode 100644 index 000000000..74c164e8e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011629.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] virtuoso-t (nepomuk?) takes too much memory (and CPU) + + + + + + + + + +

[Mageia-dev] virtuoso-t (nepomuk?) takes too much memory (and CPU)

+ Maarten Vanraes + alien at rmail.be +
+ Sun Jan 29 19:16:17 CET 2012 +

+
+ +
Op zondag 29 januari 2012 19:00:41 schreef Balcaen John:
+> On Sunday 29 January 2012 18:45:18 Maarten Vanraes wrote :
+> > Op zaterdag 28 januari 2012 18:56:35 schreef Florian Hubold:
+> > > Am 28.01.2012 09:48, schrieb Maarten Vanraes:
+> > [...]
+> > 
+> > > > what does it actually do? is this even needed? and why is it leaking
+> > > > so much memory?
+> > > 
+> > > It's the database backend for Nepomuk, and i assume that it does the
+> > > initial indexing of your /home. It does not leak memory, and it's not
+> > > really needed,
+> > > you might want to disable Nepomuk/Strigi altogether.
+> > > 
+> > > You might want to look at
+> > > http://trueg.wordpress.com/2009/10/22/virtuoso-once-more-with-feeling/
+> > > for some context information and
+> > > https://bugs.kde.org/show_bug.cgi?id=246678 or
+> > > https://bugs.kde.org/show_bug.cgi?id=281653 for bug information.
+> > 
+> > [...]
+> > 
+> > > > just wondering if there's a good reason for this?
+> > 
+> > well, i was thinking if it's here by default, there must be a good
+> > reason...
+> > 
+> > but imho it takes way too much resources.
+> 
+> Nepomuk (& so virtuoso) is only required by a few packages (like kmail or
+> bangarang for example), so you can of course remove/disable it if you don't
+> want to use it.
+> 
+> Regards,
+
+required by kmail?
+
+i use kmail...
+
+if this is somekind of desktop search stuff, i'd like to disable it while still 
+having kmail working...
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011630.html b/zarb-ml/mageia-dev/2012-January/011630.html new file mode 100644 index 000000000..a259bcae1 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011630.html @@ -0,0 +1,81 @@ + + + + [Mageia-dev] Some changes to lang.pm of drakx + + + + + + + + + +

[Mageia-dev] Some changes to lang.pm of drakx

+ Olav Vitters + olav at vitters.nl +
+ Sun Jan 29 21:31:43 CET 2012 +

+
+ +
On Sun, Jan 29, 2012 at 09:50:41PM +0800, You-Cheng Hsieh wrote:
+> - remove chinput, kinput2, oxim, xcin. These ime have no packages in
+> Mageia and are not maintained upstream long ago. So I just comment out
+> their lines.
+> These changes will only affect how users select ime in localedrake.
+
+What happens if users currently have that installed? Will they
+automatically migrate to another IME?
+
+Btw, with version control, just delete. Commenting out is bad IMO.
+
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011631.html b/zarb-ml/mageia-dev/2012-January/011631.html new file mode 100644 index 000000000..ff278e156 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011631.html @@ -0,0 +1,77 @@ + + + + [Mageia-dev] crond was not set to start + + + + + + + + + +

[Mageia-dev] crond was not set to start

+ Olav Vitters + olav at vitters.nl +
+ Sun Jan 29 21:34:46 CET 2012 +

+
+ +
On Sat, Jan 28, 2012 at 09:35:33PM +0000, Colin Guthrie wrote:
+> Yeah, but this is something Olav specifically reckons isn't actually the
+> problem in his case (FWIW, I was talking to dmorgan about it on Friday.
+> I reckon I can fix in the rpm-helper script)
+
+Yeah. Various services were broken after systemd switch. I enabled the
+broken ones. Have been using systemd for a few months at least. Suddenly
+crond broke.
+
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011632.html b/zarb-ml/mageia-dev/2012-January/011632.html new file mode 100644 index 000000000..ac221787f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011632.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] virtuoso-t (nepomuk?) takes too much memory (and CPU) + + + + + + + + + +

[Mageia-dev] virtuoso-t (nepomuk?) takes too much memory (and CPU)

+ Florian Hubold + doktor5000 at arcor.de +
+ Sun Jan 29 21:46:54 CET 2012 +

+
+ +
Am 29.01.2012 19:16, schrieb Maarten Vanraes:
+> Op zondag 29 januari 2012 19:00:41 schreef Balcaen John:
+>> On Sunday 29 January 2012 18:45:18 Maarten Vanraes wrote :
+>>> Op zaterdag 28 januari 2012 18:56:35 schreef Florian Hubold:
+>>>> Am 28.01.2012 09:48, schrieb Maarten Vanraes:
+>>> [...]
+>>>
+>>>>> what does it actually do? is this even needed? and why is it leaking
+>>>>> so much memory?
+>>>> It's the database backend for Nepomuk, and i assume that it does the
+>>>> initial indexing of your /home. It does not leak memory, and it's not
+>>>> really needed,
+>>>> you might want to disable Nepomuk/Strigi altogether.
+^^^^
+>>>> You might want to look at
+>>>> http://trueg.wordpress.com/2009/10/22/virtuoso-once-more-with-feeling/
+>>>> for some context information and
+>>>> https://bugs.kde.org/show_bug.cgi?id=246678 or
+>>>> https://bugs.kde.org/show_bug.cgi?id=281653 for bug information.
+>>> [...]
+>>>
+>>>>> just wondering if there's a good reason for this?
+>>> well, i was thinking if it's here by default, there must be a good
+>>> reason...
+>>>
+>>> but imho it takes way too much resources.
+>> Nepomuk (& so virtuoso) is only required by a few packages (like kmail or
+>> bangarang for example), so you can of course remove/disable it if you don't
+>> want to use it.
+>>
+>> Regards,
+> required by kmail?
+>
+> i use kmail...
+>
+> if this is somekind of desktop search stuff, i'd like to disable it while still 
+> having kmail working...
+Did you read me reply? See above.
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011633.html b/zarb-ml/mageia-dev/2012-January/011633.html new file mode 100644 index 000000000..2b560edec --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011633.html @@ -0,0 +1,72 @@ + + + + [Mageia-dev] Packagers meeting + + + + + + + + + +

[Mageia-dev] Packagers meeting

+ David Walser + luigiwalser at yahoo.com +
+ Mon Jan 30 01:13:25 CET 2012 +

+
+ +
Anne nicolas wrote:
+> Hi there
+> 
+> Could we have our weekly meeting tomorrow, same time, same place? Misc
+> is not available at the moment and I will be in another meeting and
+> late for sure.
+> 
+> For tomorrow's meeting:
+> 
+> - FOSDEM reminder
+> - isos content: define DVD iso content
+> - Define focus until end of Mageia 2 development cycle
+
+I skimmed the IRC log of the meeting and there was a lot of discussion on this last point.  It looked like there is definitely a set of 
+specific things you would like packagers to focus on between now and release, most of them with supporting URLs.  It would be nice if someone 
+would summarize with a "your mission should you choose to accept it" type post to mageia-dev with a summary and links.
+
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011634.html b/zarb-ml/mageia-dev/2012-January/011634.html new file mode 100644 index 000000000..127330f62 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011634.html @@ -0,0 +1,78 @@ + + + + [Mageia-dev] Some changes to lang.pm of drakx + + + + + + + + + +

[Mageia-dev] Some changes to lang.pm of drakx

+ You-Cheng Hsieh + yochenhsieh at gmail.com +
+ Mon Jan 30 01:57:56 CET 2012 +

+
+ +
2012/1/30 Olav Vitters <olav at vitters.nl>:
+> On Sun, Jan 29, 2012 at 09:50:41PM +0800, You-Cheng Hsieh wrote:
+>> - remove chinput, kinput2, oxim, xcin. These ime have no packages in
+>> Mageia and are not maintained upstream long ago. So I just comment out
+>> their lines.
+>> These changes will only affect how users select ime in localedrake.
+>
+> What happens if users currently have that installed? Will they
+> automatically migrate to another IME?
+If you mean users migrated from Mandriva and with old IME installed,
+nothing will happend to them. Only after they run localedrake and they
+will have to select other supported IME instead.
+
+> Btw, with version control, just delete. Commenting out is bad IMO.
+Thanks. I will do that next time.
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011635.html b/zarb-ml/mageia-dev/2012-January/011635.html new file mode 100644 index 000000000..524e092cf --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011635.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release fprint-demo-0.4-6.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release fprint-demo-0.4-6.mga2

+ Anssi Hannula + anssi at mageia.org +
+ Mon Jan 30 03:30:13 CET 2012 +

+
+ +
On 30.01.2012 02:11, malo wrote:
+> Name        : fprint-demo                  Relocations: (not relocatable)
+> Version     : 0.4                               Vendor: Mageia.Org
+> Release     : 6.mga2                        Build Date: Mon Jan 30 01:09:12 2012
+> Install Date: (not installed)               Build Host: jonund
+> Group       : System/Configuration/Other    Source RPM: (none)
+> Size        : 23325                            License: GPLv2
+> Signature   : (none)
+> Packager    : malo <malo>
+> URL         : http://www.freedesktop.org/wiki/Software/fprint/fprint_demo
+> Summary     : Simple GTK+ application to demonstrate and test libfprint's capabilities
+> Description :
+> fprint_demo is a simple GTK+ application to demonstrate and test libfprint's
+> capabilities. It is written in C and licensed under the GNU GPL v2.
+> 
+> It provides access to many of the features offered by the backing library,
+> libfprint.
+> 
+> malo <malo> 0.4-6.mga2:
+> + Revision: 203150
+> - Bump release after renaming the package.
+> - Renaming into fprint-demo since '_' is not allowed.
+> - renaming fprint_demo in fprint-demo since '_' is not allowed
+
+1. IMO fprint_demo would be a better name for the package since that is
+AFAICS the name of the software and binary, not fprint-demo.
+
+2. Double changelog entry, please drop one of them.
+
+3. Please use a properly named tarball instead of "v0.4", this also
+confused mgarepo so it uploaded it to SVN instead of binrepo.
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011636.html b/zarb-ml/mageia-dev/2012-January/011636.html new file mode 100644 index 000000000..290f7f33b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011636.html @@ -0,0 +1,75 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release fprint-demo-0.4-6.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release fprint-demo-0.4-6.mga2

+ Kamil Rytarowski + n54 at gmx.com +
+ Mon Jan 30 04:04:24 CET 2012 +

+
+ +
W dniu 30.01.2012 03:30, Anssi Hannula pisze:
+> On 30.01.2012 02:11, malo wrote:
+>> malo<malo>  0.4-6.mga2:
+>> + Revision: 203150
+>> - Bump release after renaming the package.
+>> - Renaming into fprint-demo since '_' is not allowed.
+>> - renaming fprint_demo in fprint-demo since '_' is not allowed
+> 1. IMO fprint_demo would be a better name for the package since that is
+> AFAICS the name of the software and binary, not fprint-demo.
+But it's still used just as a delimeter.
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011637.html b/zarb-ml/mageia-dev/2012-January/011637.html new file mode 100644 index 000000000..c9a687e3d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011637.html @@ -0,0 +1,81 @@ + + + + [Mageia-dev] virtuoso-t (nepomuk?) takes too much memory (and CPU) + + + + + + + + + +

[Mageia-dev] virtuoso-t (nepomuk?) takes too much memory (and CPU)

+ Maarten Vanraes + alien at rmail.be +
+ Mon Jan 30 08:32:20 CET 2012 +

+
+ +
Op zondag 29 januari 2012 21:46:54 schreef Florian Hubold:
+> Am 29.01.2012 19:16, schrieb Maarten Vanraes:
+> > Op zondag 29 januari 2012 19:00:41 schreef Balcaen John:
+[..]
+> >> Nepomuk (& so virtuoso) is only required by a few packages (like kmail
+> >> or bangarang for example), so you can of course remove/disable it if
+> >> you don't want to use it.
+> >> 
+> >> Regards,
+> > 
+> > required by kmail?
+> > 
+> > i use kmail...
+> > 
+> > if this is somekind of desktop search stuff, i'd like to disable it while
+> > still having kmail working...
+> 
+> Did you read me reply? See above.
+
+reply said it was needed for kmail. can i really disable this and still have 
+functional kmail?
+
+and how? iirc there was suddenly this icon about desktop search? I assume 
+that's it? i removed the applet, but i guess it didn't stop. how can i stop 
+this permanently? without also disabling kmail to work?
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011638.html b/zarb-ml/mageia-dev/2012-January/011638.html new file mode 100644 index 000000000..00a913555 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011638.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] virtuoso-t (nepomuk?) takes too much memory (and CPU) + + + + + + + + + +

[Mageia-dev] virtuoso-t (nepomuk?) takes too much memory (and CPU)

+ Florian Hubold + doktor5000 at arcor.de +
+ Mon Jan 30 10:32:35 CET 2012 +

+
+ +
Am 30.01.2012 08:32, schrieb Maarten Vanraes:
+> Op zondag 29 januari 2012 21:46:54 schreef Florian Hubold:
+>> Am 29.01.2012 19:16, schrieb Maarten Vanraes:
+>>> Op zondag 29 januari 2012 19:00:41 schreef Balcaen John:
+> [..]
+>>>> Nepomuk (& so virtuoso) is only required by a few packages (like kmail
+>>>> or bangarang for example), so you can of course remove/disable it if
+>>>> you don't want to use it.
+>>>>
+>>>> Regards,
+>>> required by kmail?
+>>>
+>>> i use kmail...
+>>>
+>>> if this is somekind of desktop search stuff, i'd like to disable it while
+>>> still having kmail working...
+>> Did you read me reply? See above.
+> reply said it was needed for kmail. can i really disable this and still have 
+> functional kmail?
+>
+> and how? iirc there was suddenly this icon about desktop search? I assume 
+> that's it? i removed the applet, but i guess it didn't stop. how can i stop 
+> this permanently? without also disabling kmail to work?
+>
+That was mikala's reply. Maybe you should ask him, i'm not really helpful
+because i don't use either one of kmail, akonadi, nepomuk or strigi.
+You should be able to disable strigi (index & search daemon) and the indexing
+of nepomuk, but i'm not sure about nepomuk itself. From what i've read,
+it can't be completely disabled as since recently many kde features
+depend on it.
+
+You still might want to look at f.ex.
+http://thomasmcguire.wordpress.com/2009/10/03/akonadi-nepomuk-and-strigi-explained/
+for what's what of Soprano, Virtuoso, Nepomuk, Strigi and Akonadi.
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011639.html b/zarb-ml/mageia-dev/2012-January/011639.html new file mode 100644 index 000000000..756c16ea1 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011639.html @@ -0,0 +1,77 @@ + + + + [Mageia-dev] virtuoso-t (nepomuk?) takes too much memory (and CPU) + + + + + + + + + +

[Mageia-dev] virtuoso-t (nepomuk?) takes too much memory (and CPU)

+ Balcaen John + mikala at mageia.org +
+ Mon Jan 30 11:08:25 CET 2012 +

+
+ +
On Monday 30 January 2012 08:32:20 Maarten Vanraes wrote :
+[...]
+> 
+> reply said it was needed for kmail. can i really disable this and still have
+> functional kmail?
+You can disable it, you'll miss (at least from the shiny yellow banner you're 
+getting in kmail) autocompletion for contact, lists support & cryptographic 
+options per user but maybe it's more than that i don't know.
+
+> and how?
+> iirc there was suddenly this icon about desktop search? I assume
+> that's it? i removed the applet, but i guess it didn't stop. how can i stop
+> this permanently? without also disabling kmail to work?
+You can use systemsettings to configure/(dis)enable the desktop search function 
+(also know as nepomuk :p ).
+
+
+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/2012-January/011640.html b/zarb-ml/mageia-dev/2012-January/011640.html new file mode 100644 index 000000000..657a93b1f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011640.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] virtuoso-t (nepomuk?) takes too much memory (and CPU) + + + + + + + + + +

[Mageia-dev] virtuoso-t (nepomuk?) takes too much memory (and CPU)

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Mon Jan 30 12:48:18 CET 2012 +

+
+ +
> On Monday 30 January 2012 08:32:20 Maarten Vanraes wrote :
+> [...]
+>>
+>> reply said it was needed for kmail. can i really disable this and still
+>> have
+>> functional kmail?
+> You can disable it, you'll miss (at least from the shiny yellow banner
+> you're
+> getting in kmail) autocompletion for contact, lists support &
+> cryptographic
+> options per user but maybe it's more than that i don't know.
+
+hmm, i like these functions. this is why i asked, because i like these
+functions, but still, even when it's been configured by default as using
+50MB, it's over 200MB, and using all these resources.
+
+is this fixable? looking at those bug reports, it looks like this has been
+going on for a while now...
+
+>> and how?
+>> iirc there was suddenly this icon about desktop search? I assume
+>> that's it? i removed the applet, but i guess it didn't stop. how can i
+>> stop
+>> this permanently? without also disabling kmail to work?
+> You can use systemsettings to configure/(dis)enable the desktop search
+> function
+> (also know as nepomuk :p ).
+
+disabling this desktop search does not have effect on the kmail?
+
+i would guess not from how you put it, but i'm just asking for
+confirmation here :-)
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011641.html b/zarb-ml/mageia-dev/2012-January/011641.html new file mode 100644 index 000000000..100cb483e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011641.html @@ -0,0 +1,79 @@ + + + + [Mageia-dev] virtuoso-t (nepomuk?) takes too much memory (and CPU) + + + + + + + + + +

[Mageia-dev] virtuoso-t (nepomuk?) takes too much memory (and CPU)

+ Balcaen John + mikala at mageia.org +
+ Mon Jan 30 14:50:11 CET 2012 +

+
+ +
On Monday 30 January 2012 12:48:18 Maarten Vanraes wrote :
+[...]
+> 
+> is this fixable? looking at those bug reports, it looks like this has been
+> going on for a while now...
+Well until upstream fix it i guess we're stuck with it :/
+[...]
+> 
+> disabling this desktop search does not have effect on the kmail?
+> 
+> i would guess not from how you put it, but i'm just asking for
+> confirmation here :-)
+If you disable desktop search it won't work in kmail.
+Also i'm not sure if it's fixed but if i'm not wrong the « disable kmail index 
+» functionnality does not work (even if it's supposed to be disable it's going 
+to work...)
+
+
+
+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/2012-January/011642.html b/zarb-ml/mageia-dev/2012-January/011642.html new file mode 100644 index 000000000..4d1a7701f --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011642.html @@ -0,0 +1,83 @@ + + + + [Mageia-dev] crond was not set to start + + + + + + + + + +

[Mageia-dev] crond was not set to start

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Mon Jan 30 15:52:34 CET 2012 +

+
+ +
'Twas brillig, and Olav Vitters at 29/01/12 20:34 did gyre and gimble:
+> Yeah. Various services were broken after systemd switch. I enabled the
+> broken ones. Have been using systemd for a few months at least. Suddenly
+> crond broke.
+
+I wonder if it suddenly got a native system unit rather than going via
+sysvinit compatibility? That would have this kind of behaviour (assuming
+it didn't break after the initial switch to systemd).
+
+This is one of the cases I'm going to have to look at in the rpm-helper
+scripts, but it should be doable.
+
+Col
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011643.html b/zarb-ml/mageia-dev/2012-January/011643.html new file mode 100644 index 000000000..43e788a49 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011643.html @@ -0,0 +1,75 @@ + + + + [Mageia-dev] stardict 3.0.3 + + + + + + + + + +

[Mageia-dev] stardict 3.0.3

+ Kamil Rytarowski + n54 at gmx.com +
+ Mon Jan 30 17:55:33 CET 2012 +

+
+ +
Hello!
+
+W dniu 30.01.2012 14:33, Funda Wang pisze:
+> Personally, i'm in favour of dropping it, due to what is said in its homepage:
+> StarDict hasn't seen any active development for many years
+Well it's worth to consider importing goldentict too, but I'm against 
+dropping stardict - it's actually alive and people keep porting it to 
+GTK3. https://code.google.com/p/stardict-3/updates/list
+> 2012/1/30 Kamil Rytarowski<n54 at gmx.com>:
+>> Hello!
+>>
+>> Thanks for fixing stardict! I had problems with mirrors and temporarely
+>> wasn't able to fix the glib.h headers locally.
+
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011644.html b/zarb-ml/mageia-dev/2012-January/011644.html new file mode 100644 index 000000000..cd9e88686 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011644.html @@ -0,0 +1,81 @@ + + + + [Mageia-dev] sudo security update + + + + + + + + + +

[Mageia-dev] sudo security update

+ nicolas vigier + boklm at mars-attacks.org +
+ Mon Jan 30 19:31:01 CET 2012 +

+
+ +
Hello,
+
+If you are using sudo on Mageia 1 or Cauldron, don't forget to update
+the package to the latest version available in updates (1.8.0-5.mga1) or
+Cauldron (sudo-1.8.3p2-1.mga2).
+
+It fix this vulnerability which can allow a user to run arbitrary
+commands as root :
+http://www.sudo.ws/sudo/alerts/sudo_debug.html
+
+
+ + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011645.html b/zarb-ml/mageia-dev/2012-January/011645.html new file mode 100644 index 000000000..312fb5a26 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011645.html @@ -0,0 +1,122 @@ + + + + [Mageia-dev] RFC Package Naming Policy + + + + + + + + + +

[Mageia-dev] RFC Package Naming Policy

+ Pierre-Malo Deniélou + malo at doc.ic.ac.uk +
+ Mon Jan 30 19:24:44 CET 2012 +

+
+ +
Dear all,
+
+Following some recent mix-up, some possible ambiguity was found in the 
+current policy with respect to package naming (as seen in 
+https://wiki.mageia.org/en/Packaging_guidelines#Package_Naming).
+
+----------------------------------------------------------------------
+So currently it is written:
+«* Name should be the upstream name of the software project, always 
+lowercase.
+* When the package name is different to the project name, you should 
+define and use %{upstream_name} macro to refer to the original project 
+name within the spec
+* ''Dash '-' must be used as the delimiter for name parts.''
+* ''Do NOT use an underscore '_', a plus '+', or a period '.' as a 
+delimiter.''
+* The spec file should be named using the %{name}.spec scheme, i.e. the 
+name of the package should be used as the name for the spec.»
+
+I propose to change it to the following:
+
+«* The base package names (used for svn and src.rpm) should be the 
+upstream name of the software project, always lowercase. Upstream names 
+can contain digits, '+', '_' or '.', but no other special characters. 
+Really exceptionally, uppercase letters can be allowed if there is 
+proper justification or historical reasons.
+* Package names that are built by Mageia packagers from the upstream 
+name by adding suffixes should always use '-' as delimiter (e.g. 
+foo-devel or foo-plugins as derived from the foo package). All '_' and 
+'+' in package names must come from upstream naming! The '.' in package 
+names should only come upstream or standard versioning schemes.
+* The spec file should be named using the %{name}.spec scheme, i.e. the 
+name of the source package and svn directory should be used as the name 
+for the spec.»
+
+---------------------------------------------------------------------
+Some of you may notice that the newly drafted policy allows upper-case 
+letters in packages as an exception (when justified). This is to follow 
+the current practice (which is not following the current policy, where 
+we have packages like R-base).
+I don't want to raise a heated discussion (there was an inconclusive 
+discussion a long time ago on cooker [*]) about enforcing an all 
+lower-case policy. Not sure a consensus can be reached today, but 
+lower-casing package names should be the default for 99% of the packages 
+in Mageia.
+
+Any comments? Is it indeed clearer this way? Any other conditions on 
+package names we should add?
+
+Best regards,
+-- 
+Malo
+
+[*] http://lists.mandriva.com/cooker/2006-03/msg03396.php
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011646.html b/zarb-ml/mageia-dev/2012-January/011646.html new file mode 100644 index 000000000..bc5ce3a5b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011646.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] RFC Package Naming Policy + + + + + + + + + +

[Mageia-dev] RFC Package Naming Policy

+ Jerome Quelin + jquelin at gmail.com +
+ Mon Jan 30 20:15:49 CET 2012 +

+
+ +
On 12/01/30 18:24 +0000, Pierre-Malo Deniélou wrote:
+> Some of you may notice that the newly drafted policy allows
+> upper-case letters in packages as an exception (when justified).
+> This is to follow the current practice (which is not following the
+> current policy, where we have packages like R-base).
+> I don't want to raise a heated discussion (there was an inconclusive
+> discussion a long time ago on cooker [*]) about enforcing an all
+> lower-case policy. Not sure a consensus can be reached today, but
+> lower-casing package names should be the default for 99% of the
+> packages in Mageia.
+
+except it cannot be. perl module Foo::Bar is shipped in package
+perl-Foo-Bar since quite a lot of time, per policy. so the ~2500 perl
+packages are almost all using some upper-case, which make your 99%
+figure totally wrong (2500 / 10000 = ~25% using upper case)
+
+note that perl packages shipping an application or a script useful on
+their own do follow the policy and are called eg perlbrew, nopaste,
+grok, etc.
+
+sorry to disappoint you,
+jérôme 
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011647.html b/zarb-ml/mageia-dev/2012-January/011647.html new file mode 100644 index 000000000..297e5b193 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011647.html @@ -0,0 +1,78 @@ + + + + [Mageia-dev] virtuoso-t (nepomuk?) takes too much memory (and CPU) + + + + + + + + + +

[Mageia-dev] virtuoso-t (nepomuk?) takes too much memory (and CPU)

+ Maarten Vanraes + alien at rmail.be +
+ Mon Jan 30 20:14:47 CET 2012 +

+
+ +
Op maandag 30 januari 2012 14:50:11 schreef Balcaen John:
+> On Monday 30 January 2012 12:48:18 Maarten Vanraes wrote :
+> [...]
+> 
+> > is this fixable? looking at those bug reports, it looks like this has
+> > been going on for a while now...
+> 
+> Well until upstream fix it i guess we're stuck with it :/
+
+Well, thanks for the info at least...
+
+> > disabling this desktop search does not have effect on the kmail?
+> > 
+> > i would guess not from how you put it, but i'm just asking for
+> > confirmation here :-)
+> 
+> If you disable desktop search it won't work in kmail.
+> Also i'm not sure if it's fixed but if i'm not wrong the « disable kmail
+> index » functionnality does not work (even if it's supposed to be disable
+> it's going to work...)
+
+/me facepalms...
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011648.html b/zarb-ml/mageia-dev/2012-January/011648.html new file mode 100644 index 000000000..7b4eb77ee --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011648.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] stardict 3.0.3 + + + + + + + + + +

[Mageia-dev] stardict 3.0.3

+ Claire Revillet + grenoya at zarb.org +
+ Mon Jan 30 20:53:45 CET 2012 +

+
+ +
Le 30/01/2012 17:55, Kamil Rytarowski a écrit :
+> Hello!
+>
+> W dniu 30.01.2012 14:33, Funda Wang pisze:
+>> Personally, i'm in favour of dropping it, due to what is said in its 
+>> homepage:
+>> StarDict hasn't seen any active development for many years
+> Well it's worth to consider importing goldentict too, but I'm against 
+> dropping stardict - it's actually alive and people keep porting it to 
+> GTK3. https://code.google.com/p/stardict-3/updates/list
+Hi
+
+What about asking his (her) opinion to the maintainer *before* upgrading 
+it to the "new" version ?
+
+********
+
+   + kamil<kamil>
+     - new versdion 3.0.3
+     - disable all patches, they seem merged
+     - update URL
+     - update SOURCE
+**********
+
+As the maintainer, it was to me to take the decision to upgrade or propose something else for mageia.
+
+You have the right to ask me what I want to do with it and to expose your opinion. But next time, ask the maintainer before ! There was no bugreport open for stardict, so no emergency to touch this package.
+
+And in case you are no aware of the fact we have a database for maintainership :
+mgarepo maintdb get<package_name>
+do the trick.
+
+Claire
+
+
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011649.html b/zarb-ml/mageia-dev/2012-January/011649.html new file mode 100644 index 000000000..33ff17637 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011649.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] stardict 3.0.3 + + + + + + + + + +

[Mageia-dev] stardict 3.0.3

+ Michael Scherer + misc at zarb.org +
+ Mon Jan 30 21:14:09 CET 2012 +

+
+ +
Le lundi 30 janvier 2012 à 20:53 +0100, Claire Revillet a écrit :
+> Le 30/01/2012 17:55, Kamil Rytarowski a écrit :
+> > Hello!
+> >
+> > W dniu 30.01.2012 14:33, Funda Wang pisze:
+> >> Personally, i'm in favour of dropping it, due to what is said in its 
+> >> homepage:
+> >> StarDict hasn't seen any active development for many years
+> > Well it's worth to consider importing goldentict too, but I'm against 
+> > dropping stardict - it's actually alive and people keep porting it to 
+> > GTK3. https://code.google.com/p/stardict-3/updates/list
+> Hi
+> 
+> What about asking his (her) opinion to the maintainer *before* upgrading 
+> it to the "new" version ?
+>
+> ********
+> 
+>    + kamil<kamil>
+>      - new versdion 3.0.3
+>      - disable all patches, they seem merged
+>      - update URL
+>      - update SOURCE
+> **********
+> 
+> As the maintainer, it was to me to take the decision to upgrade or propose something else for mageia.
+
+So as the maintainer, can you explain to us why you did not warn us of
+the copyright problem that we can see since 07/2011 on 
+http://stardict.sourceforge.net/
+
+-- 
+Michael Scherer
+
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011650.html b/zarb-ml/mageia-dev/2012-January/011650.html new file mode 100644 index 000000000..9727424e5 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011650.html @@ -0,0 +1,114 @@ + + + + [Mageia-dev] stardict 3.0.3 + + + + + + + + + +

[Mageia-dev] stardict 3.0.3

+ Kamil Rytarowski + n54 at gmx.com +
+ Mon Jan 30 21:20:13 CET 2012 +

+
+ +
W dniu 30.01.2012 20:53, Claire Revillet pisze:
+> Le 30/01/2012 17:55, Kamil Rytarowski a écrit :
+>> Hello!
+>>
+>> W dniu 30.01.2012 14:33, Funda Wang pisze:
+>>> Personally, i'm in favour of dropping it, due to what is said in its 
+>>> homepage:
+>>> StarDict hasn't seen any active development for many years
+>> Well it's worth to consider importing goldentict too, but I'm against 
+>> dropping stardict - it's actually alive and people keep porting it to 
+>> GTK3. https://code.google.com/p/stardict-3/updates/list
+> Hi
+>
+> What about asking his (her) opinion to the maintainer *before* 
+> upgrading it to the "new" version ?
+>
+> ********
+>
+>   + kamil<kamil>
+>     - new versdion 3.0.3
+>     - disable all patches, they seem merged
+>     - update URL
+>     - update SOURCE
+> **********
+>
+> As the maintainer, it was to me to take the decision to upgrade or 
+> propose something else for mageia.
+Hi Claire!
+
+I keep updating URLs and SOURCEs - the initial bug-request was there 
+https://bugs.mageia.org/show_bug.cgi?id=3035 (I have reviewed initially 
+2,500 source-packages).
+>
+> You have the right to ask me what I want to do with it and to expose 
+> your opinion. But next time, ask the maintainer before ! There was no 
+> bugreport open for stardict, so no emergency to touch this package.
+>
+> And in case you are no aware of the fact we have a database for 
+> maintainership :
+> mgarepo maintdb get<package_name>
+> do the trick.
+I was informed that this mostly means that you are responsible for 
+decisions what to do in future with a package, and you are ready to be 
+assigned in a bug-request etc.
+
+So what do you think about the future of StarDICT? I was looking at the 
+projects and I'm a little bit affraid of the licenses and patents. For 
+example GoldenDict is said to support Babylon - and this can be 
+problematic with patents.
+
+Have you reviewed the dicts if they are legally used?
+>
+> Claire
+>
+>
+
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011651.html b/zarb-ml/mageia-dev/2012-January/011651.html new file mode 100644 index 000000000..9aaf27cfa --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011651.html @@ -0,0 +1,68 @@ + + + + [Mageia-dev] virtuoso-t (nepomuk?) takes too much memory (and CPU) + + + + + + + + + +

[Mageia-dev] virtuoso-t (nepomuk?) takes too much memory (and CPU)

+ Balcaen John + mikala at mageia.org +
+ Mon Jan 30 21:53:16 CET 2012 +

+
+ +
On Monday 30 January 2012 20:14:47 Maarten Vanraes wrote :
+[...]
+> 
+> /me facepalms...
+
+You can read this thread if you want 
+http://lists.kde.org/?l=kde-pim&m=132769144326703&w=2
+
+
+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/2012-January/011652.html b/zarb-ml/mageia-dev/2012-January/011652.html new file mode 100644 index 000000000..55c8e0369 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011652.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] RFC Package Naming Policy + + + + + + + + + +

[Mageia-dev] RFC Package Naming Policy

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Mon Jan 30 21:58:11 CET 2012 +

+
+ +
On 30 January 2012 20:15, Jerome Quelin <jquelin at gmail.com> wrote:
+>> Some of you may notice that the newly drafted policy allows
+>> upper-case letters in packages as an exception (when justified).
+>> This is to follow the current practice (which is not following the
+>> current policy, where we have packages like R-base).
+>> I don't want to raise a heated discussion (there was an inconclusive
+>> discussion a long time ago on cooker [*]) about enforcing an all
+>> lower-case policy. Not sure a consensus can be reached today, but
+>> lower-casing package names should be the default for 99% of the
+>> packages in Mageia.
+>
+> except it cannot be. perl module Foo::Bar is shipped in package
+> perl-Foo-Bar since quite a lot of time, per policy. so the ~2500 perl
+> packages are almost all using some upper-case, which make your 99%
+> figure totally wrong (2500 / 10000 = ~25% using upper case)
+>
+> note that perl packages shipping an application or a script useful on
+> their own do follow the policy and are called eg perlbrew, nopaste,
+> grok, etc.
+
+Well, the low case names policy did was a policy for years.
+We slowly killed most upcase names over the years, perl being an
+exception.
+I think we should enforce it modulo perl
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011653.html b/zarb-ml/mageia-dev/2012-January/011653.html new file mode 100644 index 000000000..d95628a38 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011653.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] stardict 3.0.3 + + + + + + + + + +

[Mageia-dev] stardict 3.0.3

+ Claire Revillet + grenoya at zarb.org +
+ Mon Jan 30 22:31:28 CET 2012 +

+
+ +
+> I keep updating URLs and SOURCEs - the initial bug-request was there 
+> https://bugs.mageia.org/show_bug.cgi?id=3035 (I have reviewed 
+> initially 2,500 source-packages).
+1) stardict does not appear in the list
+2) why maintainers are not been contacted for all those problems ?
+
+
+> So what do you think about the future of StarDICT? I was looking at 
+> the projects and I'm a little bit affraid of the licenses and patents. 
+> For example GoldenDict is said to support Babylon - and this can be 
+> problematic with patents.
+>
+For me StarDict is a dead project and I was looking for a successor.
+There is no information on the "copyright infringement" and the tarball 
+that can be downloaded on the new site are exactly the same as the old 
+ones !
+So the first possibility is: there was truly a copyright problem and 
+there is still (this may be proved in the future if the copyright owner 
+ask to close again the project) ; second possibility: there was no 
+copyright problem (but a more obscure one), but, still, the project is 
+not very active.
+
+So if GoldenDict present, at this time, no license or patent problem and 
+is actively developed : it can be a better choice.
+Import freeze for mageia 2 will be in march, so I think we have a little 
+time to think about it to choose the best solution for mageia 2 and test 
+it (bugs...) before release.
+Let's take the week for discussion.
+
+> you reviewed the dicts if they are legally used?
+I checked for almost all dict : they are GPL or "Creative Commons 
+Attribution-ShareAlike Licence (V3.0)". Just 1 as to be modified 
+(quick-deu-eng) or simply removed. I'll do that in the week.
+I think url information may not be good, but I did not see the point of 
+rebuilding 200 packages just for that (taking into account the fact that 
+dictionaries are not code : they do not evolve).
+
+Claire
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011654.html b/zarb-ml/mageia-dev/2012-January/011654.html new file mode 100644 index 000000000..c51f3a07c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011654.html @@ -0,0 +1,69 @@ + + + + [Mageia-dev] stardict 3.0.3 + + + + + + + + + +

[Mageia-dev] stardict 3.0.3

+ Claire Revillet + grenoya at zarb.org +
+ Mon Jan 30 22:43:16 CET 2012 +

+
+ +
Le 30/01/2012 22:31, Claire Revillet a écrit :
+>
+>> I keep updating URLs and SOURCEs - the initial bug-request was there 
+>> https://bugs.mageia.org/show_bug.cgi?id=3035 (I have reviewed 
+>> initially 2,500 source-packages).
+> 1) stardict does not appear in the list
+> 2) why maintainers are not been contacted for all those problems ?
+>
+3) if your point was just to fix bad URLs, why upgrading ?
+>
+> Claire
+
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011655.html b/zarb-ml/mageia-dev/2012-January/011655.html new file mode 100644 index 000000000..de52d7ca1 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011655.html @@ -0,0 +1,70 @@ + + + + [Mageia-dev] stardict 3.0.3 + + + + + + + + + +

[Mageia-dev] stardict 3.0.3

+ Funda Wang + fundawang at gmail.com +
+ Mon Jan 30 22:50:29 CET 2012 +

+
+ +
2012/1/31 Claire Revillet <grenoya at zarb.org>:
+> For me StarDict is a dead project and I was looking for a successor.
+> There is no information on the "copyright infringement" and the tarball that
+> can be downloaded on the new site are exactly the same as the old ones !
+> So the first possibility is: there was truly a copyright problem and there
+> is still (this may be proved in the future if the copyright owner ask to
+> close again the project) ; second possibility: there was no copyright
+> problem (but a more obscure one), but, still, the project is not very
+> active.
+I think there is no copyright problem with the stardict the program
+itself, only the data files (dictionaries). But the author has been
+missing for half a year:
+http://goldendict.org/forum/viewtopic.php?f=4&t=1109
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011656.html b/zarb-ml/mageia-dev/2012-January/011656.html new file mode 100644 index 000000000..52b348ab5 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011656.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] stardict 3.0.3 + + + + + + + + + +

[Mageia-dev] stardict 3.0.3

+ Claire Revillet + grenoya at zarb.org +
+ Mon Jan 30 22:56:51 CET 2012 +

+
+ +
Le 30/01/2012 22:50, Funda Wang a écrit :
+> 2012/1/31 Claire Revillet<grenoya at zarb.org>:
+>> For me StarDict is a dead project and I was looking for a successor.
+>> There is no information on the "copyright infringement" and the tarball that
+>> can be downloaded on the new site are exactly the same as the old ones !
+>> So the first possibility is: there was truly a copyright problem and there
+>> is still (this may be proved in the future if the copyright owner ask to
+>> close again the project) ; second possibility: there was no copyright
+>> problem (but a more obscure one), but, still, the project is not very
+>> active.
+> I think there is no copyright problem with the stardict the program
+> itself, only the data files (dictionaries). But the author has been
+> missing for half a year:
+> http://goldendict.org/forum/viewtopic.php?f=4&t=1109
+It's also what I think : no really copyright pb with the code (and yes, 
+I had seen link :\ ).
+I don't think the problem is with the dict, because the pages with all 
+the dict are still there :
+http://abloz.com/huzheng/stardict-dic/
+(and easy to find).
+
+So, for me, dict are okay. But if the new dev is not really active, it 
+is a good time to change the software for the distribution.
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011657.html b/zarb-ml/mageia-dev/2012-January/011657.html new file mode 100644 index 000000000..505976dca --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011657.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] Servers downtime scheduled from Feb. 1 to 2 for maintenance + + + + + + + + + +

[Mageia-dev] Servers downtime scheduled from Feb. 1 to 2 for maintenance

+ Romain d'Alverny + rdalverny at gmail.com +
+ Mon Jan 30 23:19:02 CET 2012 +

+
+ +
Hello everyone,
+
+some Mageia servers will be down from Wednesday Feb. 1st to Thursday
+Feb. 2nd for maintenance. Particularly, the following services will be
+unavailable:
+- our LDAP/user identity db,
+- build system,
+- Bugzilla,
+- all mailing-lists hosted on ml.mageia.org,
+- Wiki,
+- forums.
+
+So... not all, but, a lot of what you use here! The exact hours of
+interruption are not known, so expect no availability for those 2 full
+days.
+
+Blog (where an equivalent warning will be posted), Web site,
+mailing-lists (and archives) will not be down.
+
+In the meantime, in our Marseille data center, 4 of our sysadmin team
+(dams, boklm, rtp and misc in this case) will do nothing less than:
+ - upgrade servers to Mageia 1,
+ - replace broken HDD,
+ - add SSD in build nodes,
+ - install our ARM build system,
+ - install a dedicated server for backups,
+ - install a dedicated server for QA and packagers.
+
+All hardware purchased thanks to what Mageia.Org received from so many
+donators (http://mageia.org/en/thank-you/ again).
+
+This is quite a short notice, we apologize for this. Thank you for
+your comprehension (and please spread the info to your list/team if
+relevant).
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011658.html b/zarb-ml/mageia-dev/2012-January/011658.html new file mode 100644 index 000000000..cd24c943b --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011658.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] stardict 3.0.3 + + + + + + + + + +

[Mageia-dev] stardict 3.0.3

+ Michael Scherer + misc at zarb.org +
+ Mon Jan 30 23:29:31 CET 2012 +

+
+ +
Le lundi 30 janvier 2012 à 22:56 +0100, Claire Revillet a écrit :
+> Le 30/01/2012 22:50, Funda Wang a écrit :
+> > 2012/1/31 Claire Revillet<grenoya at zarb.org>:
+> >> For me StarDict is a dead project and I was looking for a successor.
+> >> There is no information on the "copyright infringement" and the tarball that
+> >> can be downloaded on the new site are exactly the same as the old ones !
+> >> So the first possibility is: there was truly a copyright problem and there
+> >> is still (this may be proved in the future if the copyright owner ask to
+> >> close again the project) ; second possibility: there was no copyright
+> >> problem (but a more obscure one), but, still, the project is not very
+> >> active.
+> > I think there is no copyright problem with the stardict the program
+> > itself, only the data files (dictionaries). But the author has been
+> > missing for half a year:
+> > http://goldendict.org/forum/viewtopic.php?f=4&t=1109
+> It's also what I think : no really copyright pb with the code (and yes, 
+> I had seen link :\ ).
+
+Unfortunately, that's not really the opinion of the sourceforge lawyers.
+
+I assume that since you didn't warn us of a problem during the 6 months
+that you at least took the initiative as a maintainer to contact
+sourceforge.net, and that you received a answer letting you safely to
+dismiss their analysis. 
+So can you share the answer, and/or the analysis ?
+
+Because I think that if we have a special treatement for patents and
+DMCA despites having legal protections ( safe harbor laws in the USAs,
+for example ) for mirrors, we should at least be as vigilant for
+copyright violation when there is no such provision and much stricter
+laws ( per various treaty ), as we all know given the current events.
+
+-- 
+Michael Scherer
+
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011659.html b/zarb-ml/mageia-dev/2012-January/011659.html new file mode 100644 index 000000000..08ab81456 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011659.html @@ -0,0 +1,262 @@ + + + + [Mageia-dev] Media mounting broken + + + + + + + + + +

[Mageia-dev] Media mounting broken

+ JA Magallón + jamagallon at ono.com +
+ Tue Jan 31 10:28:07 CET 2012 +

+
+ +
Hi all...
+
+Since some time ago, automounting of media (USB, CD) seems gone nuts.
+How can I debug this ?
+First of all, I have udisks2 installed, not udisks, even if the later
+is also in the repos. I suppose newer version supersedes it, as it is
+required by gnome-disk-utility (formerly palimpsest).
+
+For example, when inserting a USB thumb drive, udev seems to catch it:
+
+werewolf:~# udevadm monitor
+monitor will print the received events for:
+UDEV - the event which udev sends out after rule processing
+KERNEL - the kernel uevent
+
+KERNEL[8140.437415] add      /devices/pci0000:00/0000:00:1a.7/usb7/7-4 (usb)
+KERNEL[8140.437527] add      /devices/pci0000:00/0000:00:1a.7/usb7/7-4/7-4:1.0 (usb)
+KERNEL[8140.437682] add      /devices/pci0000:00/0000:00:1a.7/usb7/7-4/7-4:1.0/host17 (scsi)
+KERNEL[8140.437767] add      /devices/pci0000:00/0000:00:1a.7/usb7/7-4/7-4:1.0/host17/scsi_host/host17 (scsi_host)
+UDEV  [8140.444785] add      /devices/pci0000:00/0000:00:1a.7/usb7/7-4 (usb)
+UDEV  [8140.449742] add      /devices/pci0000:00/0000:00:1a.7/usb7/7-4/7-4:1.0 (usb)
+UDEV  [8140.452579] add      /devices/pci0000:00/0000:00:1a.7/usb7/7-4/7-4:1.0/host17 (scsi)
+UDEV  [8140.455196] add      /devices/pci0000:00/0000:00:1a.7/usb7/7-4/7-4:1.0/host17/scsi_host/host17 (scsi_host)
+KERNEL[8141.438425] add      /devices/pci0000:00/0000:00:1a.7/usb7/7-4/7-4:1.0/host17/target17:0:0 (scsi)
+KERNEL[8141.438459] add      /devices/pci0000:00/0000:00:1a.7/usb7/7-4/7-4:1.0/host17/target17:0:0/17:0:0:0 (scsi)
+KERNEL[8141.438636] add      /devices/pci0000:00/0000:00:1a.7/usb7/7-4/7-4:1.0/host17/target17:0:0/17:0:0:0/scsi_disk/17:0:0:0 (scsi_disk)
+KERNEL[8141.438658] add      /devices/pci0000:00/0000:00:1a.7/usb7/7-4/7-4:1.0/host17/target17:0:0/17:0:0:0/scsi_device/17:0:0:0 (scsi_device)
+KERNEL[8141.438679] add      /devices/pci0000:00/0000:00:1a.7/usb7/7-4/7-4:1.0/host17/target17:0:0/17:0:0:0/bsg/17:0:0:0 (bsg)
+UDEV  [8141.441583] add      /devices/pci0000:00/0000:00:1a.7/usb7/7-4/7-4:1.0/host17/target17:0:0 (scsi)
+KERNEL[8141.441768] add      /devices/virtual/bdi/8:128 (bdi)
+UDEV  [8141.444283] add      /devices/virtual/bdi/8:128 (bdi)
+UDEV  [8141.444538] add      /devices/pci0000:00/0000:00:1a.7/usb7/7-4/7-4:1.0/host17/target17:0:0/17:0:0:0 (scsi)
+UDEV  [8141.447279] add      /devices/pci0000:00/0000:00:1a.7/usb7/7-4/7-4:1.0/host17/target17:0:0/17:0:0:0/scsi_disk/17:0:0:0 (scsi_disk)
+UDEV  [8141.447705] add      /devices/pci0000:00/0000:00:1a.7/usb7/7-4/7-4:1.0/host17/target17:0:0/17:0:0:0/scsi_device/17:0:0:0 (scsi_device)
+UDEV  [8141.447880] add      /devices/pci0000:00/0000:00:1a.7/usb7/7-4/7-4:1.0/host17/target17:0:0/17:0:0:0/bsg/17:0:0:0 (bsg)
+KERNEL[8141.584293] add      /devices/pci0000:00/0000:00:1a.7/usb7/7-4/7-4:1.0/host17/target17:0:0/17:0:0:0/block/sdi (block)
+KERNEL[8141.584332] add      /devices/pci0000:00/0000:00:1a.7/usb7/7-4/7-4:1.0/host17/target17:0:0/17:0:0:0/block/sdi/sdi1 (block)
+UDEV  [8141.813113] add      /devices/pci0000:00/0000:00:1a.7/usb7/7-4/7-4:1.0/host17/target17:0:0/17:0:0:0/block/sdi (block)
+UDEV  [8141.919823] add      /devices/pci0000:00/0000:00:1a.7/usb7/7-4/7-4:1.0/host17/target17:0:0/17:0:0:0/block/sdi/sdi1 (block)
+
+Also udisks2:
+
+werewolf:~# udisksctl monitor
+Monitoring the udisks daemon. Press Ctrl+C to exit.
+10:22:37.751: The udisks-daemon is running (name-owner :1.65).
+10:22:45.296: Added /org/freedesktop/UDisks2/drives/LG_USB_Drive_AA00000000003834
+  org.freedesktop.UDisks2.Drive:
+    ConnectionBus:              usb
+    Ejectable:                  true
+    Media:                      
+    MediaAvailable:             true
+    MediaChangeDetected:        true
+    MediaCompatibility:         
+    MediaRemovable:             true
+    Model:                      USB Drive
+    Optical:                    false
+    OpticalBlank:               false
+    OpticalNumAudioTracks:      0
+    OpticalNumDataTracks:       0
+    OpticalNumSessions:         0
+    OpticalNumTracks:           0
+    Removable:                  true
+    Revision:                   1100
+    RotationRate:               -1
+    Serial:                     AA00000000003834
+    Size:                       2029518848
+    SortKey:                    01hotplug/1328001765294221
+    TimeDetected:               1328001765294221
+    TimeMediaDetected:          1328001765294221
+    Vendor:                     LG
+    WWN:                        
+10:22:45.298: Added /org/freedesktop/UDisks2/block_devices/sdi
+  org.freedesktop.UDisks2.Block:
+    Configuration:              []
+    CryptoBackingDevice:        '/'
+    Device:                     /dev/sdi
+    DeviceNumber:               2176
+    Drive:                      '/org/freedesktop/UDisks2/drives/LG_USB_Drive_AA00000000003834'
+    HintAuto:                   true
+    HintIconName:               
+    HintIgnore:                 false
+    HintName:                   
+    HintPartitionable:          true
+    HintSystem:                 false
+    IdLabel:                    
+    IdType:                     
+    IdUUID:                     
+    IdUsage:                    
+    IdVersion:                  
+    PreferredDevice:            /dev/sdi
+    ReadOnly:                   false
+    Size:                       2029518848
+    Symlinks:                   /dev/disk/by-id/usb-LG_USB_Drive_AA00000000003834-0:0
+                                /dev/disk/by-path/pci-0000:00:1a.7-usb-0:4:1.0-scsi-0:0:0:0
+  org.freedesktop.UDisks2.PartitionTable:
+    Type:               dos
+10:22:45.403: Added /org/freedesktop/UDisks2/block_devices/sdi1
+  org.freedesktop.UDisks2.Block:
+    Configuration:              []
+    CryptoBackingDevice:        '/'
+    Device:                     /dev/sdi1
+    DeviceNumber:               2177
+    Drive:                      '/org/freedesktop/UDisks2/drives/LG_USB_Drive_AA00000000003834'
+    HintAuto:                   true
+    HintIconName:               
+    HintIgnore:                 false
+    HintName:                   
+    HintPartitionable:          true
+    HintSystem:                 false
+    IdLabel:                    LG SUSANA
+    IdType:                     vfat
+    IdUUID:                     F097-3210
+    IdUsage:                    filesystem
+    IdVersion:                  FAT16
+    PreferredDevice:            /dev/sdi1
+    ReadOnly:                   false
+    Size:                       2029502464
+    Symlinks:                   /dev/disk/by-id/usb-LG_USB_Drive_AA00000000003834-0:0-part1
+                                /dev/disk/by-label/LG\x20SUSANA
+                                /dev/disk/by-path/pci-0000:00:1a.7-usb-0:4:1.0-scsi-0:0:0:0-part1
+                                /dev/disk/by-uuid/F097-3210
+  org.freedesktop.UDisks2.Filesystem:
+    MountPoints:        
+  org.freedesktop.UDisks2.Partition:
+    Flags:              0
+    IsContained:        false
+    IsContainer:        false
+    Name:               
+    Number:             1
+    Offset:             16384
+    Size:               2029502464
+    Table:              '/org/freedesktop/UDisks2/block_devices/sdi'
+    Type:               0x06
+    UUID:               
+
+These are the same logs for an empty DVD disk:
+
+udev:
+KERNEL[8232.929362] change   /devices/pci0000:00/0000:00:1f.2/host5/target5:0:0/5:0:0:0/block/sr0 (block)
+UDEV  [8232.983491] change   /devices/pci0000:00/0000:00:1f.2/host5/target5:0:0/5:0:0:0/block/sr0 (block)
+
+udisks2:
+
+10:24:09.656: /org/freedesktop/UDisks2/drives/WDC_WD3200AVJS_63WDA0_WD_WCARW2347788: org.freedesktop.UDisks2.Drive.Ata: Properties Changed
+  SmartUpdated:         1328001849
+10:24:09.827: /org/freedesktop/UDisks2/drives/ST3320620AS_6QF1QZVN: org.freedesktop.UDisks2.Drive.Ata: Properties Changed
+  SmartUpdated:         1328001849
+10:24:09.980: /org/freedesktop/UDisks2/drives/ST3500418AS_5VM8G8RY: org.freedesktop.UDisks2.Drive.Ata: Properties Changed
+  SmartUpdated:         1328001849
+10:24:10.159: /org/freedesktop/UDisks2/drives/ST3250310AS_5RY14KMR: org.freedesktop.UDisks2.Drive.Ata: Properties Changed
+  SmartUpdated:         1328001850
+10:24:16.466: /org/freedesktop/UDisks2/drives/HL_DT_ST_DVDRAM_GH22NS50_K1197AJ3056: org.freedesktop.UDisks2.Drive: Properties Changed
+  TimeMediaDetected:            1328001856464043
+  OpticalNumTracks:             1
+  OpticalNumSessions:           1
+  OpticalBlank:                 true
+  Optical:                      true
+  Media:                        optical_dvd_r
+  MediaAvailable:               true
+  Size:                         2048
+10:24:16.466: /org/freedesktop/UDisks2/block_devices/sr0: org.freedesktop.UDisks2.Block: Properties Changed
+  Size:                 2048
+
+And these for a Mageia-1 install DVD:
+
+udev:
+KERNEL[8366.561352] change   /devices/pci0000:00/0000:00:1f.2/host5/target5:0:0/5:0:0:0/block/sr0 (block)
+UDEV  [8375.155151] change   /devices/pci0000:00/0000:00:1f.2/host5/target5:0:0/5:0:0:0/block/sr0 (block)
+
+udisks2:
+10:26:38.636: /org/freedesktop/UDisks2/block_devices/sr0: Added interface org.freedesktop.UDisks2.Filesystem
+  MountPoints:          
+10:26:38.637: /org/freedesktop/UDisks2/drives/HL_DT_ST_DVDRAM_GH22NS50_K1197AJ3056: org.freedesktop.UDisks2.Drive: Properties Changed
+  TimeMediaDetected:            1328001998635413
+  OpticalNumDataTracks:         1
+  OpticalNumTracks:             1
+  OpticalNumSessions:           1
+  Optical:                      true
+  Media:                        optical_dvd
+  MediaAvailable:               true
+  Size:                         3906994176
+10:26:38.638: /org/freedesktop/UDisks2/block_devices/sr0: org.freedesktop.UDisks2.Block: Properties Changed
+  IdLabel:              1-x86_64
+  IdType:               iso9660
+  IdUsage:              filesystem
+  Size:                 3906994176
+  Symlinks:             /dev/cdrom1
+                        /dev/cdrw1
+                        /dev/disk/by-id/ata-HL-DT-ST_DVDRAM_GH22NS50_K1197AJ3056
+                        /dev/disk/by-id/wwn-0x5001480000000000
+                        /dev/disk/by-label/1-x86_64
+                        /dev/disk/by-path/pci-0000:00:1f.2-scsi-5:0:0:0
+                        /dev/dvd1
+                        /dev/dvdrw1
+
+
+So what is the next step to check ?
+
+-- 
+J.A. Magallon <jamagallon()ono!com>        \               Winter is coming...
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011660.html b/zarb-ml/mageia-dev/2012-January/011660.html new file mode 100644 index 000000000..475380d20 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011660.html @@ -0,0 +1,78 @@ + + + + [Mageia-dev] Media mounting broken + + + + + + + + + +

[Mageia-dev] Media mounting broken

+ Robert Fox + list at foxconsult.net +
+ Tue Jan 31 10:33:54 CET 2012 +

+
+ +
On Tue, 2012-01-31 at 10:28 +0100, JA Magallón wrote:
+> Hi all...
+> 
+> Since some time ago, automounting of media (USB, CD) seems gone nuts.
+> How can I debug this ?
+> First of all, I have udisks2 installed, not udisks, even if the later
+> is also in the repos. I suppose newer version supersedes it, as it is
+> required by gnome-disk-utility (formerly palimpsest).
+> 
+
+I can confirm this under Gnome - but under KDE auto-mounting seems to
+work.
+
+Cheers, R.Fox
+
+
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011661.html b/zarb-ml/mageia-dev/2012-January/011661.html new file mode 100644 index 000000000..a85eb1897 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011661.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] Media mounting broken + + + + + + + + + +

[Mageia-dev] Media mounting broken

+ JA Magallón + jamagallon at ono.com +
+ Tue Jan 31 10:37:41 CET 2012 +

+
+ +
On 01/31/2012 10:33 AM, Robert Fox wrote:
+> On Tue, 2012-01-31 at 10:28 +0100, JA Magallón wrote:
+>> Hi all...
+>>
+>> Since some time ago, automounting of media (USB, CD) seems gone nuts.
+>> How can I debug this ?
+>> First of all, I have udisks2 installed, not udisks, even if the later
+>> is also in the repos. I suppose newer version supersedes it, as it is
+>> required by gnome-disk-utility (formerly palimpsest).
+>>
+> 
+> I can confirm this under Gnome - but under KDE auto-mounting seems to
+> work.
+> 
+
+I suspected this also, something in Gnome is ignoring/not monitoring
+disk changes.
+
+But anyways, this means that automounting would not work outside graphical
+DEs ? Should not this also work on a system running just in text mode ?
+
+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/2012-January/011662.html b/zarb-ml/mageia-dev/2012-January/011662.html new file mode 100644 index 000000000..16fb53ef2 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011662.html @@ -0,0 +1,84 @@ + + + + [Mageia-dev] Media mounting broken + + + + + + + + + +

[Mageia-dev] Media mounting broken

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Jan 31 10:39:49 CET 2012 +

+
+ +
'Twas brillig, and JA Magallón at 31/01/12 09:37 did gyre and gimble:
+> Should not this also work on a system running just in text mode
+
+Nope. Longer term, it would be possible as systemd tracks user logins
+and can launch an agent to do this job, but until then you have to do it
+manually. This is why urpmi integrate(s|ed?) with HAL to mount CD/DVDs
+when needed for installing stuff.
+
+Col
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011663.html b/zarb-ml/mageia-dev/2012-January/011663.html new file mode 100644 index 000000000..ce0a78a15 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011663.html @@ -0,0 +1,81 @@ + + + + [Mageia-dev] Media mounting broken + + + + + + + + + +

[Mageia-dev] Media mounting broken

+ Robert Fox + list at foxconsult.net +
+ Tue Jan 31 10:43:48 CET 2012 +

+
+ +
On Tue, 2012-01-31 at 09:39 +0000, Colin Guthrie wrote:
+> 'Twas brillig, and JA Magallón at 31/01/12 09:37 did gyre and gimble:
+> > Should not this also work on a system running just in text mode
+> 
+> Nope. Longer term, it would be possible as systemd tracks user logins
+> and can launch an agent to do this job, but until then you have to do it
+> manually. This is why urpmi integrate(s|ed?) with HAL to mount CD/DVDs
+> when needed for installing stuff.
+> 
+> Col
+> 
+
+Hello Colin - I though HAL is no longer needed (has been removed as
+orphan) . . .
+
+Cheers,
+R.Fox
+
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011664.html b/zarb-ml/mageia-dev/2012-January/011664.html new file mode 100644 index 000000000..0c31fc9c5 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011664.html @@ -0,0 +1,71 @@ + + + + [Mageia-dev] [soft-commits] [2851] Add hime; remove chinput, kinput2, oxim, xcin. + + + + + + + + + +

[Mageia-dev] [soft-commits] [2851] Add hime; remove chinput, kinput2, oxim, xcin.

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Jan 31 11:59:13 CET 2012 +

+
+ +
On 29 January 2012 15:09, You-Cheng Hsieh <yochenhsieh at gmail.com> wrote:
+>>> Log Message
+>>>
+>>> Add hime; remove chinput, kinput2, oxim, xcin.
+>>
+>> why 3 commits with the same changelog?
+>> If you wanted to revert only the locale list changes, then just do
+>> that next time,
+>> with a proper changelog.
+>> Thanks.
+> Sorry, I will be more careful about that next time.
+> My apology for any confusion and inconvenience.
+
+You can use svn propedit to edit your changelogs.
+Also describe your changes in at top of perl-install/NEWS
+for next release.
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011665.html b/zarb-ml/mageia-dev/2012-January/011665.html new file mode 100644 index 000000000..286ae24c9 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011665.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] Media mounting broken + + + + + + + + + +

[Mageia-dev] Media mounting broken

+ Frank Griffin + ftg at roadrunner.com +
+ Tue Jan 31 12:52:06 CET 2012 +

+
+ +
On 01/31/2012 04:33 AM, Robert Fox wrote:
+> On Tue, 2012-01-31 at 10:28 +0100, JA Magallón wrote:
+>> Hi all...
+>>
+>> Since some time ago, automounting of media (USB, CD) seems gone nuts.
+>> How can I debug this ?
+>> First of all, I have udisks2 installed, not udisks, even if the later
+>> is also in the repos. I suppose newer version supersedes it, as it is
+>> required by gnome-disk-utility (formerly palimpsest).
+>>
+> I can confirm this under Gnome - but under KDE auto-mounting seems to
+> work.
+>
+> Cheers, R.Fox
+
+There was a discussion about this on the thread "mkinitrd and Mageia2".  
+As near as I can figure, there used to be something, maybe 
+GNOME-related, that kicked in for LXDE and GNOME apps run under KDE and 
+automounted removable disks.  It stopped doing this a week or so ago.
+
+KDE recognizes the volume availability, but does not automount the 
+volume unless you choose some action from the device notification popup 
+that it (KDE) realizes requires it, e. g. Dolphin (or maybe Dolphin does 
+the automount).
+
+The result is that (at least) LXDE and GNOME apps under KDE which 
+require mounted volumes like brasero or anything under wine no longer 
+work.  Wine apps stopped working under KDE a while ago, probably for 
+this reason, and probably because wine doesn't "trigger" whatever GNOME 
+apps under KDE were triggering.
+
+ + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011666.html b/zarb-ml/mageia-dev/2012-January/011666.html new file mode 100644 index 000000000..b3fdb9065 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011666.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] Media mounting broken + + + + + + + + + +

[Mageia-dev] Media mounting broken

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Jan 31 13:13:56 CET 2012 +

+
+ +
'Twas brillig, and Robert Fox at 31/01/12 09:43 did gyre and gimble:
+> On Tue, 2012-01-31 at 09:39 +0000, Colin Guthrie wrote:
+>> 'Twas brillig, and JA Magallón at 31/01/12 09:37 did gyre and gimble:
+>>> Should not this also work on a system running just in text mode
+>>
+>> Nope. Longer term, it would be possible as systemd tracks user logins
+>> and can launch an agent to do this job, but until then you have to do it
+>> manually. This is why urpmi integrate(s|ed?) with HAL to mount CD/DVDs
+>> when needed for installing stuff.
+>>
+>> Col
+>>
+> 
+> Hello Colin - I though HAL is no longer needed (has been removed as
+> orphan) . . .
+
+Perhaps in the last few days... not looked closely, but until recently,
+urpmi stuff was still using it for CD mounting. Perhaps it's been ported
+to udev now?
+
+But I've not used CD/DVD media for several years so I never use this
+feature anyway, and thus have had hal disabled/uninstalled for a long time.
+
+Col
+
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011667.html b/zarb-ml/mageia-dev/2012-January/011667.html new file mode 100644 index 000000000..51eae3e94 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011667.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] Media mounting broken + + + + + + + + + +

[Mageia-dev] Media mounting broken

+ Frank Griffin + ftg at roadrunner.com +
+ Tue Jan 31 13:23:07 CET 2012 +

+
+ +
On 01/31/2012 06:52 AM, Frank Griffin wrote:
+>
+> There was a discussion about this on the thread "mkinitrd and 
+> Mageia2".  As near as I can figure, there used to be something, maybe 
+> GNOME-related, that kicked in for LXDE and GNOME apps run under KDE 
+> and automounted removable disks.  It stopped doing this a week or so ago.
+>
+> KDE recognizes the volume availability, but does not automount the 
+> volume unless you choose some action from the device notification 
+> popup that it (KDE) realizes requires it, e. g. Dolphin (or maybe 
+> Dolphin does the automount).
+>
+> The result is that (at least) LXDE and GNOME apps under KDE which 
+> require mounted volumes like brasero or anything under wine no longer 
+> work.  Wine apps stopped working under KDE a while ago, probably for 
+> this reason, and probably because wine doesn't "trigger" whatever 
+> GNOME apps under KDE were triggering.
+>
+
+I've just found that if you right-click on the device notifier panel 
+icon and select Settings, then Removable Media, there is an option to 
+automount removable media which  is not checked.  I'll bet the default 
+for this changed with the latest KDE upload.  Still doesn't explain why 
+LXDE has problems, tho.
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011668.html b/zarb-ml/mageia-dev/2012-January/011668.html new file mode 100644 index 000000000..882b99970 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011668.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] Media mounting broken + + + + + + + + + +

[Mageia-dev] Media mounting broken

+ Thomas Backlund + tmb at mageia.org +
+ Tue Jan 31 13:47:11 CET 2012 +

+
+ +
Colin Guthrie skrev 31.1.2012 14:13:
+> 'Twas brillig, and Robert Fox at 31/01/12 09:43 did gyre and gimble:
+>> On Tue, 2012-01-31 at 09:39 +0000, Colin Guthrie wrote:
+>>> 'Twas brillig, and JA Magallón at 31/01/12 09:37 did gyre and gimble:
+>>>> Should not this also work on a system running just in text mode
+>>>
+>>> Nope. Longer term, it would be possible as systemd tracks user logins
+>>> and can launch an agent to do this job, but until then you have to do it
+>>> manually. This is why urpmi integrate(s|ed?) with HAL to mount CD/DVDs
+>>> when needed for installing stuff.
+>>>
+>>> Col
+>>>
+>>
+>> Hello Colin - I though HAL is no longer needed (has been removed as
+>> orphan) . . .
+>
+> Perhaps in the last few days... not looked closely, but until recently,
+> urpmi stuff was still using it for CD mounting. Perhaps it's been ported
+> to udev now?
+
+As of perl-Hal-Cdroms-0.04-1.mga2, released on Sunday, January 29th it 
+now relies on udisks... All done by tv.
+
+--
+Thomas
+
+
+
+
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011669.html b/zarb-ml/mageia-dev/2012-January/011669.html new file mode 100644 index 000000000..c5b60fccd --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011669.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] Media mounting broken + + + + + + + + + +

[Mageia-dev] Media mounting broken

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Jan 31 14:20:48 CET 2012 +

+
+ +
'Twas brillig, and Thomas Backlund at 31/01/12 12:47 did gyre and gimble:
+> As of perl-Hal-Cdroms-0.04-1.mga2, released on Sunday, January 29th it
+> now relies on udisks... All done by tv.
+
+\o/ yay for Thierry!
+
+Col
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011670.html b/zarb-ml/mageia-dev/2012-January/011670.html new file mode 100644 index 000000000..79d4a537e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011670.html @@ -0,0 +1,70 @@ + + + + [Mageia-dev] Media mounting broken + + + + + + + + + +

[Mageia-dev] Media mounting broken

+ Frank Griffin + ftg at roadrunner.com +
+ Tue Jan 31 14:32:57 CET 2012 +

+
+ +
On 01/31/2012 07:23 AM, Frank Griffin wrote:
+>
+> I've just found that if you right-click on the device notifier panel 
+> icon and select Settings, then Removable Media, there is an option to 
+> automount removable media which  is not checked.  I'll bet the default 
+> for this changed with the latest KDE upload.  Still doesn't explain 
+> why LXDE has problems, tho.
+>
+There is no joy in Mudville: https://bugs.mageia.org/show_bug.cgi?id=4361
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011671.html b/zarb-ml/mageia-dev/2012-January/011671.html new file mode 100644 index 000000000..c68345327 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011671.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] Media mounting broken + + + + + + + + + +

[Mageia-dev] Media mounting broken

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Jan 31 14:50:41 CET 2012 +

+
+ +
'Twas brillig, and Frank Griffin at 31/01/12 13:32 did gyre and gimble:
+> On 01/31/2012 07:23 AM, Frank Griffin wrote:
+>>
+>> I've just found that if you right-click on the device notifier panel
+>> icon and select Settings, then Removable Media, there is an option to
+>> automount removable media which  is not checked.  I'll bet the default
+>> for this changed with the latest KDE upload.  Still doesn't explain
+>> why LXDE has problems, tho.
+>>
+> There is no joy in Mudville: https://bugs.mageia.org/show_bug.cgi?id=4361
+
+I suspect the problem is somewhere in gvfs or below. I believe LXDE uses
+gvfs so this would explain why both it and GNOME are affected..
+
+Certainly running:
+gvfs-mount -oi
+
+does not show any events when plugging/unplugging a USB disk.
+
+Something to investigate - I don't really have time right now.
+
+Col
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011672.html b/zarb-ml/mageia-dev/2012-January/011672.html new file mode 100644 index 000000000..60268af91 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011672.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] Servers downtime scheduled from Feb. 1 to 2 for maintenance + + + + + + + + + +

[Mageia-dev] Servers downtime scheduled from Feb. 1 to 2 for maintenance

+ Michael Scherer + misc at zarb.org +
+ Tue Jan 31 15:09:31 CET 2012 +

+
+ +
Le lundi 30 janvier 2012 à 23:19 +0100, Romain d'Alverny a écrit :
+> Hello everyone,
+> 
+> some Mageia servers will be down from Wednesday Feb. 1st to Thursday
+> Feb. 2nd for maintenance. Particularly, the following services will be
+> unavailable:
+> - our LDAP/user identity db,
+> - build system,
+> - Bugzilla,
+> - all mailing-lists hosted on ml.mageia.org,
+> - Wiki,
+> - forums.
+- transifex
+- epoll
+- svn, git
+- youri web interface
+- maint db
+
+in short, almost all web applications ( ie, hosted on alamut ), and the
+build system. See http://svnweb.mageia.org/adm/puppet/manifests/nodes/ 
+
+And to complete :
+- ldap will still work ( we do have a redundant setup, even if I have
+not finished making sure everything use the 2nd ldap in case of failure
+), but readonly
+
+- mails will still be queued, so nothing should be lost
+
+We will announce on irc the exact moment when we plan to shutdown
+servers.
+
+-- 
+Michael Scherer
+
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011673.html b/zarb-ml/mageia-dev/2012-January/011673.html new file mode 100644 index 000000000..1c2ff6b54 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011673.html @@ -0,0 +1,116 @@ + + + + [Mageia-dev] Media mounting broken + + + + + + + + + +

[Mageia-dev] Media mounting broken

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Jan 31 15:15:21 CET 2012 +

+
+ +
'Twas brillig, and Colin Guthrie at 31/01/12 13:50 did gyre and gimble:
+> 'Twas brillig, and Frank Griffin at 31/01/12 13:32 did gyre and gimble:
+>> On 01/31/2012 07:23 AM, Frank Griffin wrote:
+>>>
+>>> I've just found that if you right-click on the device notifier panel
+>>> icon and select Settings, then Removable Media, there is an option to
+>>> automount removable media which  is not checked.  I'll bet the default
+>>> for this changed with the latest KDE upload.  Still doesn't explain
+>>> why LXDE has problems, tho.
+>>>
+>> There is no joy in Mudville: https://bugs.mageia.org/show_bug.cgi?id=4361
+> 
+> I suspect the problem is somewhere in gvfs or below. I believe LXDE uses
+> gvfs so this would explain why both it and GNOME are affected..
+> 
+> Certainly running:
+> gvfs-mount -oi
+> 
+> does not show any events when plugging/unplugging a USB disk.
+> 
+> Something to investigate - I don't really have time right now.
+
+OK, so basically it's due to the switch form using the gdu volume
+monitor backend to the udisks2 one.
+
+As gnome-disk-utility was updated, it no longer offers the gdu volume
+monitor....
+
+So you *will* need udisks2 installed (no requires yet), but even then it
+is not working for me...
+
+udisks2 does see the drives being plugged in (udisksctl monitor) but
+it's not getting through to gvfs.
+
+Grepping for udisks2 in gvfs's configure does not show any results... so
+the problem is our gvfs does not support udisks...
+
+To the git tree batman!!!
+
+Col
+
+
+
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011674.html b/zarb-ml/mageia-dev/2012-January/011674.html new file mode 100644 index 000000000..c71109a38 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011674.html @@ -0,0 +1,126 @@ + + + + [Mageia-dev] Media mounting broken + + + + + + + + + +

[Mageia-dev] Media mounting broken

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Jan 31 15:39:38 CET 2012 +

+
+ +
'Twas brillig, and Colin Guthrie at 31/01/12 14:15 did gyre and gimble:
+> 'Twas brillig, and Colin Guthrie at 31/01/12 13:50 did gyre and gimble:
+>> 'Twas brillig, and Frank Griffin at 31/01/12 13:32 did gyre and gimble:
+>>> On 01/31/2012 07:23 AM, Frank Griffin wrote:
+>>>>
+>>>> I've just found that if you right-click on the device notifier panel
+>>>> icon and select Settings, then Removable Media, there is an option to
+>>>> automount removable media which  is not checked.  I'll bet the default
+>>>> for this changed with the latest KDE upload.  Still doesn't explain
+>>>> why LXDE has problems, tho.
+>>>>
+>>> There is no joy in Mudville: https://bugs.mageia.org/show_bug.cgi?id=4361
+>>
+>> I suspect the problem is somewhere in gvfs or below. I believe LXDE uses
+>> gvfs so this would explain why both it and GNOME are affected..
+>>
+>> Certainly running:
+>> gvfs-mount -oi
+>>
+>> does not show any events when plugging/unplugging a USB disk.
+>>
+>> Something to investigate - I don't really have time right now.
+> 
+> OK, so basically it's due to the switch form using the gdu volume
+> monitor backend to the udisks2 one.
+> 
+> As gnome-disk-utility was updated, it no longer offers the gdu volume
+> monitor....
+> 
+> So you *will* need udisks2 installed (no requires yet), but even then it
+> is not working for me...
+> 
+> udisks2 does see the drives being plugged in (udisksctl monitor) but
+> it's not getting through to gvfs.
+> 
+> Grepping for udisks2 in gvfs's configure does not show any results... so
+> the problem is our gvfs does not support udisks...
+> 
+> To the git tree batman!!!
+
+OK, so I packaged a git snapshot of gvfs with the udisks2 media monitor
+support merged. Works fine for me. Submitted for build.
+
+Seems Funda tried to do this before but didn't actually check that the
+codebase included the udisks2 backend. It did not.
+
+Also had to fix some format security errors too which I'll push upstream.
+
+Must get back to work now!!
+
+Col
+
+
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+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/2012-January/011675.html b/zarb-ml/mageia-dev/2012-January/011675.html new file mode 100644 index 000000000..82d83af4e --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011675.html @@ -0,0 +1,62 @@ + + + + [Mageia-dev] stardict 3.0.3 + + + + + + + + + +

[Mageia-dev] stardict 3.0.3

+ Romain d'Alverny + rdalverny at gmail.com +
+ Tue Jan 31 15:45:03 CET 2012 +

+
+ +
On Mon, Jan 30, 2012 at 23:29, Michael Scherer <misc at zarb.org> wrote:
+> Unfortunately, that's not really the opinion of the sourceforge lawyers.
+
+Where is this opinion documented? Are there source/reference/details
+about said copyright infringement reports? (without which the claim
+does not stand) I could not find on the old site, neither on the new
+one, neither through a quick Google search.
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011676.html b/zarb-ml/mageia-dev/2012-January/011676.html new file mode 100644 index 000000000..8a0e82c01 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011676.html @@ -0,0 +1,77 @@ + + + + [Mageia-dev] Media mounting broken + + + + + + + + + +

[Mageia-dev] Media mounting broken

+ Frank Griffin + ftg at roadrunner.com +
+ Tue Jan 31 15:46:23 CET 2012 +

+
+ +
On 01/31/2012 09:39 AM, Colin Guthrie wrote:
+>
+> OK, so I packaged a git snapshot of gvfs with the udisks2 media monitor
+> support merged. Works fine for me. Submitted for build.
+>
+> Seems Funda tried to do this before but didn't actually check that the
+> codebase included the udisks2 backend. It did not.
+>
+> Also had to fix some format security errors too which I'll push upstream.
+>
+> Must get back to work now!!
+>
+> Col
+>
+>
+>
+
+Brilliant, thanks !
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011677.html b/zarb-ml/mageia-dev/2012-January/011677.html new file mode 100644 index 000000000..1a62506dc --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011677.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] Servers downtime scheduled from Feb. 1 to 2 for maintenance + + + + + + + + + +

[Mageia-dev] Servers downtime scheduled from Feb. 1 to 2 for maintenance

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Jan 31 17:02:25 CET 2012 +

+
+ +
On 31 January 2012 15:09, Michael Scherer <misc at zarb.org> wrote:
+>> some Mageia servers will be down from Wednesday Feb. 1st to Thursday
+>> Feb. 2nd for maintenance. Particularly, the following services will be
+>> unavailable:
+>> - our LDAP/user identity db,
+>> - build system,
+>> - Bugzilla,
+>> - all mailing-lists hosted on ml.mageia.org,
+>> - Wiki,
+>> - forums.
+> - transifex
+> - epoll
+> - svn, git
+> - youri web interface
+> - maint db
+>
+> in short, almost all web applications ( ie, hosted on alamut ), and the
+> build system. See http://svnweb.mageia.org/adm/puppet/manifests/nodes/
+>
+> And to complete :
+> - ldap will still work ( we do have a redundant setup, even if I have
+> not finished making sure everything use the 2nd ldap in case of failure
+> ), but readonly
+>
+> - mails will still be queued, so nothing should be lost
+>
+> We will announce on irc the exact moment when we plan to shutdown
+> servers.
+
+Announce it by mail too please.
+
+BTW, we should try to make more stuff redundancy. Withough going up to
+using DRBD
+for VM images, we could:
+- for SVN, it's easy to have at least a RO secondary server:
+http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.extra.writethruproxy
+if we stop write access on the master, we could wait for the slave to
+keep up with the latest commits, then make it RW
+when we need to stop the master.
+- for bugzilla, have two VM who perform master-master replication; we
+can this way
+ I'm not sure bugzilla support writing on both ends, but without
+performing load balancing,
+ when needed, we could stop access to the active one, wait for
+replication to finish, open
+ access on the second one
+- having more hypervisors and live migrating our VMs off the
+hypervisor we update so that
+  rebooting it doesn't impact service;
+- ...
+
+See you
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011678.html b/zarb-ml/mageia-dev/2012-January/011678.html new file mode 100644 index 000000000..6061c9a5c --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011678.html @@ -0,0 +1,117 @@ + + + + [Mageia-dev] Servers downtime scheduled from Feb. 1 to 2 for maintenance + + + + + + + + + +

[Mageia-dev] Servers downtime scheduled from Feb. 1 to 2 for maintenance

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Tue Jan 31 17:50:16 CET 2012 +

+
+ +
Le 31/01/2012 17:02, Thierry Vignaud a écrit :
+> On 31 January 2012 15:09, Michael Scherer<misc at zarb.org>  wrote:
+>>> some Mageia servers will be down from Wednesday Feb. 1st to Thursday
+>>> Feb. 2nd for maintenance. Particularly, the following services will be
+>>> unavailable:
+>>> - our LDAP/user identity db,
+>>> - build system,
+>>> - Bugzilla,
+>>> - all mailing-lists hosted on ml.mageia.org,
+>>> - Wiki,
+>>> - forums.
+>> - transifex
+>> - epoll
+>> - svn, git
+>> - youri web interface
+>> - maint db
+>>
+>> in short, almost all web applications ( ie, hosted on alamut ), and the
+>> build system. See http://svnweb.mageia.org/adm/puppet/manifests/nodes/
+>>
+>> And to complete :
+>> - ldap will still work ( we do have a redundant setup, even if I have
+>> not finished making sure everything use the 2nd ldap in case of failure
+>> ), but readonly
+>>
+>> - mails will still be queued, so nothing should be lost
+>>
+>> We will announce on irc the exact moment when we plan to shutdown
+>> servers.
+>
+> Announce it by mail too please.
+>
+> BTW, we should try to make more stuff redundancy. Withough going up to
+> using DRBD
+> for VM images, we could:
+> - for SVN, it's easy to have at least a RO secondary server:
+> http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.extra.writethruproxy
+> if we stop write access on the master, we could wait for the slave to
+> keep up with the latest commits, then make it RW
+> when we need to stop the master.
+> - for bugzilla, have two VM who perform master-master replication; we
+> can this way
+>   I'm not sure bugzilla support writing on both ends, but without
+> performing load balancing,
+>   when needed, we could stop access to the active one, wait for
+> replication to finish, open
+>   access on the second one
+Given the few downtime sofar, is this really justified ? Complexity is 
+rarely a synonym of high availability...
+
+> - having more hypervisors and live migrating our VMs off the
+> hypervisor we update so that
+>    rebooting it doesn't impact service;
+> - ...
+This one seems perfectly reasonable, tough, as natively supported by 
+hypervisors.
+
+-- 
+BOFH excuse #101:
+
+Collapsed Backbone
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011679.html b/zarb-ml/mageia-dev/2012-January/011679.html new file mode 100644 index 000000000..d6421f203 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011679.html @@ -0,0 +1,68 @@ + + + + [Mageia-dev] Media mounting broken + + + + + + + + + +

[Mageia-dev] Media mounting broken

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Jan 31 19:09:34 CET 2012 +

+
+ +
On 31 January 2012 15:39, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+>> So you *will* need udisks2 installed (no requires yet), but even then it
+>> is not working for me...
+
+(...)
+
+> OK, so I packaged a git snapshot of gvfs with the udisks2 media monitor
+> support merged. Works fine for me. Submitted for build.
+
+Note that FC actually requires udisks2 in gfvfs:
+http://pkgs.fedoraproject.org/gitweb/?p=gvfs.git;a=commitdiff;h=323b765f24f62bba78290f0a595e391ecf470448
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011680.html b/zarb-ml/mageia-dev/2012-January/011680.html new file mode 100644 index 000000000..7d49f54e8 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011680.html @@ -0,0 +1,63 @@ + + + + [Mageia-dev] [Mageia-discuss] Servers downtime scheduled from Feb. 1 to 2 for maintenance + + + + + + + + + +

[Mageia-dev] [Mageia-discuss] Servers downtime scheduled from Feb. 1 to 2 for maintenance

+ Maarten Vanraes + alien at rmail.be +
+ Tue Jan 31 20:47:59 CET 2012 +

+
+ +
Op maandag 30 januari 2012 23:19:02 schreef Romain d'Alverny:
+[...]
+> All hardware purchased thanks to what Mageia.Org received from so many
+> donators (http://mageia.org/en/thank-you/ again).
+[...]
+
+http://mageia.org/en/thank-you/ works, 
+but http://mageia.org/en/thank-you/again doesn't seem to work...
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/011681.html b/zarb-ml/mageia-dev/2012-January/011681.html new file mode 100644 index 000000000..e791d0ad2 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011681.html @@ -0,0 +1,71 @@ + + + + [Mageia-dev] scummvm error at build : hint welcome + + + + + + + + + +

[Mageia-dev] scummvm error at build : hint welcome

+ zezinho + lists.jjorge at free.fr +
+ Tue Jan 31 22:20:44 CET 2012 +

+
+ +
This problem was seen in Fedora, and it seems they have change rpmbuild 
+behaviour :
+
+http://permalink.gmane.org/gmane.linux.redhat.fedora.devel/156484
+
+
+extracting debug info from 
+/home/iurt/rpm/BUILDROOT/scummvm-1.4.1-1.mga2.i386/usr/games/scummvm
+Stabs debuginfo not supported: 
+/home/iurt/rpm/BUILDROOT/scummvm-1.4.1-1.mga2.i386/usr/games/scummvm
+error: Bad exit status from /home/iurt/rpm/tmp/rpm-tmp.gQ6jqv (%install)
+-------------- next part --------------
+An embedded message was scrubbed...
+From: Ulri the scheduler bot <pterjan at gmail.com>
+Subject: Rebuild failed on i586 for @203683:scummvm-1.4.1-1.mga2.src.rpm 
+Date: Tue, 31 Jan 2012 22:09:01 +0100 (CET)
+Size: 3258
+URL: </pipermail/mageia-dev/attachments/20120131/77055c3d/attachment-0001.mht>
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2012-January/author.html b/zarb-ml/mageia-dev/2012-January/author.html new file mode 100644 index 000000000..aee2e51e4 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/author.html @@ -0,0 +1,4212 @@ + + + + The Mageia-dev January 2012 Archive by author + + + + + +

January 2012 Archives by author

+ +

Starting: Sun Jan 1 03:11:30 CET 2012
+ Ending: Tue Jan 31 22:20:44 CET 2012
+ Messages: 833

+

+

+ Last message date: + Tue Jan 31 22:20:44 CET 2012
+ Archived on: Tue Jan 31 22:21:01 CET 2012 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/zarb-ml/mageia-dev/2012-January/date.html b/zarb-ml/mageia-dev/2012-January/date.html new file mode 100644 index 000000000..e0d198082 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/date.html @@ -0,0 +1,4212 @@ + + + + The Mageia-dev January 2012 Archive by date + + + + + +

January 2012 Archives by date

+ +

Starting: Sun Jan 1 03:11:30 CET 2012
+ Ending: Tue Jan 31 22:20:44 CET 2012
+ Messages: 833

+

+

+ Last message date: + Tue Jan 31 22:20:44 CET 2012
+ Archived on: Tue Jan 31 22:21:01 CET 2012 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/zarb-ml/mageia-dev/2012-January/index.html b/zarb-ml/mageia-dev/2012-January/index.html new file mode 120000 index 000000000..db4b46f72 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/zarb-ml/mageia-dev/2012-January/subject.html b/zarb-ml/mageia-dev/2012-January/subject.html new file mode 100644 index 000000000..9ee57f167 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/subject.html @@ -0,0 +1,4212 @@ + + + + The Mageia-dev January 2012 Archive by subject + + + + + +

January 2012 Archives by subject

+ +

Starting: Sun Jan 1 03:11:30 CET 2012
+ Ending: Tue Jan 31 22:20:44 CET 2012
+ Messages: 833

+

+

+ Last message date: + Tue Jan 31 22:20:44 CET 2012
+ Archived on: Tue Jan 31 22:21:01 CET 2012 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/zarb-ml/mageia-dev/2012-January/thread.html b/zarb-ml/mageia-dev/2012-January/thread.html new file mode 100644 index 000000000..7982ed5ca --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/thread.html @@ -0,0 +1,5661 @@ + + + + The Mageia-dev January 2012 Archive by thread + + + + + +

January 2012 Archives by thread

+ +

Starting: Sun Jan 1 03:11:30 CET 2012
+ Ending: Tue Jan 31 22:20:44 CET 2012
+ Messages: 833

+

+

+ Last message date: + Tue Jan 31 22:20:44 CET 2012
+ Archived on: Tue Jan 31 22:21:01 CET 2012 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + -- cgit v1.2.1