From mvdan at mvdan.cc  Thu Nov  1 12:49:53 2012
From: mvdan at mvdan.cc (Daniel =?iso-8859-1?Q?Mart=ED?=)
Date: Thu, 1 Nov 2012 13:49:53 +0100
Subject: [Dev] hackers.git patch
Message-ID: <20121101124953.GA14421@royal>

Hello list,

I'm attaching a patch against hackers.git which appends my ssh and gnupg
keys.

Cheers.

-- 
Daniel Mart? - mvdan at mvdan.cc - GPG 0x58BF72C3
-------------- next part --------------
diff --git a/authorized_keys b/authorized_keys
index 4926f56..a0cb81a 100644
--- a/authorized_keys
+++ b/authorized_keys
@@ -20,3 +20,4 @@ ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBAFwUVGO
 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCkLc4Ev5ADx1psS056kl0rn2ljuo8VBiH+NjNv2ohPCBNlW3GhzpqGTECN9pYA7BYiyzBmKgC971OJiKsG/5R+m9L5SsZ2v9h7b9IgZlLMYvrJftEvJQL8aVnPlU3CGtc5sjlgktREGjc9lOVXl4AWgR+3Ui3QIyD0TqXBRWZoPGx7UwnMUfdwfI70mikQYei69uPST9zbSX28TfGczZbZNyL6N+7jM4LPXFZ5pVC1XjsKOdkJ6XhaOHe8zb6DJ0eS1PUUnUzoQVtfXnddvuZl1EgY6Y6ErIUNdIJvyA0jghuD1EohvHGissXBl01jbj59bbvIdYMPxZmaZf4hQtgF "Jorge Araya Navarro <jorgean at lavabit.com>"
 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDeJHi2YJKw1FFA8aLkDyR7BBhmNP+5D6PX7Fg4YHYNm/VJt5Q97JiniPAT/STbU8MJQc7SULmt5NhSmLUcQYhuVSqkKE6cWTe2MdplfoSe2n/V2D214VXzrDghDprPG1OZohj19qaK5VwAmaMK2GkAywNc4bassjD4gLYBpOug9HIulsf/+1tHfG/6BQotf6EF5OFE+JjSOX0nBZ3cCyuVtC233oinMD42bvFqB4uXV6z48Q0NaTDHbjyJd4yeVc418FVI2H++YrABuXuuPVEdTpc9f6FJhrIyC2BSUBMlGSmqyc03QQG+Qi/9Br0quP8sO9k6t0d6kkdocBDfFUlpBbibPfScv2+hBMsyp7JlF8WMmv2O4xA8KZCWEcrgBlcxEb9vyq5ygJVmeKXJ5vNHTlYqSvmFSrI5AsKi2ah6APsKfpKKjjG7GifyNlaogrZyRnPboUed0TncnnQDxri4oZHiUXIIycjb3jcHc2ravTjiJ2BCU8/IVEw6b9O8QgQV1+8dzctXUu7T/v+OOQnWly9/bHcnovYCVK85Bo17rhQeBTj9p4Cvh9zAcLDNaCjMdNv16Ew4wr649zZlceawyHpiBydNyPnXTGlNGKmZcKr3sfgpYkgcnaBxaOcf1m9cWwekvQ/B07fGFZC7ugL6Vp2OvsY8qFNb6xSQIuev2Q== "Ben Peterson <mulenmar at yahoo.com>"
 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDw0O6ggkadO1LV717MrH3jpc4ZHjN6ErwpOd9p9NvEE+qDiyWG3VBai8C3m5uZeG6dMiYOYK1uIOm14Y3f7KIFxPar7Fu2wJvU4n2mmdePAKjX4cMKTXWKGflbJ5spA75Ha86WW3QB1AX7UdfJHfJmBjYLo4nPTRqJOg/vXUxwMI9dTmmucJOVSpp5RueKAbOlDnbIJB3CABLSJn9L8Fo89vw/nyVEK87GBOWcrdg3gjr4FFbbiWTZhe3gROP776En/up5PwQjIyfjno7sMPu0nzHn11WCSH8mDl5bhU9mxLaKfPzo6bg7OGoTjeCOH8iXwowRVg/TYZ0+/B2APJ3x "Esteban Carnevale <alfplayer at mailoo.org>"
+ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC9uPZarXLb3qAbZdKhN52wKEc4Rkoti7MmZxmhNnMxNHmmdwxo/aMmWSQPGweP7/vw2rtnoTomk5pXS5yiwiwWLmt0SOBoZV33M3CS95+u/7HEz+WeOhFmxQz9xlNDSh7ipA6cOyOHmuTOJ0uH3LqUxSG/LTYM9qzZFKfrUZTXrxRcjb3cT2VzkWFYfd7ToHbaWZek7AdwMolGu7zg9UIss6/PpdCzk9f9Pa+8JpKF4RTe6DvgBKNJfOVgs4PsT3kFEUuObYBl4+LaHQonfEEoQQ5jkL2aWElWjliCUZkMAhOKw/Xd2L2Z2qY4hm8tfEqbuJaYcL4viST95nboSvSd "Daniel Mart? <mvdan at mvdan.cc>"
diff --git a/parabola-keyring/parabola.gpg b/parabola-keyring/parabola.gpg
index 8e8d6c6..535ca2a 100644
--- a/parabola-keyring/parabola.gpg
+++ b/parabola-keyring/parabola.gpg
@@ -2613,3 +2613,173 @@ RDy/vHZF1TWs9HDdSMF2gRVpMPLcjAE4A+HFKHRbmvXExiSHM39mnxk0m7Wf+ykB
 EVs5LM6WkwDx40J/O7OIBocS8/np0w==
 =j2+J
 -----END PGP PUBLIC KEY BLOCK-----
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Version: GnuPG v2.0.19 (GNU/Linux)
+
+mQINBE7HoVIBEADJnlE+86lrQO/cDruubCp8jvYDSeZGPcr8YBbJ5uo6ADFN6o2a
+8LBpdMi23hpP91jHmlSrNcpesr9KXE0ONvY8K383lygx+5sU97oUmub7c3vOfk0/
+nJ0yTCyYzJo49V2tOvXjQCtmy8ODXXmPyocyzeX3Bl0ckpOhETBuFyi33eI+KSsj
+G2NUbVboDGAS5q2KbFVp1wZMMiM84poiqLL2jsc2o7NHa88HWbriUDV8ZGp2+P4v
+z5bDXKE4bHMmvg9ursMeMS8TF+tyxhUSkwi6X5/xF+nWsdDIdpQXW2hUSrrryN11
+0RAOJmK/rGbVXezMgDr7wfpuWDq5T9MMEEPsFUYSE0hzzOSJvvtP7RqBZNrei/Yy
+LXzg7yhQrhsg2i014JdB/1sNR5K7Pzycb2qAvkiHFhZolreno1+vcGtqGcfSQTmW
+M7O/qnQS3KrDYg19f2z/qVGsLHRunQ19rV1hD8e0PdR3HZ5x/FL7M3yjNl5jyq0M
+uiYCZjrsNpiGeqJKuXShr748A+cc25wzuGIRYOU607xueNRKtm0oyXdioo1ERH3U
+ffCUxU4s2mSBOO2vQPJeU1mQ4Uy4xnUTwB0JSSHs07feXmTQHH0IzSh2Q/vd+Kq9
+y+rksyKezJB4yLWvbB07Fza991s4UUu2zmxTeMHPm6wNf7WHIFRaBzA3NQARAQAB
+tB5EYW5pZWwgTWFydMOtIDxtdmRhbkBtdmRhbi5jYz6JAkEEEwECACsCGwMFCQPC
+ZwAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJPkEQVAhkBAAoJEK0DlohYv3LD
+H9QQAKUhO5wUSpCjEoXRfpFLecujqE4t9sai4t+rD2V2ozRkdTpPb3Op0uGAhoG+
+s1xC5HcTVuFVeCPgtS1U6SSbKvvgdNFOocHM+AhFkxfn55kP9ou5TLdAauybX8ii
+95v2PY4m1atwhX0VKgpYvMEqrWxlpD40Lxn9uLuPm6y8w6h905iNFp0l98wvZ+2X
+oOgcc1xUEHqzoOjgMbknatKLDkWj0B8rPkaydIxuApZ5K2JoG6pqAZr2olgcrUtM
+4O+HJV8UlAKVGnUDF59GOoCs2FPF5GdfEIuoLt7WNQYieEMbJ+1cVzYuTZk49vVn
+GFSzKXIV69/zHf38vcE1FcJFYK2jniQMGWC23DpJjRQXOoo/zNqcP/WdD9fqd+Pd
+lrJ80HEo9vBZVll8C1tK4UWmQVeD39sKTATz1JsjxaNdm2OOW8ApBWvIqfLF5gze
+7ixkdqG8+rHpboXc5m92ck230Re8Wi8nd809nlCdm3syfMUCkmcp6IFz+lyq9Yzz
+ZeBsLtG4syjOwXp+Ho+/a2lEf8e8EDQLkIQZcJ1H1qak8fV+DwIAAIlX+zD5QNge
+8OPR9qATOgD/hKoEENmWTfr65SNadS/xhpexEFIuJp2GauN7dGdNi7lsaTfvdkuf
+V+gEZAlSzmV9+X6HAmdyb7NiLg8+fivBf5xrR1WbuvipR5RdtCxEYW5pZWwgTWFy
+dMOtIDxkYW5pZWxtYXJ0aS5kZWJpYW5AZ21haWwuY29tPokCHAQQAQgABgUCT0Ig
+6AAKCRAbHjgJYzZOpmzuD/9HqUgFZy9q0kw2G2iMX3+zIMr6fSaUCFYZSla+SBtE
+69hyOB03N3v4+VG/q+FAvMYfBOgk94FhwnQzNEbT8anR+O83+SY46gO0dqavzmWX
+0g11OnB7XM0KDv3OJgJsiJcQ8EDiya0I1VEZp2s7HW1KjbBHXwmw0JMDsMjGxGU8
+0zP0ATAlxVMK+zeDGxwxmHjen5Nksrq/Iz9MKGrmlaUThIETuKl43nDiShj4y0hR
+8mWRz62ahNua8abzN4IVZHuBxKf8CjduDht7zFWhbp3hiGIa4J8bikIVwICV9TiS
+V3gTBp7En5+NJLpE0DFmT+/g+3RkCujLfYCMsj0bTG/+xD5S+36iYLxTOUvzmhqP
+WYnu18av3ftj+PzPQTSGF9RQeyuJO20w1CMflYLldhmsz5JfkLFWZsS0xcw+BmuL
+djUEdJchqjwal9VoZVtMyEyZW7mYkq707RjSyK/u0+vYlT5EE2MEkVR+OV3H+FiY
+fWD7lURKYibJcjF5YUGPzihCvK/xhk3W6ZdTKBIcGYVrK8jK7razgt8ibzV8HaaJ
+F+HCO2LNjYhVR9g+0jjmOHwmrkn9sNp69YJTUeEHzDmNdzFj3pBj8A1cTte+Sfyw
+Gnk7G13VKuR9K+8ZXd+2sj3I/nDMkyA9j5PNgXEDDMyrci8C1DfuiBRserDNZW39
+C4kCHAQQAQgABgUCT0IhNAAKCRDFDgNwJsOPZlUwD/9HzBz6+0NyouyYRLIuUtKf
+f/nSizB4Ie/1tUGsNj0MUlHKdb+NQy/0EYu50m6gkmc+dQ3w7zzWOxwVTVnz0rzO
+Ko6v+aBTJe3eRQ8HbOjmMogZQidWiIZDwoyhrqszj+fktrO5Z6AjTLsv3cKhbPGW
+dIdNKuyk7jwK+82KaOU9kq8jhcCxNS5yplb1NEY0oiXmcZmvMhnbHh5WeyKrBvA7
+STBRfZw45G3HYiiE1xxTXnWea4xHyOtr7WjiEeTkYACOkDsAX08qS47IYUZHiPp0
+S3aqH6tGOoJtUfpR1wBlBsFgIgGUG2H7NyXjz67RWTCaKXMLeonBmIj0F2b4Lnat
+iHofin+xR06W6uXQvstPVxhRDtd/K8hDhUrf55dJL47508QRjHTo2/UNbZ14285p
+mk80oqdhkhTZlPZnnGd0zBSK59KxOtYFUbFrn7Y2lgjbyG+nz5n30JMQGxs+5n2A
+fHZIt6AK+aZOf05kLbd+ZM3fCLsGXOg1zGvBHEBejggFLThc/IOeXbQHbxCKSxeL
+Cm+Eg8VbPxDaJ05/s2V2dTmbNtpoNx5JXTqFf0JEKGoKU+up8FlP3iHdU7g1lg6T
+Tqez8YqdygmJMPvrwa6KfnBPEkxo1Uk/PhhvFlMF0fM/zuNI8r3Iwsw08XofM4Vf
+6tCGw57UiQ65dAa0567+w4kCHwQwAQIACQUCT5BPGgIdIAAKCRCtA5aIWL9yw5To
+EACvfBsU1XbHmbu99uu8xuUxXu0V4ETRzCgwgp2FN3TP94U7mgbu1CrZ1VmtFoo5
+9qMZOBilbnmnnxkjH/Edr4J8Mdura4zPKWhuPgFbUV0H6Rj5JW5YHzzk62+Zp7L2
+pSF4VYWNaPsYAzW6CjqkNNR7pDqCpc30OsgUUof94k92nn86wrIrykNypfd8dlcY
+FCkPm2f7vz6PDBcZFz9dOR0hNNZSWxMTz2mncuJUeqJg6HonZsmhM2CKbgBYzGgr
+8oT5851aVL9bcdkCuzY2y4KPix4pvupNfNkTh4wgj/sE087422HPxn55RFc7OOe+
+CfKmdTrYPANR7IWaUOpAkWnyPUR7270ZrywbAnItv/yPvJQZgpb4YzTOmlCLSO/J
+1yeg0j4qxVtf759k6OHY8gmHxxLMaJZXO42YZh1bsWpJ4QsL1EgtyNaxGmSzSaEq
+N2FZTXOUoIRfaZF9QiyzUX4zwmF39ubKfOacrBmvciYdQy9Exu5aarzyE6b+/Esr
+WgmkjZ4MwH7N1dC154Ev97ROgHpWRE7YZw/bLiMC7YVThElkuLv0EbF8xC40YnIQ
+mbtXWj9+14Lu+M4BQ7B5DY9n7vLPSs5fI1/MztJccLAxbI/z8j5h5teveTeUjFxZ
+Rbgy1wdFclkp+BG/j3ukTbYyAzaAZHLx1Tt/HkvYT/Lxo4kCPQQTAQgAJwIbAwUJ
+A8JnAAULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAUCT5BPJAAKCRCtA5aIWL9yw5A9
+EACtO57+Z6/rcsWrqcqpqf+vHgbMLbhCx06t8xM1+nq0riWraBdu3VlAffMUZXbk
+8u7McyEuXduBCndagu855PQZgBMehjqWOsvA9WeAOTLBueM/4wMNdZPfItKX5jtj
+b5Xa5lSvjXYL3zX3Zyc+pQOZYm3UoSCBcAsSw36ycJwHKXZ5BY1h2NGKkS7UMMfp
+2PsrVWyVptoXliQZEAzj4ts03t/EUGDiFLfZRLA1BEedBLkrFtye1mLRbhJeMKl3
+sERN9HnpdNKduXBJNsYJGTVmsM0d8JC2t5P+54wr0PVao1kAKIRwvudrcT4wSkzM
+ZTF3CXWV3Tl/MoGC1zbblB20eLytCaQaZLaj2E0D9LSfTDbpSP2RpNDcq5PM4Sd0
+ry4APDRwkUKm/OCptkJhWZmI9CInXHDaTCXIbcTVBn4Ed0V0yPdkwh4lZjHwM8eA
+/4qQx4hwRL7dgptZs6qhfzOdAtsQT21Z7+W2gTjN/XT1VqGMXFFf9zhChlyeM3vi
+F3DI5AWtuuO4TzAeMnn6phiD8tMG1UQNzvOJD5UlyAwpsyhuLmeT4sREFftHfC0b
+1np20DmJwDecPgya2wfxjd1rLuXPD08gZTC46518AHAMW1FdhCSKqBTv2czH1y4t
+/sF3YN7ybRGBmslBl3Uu4fuSZ3tWAyXH4vbgAZrGGeQQw4kCQAQTAQgAKgIbAwUJ
+A8JnAAULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAUCTxHb+QIZAQAKCRCtA5aIWL9y
+w4usD/9TTUBmnkwJmHQzl/OYMp+nJEGSA2O9RpwoYgNTHnt37PJlr0h3tGWN2x3m
+xVSaBW4BfQHYQq1jwBwSo/y2+mp54Dp/OILU3pkqcaQoC2e9X6DbCe7uMMDLv9/U
+q03xNwNNbe87FonnzKI/3q4HSkJjM4GxSI/fxjqw+xJvP1+rQiL5owKQLWJp8gpx
+x68dB3wvY7OgUaG24KQsvaqBbSDhl9NQ7yRQtZgSi16JYUxDcvutb9PnVyHV/WEv
+VfqHjbcSy7wbH/E+Bye2aXzctIXr26B/1q9gixadUgv8ZW1XmG7egJVfJOjJXtJL
+zyyl3HC7hlNdhkYQHxr4iAQnX6403z7LdmV9BPywL+XDwE766Yb9+Mwh241SXuZj
+yWEnWmQUEtYzN+btMbJxeQJOPm1taJ4Y1H7eLrM0sFVg9Ps9ssaemWtV/tNabHyq
+w4XpSR1OkZ51akEh5m9juiwdTGWs4sG7EDPHNc4blAzEsfQMsQbCBQJXxYfbZ8Vh
+HLNg5sZR6Q1C4N/6M7tRZGTMmLrE9yQAzolqEOkA5EPqFgDcL+AQfcdoIij7nMzO
+s7eqspg4ZsMBqF+5hQQkflZggYBj/SUCdVKMDfMNdI4pRYI17KkrVdjf7MoWniBE
+8FulGjtc/QgEOkuRtAytAtG87++W7QKzTYAWqqiEPGKOKRLaCLQ0RGFuaWVsIE1h
+cnTDrSAobXZkYW4pIDxkYW5pZWxtYXJ0aS5kZWJpYW5AZ21haWwuY29tPokCHAQQ
+AQgABgUCT0Ig6AAKCRAbHjgJYzZOpnmSD/9Y6TrJecI5yUhqinshrnDHC27i5bcj
+HVy0z043Igl5vHR1Wo7afWAptG68xG1lhsKLQOc2BTl6r4awRaJMHqPCJSaBHF9q
+ZqC0JN9pvwDxRqnscpw2NdCjPTs8zWOXC/d0PA2kcFH7+eTd0LqjBA7AXlWKnshQ
+ouOX09dkHxVPx/zwQhDhpfyol4h3DDvlGl/24N0xMiV8J8CvPNWmvrPUBWugfY5g
+Xg38Fqcdikjpv4g7DGbM/UoNG+rS6VQ0ohWnICEaExY0v+/zfy4f4fxidGJuAJd3
+CVyOvz81P+O5Pc2WvFyfafntazMs+YendX3S2sMt55ZErJv2oQzHKTARmASpUmV/
+jqU1FnzWXmDiGh8KfnsYP9tEub6w9/xeUSZarhZ+ywx9PALbPI+P5A2BrkKQZhNC
+dqU6sHtX+x4QOxIZZUeeNaUYfNjgbAN1kl9VmReUvP99wJNjbSHYsfku10JDdYLT
+9SCeq6GWzH2aWDwgZ7CPc5UnVOwtvEsKzLRSv/jxSXs5H7TWYjVx1wZY0LVJju4e
+mW5vKEJugVBFheBMfKfqdYmE0oOgGZyPZkP0HSJxqerUK5HGVujmi1MpGkNLr8dG
+HShc4+qr44KNwJfblJ88u7oBVg+kkOXL8bc3/ab6gXS46Y4L7kXQnm2iowWVjNrA
+K5GlpyFWyWDBh4kCHAQQAQgABgUCT0IhNAAKCRDFDgNwJsOPZoUED/45opyVMvRo
+n6yUElpogh6/GxYsCN3dePmed5tI6KZ9F3DVsG0yKJEk2PXIbZr+YahiNPNkQ/Dv
+ylULX9jnht/hKrNvU2ELPGmeaJD1fi1TQkcOmUpUleoAPy61chM4ThAWodYgsQd5
+bD37cIwJk51YwYCsuctaTI4qRbUdr5kZRdgZvOeJ8U+gq5kwj+0kZrZsZdnH3P15
+0VOCCgpEyP6J4iQLDBDepFSAT0n3N1c2bIIeudjqyHypa2WEJtO7IG59bnqamhFq
+BxKXaWQc32nsPfsqPHQDwboJGObyYm2F0LBpZVeuQCIQ/Ubdits5ikscn1Mu8LBt
+dE4iM/4aKwy9+/pnvk2lGZYgSUMjiu4cZoXQ9HTIw0DyoFar8JMvQ5geKGR44+GT
+9A9xRbVZ6KZuKLhnxCL6QkIubnpBMqc+9zM37efFHXM7HvJjlaBFdQjlKVFXzhib
++1d59pmHbZStxOUNr1rOkbiedMA5SKUDBT9FYMTItOU+yjyU0L8YO6o30bDgCOhb
+KuNwsVWB1U68UzaPxl576KI53DcB2Jt9Tq5Mndlh6IRoHnmOxIqzd/Z6KRB89d0f
+JHBcyJcQgMbK+tA1Lp7xoU3BRps7Z6qt8rnn50YEtsicqctsj95gOldtHxG1sOAz
+/2Ys+Obrwa4uo3+gT6l9WINy9kaeIEgaP4kCHwQwAQIACQUCT5BPCgIdIAAKCRCt
+A5aIWL9yw+KAD/912Eljvs2gKBavuYJy9iGFAaYuBHJGRIDKBKTlFI0IkM1VNrT8
+JQw5AIN2QhE6JeHeepDh2qFymi2TFHl62Anfjg1iN7iAjChk/9VGE1qDOj4JjSF9
+bttuI/ZCJAwbKmB41Lpirigj4peOi48htCZ+mck2stTck1rGjGufVBufbKtkKRJZ
+wDHbzO9IAOF3+86+tOguoTPAtXCuR4WVbUijypLnESd6JTjVw8KGiRewVRFgRV67
+MDZhSs/AoEOoTTWhBRPE+qanEDuNyYmNr+aH2sb3iu39z9uUG9VlNkCU52puN2ce
+5BIhHaMcy+W8Bcntx2KLfKJ81xLi1R8Wc/MDuhRgEX4LdZBaxki/zOINVOcZKGfD
+MSiunnC80nKTfx/dACguADfxEWsP38WTn0yFKobmobY1AH3r8eKBz231XQ/qawAd
+mF4Y8P5cxKeoNGrKrS3JX2ULBtgvKOPSph10AdQ2Ko6VtrixRIsG8pe2Q7pu8z/5
+AXYpLKexIK9p/Anu5FG913t72ynxsfAoW2lnod47xw9R2x+eeIQH9T2c8K1y3sn3
++q9Q92WqW6Of+urtmucoTtNzeYVinilAcR6wActB9qOYLlDRkKMRI44/1CT8FEJq
+o6p1AF6/sOrd20+ihA6YFUkw1qNfW/hPXZu4FVK7NN7CXvIetiGYBXxUqokCPQQT
+AQgAJwIbAwUJA8JnAAIeAQIXgAULCQgHAwUVCgkICwUWAgMBAAUCT5BPJAAKCRCt
+A5aIWL9yw7M+D/40qZwFm1YhwzirRQSanmO9ZFdcMiJKQb0lTAaoo+AIApAM0gtg
+n///CfDQFTbZXhFwREdZlgqQfzGpFhoNTjNzokxsVi7ELHL0gVbEmDRrDPs4fgVq
+84cSTashZxK7ndnoLir2l0KvOzPoIBFSjyzBv9QGeuah+awQO3orYAChuGFqcg40
+6XtxLVpfBEiAtBSnSuaZUWPaSYo3l3ApSyqLB6TtiekDlo53Qu17WYrKVU/GC6Ra
+l0W+5kbwx4WyysOFrXsxUIP8lMbrS8n+U2wFB2z4+Ha6og0rzvQjEUt1dK17QBr3
+pJanwlBO7au3MIEXasYXdvO7tlklf7pz5cWN0FxszaFK2iQW88Hs5c8Ut+BvmiUB
+yz79zONZlAiW9RVtsNhd/VlhQkzUYJqQCv8kSYl75ejHjcWg4gRlus07CB/g+Ztl
+E18gt4zDwZoamHoLO0MAUee2QLxbgMyGpY9zQdLUiVrZK91npgMdKJXRqgVDYW4J
+XvQdLNTV42nB8J271kTm7n91atnBqnbPFdIMI1n2qH5h9irHYzNgP8PSnaWAxuac
+UIK4jjUvS3YLrJKzRkSjpG6/qNst4A3tPx9KR6vg3zLsHsp3X10BkEbN45hLzfvv
+o+6SFQsHvjvfSPL5qvbU7q3dZ8I7pqplSl0EtEBYnH7t23rTcds0cvlfR4kCQAQT
+AQgAKgIbAwUJA8JnAAIeAQIXgAULCQgHAwUVCgkICwUWAgMBAAUCTsei+QIZAQAK
+CRCtA5aIWL9yw9cOEACrcP3Z0Hphxv4FwWekd9KjtIs1Dt6KIQUT62VeWMerOFsX
+uWQKBk7vdwG4dxOgbpsWZVRB69n5hWQl6KCHZXkoJ+Djc0IwkvCz2n3Ol264QyrP
+vjINb/cR3pCa6TDwyDVgIy3yWIG5XiP9ZIvuK50v2Z9YAhKh7YP0moMMzDb7aRGO
+I6N1WAyESucfqQa7uCgAnJvyDyqOJTBU8UvqFXip/DeXeMIvv1RnxZWfiQXqkBPa
+QtbPg4/GKvgiat2m4y3rMRxAMf4jG1ZBh+MDfOUY8P2KWw00EjWUOR6UjzoCdFA1
+ZKWHpZ8AsEW8Dx7l5/gt5k2ay/AtL98ksjeGUbFCDQwMrNluMeDz3Igo3j5u1cJC
+MUWDksRHiYa4WKvByc1MmdQq+7WFV5G8QeEJffzYLrr66nCYm10oYOAWPm8UzvwV
+mHDvuqrj1ufk3zwCg0sZbV4PP5fGQ60Acjbz3p4EKsW43rGQenACo5KJkBgyHUvv
+cmIdzqiQHxUWKAiOoS4EMQkHxozO6GxXtkRrZlKj1texGDU7iA78uLQINi853jMZ
+klp0WXw17NUNF4y1imKych1SunoE+yKBQU/K5V5gUbOpw7FzlG/CwUImch+n+41n
+cXd3lxeiZx4k38PCVHZC6x3gD5xRnFWyDuUUfrkBY4HEfgS4eeqqdVp1gD278bkC
+DQROx6FSARAAxoBpYz8uzRvIO+PIQctCQZ20bRBQPjzvXwGbmxFJqFBiIhv7EeeR
+/jkLQWsbcA9DHBSnmtyWRrsyPMdz63JWANEnROXbN4jqG2KmhjDkrH9ap9swgbA6
+3nNbzD80tUZ8T455CL8Q/pUSgBw/D3Cyqv+/BMS18uUUilern6VsZTD5MWF1IqNk
+rKyThjXqa/GkWRAyt6OzvryO4ii8N0YjVmvrlcSuuu/Jem+VeqbAKs7oUR+fQ7zf
+1a9Yly++31ChX60K/mcxtfw/nPyg7ZUtg/0EWgrpzzXIBDf0go8TgLNWaEPSDghw
+WANgQg5lPXekqwCx8d72iYesfPY86yhu/PrzWtKl1EBA1tslTpQmztWfmMob96hJ
+0NxGHQnAZVju3kqFyksiwxNRveQHC1NSxj+ZM6GPS7YThDtT79mbPgOfe7xzYqTP
+m8FFcSBurYz43h2tlERuGO/WzyMN6pxThrPke57qt8BIsHpQM+G6trp/sID9wV4E
+5e/GE4G4qD/OxrbSdURTn8ABIuirBL3UEM9IgqlJ0JegdJkPM7HxgtSCzwhbAH4S
+MJxslV3o3ydiZXgyj0JedlOnV4DvhnAwXy1L0ibnQBn/fbl0d90dMEQPA9xbGI5x
+CG6x79IiM+SgmFH+226jsgpqM+Ywrz42lPQ8+E9XdOnwTyU8G2IGTZcAEQEAAYkC
+JQQYAQgADwUCTsehUgIbDAUJA8JnAAAKCRCtA5aIWL9yw5DoEACI9x048YMFswQh
+95CEWtFXj2iy8SmV1JjIxIJUnrpuQxLyw+rt6IQdRrmAOgzqdFB3XqZCthoR6Ok6
+r5MBgSsW+y/R4wpe+99JxxfI9QX8cT4xtNJURZORt+dpEJqYC47q2tsjzSPyCh4v
+IyztVGZjfI6CSAeDckaxwrcxR4YZGPg5YSCGLCVbBMEGItmujgKpkFQGRGgrcJPM
+4NuvtDyEbuoAkpl+r4WCqsaHbKp1gMEzhgczcnFsI0j6j10Zsunc5AH6eoZd2/Ag
+NNNSb8nv40fT/EybFrnyGkgKJI74+xOxWsGj3nJOJLXA0dRyM80Lsz0y4fY7fRiY
+zWMeBdnEn7ACX1jRTKDIezw573vCqse75OwQ05auAQhS4EPfcco7F48zxkyBNBP2
+d8WrR0U7y+zqUT/tdxnL0rwXg0iXtMDTS2fNqCFhJ7DspWHbGe5ZC8jdb8/QWCJO
+80IxNUKpC8bQZQf+tpAZWLJBuBEE+0EoJHCfwW2a7hFah8OnbomNMOwMVrE/Wgfr
+rBcyvCmk3rt96Fr+RzOkL2Hek6jRfUwPove3duKtW9bnsBJOVFnKmkJNf2vesn51
+pULthGpetS90gK+iyId+RImgdEKKTAOAWE2eQTUpA2F4FUYr4J3GFJUxn0SSg8CR
+qNDN+fXaMIsd+jvDB/oKPZS2i+kn6w==
+=Ckgd
+-----END PGP PUBLIC KEY BLOCK-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121101/8892aef6/attachment.sig>

From lukeshu at sbcglobal.net  Thu Nov  1 14:24:26 2012
From: lukeshu at sbcglobal.net (Luke T. Shumaker)
Date: Thu, 01 Nov 2012 10:24:26 -0400
Subject: [Dev] About DuckDuckGo offer to Parabola...
In-Reply-To: <CAB1_LYO2_iGfDkcCP6uwbT4D1WGwNxMGxP-H+q6BYVWm5Pt0Pw@mail.gmail.com>
References: <5090733A.1000707@lavabit.com>
 <87ehkecm3w.wl%lukeshu@sbcglobal.net>
 <CAB1_LYO2_iGfDkcCP6uwbT4D1WGwNxMGxP-H+q6BYVWm5Pt0Pw@mail.gmail.com>
Message-ID: <87625pcsf9.wl%lukeshu@sbcglobal.net>

At Thu, 1 Nov 2012 11:34:01 +0530,
Prakash Swaminathan wrote:
> 
> Hi Luke,
> 
> >  1. By default, we include "Duck Duck Go (Lite)", *not*
> >     "Duck Duck Go". The non-lite DDG was formerly included, but
> >     removed because it did not meet our policies (point 3 below).
> >
> >     It was my understanding that an effort had been made to work with
> >     you to meet our policies before it was removed.  If not, we would
> >     love to start now.
> >
> 
> Do you remember who you spoke with?

I don't.  The bug report that lead to the removal is
<https://labs.parabola.nu/issues/132>, which doesn't help.  I just
remember someone on IRC telling me that they'd tried talking to you
guys about it.

That said, I also just noticed the HTML-only version, I will add
that.  It still doesn't show adds, but it is a UI-improvement.

> >
> >  2. Does DDG Lite qualify for revenue sharing? AFAICT, DDG Lite does
> >     not include ads, so I would assume "no".
> >
> 
> Yes, there aren't any ads on the Lite version, which rules out revenue
> sharing till we start showing ads, which might take a while.
> 
> 
> >  3. In order for the non-lite DDG to be included in Parabola, all
> >     JavaScript used must be available under a Free Software license,
> >     as defined by the FSF.  Preferrably, it also should get through
> >     the LibreJS browser plugin[1].
> >
> > [1] <http://www.gnu.org/software/librejs/>.
> >
> 
> I think we use YUI, but will need to check.

The YUI code itself is OK (I'm not sure if it gets through LibreJS by
default though, but that's a practical problem, not a policy one).

I you use the YUI compressor, you can force a comment to be preserved
by using '/*! ... */' instead of '/* ... */', to include license
information.  Of course, you'd still have to publish the uncompressed
code elsewhere.

I guess I should clarify too, this refers to all "non-trivial"
javascript.  So for example, poking around, it looks like "b.js",
"d.js", and sometimes "y.js" are JSONP, containing data, not code, so
they are fine.

----

Semi-related:
Please change <duckduckgo.com/opensearch_html.xml> and
<duckduckgo.com/opensearch_lite.xml> to have unique "SortName"
settings, Firefox-based browsers save the file as "shortname.xml",
which makes it impossible for a user to add multiple versions of DDG.

Happy hacking,
~ Luke Shumaker


From mtjm at mtjm.eu  Thu Nov  1 20:17:16 2012
From: mtjm at mtjm.eu (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=)
Date: Thu, 01 Nov 2012 21:17:16 +0100
Subject: [Dev] [RFC] Yet another fullpkg/treepkg/libretools replacement
Message-ID: <87lielulgz.fsf@mtjm.eu>

Hello.  The following long text are my raw notes for deepbuild, a
reimplementation of a part of libretools used for building mips64el
packages that I plan to write.

As these notes should suggest, my main motivation for this project is to
implement solutions of some problems that I personally consider too
difficult to solve in fullpkg and related scripts.  Some other problems
that could be more easily solved using the designs described here might
be just fun to implement, maybe they are not really needed.

I don't remember now the specific problems which motivated me to choose
some of the approaches listed below, so I'm not able to answer "this is
too complex" questions now.

What other problems does this have?  Are there problems with ordering
mips64el builds or processing PKGBUILDs for which these methods would be
bad?


A set of tools for ordered building of Parabola packages.


* TODO to plan
** code modules
** formats of databases, etc
** iterative milestones


* design goals
** in Python 3, GPL3+-licensed
** fast
** easy to maintain
** tested
** documented
** not too Parabola-specific
e.g. should be possible to reuse some parts for a more portable distro

look for clean solutions, don't use hacks specific to how Arch
packages are typically developed (like parsing shell scripts with
regular expressions or comparing build dates)


* host-like object names
could use different names
** master
has the graph, does fetching of sources and packages, sends jobs to
chroots, releases packages
** chroot
just builds a package, doing network communication only with the
master


* TODO abs crawler
(I already have a script for this, it just gets the metadata of
PKGBUILDs in parallel using a separate shell process for each one)

check that it sources the PKGBUILDs in their directories

support quickly and reliably finding which PKGBUILDs were updated, so
it can be automatically done for each invocation of a command using
the database

initially just require running it manually after abs changes


* TODO graph construction
understanding the set of packages to build as a tree leads to complex
code and many potential problems

depends, makedepends and checkdepends for outdated packages

only depends for non-outdated packages (can change their
installability)

a package depends on possibly virtual packages

which package provide a package: use x86_64 pacman dbs for this

packages not in abs are always up to date, mips64el arch=any packages
are an example; get their dependencies from pacman dbs

choosing the provider: ignore ones replaced by other providers, use
the "first" remaining one found

ignore the existence of package conflicts, it will result in a build
failure if it's a problem (otherwise could have a difficult and slow
graph generation algorithm, could not get a single graph for all
outdated packages)


* TODO graph build
a topological sort, could schedule several packages at once at
different chroots (probably on different hosts)

assume all enabled chroots are equal and independent, ignore all the
theory of scheduling

build only already fetched packages, wait until one is fetched if none
are available if the fetcher works (error otherwise)

package fails before build: save the log (i.e. dependency installation
problem)

package fails during build/check/package: save the build directory

package fails: keep building packages which don't depend on it

package succeeds: stage it (also add to a local repo on the chroot)
and save logs


* TODO chroot management
can be remote
** use a local repo
for packages not released yet; keep it on the master
** operations
*** create a chroot, run a job in a chroot
maybe replace mkarchroot

have no network access in the chroot, except to a single program
sending the tasks and the loopback (for package testsuites)

have premade /etc/makepkg.conf and /etc/pacman.conf, use only a single
repo from the master
*** change packages to listed ones (or groups) with dependencies and upgrade
can fail for many reasons, consider them failing the package

problem: might be interactive (parabola-keyring), find a workaround
*** build single package
send a full source package to nonlocal chroots or assume a shared
filesystem?
*** pacman cache management
will introduce multiple packages of the same version, should also
avoid downloading multiple times

do all downloads on master only
*** run an interactive shell


* master directories
** abs trees
multiple ones, equally supported
** released package cache
** unreleased package repo
** staged packages
** graph
** source cache
** configuration
** repo dbs
** abs db
all PKGBUILD metadata + paths to PKGBUILDs
** maybe other databases generated from the above


* TODO caches
each is a content-addressable filesystem (avoiding the common
conflicts of multiple cached files with the same names) with an index
of name -> content mapping (not used for sources unless the user asks
for it: they can handle multiple contents); for packages the newest
one/from the repo db is used

ugly thing: will use multiple hash algorithms, not accepting
collisions on any of them


* TODO make the separate released and unreleased package caches useful as pacman's cache
have a single mirror on the system that's provided by deepbuild?

use the same solution for chroots


* TODO source fetching
** background process fetching specified packages
try to reuse http connections

continue fetching partial files
** notify build-graph after a package is fetched
** use an appropriate order for it
try to always keep a package ready to build, maybe just use a
topological sort of the graph as fetch order

(could use the scheduling theory for this)
** rewrite URLs to use faster mirrors
keep lists of mirrors of important services
** fail a package if sources cannot be fetched
also if the non-URLs files are missing in the tree


* UI
a single command, deepbuild, with subcommands
** TODO make a consistent naming of these
** sync-db
gets the databases for pacman -Sy (for multiple arches) using the
mirrorlist, saves the data in its own format
** sync-abs
gets all PKGBUILD metadata
** make-graph
generate a dependency graph of all outdated packages, specified
packages (i.e. the full graph without parts which aren't needed to
build these packages), or specified packages and all their reverse
dependencies (e.g. for xorg-server ABI changes)

can use different architecture repos to determine outdateness: e.g. to
fix mips64el build problems on x86_64

should determine if the graph is not buildable, e.g. due to cycles or
lack of dependency providers (listing the unarched providers from
another arch)
** build-graph
build packages from the graph
** show-graph
show the graph, what's built and what isn't
** edit-graph
add/remove package, forget a dependency (e.g. to fix a cycle), rebuild
a package (i.e. after fixing it without changing the rest of the
graph, e.g. when fixed a chroot update problem)
** input-graph
the user manually specifies the graph, e.g. for toolchain builds (with
two glibc and two binutils builds)
** fetch-source
fetch sources for the graph, for specified packages or for all
packages
** clean-source
remove sources not for any package in abs

print size statistics
** list-staged
** release
signs the staged packages and releases them to repo

then remove these packages from the staged list

don't do multiple releases at once

is a nontrivial scheduling algorithm needed for this?
** unstage
remove a package/list of packages from the list to be released
** arch-diff
list packages having one arch and not having another one
** clean-packages
like pacman -Sc with support for multiple arches
** clean-local-packages
removes all unreleased local packages
** chroot-shell
** chroot-new
** TODO more commands if needed for the above features


* TODO configuration
- list of abs trees (find an algorithm to determine which one to use
  when more than one has the package)
- list of repos
- list of chroots
- key fingerprint for signing packages
- packager name and email for use in the packages
- lists of repos to use for building packages for a given repo
  (e.g. only multilib has multilib available, only ~user has ~user,
  standard repos have only standard repos)


* TODO Parabola connection settings
PARABOLAHOST=parabola
LIBREDESTDIR=/srv/http/repo/public

have a recommended ssh config in the documentation


* libretools scripts: usefulness for deepbuild and replacements
** abslibre-commit
no need for it; produces useless commit messages and discourages from
using git directly
** add-mips64el
leads to arching packages we don't need; make-graph and arch-diff will
show data needed for this
** aur
out of scope
** buildenv
will use a different chroot management solution
** chcleanup
will manage chroot packages differently
** createworkdir
will automatically create needed directories; will NOT clone abs repos
since users should know and use git and the script won't know what
repos they prefer (e.g. Parabola already has two)
** diff-unfree
out of scope
** fullpkg
separately use make-graph and build-graph
** fullpkg-build
build-graph will perform a similar task with different algorithms
** fullpkg-find
make-graph, completely different algorithm; don't deal with copying
files; split sourcing PKGBUILDs and generating the graph
** is_built
will have something similar internally
** is_unfree
will assume that all packages are free, we don't have (and shouldn't
have) nonfree packages in our abs trees
** lb
useless
** libreaddiff
{make,show,edit}-graph will replace it in a more manageable way
** librebasebuilder
out of scope
** librechroot
will reimplement it
** librecommit
like abslibre-commit
** librediff
use diff manually
** libremakepkg
will reimplement with a different interface
** libremessages
not a script
** libremkchroot
chroot-new
** librerelease
release
** librerepkg
out of scope
** librestage
will be automatically done by build-graph
** libretools.conf
will have defaults in the program and user's configuration file
overriding some settings

won't have these:

- BLACKLIST
- DIFFTOOL
- WORKDIR: just ~/deepbuild
- ARCHES: usually just some specific ones are used
- CHROOTDIR: will have any dirs to specified chroots
- HOOKPRERELEASE
- ABSLIBREGIT
- COMMITCMD: should not have an option with only one supported value
- FULLBUILDCMD
- TORUPATH: will have fixed layout under the workdir
- SIGEXT: only one correct value
- HOOKPKGBUILDMOD
- HOOKLOCALRELEASE: the only example given is obsolete
** mips-add
like add-mips64el
** mips-release
obsolete; will have different local repo handling
** pkgbuild-check-nonfree
like is_unfree
** prtools
not checked how they differ from main tools
** toru
sync-abs and its database will do the part that I need
** toru-info
useful for debugging only?
** toru-path
what does it do?
** toru-utils
not a script
** toru-where
will have a different internal replacement
** treepkg
like fullpkg; will have different algorithms
** updateabslibre
has the problems of createworkdir
** update-cleansystem
won't have the cleansystem file doing upgrade, cleaning and installing
packages on the chroot at once


* distributed package building notes
** why not distcc
- much work done is not building (e.g. tests, non-C/C++ code)
- not all buildsystems support it well (and some don't support it at
  all)
** potential uses
- building a package in a virtual machine instead of a chroot
- building many packages on multiple mips64el machines
- building many packages in multiple i686-hurd virtual machines on an
  SMP host (since Hurd doesn't support SMP yet)


* TODO master-master build notifications
somehow be able to notify all other masters (e.g. via the repo server)

notify of a build starting, failing or ending (separate states:
released or aborted), so other masters will treat it as if it failed
(not building any packages depending on it) until it's released or
aborted
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121101/15346c60/attachment.sig>

From yogesh.powar at gmail.com  Thu Nov  1 06:00:11 2012
From: yogesh.powar at gmail.com (Yogesh Ashok Powar)
Date: Thu, 1 Nov 2012 11:30:11 +0530
Subject: [Dev] Need Dev Access
Message-ID: <20121101060011.GA3500@MasterMint>

Hello All,

I am Yogesh and wants to contribute for Parabola.

Here is my PGP key 
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x8486C2CC6824C4F6

Attaching rsa_pub and its sign.

Thanks
Yogesh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: id_rsa.pub
Type: application/x-mspublisher
Size: 400 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121101/6a8bcd72/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: id_rsa.pub.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121101/6a8bcd72/attachment.sig>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121101/6a8bcd72/attachment-0001.sig>

From prakash at duckduckgo.com  Thu Nov  1 06:04:01 2012
From: prakash at duckduckgo.com (Prakash Swaminathan)
Date: Thu, 1 Nov 2012 11:34:01 +0530
Subject: [Dev] About DuckDuckGo offer to Parabola...
In-Reply-To: <87ehkecm3w.wl%lukeshu@sbcglobal.net>
References: <5090733A.1000707@lavabit.com>
 <87ehkecm3w.wl%lukeshu@sbcglobal.net>
Message-ID: <CAB1_LYO2_iGfDkcCP6uwbT4D1WGwNxMGxP-H+q6BYVWm5Pt0Pw@mail.gmail.com>

Hi Luke,

 1. By default, we include "Duck Duck Go (Lite)", *not*
>     "Duck Duck Go". The non-lite DDG was formerly included, but
>     removed because it did not meet our policies (point 3 below).
>
>     It was my understanding that an effort had been made to work with
>     you to meet our policies before it was removed.  If not, we would
>     love to start now.
>

Do you remember who you spoke with?


>
>  2. Does DDG Lite qualify for revenue sharing? AFAICT, DDG Lite does
>     not include ads, so I would assume "no".
>

Yes, there aren't any ads on the Lite version, which rules out revenue
sharing till we start showing ads, which might take a while.


>  3. In order for the non-lite DDG to be included in Parabola, all
>     JavaScript used must be available under a Free Software license,
>     as defined by the FSF.  Preferrably, it also should get through
>     the LibreJS browser plugin[1].
>
> [1] <http://www.gnu.org/software/librejs/>.
>

I think we use YUI, but will need to check.

In any case, we appreciate the fact that Parabola uses DuckDuckGo as it's
default and would like to send over DuckDuckGo tshirts.

Can you please send over the tshirt sizes and mailing address for the
Parabola dev team?

Kind regards,
Prakash
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121101/6b60a76c/attachment.htm>

From prakash at duckduckgo.com  Fri Nov  2 07:36:12 2012
From: prakash at duckduckgo.com (Prakash Swaminathan)
Date: Fri, 2 Nov 2012 13:06:12 +0530
Subject: [Dev] About DuckDuckGo offer to Parabola...
In-Reply-To: <87625pcsf9.wl%lukeshu@sbcglobal.net>
References: <5090733A.1000707@lavabit.com>
 <87ehkecm3w.wl%lukeshu@sbcglobal.net>
 <CAB1_LYO2_iGfDkcCP6uwbT4D1WGwNxMGxP-H+q6BYVWm5Pt0Pw@mail.gmail.com>
 <87625pcsf9.wl%lukeshu@sbcglobal.net>
Message-ID: <CAB1_LYO1bPpv0iuSpideVhDvTPAWJnNdrwf7UdJ3_Gtkq1KNuw@mail.gmail.com>

Hi Luke,

That said, I also just noticed the HTML-only version, I will add
> that.  It still doesn't show adds, but it is a UI-improvement.
>

Sounds good.


> Semi-related:
> Please change <duckduckgo.com/opensearch_html.xml> and
> <duckduckgo.com/opensearch_lite.xml> to have unique "SortName"
> settings, Firefox-based browsers save the file as "shortname.xml",
> which makes it impossible for a user to add multiple versions of DDG.


Will send it to our engineers.

Please send over your dev teams tshirts sizes and mailing address.

Thanks,
Prakash
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121102/83cf8062/attachment.htm>

From prakash at duckduckgo.com  Fri Nov  2 14:50:13 2012
From: prakash at duckduckgo.com (Prakash Swaminathan)
Date: Fri, 2 Nov 2012 20:20:13 +0530
Subject: [Dev] About DuckDuckGo offer to Parabola...
In-Reply-To: <87625pcsf9.wl%lukeshu@sbcglobal.net>
References: <5090733A.1000707@lavabit.com>
 <87ehkecm3w.wl%lukeshu@sbcglobal.net>
 <CAB1_LYO2_iGfDkcCP6uwbT4D1WGwNxMGxP-H+q6BYVWm5Pt0Pw@mail.gmail.com>
 <87625pcsf9.wl%lukeshu@sbcglobal.net>
Message-ID: <CAB1_LYO6MzxGUMQqXB13ZdH1i3dOpv0TRWSDLVOWkKQTq3NfrA@mail.gmail.com>

> Semi-related:
> Please change <duckduckgo.com/opensearch_html.xml> and
> <duckduckgo.com/opensearch_lite.xml> to have unique "SortName"
> settings, Firefox-based browsers save the file as "shortname.xml",
> which makes it impossible for a user to add multiple versions of DDG.

This is fixed now.

Prakash


From korobkov at fryxell.info  Sun Nov  4 15:40:20 2012
From: korobkov at fryxell.info (Andrey Korobkov)
Date: Sun, 4 Nov 2012 19:40:20 +0400
Subject: [Dev] New mirror
In-Reply-To: <E1SWn5g-00084A-Sn@mx.fryxell.info>
References: <E1SWn5g-00084A-Sn@mx.fryxell.info>
Message-ID: <E1TV2JE-0004EC-01@mx.fryxell.info>

Hello, all

Please, update my mirror server info to this:

# Location: Paris, France
# Responsible: 4096R/177A2DB9EA08BF5D Andrey Korobkov <korobkov at fryxell.info>
# HTTPS cert SHA1 CC:CD:13:03:FD:B6:39:23:5F:15:98:16:CC:76:E3:CD:95:93:56:7F 
Server = https://parabola.fryxell.info/$repo/os/$arch

-- 
Andrey Korobkov


From aurelien at cwb.io  Sun Nov  4 15:59:25 2012
From: aurelien at cwb.io (=?utf-8?Q?Aur=C3=A9lien?=)
Date: Sun, 04 Nov 2012 16:59:25 +0100
Subject: [Dev] New mirror
In-Reply-To: <E1TV2JE-0004EC-01@mx.fryxell.info> (Andrey Korobkov's message of
 "Sun, 4 Nov 2012 19:40:20 +0400")
References: <E1SWn5g-00084A-Sn@mx.fryxell.info>
 <E1TV2JE-0004EC-01@mx.fryxell.info>
Message-ID: <871ug9740y.fsf@cwb.io>

Andrey Korobkov <korobkov at fryxell.info> writes:

> Hello, all
>
> Please, update my mirror server info to this:
>
> # Location: Paris, France
> # Responsible: 4096R/177A2DB9EA08BF5D Andrey Korobkov <korobkov at fryxell.info>
> # HTTPS cert SHA1 CC:CD:13:03:FD:B6:39:23:5F:15:98:16:CC:76:E3:CD:95:93:56:7F 
> Server = https://parabola.fryxell.info/$repo/os/$arch

Done.

Thanks for mirroring!

-- 
Aurelien DESBRIERES
Ride Free! Ride GNU.org


From jorgean at lavabit.com  Tue Nov  6 15:55:16 2012
From: jorgean at lavabit.com (Jorge Araya Navarro)
Date: Tue, 06 Nov 2012 09:55:16 -0600
Subject: [Dev] About DuckDuckGo offer to Parabola...
In-Reply-To: <87objjgkui.fsf@mtjm.eu>
References: <5090733A.1000707@lavabit.com>
 <20121031005707.GA18785@chrysophylax.my.domain> <87objjgkui.fsf@mtjm.eu>
Message-ID: <509932E4.2090601@lavabit.com>

El 31/10/2012 01:29, Micha? Mas?owski escribi?:
>> I think the REVENUE SHARING idea is fine if:
>>
>> 1) We make clear to DDG they have to continue to meet our privacy &
>> freedom goals
> This includes making their JavaScript free so we would recommend their
> main search site, not the Lite one?
>
I agree on that, publishing the Javascript source code as free software 
wouldn't affect DDG at all.
That have to be introduced into the arregment.
-- 
Jorge Araya Navarro
Universitario, idealista y activista del Software Libre.
Siquirres, Lim?n, Costa Rica.
http://swt.encyclomundi.net
Diaspora*: http://diasp.org/u/shackra
identi.ca: http://parlementum.net/sweet
Jabber: shackra at jabberes.org
Skype: ?De ninguna manera, tras de privativo, te esp?an!.
El software privativo en GNU/Linux, al igual que en Windows o en MacOs, 
te hace un ser no-libre. Deja de enga?arte, ??despierta ahora!!:
http://www.gnu.org/distros/free-distros.html
http://replicant.us/about/



From jorgean at lavabit.com  Tue Nov  6 16:01:28 2012
From: jorgean at lavabit.com (Jorge Araya Navarro)
Date: Tue, 06 Nov 2012 10:01:28 -0600
Subject: [Dev] About DuckDuckGo offer to Parabola...
In-Reply-To: <CAB1_LYO1bPpv0iuSpideVhDvTPAWJnNdrwf7UdJ3_Gtkq1KNuw@mail.gmail.com>
References: <5090733A.1000707@lavabit.com>
 <87ehkecm3w.wl%lukeshu@sbcglobal.net>
 <CAB1_LYO2_iGfDkcCP6uwbT4D1WGwNxMGxP-H+q6BYVWm5Pt0Pw@mail.gmail.com>
 <87625pcsf9.wl%lukeshu@sbcglobal.net>
 <CAB1_LYO1bPpv0iuSpideVhDvTPAWJnNdrwf7UdJ3_Gtkq1KNuw@mail.gmail.com>
Message-ID: <50993458.5010001@lavabit.com>

El 02/11/2012 01:36, Prakash Swaminathan escribi?:
> Hi Luke,
>
>     That said, I also just noticed the HTML-only version, I will add
>     that.  It still doesn't show adds, but it is a UI-improvement.
>
>
> Sounds good.
>
>     Semi-related:
>     Please change <duckduckgo.com/opensearch_html.xml
>     <http://duckduckgo.com/opensearch_html.xml>> and
>     <duckduckgo.com/opensearch_lite.xml
>     <http://duckduckgo.com/opensearch_lite.xml>> to have unique "SortName"
>     settings, Firefox-based browsers save the file as "shortname.xml",
>     which makes it impossible for a user to add multiple versions of DDG.
>
>
> Will send it to our engineers.
>
> Please send over your dev teams tshirts sizes and mailing address.
>
> Thanks,
> Prakash
> If your tired of your Internet connection making you a criminal, click 
> here.
> http://www.eff.org/
>
>
> _______________________________________________
> Dev mailing list
> Dev at lists.parabolagnulinux.org
> https://lists.parabolagnulinux.org/mailman/listinfo/dev
Wait, No one else besides me wants a DDG tshirt? T_T
I really want one! :'D
Is ok if I give my shipping address from Miami?
-- 
Jorge Araya Navarro
Universitario, idealista y activista del Software Libre.
Siquirres, Lim?n, Costa Rica.
http://swt.encyclomundi.net
Diaspora*: http://diasp.org/u/shackra
identi.ca: http://parlementum.net/sweet
Jabber: shackra at jabberes.org
Skype: ?De ninguna manera, tras de privativo, te esp?an!.
El software privativo en GNU/Linux, al igual que en Windows o en MacOs, 
te hace un ser no-libre. Deja de enga?arte, ??despierta ahora!!:
http://www.gnu.org/distros/free-distros.html
http://replicant.us/about/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121106/d287c16d/attachment.htm>

From mtjm at mtjm.eu  Wed Nov  7 21:35:27 2012
From: mtjm at mtjm.eu (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=)
Date: Wed, 07 Nov 2012 22:35:27 +0100
Subject: [Dev] Remote Lemote for Parabola development
In-Reply-To: <E1TW33r-0004is-RZ@fencepost.gnu.org> (Richard Stallman's message
 of "Wed, 07 Nov 2012 05:40:43 -0500")
References: <E1TW33r-0004is-RZ@fencepost.gnu.org>
Message-ID: <87zk2t6qqo.fsf@mtjm.eu>

Richard Stallman <rms at gnu.org> writes:

> Would it be useful for the FSF to put a Lemote on the net
> for Parabola development?

I think we need hackers with access (possibly remote) to Lemote machines
who could port important packages with architecture-specific code
(compilers, runtime libraries and tools processing binaries have it;
gcc-go is indirectly required to build some packages, elfutils would
provide useful features in perf which could be used to profile the
graphics performance issues) or fix bugs like the performance issues
affecting all IceWeasel releases since 10.0 or the WebKit crashes (which
occur only in optimized builds).

I don't remember anyone on the IRC channel able and willing to help with
these issues while unable to due to not having a Lemote machine, this
needs specific experience which isn't common here.

We have many outdated packages, when a single developer keeps their
YeeLoong compiling the packages for several days, nearly only ones
having build errors are left outdated (or ones depending on them).  Not
all of them we are able to fix (like newer versions of packages needed
dependencies compiled using gcc-go; IceWeasel).

Many packages fail build due to changes in dependencies (usually glibc
or gcc not accepting some non-standard-compliant code) or due to
requiring Java or other not available yet dependencies.  I think these
would be easier and quicker to fix on x86 machines first.  (Similarly
various issues with the tools we use for building packages.)

There are also the graphics performance issues that no one here can fix
and that most probably need a local machine for debugging.

I have my own YeeLoong and I tried to fix some of the issues I described
above (and fixed some simpler ones).  Opinions of other developers would
be more useful in this case.  I also don't know the wider goals of the
project well, nor the needs of other users.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121107/e942415b/attachment.sig>

From rms at gnu.org  Thu Nov  8 00:44:42 2012
From: rms at gnu.org (Richard Stallman)
Date: Wed, 07 Nov 2012 19:44:42 -0500
Subject: [Dev] Remote Lemote for Parabola development
In-Reply-To: <87zk2t6qqo.fsf@mtjm.eu>
References: <E1TW33r-0004is-RZ@fencepost.gnu.org> <87zk2t6qqo.fsf@mtjm.eu>
Message-ID: <E1TWGEc-00067M-KS@fencepost.gnu.org>

You've given me a lot of information, but no decision.
We have the ability to set up a machine for remote Parabola development.
Should we do so?  Would it be useful?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call



From mtjm at mtjm.eu  Thu Nov  8 07:53:03 2012
From: mtjm at mtjm.eu (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=)
Date: Thu, 08 Nov 2012 08:53:03 +0100
Subject: [Dev] Remote Lemote for Parabola development
In-Reply-To: <E1TWGEc-00067M-KS@fencepost.gnu.org> (Richard Stallman's message
 of "Wed, 07 Nov 2012 19:44:42 -0500")
References: <E1TW33r-0004is-RZ@fencepost.gnu.org> <87zk2t6qqo.fsf@mtjm.eu>
 <E1TWGEc-00067M-KS@fencepost.gnu.org>
Message-ID: <87mwysfs4g.fsf@mtjm.eu>

Richard Stallman <rms at gnu.org> writes:

> You've given me a lot of information, but no decision.
> We have the ability to set up a machine for remote Parabola development.
> Should we do so?  Would it be useful?

Even assuming there will be no new contributors, it should be useful.
Having other developers able to access the build files on it, or to
build packages over the night, would solve some problems we have more
quickly than with it.  Now I remember that this is exactly what we would
need to have LibreOffice packaged.

It would be useful, I support the decision to have it and I can do the
Parabola changes that would be needed for the use I described.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121108/0fa74c34/attachment.sig>

From aurelien at cwb.io  Thu Nov  8 11:01:26 2012
From: aurelien at cwb.io (=?utf-8?Q?Aur=C3=A9lien?=)
Date: Thu, 08 Nov 2012 12:01:26 +0100
Subject: [Dev] Remote Lemote for Parabola development
In-Reply-To: <87mwysfs4g.fsf@mtjm.eu> (=?utf-8?Q?=22Micha=C5=82_Mas=C5=82o?=
 =?utf-8?Q?wski=22's?= message of "Thu,
 08 Nov 2012 08:53:03 +0100")
References: <E1TW33r-0004is-RZ@fencepost.gnu.org> <87zk2t6qqo.fsf@mtjm.eu>
 <E1TWGEc-00067M-KS@fencepost.gnu.org> <87mwysfs4g.fsf@mtjm.eu>
Message-ID: <87y5icz7cp.fsf@cwb.io>

mtjm at mtjm.eu (Micha? Mas?owski) writes:

> Richard Stallman <rms at gnu.org> writes:
>
>> You've given me a lot of information, but no decision.
>> We have the ability to set up a machine for remote Parabola development.
>> Should we do so?  Would it be useful?

Thanks for the help!

> Even assuming there will be no new contributors, it should be useful.
> Having other developers able to access the build files on it, or to
> build packages over the night, would solve some problems we have more
> quickly than with it.  Now I remember that this is exactly what we would
> need to have LibreOffice packaged.

And certainly other stuff like stumpwm ... a yeelong with a stump and
emacs should be great for the users :-)

> It would be useful, I support the decision to have it and I can do the
> Parabola changes that would be needed for the use I described.

It would be useful, I will help you mtjm on some builds too, and afaik
Emulatorman and is brother are ready too.

Now the question is, does libretools can get the keyring or do we have
to modify the libretools.conf gpp ID before building?

-- 
Aurelien DESBRIERES
Ride free! Ride gnu.org


From mvdan at mvdan.cc  Thu Nov  8 16:22:18 2012
From: mvdan at mvdan.cc (Daniel =?iso-8859-1?Q?Mart=ED?=)
Date: Thu, 8 Nov 2012 17:22:18 +0100
Subject: [Dev] Remote Lemote for Parabola development
In-Reply-To: <87y5icz7cp.fsf@cwb.io>
References: <E1TW33r-0004is-RZ@fencepost.gnu.org> <87zk2t6qqo.fsf@mtjm.eu>
 <E1TWGEc-00067M-KS@fencepost.gnu.org> <87mwysfs4g.fsf@mtjm.eu>
 <87y5icz7cp.fsf@cwb.io>
Message-ID: <20121108162218.GC30899@royal>

Hello everyone,

On Thu, Nov 08, 2012 at 12:01:26PM +0100, Aur?lien wrote:
> mtjm at mtjm.eu (Micha? Mas?owski) writes:
> 
> > Richard Stallman <rms at gnu.org> writes:
> >
> >> You've given me a lot of information, but no decision.
> >> We have the ability to set up a machine for remote Parabola development.
> >> Should we do so?  Would it be useful?

It would certainly be :)

> > It would be useful, I support the decision to have it and I can do the
> > Parabola changes that would be needed for the use I described.
> 
> It would be useful, I will help you mtjm on some builds too, and afaik
> Emulatorman and is brother are ready too.

You can count on me as well. Let me know what tasks can get assigned to
me and I'll get to it.

> Now the question is, does libretools can get the keyring or do we have
> to modify the libretools.conf gpp ID before building?

I don't understand your question. parabola-keyring is not
arch-dependent, thus why would we have to worry about it?

Regards.

-- 
Daniel Mart? - mvdan at mvdan.cc - GPG 0x58BF72C3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121108/77995a1f/attachment.sig>

From aurelien at cwb.io  Thu Nov  8 17:20:15 2012
From: aurelien at cwb.io (=?utf-8?Q?Aur=C3=A9lien?=)
Date: Thu, 08 Nov 2012 18:20:15 +0100
Subject: [Dev] Remote Lemote for Parabola development
In-Reply-To: <20121108162218.GC30899@royal> ("Daniel
 \=\?utf-8\?Q\?Mart\=C3\=AD\?\=
 \=\?utf-8\?Q\?\=22's\?\= message of "Thu,
 8 Nov 2012 17:22:18 +0100")
References: <E1TW33r-0004is-RZ@fencepost.gnu.org> <87zk2t6qqo.fsf@mtjm.eu>
 <E1TWGEc-00067M-KS@fencepost.gnu.org> <87mwysfs4g.fsf@mtjm.eu>
 <87y5icz7cp.fsf@cwb.io> <20121108162218.GC30899@royal>
Message-ID: <87txt0ko4w.fsf@cwb.io>

Daniel Mart? <mvdan at mvdan.cc> writes:


> I don't understand your question. parabola-keyring is not
> arch-dependent, thus why would we have to worry about it?

During the build you sign the packages with your gpg at the librerelease
time.

Since it seems there is one machine for a tuples of people, modifying
one by one the /etc/libretools.conf on the key ID sounds weird.

So maybe we will need to redraw libretools.conf to ask for a key inside
the parabola-keyring and not just one known ID.

-- 
Aurelien DESBRIERES
Ride Free! Ride GNU.org


From mtjm at mtjm.eu  Thu Nov  8 17:23:30 2012
From: mtjm at mtjm.eu (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=)
Date: Thu, 08 Nov 2012 18:23:30 +0100
Subject: [Dev] Remote Lemote for Parabola development
In-Reply-To: <87y5icz7cp.fsf@cwb.io> (=?utf-8?Q?=22Aur=C3=A9lien=22's?=
 message of "Thu, 08 Nov 2012 12:01:26 +0100")
References: <E1TW33r-0004is-RZ@fencepost.gnu.org> <87zk2t6qqo.fsf@mtjm.eu>
 <E1TWGEc-00067M-KS@fencepost.gnu.org> <87mwysfs4g.fsf@mtjm.eu>
 <87y5icz7cp.fsf@cwb.io>
Message-ID: <87ip9gf1pp.fsf@mtjm.eu>

> And certainly other stuff like stumpwm ... a yeelong with a stump and
> emacs should be great for the users :-)

We would most probably just need a stable stumpwm PKGBUILD, I haven't
seen it available in non-mips64el Parabola.  Since it's written in
Common Lisp and officially supports CLISP, there should be no problems.
Please don't use this thread for reporting packages you want to have
available, labs.parabola.nu has relevant projects.

> It would be useful, I will help you mtjm on some builds too, and afaik
> Emulatorman and is brother are ready too.

We need to discuss how to determine how we can help.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121108/a5234df1/attachment.sig>

From mtjm at mtjm.eu  Thu Nov  8 17:27:08 2012
From: mtjm at mtjm.eu (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=)
Date: Thu, 08 Nov 2012 18:27:08 +0100
Subject: [Dev] Remote Lemote for Parabola development
In-Reply-To: <87txt0ko4w.fsf@cwb.io> (=?utf-8?Q?=22Aur=C3=A9lien=22's?=
 message of "Thu, 08 Nov 2012 18:20:15 +0100")
References: <E1TW33r-0004is-RZ@fencepost.gnu.org> <87zk2t6qqo.fsf@mtjm.eu>
 <E1TWGEc-00067M-KS@fencepost.gnu.org> <87mwysfs4g.fsf@mtjm.eu>
 <87y5icz7cp.fsf@cwb.io> <20121108162218.GC30899@royal>
 <87txt0ko4w.fsf@cwb.io>
Message-ID: <87ehk4f1jn.fsf@mtjm.eu>

> During the build you sign the packages with your gpg at the librerelease
> time.

With your private key for which the public key should be included in
parabola-keyring.

> Since it seems there is one machine for a tuples of people, modifying
> one by one the /etc/libretools.conf on the key ID sounds weird.

IMO we should use a separate keypair just for packages built on that
machine.

Most libretools load user-specific configuration files, they would
literally answer your question.

> So maybe we will need to redraw libretools.conf to ask for a key inside
> the parabola-keyring and not just one known ID.

I won't publish my private key and I don't want to download the packages
just to sign them (it seems also pointless for security).  I'm also not
convinced that relating the keys to users signing the packages instead
of the machine building them is useful.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121108/ee6bf3db/attachment.sig>

From aurelien at cwb.io  Thu Nov  8 17:40:29 2012
From: aurelien at cwb.io (=?utf-8?Q?Aur=C3=A9lien?=)
Date: Thu, 08 Nov 2012 18:40:29 +0100
Subject: [Dev] Remote Lemote for Parabola development
In-Reply-To: <87ehk4f1jn.fsf@mtjm.eu> (=?utf-8?Q?=22Micha=C5=82_Mas=C5=82o?=
 =?utf-8?Q?wski=22's?= message of "Thu,
 08 Nov 2012 18:27:08 +0100")
References: <E1TW33r-0004is-RZ@fencepost.gnu.org> <87zk2t6qqo.fsf@mtjm.eu>
 <E1TWGEc-00067M-KS@fencepost.gnu.org> <87mwysfs4g.fsf@mtjm.eu>
 <87y5icz7cp.fsf@cwb.io> <20121108162218.GC30899@royal>
 <87txt0ko4w.fsf@cwb.io> <87ehk4f1jn.fsf@mtjm.eu>
Message-ID: <87mwyskn76.fsf@cwb.io>

mtjm at mtjm.eu (Micha? Mas?owski) writes:

>> During the build you sign the packages with your gpg at the librerelease
>> time.
>
> With your private key for which the public key should be included in
> parabola-keyring.
>
>> Since it seems there is one machine for a tuples of people, modifying
>> one by one the /etc/libretools.conf on the key ID sounds weird.
>
> IMO we should use a separate keypair just for packages built on that
> machine.
>
> Most libretools load user-specific configuration files, they would
> literally answer your question.
>
>> So maybe we will need to redraw libretools.conf to ask for a key inside
>> the parabola-keyring and not just one known ID.
>
> I won't publish my private key and I don't want to download the packages
> just to sign them (it seems also pointless for security).  I'm also not
> convinced that relating the keys to users signing the packages instead
> of the machine building them is useful.

Well ... that is why the question, how to make the things for
multi-builder without create a form of security holes?

-- 
Aurelien DESBRIERES
Ride Free! Ride GNU.org


From theguestone at gmail.com  Thu Nov  8 21:20:10 2012
From: theguestone at gmail.com (Guest One)
Date: Thu, 8 Nov 2012 22:20:10 +0100
Subject: [Dev] Simutrans patch for blacklist.git
Message-ID: <CAGEkTWxWdoMWxHc_L1jshFc1F1gChnSbemOq65aBV3X0YEjKKg@mail.gmail.com>

Hi guys,

this is my first patch for blacklist.git:


diff --git a/blacklist.txt b/blacklist.txt
index 8a5988f..2c94c50 100644
--- a/blacklist.txt
+++ b/blacklist.txt
@@ -432,6 +432,9 @@ sdl:sdl-libre:license doesn't mention modification
 sdlmame
 seamonkey:iceape-libre: contains propietary artwork and trademark issues
[[issue384]], points to the unfree addon site [[issue66]]
 sfarkxtc
+simutrans:: non-free license: Artistic license 1.0
+simutrans-pak128:: non-free license: Artistic license 1.0
+simutrans-pak64:: non-free license: Artistic license 1.0
 skype
 skype-call-recorder::only useful with skype installed
 skype-oss


as you can see i have blacklisted simutrans and related packages because
they are released under Artistic License 1.0 (
https://www.gnu.org/licenses/license-list.html#ArtisticLicense ).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121108/2468f680/attachment.htm>

From mtjm at mtjm.eu  Thu Nov  8 21:47:19 2012
From: mtjm at mtjm.eu (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=)
Date: Thu, 08 Nov 2012 22:47:19 +0100
Subject: [Dev] Simutrans patch for blacklist.git
In-Reply-To: <CAGEkTWxWdoMWxHc_L1jshFc1F1gChnSbemOq65aBV3X0YEjKKg@mail.gmail.com>
 (Guest One's message of "Thu, 8 Nov 2012 22:20:10 +0100")
References: <CAGEkTWxWdoMWxHc_L1jshFc1F1gChnSbemOq65aBV3X0YEjKKg@mail.gmail.com>
Message-ID: <87zk2repi0.fsf@mtjm.eu>

> diff --git a/blacklist.txt b/blacklist.txt
> index 8a5988f..2c94c50 100644
> --- a/blacklist.txt
> +++ b/blacklist.txt
> @@ -432,6 +432,9 @@ sdl:sdl-libre:license doesn't mention modification
> ?sdlmame
> ?seamonkey:iceape-libre: contains propietary artwork and trademark
> issues [[issue384]], points to the unfree addon site [[issue66]]
> ?sfarkxtc
> +simutrans:: non-free license: Artistic license 1.0
> +simutrans-pak128:: non-free license: Artistic license 1.0
> +simutrans-pak64:: non-free license: Artistic license 1.0
> ?skype
> ?skype-call-recorder::only useful with skype installed
> ?skype-oss

Applied, thanks.

> as you can see i have blacklisted simutrans and related packages
> because they are released under Artistic License 1.0 (
> https://www.gnu.org/licenses/license-list.html#ArtisticLicense ).

I knew this issue before (implementation reported it on the IRC
channel), I don't know how I haven't noticed that this package was
included in Parabola.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121108/0bf2eed9/attachment.sig>

From emulatorman at lavabit.com  Fri Nov  9 00:51:23 2012
From: emulatorman at lavabit.com (=?ISO-8859-1?Q?Andr=E9_Silva?=)
Date: Thu, 08 Nov 2012 22:51:23 -0200
Subject: [Dev] No left space on device => /home/parabola/dbscripts/get-repos
In-Reply-To: <E1TWZPM-0000b1-EG@rshg054.dnsready.net>
References: <E1TWZPM-0000b1-EG@rshg054.dnsready.net>
Message-ID: <509C538B.3050205@lavabit.com>

"No left space on device" <= it could be the problem related to
parabolaweb that wasn't updated (recent updates) in these days.

On 11/08/2012 07:13 PM, Cron Daemon wrote:
> ==> Retrieving 85 databases
> 2012-11-08 13:13:04 URL:http://repo.parabolagnulinux.org/core/os/i686/core.db.tar.gz [97246/97246] -> "/tmp/get-repos.95HH/core/os/i686/core.db.tar.gz" [1]
> 2012-11-08 13:13:04 URL:http://repo.parabolagnulinux.org/core/os/x86_64/core.db.tar.gz [97270/97270] -> "/tmp/get-repos.95HH/core/os/x86_64/core.db.tar.gz" [1]
> 2012-11-08 13:13:05 URL:http://repo.parabolagnulinux.org/core/os/mips64el/core.db.tar.gz [121368/121368] -> "/tmp/get-repos.95HH/core/os/mips64el/core.db.tar.gz" [1]
> 2012-11-08 13:13:05 URL:http://repo.parabolagnulinux.org/testing/os/i686/testing.db.tar.gz [165374/165374] -> "/tmp/get-repos.95HH/testing/os/i686/testing.db.tar.gz" [1]
> 2012-11-08 13:13:05 URL:http://repo.parabolagnulinux.org/testing/os/x86_64/testing.db.tar.gz [165625/165625] -> "/tmp/get-repos.95HH/testing/os/x86_64/testing.db.tar.gz" [1]
> 2012-11-08 13:13:05 URL:http://repo.parabolagnulinux.org/testing/os/mips64el/testing.db.tar.gz [54131/54131] -> "/tmp/get-repos.95HH/testing/os/mips64el/testing.db.tar.gz" [1]
> 2012-11-08 13:13:06 URL:http://repo.parabolagnulinux.org/extra/os/i686/extra.db.tar.gz [1343009/1343009] -> "/tmp/get-repos.95HH/extra/os/i686/extra.db.tar.gz" [1]
> 2012-11-08 13:13:06 URL:http://repo.parabolagnulinux.org/extra/os/x86_64/extra.db.tar.gz [1342616/1342616] -> "/tmp/get-repos.95HH/extra/os/x86_64/extra.db.tar.gz" [1]
> 2012-11-08 13:13:07 URL:http://repo.parabolagnulinux.org/extra/os/mips64el/extra.db.tar.gz [1321066/1321066] -> "/tmp/get-repos.95HH/extra/os/mips64el/extra.db.tar.gz" [1]
> 2012-11-08 13:13:07 URL:http://repo.parabolagnulinux.org/community/os/i686/community.db.tar.gz [1738325/1738325] -> "/tmp/get-repos.95HH/community/os/i686/community.db.tar.gz" [1]
> 2012-11-08 13:13:08 URL:http://repo.parabolagnulinux.org/community/os/x86_64/community.db.tar.gz [1732004/1732004] -> "/tmp/get-repos.95HH/community/os/x86_64/community.db.tar.gz" [1]
> 2012-11-08 13:13:08 URL:http://repo.parabolagnulinux.org/community/os/mips64el/community.db.tar.gz [1135953/1135953] -> "/tmp/get-repos.95HH/community/os/mips64el/community.db.tar.gz" [1]
> http://repo.parabolagnulinux.org/multilib/os/i686/multilib.db.tar.gz:
> 2012-11-08 13:13:08 ERROR 404: Not Found.
> 2012-11-08 13:13:08 URL:http://repo.parabolagnulinux.org/multilib/os/x86_64/multilib.db.tar.gz [86733/86733] -> "/tmp/get-repos.95HH/multilib/os/x86_64/multilib.db.tar.gz" [1]
> http://repo.parabolagnulinux.org/multilib/os/mips64el/multilib.db.tar.gz:
> 2012-11-08 13:13:08 ERROR 404: Not Found.
> 2012-11-08 13:13:08 URL:http://repo.parabolagnulinux.org/libre/os/i686/libre.db.tar.gz [291452/291452] -> "/tmp/get-repos.95HH/libre/os/i686/libre.db.tar.gz" [1]
> Cannot write to '/tmp/get-repos.95HH/libre/os/x86_64/libre.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/libre/os/mips64el/libre.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/libre-testing/os/i686/libre-testing.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/libre-testing/os/x86_64/libre-testing.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/libre-testing/os/mips64el/libre-testing.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/~fauno/os/i686/~fauno.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/~fauno/os/x86_64/~fauno.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/~fauno/os/mips64el/~fauno.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/~smv/os/i686/~smv.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/~smv/os/x86_64/~smv.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/~smv/os/mips64el/~smv.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/~xihh/os/i686/~xihh.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/~xihh/os/x86_64/~xihh.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/~xihh/os/mips64el/~xihh.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/~mtjm/os/i686/~mtjm.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/~mtjm/os/x86_64/~mtjm.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/~mtjm/os/mips64el/~mtjm.db.tar.gz' (No space left on device).
> http://repo.parabolagnulinux.org/~brendan/os/i686/~brendan.db.tar.gz:
> 2012-11-08 13:13:12 ERROR 404: Not Found.
> Cannot write to '/tmp/get-repos.95HH/~brendan/os/x86_64/~brendan.db.tar.gz' (No space left on device).
> http://repo.parabolagnulinux.org/~brendan/os/mips64el/~brendan.db.tar.gz:
> 2012-11-08 13:13:13 ERROR 404: Not Found.
> Cannot write to '/tmp/get-repos.95HH/~lukeshu/os/i686/~lukeshu.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/~lukeshu/os/x86_64/~lukeshu.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/~lukeshu/os/mips64el/~lukeshu.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/~emulatorman/os/i686/~emulatorman.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/~emulatorman/os/x86_64/~emulatorman.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/~emulatorman/os/mips64el/~emulatorman.db.tar.gz' (No space left on device).
> http://repo.parabolagnulinux.org/~aurelien/os/i686/~aurelien.db.tar.gz:
> 2012-11-08 13:13:14 ERROR 404: Not Found.
> Cannot write to '/tmp/get-repos.95HH/~aurelien/os/x86_64/~aurelien.db.tar.gz' (No space left on device).
> http://repo.parabolagnulinux.org/~aurelien/os/mips64el/~aurelien.db.tar.gz:
> 2012-11-08 13:13:14 ERROR 404: Not Found.
> Cannot write to '/tmp/get-repos.95HH/~jorginho/os/i686/~jorginho.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/~jorginho/os/x86_64/~jorginho.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/~jorginho/os/mips64el/~jorginho.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/~coadde/os/i686/~coadde.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/~coadde/os/x86_64/~coadde.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/~coadde/os/mips64el/~coadde.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/pcr/os/i686/pcr.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/pcr/os/x86_64/pcr.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/pcr/os/mips64el/pcr.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/social/os/i686/social.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/social/os/x86_64/social.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/social/os/mips64el/social.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/gis/os/i686/gis.db.tar.gz' (No space left on device).
> http://repo.parabolagnulinux.org/gis/os/x86_64/gis.db.tar.gz:
> 2012-11-08 13:13:17 ERROR 404: Not Found.
> http://repo.parabolagnulinux.org/gis/os/mips64el/gis.db.tar.gz:
> 2012-11-08 13:13:17 ERROR 404: Not Found.
> Cannot write to '/tmp/get-repos.95HH/artistic/os/i686/artistic.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/artistic/os/x86_64/artistic.db.tar.gz' (No space left on device).
> http://repo.parabolagnulinux.org/artistic/os/mips64el/artistic.db.tar.gz:
> 2012-11-08 13:13:17 ERROR 404: Not Found.
> Cannot write to '/tmp/get-repos.95HH/elementary/os/i686/elementary.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/elementary/os/x86_64/elementary.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/elementary/os/mips64el/elementary.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/kernels/os/i686/kernels.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/kernels/os/x86_64/kernels.db.tar.gz' (No space left on device).
> http://repo.parabolagnulinux.org/kernels/os/mips64el/kernels.db.tar.gz:
> 2012-11-08 13:13:18 ERROR 404: Not Found.
> Cannot write to '/tmp/get-repos.95HH/radio/os/i686/radio.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/radio/os/x86_64/radio.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/radio/os/mips64el/radio.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/security/os/i686/security.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/security/os/x86_64/security.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/security/os/mips64el/security.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/sugar/os/i686/sugar.db.tar.gz' (No space left on device).
> http://repo.parabolagnulinux.org/sugar/os/x86_64/sugar.db.tar.gz:
> 2012-11-08 13:13:19 ERROR 404: Not Found.
> http://repo.parabolagnulinux.org/sugar/os/mips64el/sugar.db.tar.gz:
> 2012-11-08 13:13:19 ERROR 404: Not Found.
> Cannot write to '/tmp/get-repos.95HH/gnu/os/i686/gnu.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/gnu/os/x86_64/gnu.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/gnu/os/mips64el/gnu.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/cross/os/i686/cross.db.tar.gz' (No space left on device).
> Cannot write to '/tmp/get-repos.95HH/cross/os/x86_64/cross.db.tar.gz' (No space left on device).
> http://repo.parabolagnulinux.org/cross/os/mips64el/cross.db.tar.gz:
> 2012-11-08 13:13:20 ERROR 404: Not Found.
> Cannot write to '/tmp/get-repos.95HH/os/i586/connos/connos.db.tar.gz' (No space left on device).
> FINISHED --2012-11-08 13:13:21--
> Total wall clock time: 18s
> Downloaded: 14 files, 9.2M in 3.1s (2.98 MB/s)
> ==> Adding to parabolaweb
> 2012-11-08 16:13:23 -> INFO: Starting repo parsing
> 2012-11-08 16:13:23 -> INFO: Reading repo tarfile /tmp/get-repos.95HH/os/i586/connos/connos.db.tar.gz
> Traceback (most recent call last):
>   File "/srv/http/web/manage.py", line 13, in <module>
>     execute_manager(settings)
>   File "/usr/lib/python2.7/site-packages/django/core/management/__init__.py", line 438, in execute_manager
>     utility.execute()
>   File "/usr/lib/python2.7/site-packages/django/core/management/__init__.py", line 379, in execute
>     self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "/usr/lib/python2.7/site-packages/django/core/management/base.py", line 191, in run_from_argv
>     self.execute(*args, **options.__dict__)
>   File "/usr/lib/python2.7/site-packages/django/core/management/base.py", line 220, in execute
>     output = self.handle(*args, **options)
>   File "/srv/http/web/devel/management/commands/reporead.py", line 71, in handle
>     return read_repo(arch, filename, options)
>   File "/srv/http/web/devel/management/commands/reporead.py", line 517, in read_repo
>     repo, packages = parse_repo(repo_file)
>   File "/srv/http/web/devel/management/commands/reporead.py", line 470, in parse_repo
>     repodb = tarfile.open(repopath, "r")
>   File "/usr/lib/python2.7/tarfile.py", line 1663, in open
>     raise ReadError("file could not be opened successfully")
> tarfile.ReadError: file could not be opened successfully
>
> ==> ERROR: An unknown error has occurred. Exiting...
>
> ==> ERROR: An unknown error has occurred. Exiting...
> _______________________________________________
> Maintenance mailing list
> Maintenance at lists.parabolagnulinux.org
> https://lists.parabolagnulinux.org/mailman/listinfo/maintenance
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121108/bd216c6f/attachment.sig>

From fauno at kiwwwi.com.ar  Fri Nov  9 03:33:34 2012
From: fauno at kiwwwi.com.ar (=?utf-8?Q?Nicol=C3=A1s?= Reynolds)
Date: Fri, 09 Nov 2012 00:33:34 -0300
Subject: [Dev] No left space on device =>
	/home/parabola/dbscripts/get-repos
In-Reply-To: <509C538B.3050205@lavabit.com>
References: <E1TWZPM-0000b1-EG@rshg054.dnsready.net>
 <509C538B.3050205@lavabit.com>
Message-ID: <87pq3n30xd.fsf@kiwwwi.com.ar>

Andr? Silva <emulatorman at lavabit.com> writes:

> "No left space on device" <= it could be the problem related to
> parabolaweb that wasn't updated (recent updates) in these days.

i entered the server today and made cleanup, removed 40gb on old backups :B

-- 
http://kiwwwi.com.ar/pastes/para-cooptar-una-comunidad.markdown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121109/92a835e8/attachment.sig>

From dclark at pobox.com  Fri Nov  9 19:42:03 2012
From: dclark at pobox.com (Daniel Clark)
Date: Fri, 9 Nov 2012 14:42:03 -0500
Subject: [Dev] [lemote] [Fwd: Re: Loongson 3A hardware]
In-Reply-To: <509D425C.1030404@elmundolibre.be>
References: <509D425C.1030404@elmundolibre.be>
Message-ID: <CA+VYMuY5iVTzm3bLijOs=AbLJ8=YiD28nyO8eV78m9rVySW7xg@mail.gmail.com>

I'm getting a sample unit soon to evaluate soon (just did the wire transfer
yesterday), if that goes well I'll probably start selling the Lemote 8133
Loongson3a based laptop.

If I do sell them, I'll get another unit and put it on iKVM [1] and remote
power cycling control to help GNU/Linux distro porting efforts. If I don't,
I'll do the same with the initial unit.

Unfortunately the new units are too expensive for me to give away gratis to
developers (I'll need to sell them at somewhere around $1200), however I'm
thinking of doing something like selling a developer support model, where
people can choose to spend an extra few hundred dollars in order to support
a pool of money that will trigger a donation to a GNU/Linux distro
developer or other person who is known to have done important work (such as
phcoder for GRUB) with Loongson2f hardware.

It's a little bit hard to decipher the below threads, but I think that
Mr. Zhang offered to donate some hardware to some projects. If that is the
case, I'd be happy to work with FSF et al on what the best use of those
machines would be. In addition to gNewSense, Parabola, the GRUB project and
(probably less interesting to the FSF as it's not on their distro list)
Gentoo  could use hardware. I think we are talking somewhere on the order
of 8 people who are active with the older Loongson2f hardware in these
various projects.

[1] http://en.wikipedia.org/wiki/KVM_switch#KVM_over_IP_.28iKVM.29

On Fri, Nov 9, 2012 at 12:50 PM, Sam Geeraerts <samgee at elmundolibre.be>wrote:

>
>
> -------- Original Message --------
> Subject: [Fwd: Re: Loongson 3A hardware]
> Date: Tue, 06 Nov 2012 04:42:59 +0100
> From: Samy Boutayeb
>
> Hi,
> This is a preliminary consultation about your potential interest in the
> porting of a free distribution like GNewSense [1] to the Loongson 3A
> hardware [2]. This project would be inspired by some prior porting
> projects, on similar hardware, as the Yeeloong laptop [3, 4, 5].
> Lemote [6], who helped on the GnewSenseToMips project, donating hardware
> and providing code and documentation, is willing to help again this new
> project with hardware & support (see forwarded message).
>
> Looking forward your comments,
>
> Kind regards,
>
> Samy
>
> [1] www.gnewsense.org
> [2] www.lemote.com/products/computer/yilong/312.html
> [3] www.gnewsense.org/Projects/GNewSenseToMips
> [4] www.gentoo.org/proj/en/base/mips/yeeloong.xml
> [5] ftp.openbsd.org/pub/OpenBSD/5.2/loongson/INSTALL.loongson
> [6] www.lemote.com
>
>
> Dear Samy,
> ? 2012/11/3 19:24, Samy Boutayeb ??:
>
>> Dear Mister Zhang,
>>
>> I am part of the team that is working on your Yeeloong laptop, helping
>> to coordinate a team of contributors to adapt the GNewsense
>> distribution, and to make it available for the Free Software Foundation.
>>
>> Are you interested in the development of a similar project on your
>> hardware using the 3A cpu?
>>
>> How can we help you in such a project?
>>
> FSF talked with me for this, and we would like to have GNewsense support
> too. But we are not yet able to allocate enough people to work on the
> project due to the related limited personal market of our laptops. Most of
> our guys are busy with business/government projects.
>
> If you are so kind to help on this, we can donate some hardwares and
> necessary support materials.
>
> Thank you very much.
>
> yours Fuxin
>
>>
>> Looking forward your answer.
>>
>> Kind regards from France
>>
>> Samy Boutayeb
>>
>>
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121109/4812c3ca/attachment.htm>

From s.boutayeb at free.fr  Fri Nov  9 19:29:45 2012
From: s.boutayeb at free.fr (Samy Boutayeb)
Date: Fri, 09 Nov 2012 20:29:45 +0100
Subject: [Dev] Loongson 3A hardware
Message-ID: <1352489385.25931.16.camel@901d.lan>

Hi,
This is a preliminary consultation about your potential interest in the
porting of a free distribution like GNewSense [1] or Parabola [2] to the
Loongson 3A hardware [3, 4]. This project would be inspired by some
prior porting projects, on similar hardware, as the Yeeloong laptop
[e.g. 5, 6, 7, 8]. Lemote [9], who helped on the GnewSenseToMips
project, donating hardware and providing code and documentation, is
willing to help again this new project with hardware & support (see
forwarded message).

Looking forward your comments,

Kind regards,

Samy

[1] www.gnewsense.org
[2] https://parabolagnulinux.org
[3] www.lemote.com/products/computer/yilong/312.html
[4] http://www.loongson.cn/dev/ftp/doc/01user manual/loongson3a/
[5] www.gnewsense.org/Projects/GNewSenseToMips
[6] www.gentoo.org/proj/en/base/mips/yeeloong.xml
[7] ftp.openbsd.org/pub/OpenBSD/5.2/loongson/INSTALL.loongson
[8] https://wiki.parabolagnulinux.org/MIPS_Installation
[9] www.lemote.com




From mtjm at mtjm.eu  Fri Nov  9 20:38:36 2012
From: mtjm at mtjm.eu (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=)
Date: Fri, 09 Nov 2012 21:38:36 +0100
Subject: [Dev] Loongson 3A hardware
In-Reply-To: <1352489385.25931.16.camel@901d.lan> (Samy Boutayeb's message of
 "Fri, 09 Nov 2012 20:29:45 +0100")
References: <1352489385.25931.16.camel@901d.lan>
Message-ID: <87mwyqfr5f.fsf@mtjm.eu>

> This is a preliminary consultation about your potential interest in the
> porting of a free distribution like GNewSense [1] or Parabola [2] to the
> Loongson 3A hardware [3, 4]. This project would be inspired by some
> prior porting projects, on similar hardware, as the Yeeloong laptop
> [e.g. 5, 6, 7, 8]. Lemote [9], who helped on the GnewSenseToMips
> project, donating hardware and providing code and documentation, is
> willing to help again this new project with hardware & support (see
> forwarded message).

A Parabola port would have at least these problems:

- there is no English documentation for the CPU, none of our developers
  know Chinese

- some other machines with Radeon GPUs have no kernel modesetting
  support (or other important features like suspend and resume) without
  sourceless microcode that we won't provide, we don't know if the chip
  used is affected by this (all Radeons provide no acceleration without
  related microcode, this probably won't be worse than with the GPU of
  the 2F YeeLoong; another issue is that many of our users choose
  YeeLoongs for lack of nonfree VGA BIOS while the 3A machines have one)

It would most probably require more time from the developers, although
this can be solved by us.  Is translation of the documentation planned
(or available, maybe I haven't searched for it well) or are the Radeon
issues better with this chip than usually?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121109/a276b563/attachment.sig>

From djbclark at freedomincluded.com  Fri Nov  9 20:38:47 2012
From: djbclark at freedomincluded.com (Daniel J Clark)
Date: Fri, 9 Nov 2012 15:38:47 -0500
Subject: [Dev] [lemote] [Fwd: Re: Loongson 3A hardware]
In-Reply-To: <CA+VYMuY5iVTzm3bLijOs=AbLJ8=YiD28nyO8eV78m9rVySW7xg@mail.gmail.com>
References: <509D425C.1030404@elmundolibre.be>
 <CA+VYMuY5iVTzm3bLijOs=AbLJ8=YiD28nyO8eV78m9rVySW7xg@mail.gmail.com>
Message-ID: <CAP-QOJfd5Ug+hj15eNSUew_qW0JmRbH=xOtu+Cmf3HnJrYYE=w@mail.gmail.com>

On Fri, Nov 9, 2012 at 2:42 PM, Daniel Clark <dclark at pobox.com> wrote:

> It's a little bit hard to decipher the below threads, but I think that
> Mr. Zhang offered to donate some hardware to some projects. If that is the
> case, I'd be happy to work with FSF et al on what the best use of those
> machines would be. In addition to gNewSense, Parabola, the GRUB project and
> (probably less interesting to the FSF as it's not on their distro list)
> Gentoo  could use hardware. I think we are talking somewhere on the order
> of 8 people who are active with the older Loongson2f hardware in these
> various projects.
>

Oh, and of course linux-libre project / lxo which gNewSense and Parabola
(and optionally used on Gentoo) use.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121109/0d480d2b/attachment.htm>

From s.boutayeb at free.fr  Fri Nov  9 21:20:26 2012
From: s.boutayeb at free.fr (Samy Boutayeb)
Date: Fri, 09 Nov 2012 22:20:26 +0100
Subject: [Dev] Loongson 3A hardware
In-Reply-To: <87mwyqfr5f.fsf@mtjm.eu>
References: <1352489385.25931.16.camel@901d.lan> <87mwyqfr5f.fsf@mtjm.eu>
Message-ID: <1352496026.25931.38.camel@901d.lan>

> A Parabola port would have at least these problems:
> 
> - there is no English documentation for the CPU, none of our developers
>   know Chinese
> 
See [1] where one can find some eventually usefull infos about the cpu
(the actual one is named "3A" and should be followed by an upgrade named
"3B".
As for the machines using this 3A cpu, I am aware of:
- a laptop [2] AKA "Librenote", according to [3],
- a desktop [4], and 
- a server [5].
Another potentially interesting reference seems to be in [6].
Unfortunately, the decompressing of the "linux-3A-notebook.tgz" archive
ends with an "gzip: stdin: unexpectec end of file" message.

> - some other machines with Radeon GPUs have no kernel modesetting
>   support (or other important features like suspend and resume) without
>   sourceless microcode that we won't provide, we don't know if the chip
>   used is affected by this (all Radeons provide no acceleration without
>   related microcode, this probably won't be worse than with the GPU of
>   the 2F YeeLoong; another issue is that many of our users choose
>   YeeLoongs for lack of nonfree VGA BIOS while the 3A machines have one)
> 
> It would most probably require more time from the developers, although
> this can be solved by us.  Is translation of the documentation planned
> (or available, maybe I haven't searched for it well) or are the Radeon
> issues better with this chip than usually?

See [7] where one file is related to the radeonhd gpu. According to the
COPYING file inside the archive, this is under the xorg license from
freedesktop.org)

rgds
samy

[1] http://www.loongson.cn/dev/ftp/doc/01user manual/loongson3a/
[2] http://www.lemote.com/products/computer/yilong/312.html
[3]
www.ourlibreway.org/2011/11/13/lemote-company-8133-librenote-notebook/
[4] http://www.lemote.com/products/computer/fulong/348.html 
[5] http://www.lemote.com/products/computer/hongri/346.html 
[6] http://www.loongson.cn/dev/ftp/os/linux3Anotebook.tgz 
[7] http://www.loongson.cn/dev/ftp/3aXorg/




From mtjm at mtjm.eu  Fri Nov  9 21:55:09 2012
From: mtjm at mtjm.eu (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=)
Date: Fri, 09 Nov 2012 22:55:09 +0100
Subject: [Dev] Loongson 3A hardware
In-Reply-To: <1352496026.25931.38.camel@901d.lan> (Samy Boutayeb's message of
 "Fri, 09 Nov 2012 22:20:26 +0100")
References: <1352489385.25931.16.camel@901d.lan> <87mwyqfr5f.fsf@mtjm.eu>
 <1352496026.25931.38.camel@901d.lan>
Message-ID: <87ip9efnlu.fsf@mtjm.eu>

>> - there is no English documentation for the CPU, none of our developers
>>   know Chinese
>> 
> See [1] where one can find some eventually usefull infos about the cpu
> (the actual one is named "3A" and should be followed by an upgrade named
> "3B".

I trust you that it would be useful for a developer who knows the
language it is written in.

> As for the machines using this 3A cpu, I am aware of:
> - a laptop [2] AKA "Librenote", according to [3],
> - a desktop [4], and 
> - a server [5].

These might answer the "should we buy it?" question, the CPU
documentation is useful later.  Although I haven't seen e.g. a specific
chipset vendor name for the wifi card.

> Another potentially interesting reference seems to be in [6].
> Unfortunately, the decompressing of the "linux-3A-notebook.tgz" archive
> ends with an "gzip: stdin: unexpectec end of file" message.

Very slow download; might be interesting.

> See [7] where one file is related to the radeonhd gpu. According to the
> COPYING file inside the archive, this is under the xorg license from
> freedesktop.org)

The microcode is included with the kernel (and linux-firmware).  All
code run on the main CPU since the kernel starts is free, I don't know
how PMON initializes the display.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121109/00e97594/attachment.sig>

From s.boutayeb at free.fr  Sat Nov 10 11:37:24 2012
From: s.boutayeb at free.fr (Samy Boutayeb)
Date: Sat, 10 Nov 2012 12:37:24 +0100
Subject: [Dev] missing grub-mkfont (grub 2.00) in Yeelong
Message-ID: <1352547444.25931.47.camel@901d.lan>

Hi,
I tried to install grub 2.0 from [1] on a Yeeloong according to [2].
The configure procedure ends with an "error: loongson port needs
grub-mkfont"

Any clue?

Im am using a Yeeloong laptop with GNewSense (and the "gns1 3.6.6-gnu"
kernel) and the parkes repositories in /etc/apt/sources.list .

rgds
samy

[1] http://ftp.gnu.org/grub/
[2]
https://lists.parabolagnulinux.org/pipermail/dev/2012-June/000734.html





From rms at gnu.org  Sat Nov 10 18:26:30 2012
From: rms at gnu.org (Richard Stallman)
Date: Sat, 10 Nov 2012 13:26:30 -0500
Subject: [Dev] [lemote] [Fwd: Re: Loongson 3A hardware]
In-Reply-To: <CA+VYMuY5iVTzm3bLijOs=AbLJ8=YiD28nyO8eV78m9rVySW7xg@mail.gmail.com>
 (message from Daniel Clark on Fri, 9 Nov 2012 14:42:03 -0500)
References: <509D425C.1030404@elmundolibre.be>
 <CA+VYMuY5iVTzm3bLijOs=AbLJ8=YiD28nyO8eV78m9rVySW7xg@mail.gmail.com>
Message-ID: <E1TXFlG-0000zk-7m@fencepost.gnu.org>

    I'm getting a sample unit soon to evaluate soon (just did the wire transfer
    yesterday), if that goes well I'll probably start selling the Lemote 8133
    Loongson3a based laptop.

If you are talking about the Yilong, that has a grave flaw:
the video won't work without a nonfree blob.  Lemote has no interest
in fixing this.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call



From djbclark at freedomincluded.com  Sat Nov 10 20:26:43 2012
From: djbclark at freedomincluded.com (Daniel J Clark)
Date: Sat, 10 Nov 2012 15:26:43 -0500
Subject: [Dev] [lemote] [Fwd: Re: Loongson 3A hardware]
In-Reply-To: <E1TXFlG-0000zk-7m@fencepost.gnu.org>
References: <509D425C.1030404@elmundolibre.be>
 <CA+VYMuY5iVTzm3bLijOs=AbLJ8=YiD28nyO8eV78m9rVySW7xg@mail.gmail.com>
 <E1TXFlG-0000zk-7m@fencepost.gnu.org>
Message-ID: <CAP-QOJc8N0nYeBMs_uKvaY=129FMo5v=w2yF6KZQz3ygnm7bQw@mail.gmail.com>

On Sat, Nov 10, 2012 at 1:26 PM, Richard Stallman <rms at gnu.org> wrote:

>     I'm getting a sample unit soon to evaluate soon (just did the wire
> transfer
>     yesterday), if that goes well I'll probably start selling the Lemote
> 8133
>     Loongson3a based laptop.
>
> If you are talking about the Yilong, that has a grave flaw:
> the video won't work without a nonfree blob.  Lemote has no interest
> in fixing this.
>

Has someone actually tested the notebook with linux-libre?

According to specs the Lemote 8133 (Yilong) has AMD RS780E + SB710 chipset.

According to http://en.wikipedia.org/wiki/AMD_700_chipset_series#780E that
chipset has integrated Radeon HD 3200 video.

According to

http://h-node.org/videocards/view/en/824/Advanced-Micro-Devices--AMD--nee-ATI-RS780--Radeon-HD-3200-/3/1/undef/undef/undef/undef/alphabetically/undef

http://h-node.org/videocards/view/en/274/Advanced-Micro-Devices--AMD--nee-ATI-RS780M-RS780MN--Mobility-Radeon-HD-3200-Graphics-/3/1/undef/undef/undef/undef/alphabetically/undef

Radeon HD 3200 works with linux-libre, which is compiled without

Device Drivers --->
Generic Driver Options --->
 [*]  Include in-kernel firmware blobs in kernel binary
# RadeonHD 2000, 3000, and 4000 series cards:
 (radeon/R600_rlc.bin
                 radeon/R700_rlc.bin) External firmware blobs

Specifically, "works, but without 3D acceleration".

So if this is true for RS780E (the above reports are against
RS780/RS780M/RS780MN) you do get more features if you use nonfree blobs,
but you can just choose to not do that.

Like with the OLPC X01 wireless that would probably make it unendorsable by
you/FSF, but not unusable.

>From a longer term perspective, it looks like the Chinese are developing
their own GPU designs -
http://vr-zone.com/articles/chinese-cpus-are-just-the-beginning...-middle-kingdom-to-go-for-gpus-too/15456.html
-
IMHO it's a better bet that something like that will be used in a Lemote
machine (and not need binary blobs) within the next several years than
Coreboot being preinstalled, or even working well, on Intel-based laptops.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121110/6e1cace0/attachment.htm>

From samgee at elmundolibre.be  Sat Nov 10 21:20:29 2012
From: samgee at elmundolibre.be (Sam Geeraerts)
Date: Sat, 10 Nov 2012 22:20:29 +0100
Subject: [Dev] [Gnewsense-dev] Loongson 3A hardware
In-Reply-To: <1352489385.25931.16.camel@901d.lan>
References: <1352489385.25931.16.camel@901d.lan>
Message-ID: <509EC51D.3020501@elmundolibre.be>

Samy Boutayeb wrote:
> Hi,
> This is a preliminary consultation about your potential interest in the
> porting of a free distribution like GNewSense [1] or Parabola [2] to the
> Loongson 3A hardware [3, 4]. This project would be inspired by some
> prior porting projects, on similar hardware, as the Yeeloong laptop
> [e.g. 5, 6, 7, 8]. Lemote [9], who helped on the GnewSenseToMips
> project, donating hardware and providing code and documentation, is
> willing to help again this new project with hardware & support (see
> forwarded message).

While the machine probably can't be used to its full potential with
gNewSense due to freedom problems with certain components, I'll gladly
accept patches (or hardware) to support it as far as we can.


From samgee at elmundolibre.be  Sat Nov 10 21:34:01 2012
From: samgee at elmundolibre.be (Sam Geeraerts)
Date: Sat, 10 Nov 2012 22:34:01 +0100
Subject: [Dev] [lemote] [Fwd: Re: Loongson 3A hardware]
In-Reply-To: <CA+VYMuY5iVTzm3bLijOs=AbLJ8=YiD28nyO8eV78m9rVySW7xg@mail.gmail.com>
References: <509D425C.1030404@elmundolibre.be>
 <CA+VYMuY5iVTzm3bLijOs=AbLJ8=YiD28nyO8eV78m9rVySW7xg@mail.gmail.com>
Message-ID: <509EC849.90909@elmundolibre.be>

Daniel Clark wrote:
> I'm getting a sample unit soon to evaluate soon (just did the wire transfer
> yesterday), if that goes well I'll probably start selling the Lemote 8133
> Loongson3a based laptop.
> 
> If I do sell them, I'll get another unit and put it on iKVM [1] and remote
> power cycling control to help GNU/Linux distro porting efforts. If I don't,
> I'll do the same with the initial unit.

Interesting. I never worked with iKVM before. I suppose that's single
user access? Does that work with free software?


From samgee at elmundolibre.be  Sat Nov 10 21:40:49 2012
From: samgee at elmundolibre.be (Sam Geeraerts)
Date: Sat, 10 Nov 2012 22:40:49 +0100
Subject: [Dev] [lemote] [Fwd: Re: Loongson 3A hardware]
In-Reply-To: <E1TXFlG-0000zk-7m@fencepost.gnu.org>
References: <509D425C.1030404@elmundolibre.be>
 <CA+VYMuY5iVTzm3bLijOs=AbLJ8=YiD28nyO8eV78m9rVySW7xg@mail.gmail.com>
 <E1TXFlG-0000zk-7m@fencepost.gnu.org>
Message-ID: <509EC9E1.4070100@elmundolibre.be>

Richard Stallman wrote:
>     I'm getting a sample unit soon to evaluate soon (just did the wire transfer
>     yesterday), if that goes well I'll probably start selling the Lemote 8133
>     Loongson3a based laptop.
> 
> If you are talking about the Yilong, that has a grave flaw:
> the video won't work without a nonfree blob.  Lemote has no interest
> in fixing this.

Will Lemote continue producing the Yeeloong until they come up with
something as good or better? If not, does a "second best" currently
exist that's better than the 8133?


From samgee at elmundolibre.be  Sat Nov 10 21:46:20 2012
From: samgee at elmundolibre.be (Sam Geeraerts)
Date: Sat, 10 Nov 2012 22:46:20 +0100
Subject: [Dev] [Gnewsense-dev] missing grub-mkfont (grub 2.00) in Yeelong
In-Reply-To: <1352547444.25931.47.camel@901d.lan>
References: <1352547444.25931.47.camel@901d.lan>
Message-ID: <509ECB2C.80909@elmundolibre.be>

Samy Boutayeb wrote:
> Hi,
> I tried to install grub 2.0 from [1] on a Yeeloong according to [2].
> The configure procedure ends with an "error: loongson port needs
> grub-mkfont"
> 
> Any clue?
> 
> Im am using a Yeeloong laptop with GNewSense (and the "gns1 3.6.6-gnu"
> kernel) and the parkes repositories in /etc/apt/sources.list .

grub-mkfont is part of the grub-common binary package [1].

[1]
http://packages.debian.org/search?searchon=contents&keywords=grub-mkfont&mode=path&suite=stable&arch=any


From rms at gnu.org  Sun Nov 11 04:08:35 2012
From: rms at gnu.org (Richard Stallman)
Date: Sat, 10 Nov 2012 23:08:35 -0500
Subject: [Dev] [lemote] [Fwd: Re: Loongson 3A hardware]
In-Reply-To: <509EC9E1.4070100@elmundolibre.be> (message from Sam Geeraerts on
 Sat, 10 Nov 2012 22:40:49 +0100)
References: <509D425C.1030404@elmundolibre.be>
 <CA+VYMuY5iVTzm3bLijOs=AbLJ8=YiD28nyO8eV78m9rVySW7xg@mail.gmail.com>
 <E1TXFlG-0000zk-7m@fencepost.gnu.org> <509EC9E1.4070100@elmundolibre.be>
Message-ID: <E1TXOqZ-0008Jr-Nu@fencepost.gnu.org>

    Will Lemote continue producing the Yeeloong until they come up with
    something as good or better? If not, does a "second best" currently
    exist that's better than the 8133?

No, and no.

Maybe there will be a new machine next year which uses a documented GPU.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call



From rms at gnu.org  Sun Nov 11 04:08:47 2012
From: rms at gnu.org (Richard Stallman)
Date: Sat, 10 Nov 2012 23:08:47 -0500
Subject: [Dev] [lemote] [Fwd: Re: Loongson 3A hardware]
In-Reply-To: <CAP-QOJc8N0nYeBMs_uKvaY=129FMo5v=w2yF6KZQz3ygnm7bQw@mail.gmail.com>
 (message from Daniel J Clark on Sat, 10 Nov 2012 15:26:43 -0500)
References: <509D425C.1030404@elmundolibre.be>
 <CA+VYMuY5iVTzm3bLijOs=AbLJ8=YiD28nyO8eV78m9rVySW7xg@mail.gmail.com>
 <E1TXFlG-0000zk-7m@fencepost.gnu.org>
 <CAP-QOJc8N0nYeBMs_uKvaY=129FMo5v=w2yF6KZQz3ygnm7bQw@mail.gmail.com>
Message-ID: <E1TXOql-0008MO-Mi@fencepost.gnu.org>

Someone reportedly tried booting gNewSense on this machine, and it did
not run at all.

However, based on this information

    Specifically, "works, but without 3D acceleration".

maybe it is feasible to fix it.  If that is so, it would
be useful if someone tried it.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call



From s.boutayeb at free.fr  Sun Nov 11 10:06:29 2012
From: s.boutayeb at free.fr (s.boutayeb at free.fr)
Date: Sun, 11 Nov 2012 02:06:29 -0800 (PST)
Subject: [Dev] Which graphics chip is used your Loongson hardware?
Message-ID: <86fe42b7-7366-42ba-af0f-2521bfa851fe@k20g2000vbj.googlegroups.com>

Hi,
I would like to know which graphics chip your loongson machine is
using, including the ones using a 3A CPU.

For instance, on a Yeeloong (model 8089) the output of:

lspci | grep VGA

in GNewsense (kernel is 3.6.6-gnu) is:
00:08:0 VGA compatible controller: Silicon Motion, Inc. SM712 LynxEM+
(rev b0)

In OpenBSD (5.2), the output of:

pcidump -v

is:

0:8:0: Silicon Motion LynxEM+
        0x0000: Vendor ID: 126f Product ID: 0712
Thanks in advance
regards
samy



From s.boutayeb at free.fr  Sun Nov 11 10:17:46 2012
From: s.boutayeb at free.fr (Samy Boutayeb)
Date: Sun, 11 Nov 2012 11:17:46 +0100
Subject: [Dev] [Gnewsense-dev] missing grub-mkfont (grub 2.00) in Yeelong
In-Reply-To: <509ECB2C.80909@elmundolibre.be>
References: <1352547444.25931.47.camel@901d.lan>
 <509ECB2C.80909@elmundolibre.be>
Message-ID: <1352629066.31170.4.camel@901d.lan>

Hi Sam,
Le samedi 10 novembre 2012 ? 22:46 +0100, Sam Geeraerts a ?crit :
> Samy Boutayeb wrote:
> > Hi,
> > I tried to install grub 2.0 from [1] on a Yeeloong according to [2].
> > The configure procedure ends with an "error: loongson port needs
> > grub-mkfont"
> > 
> > Any clue?
> > 
> > Im am using a Yeeloong laptop with GNewSense (and the "gns1 3.6.6-gnu"
> > kernel) and the parkes repositories in /etc/apt/sources.list .
> 
> grub-mkfont is part of the grub-common binary package [1].
> 
> [1]
> http://packages.debian.org/search?searchon=contents&keywords=grub-mkfont&mode=path&suite=stable&arch=any
> 

Thanks, I installed grub-common. Now, grub-mkimage is in /usr/bin/

Then, I tried to configure grub-2.00 again. Unfortunately, it ends with
"error: loongson port needs grub-mkfont"

Same result with:
configure --enable-grub-mkfont=no

I will investigate further
rgds
samy



From zhangfx at lemote.com  Sun Nov 11 12:45:40 2012
From: zhangfx at lemote.com (Fuxin Zhang)
Date: Sun, 11 Nov 2012 20:45:40 +0800 (CST)
Subject: [Dev] [loongson-dev] Which graphics chip is used your Loongson
 hardware?
Message-ID: <20051.111.197.106.231.1352637940.squirrel@mail.lemote.com>

> Hi,
> I would like to know which graphics chip your loongson machine is
> using, including the ones using a 3A CPU.
>
Yeeloong 8xxx (based on Loongson2F CPU) uses Silicon Motion 712 as
graphics chip, connected to CPU with PCI bus.

Yeeloong 8133 (based on Loongson3A) uses the embed GPU of AMD RS780
chipset(should be radeon HD 3200). The system bus is Hypertransport.

We used to also use some chips like sis315E, sis6326, XGI z9 etc. in older
models.

If you are interested in detailed information, you can mail me to ask.

Regards

> For instance, on a Yeeloong (model 8089) the output of:
>
> lspci | grep VGA
>
> in GNewsense (kernel is 3.6.6-gnu) is:
> 00:08:0 VGA compatible controller: Silicon Motion, Inc. SM712 LynxEM+
> (rev b0)
>
> In OpenBSD (5.2), the output of:
>
> pcidump -v
>
> is:
>
> 0:8:0: Silicon Motion LynxEM+
>         0x0000: Vendor ID: 126f Product ID: 0712
> Thanks in advance
> regards
> samy
>
> --
> You received this message because you are subscribed to the Google Groups
> "loongson-dev" group.
> To post to this group, send email to loongson-dev at googlegroups.com.
> To unsubscribe from this group, send email to
> loongson-dev+unsubscribe at googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/loongson-dev?hl=en.
>
>




From zhangfx at lemote.com  Sun Nov 11 12:55:21 2012
From: zhangfx at lemote.com (Fuxin Zhang)
Date: Sun, 11 Nov 2012 20:55:21 +0800 (CST)
Subject: [Dev] [lemote] [Fwd: Re: Loongson 3A hardware]
Message-ID: <20196.111.197.106.231.1352638521.squirrel@mail.lemote.com>

> Richard Stallman wrote:
>>     I'm getting a sample unit soon to evaluate soon (just did the wire
>> transfer
>>     yesterday), if that goes well I'll probably start selling the Lemote
>> 8133
>>     Loongson3a based laptop.
>>
>> If you are talking about the Yilong, that has a grave flaw:
>> the video won't work without a nonfree blob.  Lemote has no interest
>> in fixing this.
>
> Will Lemote continue producing the Yeeloong until they come up with
> something as good or better? If not, does a "second best" currently
> exist that's better than the 8133?
>
No grantee for 8133 due to some supply issues as said. But we do have
other pc/server models that can be provided in volume.

8133 is expensive which is also due to the choice of some high-end
technology of components.
>




From dclark at pobox.com  Sun Nov 11 19:08:23 2012
From: dclark at pobox.com (Daniel Clark)
Date: Sun, 11 Nov 2012 14:08:23 -0500
Subject: [Dev] [lemote] [Fwd: Re: Loongson 3A hardware]
In-Reply-To: <20196.111.197.106.231.1352638521.squirrel@mail.lemote.com>
References: <20196.111.197.106.231.1352638521.squirrel@mail.lemote.com>
Message-ID: <CA+VYMubD-V8wucnhoFg+XR+8XD1Xgq11n-SA7PcrZ+B05sPS-A@mail.gmail.com>

On Sun, Nov 11, 2012 at 7:55 AM, Fuxin Zhang <zhangfx at lemote.com> wrote:

> But we do have other pc/server models that can be provided in volume.
>

Are you referring to these?

Spark 3A 6100 split desktop (??3A 6100?????)
Sales Status: upcoming
http://www.lemote.com/products/computer/fulong/348.html

Red Sun 3A 2001 server (?? 3A 2001???)
Sales Status: upcoming
http://www.lemote.com/products/computer/hongri/346.html

>From a FSF point of view I do not think they would be any more interesting
then the 8133 laptop due to use of the same graphics chipset, however the
possibility of 16GB of RAM on the server should be very welcome news to
GNU/Linux distributions trying to compile more complex software - I know
the 2GB limit of the Yeeloong was causing hard problems for some people.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121111/34fa38fd/attachment.htm>

From christophe.jarry at ouvaton.org  Mon Nov 12 07:33:13 2012
From: christophe.jarry at ouvaton.org (christophe.jarry at ouvaton.org)
Date: Mon, 12 Nov 2012 08:33:13 +0100
Subject: [Dev] Lemote Yeeloong 8133: network and wifi cards
Message-ID: <330a6e851d7e037c62558c862239846e.squirrel@webmail.ocsa-data.net>

Hi,

I would like to know which network and wifi cards are in the Lemote
Yeeloong 8133. Do you have more specific information about other
hardware components than those on
http://www.lemote.com/products/computer/yilong/312.html, for instance
company and model of components?

Thank you,

Christophe




From zhangfx at lemote.com  Mon Nov 12 12:04:24 2012
From: zhangfx at lemote.com (Fuxin Zhang)
Date: Mon, 12 Nov 2012 20:04:24 +0800
Subject: [Dev] [lemote] [Fwd: Re: Loongson 3A hardware]
In-Reply-To: <CA+VYMubD-V8wucnhoFg+XR+8XD1Xgq11n-SA7PcrZ+B05sPS-A@mail.gmail.com>
References: <20196.111.197.106.231.1352638521.squirrel@mail.lemote.com>
 <CA+VYMubD-V8wucnhoFg+XR+8XD1Xgq11n-SA7PcrZ+B05sPS-A@mail.gmail.com>
Message-ID: <50A0E5C8.20402@lemote.com>

? 2012/11/12 3:08, Daniel Clark ??:
> On Sun, Nov 11, 2012 at 7:55 AM, Fuxin Zhang <zhangfx at lemote.com
> <mailto:zhangfx at lemote.com>> wrote:
>
>     But we do have other pc/server models that can be provided in volume.
>
>
> Are you referring to these?
>
> Spark 3A 6100 split desktop (??3A 6100?????)
> Sales Status: upcoming
> http://www.lemote.com/products/computer/fulong/348.html
>
> Red Sun 3A 2001 server (?? 3A 2001???)
> Sales Status: upcoming
> http://www.lemote.com/products/computer/hongri/346.html
>
> From a FSF point of view I do not think they would be any more
> interesting then the 8133 laptop due to use of the same graphics
> chipset, however the possibility of 16GB of RAM on the server should
> be very welcome news to GNU/Linux distributions trying to compile more
> complex software - I know the 2GB limit of the Yeeloong was causing
> hard problems for some people.
>
Yes.

Hopefully next year we will have Loongson3A/B/C + Loongson2H as a
chipset. The GPU driver should then be fully free. But no fix schedule
yet(2H is in test).

Regards
Fuxin Zhang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121112/80e68150/attachment.htm>

From christophe.jarry at ouvaton.org  Mon Nov 12 14:33:17 2012
From: christophe.jarry at ouvaton.org (christophe.jarry at ouvaton.org)
Date: Mon, 12 Nov 2012 15:33:17 +0100
Subject: [Dev] [Gnewsense-dev] Lemote Yeeloong 8133: network and wifi
	cards
Message-ID: <8e9335b6da86a62ff455e7a131a9004d.squirrel@webmail.ocsa-data.net>

? 2012/11/12 15:33, christophe.jarry at ouvaton.org ??:
> Hi,
>
> I would like to know which network and wifi cards are in the Lemote
> Yeeloong 8133. Do you have more specific information about other
> hardware components than those on
> http://www.lemote.com/products/computer/yilong/312.html, for instance
> company and model of components?
Network: Realtek , Realtek RTL8111/8168B PCI Express Gigabit Enternet
Wifi:Atheros, Atheros? AR9285
>
> Thank you,
>
> Christophe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121112/5ad70ac3/attachment.html>

From samgee at elmundolibre.be  Mon Nov 12 20:03:54 2012
From: samgee at elmundolibre.be (Sam Geeraerts)
Date: Mon, 12 Nov 2012 21:03:54 +0100
Subject: [Dev] [Gnewsense-dev] missing grub-mkfont (grub 2.00) in Yeelong
In-Reply-To: <1352629066.31170.4.camel@901d.lan>
References: <1352547444.25931.47.camel@901d.lan>	
 <509ECB2C.80909@elmundolibre.be> <1352629066.31170.4.camel@901d.lan>
Message-ID: <50A1562A.4040503@elmundolibre.be>

Samy Boutayeb wrote:
> Thanks, I installed grub-common. Now, grub-mkimage is in /usr/bin/
> 
> Then, I tried to configure grub-2.00 again. Unfortunately, it ends with
> "error: loongson port needs grub-mkfont"
> 
> Same result with:
> configure --enable-grub-mkfont=no

I tried it myself now and configure just works for me. But the error
message concerns the configure flag, not a build dependency. So try with
--enable-grub-mkfont=yes.


From s.boutayeb at free.fr  Mon Nov 12 23:22:02 2012
From: s.boutayeb at free.fr (s.boutayeb at free.fr)
Date: Tue, 13 Nov 2012 00:22:02 +0100
Subject: [Dev] [Gnewsense-dev] missing grub-mkfont (grub 2.00) in Yeelong
In-Reply-To: <50A1562A.4040503@elmundolibre.be>
References: <1352547444.25931.47.camel@901d.lan>
 <509ECB2C.80909@elmundolibre.be> <1352629066.31170.4.camel@901d.lan>
 <50A1562A.4040503@elmundolibre.be>
Message-ID: <1352762522.50a1849aa97fc@imp.free.fr>

Quoting Sam Geeraerts <samgee at elmundolibre.be>:

> Samy Boutayeb wrote:
> > Thanks, I installed grub-common. Now, grub-mkimage is in /usr/bin/
> >
> > Then, I tried to configure grub-2.00 again. Unfortunately, it ends with
> > "error: loongson port needs grub-mkfont"
> >
> > Same result with:
> > configure --enable-grub-mkfont=no
>
> I tried it myself now and configure just works for me. But the error
> message concerns the configure flag, not a build dependency. So try with
> --enable-grub-mkfont=yes.
>
Thanks Sam

The initial attempt to configure grub-2.00 (from http://ftp.gnu.org/gnu/grub/ )
failed, either with --enable-grub-mkfont=no or with --enable-grub-mkfont=yes

Finally, I managed to install grub-yeeloong-bin
(grub-yeeloong_2.00-7_mipsel.deb, from debian/testing) on a Yeeloong with
GnewSense/parkes (kernel 3.6.6-gnu), with following workaround.

apt-get install grub-yeeloong
grub-install /dev/sda1 --directory=/usr/lib/grub/mipsel-loongson/

The issue with the missing "--target" or "--directory" parameter is described in
http://wiki.debian.org/DebianYeeloong/HowTo/Install

and is caused by a bug described in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620420

So, after rebooting the Yeeloong, the grub screen displays as expected.








From lukeshu at sbcglobal.net  Wed Nov 14 18:13:30 2012
From: lukeshu at sbcglobal.net (Luke T. Shumaker)
Date: Wed, 14 Nov 2012 13:13:30 -0500
Subject: [Dev] Forking devtools
Message-ID: <87obj0vyr9.wl%lukeshu@sbcglobal.net>

I mentioned on IRC a while ago that I wanted to fork devtools, but
never explained why.

 1. To help keep the "libretools suite" small.
    devtools:
        42    Total programs installed
    ------------------------------------------------------------------
        30    Programs that are non applicable to Parabola because
              they make assumptions about the architectures and
              repositories supported (we have replacements for them).
	      (note: includes `archbuild`)
         6    Programs that are specific to ABS (won't work with
              ABSLibre or PBS)
    ------------------------------------------------------------------
	 4    Programs that pass the above "smell test", but we don't
              currently use (checkpkg, finddeps, find-libdeps, lddd)
	 2    Programs that we actually take advantage of
              (makechrootpkg, mkarchroot)
    I remember being a newb.  Having all of those can be confusing,
    when you don't know what to use.
 2. To prevent breakage.
    Libretools is pretty tightly coupled with devtools, and has broken
    with devtools updates.  An update to devtools usually requires us
    to change code anyway.
 2. To fix bugs that the Arch devs don't care about.
    `makechrootpkg` can't inherit a chroot lock... because it doesn't
    fit into the archdevs' workflow. This would be useful for
    `libremakepkg`.
 3. To reduce code duplication.
    `librechroot` currently contains code from `archbuild`.  If I
    could simply patch archbuild to be acceptable to Parabola, that
    would be simpler.
 4. To add features.
    I would like to add the ability to prevent a chroot from accessing
    the network.  It would be a 4-line patch to add a flag to do this.

Any objections?

Happy hacking,
~ Luke Shumaker


From s.boutayeb at free.fr  Fri Nov 16 13:26:24 2012
From: s.boutayeb at free.fr (s.boutayeb at free.fr)
Date: Fri, 16 Nov 2012 14:26:24 +0100
Subject: [Dev] A recent rescue image for the Yeeloong
Message-ID: <1353072384.50a63f0025be9@imp.free.fr>

I installed Gentoo on a spare partition of my Yeeloong. Very nice...

The README [1] suggests to use a netboot image for the installation.

Indeed, the netboot-yeeloong.img ( from [2]) may be used alternatively as a
rescue image, and not only as a netboot image, as described in the document.
It's an convenient toolbox, especially with its recent kernel and busybox.

Used as rescue image, you can install it on the internal disk (instead of an usb
stick).

Then, the "/boot/boot.cfg" file should have following lines (assuming that the
/boot partition is on /dev/sda1):

title Rescue/Netboot (from Gentoo)
   kernel (wd0,0)/netboot/netboot-yeeloong.img
   args console=tty no_auto_cmd

Regards,
Samy

[1]
ftp://ftp.free.fr/mirrors/ftp.gentoo.org/experimental/mips/desktop-loongson2f/README
[2]
ftp://ftp.free.fr/mirrors/ftp.gentoo.org/experimental/mips/desktop-loongson2f/


From aurelien at cwb.io  Thu Nov 22 10:46:16 2012
From: aurelien at cwb.io (=?utf-8?Q?Aur=C3=A9lien?=)
Date: Thu, 22 Nov 2012 11:46:16 +0100
Subject: [Dev] gsopcast need a unblacklisted revision
Message-ID: <871uflj4p3.fsf@cwb.io>


Hi,

I've scroll all the code of gsopcast it's all under gpl v2

Any reason to keep it in the blacklist?

-- 
Aurelien DESBRIERES
Ride free! Ride gnu.org


From s.boutayeb at free.fr  Thu Nov 22 18:01:21 2012
From: s.boutayeb at free.fr (s.boutayeb at free.fr)
Date: Thu, 22 Nov 2012 10:01:21 -0800 (PST)
Subject: [Dev] A live CD/USB for loongson hardware
Message-ID: <ef1ba11a-52df-4e15-9fb0-a8afc53888fd@googlegroups.com>

Hi,

I just found in [1] that the loongson hardware may eventually enable the 
execution of a live system (either from an USB drive or from a CD/DVD drive.

See [2], where pmon launches the system from an iso9660 filesystem 

It sounds interesting. However, Im am not sure if this is a new feature 
introduced in the updated pmon, which runs on the recent 3A hardware, or if 
the "old" pmon used in the Fuloong/Yeeloong enables the booting from an 
iso9660 filesystem.

Rgds
samy




[1] http://www.loongson.cn/dev/ftp/os/live_usb/
[2] http://www.loongson.cn/dev/ftp/os/live_usb/readme
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121122/90de4a89/attachment.htm>

From alfplayer at mailoo.org  Fri Nov 23 23:05:11 2012
From: alfplayer at mailoo.org (Esteban Carnevale)
Date: Fri, 23 Nov 2012 20:05:11 -0300
Subject: [Dev] Translations for a VirtualBox freedom patch
Message-ID: <20121123230511.GA378@ab2>

I'm asking for translations of the following string to be included in a VirtualBox patch that warns the user against non-free software.

* Note: We hope you don't use non-free GNU/Linux distros and non-free operating systems, since to use them is to surrender your freedom.

The list of languages to translate is on the table on https://www.virtualbox.org/ticket/2018. Translation of languages not marked as disabled (on the last column) is more important.

Only Spanish and Portuguese have been translated.

How to translate the term "free software": https://www.gnu.org/philosophy/fs-translations.html


From alfplayer at mailoo.org  Sat Nov 24 01:37:35 2012
From: alfplayer at mailoo.org (alfplayer at mailoo.org)
Date: Fri, 23 Nov 2012 22:37:35 -0300
Subject: [Dev] test, disregard
Message-ID: <ef611147e5b61711bef6055fc6206b71@mailoo.org>

 

test, disregard 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121123/5b92dabe/attachment.htm>

From fauno at kiwwwi.com.ar  Sat Nov 24 01:43:28 2012
From: fauno at kiwwwi.com.ar (=?utf-8?Q?Nicol=C3=A1s?= Reynolds)
Date: Fri, 23 Nov 2012 22:43:28 -0300
Subject: [Dev] test, disregard
In-Reply-To: <ef611147e5b61711bef6055fc6206b71@mailoo.org>
References: <ef611147e5b61711bef6055fc6206b71@mailoo.org>
Message-ID: <87ip8vixmn.fsf@kiwwwi.com.ar>

alfplayer at mailoo.org writes:

>  
>
> test, disregard 
>  _______________________________________________

the mailman daemon was down :P

-- 
http://kiwwwi.com.ar/pastes/para-cooptar-una-comunidad.markdown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121123/17a9978b/attachment.sig>

From alonivtsan at gmail.com  Thu Nov 22 11:24:25 2012
From: alonivtsan at gmail.com (alonivtsan)
Date: Thu, 22 Nov 2012 13:24:25 +0200
Subject: [Dev] handbrake-cli uses non free FAAC encoder
Message-ID: <1353583465.4977.5.camel@localhost.localdomain>

Hello,

The package handbrake-cli should be blacklisted in your-freedom package.
A simple test shows this, e.g typing this in the terminal with input
replaced by any video which contains audio
"HandBrakeCLI -i input -o output.mp4" 
shows the output file uses FAAC.

Apparently, handbrake can also use a free AAC encoder now so a libre
version of handbrake-gtk and handbrake-cli might be possible to build.

Best,

Alon.



From alonivtsan at gmail.com  Thu Nov 22 11:30:50 2012
From: alonivtsan at gmail.com (alonivtsan)
Date: Thu, 22 Nov 2012 13:30:50 +0200
Subject: [Dev] [Fwd: handbrake-cli uses non free FAAC encoder]
Message-ID: <1353583850.4977.6.camel@localhost.localdomain>

Sorry meant package "handbrake" instead of "handbrake-gtk"

-------- Forwarded Message --------
> From: alonivtsan <alonivtsan at gmail.com>
> To: dev at list.parabolagnulinux.org
> Subject: handbrake-cli uses non free FAAC encoder
> Date: Thu, 22 Nov 2012 13:24:25 +0200
> 
> Hello,
> 
> The package handbrake-cli should be blacklisted in your-freedom package.
> A simple test shows this, e.g typing this in the terminal with input
> replaced by any video which contains audio
> "HandBrakeCLI -i input -o output.mp4" 
> shows the output file uses FAAC.
> 
> Apparently, handbrake can also use a free AAC encoder now so a libre
> version of handbrake-gtk and handbrake-cli might be possible to build.
> 
> Best,
> 
> Alon.




From mtjm at mtjm.eu  Sat Nov 24 22:11:48 2012
From: mtjm at mtjm.eu (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=)
Date: Sat, 24 Nov 2012 23:11:48 +0100
Subject: [Dev] [RFC] Package freedom requirements clarification
Message-ID: <87a9u67isb.fsf@mtjm.eu>

Hello.

We have many free packages, many new ones added and some being found
nonfree and replaced.  We also get questions why some packages are
included or not, some examples are nonfree game data (ND or NC) and
documentation being a nonfree cultural work (e.g. GNU manuals or POSIX
man pages; I'm probably the only user asking about these).

I haven't found any specific policy clearly explaining what software (or
non-software work) is allowed and what isn't.  The Social Contract?[0]
is sometimes used to explain this, although it provides no answer other
than referring to the FSDG, while we have stricter unwritten
requirements on ND non-functional data.

There are also Parabola- or Arch-specific packaging issues that
obviously aren't explained by the FSDG which I believe should be
documented.

We solve some freedom-related issues on mips64el, while there is
completely no need for this when the x86 ports provide free PKGBUILDs
and sources for packages.

Therefore I propose introducing the four rules listed below so we will
save developers' time by having these policies written and not having
multiple different interpretations of them and by making less changes
mips64el-specific.

0. Do not fetch nonfree sources in PKGBUILDs

I believe this is needed for FSDG compliance.  This can be implemented
using SRCBUILDs or similar technologies.  Having patches containing
whole nontrivial nonfree files in abslibre is IMO also not acceptable.

1. Blacklist source packages/PKGBUILDs, not binary packages

We shouldn't have PKGBUILDs providing non-FSDG packages.  This would
include deprecating rePKGBUILDs.

This change is also needed for the blacklist rewrite I proposed many
months ago.  The recent blacklisting activity and questions for the
reasons why old packages were blacklisted remind me of this being
useful, I will update that proposal.

Some possible benefits:

- all PKGBUILDs are known to have worked at some time

- builds are more reproducible, they don't depend on how the Arch
  packages with nonfree parts were built

- non-x86 ports don't have to do the same changes separately nor merge
  them

- no need to split a PKGBUILD for a single package that was replaced
  (this currently would save much time for mips64el KDE builds)

Why I don't consider rePKGBUILDs important:

- modern non-mips64el machines are fast, while mips64el already needs to
  build the package from source

- we have multiple active x86_64 packages, i686 packages can be built
  too on x86_64 hosts

Examples of affected packages: sqlite, kdebase, kdeutils, kdenetwork.

2. Accept only free cultural works and GNU FDL-licensed documentation

I.e. require all nontrivial non-license works to comply with [1] or [2]
unless they are correctly FDL-licensed documentation (so e.g. a manual
that consists only of invariant sections isn't accepted).

Is there a better way to express our support for free culture without
including too many nonfree works?

3. Provide sources for all packages

We have source tarballs for some packages.  Should these sources be
complete (i.e. so having only abs, all binary packages, the source
tarball and no network access it is possible to build the binary package
From exactly the same source)?  I believe that they should, this might
need VCS packaging standards changes.

This change would benefit from scripts to use our source repos instead
of PKGBUILD-specified mirrors (these aren't always online when repo is,
some URLs have broken while the package needs building on mips64el or is
available on x86), to check the completeness of the source repo and to
upload the source when releasing a package.


Any questions or comments?

[0] https://wiki.parabolagnulinux.org/Parabola/GNU_Linux_Social_Contract
[1] https://www.gnu.org/philosophy/free-sw.html
[2] http://freedomdefined.org/Definition
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121124/94b3c341/attachment.sig>

From hahj87 at gmail.com  Sun Nov 25 01:24:33 2012
From: hahj87 at gmail.com (Joshua Ismael Haase Hernandez)
Date: Sat, 24 Nov 2012 19:24:33 -0600
Subject: [Dev] [RFC] Package freedom requirements clarification
In-Reply-To: <87a9u67isb.fsf@mtjm.eu>
References: <87a9u67isb.fsf@mtjm.eu>
Message-ID: <871ufixyni.fsf@parabola.nu>

I agree with this course of action. One question tough: Would this
require us to maintain a public repo with non-free sources?

Micha? Mas?owski <mtjm at mtjm.eu> writes:

> Hello.
>
> We have many free packages, many new ones added and some being found
> nonfree and replaced.  We also get questions why some packages are
> included or not, some examples are nonfree game data (ND or NC) and
> documentation being a nonfree cultural work (e.g. GNU manuals or POSIX
> man pages; I'm probably the only user asking about these).
>
> I haven't found any specific policy clearly explaining what software (or
> non-software work) is allowed and what isn't.  The Social Contract?[0]
> is sometimes used to explain this, although it provides no answer other
> than referring to the FSDG, while we have stricter unwritten
> requirements on ND non-functional data.

It is true that we have stricter requirements and we should make those
statements public.

> There are also Parabola- or Arch-specific packaging issues that
> obviously aren't explained by the FSDG which I believe should be
> documented.
>
> We solve some freedom-related issues on mips64el, while there is
> completely no need for this when the x86 ports provide free PKGBUILDs
> and sources for packages.
>
> Therefore I propose introducing the four rules listed below so we will
> save developers' time by having these policies written and not having
> multiple different interpretations of them and by making less changes
> mips64el-specific.
>
> 0. Do not fetch nonfree sources in PKGBUILDs
>
> I believe this is needed for FSDG compliance.  This can be implemented
> using SRCBUILDs or similar technologies.  Having patches containing
> whole nontrivial nonfree files in abslibre is IMO also not acceptable.
>
> 1. Blacklist source packages/PKGBUILDs, not binary packages
>
> We shouldn't have PKGBUILDs providing non-FSDG packages.  This would
> include deprecating rePKGBUILDs.
>
> This change is also needed for the blacklist rewrite I proposed many
> months ago.  The recent blacklisting activity and questions for the
> reasons why old packages were blacklisted remind me of this being
> useful, I will update that proposal.
>
> Some possible benefits:
>
> - all PKGBUILDs are known to have worked at some time
>
> - builds are more reproducible, they don't depend on how the Arch
>   packages with nonfree parts were built
>
> - non-x86 ports don't have to do the same changes separately nor merge
>   them
>
> - no need to split a PKGBUILD for a single package that was replaced
>   (this currently would save much time for mips64el KDE builds)
>
> Why I don't consider rePKGBUILDs important:
>
> - modern non-mips64el machines are fast, while mips64el already needs to
>   build the package from source
>
> - we have multiple active x86_64 packages, i686 packages can be built
>   too on x86_64 hosts
>
> Examples of affected packages: sqlite, kdebase, kdeutils, kdenetwork.
>
> 2. Accept only free cultural works and GNU FDL-licensed documentation
>
> I.e. require all nontrivial non-license works to comply with [1] or [2]
> unless they are correctly FDL-licensed documentation (so e.g. a manual
> that consists only of invariant sections isn't accepted).
>
> Is there a better way to express our support for free culture without
> including too many nonfree works?
>
> 3. Provide sources for all packages
>
> We have source tarballs for some packages.  Should these sources be
> complete (i.e. so having only abs, all binary packages, the source
> tarball and no network access it is possible to build the binary package
> From exactly the same source)?  I believe that they should, this might
> need VCS packaging standards changes.
>
> This change would benefit from scripts to use our source repos instead
> of PKGBUILD-specified mirrors (these aren't always online when repo is,
> some URLs have broken while the package needs building on mips64el or is
> available on x86), to check the completeness of the source repo and to
> upload the source when releasing a package.
>
>
> Any questions or comments?
>
> [0] https://wiki.parabolagnulinux.org/Parabola/GNU_Linux_Social_Contract
> [1] https://www.gnu.org/philosophy/free-sw.html
> [2] http://freedomdefined.org/Definition
> _______________________________________________
> Dev mailing list
> Dev at lists.parabolagnulinux.org
> https://lists.parabolagnulinux.org/mailman/listinfo/dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121124/e28ff9fb/attachment.sig>

From lukeshu at sbcglobal.net  Sun Nov 25 05:27:24 2012
From: lukeshu at sbcglobal.net (Luke T. Shumaker)
Date: Sun, 25 Nov 2012 00:27:24 -0500
Subject: [Dev] [RFC] Package freedom requirements clarification
In-Reply-To: <87a9u67isb.fsf@mtjm.eu>
References: <87a9u67isb.fsf@mtjm.eu>
Message-ID: <87haoemev7.wl%lukeshu@sbcglobal.net>

At Sat, 24 Nov 2012 23:11:48 +0100,
Micha? Mas?owski wrote:
> 0. Do not fetch nonfree sources in PKGBUILDs
> 
> I believe this is needed for FSDG compliance.  This can be implemented
> using SRCBUILDs or similar technologies.  Having patches containing
> whole nontrivial nonfree files in abslibre is IMO also not acceptable.

I'd like to change this to:

 0.1. There should be no nonfree code by the end of `makepkg -o`"
 0.2. Nothing nonfree should be tracked in ABSLibre/PBS

Right now 0.1 means what you have; but the next version of makepkg
offers a `prepare()` function to prepare the sources.  It works exactly
like our `mksource()` (currently deprecated in favor of `SRCBUILD`).

I added 0.2 to mean that there can't be a patch file containing
non-free code.  Which means that we must use `rm` and friends to
remove non-free code; which is fine in most cases.

> 3. Provide sources for all packages
> 
> We have source tarballs for some packages.  Should these sources be
> complete (i.e. so having only abs, all binary packages, the source
> tarball and no network access it is possible to build the binary package
> From exactly the same source)?  I believe that they should, this might
> need VCS packaging standards changes.
> 
> This change would benefit from scripts to use our source repos instead
> of PKGBUILD-specified mirrors (these aren't always online when repo is,
> some URLs have broken while the package needs building on mips64el or is
> available on x86), to check the completeness of the source repo and to
> upload the source when releasing a package.

I think our policy is actually to do that (documented somewhere; not
the contract), but we don't :P

I think that this is something that we should implement using our
tools.  I'm currently working on both libretools and PBS; this is
something I will consider.

Happy hacking,
~ Luke Shumaker


From mtjm at mtjm.eu  Sun Nov 25 10:29:46 2012
From: mtjm at mtjm.eu (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=)
Date: Sun, 25 Nov 2012 11:29:46 +0100
Subject: [Dev] [RFC] Package freedom requirements clarification
In-Reply-To: <87haoemev7.wl%lukeshu@sbcglobal.net> (Luke T. Shumaker's message
 of "Sun, 25 Nov 2012 00:27:24 -0500")
References: <87a9u67isb.fsf@mtjm.eu> <87haoemev7.wl%lukeshu@sbcglobal.net>
Message-ID: <87d2z2rn51.fsf@mtjm.eu>

>> 0. Do not fetch nonfree sources in PKGBUILDs
>> 
>> I believe this is needed for FSDG compliance.  This can be implemented
>> using SRCBUILDs or similar technologies.  Having patches containing
>> whole nontrivial nonfree files in abslibre is IMO also not acceptable.
>
> I'd like to change this to:
>
>  0.1. There should be no nonfree code by the end of `makepkg -o`"
>  0.2. Nothing nonfree should be tracked in ABSLibre/PBS

It's the same, more explicit.

> Right now 0.1 means what you have; but the next version of makepkg
> offers a `prepare()` function to prepare the sources.  It works exactly
> like our `mksource()` (currently deprecated in favor of `SRCBUILD`).

The documentation suggests it being used after the source is extracted,
while mksource and SRCBUILDs do this to make the source archive used for
builds.  Does this mean that our source mirrors would provide the
nonfree files removed in prepare()?

> I added 0.2 to mean that there can't be a patch file containing
> non-free code.  Which means that we must use `rm` and friends to
> remove non-free code; which is fine in most cases.

True.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121125/54607310/attachment.sig>

From mtjm at mtjm.eu  Sun Nov 25 10:31:28 2012
From: mtjm at mtjm.eu (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=)
Date: Sun, 25 Nov 2012 11:31:28 +0100
Subject: [Dev] [RFC] Package freedom requirements clarification
In-Reply-To: <871ufixyni.fsf@parabola.nu> (Joshua Ismael Haase Hernandez's
 message of "Sat, 24 Nov 2012 19:24:33 -0600")
References: <87a9u67isb.fsf@mtjm.eu> <871ufixyni.fsf@parabola.nu>
Message-ID: <878v9qrn27.fsf@mtjm.eu>

> I agree with this course of action. One question tough: Would this
> require us to maintain a public repo with non-free sources?

It wouldn't, we would provide the sources with nonfree parts removed,
like Debian does (they too have rules to remove them in their packages).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121125/edc743b9/attachment.sig>

From lukeshu at sbcglobal.net  Sun Nov 25 20:47:22 2012
From: lukeshu at sbcglobal.net (Luke T. Shumaker)
Date: Sun, 25 Nov 2012 15:47:22 -0500
Subject: [Dev] [RFC] Package freedom requirements clarification
In-Reply-To: <87d2z2rn51.fsf@mtjm.eu>
References: <87a9u67isb.fsf@mtjm.eu> <87haoemev7.wl%lukeshu@sbcglobal.net>
 <87d2z2rn51.fsf@mtjm.eu>
Message-ID: <87boelmmud.wl%lukeshu@sbcglobal.net>

At Sun, 25 Nov 2012 11:29:46 +0100,
Micha? Mas?owski wrote:
> 
> > > 0. Do not fetch nonfree sources in PKGBUILDs
> > > 
> > > I believe this is needed for FSDG compliance.  This can be implemented
> > > using SRCBUILDs or similar technologies.  Having patches containing
> > > whole nontrivial nonfree files in abslibre is IMO also not acceptable.
> >
> > I'd like to change this to:
> >
> >  0.1. There should be no nonfree code by the end of `makepkg -o`"
> >  0.2. Nothing nonfree should be tracked in ABSLibre/PBS
> 
> It's the same, more explicit.
> 
> > Right now 0.1 means what you have; but the next version of makepkg
> > offers a `prepare()` function to prepare the sources.  It works exactly
> > like our `mksource()` (currently deprecated in favor of `SRCBUILD`).
> 
> The documentation suggests it being used after the source is extracted,
> while mksource and SRCBUILDs do this to make the source archive used for
> builds.  Does this mean that our source mirrors would provide the
> nonfree files removed in prepare()?

I didn't think about that.  Our source mirrors would mirror the
nonfree files.  (But do we even do source mirrors in most cases?)

I guess the question is:

  Can we download and distribute non-free code, if it is immediately
  deleted at the beginning of the build process?

The only relevent part of FSDG that I could find is:

  A free system distribution must not steer users towards obtaining
  any nonfree information for practical use, or encourage them to do
  so.

So, I think that it is at least ok by FSDG, as the non-free code isn't
being obtained for "practical use".

If we decide that we can't, I will contact the pacman devs and discuss
getting `makepkg --allsource` run `prepare()`.

> > I added 0.2 to mean that there can't be a patch file containing
> > non-free code.  Which means that we must use `rm` and friends to
> > remove non-free code; which is fine in most cases.
> 
> True.

Happy hacking,
~ Luke Shumaker


From mtjm at mtjm.eu  Sun Nov 25 21:00:25 2012
From: mtjm at mtjm.eu (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=)
Date: Sun, 25 Nov 2012 22:00:25 +0100
Subject: [Dev] [RFC] Package freedom requirements clarification
In-Reply-To: <87boelmmud.wl%lukeshu@sbcglobal.net> (Luke T. Shumaker's message
 of "Sun, 25 Nov 2012 15:47:22 -0500")
References: <87a9u67isb.fsf@mtjm.eu> <87haoemev7.wl%lukeshu@sbcglobal.net>
 <87d2z2rn51.fsf@mtjm.eu> <87boelmmud.wl%lukeshu@sbcglobal.net>
Message-ID: <87zk25qtxy.fsf@mtjm.eu>

> I didn't think about that.  Our source mirrors would mirror the
> nonfree files.  (But do we even do source mirrors in most cases?)

We have to distribute the source of GPL-licensed software, it would be
useful (and simpler) to distribute source of all our packages.

> I guess the question is:
>
>   Can we download and distribute non-free code, if it is immediately
>   deleted at the beginning of the build process?

I don't want to assume that all this nonfree code has licenses allowing
us to distribute it (e.g. some has no license or invalid ones like
mixing GPL with incompatible licenses).  It would also prevent users
From legally selling CDs with our binary and source packages (since some
of this nonfree code disallows selling), while we want to support this
use.

> The only relevent part of FSDG that I could find is:
>
>   A free system distribution must not steer users towards obtaining
>   any nonfree information for practical use, or encourage them to do
>   so.
>
> So, I think that it is at least ok by FSDG, as the non-free code isn't
> being obtained for "practical use".

There is also this definition:

  ?Information for practical use? includes software, documentation,
  fonts, and other data that has direct functional applications. It does
  not include artistic works that have an aesthetic (rather than
  functional) purpose, or statements of opinion or judgment.

At least some of this nonfree code certainly have "direct functional
applications" despite not being used for them in free systems.

> If we decide that we can't, I will contact the pacman devs and discuss
> getting `makepkg --allsource` run `prepare()`.

+1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121125/fdadbff9/attachment.sig>

From fauno at kiwwwi.com.ar  Sun Nov 25 22:23:41 2012
From: fauno at kiwwwi.com.ar (=?utf-8?Q?Nicol=C3=A1s?= Reynolds)
Date: Sun, 25 Nov 2012 19:23:41 -0300
Subject: [Dev] [RFC] Package freedom requirements clarification
In-Reply-To: <87a9u67isb.fsf@mtjm.eu>
References: <87a9u67isb.fsf@mtjm.eu>
Message-ID: <87k3t9gw42.fsf@kiwwwi.com.ar>

Micha? Mas?owski <mtjm at mtjm.eu> writes:

> Hello.
>
> We have many free packages, many new ones added and some being found
> nonfree and replaced.  We also get questions why some packages are
> included or not, some examples are nonfree game data (ND or NC) and
> documentation being a nonfree cultural work (e.g. GNU manuals or POSIX
> man pages; I'm probably the only user asking about these).
> 
> I haven't found any specific policy clearly explaining what software (or
> non-software work) is allowed and what isn't.  The Social Contract?[0]
> is sometimes used to explain this, although it provides no answer other
> than referring to the FSDG, while we have stricter unwritten
> requirements on ND non-functional data.
>
> There are also Parabola- or Arch-specific packaging issues that
> obviously aren't explained by the FSDG which I believe should be
> documented.
>
> We solve some freedom-related issues on mips64el, while there is
> completely no need for this when the x86 ports provide free PKGBUILDs
> and sources for packages.
>
> Therefore I propose introducing the four rules listed below so we will
> save developers' time by having these policies written and not having
> multiple different interpretations of them and by making less changes
> mips64el-specific.
>
> 0. Do not fetch nonfree sources in PKGBUILDs
>
> I believe this is needed for FSDG compliance.  This can be implemented
> using SRCBUILDs or similar technologies.  Having patches containing
> whole nontrivial nonfree files in abslibre is IMO also not acceptable.

+1 

> 1. Blacklist source packages/PKGBUILDs, not binary packages
>
> We shouldn't have PKGBUILDs providing non-FSDG packages.  This would
> include deprecating rePKGBUILDs.
>
> This change is also needed for the blacklist rewrite I proposed many
> months ago.  The recent blacklisting activity and questions for the
> reasons why old packages were blacklisted remind me of this being
> useful, I will update that proposal.

i think this should be coded into PBS:

* we'll get pkgbuild updates directly from upstream and merge them with
  our freedom-related and/or port changes

* this can be done by automated tools so it's less boring work for us
  and the intermediate probably-unfree-steering pkgbuilds won't be
  published

* your listed benefits

> Some possible benefits:
>
> - all PKGBUILDs are known to have worked at some time
>
> - builds are more reproducible, they don't depend on how the Arch
>   packages with nonfree parts were built
>
> - non-x86 ports don't have to do the same changes separately nor merge
>   them
>
> - no need to split a PKGBUILD for a single package that was replaced
>   (this currently would save much time for mips64el KDE builds)
>
> Why I don't consider rePKGBUILDs important:
>
> - modern non-mips64el machines are fast, while mips64el already needs to
>   build the package from source
>
> - we have multiple active x86_64 packages, i686 packages can be built
>   too on x86_64 hosts
>
> Examples of affected packages: sqlite, kdebase, kdeutils, kdenetwork.
>
> 2. Accept only free cultural works and GNU FDL-licensed documentation
>
> I.e. require all nontrivial non-license works to comply with [1] or [2]
> unless they are correctly FDL-licensed documentation (so e.g. a manual
> that consists only of invariant sections isn't accepted).
>
> Is there a better way to express our support for free culture without
> including too many nonfree works?

discussing freedom related issues with upstream (without trolling) is
better. we had discussed this with encyclomundi when the syslog-ng guys
got angry because we blacklisted them iirc, and also guestone reported a
mislicensed art for a game that would go unnoticed if we had just
blacklisted it.

> 3. Provide sources for all packages
>
> We have source tarballs for some packages.  Should these sources be
> complete (i.e. so having only abs, all binary packages, the source
> tarball and no network access it is possible to build the binary package
> From exactly the same source)?  I believe that they should, this might
> need VCS packaging standards changes.

i remember lxo asking if we'd provide source dvds too.


i think it's ok but the social contract should add the clarification in
favor of free cultural works too.

-- 
http://kiwwwi.com.ar/pastes/para-cooptar-una-comunidad.markdown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121125/fbe7c6cf/attachment.sig>

From mtjm at mtjm.eu  Sun Nov 25 22:44:40 2012
From: mtjm at mtjm.eu (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=)
Date: Sun, 25 Nov 2012 23:44:40 +0100
Subject: [Dev] [RFC] Package freedom requirements clarification
In-Reply-To: <87k3t9gw42.fsf@kiwwwi.com.ar> (=?utf-8?Q?=22Nicol=C3=A1s?=
 Reynolds"'s message of "Sun, 25 Nov 2012 19:23:41 -0300")
References: <87a9u67isb.fsf@mtjm.eu> <87k3t9gw42.fsf@kiwwwi.com.ar>
Message-ID: <87vcctqp47.fsf@mtjm.eu>

> i think this should be coded into PBS:
>
> * we'll get pkgbuild updates directly from upstream and merge them with
>   our freedom-related and/or port changes
>
> * this can be done by automated tools so it's less boring work for us
>   and the intermediate probably-unfree-steering pkgbuilds won't be
>   published

Yes, keeping our PKGBUILDs similar to the upstream makes merges easier
(seen this often on mips64el).  Had a similar experience using
diff-unfree on a package with a rePKGBUILD.

> discussing freedom related issues with upstream (without trolling) is
> better. we had discussed this with encyclomundi when the syslog-ng guys
> got angry because we blacklisted them iirc, and also guestone reported a
> mislicensed art for a game that would go unnoticed if we had just
> blacklisted it.

This is another issue that will occur with any standards.  Recommend
blacklisting the package, asking upstream and leaving the issue open
until there is a free package or it's known that there won't be one?

> i think it's ok but the social contract should add the clarification in
> favor of free cultural works too.

+1.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121125/fcd40e1e/attachment.sig>

From lukeshu at sbcglobal.net  Mon Nov 26 01:26:52 2012
From: lukeshu at sbcglobal.net (Luke T. Shumaker)
Date: Sun, 25 Nov 2012 20:26:52 -0500
Subject: [Dev] Forking devtools
In-Reply-To: <87obj0vyr9.wl%lukeshu@sbcglobal.net>
References: <87obj0vyr9.wl%lukeshu@sbcglobal.net>
Message-ID: <87r4nh8883.wl%lukeshu@sbcglobal.net>

At Wed, 14 Nov 2012 13:13:30 -0500,
Luke T. Shumaker wrote:
>         30    Programs that are non applicable to Parabola because
>               they make assumptions about the architectures and
>               repositories supported (we have replacements for them).
>               (note: includes `archbuild`)
...
>  3. To reduce code duplication.
>     `librechroot` currently contains code from `archbuild`.  If I
>     could simply patch archbuild to be acceptable to Parabola, that
>     would be simpler.

I'm sorry, I was thinking of `makechrootpkg`; it contains some code
that is useful outside of the specific place where it is used, so it
is copied into `librechroot`.  I'm not sure why I was thinking that it
was in `archbuild` when I wrote that email.

Happy hacking,
~ Luke Shumaker


From lukeshu at sbcglobal.net  Mon Nov 26 01:42:13 2012
From: lukeshu at sbcglobal.net (Luke T. Shumaker)
Date: Sun, 25 Nov 2012 20:42:13 -0500
Subject: [Dev] [RFC] Package freedom requirements clarification
In-Reply-To: <87k3t9gw42.fsf@kiwwwi.com.ar>
References: <87a9u67isb.fsf@mtjm.eu>
	<87k3t9gw42.fsf@kiwwwi.com.ar>
Message-ID: <87obil87ii.wl%lukeshu@sbcglobal.net>

At Sun, 25 Nov 2012 19:23:41 -0300,
Nicol?s Reynolds wrote:
> Micha? Mas?owski <mtjm at mtjm.eu> writes:
> > 1. Blacklist source packages/PKGBUILDs, not binary packages
> >
> > We shouldn't have PKGBUILDs providing non-FSDG packages.  This would
> > include deprecating rePKGBUILDs.
> >
> > This change is also needed for the blacklist rewrite I proposed many
> > months ago.  The recent blacklisting activity and questions for the
> > reasons why old packages were blacklisted remind me of this being
> > useful, I will update that proposal.
> 
> i think this should be coded into PBS:
> 
> * we'll get pkgbuild updates directly from upstream and merge them with
>   our freedom-related and/or port changes
> 
> * this can be done by automated tools so it's less boring work for us
>   and the intermediate probably-unfree-steering pkgbuilds won't be
>   published
> 
> * your listed benefits

Noted!  That is how PBS is currently designed to work.  FWIW, that is
also why I want to have the source name for a package embedded into
the branch name; it means you don't have to mess around with
configuring multiple remotes when doing this kind of work.

> discussing freedom related issues with upstream (without trolling) is
> better. we had discussed this with encyclomundi when the syslog-ng guys
> got angry because we blacklisted them iirc, and also guestone reported a
> mislicensed art for a game that would go unnoticed if we had just
> blacklisted it.

Yeah, they got angry because we blacklisted them without any
notification.  What was weird is that someone said they were trying to
talk with them--I even read a draft of the email.  I guess it never
got sent.

Happy hacking,
~ Luke Shumaker


From lukeshu at sbcglobal.net  Mon Nov 26 01:49:58 2012
From: lukeshu at sbcglobal.net (Luke T. Shumaker)
Date: Sun, 25 Nov 2012 20:49:58 -0500
Subject: [Dev] [RFC] Package freedom requirements clarification [gnu.org
	#785062]
In-Reply-To: <87zk25qtxy.fsf@mtjm.eu>
References: <87a9u67isb.fsf@mtjm.eu> <87haoemev7.wl%lukeshu@sbcglobal.net>
 <87d2z2rn51.fsf@mtjm.eu> <87boelmmud.wl%lukeshu@sbcglobal.net>
 <87zk25qtxy.fsf@mtjm.eu>
Message-ID: <87mwy5875l.wl%lukeshu@sbcglobal.net>

At Sun, 25 Nov 2012 22:00:25 +0100,
Micha? Mas?owski wrote:
> > I guess the question is:
> >
> >   Can we download and distribute non-free code, if it is immediately
> >   deleted at the beginning of the build process?
> 
> I don't want to assume that all this nonfree code has licenses allowing
> us to distribute it

Nonfree code that can't be distributed verbatim is fairly uncommon (at
least for the software that we package).  Those cases definately would
require us to create custom tarballs.

> (e.g. some has no license or invalid ones like
> mixing GPL with incompatible licenses).  It would also prevent users
> From legally selling CDs with our binary and source packages (since some
> of this nonfree code disallows selling), while we want to support this
> use.

I didn't think about that either.  I agree with you now.

> > If we decide that we can't, I will contact the pacman devs and discuss
> > getting `makepkg --allsource` run `prepare()`.
> 
> +1

I guess I'll be sending them a patch in the next few days!

Happy hacking,
~ Luke Shumaker


From theguestone at gmail.com  Mon Nov 26 07:13:04 2012
From: theguestone at gmail.com (Guest One)
Date: Mon, 26 Nov 2012 08:13:04 +0100
Subject: [Dev] [RFC] Package freedom requirements clarification
In-Reply-To: <87k3t9gw42.fsf@kiwwwi.com.ar>
References: <87a9u67isb.fsf@mtjm.eu>
	<87k3t9gw42.fsf@kiwwwi.com.ar>
Message-ID: <CAGEkTWzC6ByYAXP+0NGto2WdLu13jGn+hTAeSnSWMxBF_LiVOQ@mail.gmail.com>

2012/11/25, Nicol?s Reynolds <fauno at kiwwwi.com.ar>:

>
> i think it's ok but the social contract should add the clarification in
> favor of free cultural works too.
>

+1


From theguestone at gmail.com  Mon Nov 26 07:42:17 2012
From: theguestone at gmail.com (Guest One)
Date: Mon, 26 Nov 2012 08:42:17 +0100
Subject: [Dev] [RFC] Package freedom requirements clarification
In-Reply-To: <87k3t9gw42.fsf@kiwwwi.com.ar>
References: <87a9u67isb.fsf@mtjm.eu>
	<87k3t9gw42.fsf@kiwwwi.com.ar>
Message-ID: <CAGEkTWync7pYiwtbws5xum4ope07OztTiAaNz92kckxz2gfLWQ@mail.gmail.com>

2012/11/25, Nicol?s Reynolds <fauno at kiwwwi.com.ar>:

> and also guestone reported a
> mislicensed art for a game that would go unnoticed if we had just
> blacklisted it.

Supertuxkart is ok now (next version will be totally free):
http://sourceforge.net/mailarchive/forum.php?thread_name=50B2715B.3050802%40gmail.com&forum_name=supertuxkart-devel

Simutrans unfortunately is released under Artistic License 1.0 and the
developers don't want to release it under Artistic License 2.0:
http://forum.simutrans.com/index.php?topic=10455.0 (it's sad) so i
think it's useless to talk with them (or maybe not?).

This is a thread where somebody ask to replace non-free assets in
AssaultCube forum where i have intervened:
http://forum.cubers.net/thread-5886.html if you are interested.

Each of us should talk with the developers of a non-free project in
the blacklist and explain the reasons of release a free product.
This is what i do since i fell in love with free games and free software.


From fauno at kiwwwi.com.ar  Mon Nov 26 16:21:47 2012
From: fauno at kiwwwi.com.ar (=?utf-8?Q?Nicol=C3=A1s?= Reynolds)
Date: Mon, 26 Nov 2012 13:21:47 -0300
Subject: [Dev] [Fwd: handbrake-cli uses non free FAAC encoder]
In-Reply-To: <1353583850.4977.6.camel@localhost.localdomain>
References: <1353583850.4977.6.camel@localhost.localdomain>
Message-ID: <87624sgwro.fsf@kiwwwi.com.ar>

alonivtsan <alonivtsan at gmail.com> writes:

> Sorry meant package "handbrake" instead of "handbrake-gtk"

it is already blacklisted, do you want to work on the libre version?

last time i checked, handbrake downloaded the codecs by itself instead
of using the system libraries :|

-- 
http://kiwwwi.com.ar/pastes/para-cooptar-una-comunidad.markdown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121126/a7a52aa5/attachment.sig>

From jorgean at lavabit.com  Mon Nov 26 16:41:00 2012
From: jorgean at lavabit.com (Jorge Araya Navarro)
Date: Mon, 26 Nov 2012 10:41:00 -0600
Subject: [Dev] [RFC] Package freedom requirements clarification
In-Reply-To: <CAGEkTWync7pYiwtbws5xum4ope07OztTiAaNz92kckxz2gfLWQ@mail.gmail.com>
References: <87a9u67isb.fsf@mtjm.eu> <87k3t9gw42.fsf@kiwwwi.com.ar>
 <CAGEkTWync7pYiwtbws5xum4ope07OztTiAaNz92kckxz2gfLWQ@mail.gmail.com>
Message-ID: <50B39B9C.9060707@lavabit.com>

El 26/11/2012 01:42, Guest One escribi?:
> 2012/11/25, Nicol?s Reynolds <fauno at kiwwwi.com.ar>:
>
>> and also guestone reported a
>> mislicensed art for a game that would go unnoticed if we had just
>> blacklisted it.
> Supertuxkart is ok now (next version will be totally free):
> http://sourceforge.net/mailarchive/forum.php?thread_name=50B2715B.3050802%40gmail.com&forum_name=supertuxkart-devel
>
> Simutrans unfortunately is released under Artistic License 1.0 and the
> developers don't want to release it under Artistic License 2.0:
> http://forum.simutrans.com/index.php?topic=10455.0 (it's sad) so i
> think it's useless to talk with them (or maybe not?).
>
> This is a thread where somebody ask to replace non-free assets in
> AssaultCube forum where i have intervened:
> http://forum.cubers.net/thread-5886.html if you are interested.
>
> Each of us should talk with the developers of a non-free project in
> the blacklist and explain the reasons of release a free product.
> This is what i do since i fell in love with free games and free software.
> _______________________________________________
> Dev mailing list
> Dev at lists.parabolagnulinux.org
> https://lists.parabolagnulinux.org/mailman/listinfo/dev
>
> ____________________________________________________________________________________
> Your personal email. Anytime, anywhere.
> Ridiculously affordable at $19.95. No contracts.
> http://www.getpeek.com/lavabit.html
> ____________________________________________________________________________________
the Simutrans is a jackass :-/

-- 
Jorge Araya Navarro
Universitario, idealista y activista del Software Libre.
Siquirres, Lim?n, Costa Rica.
http://swt.encyclomundi.net
Diaspora*: http://diasp.org/u/shackra
identi.ca: http://parlementum.net/sweet
Jabber: shackra at jabberes.org
Skype: ?De ninguna manera, tras de privativo, te esp?an!.
El software privativo en GNU/Linux, al igual que en Windows o en MacOs, 
te hace un ser no-libre. Deja de enga?arte, ??despierta ahora!!:
http://www.gnu.org/distros/free-distros.html
http://replicant.us/about/



From nicolasfloquet59 at gmail.com  Thu Nov 29 14:50:37 2012
From: nicolasfloquet59 at gmail.com (nicolas floquet)
Date: Thu, 29 Nov 2012 15:50:37 +0100
Subject: [Dev] logo parabola
Message-ID: <CAKt4Hk-gRGjhzZXbpKugEocdeicr0nPo_kS=BfqoetJUrh6s=Q@mail.gmail.com>

Hello,

At the moment, I learn some little things about logo design on Inkscape.
What do you think of this one ?

Cordialement,
Nicolas Floquet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121129/1713554e/attachment.htm>

From nicolasfloquet59 at gmail.com  Thu Nov 29 14:51:21 2012
From: nicolasfloquet59 at gmail.com (nicolas floquet)
Date: Thu, 29 Nov 2012 15:51:21 +0100
Subject: [Dev] logo parabola
In-Reply-To: <CAKt4Hk-gRGjhzZXbpKugEocdeicr0nPo_kS=BfqoetJUrh6s=Q@mail.gmail.com>
References: <CAKt4Hk-gRGjhzZXbpKugEocdeicr0nPo_kS=BfqoetJUrh6s=Q@mail.gmail.com>
Message-ID: <CAKt4Hk8vHo4wwzmKKEvfb6+6yTLPDFXvWHBz5non5pGJJw52xQ@mail.gmail.com>

Sorry.

Nicolas Floquet


2012/11/29 nicolas floquet <nicolasfloquet59 at gmail.com>

> Hello,
>
> At the moment, I learn some little things about logo design on Inkscape.
> What do you think of this one ?
>
> Cordialement,
> Nicolas Floquet.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121129/faf08b1a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logoparabola.svg
Type: image/svg+xml
Size: 32417 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121129/faf08b1a/attachment.svg>

From habstinat at gmail.com  Fri Nov 30 00:17:02 2012
From: habstinat at gmail.com (Harry Prevor)
Date: Thu, 29 Nov 2012 19:17:02 -0500
Subject: [Dev] logo parabola
In-Reply-To: <CAKt4Hk-gRGjhzZXbpKugEocdeicr0nPo_kS=BfqoetJUrh6s=Q@mail.gmail.com>
References: <CAKt4Hk-gRGjhzZXbpKugEocdeicr0nPo_kS=BfqoetJUrh6s=Q@mail.gmail.com>
Message-ID: <CABAfZD2a8b1y7URYw4vHmZ4p1MjQ+-7QoWu7R1WwzWUnSd+gag@mail.gmail.com>

On 11/29/12, nicolas floquet <nicolasfloquet59 at gmail.com> wrote:
> Hello,
>
> At the moment, I learn some little things about logo design on Inkscape.
> What do you think of this one ?

I really like it. It's a bit too large to be an official stamp but if
you made wallpapers with that logo I imagine people would definitely
use them. Also perhaps you should change the bottom text font from the
Courier family to something like Dejavu Sans Mono. Thanks a lot for
the effort!

-- 
Harry Prevor


From fauno at kiwwwi.com.ar  Fri Nov 30 01:46:37 2012
From: fauno at kiwwwi.com.ar (=?utf-8?Q?Nicol=C3=A1s?= Reynolds)
Date: Thu, 29 Nov 2012 22:46:37 -0300
Subject: [Dev] logo parabola
In-Reply-To: <CAKt4Hk8vHo4wwzmKKEvfb6+6yTLPDFXvWHBz5non5pGJJw52xQ@mail.gmail.com>
References: <CAKt4Hk-gRGjhzZXbpKugEocdeicr0nPo_kS=BfqoetJUrh6s=Q@mail.gmail.com>
 <CAKt4Hk8vHo4wwzmKKEvfb6+6yTLPDFXvWHBz5non5pGJJw52xQ@mail.gmail.com>
Message-ID: <87txs7dfr6.fsf@kiwwwi.com.ar>

nicolas floquet <nicolasfloquet59 at gmail.com> writes:

> Sorry.

thanks! i guess it's freely licensed no? :P

could you upload it to labs.parabola.nu? there's a project for artwork
and it will be better than lossing it here on the ml.

-- 
http://kiwwwi.com.ar/pastes/para-cooptar-una-comunidad.markdown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121129/0c5da846/attachment.sig>

From aurelien at cwb.io  Fri Nov 30 05:45:21 2012
From: aurelien at cwb.io (=?utf-8?Q?Aur=C3=A9lien?=)
Date: Fri, 30 Nov 2012 06:45:21 +0100
Subject: [Dev] logo parabola
In-Reply-To: <87txs7dfr6.fsf@kiwwwi.com.ar> (=?utf-8?Q?=22Nicol=C3=A1s?=
 Reynolds"'s message of "Thu, 29 Nov 2012 22:46:37 -0300")
References: <CAKt4Hk-gRGjhzZXbpKugEocdeicr0nPo_kS=BfqoetJUrh6s=Q@mail.gmail.com>
 <CAKt4Hk8vHo4wwzmKKEvfb6+6yTLPDFXvWHBz5non5pGJJw52xQ@mail.gmail.com>
 <87txs7dfr6.fsf@kiwwwi.com.ar>
Message-ID: <87ip8nbq4u.fsf@cwb.io>

Nicol?s Reynolds <fauno at kiwwwi.com.ar> writes:

> nicolas floquet <nicolasfloquet59 at gmail.com> writes:
>
>> Sorry.
>
> thanks! i guess it's freely licensed no? :P
>
> could you upload it to labs.parabola.nu? there's a project for artwork
> and it will be better than lossing it here on the ml.

Really nice job!

Congrats!


From lukeshu at sbcglobal.net  Fri Nov 30 06:45:22 2012
From: lukeshu at sbcglobal.net (Luke T. Shumaker)
Date: Fri, 30 Nov 2012 01:45:22 -0500
Subject: [Dev] Fauno's workflow
Message-ID: <87lidjk2rh.wl%lukeshu@sbcglobal.net>

Fauno put this file in /doc/ in libretools, but I felt the best way to
discuss it was an email

Fauno wrote:
> ## fauno's way
> 
> During packaging, I don't usually restart a build from scratch if I have to
> make changes to the PKGBUILD. I use a lot of commenting out commands already
> ran, `makepkg -R`, etc. When I used `libremakepkg` I ended up using a lot more
> `librechroot` and working from inside the unconfigured chroot, because
> `makechrootpkg` (the underlying technology for `libremakepkg`) tries to be too
> smart.

I'm not sure that's a "safe" way to build packages. I might do that
while getting a package to build, but I always build from scratch at
the end. "ccache" makes this bearable.

Also, libremakepkg no longer uses makechrootpkg, and is *very*
transparent and doesn't try to be too smart.

 * Copies the PKGBUILD and sources in (ok, some clever things happen
   to copy the sources)
 * Runs checks on the PKGBUILD (currently pkgbuild-check-nonfree,
   eventually librenamcap)
 * Runs "makepkg -o"
 * Runs checks on the source directory
 * Runs "makepkg -e" with networking dissabled in the chroot
 * Copies the resulting packages to SRCDEST.

> When I started writing `treepkg` I found that mounting what I need directly on
> the chroot and working from inside it was much more comfortable and simple than
> having a makepkg wrapper doing funny stuff (for instance, mangling makepkg.conf
> and breaking everything.)

There is still some mangling of pacman.conf that I don't understand
(maybe it is important; I'm affraid to remove code I don't understand)
https://labs.parabola.nu/issues/256

However, all that happens to makepkg.conf is it sets PKGDEST and SRCDEST.

> This is how the chroot is configured:
> 
> * Create the same user (with same uid) on the chroot that the one I use regularly.
> 
> * Give it password-less sudo on the chroot.
> 
> * Bind mount /home to /chroot/home, where I have the abslibre-mips64el clone.

I'm not sure that's a good idea; maybe it works for you, but
 * A lot of tools look at configuration in $HOME; a chroot means it is
   a fresh directory... unless you bind mount /home.
 * A chroot also protects you from a misbehaving build script messing
   with your $HOME.

> * Bind mount /var/cache/pacman/pkg to /chroot/var/cache/pacman/pkg
> * Put these on system's fstab so I don't have to do it everytime

archroot (librechroot's backend) bind mounts that for you so you don't have to
have it in fstab or do it manually.

> * Configure makepkg.conf to PKGDEST=CacheDir and SRCDEST to something on my home.
> 
> Workflow:
> 
> * Enter the chroot with `systemd-nspawn -D/chroot` and `su - fauno`.
> 
> * From another shell (I use tmux) edit the abslibre or search for updates with
>   `git log --no-merges --numstat`.
> 
> * Pick a package and run `treepkg` from its dir on the chroot, or retake
>   a build with `treepkg /tmp/package-treepkg-xxxx`. (Refer to doc/treepkg
>   here).
> 
> What this allows:
> 
> * Not having to worry about the state of the chroot. `chcleanup` removes and
>   adds packages in a smart way so shared dependencies stay and others move
>   along (think of installing and removing qt for a complete kde
>   rebuild).

`librechroot -c` now uses chcleanup to clean the chroot.

> * Building many packages in a row without recreating a chroot for every one of
>   them.

libremakepkg did not recreate the chroot automatically before, and
can't now.

> * Knowing that any change you made to the chroot stays as you want (no one
>   touches your makepkg.conf)

For someone who doesn't work from inside the chroot, only setting
PKGDEST and SRCDEST seems to be a good balance between "don't mess
with my stuff" and "just work".

> * Hability to run regular commands, not through a chroot wrapper. I can `cd` to
>   a dir and use `makepkg -whatever` on it and nothing breaks.
> 
> * No extra code spent on wrappers.

Again, I'm working to make libremakepkg provide more checks than
simply working in a clean chroot does.

Happy hacking,
~ Luke Shumaker


From s.boutayeb at free.fr  Fri Nov 30 07:03:07 2012
From: s.boutayeb at free.fr (s.boutayeb at free.fr)
Date: Fri, 30 Nov 2012 08:03:07 +0100
Subject: [Dev] Yeeloong: Changing the boot screen (was: logo parabola)
In-Reply-To: <mailman.131.1354204291.31247.dev@lists.parabolagnulinux.org>
References: <mailman.131.1354204291.31247.dev@lists.parabolagnulinux.org>
Message-ID: <1354258987.50b85a2b7e7e0@imp.free.fr>

> At the moment, I learn some little things about logo design on Inkscape.
> What do you think of this one ?
>
> Cordialement,
> Nicolas Floquet.

Hi,

This logo is likely to be displayed as boot screen on the Yeeloong laptop, using
the pmon boot loader.

See: http://www.mail-archive.com/misc at openbsd.org/msg102855.html

for a detailed howto.

Beware, this may brick your laptop, if executed without caution

rgds
samy


From ramana at member.fsf.org  Fri Nov 30 07:55:20 2012
From: ramana at member.fsf.org (Ramana Kumar)
Date: Fri, 30 Nov 2012 07:55:20 +0000
Subject: [Dev] logo parabola
In-Reply-To: <87ip8nbq4u.fsf@cwb.io>
References: <CAKt4Hk-gRGjhzZXbpKugEocdeicr0nPo_kS=BfqoetJUrh6s=Q@mail.gmail.com>
 <CAKt4Hk8vHo4wwzmKKEvfb6+6yTLPDFXvWHBz5non5pGJJw52xQ@mail.gmail.com>
 <87txs7dfr6.fsf@kiwwwi.com.ar> <87ip8nbq4u.fsf@cwb.io>
Message-ID: <CAMej=25oi+QCpsPSHE8Z3AFttQU5GUq5BqQv-hD5H5CgV-jG_A@mail.gmail.com>

"free kiss" primes the wrong meaning of "free". That might be something to
avoid. Though it is a nice pun.


On Fri, Nov 30, 2012 at 5:45 AM, Aur?lien <aurelien at cwb.io> wrote:

> Nicol?s Reynolds <fauno at kiwwwi.com.ar> writes:
>
> > nicolas floquet <nicolasfloquet59 at gmail.com> writes:
> >
> >> Sorry.
> >
> > thanks! i guess it's freely licensed no? :P
> >
> > could you upload it to labs.parabola.nu? there's a project for artwork
> > and it will be better than lossing it here on the ml.
>
> Really nice job!
>
> Congrats!
> _______________________________________________
> Dev mailing list
> Dev at lists.parabolagnulinux.org
> https://lists.parabolagnulinux.org/mailman/listinfo/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121130/5f580dd7/attachment.htm>

From fauno at kiwwwi.com.ar  Fri Nov 30 17:28:44 2012
From: fauno at kiwwwi.com.ar (=?utf-8?Q?Nicol=C3=A1s?= Reynolds)
Date: Fri, 30 Nov 2012 14:28:44 -0300
Subject: [Dev] Fauno's workflow
In-Reply-To: <87lidjk2rh.wl%lukeshu@sbcglobal.net>
References: <87lidjk2rh.wl%lukeshu@sbcglobal.net>
Message-ID: <87wqx3atkj.fsf@kiwwwi.com.ar>

"Luke T. Shumaker" <lukeshu at sbcglobal.net> writes:

> Fauno put this file in /doc/ in libretools, but I felt the best way to
> discuss it was an email
>
> Fauno wrote:
>> ## fauno's way
>> 
>> During packaging, I don't usually restart a build from scratch if I have to
>> make changes to the PKGBUILD. I use a lot of commenting out commands already
>> ran, `makepkg -R`, etc. When I used `libremakepkg` I ended up using a lot more
>> `librechroot` and working from inside the unconfigured chroot, because
>> `makechrootpkg` (the underlying technology for `libremakepkg`) tries to be too
>> smart.
>
> I'm not sure that's a "safe" way to build packages. I might do that
> while getting a package to build, but I always build from scratch at
> the end. "ccache" makes this bearable.

i'm a daredevil B)

> Also, libremakepkg no longer uses makechrootpkg, and is *very*
> transparent and doesn't try to be too smart.
>
>  * Copies the PKGBUILD and sources in (ok, some clever things happen
>    to copy the sources)

which ones?

>  * Runs checks on the PKGBUILD (currently pkgbuild-check-nonfree,
>    eventually librenamcap)
>  * Runs "makepkg -o"
>  * Runs checks on the source directory

what kind of checks?

>  * Runs "makepkg -e" with networking dissabled in the chroot

sounds fine

>  * Copies the resulting packages to SRCDEST.

?


>> When I started writing `treepkg` I found that mounting what I need
>> directly on the chroot and working from inside it was much more
>> comfortable and simple than having a makepkg wrapper doing funny
>> stuff (for instance, mangling makepkg.conf and breaking everything.)
>
> There is still some mangling of pacman.conf that I don't understand
> (maybe it is important; I'm affraid to remove code I don't understand)
> https://labs.parabola.nu/issues/256
>
> However, all that happens to makepkg.conf is it sets PKGDEST and SRCDEST.

i remember it also rewrites the makepkg entirely everytime, so if you
use distcc (it requires setting DISTCC_HOSTS) it will disable it.

>> This is how the chroot is configured:
>> 
>> * Create the same user (with same uid) on the chroot that the one I
>> use regularly.
>> 
>> * Give it password-less sudo on the chroot.
>> 
>> * Bind mount /home to /chroot/home, where I have the abslibre-mips64el clone.
>
> I'm not sure that's a good idea; maybe it works for you, but
>  * A lot of tools look at configuration in $HOME; a chroot means it is
>    a fresh directory... unless you bind mount /home.

it may also bind mount a subdir on home where you store abslibre and
libretools (i use the git version) and that's clean enough. it's never
been a problem though.

>  * A chroot also protects you from a misbehaving build script messing
>    with your $HOME.

i usually check pkgbuilds from aur and trust the ones that come from
abslibre...

>> * Bind mount /var/cache/pacman/pkg to /chroot/var/cache/pacman/pkg
>> * Put these on system's fstab so I don't have to do it everytime
>
> archroot (librechroot's backend) bind mounts that for you so you don't have to
> have it in fstab or do it manually.

but it's done several times, on fstab it's done once at boot.

>> * Configure makepkg.conf to PKGDEST=CacheDir and SRCDEST to something on my home.
>> 
>> Workflow:
>> 
>> * Enter the chroot with `systemd-nspawn -D/chroot` and `su - fauno`.
>> 
>> * From another shell (I use tmux) edit the abslibre or search for updates with
>>   `git log --no-merges --numstat`.
>> 
>> * Pick a package and run `treepkg` from its dir on the chroot, or retake
>>   a build with `treepkg /tmp/package-treepkg-xxxx`. (Refer to doc/treepkg
>>   here).
>> 
>> What this allows:
>> 
>> * Not having to worry about the state of the chroot. `chcleanup` removes and
>>   adds packages in a smart way so shared dependencies stay and others move
>>   along (think of installing and removing qt for a complete kde
>>   rebuild).
>
> `librechroot -c` now uses chcleanup to clean the chroot.

chcleanup is run automatically here, not optionally. -c is needed when
the chroot is considered dirty if not pristine so it may remove the
packages you already installed if this is the second run, and this isn't
the case: chroot is considered dirty when more than the needed packages
are installed.

>> * Building many packages in a row without recreating a chroot for every one of
>>   them.
>
> libremakepkg did not recreate the chroot automatically before, and
> can't now.

recreating here means "mounting and umounting, removing files, spawning
shells...", why has this to be done many times when i can do it once or
less? (yeeloongs aren't the quickest machines).

>> * Knowing that any change you made to the chroot stays as you want (no one
>>   touches your makepkg.conf)
>
> For someone who doesn't work from inside the chroot, only setting
> PKGDEST and SRCDEST seems to be a good balance between "don't mess
> with my stuff" and "just work".
>
>> * Hability to run regular commands, not through a chroot wrapper. I can `cd` to
>>   a dir and use `makepkg -whatever` on it and nothing breaks.

also rm packages from the build order (see treepkg), add or remove
packages from the repo, etc.

>> 
>> * No extra code spent on wrappers.
>
> Again, I'm working to make libremakepkg provide more checks than
> simply working in a clean chroot does.

checks are ok, i just feel chroot wrappers add complexity that's not
needed if you take the chroot as a working environment. less bugs to
trace down!

-- 
http://kiwwwi.com.ar/pastes/para-cooptar-una-comunidad.markdown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121130/d037a402/attachment.sig>

From lukeshu at sbcglobal.net  Fri Nov 30 18:18:48 2012
From: lukeshu at sbcglobal.net (Luke T. Shumaker)
Date: Fri, 30 Nov 2012 13:18:48 -0500
Subject: [Dev] Fauno's workflow
In-Reply-To: <87wqx3atkj.fsf@kiwwwi.com.ar>
References: <87lidjk2rh.wl%lukeshu@sbcglobal.net>
 <87wqx3atkj.fsf@kiwwwi.com.ar>
Message-ID: <87fw3rj6nr.wl%lukeshu@sbcglobal.net>

At Fri, 30 Nov 2012 14:28:44 -0300,
Nicol?s Reynolds wrote:
> 
> [1  <text/plain (quoted-printable)>]
> "Luke T. Shumaker" <lukeshu at sbcglobal.net> writes:
> 
> > Fauno put this file in /doc/ in libretools, but I felt the best way to
> > discuss it was an email
> >
> > Fauno wrote:
> >> ## fauno's way
> >> 
> >> During packaging, I don't usually restart a build from scratch if I have to
> >> make changes to the PKGBUILD. I use a lot of commenting out commands already
> >> ran, `makepkg -R`, etc. When I used `libremakepkg` I ended up using a lot more
> >> `librechroot` and working from inside the unconfigured chroot, because
> >> `makechrootpkg` (the underlying technology for `libremakepkg`) tries to be too
> >> smart.
> >
> > I'm not sure that's a "safe" way to build packages. I might do that
> > while getting a package to build, but I always build from scratch at
> > the end. "ccache" makes this bearable.
> 
> i'm a daredevil B)
> 
> > Also, libremakepkg no longer uses makechrootpkg, and is *very*
> > transparent and doesn't try to be too smart.
> >
> >  * Copies the PKGBUILD and sources in (ok, some clever things happen
> >    to copy the sources)
> 
> which ones?

The PKGBUILD in the current directory, and the sources named in it;
the ones `makepkg` would care about.

> >  * Runs checks on the PKGBUILD (currently pkgbuild-check-nonfree,
> >    eventually librenamcap)
> >  * Runs "makepkg -o"
> >  * Runs checks on the source directory
> 
> what kind of checks?

It runs the functions:

 * libre_check_pkgbuild
    currently:
     * "pkgbuild-check-nonfree"
    eventually:
     * "pkgbuild-check-nonfree"
     * "namcap"
 * libre_check_src
    currently:
     * nothing
    eventually:
     * "jh checksource"
 * libre_check_pkg
    currently:
     * nothing
    eventually:
     * "namcap"

And possibly more. The checking will eventually be encapsulated by
"librenamcap".

> >  * Runs "makepkg -e" with networking dissabled in the chroot
> 
> sounds fine
> 
> >  * Copies the resulting packages to SRCDEST.
> 
> ?

It copies the packages in ${chrootdir}/srcdest to your configured
SRCDEST outside of the chroot; where normal `makepkg` would put them.

I forgot to mention it, but it also runs `libre_check_pkg` on the
packages before it copies them.

> >> When I started writing `treepkg` I found that mounting what I need
> >> directly on the chroot and working from inside it was much more
> >> comfortable and simple than having a makepkg wrapper doing funny
> >> stuff (for instance, mangling makepkg.conf and breaking everything.)
> >
> > There is still some mangling of pacman.conf that I don't understand
> > (maybe it is important; I'm affraid to remove code I don't understand)
> > https://labs.parabola.nu/issues/256
> >
> > However, all that happens to makepkg.conf is it sets PKGDEST and SRCDEST.
> 
> i remember it also rewrites the makepkg entirely everytime, so if you
> use distcc (it requires setting DISTCC_HOSTS) it will disable it.

Maybe it used to, but it no longer does. (I did rewrite it after all)

> >> This is how the chroot is configured:
> >> 
> >> * Create the same user (with same uid) on the chroot that the one I
> >> use regularly.
> >> 
> >> * Give it password-less sudo on the chroot.
> >> 
> >> * Bind mount /home to /chroot/home, where I have the abslibre-mips64el clone.
> >
> > I'm not sure that's a good idea; maybe it works for you, but
> >  * A lot of tools look at configuration in $HOME; a chroot means it is
> >    a fresh directory... unless you bind mount /home.
> 
> it may also bind mount a subdir on home where you store abslibre and
> libretools (i use the git version) and that's clean enough. it's never
> been a problem though.

Eh, I'm a fan of getting an up-to-date libretools on the repos.

> >  * A chroot also protects you from a misbehaving build script messing
> >    with your $HOME.
> 
> i usually check pkgbuilds from aur and trust the ones that come from
> abslibre...

Not just the PKGBUILDS, but the Makefiles, ant scripts, etc that are
part of the source.

> >> * Bind mount /var/cache/pacman/pkg to /chroot/var/cache/pacman/pkg
> >> * Put these on system's fstab so I don't have to do it everytime
> >
> > archroot (librechroot's backend) bind mounts that for you so you don't have to
> > have it in fstab or do it manually.
> 
> but it's done several times, on fstab it's done once at boot.
> 
> >> * Configure makepkg.conf to PKGDEST=CacheDir and SRCDEST to something on my home.
> >> 
> >> Workflow:
> >> 
> >> * Enter the chroot with `systemd-nspawn -D/chroot` and `su - fauno`.
> >> 
> >> * From another shell (I use tmux) edit the abslibre or search for updates with
> >>   `git log --no-merges --numstat`.
> >> 
> >> * Pick a package and run `treepkg` from its dir on the chroot, or retake
> >>   a build with `treepkg /tmp/package-treepkg-xxxx`. (Refer to doc/treepkg
> >>   here).
> >> 
> >> What this allows:
> >> 
> >> * Not having to worry about the state of the chroot. `chcleanup` removes and
> >>   adds packages in a smart way so shared dependencies stay and others move
> >>   along (think of installing and removing qt for a complete kde
> >>   rebuild).
> >
> > `librechroot -c` now uses chcleanup to clean the chroot.
> 
> chcleanup is run automatically here, not optionally. -c is needed when
> the chroot is considered dirty if not pristine so it may remove the
> packages you already installed if this is the second run, and this isn't
> the case: chroot is considered dirty when more than the needed packages
> are installed.

How is it done automatically?

> >> * Building many packages in a row without recreating a chroot for every one of
> >>   them.
> >
> > libremakepkg did not recreate the chroot automatically before, and
> > can't now.
> 
> recreating here means "mounting and umounting, removing files, spawning
> shells...", why has this to be done many times when i can do it once or
> less? (yeeloongs aren't the quickest machines).

I wish I hade a yeeloong to verify...

> >> * Knowing that any change you made to the chroot stays as you want (no one
> >>   touches your makepkg.conf)
> >
> > For someone who doesn't work from inside the chroot, only setting
> > PKGDEST and SRCDEST seems to be a good balance between "don't mess
> > with my stuff" and "just work".
> >
> >> * Hability to run regular commands, not through a chroot wrapper. I can `cd` to
> >>   a dir and use `makepkg -whatever` on it and nothing breaks.
> 
> also rm packages from the build order (see treepkg), add or remove
> packages from the repo, etc.
> 
> >> 
> >> * No extra code spent on wrappers.
> >
> > Again, I'm working to make libremakepkg provide more checks than
> > simply working in a clean chroot does.
> 
> checks are ok, i just feel chroot wrappers add complexity that's not
> needed if you take the chroot as a working environment. less bugs to
> trace down!

It's pretty minimal now.  The most complicated parts are:
 * handling signals to umount and exit gracefully
 * the legacy code that only runs if systemd-nspawn isn't available

And some of the "checks" can only be done with a chroot, such as
turning networking off during the build and package stages.

Happy hacking,
~ Luke Shumaker


From fauno at kiwwwi.com.ar  Fri Nov 30 18:29:56 2012
From: fauno at kiwwwi.com.ar (=?utf-8?Q?Nicol=C3=A1s?= Reynolds)
Date: Fri, 30 Nov 2012 15:29:56 -0300
Subject: [Dev] Fauno's workflow
In-Reply-To: <87fw3rj6nr.wl%lukeshu@sbcglobal.net>
References: <87lidjk2rh.wl%lukeshu@sbcglobal.net>
 <87wqx3atkj.fsf@kiwwwi.com.ar> <87fw3rj6nr.wl%lukeshu@sbcglobal.net>
Message-ID: <87obifaqqj.fsf@kiwwwi.com.ar>

"Luke T. Shumaker" <lukeshu at sbcglobal.net> writes:
>> >  * Copies the resulting packages to SRCDEST.
>> 
>> ?
>
> It copies the packages in ${chrootdir}/srcdest to your configured
> SRCDEST outside of the chroot; where normal `makepkg` would put them.
>
> I forgot to mention it, but it also runs `libre_check_pkg` on the
> packages before it copies them.

but srcdest is for downloading sources... why copying if you can have
them all in the same place anyway? :D

>> it may also bind mount a subdir on home where you store abslibre and
>> libretools (i use the git version) and that's clean enough. it's never
>> been a problem though.
>
> Eh, I'm a fan of getting an up-to-date libretools on the repos.

it's not enough if i'm testing changes to libretools itself ;)

>> >  * A chroot also protects you from a misbehaving build script messing
>> >    with your $HOME.
>> 
>> i usually check pkgbuilds from aur and trust the ones that come from
>> abslibre...
>
> Not just the PKGBUILDS, but the Makefiles, ant scripts, etc that are
> part of the source.

ok then refer to mount chroot's ~ to something that contains libretools
and abslibre (or just abslibre):

$ ls ~/packages/
abslibre/
packages/
sources/

$ mount --bind ~/packages $chrootdir/home/$USER/

>> chcleanup is run automatically here, not optionally. -c is needed when
>> the chroot is considered dirty if not pristine so it may remove the
>> packages you already installed if this is the second run, and this isn't
>> the case: chroot is considered dirty when more than the needed packages
>> are installed.
>
> How is it done automatically?

it's always run by treepkg before makepkg, no flag involved, and it's a
tiny script that just knows what to remove instead of removing
everything just in case (rsync is slow and btrfs is overkill in
comparison to a *tiny* script that runs pacman -Rn
packages-not-in-base-or-pkgbuild).

>> recreating here means "mounting and umounting, removing files, spawning
>> shells...", why has this to be done many times when i can do it once or
>> less? (yeeloongs aren't the quickest machines).
>
> I wish I hade a yeeloong to verify...

:c

but still, doing things many times unnecesarily doesn't sound kiss to
me, as in i didn't had to rewrite libremakepkg, i just stopped using it
;)

> It's pretty minimal now.  The most complicated parts are:
>  * handling signals to umount and exit gracefully

that's the problem with making it mount everytime instead of using
fstab, you can end up with the same dir bind mounted many many times.

>  * the legacy code that only runs if systemd-nspawn isn't available

this should be deprecated imo

> And some of the "checks" can only be done with a chroot, such as
> turning networking off during the build and package stages.

this is true, but what we're discussing (except from the "running any
command instead of a predefined set" part) does still apply.

-- 
http://kiwwwi.com.ar/pastes/para-cooptar-una-comunidad.markdown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121130/5f80612f/attachment.sig>

From lukeshu at sbcglobal.net  Fri Nov 30 23:51:20 2012
From: lukeshu at sbcglobal.net (Luke T. Shumaker)
Date: Fri, 30 Nov 2012 18:51:20 -0500
Subject: [Dev] Fauno's workflow
In-Reply-To: <87obifaqqj.fsf@kiwwwi.com.ar>
References: <87lidjk2rh.wl%lukeshu@sbcglobal.net>
 <87wqx3atkj.fsf@kiwwwi.com.ar>
 <87fw3rj6nr.wl%lukeshu@sbcglobal.net>
 <87obifaqqj.fsf@kiwwwi.com.ar>
Message-ID: <87boeek5tz.wl%lukeshu@sbcglobal.net>

At Fri, 30 Nov 2012 15:29:56 -0300,
Nicol?s Reynolds wrote:
> "Luke T. Shumaker" <lukeshu at sbcglobal.net> writes:
> > It copies the packages in ${chrootdir}/srcdest to your configured
> > SRCDEST outside of the chroot; where normal `makepkg` would put them.
> 
> but srcdest is for downloading sources... why copying if you can have
> them all in the same place anyway? :D

Because the file ownership of the outside srcdest (you) and the inside
srcdest ("nobody") are different.

> > > it may also bind mount a subdir on home where you store abslibre and
> > > libretools (i use the git version) and that's clean enough. it's never
> > > been a problem though.
> >
> > Eh, I'm a fan of getting an up-to-date libretools on the repos.
> 
> it's not enough if i'm testing changes to libretools itself ;)

Well then, that's what /repo is for, put the testing package there.

> > > >  * A chroot also protects you from a misbehaving build script messing
> > > >    with your $HOME.
> > > 
> > > i usually check pkgbuilds from aur and trust the ones that come from
> > > abslibre...
> >
> > Not just the PKGBUILDS, but the Makefiles, ant scripts, etc that are
> > part of the source.
> 
> ok then refer to mount chroot's ~ to something that contains libretools
> and abslibre (or just abslibre):
> 
> $ ls ~/packages/
> abslibre/
> packages/
> sources/
> 
> $ mount --bind ~/packages $chrootdir/home/$USER/

I'll consider this. Perhaps I'll make bind mounts configurable, so you
can configure whatever mounts you want.

> >> chcleanup is run automatically here, not optionally. -c is needed when
> >> the chroot is considered dirty if not pristine so it may remove the
> >> packages you already installed if this is the second run, and this isn't
> >> the case: chroot is considered dirty when more than the needed packages
> >> are installed.
> >
> > How is it done automatically?
> 
> it's always run by treepkg before makepkg, no flag involved, and it's a
> tiny script that just knows what to remove instead of removing
> everything just in case (rsync is slow and btrfs is overkill in
> comparison to a *tiny* script that runs pacman -Rn
> packages-not-in-base-or-pkgbuild).

How the tools clean has changed.

 librechroot -c cleans the chroot using chcleanup
 librechroot -s syncs it to a pristine chroot with rsync/btrfs 

I've also just (since I started writing the email) tought libremakepkg
to also run chcleanup for every build, since it isn't overkill like
the old package cleanup was.

> >> recreating here means "mounting and umounting, removing files, spawning
> >> shells...", why has this to be done many times when i can do it once or
> >> less? (yeeloongs aren't the quickest machines).
> >
> > I wish I hade a yeeloong to verify...
> 
> :c
> 
> but still, doing things many times unnecesarily doesn't sound kiss to
> me, as in i didn't had to rewrite libremakepkg, i just stopped using it
> ;)

My goal with rewriting libremakepkg was to "wrap makepkg, adding hooks
to do things for me that I'm doing manually now".

> > It's pretty minimal now.  The most complicated parts are:
> >  * handling signals to umount and exit gracefully
> 
> that's the problem with making it mount everytime instead of using
> fstab, you can end up with the same dir bind mounted many many times.

I think I fixed that bug. Before it trapped the signals so that when
there was an error, it went to the umount function. The first thing
that function did was reset the traps to the exit function. This was
bad because it meant that it might exit early and not umount
everything.

I think that modifying the outside fstab is too invasive into the
user's system.

> >  * the legacy code that only runs if systemd-nspawn isn't available
> 
> this should be deprecated imo

I agree, but removing it would involve patching devtools even more
than I already do.  I'm trying to keep it so that I can still pull
changes from devtools.

> > And some of the "checks" can only be done with a chroot, such as
> > turning networking off during the build and package stages.
> 
> this is true, but what we're discussing (except from the "running any
> command instead of a predefined set" part) does still apply.

I'm not sure what you mean. In order to toggle the networking you must
exit and re-enter the chroot.

Happy hacking,
~ Luke Shumaker