From mail at eduardmarti.cat Fri Mar 3 00:53:28 2017 From: mail at eduardmarti.cat (=?UTF-8?Q?Eduard_Mart=c3=ad?=) Date: Fri, 3 Mar 2017 01:53:28 +0100 Subject: [Dev] Package maintaining Message-ID: <830c1f26-9a43-0c6d-a469-b44fdef0a22b@eduardmarti.cat> Hi, I'm sending my ssh public key with the intention to cooperate with you soon. Thanks! Eduard Mart? Valls mail at eduardmarti.cat -------------- next part -------------- -----BEGIN PGP MESSAGE----- owE1k2lwEwUAhcvRmVK5BEqBGWoBpZSl5NicSDvdZLPpNtmc2+wmCEx2k02yTTZ3 stmpiA4ILXLIoYWWqgUFxHrUKdeAB6LoFIYWlWOmrSDCAIItDQy2gFh+8ObNvPne /2/LhDE5eaNOuG0l335wMjGqbfQwlR/wrIzF3YsjSYo8cvxSPO4vG8FiaCQa0CS4 tZIMLdU9QxiyQpqR1UJWbQClHClnhMBlfFIBM2I6orZX1YYgk0CKk1ozQ3oJjNWi TDShCBl4swbkSamD4TQap9KC0ZjYlTbXCBHE50EkMtZZE2cwh9QXU8mrEQpNYka2 Gk+hMKHzkqyYpnwRVhUBrR5GWcNUO+J2hQax8BYdSPkAQpSRplIOQU/59LBayZPB mD2kTlBiPSmuDUo4GovzEEBZyYiWp3gEE8cyRESBJkjQgMjoTBgmST9gxAAEV0lh mwVGpfJwsjqsDqQ9WDoEw6oqlx+POaFUwuzjwx4etKmSVKJaKSIZjYOqlmXwMOVh 7GrYxwhhJ4Sk/UGdBORUghryo3KZDteaXTUA4hBJCFpKJegoZsNiRBAlvSrUCNk4 bVBJqAmdOmSuFvwRXIBNIjSK05Cbgd00nzTLa2IYR2n1VBLxokZUblWZjDLUFkxF oRBgNRl4H8iDuIRIy6S1SrmYdbI21Bjj2RQW0tQImMwOQh6DzxCrilFqIuXXyzlB JVL4OLdF7o2oMUxmqE0pgNq035U0OgwBMCzmkpqqGBgH0wqLxCdgAU1UpqWQACdI 3Gq5REeiOItqRPaQwYooGTGCsSiPI0pLwOSOVqFaAcaZqIPjAIQQBRRuIGWCPBGP CM7YaakftiWqVIBVQbBygIo4KbEjJLLBkXA65LSEQZ3JH4YpgEZTDEYJMMviSl3Y JzPRFBCTBAFYqrDRaRpUQcaYwcVzaShOWsX+qIKSsQkjCzMGZ5TI1NYgjpTFSdCp gMFDiQNOvbW8vJgNp7yVnDcQLJOKJcoyMTjS/PrR4NicUXk5s6fPGTtg7C3pQxds HFQqBp7bkTv6mQ85+eMmP3/qFk16yurWG2fv2PVuezZ8NSY/V1rUvnIggEze92rR FaBpZvJi/7JjJT3rdm+vOnBBMQEsh7rLCpsb9uTOoESfb8aLMlNO7RhevPTMtn9v KyWhedopvW72kSlwfWfiamdd16D59N5X9IJ8c3+76/RHt+rZZm8711Ff/3Xfseq9 itsd2scznnw2vLbz96tNr63CiR+y97dipopHbs2c1rlbeu5tuex1nD11sPvXyj0V ok8WXAeaVu1i/MvV9UdvNZYO3i7dn2nVgq2N0W0c1+0byF1SsaHhqOfipg3Tmv/4 e+Phh2zRwNmjjTfLT5SJWsrH9xecfJurOLWWXdI0cb9LnLqbVWBf7eh/fCh0bv6S bdTiH+sORittVkffe+OXnxt6oSghyd5y4NcaL9FX2lbfG/tgWpc913zEpVyV/2Dm g33Zs33Tbgx8nGxrKOrs6hm+S+N/dXRf4ydTwV0XsvN8eRWVSOFbW//UOyrXnf9u EnL8i+IDxV92nW8cYqzdpvc9D0O7X09vzs7NG46mBtfc2f7G/DrUde9QWTG1YpZT daancRHeWZBPLN26PG5ePWb48gqkxPHkRnNhRanIWAD8tCD7286WhUMto7UfXuqd evjNgp5/lhUOrQm8NIssai1tXXhe3qbKY9ab33lx4ripv/zcf/B7Zp7QueKbhk87 WmSrg8LTm733X+6c/t+eOyc2/Q8= =ExOw -----END PGP MESSAGE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xBF9FC274.asc Type: application/pgp-keys Size: 3151 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From fauno at endefensadelsl.org Fri Mar 3 15:44:49 2017 From: fauno at endefensadelsl.org (fauno) Date: Fri, 03 Mar 2017 12:44:49 -0300 Subject: [Dev] librerouter aka communitycube Message-ID: <87pohy9xfy.fsf@endefensadelsl.org> do you remember when we were approached by some guy with a crowdfunded arm board with local services and were dismissed because we failed to give a reply in like a week? he just scammed a friend of mine by making him work and refusing to pay him what they agreed. my friend posted the story on github but the content was changed by the scammer into text abuse: https://github.com/Librerouter/Librekernel/issues/237 just letting you know so you don't get scammed too :( -- :{ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 617 bytes Desc: not available URL: From g4jc at openmailbox.org Fri Mar 3 23:10:05 2017 From: g4jc at openmailbox.org (Luke) Date: Fri, 3 Mar 2017 23:10:05 +0000 Subject: [Dev] librerouter aka communitycube In-Reply-To: <87pohy9xfy.fsf@endefensadelsl.org> References: <87pohy9xfy.fsf@endefensadelsl.org> Message-ID: <9a1fbb5c-6fa7-1c0d-bda2-94e21b54e796@openmailbox.org> On 03/03/2017 03:44 PM, fauno wrote: > do you remember when we were approached by some guy with a crowdfunded > arm board with local services and were dismissed because we failed to > give a reply in like a week? > > he just scammed a friend of mine by making him work and refusing to pay > him what they agreed. > > my friend posted the story on github but the content was changed by the > scammer into text abuse: > https://github.com/Librerouter/Librekernel/issues/237 > > just letting you know so you don't get scammed too :( > I remember that guy, I triggered him by asking specific questions in chat. He got hostile and said we didn't share his vision. Glad we didn't make any agreement with him. He had already scammed a bunch of people through crowdfunding by promising the product before any product had even been created. Those people were/are no doubt demanding refunds, so he had no equity to begin with, and is liable for lying to his customers and stealing their money. Kickstarter should refund the customers, but I imagine he has already withdrawn all the money and spent it. - Classic example of https://en.wikipedia.org/wiki/Vaporware https://www.kickstarter.com/projects/communitycubes/communitycube-lets-build-a-fair-internet/comments In addition to that, several of his proposals were completely impossible to do and shows he had no basic understanding of networking and computer limitations, just profiting off of the hype for free software and privacy. Any time someone offers you a high-pressure job with unrealistic goals, or a product that can't keep up with it's claims, it is probably a scam. It's also sad that still actively seeks out people to scam by holding them to impossible to reach goals and then lying to his customers about the product's progress. Lesson learned. Avoid this shill like the plague. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From nobody at parabola.nu Sun Mar 5 21:32:21 2017 From: nobody at parabola.nu (Parabola Website Notification) Date: Sun, 05 Mar 2017 21:32:21 -0000 Subject: [Dev] Orphan Libre package [icecat] marked out-of-date Message-ID: <20170305213221.1441.19247@parabola.nu> jc_gargma at iserlohn-fortress.net wants to notify you that the following packages may be out-of-date: * icecat 45.5.1_gnu1-2 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/icecat/ * icecat 45.5.1_gnu1-4 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/icecat/ * icecat 45.5.1_gnu1-4 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/icecat/ * icecat-debug 45.5.1_gnu1-2 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/icecat-debug/ * icecat-debug 45.5.1_gnu1-4 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/icecat-debug/ * icecat-debug 45.5.1_gnu1-4 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/icecat-debug/ The user provided the following additional text: IceCat 45.7.0 has been released. https://lists.gnu.org/archive/html/bug-gnuzilla/2017-03/msg00000.html From nobody at parabola.nu Sun Mar 5 23:53:49 2017 From: nobody at parabola.nu (Parabola Website Notification) Date: Sun, 05 Mar 2017 23:53:49 -0000 Subject: [Dev] Orphan Libre package [iceweasel-l10n-es-ar] marked out-of-date Message-ID: <20170305235349.1441.76458@parabola.nu> eliotime3000 at openmailbox.org wants to notify you that the following packages may be out-of-date: * iceweasel-l10n-ach 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ach/ * iceweasel-l10n-af 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-af/ * iceweasel-l10n-an 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-an/ * iceweasel-l10n-ar 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ar/ * iceweasel-l10n-as 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-as/ * iceweasel-l10n-ast 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ast/ * iceweasel-l10n-az 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-az/ * iceweasel-l10n-bg 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-bg/ * iceweasel-l10n-bn-bd 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-bn-bd/ * iceweasel-l10n-bn-in 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-bn-in/ * iceweasel-l10n-br 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-br/ * iceweasel-l10n-bs 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-bs/ * iceweasel-l10n-ca 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ca/ * iceweasel-l10n-cak 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-cak/ * iceweasel-l10n-cs 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-cs/ * iceweasel-l10n-cy 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-cy/ * iceweasel-l10n-da 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-da/ * iceweasel-l10n-de 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-de/ * iceweasel-l10n-dsb 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-dsb/ * iceweasel-l10n-el 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-el/ * iceweasel-l10n-en-gb 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-en-gb/ * iceweasel-l10n-en-za 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-en-za/ * iceweasel-l10n-eo 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-eo/ * iceweasel-l10n-es-ar 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-es-ar/ * iceweasel-l10n-es-cl 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-es-cl/ * iceweasel-l10n-es-es 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-es-es/ * iceweasel-l10n-es-mx 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-es-mx/ * iceweasel-l10n-et 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-et/ * iceweasel-l10n-eu 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-eu/ * iceweasel-l10n-fa 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-fa/ * iceweasel-l10n-ff 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ff/ * iceweasel-l10n-fi 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-fi/ * iceweasel-l10n-fr 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-fr/ * iceweasel-l10n-fy-nl 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-fy-nl/ * iceweasel-l10n-ga-ie 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ga-ie/ * iceweasel-l10n-gd 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-gd/ * iceweasel-l10n-gl 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-gl/ * iceweasel-l10n-gn 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-gn/ * iceweasel-l10n-gu-in 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-gu-in/ * iceweasel-l10n-he 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-he/ * iceweasel-l10n-hi-in 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-hi-in/ * iceweasel-l10n-hr 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-hr/ * iceweasel-l10n-hsb 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-hsb/ * iceweasel-l10n-hu 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-hu/ * iceweasel-l10n-hy-am 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-hy-am/ * iceweasel-l10n-id 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-id/ * iceweasel-l10n-is 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-is/ * iceweasel-l10n-it 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-it/ * iceweasel-l10n-ja 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ja/ * iceweasel-l10n-kk 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-kk/ * iceweasel-l10n-km 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-km/ * iceweasel-l10n-kn 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-kn/ * iceweasel-l10n-ko 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ko/ * iceweasel-l10n-lij 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-lij/ * iceweasel-l10n-lt 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-lt/ * iceweasel-l10n-lv 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-lv/ * iceweasel-l10n-mai 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-mai/ * iceweasel-l10n-mk 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-mk/ * iceweasel-l10n-ml 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ml/ * iceweasel-l10n-mr 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-mr/ * iceweasel-l10n-ms 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ms/ * iceweasel-l10n-nb-no 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-nb-no/ * iceweasel-l10n-nl 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-nl/ * iceweasel-l10n-nn-no 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-nn-no/ * iceweasel-l10n-or 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-or/ * iceweasel-l10n-pa-in 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-pa-in/ * iceweasel-l10n-pl 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-pl/ * iceweasel-l10n-pt-br 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-pt-br/ * iceweasel-l10n-pt-pt 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-pt-pt/ * iceweasel-l10n-rm 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-rm/ * iceweasel-l10n-ro 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ro/ * iceweasel-l10n-ru 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ru/ * iceweasel-l10n-si 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-si/ * iceweasel-l10n-sk 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-sk/ * iceweasel-l10n-sl 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-sl/ * iceweasel-l10n-son 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-son/ * iceweasel-l10n-sq 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-sq/ * iceweasel-l10n-sr 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-sr/ * iceweasel-l10n-sv-se 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-sv-se/ * iceweasel-l10n-ta 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ta/ * iceweasel-l10n-te 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-te/ * iceweasel-l10n-th 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-th/ * iceweasel-l10n-tr 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-tr/ * iceweasel-l10n-uk 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-uk/ * iceweasel-l10n-uz 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-uz/ * iceweasel-l10n-vi 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-vi/ * iceweasel-l10n-xh 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-xh/ * iceweasel-l10n-zh-cn 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-zh-cn/ * iceweasel-l10n-zh-tw 1:51.0.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-zh-tw/ The user provided the following additional text: The actual language pack version of Iceweasel (1:51.0.1.deb1-1) does not match with the main application version (1:51.0.1.deb3-1), generating a conflict between both packages. Please update the language pack version of Iceweasel to make effective the update. Thanks. From emulatorman at riseup.net Mon Mar 6 23:36:05 2017 From: emulatorman at riseup.net (=?UTF-8?Q?Andr=c3=a9_Silva?=) Date: Mon, 6 Mar 2017 23:36:05 +0000 Subject: [Dev] Fwd: Re: Article: Chromium's subtle freedom flaws In-Reply-To: References: Message-ID: Per Richard Stallman, we are removing QTWebengine. It is the entire Chromium browser, which is non-free. -------- Forwarded Message -------- Subject: Re: Article: Chromium's subtle freedom flaws Date: Sun, 05 Mar 2017 20:33:34 -0500 From: Richard Stallman Reply-To: rms at gnu.org To: Luke CC: emulatorman at parabola.nu [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Has there been any update on this? It is going to take time. We would like remove Chromium from > Parabola until the freedom issues have been fixed/forked. I think that is wise. -- Dr Richard Stallman President, Free Software Foundation (gnu.org, fsf.org) Internet Hall-of-Famer (internethalloffame.org) Skype: No way! See stallman.org/skype.html. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From fauno at endefensadelsl.org Tue Mar 7 00:08:39 2017 From: fauno at endefensadelsl.org (fauno) Date: Mon, 06 Mar 2017 21:08:39 -0300 Subject: [Dev] Fwd: Re: Article: Chromium's subtle freedom flaws In-Reply-To: References: Message-ID: <87efyane2g.fsf@endefensadelsl.org> Andr? Silva writes: > Per Richard Stallman, we are removing QTWebengine. It is the entire > Chromium browser, which is non-free. what are those subtle flaws? -- :O -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 617 bytes Desc: not available URL: From g4jc at openmailbox.org Tue Mar 7 00:13:24 2017 From: g4jc at openmailbox.org (Luke) Date: Tue, 7 Mar 2017 00:13:24 +0000 Subject: [Dev] Fwd: Re: Article: Chromium's subtle freedom flaws In-Reply-To: <87efyane2g.fsf@endefensadelsl.org> References: <87efyane2g.fsf@endefensadelsl.org> Message-ID: <962e148d-579d-6b8e-d77a-a95bdfcd2da0@openmailbox.org> On 03/07/2017 12:08 AM, fauno wrote: > Andr? Silva writes: > >> Per Richard Stallman, we are removing QTWebengine. It is the entire >> Chromium browser, which is non-free. > what are those subtle flaws? > The article hasn't been published yet, it should be announced on FSF soon. TL; DR: Hundreds of line of minified js, non-free plugins, DRM, hard-coded connections to Google.com, and privacy leaks. Stallman recommended that someone should make a fork similar to GNUIcecat for Chromium to address these issues, patching is not enough. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From nobody at parabola.nu Tue Mar 7 00:14:26 2017 From: nobody at parabola.nu (Parabola Website Notification) Date: Tue, 07 Mar 2017 00:14:26 -0000 Subject: [Dev] Orphan Pcr package [xfce-theme-greybird] marked out-of-date Message-ID: <20170307001426.1445.19213@parabola.nu> eliotime3000 at openmailbox.org wants to notify you that the following packages may be out-of-date: * xfce-theme-greybird 3.22.1-1 [pcr] (any): https://parabolagnulinux.org/packages/pcr/any/xfce-theme-greybird/ The user provided the following additional text: Please update to Greybird 3.22.2 from the GIT repo. The AUR page shows the upgraded version. https://aur.archlinux.org/packages/xfce-theme-greybird/ From david.pizarro at openmailbox.org Tue Mar 7 13:13:09 2017 From: david.pizarro at openmailbox.org (David Pizarro) Date: Tue, 7 Mar 2017 10:13:09 -0300 Subject: [Dev] Fwd: Re: Article: Chromium's subtle freedom flaws In-Reply-To: <962e148d-579d-6b8e-d77a-a95bdfcd2da0@openmailbox.org> References: <87efyane2g.fsf@endefensadelsl.org> <962e148d-579d-6b8e-d77a-a95bdfcd2da0@openmailbox.org> Message-ID: <17b64654-4dbc-0ac6-5375-fafc8706bdd1@openmailbox.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 That's a good idea, but what about Iridium? maybe we could fork it, and make a replacement for QTWebengine, which can also be used for other libre distros. Now QTWebengine will be blacklisted? El 06/03/17 a las 21:13, Luke escribi?: > On 03/07/2017 12:08 AM, fauno wrote: >> Andr? Silva writes: >> >>> Per Richard Stallman, we are removing QTWebengine. It is the >>> entire Chromium browser, which is non-free. >> what are those subtle flaws? >> > The article hasn't been published yet, it should be announced on > FSF soon. > > TL; DR: Hundreds of line of minified js, non-free plugins, DRM, > hard-coded connections to Google.com, and privacy leaks. Stallman > recommended that someone should make a fork similar to GNUIcecat > for Chromium to address these issues, patching is not enough. > > > > _______________________________________________ Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev > -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEErCbv92SojUTThXEpQKKthCTeGvMFAli+seAACgkQQKKthCTe GvMUXQf/W4dDwmFEbDipPRja9Ifh3d98LcbP0QyM+YEhuZeelJgLRlEZl/H7jnW2 dRkQdeFevj7ZvydkbUMo7rdoHIt58e2NLZACmoCNgi1CWsupGO00HHkoBCqV/Dzm 5zBUFP8YtNBQubCQu7JhIsCY/Si6VQao25g02WZb/zWfZhcyRaTAL2a1fn0G5ovI E/X2laM1Vs1mEFspYbiRNznBIQllVMC2d9mw721SKfww1dQXVXTapFvepKk5VNzj Wt9ATkZHOAdxLaRK2HcYZiYUH9LnCx1gxOzxGHTulwYytjwnvb2moyLsyQq8yRYQ 7hmzT3raRuU2Hx3pvOerVPMkiun+ag== =Djtl -----END PGP SIGNATURE----- From nobody at parabola.nu Wed Mar 8 23:45:24 2017 From: nobody at parabola.nu (Parabola Website Notification) Date: Wed, 08 Mar 2017 23:45:24 -0000 Subject: [Dev] Orphan Libre package [iceweasel] marked out-of-date Message-ID: <20170308234524.1441.8219@parabola.nu> eliotime3000 at openmailbox.org wants to notify you that the following packages may be out-of-date: * iceweasel 1:51.0.1.deb3-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/iceweasel/ * iceweasel 1:51.0.1.deb3-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/iceweasel/ * iceweasel-debug 1:51.0.1.deb3-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/iceweasel-debug/ * iceweasel-debug 1:51.0.1.deb3-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/iceweasel-debug/ The user provided the following additional text: Please update Iceweasel to the version 52, which is avariable at Debian unstable repository. https://packages.debian.org/sid/firefox From nobody at parabola.nu Wed Mar 8 23:45:49 2017 From: nobody at parabola.nu (Parabola Website Notification) Date: Wed, 08 Mar 2017 23:45:49 -0000 Subject: [Dev] Orphan Libre package [iceweasel-l10n-es-ar] marked out-of-date Message-ID: <20170308234549.1445.68604@parabola.nu> eliotime3000 at openmailbox.org wants to notify you that the following packages may be out-of-date: * iceweasel-l10n-ach 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ach/ * iceweasel-l10n-af 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-af/ * iceweasel-l10n-an 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-an/ * iceweasel-l10n-ar 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ar/ * iceweasel-l10n-as 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-as/ * iceweasel-l10n-ast 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ast/ * iceweasel-l10n-az 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-az/ * iceweasel-l10n-bg 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-bg/ * iceweasel-l10n-bn-bd 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-bn-bd/ * iceweasel-l10n-bn-in 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-bn-in/ * iceweasel-l10n-br 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-br/ * iceweasel-l10n-bs 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-bs/ * iceweasel-l10n-ca 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ca/ * iceweasel-l10n-cak 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-cak/ * iceweasel-l10n-cs 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-cs/ * iceweasel-l10n-cy 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-cy/ * iceweasel-l10n-da 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-da/ * iceweasel-l10n-de 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-de/ * iceweasel-l10n-dsb 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-dsb/ * iceweasel-l10n-el 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-el/ * iceweasel-l10n-en-gb 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-en-gb/ * iceweasel-l10n-en-za 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-en-za/ * iceweasel-l10n-eo 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-eo/ * iceweasel-l10n-es-ar 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-es-ar/ * iceweasel-l10n-es-cl 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-es-cl/ * iceweasel-l10n-es-es 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-es-es/ * iceweasel-l10n-es-mx 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-es-mx/ * iceweasel-l10n-et 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-et/ * iceweasel-l10n-eu 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-eu/ * iceweasel-l10n-fa 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-fa/ * iceweasel-l10n-ff 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ff/ * iceweasel-l10n-fi 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-fi/ * iceweasel-l10n-fr 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-fr/ * iceweasel-l10n-fy-nl 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-fy-nl/ * iceweasel-l10n-ga-ie 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ga-ie/ * iceweasel-l10n-gd 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-gd/ * iceweasel-l10n-gl 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-gl/ * iceweasel-l10n-gn 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-gn/ * iceweasel-l10n-gu-in 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-gu-in/ * iceweasel-l10n-he 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-he/ * iceweasel-l10n-hi-in 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-hi-in/ * iceweasel-l10n-hr 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-hr/ * iceweasel-l10n-hsb 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-hsb/ * iceweasel-l10n-hu 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-hu/ * iceweasel-l10n-hy-am 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-hy-am/ * iceweasel-l10n-id 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-id/ * iceweasel-l10n-is 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-is/ * iceweasel-l10n-it 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-it/ * iceweasel-l10n-ja 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ja/ * iceweasel-l10n-kk 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-kk/ * iceweasel-l10n-km 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-km/ * iceweasel-l10n-kn 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-kn/ * iceweasel-l10n-ko 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ko/ * iceweasel-l10n-lij 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-lij/ * iceweasel-l10n-lt 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-lt/ * iceweasel-l10n-lv 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-lv/ * iceweasel-l10n-mai 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-mai/ * iceweasel-l10n-mk 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-mk/ * iceweasel-l10n-ml 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ml/ * iceweasel-l10n-mr 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-mr/ * iceweasel-l10n-ms 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ms/ * iceweasel-l10n-nb-no 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-nb-no/ * iceweasel-l10n-nl 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-nl/ * iceweasel-l10n-nn-no 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-nn-no/ * iceweasel-l10n-or 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-or/ * iceweasel-l10n-pa-in 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-pa-in/ * iceweasel-l10n-pl 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-pl/ * iceweasel-l10n-pt-br 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-pt-br/ * iceweasel-l10n-pt-pt 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-pt-pt/ * iceweasel-l10n-rm 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-rm/ * iceweasel-l10n-ro 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ro/ * iceweasel-l10n-ru 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ru/ * iceweasel-l10n-si 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-si/ * iceweasel-l10n-sk 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-sk/ * iceweasel-l10n-sl 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-sl/ * iceweasel-l10n-son 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-son/ * iceweasel-l10n-sq 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-sq/ * iceweasel-l10n-sr 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-sr/ * iceweasel-l10n-sv-se 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-sv-se/ * iceweasel-l10n-ta 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ta/ * iceweasel-l10n-te 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-te/ * iceweasel-l10n-th 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-th/ * iceweasel-l10n-tr 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-tr/ * iceweasel-l10n-uk 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-uk/ * iceweasel-l10n-uz 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-uz/ * iceweasel-l10n-vi 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-vi/ * iceweasel-l10n-xh 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-xh/ * iceweasel-l10n-zh-cn 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-zh-cn/ * iceweasel-l10n-zh-tw 1:51.0.1.deb3-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-zh-tw/ The user provided the following additional text: Please update the Iceweasel language packs to the version 52, which is avariable at Debian unstable repository. https://packages.debian.org/sid/firefox From emulatorman at riseup.net Thu Mar 9 06:44:33 2017 From: emulatorman at riseup.net (=?UTF-8?Q?Andr=c3=a9_Silva?=) Date: Thu, 9 Mar 2017 06:44:33 +0000 Subject: [Dev] Orphan Libre package [iceweasel] marked out-of-date In-Reply-To: <20170308234524.1441.8219@parabola.nu> References: <20170308234524.1441.8219@parabola.nu> Message-ID: <1212d8e1-861c-34ac-6da1-503f0e193ddc@riseup.net> On 03/08/2017 11:45 PM, Parabola Website Notification wrote: > eliotime3000 at openmailbox.org wants to notify you that the following packages may be out-of-date: > > > * iceweasel 1:51.0.1.deb3-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/iceweasel/ > * iceweasel 1:51.0.1.deb3-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/iceweasel/ > * iceweasel-debug 1:51.0.1.deb3-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/iceweasel-debug/ > * iceweasel-debug 1:51.0.1.deb3-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/iceweasel-debug/ > > > The user provided the following additional text: > > Please update Iceweasel to the version 52, which is avariable at Debian unstable repository. > > https://packages.debian.org/sid/firefox Thanks eliotime3000 for the reporting, i'm preparing the new version of Iceweasel yet [0] since it requires new modifications. I let you know when it is ready. :) [0]:https://git.parabola.nu/packages/iceweasel.git/commit/?h=52.0&id=458d41028a245b68f8c5c6b28ec837454988b7f4 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From nobody at parabola.nu Thu Mar 9 19:54:53 2017 From: nobody at parabola.nu (Parabola Website Notification) Date: Thu, 09 Mar 2017 19:54:53 -0000 Subject: [Dev] Orphan Pcr package [peek] marked out-of-date Message-ID: <20170309195453.7635.53832@parabola.nu> ph.wolfer at gmail.com wants to notify you that the following packages may be out-of-date: * peek 0.8.0-1 [pcr] (i686): https://parabolagnulinux.org/packages/pcr/i686/peek/ * peek 0.8.0-1 [pcr] (x86_64): https://parabolagnulinux.org/packages/pcr/x86_64/peek/ The user provided the following additional text: Release 0.9.1 is available From emulatorman at riseup.net Fri Mar 10 04:05:02 2017 From: emulatorman at riseup.net (=?UTF-8?Q?Andr=c3=a9_Silva?=) Date: Fri, 10 Mar 2017 04:05:02 +0000 Subject: [Dev] Orphan Libre package [iceweasel] marked out-of-date In-Reply-To: <1212d8e1-861c-34ac-6da1-503f0e193ddc@riseup.net> References: <20170308234524.1441.8219@parabola.nu> <1212d8e1-861c-34ac-6da1-503f0e193ddc@riseup.net> Message-ID: <51070f9d-d65a-d8f8-e387-f4396b76e5eb@riseup.net> On 03/09/2017 06:44 AM, Andr? Silva wrote: > On 03/08/2017 11:45 PM, Parabola Website Notification wrote: >> eliotime3000 at openmailbox.org wants to notify you that the following packages may be out-of-date: >> >> >> * iceweasel 1:51.0.1.deb3-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/iceweasel/ >> * iceweasel 1:51.0.1.deb3-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/iceweasel/ >> * iceweasel-debug 1:51.0.1.deb3-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/iceweasel-debug/ >> * iceweasel-debug 1:51.0.1.deb3-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/iceweasel-debug/ >> >> >> The user provided the following additional text: >> >> Please update Iceweasel to the version 52, which is avariable at Debian unstable repository. >> >> https://packages.debian.org/sid/firefox > > Thanks eliotime3000 for the reporting, i'm preparing the new version of > Iceweasel yet [0] since it requires new modifications. I let you know > when it is ready. :) > > [0]:https://git.parabola.nu/packages/iceweasel.git/commit/?h=52.0&id=458d41028a245b68f8c5c6b28ec837454988b7f4 iceweasel-1:52.0.deb1-1 pushed (including language packs) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From lukeshu at lukeshu.com Fri Mar 10 17:44:11 2017 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Fri, 10 Mar 2017 12:44:11 -0500 Subject: [Dev] [RFC] Documentation in post_install() Message-ID: <87zigt6n84.wl-lukeshu@lukeshu.com> There's an increasing trend to put bits of documentation in post_install(). This is particularly common for openrc packages. I think that this trend should die. That's what /usr/share/doc is for. That's what the wiki is for. I shouldn't have to try to parse through scripts in `/var/lib/pacman/local/*/install` to re-read documentation. -- Happy hacking, ~ Luke Shumaker From nobody at parabola.nu Fri Mar 10 17:54:04 2017 From: nobody at parabola.nu (Parabola Website Notification) Date: Fri, 10 Mar 2017 17:54:04 -0000 Subject: [Dev] Orphan Libre package [icedove] marked out-of-date Message-ID: <20170310175404.7634.98907@parabola.nu> eliotime3000 at openmailbox.org wants to notify you that the following packages may be out-of-date: * icedove 1:45.7.1.deb1-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/icedove/ * icedove 1:45.7.1.deb1-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/icedove/ The user provided the following additional text: Please update Icedove to the version 45.8.0, according to the Debian webpage. https://packages.debian.org/sid/icedove https://anonscm.debian.org/cgit/pkg-mozilla/icedove.git From nobody at parabola.nu Fri Mar 10 17:54:27 2017 From: nobody at parabola.nu (Parabola Website Notification) Date: Fri, 10 Mar 2017 17:54:27 -0000 Subject: [Dev] Orphan Libre package [icedove-l10n-es-ar] marked out-of-date Message-ID: <20170310175427.7634.40590@parabola.nu> eliotime3000 at openmailbox.org wants to notify you that the following packages may be out-of-date: * icedove-l10n-ar 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-ar/ * icedove-l10n-ast 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-ast/ * icedove-l10n-be 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-be/ * icedove-l10n-bg 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-bg/ * icedove-l10n-bn-bd 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-bn-bd/ * icedove-l10n-br 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-br/ * icedove-l10n-ca 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-ca/ * icedove-l10n-cs 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-cs/ * icedove-l10n-cy 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-cy/ * icedove-l10n-da 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-da/ * icedove-l10n-de 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-de/ * icedove-l10n-dsb 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-dsb/ * icedove-l10n-el 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-el/ * icedove-l10n-en-gb 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-en-gb/ * icedove-l10n-en-us 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-en-us/ * icedove-l10n-es-ar 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-es-ar/ * icedove-l10n-es-es 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-es-es/ * icedove-l10n-et 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-et/ * icedove-l10n-eu 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-eu/ * icedove-l10n-fi 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-fi/ * icedove-l10n-fr 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-fr/ * icedove-l10n-fy-nl 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-fy-nl/ * icedove-l10n-ga-ie 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-ga-ie/ * icedove-l10n-gd 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-gd/ * icedove-l10n-gl 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-gl/ * icedove-l10n-he 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-he/ * icedove-l10n-hr 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-hr/ * icedove-l10n-hsb 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-hsb/ * icedove-l10n-hu 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-hu/ * icedove-l10n-hy-am 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-hy-am/ * icedove-l10n-id 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-id/ * icedove-l10n-is 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-is/ * icedove-l10n-it 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-it/ * icedove-l10n-ja 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-ja/ * icedove-l10n-ko 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-ko/ * icedove-l10n-lt 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-lt/ * icedove-l10n-nb-no 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-nb-no/ * icedove-l10n-nl 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-nl/ * icedove-l10n-nn-no 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-nn-no/ * icedove-l10n-pa-in 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-pa-in/ * icedove-l10n-pl 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-pl/ * icedove-l10n-pt-br 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-pt-br/ * icedove-l10n-pt-pt 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-pt-pt/ * icedove-l10n-rm 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-rm/ * icedove-l10n-ro 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-ro/ * icedove-l10n-ru 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-ru/ * icedove-l10n-si 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-si/ * icedove-l10n-sk 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-sk/ * icedove-l10n-sl 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-sl/ * icedove-l10n-sq 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-sq/ * icedove-l10n-sr 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-sr/ * icedove-l10n-sv-se 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-sv-se/ * icedove-l10n-ta-lk 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-ta-lk/ * icedove-l10n-tr 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-tr/ * icedove-l10n-uk 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-uk/ * icedove-l10n-vi 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-vi/ * icedove-l10n-zh-cn 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-zh-cn/ * icedove-l10n-zh-tw 1:45.7.1.deb1-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/icedove-l10n-zh-tw/ The user provided the following additional text: Please update Icedove language packs to the version 45.8.0, according to the Debian webpage. https://packages.debian.org/sid/icedove https://anonscm.debian.org/cgit/pkg-mozilla/icedove.git From nobody at parabola.nu Fri Mar 10 17:55:21 2017 From: nobody at parabola.nu (Parabola Website Notification) Date: Fri, 10 Mar 2017 17:55:21 -0000 Subject: [Dev] Orphan Nonprism package [icedove] marked out-of-date Message-ID: <20170310175521.7634.91406@parabola.nu> eliotime3000 at openmailbox.org wants to notify you that the following packages may be out-of-date: The user provided the following additional text: Please update Icedove (Non-PRISM edition) to the version 45.8.0, according to the Debian webpage. https://packages.debian.org/sid/icedove https://anonscm.debian.org/cgit/pkg-mozilla/icedove.git From david.pizarro at openmailbox.org Fri Mar 10 17:57:48 2017 From: david.pizarro at openmailbox.org (David Pizarro) Date: Fri, 10 Mar 2017 14:57:48 -0300 Subject: [Dev] [RFC] Documentation in post_install() In-Reply-To: <87zigt6n84.wl-lukeshu@lukeshu.com> References: <87zigt6n84.wl-lukeshu@lukeshu.com> Message-ID: <4a8d15ae-e84f-ab2d-31b5-e21f6fc053f5@openmailbox.org> OpenRC! I can confirm that's true and I agree with you Luke, that's what the wiki is for. El 10/03/17 a las 14:44, Luke Shumaker escribi?: > There's an increasing trend to put bits of documentation in > post_install(). This is particularly common for openrc packages. > > I think that this trend should die. That's what /usr/share/doc is > for. That's what the wiki is for. I shouldn't have to try to parse > through scripts in `/var/lib/pacman/local/*/install` to re-read > documentation. > From nobody at parabola.nu Sat Mar 11 00:41:23 2017 From: nobody at parabola.nu (Parabola Website Notification) Date: Sat, 11 Mar 2017 00:41:23 -0000 Subject: [Dev] Orphan Libre package [linux-libre-api-headers] marked out-of-date Message-ID: <20170311004123.7634.41216@parabola.nu> megver83 at openmailbox.org wants to notify you that the following packages may be out-of-date: * linux-libre-api-headers 4.7_gnu-1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/linux-libre-api-headers/ * linux-libre-api-headers 4.7_gnu-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/linux-libre-api-headers/ * linux-libre-api-headers 4.7_gnu-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/linux-libre-api-headers/ The user provided the following additional text: New version 4.10 Now some packages depend on this new version, otherwise upgrading is not possible. From nobody at parabola.nu Sat Mar 11 01:31:44 2017 From: nobody at parabola.nu (Parabola Website Notification) Date: Sat, 11 Mar 2017 01:31:44 -0000 Subject: [Dev] Orphan Libre package [linux-libre] marked out-of-date Message-ID: <20170311013144.7634.52520@parabola.nu> eliotime3000 at openmailbox.org wants to notify you that the following packages may be out-of-date: * linux-libre 4.9.6_gnu-1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/linux-libre/ * linux-libre 4.9.11_gnu-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/linux-libre/ * linux-libre 4.9.11_gnu-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/linux-libre/ * linux-libre-docs 4.9.6_gnu-1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/linux-libre-docs/ * linux-libre-docs 4.9.11_gnu-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/linux-libre-docs/ * linux-libre-docs 4.9.11_gnu-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/linux-libre-docs/ * linux-libre-headers 4.9.6_gnu-1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/linux-libre-headers/ * linux-libre-headers 4.9.11_gnu-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/linux-libre-headers/ * linux-libre-headers 4.9.11_gnu-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/linux-libre-headers/ The user provided the following additional text: Please update to Liunx-libre 4.10.1 for Parabola GNU/Linux-libre. Arch Linux updated today the vanilla kernel to the 4.10.1. From nobody at parabola.nu Sun Mar 12 11:00:45 2017 From: nobody at parabola.nu (Parabola Website Notification) Date: Sun, 12 Mar 2017 11:00:45 -0000 Subject: [Dev] Orphan Libre package [qupzilla] marked out-of-date Message-ID: <20170312110045.7634.9278@parabola.nu> felicien at gnu.org wants to notify you that the following packages may be out-of-date: * qupzilla 2.0.2-1.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/qupzilla/ The user provided the following additional text: Hi, this package has not been upgraded since 2016-10-24, and is causing conflicts (with your-freedom) during system upgrade. Here is the last commits of the ArchLinux package: Age Commit message Author 9 days openssl 1.1 rebuild arojas 2017-02-14 Update to 2.1.1 arojas 2017-02-08 Remove hunspell dependency (FS#52894) arojas 2017-02-08 Add missing qt5-svg dependency (FS#52854) arojas 2017-02-04 Update to 2.1.0 arojas 2016-10-24 Update to 2.0.2 arojas From emulatorman at riseup.net Sun Mar 12 13:04:14 2017 From: emulatorman at riseup.net (=?UTF-8?Q?Andr=c3=a9_Silva?=) Date: Sun, 12 Mar 2017 13:04:14 +0000 Subject: [Dev] Orphan Libre package [qupzilla] marked out-of-date In-Reply-To: <20170312110045.7634.9278@parabola.nu> References: <20170312110045.7634.9278@parabola.nu> Message-ID: On 03/12/2017 11:00 AM, Parabola Website Notification wrote: > felicien at gnu.org wants to notify you that the following packages may be out-of-date: > > > * qupzilla 2.0.2-1.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/qupzilla/ > > > The user provided the following additional text: > > Hi, this package has not been upgraded since 2016-10-24, and is causing conflicts (with your-freedom) during system upgrade. > > Here is the last commits of the ArchLinux package: > > Age Commit message Author > 9 days openssl 1.1 rebuild arojas > 2017-02-14 Update to 2.1.1 arojas > 2017-02-08 Remove hunspell dependency (FS#52894) arojas > 2017-02-08 Add missing qt5-svg dependency (FS#52854) arojas > 2017-02-04 Update to 2.1.0 arojas > 2016-10-24 Update to 2.0.2 arojas > > > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev > qupzilla has been blacklist since it is one of packages affected by nonfree qt5-webengine. See our announcement about it [0] for further details. [0]:https://www.parabola.nu/news/chromium-blacklisted-to-respect-your-freedom/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From emulatorman at riseup.net Sun Mar 12 13:59:24 2017 From: emulatorman at riseup.net (=?UTF-8?Q?Andr=c3=a9_Silva?=) Date: Sun, 12 Mar 2017 13:59:24 +0000 Subject: [Dev] Orphan Libre package [qupzilla] marked out-of-date In-Reply-To: References: <20170312110045.7634.9278@parabola.nu> Message-ID: On 03/12/2017 01:04 PM, Andr? Silva wrote: > On 03/12/2017 11:00 AM, Parabola Website Notification wrote: >> felicien at gnu.org wants to notify you that the following packages may be out-of-date: >> >> >> * qupzilla 2.0.2-1.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/qupzilla/ >> >> >> The user provided the following additional text: >> >> Hi, this package has not been upgraded since 2016-10-24, and is causing conflicts (with your-freedom) during system upgrade. >> >> Here is the last commits of the ArchLinux package: >> >> Age Commit message Author >> 9 days openssl 1.1 rebuild arojas >> 2017-02-14 Update to 2.1.1 arojas >> 2017-02-08 Remove hunspell dependency (FS#52894) arojas >> 2017-02-08 Add missing qt5-svg dependency (FS#52854) arojas >> 2017-02-04 Update to 2.1.0 arojas >> 2016-10-24 Update to 2.0.2 arojas >> >> >> _______________________________________________ >> Dev mailing list >> Dev at lists.parabola.nu >> https://lists.parabola.nu/mailman/listinfo/dev >> > > qupzilla has been blacklist since it is one of packages affected by > nonfree qt5-webengine. See our announcement about it [0] for further > details. > > [0]:https://www.parabola.nu/news/chromium-blacklisted-to-respect-your-freedom/ s|blacklist|blacklisted| -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From louis at bettens.org Sun Mar 12 17:26:50 2017 From: louis at bettens.org (Louis Bettens) Date: Sun, 12 Mar 2017 18:26:50 +0100 Subject: [Dev] lzo2 virtual package gone Message-ID: Hey everyone, Apologies for coming out of the blue like that, but I encountered a trivial bug introduced by the last release of lzo while toying with Xen. This seems to be due to https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/lzo&id=eb70476e9442d349f3c353e91631c0e713781c07, but despite the fact that this commit is 1yo, it was dormant until Arch released lzo 2.10-1. Attached patch seems to fix it, hope it's of use to you. I haven't done any tests on that, but I assume it's safe. Sorry again for distracting, I know this is my first message here and it's inherently rude, but I hope I did the right thing. I'll come back to introduce myself properly shortly, and I hope I can contribute again to this wonderful distro I have been using for ~1 year. LB -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xF16E1A51.asc Type: application/pgp-keys Size: 1420 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-fix-missing-dependency-lzo2.patch Type: text/x-patch Size: 1577 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From isacdaavid at isacdaavid.info Tue Mar 14 20:56:54 2017 From: isacdaavid at isacdaavid.info (Isaac David) Date: Tue, 14 Mar 2017 14:56:54 -0600 Subject: [Dev] lzo2 virtual package gone In-Reply-To: References: Message-ID: <1489525014.1318.0@plebeian.isacdaavid.info> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 NotDashEscaped: You need gpg to verify this message Louis Bettens: > Hey everyone, > > Apologies for coming out of the blue like that, but I encountered a > trivial bug introduced by the last release of lzo while toying with Xen. > > This seems to be due to > https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/lzo&id=eb70476e9442d349f3c353e91631c0e713781c07, > but despite the fact that this commit is 1yo, it was dormant until Arch > released lzo 2.10-1. > > Attached patch seems to fix it, hope it's of use to you. I haven't done > any tests on that, but I assume it's safe. thank you, your commit was pushed. new tinc-pre and xen releases are in the oven. did you know those were the only 2 packages still depending on lzo2 ? if so, I'm curious as to how you found them when lzo2 was already gone from the package databases. old database backups?, querying package metadata for everything in [libre], [pcr], etc? I had to add a dummy lzo2 to a throw-away repo database before I could point pacman to it and run `pacman -Sii lzo2` -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEONM+8pp2kRNDV2SHM0ZuEux7qUMFAljIWKYACgkQM0ZuEux7 qUP6iBAApPW3/VvVKliILGv3gVQ3nYPnuUkFfYikEUIOsLCSMarZ6I7RPyQTQeXx BX5F+DTT2P1gp8KfDDTqlLonfEQv4ha0tkGLhGv/PCuSxkSZdt/lezX/xSGRKE88 7WxFw6m1Gx6eOrGBvrUIYkf9nX3HlPXK5TQ9bvPt3hDnuk+DWCW8mZW8vIAom118 GU6+ACxuAlP4xjzD9jub28EXktYciag5rZI8SIzfmZUAXsMwwdGuzFn9YQBgmnd1 Oq5ZHhww/KfdCuxwJn6ToMzaQQ7C6DptG0Blgo5b7lFrk7P5BqnEh8dD3ievIN2Q Q5ylkGKs8qAZg9gtPX36pgyXP98e4pi2AizGXd1PJ0GPo9vyRGKG4OjpkD9RaR4V kVUYylUxM3v/NJWFS4LhQf6BXIoG24EGYHHK/HF9A5ywMSLooe1RTD97kpqKTNcN G7TmQoAu7wQIUpXlcaiWLoaiUEKBXcXXllo95oOGZGaaFi1tCP4BDs9qbs0VUTw2 WTKEzIBJ6+VDXdqkUKGLzAD0bagETENyvgrwNKxdtnN2rAzzrE+eDA+dMkwMwaKH yLyPM5Ehwh4BPawAO0K/fWDgEXPxT9EA1HW62jV3B6NFJledXHDShuiijMuhnZg4 ud9SaK9IH8WtHbeVnn1KhD6FWgLsecyzf2WHXKTvqqiQ7xY2s6o= =54UB -----END PGP SIGNATURE----- From louis at bettens.org Tue Mar 14 21:34:45 2017 From: louis at bettens.org (Louis Bettens) Date: Tue, 14 Mar 2017 22:34:45 +0100 Subject: [Dev] lzo2 virtual package gone In-Reply-To: <1489525014.1318.0@plebeian.isacdaavid.info> References: <1489525014.1318.0@plebeian.isacdaavid.info> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 14. 03. 17 21:56, Isaac David wrote: > thank you, your commit was pushed. new tinc-pre and xen releases > are in the oven. > Happy to hear that, thank you. > did you know those were the only 2 packages still depending on lzo2 > ? if so, I'm curious as to how you found them when lzo2 was already > gone from the package databases. old database backups?, querying > package metadata for everything in [libre], [pcr], etc? I had to > add a dummy lzo2 to a throw-away repo database before I could point > pacman to it and run `pacman -Sii lzo2` > Well... actually I just grepped through abslibre.git, I should have mentionned that. Arch took care of their own packages, so only those we maintain separately mattered, so it occured to me as the most logical place to look into. LB -----BEGIN PGP SIGNATURE----- iIgEARYIADAWIQTBHYGyWXcnF7tYuN/coJ8q8W4aUQUCWMhh9BIcbG91aXNAYmV0 dGVucy5vcmcACgkQ3KCfKvFuGlFz8QD9F3DMhs49X8vMmO9tl78irN54k5/4Ctqs wHHMBM4P78QA/3g+yTDN6eoFOrwu+P8eLJ3ocApNdWEHMdQ6fdk5HqQB =vaYe -----END PGP SIGNATURE----- From nospam at curso.re Thu Mar 16 14:59:25 2017 From: nospam at curso.re (nospam at curso.re) Date: Thu, 16 Mar 2017 14:59:25 +0000 Subject: [Dev] ca-certificates-mozilla-3.29.3-2 and ca-certificates-utils-20170307-1 may be broken Message-ID: <8760j9z2r6.fsf@example.com> Hi all, posting from gmane... I hope this is OK. I have just tried a system upgrade and HTTPS connection broke when I installed ca-certificates-mozilla-3.29.3-2 Operations like `pacman -Syu` or `git fetch origin` failed due to problems with SSL certificates. Restoring ca-certificates-mozilla-3.28.1-1 from pacman's cache solved the problems. I have put ca-certificates-mozilla in my IgnorePkg list in `/etc/pacman.conf` temporarily so I can upgrade the other packages. Additionally, I had a problem with the installation of `ca-certificates-utils-20170307-1` that failed complaining that `/etc/ssl/certs/ca-certificates.crt` already existed (in fact that was true and it was a symlink). I had to rename the symlink to be able to install the package. Have I been doing something wrong or are the packages broken? I hope that you'll find this information useful. Best, -- S. From david.pizarro at openmailbox.org Thu Mar 16 15:08:56 2017 From: david.pizarro at openmailbox.org (David Pizarro) Date: Thu, 16 Mar 2017 12:08:56 -0300 Subject: [Dev] ca-certificates-mozilla-3.29.3-2 and ca-certificates-utils-20170307-1 may be broken In-Reply-To: <8760j9z2r6.fsf@example.com> References: <8760j9z2r6.fsf@example.com> Message-ID: Did you read the lastest Parabola's News before posting? https://www.parabola.nu/news/ca-certificates-utils-20170307-1-upgrade-requires-manual-intervention/ El 16/03/17 a las 11:59, nospam at curso.re escribi?: > Hi all, > > posting from gmane... I hope this is OK. > > I have just tried a system upgrade and HTTPS connection broke when I > installed ca-certificates-mozilla-3.29.3-2 > > Operations like `pacman -Syu` or `git fetch origin` failed due to > problems with SSL certificates. Restoring > ca-certificates-mozilla-3.28.1-1 from pacman's cache solved the > problems. > > I have put ca-certificates-mozilla in my IgnorePkg list in > `/etc/pacman.conf` temporarily so I can upgrade the other packages. > > Additionally, I had a problem with the installation of > `ca-certificates-utils-20170307-1` that failed complaining that > `/etc/ssl/certs/ca-certificates.crt` already existed (in fact that was > true and it was a symlink). I had to rename the symlink to be able to > install the package. > > Have I been doing something wrong or are the packages broken? > > I hope that you'll find this information useful. > > Best, > > -- S. > > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev > From nospam at curso.re Thu Mar 16 15:22:03 2017 From: nospam at curso.re (nospam at curso.re) Date: Thu, 16 Mar 2017 15:22:03 +0000 Subject: [Dev] ca-certificates-mozilla-3.29.3-2 and ca-certificates-utils-20170307-1 may be broken References: <8760j9z2r6.fsf@example.com> Message-ID: <87var9xn50.fsf@example.com> David Pizarro writes: > Did you read the lastest Parabola's News before posting? > https://www.parabola.nu/news/ca-certificates-utils-20170307-1-upgrade-requires-manual-intervention/ > No, I haven't. In fact I have just noticed it and as a consequence have subscribed to the RSS feed. Actually, I thought that the main problem was the mozilla certificates packages, which in fact is not. Apologies about the noise, -- S. > El 16/03/17 a las 11:59, nospam at curso.re escribi?: >> Hi all, >> >> posting from gmane... I hope this is OK. >> >> I have just tried a system upgrade and HTTPS connection broke when I >> installed ca-certificates-mozilla-3.29.3-2 >> >> Operations like `pacman -Syu` or `git fetch origin` failed due to >> problems with SSL certificates. Restoring >> ca-certificates-mozilla-3.28.1-1 from pacman's cache solved the >> problems. >> >> I have put ca-certificates-mozilla in my IgnorePkg list in >> `/etc/pacman.conf` temporarily so I can upgrade the other packages. >> >> Additionally, I had a problem with the installation of >> `ca-certificates-utils-20170307-1` that failed complaining that >> `/etc/ssl/certs/ca-certificates.crt` already existed (in fact that was >> true and it was a symlink). I had to rename the symlink to be able to >> install the package. >> >> Have I been doing something wrong or are the packages broken? >> >> I hope that you'll find this information useful. >> >> Best, >> >> -- S. >> >> _______________________________________________ >> Dev mailing list >> Dev at lists.parabola.nu >> https://lists.parabola.nu/mailman/listinfo/dev >> From megver83 at openmailbox.org Thu Mar 16 17:21:04 2017 From: megver83 at openmailbox.org (Megver83) Date: Thu, 16 Mar 2017 14:21:04 -0300 Subject: [Dev] New GPG key Message-ID: <865427ef-95c4-8a8e-ebed-6f5c321af34e@openmailbox.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I've created a key for this email, which is the one I plan to use. Please, sign it so I can use it. Thanks! P.S: I'm not sending id_rsa.pub because that's the SSH key, which is already registered, so I send the signed file only to register the new k ey GPG Key: 6DB9C4B4F0D8C0DC432CF6E4227CA7C556B2BA78 -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEErCbv92SojUTThXEpQKKthCTeGvMFAljKyXoACgkQQKKthCTe GvPuIQf9EuxAgIjV3Zx5xb2wmcFl3zUTknEBmsdjnLc7nWb/50BFH7hUZ1znu7nK U8WY8noNKK7l/Qia5w3usy6/MkDRgRcwVCa4shZ2BVCsgRZp2HOvbmCwRKmxOY5t Q7e8GFp0ilr51EdYNRQ4iIwPRexlc3G2QcwSB3HFSnFmjxhfWsAHW1rU9MfF1Bl8 vT4UBmjirzGhDoNEjHhTGhW+nN0vjnIrIzawz/X64OoI3vMRtqPp9LOR2NkW0+LA yOOL+hfvQPRJAifdw0R9kzzpDFyf5oxKgBhFdtqAqNEBDVvwcjrvN4IFwrh7E99q 1ekQzOs/KWWDC2RI/GMikqNnF4n4zA== =lj0U -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: id_rsa.pub.sig Type: application/pgp-signature Size: 310 bytes Desc: not available URL: From nobody at parabola.nu Fri Mar 17 15:19:55 2017 From: nobody at parabola.nu (Parabola Website Notification) Date: Fri, 17 Mar 2017 15:19:55 -0000 Subject: [Dev] Orphan Libre package [linux-libre-grsec] marked out-of-date Message-ID: <20170317151955.756.83425@parabola.nu> invivo at bitmessage.ch wants to notify you that the following packages may be out-of-date: * linux-libre-grsec 1:4.9.14_gnu.r201703121245-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/linux-libre-grsec/ * linux-libre-grsec 1:4.9.14_gnu.r201703121245-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/linux-libre-grsec/ * linux-libre-grsec-docs 1:4.9.14_gnu.r201703121245-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/linux-libre-grsec-docs/ * linux-libre-grsec-docs 1:4.9.14_gnu.r201703121245-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/linux-libre-grsec-docs/ * linux-libre-grsec-headers 1:4.9.14_gnu.r201703121245-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/linux-libre-grsec-headers/ * linux-libre-grsec-headers 1:4.9.14_gnu.r201703121245-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/linux-libre-grsec-headers/ The user provided the following additional text: 4.9.15 patchset is out From elyzabethvonreuenthal at iserlohn-fortress.net Fri Mar 17 15:43:20 2017 From: elyzabethvonreuenthal at iserlohn-fortress.net (Elyzabeth von Reuenthal) Date: Fri, 17 Mar 2017 16:43:20 +0100 Subject: [Dev] Fwd: Re: Article: Chromium's subtle freedom flaws In-Reply-To: References: Message-ID: <12733671.JIlGi94sWX@kongou> As a KDE user and a casual coder, I have been very interested in this article. Have I missed it, or is it still coming soon? > QTWebengine [...] is the entire Chromium browser, which is non-free. No, it is not. To quote the Qt devs: [0] > Yes, we remove a large amount of code from Chromium. Note in particular we > are using the Chromium content API, not the Chromium browser implementation, > which means we are a step lower that most Chromium forks. If QtWebEngine is Chromium, then Thunderbird is Firefox because it also uses Gecko. I earnestly hope this upcoming FSF article provides explicit and irrefutable proof of QtWebEngine being non-free. Proof of hard-coded connections and privacy leaks that I can verify for myself. A list of the non-free plugins and DRM shipped as a part of Qt because none are listed in the documentation. Any evidence of such obviously malicious behaviour that I can report to Qt and work towards fixing. As it stands however, these allegations have been circulating around for a good while, and I have yet to see a single one supported by hard evidence. That rumours continue to propagate despite the assurances of Qt developers to the contrary is making this removal seem like it has more to do with waging the GTK/Qt holy war than it does about freedom. The removal of QtWebEngine has also broken the KDE kontact suite that remains in the repositories. KMail and akregator segfault from missing dependencies. Assistant (Qt documentation viewer, in qt5-tools) will also break soon with the deprecation and removal of QtWebKit. If QtWebEngine has to die, I will accept that, but only if it is sentenced for it's own crimes, and not the crimes of Chromium. [0]: http://lists.qt-project.org/pipermail/qtwebengine/2017-January/ 000408.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From deathsbreed at themusicinnoise.net Fri Mar 17 17:37:45 2017 From: deathsbreed at themusicinnoise.net (=?iso-8859-1?Q?Nicol=E1s_A=2E?= Ortega) Date: Fri, 17 Mar 2017 18:37:45 +0100 Subject: [Dev] Fwd: Re: Article: Chromium's subtle freedom flaws In-Reply-To: <12733671.JIlGi94sWX@kongou> References: <12733671.JIlGi94sWX@kongou> Message-ID: <20170317173745.GA892@athena> I have been following this issue for a long time now, however I haven't been able to respond to any threads due to technical reasons. As I've been following along with these issues I've found very little evidence that Chromium is in-and-of-itself non-free (not including third-party plugins such as Widevine, which also support DRM), much less other software that use Chromium infrastructure (correct me if that was the incorrect term) such as QtWebEngine. What's more, the evidence that is provided tends to be either of no indication that Chromium is non-free (such as the Debian lintian reports that I constantly see floating around [0]) typically refers to JavaScript files that are Free Software, however they are simply minified. Although this may be a reason not to package it, it most definitely is not a reason to call Chromium non-free. If the arguments were saying that Chromium has non-free third parties such as Widevine then that is perfectly valid (so does Firefox[1], however we do not have the Firefox issue, in Parabola at least, since we use IceWeasel/IceCat instead), but third-party plugins such as Widevine can be easily removed (the Debian community has done this[2]). In the Red Hat community these reports were brought up to their maintainer and the maintainer concluded that all of the issues brought up in the prior mentioned lintian reports are in reality free JS but simply minified (which, as I mentioned before, is an issue for packaging but not for freedom necessarily)[3] The second largest complaint of Chromium has been that it leaks information[4][5]. First I would like to make very clear that even if a program lacks security or privacy features that **does not** make it non-free. Therefore, even if there are privacy issues Chromium should not be labelled as non-free, but rather insecure and at the very most spyware (we are well aware that even Free Software can spy on you[6]). However, moving on, I have looked through these issues that were brought up and it seems that they have been slowly fixed with the exception of three of them which were labelled as either `wontfix'[7][8] or still remain open[9]. Upon these grounds Chromium can be judged. If it turns out that there truly are non-free files in Chromium then let it be so, I won't complain, but there needs to be solid evidence. I understand it being removed from the Parabola repositories as a temporary measure until the issue is resolved (as Parabola should not risk there being non-free software in the repository), however to publicly claim that it is non-free without any substantial evidence is something that has been annoying me. I would ask that when these claims are made that they are given with hard evidence as to the matter, and (quite importantly) that when it is announced to the community via news post[10] that it give **all** evidence (or at least the most pertinent evidence) as to why a software is non-free, and if the reasons are something other then it should be stated as such (eg. privacy concerns, temporary removal until freedom issues resolved, etc.). Again, if Chromium indeed has non-free files then I am fine with it being removed, however I would like links with the evidence **and** it should be reported to upstream as an issue (a link to the upstream bug would also be something nice to add to the news post). I'm pretty sure that opening a bug report will be much less work than all of this repackaging of KDE and Qt packages to work without QtWebEngine (which, as mentioned by Elyzabeth, is probably not even non-free even if Chromium were). [0] https://lintian.debian.org/maintainer/pkg-chromium-maint at lists.alioth.debian.org.html#chromium-browser [1] https://support.mozilla.org/t5/Video-audio-and-interactive/Watch-DRM-content-on-Firefox/ta-p/37423 [2] https://packages.debian.org/stretch/chromium-widevine [3] https://bugzilla.redhat.com/show_bug.cgi?id=1418917 [4] https://lists.gnu.org/archive/html/libreplanet-discuss/2017-01/msg00056.html [5] https://trac.torproject.org/projects/tor/wiki/doc/ImportantGoogleChromeBugs [6] https://www.gnu.org/philosophy/ubuntu-spyware.html [7] https://bugs.chromium.org/p/chromium/issues/detail?id=163116 [8] https://bugs.chromium.org/p/chromium/issues/detail?id=80722 [9] https://bugs.chromium.org/p/chromium/issues/detail?id=55058 [10] https://www.parabola.nu/news/chromium-blacklisted-to-respect-your-freedom/ > I earnestly hope this upcoming FSF article provides explicit and irrefutable > proof of QtWebEngine being non-free. Proof of hard-coded connections and > privacy leaks that I can verify for myself. A list of the non-free plugins and > DRM shipped as a part of Qt because none are listed in the documentation. Any > evidence of such obviously malicious behaviour that I can report to Qt and > work towards fixing. -- Nicol?s A. Ortega (Deathsbreed) https://themusicinnoise.net/ http://uk7ewohr7xpjuaca.onion/ Public PGP Key: https://themusicinnoise.net/deathsbreed at themusicinnoise.net_pub.asc http://uk7ewohr7xpjuaca.onion/deathsbreed at themusicinnoise.net_pub.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From alejandrohp at openmailbox.org Fri Mar 17 18:37:53 2017 From: alejandrohp at openmailbox.org (=?UTF-8?Q?Alejandro_Hern=c3=a1ndez_Petermann?=) Date: Fri, 17 Mar 2017 19:37:53 +0100 Subject: [Dev] Fwd: Re: Article: Chromium's subtle freedom flaws In-Reply-To: <20170317173745.GA892@athena> References: <12733671.JIlGi94sWX@kongou> <20170317173745.GA892@athena> Message-ID: As an user, I saw this " It is not just a port of the core HTML/CSS rendering engine, it is the entire Chromium platform. " into https://wiki.qt.io/QtWebEngine and I have to admit that it was pretty clear. ? On 17/03/17 18:37, Nicol?s A. Ortega wrote: > I have been following this issue for a long time now, however I haven't > been able to respond to any threads due to technical reasons. > > As I've been following along with these issues I've found very little > evidence that Chromium is in-and-of-itself non-free (not including > third-party plugins such as Widevine, which also support DRM), much less > other software that use Chromium infrastructure (correct me if that was > the incorrect term) such as QtWebEngine. What's more, the evidence that > is provided tends to be either of no indication that Chromium is > non-free (such as the Debian lintian reports that I constantly see > floating around [0]) typically refers to JavaScript files that are Free > Software, however they are simply minified. Although this may be a > reason not to package it, it most definitely is not a reason to call > Chromium non-free. If the arguments were saying that Chromium has > non-free third parties such as Widevine then that is perfectly valid (so > does Firefox[1], however we do not have the Firefox issue, in Parabola > at least, since we use IceWeasel/IceCat instead), but third-party > plugins such as Widevine can be easily removed (the Debian community has > done this[2]). In the Red Hat community these reports were brought up to > their maintainer and the maintainer concluded that all of the issues > brought up in the prior mentioned lintian reports are in reality free JS > but simply minified (which, as I mentioned before, is an issue for > packaging but not for freedom necessarily)[3] > > The second largest complaint of Chromium has been that it leaks > information[4][5]. First I would like to make very clear that even if a > program lacks security or privacy features that **does not** make it > non-free. Therefore, even if there are privacy issues Chromium should > not be labelled as non-free, but rather insecure and at the very most > spyware (we are well aware that even Free Software can spy on you[6]). > However, moving on, I have looked through these issues that were brought > up and it seems that they have been slowly fixed with the exception of > three of them which were labelled as either `wontfix'[7][8] or still > remain open[9]. Upon these grounds Chromium can be judged. > > If it turns out that there truly are non-free files in Chromium then let > it be so, I won't complain, but there needs to be solid evidence. I > understand it being removed from the Parabola repositories as a > temporary measure until the issue is resolved (as Parabola should not > risk there being non-free software in the repository), however to > publicly claim that it is non-free without any substantial evidence is > something that has been annoying me. I would ask that when these claims > are made that they are given with hard evidence as to the matter, and > (quite importantly) that when it is announced to the community via news > post[10] that it give **all** evidence (or at least the most pertinent > evidence) as to why a software is non-free, and if the reasons are > something other then it should be stated as such (eg. privacy concerns, > temporary removal until freedom issues resolved, etc.). > > Again, if Chromium indeed has non-free files then I am fine with it > being removed, however I would like links with the evidence **and** it > should be reported to upstream as an issue (a link to the upstream bug > would also be something nice to add to the news post). I'm pretty sure > that opening a bug report will be much less work than all of this > repackaging of KDE and Qt packages to work without QtWebEngine (which, > as mentioned by Elyzabeth, is probably not even non-free even if > Chromium were). > > [0] https://lintian.debian.org/maintainer/pkg-chromium-maint at lists.alioth.debian.org.html#chromium-browser > [1] https://support.mozilla.org/t5/Video-audio-and-interactive/Watch-DRM-content-on-Firefox/ta-p/37423 > [2] https://packages.debian.org/stretch/chromium-widevine > [3] https://bugzilla.redhat.com/show_bug.cgi?id=1418917 > [4] https://lists.gnu.org/archive/html/libreplanet-discuss/2017-01/msg00056.html > [5] https://trac.torproject.org/projects/tor/wiki/doc/ImportantGoogleChromeBugs > [6] https://www.gnu.org/philosophy/ubuntu-spyware.html > [7] https://bugs.chromium.org/p/chromium/issues/detail?id=163116 > [8] https://bugs.chromium.org/p/chromium/issues/detail?id=80722 > [9] https://bugs.chromium.org/p/chromium/issues/detail?id=55058 > [10] https://www.parabola.nu/news/chromium-blacklisted-to-respect-your-freedom/ > >> I earnestly hope this upcoming FSF article provides explicit and irrefutable >> proof of QtWebEngine being non-free. Proof of hard-coded connections and >> privacy leaks that I can verify for myself. A list of the non-free plugins and >> DRM shipped as a part of Qt because none are listed in the documentation. Any >> evidence of such obviously malicious behaviour that I can report to Qt and >> work towards fixing. > > > > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev > From isacdaavid at isacdaavid.info Sun Mar 19 04:32:25 2017 From: isacdaavid at isacdaavid.info (Isaac David) Date: Sat, 18 Mar 2017 22:32:25 -0600 Subject: [Dev] Fwd: Re: Article: Chromium's subtle freedom flaws In-Reply-To: <20170317173745.GA892@athena> References: <12733671.JIlGi94sWX@kongou> <20170317173745.GA892@athena> Message-ID: <1489897945.8847.0@plebeian.isacdaavid.info> I think _little_ or _much_ evidence aren't the right quantifiers to approach this issue. a single piece of evidence would suffice, whether for Chromium or any other software. also, we should be cautious not to redefine things in order to spare their faults; that would simply beg the question of whether software foo is guilty of bar or not. along those lines, was the upcoming article even supposed to touch on Qt-WebEngine? I'm also increasingly convinced that future claims would make us an enormous favor if they mentioned the scope of their charges. we have been saying "Chromium" to mean a number of things: (a) the Chromium project source code repository, (b) the idealization of a generic Chromium binary, (c) the versions of Chromium shipped by different distros, (d) some sort of library/dependency derived from (a) used by projects like Qt-WebEngine and Electron. it's perfectly possible for Debian's or Fedora's version of Chromium to be free and dandy while the others are non-free, or any other such combination. as far as I can tell from the couple times I have stared at Debian's version of Chromium, **there are no non-free files there**, nor I could find indication of confusingly-licensed files in the aforementioned lintian report. the minified javascript seems to be free. also, it's my understanding from [0] that the non-free plugins are nowhere to be found in (a). ([1] suggests differently, but I'm suspicious of it). so is it fair to say Chromium is free? I think so **for Debian's**, even if it's just a rubber stamp. I also know Debian is pruning many things from (a) but that doesn't prove anything. should distros like Parabola start shipping Chromium right away? no. As Nicol?s said, there's more to it than mere files and their licenses (I'm putting privacy concerns aside for a moment): recommending non-free software (or silently downloading non-free modules for that matter), missing source code for the minified javascript. in my estimation, accepting any of these caveats would make Parabola go against the Free System Distribution Guidelines.[2] recommending non-free software is the very reason why Firefox isn't shipped in Parabola either. should Parabola remove Qt-WebEngine, Electron, etc? determining what pieces are going into all the different projects isn't trivial for someone who isn't remotely familiar with the Chromium project. I think the next logical step for me is to learn what Debian is stripping away from (a) plus their build flags, check against (a) itself, then try to compare to projects like Qt-WebEngine and infer from there. For now all I can do is go on a case-by-case basis. for instance, I found instructions for installing Widevine in Electron[2]; which I think are enough to warrant blacklisting. Were that issue addressed in a [libre] package, I would try to look for minified javascript leaking into Electron, or any other such problems. I haven't looked into Qt-WebEngine but other devs have. they could add their own rationale to this thread. [0]: http://lists.qt-project.org/pipermail/qtwebengine/2017-January/000408.html [1]: https://raw.githubusercontent.com/electron/electron/787bc8570382e98c4f204abff05b2af122e5a422/docs/tutorial/using-widevine-cdm-plugin.md [2]: https://www.gnu.org/distros/free-system-distribution-guidelines.html -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C From lukeshu at lukeshu.com Wed Mar 22 00:46:20 2017 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Tue, 21 Mar 2017 20:46:20 -0400 Subject: [Dev] [FYI] ~4 minutes of downtime on winston Message-ID: <87var2rvdv.wl-lukeshu@lukeshu.com> FYI, we just now had a bit under 4 minutes of downtime on winston.parabola.nu (www, repo, wiki, git) while it rebooted and ran fsck. Everything looks good now. -- Happy hacking, ~ Luke Shumaker From lukeshu at lukeshu.com Wed Mar 22 16:07:23 2017 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Wed, 22 Mar 2017 12:07:23 -0400 Subject: [Dev] [RFC] Linux kernel ABI versioning Message-ID: <87tw6ls3b8.wl-lukeshu@lukeshu.com> I'd like to propose adding a LINUX-ABI_VERSION pseudo-package that is provided by each of the Linux kernel packages. So then a package that requires at least Linux kernel 4.7 (until recently, -lts was 4.4), can say requires=('LINUX-ABI_VERSION>=4.7') conflicts=('LINUX-ABI_VERSION<4.7') without having to worry about if the user uses linux-libre or linux-libre-lts or linux-libre-knock-lts or whatever. The "conflicts" line is important because it handles the case where the user has both linux-libre and linux-libre-lts installed, but boots to -lts by default; thus breaking the dependency on the newer kernel. This can be accomplished by adding "LINUX-ABI_VERSION=${_pkgver%%-*}" to the provides=() line in the "_package()" function. -- Happy hacking, ~ Luke Shumaker From emulatorman at riseup.net Wed Mar 22 19:55:23 2017 From: emulatorman at riseup.net (=?UTF-8?Q?Andr=c3=a9_Silva?=) Date: Wed, 22 Mar 2017 19:55:23 +0000 Subject: [Dev] [RFC] Linux kernel ABI versioning In-Reply-To: <87tw6ls3b8.wl-lukeshu@lukeshu.com> References: <87tw6ls3b8.wl-lukeshu@lukeshu.com> Message-ID: On 03/22/2017 04:07 PM, Luke Shumaker wrote: > I'd like to propose adding a LINUX-ABI_VERSION pseudo-package that is > provided by each of the Linux kernel packages. > > So then a package that requires at least Linux kernel 4.7 (until > recently, -lts was 4.4), can say > > requires=('LINUX-ABI_VERSION>=4.7') > conflicts=('LINUX-ABI_VERSION<4.7') > > without having to worry about if the user uses linux-libre or > linux-libre-lts or linux-libre-knock-lts or whatever. The "conflicts" > line is important because it handles the case where the user has both > linux-libre and linux-libre-lts installed, but boots to -lts by > default; thus breaking the dependency on the newer kernel. +1 > This can be accomplished by adding "LINUX-ABI_VERSION=${_pkgver%%-*}" > to the provides=() line in the "_package()" function. I will add it in our kernels, thanks for the suggestion. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From emulatorman at riseup.net Fri Mar 24 01:40:21 2017 From: emulatorman at riseup.net (=?UTF-8?Q?Andr=c3=a9_Silva?=) Date: Fri, 24 Mar 2017 01:40:21 +0000 Subject: [Dev] DDNS + parabola.nu sub-domain for our build server Message-ID: Hi guys, Luke .R (Gaming4JC) and me are planning to do + create a build server for Parabola because we need it before November 2017 in order to support 32-bit computers such as the libre ThinkPad x60. Since i have a fast connection (optic fibre) and we would have it managed by our of trusted hackers for privacy/security reasons; g4jc is shipping some important parts (motherboard, cpu, etc) to my address to put it in my home 24 hours connected for our build server. Since i have a dynamic connection, DDNS and a parabola.nu sub-domain is needed to make it possible for us (eg. build.parabola.nu), could someone help me do that for me from dns.he.net? Btw, donations (money, ups, etc) are welcome to help us too! :) Cheers and happy hacking! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From emulatorman at riseup.net Fri Mar 24 01:46:02 2017 From: emulatorman at riseup.net (=?UTF-8?Q?Andr=c3=a9_Silva?=) Date: Fri, 24 Mar 2017 01:46:02 +0000 Subject: [Dev] DDNS + parabola.nu sub-domain for our build server In-Reply-To: References: Message-ID: <82c47761-0175-6440-a76b-4a5f3b28c903@riseup.net> On 03/24/2017 01:40 AM, Andr? Silva wrote: > Hi guys, Luke .R (Gaming4JC) and me are planning to do + create a build > server for Parabola because we need it before November 2017 in order to > support 32-bit computers such as the libre ThinkPad x60. > > Since i have a fast connection (optic fibre) and we would have it > managed by our of trusted hackers for privacy/security reasons; g4jc is > shipping some important parts (motherboard, cpu, etc) to my address to > put it in my home 24 hours connected for our build server. > > Since i have a dynamic connection, DDNS and a parabola.nu sub-domain is > needed to make it possible for us (eg. build.parabola.nu), could someone > help me do that for me from dns.he.net? > > Btw, donations (money, ups, etc) are welcome to help us too! :) > > Cheers and happy hacking! s|our of trusted hackers|by one of our trusted hackers| -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From emulatorman at riseup.net Fri Mar 24 01:50:08 2017 From: emulatorman at riseup.net (=?UTF-8?Q?Andr=c3=a9_Silva?=) Date: Fri, 24 Mar 2017 01:50:08 +0000 Subject: [Dev] DDNS + parabola.nu sub-domain for our build server In-Reply-To: <82c47761-0175-6440-a76b-4a5f3b28c903@riseup.net> References: <82c47761-0175-6440-a76b-4a5f3b28c903@riseup.net> Message-ID: <9933682c-3be4-09e6-33ae-881958df1b63@riseup.net> On 03/24/2017 01:46 AM, Andr? Silva wrote: > On 03/24/2017 01:40 AM, Andr? Silva wrote: >> Hi guys, Luke .R (Gaming4JC) and me are planning to do + create a build >> server for Parabola because we need it before November 2017 in order to >> support 32-bit computers such as the libre ThinkPad x60. >> >> Since i have a fast connection (optic fibre) and we would have it >> managed by our of trusted hackers for privacy/security reasons; g4jc is >> shipping some important parts (motherboard, cpu, etc) to my address to >> put it in my home 24 hours connected for our build server. >> >> Since i have a dynamic connection, DDNS and a parabola.nu sub-domain is >> needed to make it possible for us (eg. build.parabola.nu), could someone >> help me do that for me from dns.he.net? >> >> Btw, donations (money, ups, etc) are welcome to help us too! :) >> >> Cheers and happy hacking! > > s|our of trusted hackers|by one of our trusted hackers| s|our of trusted hackers|one of our trusted hackers| Sorry for my spelling mistakes :P -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From emulatorman at riseup.net Fri Mar 24 07:10:20 2017 From: emulatorman at riseup.net (=?UTF-8?Q?Andr=c3=a9_Silva?=) Date: Fri, 24 Mar 2017 07:10:20 +0000 Subject: [Dev] DDNS + parabola.nu sub-domain for our build server In-Reply-To: <20170324055254.GA16448@parabola-pocket> References: <20170324055254.GA16448@parabola-pocket> Message-ID: On 03/24/2017 05:52 AM, Andreas Grapentin wrote: > > Hi Andr?, > > does this box have to be located at your house, instead of a > run-of-the-mill dedicated root server in some reputable hosting company? > > In my experience, this usually causes more trouble than it is worth, > unless you have very specific requirements a hoster can not offer. Hi Andreas, we need at least a dedicated and specific build server with a motherboard such as ASUS KFSN4-DRE [0] or ASUS KGPE-D16 [1] and CPUs focused 100% for building, not to host a simple server. I don't know if a reputable hosting company as our server hosting sponsor (1984.is [2]) could do that for a cheap cost, gratis or if they can offer those very specific requirements. :( Otherwise, if it is not possible, at least one of our trusted hackers [3][4][5] should handle it "in situ" for security/privacy reasons. [0]:https://libreboot.org/docs/hcl/kfsn4-dre.html [1]:https://libreboot.org/docs/hcl/kgpe-d16.html [2]:https://www.1984.is/ [3]:https://www.parabola.nu/people/hackers/ [4]:https://www.parabola.nu/people/support-staff/ [5]:https://www.parabola.nu/people/artists/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From lovell.joshyyy at gmail.com Fri Mar 24 11:42:24 2017 From: lovell.joshyyy at gmail.com (Josh Branning) Date: Fri, 24 Mar 2017 11:42:24 +0000 Subject: [Dev] DDNS + parabola.nu sub-domain for our build server In-Reply-To: <82c47761-0175-6440-a76b-4a5f3b28c903@riseup.net> References: <82c47761-0175-6440-a76b-4a5f3b28c903@riseup.net> Message-ID: <58D50620.6070909@gmail.com> On 24/03/17 01:46, Andr? Silva wrote: > On 03/24/2017 01:40 AM, Andr? Silva wrote: >> Hi guys, Luke .R (Gaming4JC) and me are planning to do + create a build >> server for Parabola because we need it before November 2017 in order to >> support 32-bit computers such as the libre ThinkPad x60. >> >> Since i have a fast connection (optic fibre) and we would have it >> managed by our of trusted hackers for privacy/security reasons; g4jc is >> shipping some important parts (motherboard, cpu, etc) to my address to >> put it in my home 24 hours connected for our build server. >> >> Since i have a dynamic connection, DDNS and a parabola.nu sub-domain is >> needed to make it possible for us (eg. build.parabola.nu), could someone >> help me do that for me from dns.he.net? >> >> Btw, donations (money, ups, etc) are welcome to help us too! :) >> >> Cheers and happy hacking! > > s|our of trusted hackers|by one of our trusted hackers| For my website, I use http://freedns.afraid.org/ and inadyn as the client. I use a CNAME record to point to the web address. From emulatorman at riseup.net Fri Mar 24 18:21:17 2017 From: emulatorman at riseup.net (=?UTF-8?Q?Andr=c3=a9_Silva?=) Date: Fri, 24 Mar 2017 18:21:17 +0000 Subject: [Dev] DDNS + parabola.nu sub-domain for our build server In-Reply-To: <58D50620.6070909@gmail.com> References: <82c47761-0175-6440-a76b-4a5f3b28c903@riseup.net> <58D50620.6070909@gmail.com> Message-ID: <27b1cbc2-70cf-803f-cb8e-b8e07350e64b@riseup.net> On 03/24/2017 11:42 AM, Josh Branning wrote: > For my website, I use http://freedns.afraid.org/ and inadyn as the > client. I use a CNAME record to point to the web address. Cool, thanks for let me know, i'll test inadyn then :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From eliotime3000 at openmailbox.org Fri Mar 24 21:47:13 2017 From: eliotime3000 at openmailbox.org (Eliot Reyna) Date: Fri, 24 Mar 2017 21:47:13 +0000 Subject: [Dev] Fwd: Re: Article: Chromium's subtle freedom flaws In-Reply-To: <1489897945.8847.0@plebeian.isacdaavid.info> References: <12733671.JIlGi94sWX@kongou> <20170317173745.GA892@athena> <1489897945.8847.0@plebeian.isacdaavid.info> Message-ID: <7f07ee19-2de2-af47-3abf-fdf9bd049879@openmailbox.org> I think that a possible reconsideration of Iridium Browser should be a good idea. Nowdays, this Chromium fork made great efforts to distill the Chromium Browser, separating the free software components from the blur features that Google and/or other contribuitors embedded: https://github.com/iridium-browser/tracker/wiki/Differences-between-Iridium-and-Chromium In case that want to get more details about the progress of Iridium, you can follow this page: https://git.iridiumbrowser.de/cgit.cgi/iridium-browser/tree/?h=patchview I hope that if apply the modifications of Iridium Browser in qt5-webengine, it could be free (if the source code allows it, of course). Eliot. El 19/03/17 a las 04:32, Isaac David escribi?: > I think _little_ or _much_ evidence aren't the right quantifiers to > approach this issue. a single piece of evidence would suffice, whether > for Chromium or any other software. also, we should be cautious not to > redefine things in order to spare their faults; that would simply beg > the question of whether software foo is guilty of bar or not. along > those lines, was the upcoming article even supposed to touch on > Qt-WebEngine? > > I'm also increasingly convinced that future claims would make us an > enormous favor if they mentioned the scope of their charges. we have > been saying "Chromium" to mean a number of things: (a) the Chromium > project source code repository, (b) the idealization of a generic > Chromium binary, (c) the versions of Chromium shipped by different > distros, (d) some sort of library/dependency derived from (a) used by > projects like Qt-WebEngine and Electron. it's perfectly possible for > Debian's or Fedora's version of Chromium to be free and dandy while > the others are non-free, or any other such combination. > > as far as I can tell from the couple times I have stared at Debian's > version of Chromium, **there are no non-free files there**, nor I could > find indication of confusingly-licensed files in the aforementioned > lintian report. the minified javascript seems to be free. also, it's > my understanding from [0] that the non-free plugins are nowhere to be > found in (a). ([1] suggests differently, but I'm suspicious of it). > > so is it fair to say Chromium is free? I think so **for Debian's**, > even if it's just a rubber stamp. I also know Debian is pruning many > things from (a) but that doesn't prove anything. > > should distros like Parabola start shipping Chromium right away? > no. As Nicol?s said, there's more to it than mere files and their > licenses (I'm putting privacy concerns aside for a moment): > recommending non-free software (or silently downloading non-free > modules for that matter), missing source code for the minified > javascript. in my estimation, accepting any of these caveats would make > Parabola go against the Free System Distribution Guidelines.[2] > recommending non-free software is the very reason why Firefox isn't > shipped in Parabola either. > > should Parabola remove Qt-WebEngine, Electron, etc? determining what > pieces are going into all the different projects isn't trivial for > someone who isn't remotely familiar with the Chromium project. I think > the next logical step for me is to learn what Debian is stripping away > from (a) plus their build flags, check against (a) itself, then try to > compare to projects like Qt-WebEngine and infer from there. For now > all I can do is go on a case-by-case basis. for instance, I found > instructions for installing Widevine in Electron[2]; which I think are > enough to warrant blacklisting. Were that issue addressed in a [libre] > package, I would try to look for minified javascript leaking into > Electron, or any other such problems. I haven't looked into Qt-WebEngine > but other devs have. they could add their own rationale to this thread. > > [0]: > http://lists.qt-project.org/pipermail/qtwebengine/2017-January/000408.html > [1]: > https://raw.githubusercontent.com/electron/electron/787bc8570382e98c4f204abff05b2af122e5a422/docs/tutorial/using-widevine-cdm-plugin.md > [2]: https://www.gnu.org/distros/free-system-distribution-guidelines.html > From emulatorman at riseup.net Sat Mar 25 05:29:05 2017 From: emulatorman at riseup.net (=?UTF-8?Q?Andr=c3=a9_Silva?=) Date: Sat, 25 Mar 2017 05:29:05 +0000 Subject: [Dev] DDNS + parabola.nu sub-domain for our build server In-Reply-To: <27b1cbc2-70cf-803f-cb8e-b8e07350e64b@riseup.net> References: <82c47761-0175-6440-a76b-4a5f3b28c903@riseup.net> <58D50620.6070909@gmail.com> <27b1cbc2-70cf-803f-cb8e-b8e07350e64b@riseup.net> Message-ID: <82009ec8-1019-fadc-ec37-4da13cf5f3de@riseup.net> On 03/24/2017 06:21 PM, Andr? Silva wrote: > On 03/24/2017 11:42 AM, Josh Branning wrote: >> For my website, I use http://freedns.afraid.org/ and inadyn as the >> client. I use a CNAME record to point to the web address. > > Cool, thanks for let me know, i'll test inadyn then :) Hey guys, Luke .R let me know that DDNS + sub-domain is not needed for our build server, since we can configure it to upload directly to winston. Using DDNS on a build server may expose my local area network, which isn't good for security. We are still in need of several donations in order to complete this build. 1) An Uninterruptable Power Supply - Preferably 1500VA. e.g. https://www.amazon.com/APC-Back-UPS-Battery-Protector-BR1500G/dp/B003Y24DEU 2) A Power Supply for the Build Server - Preferably 500W e.g. https://www.amazon.com/EVGA-WHITE-Power-Supply-100-W1-0500-KR/dp/B00H33SFJU 3) EEB Form-Factor Compatible Chasis e.g. https://www.newegg.com/Product/Product.aspx?Item=N82E16811854018 4) PC-4200 DDR2 RAM (Preferably 16GB+ for fast building without using swap) Mobo is Compatible with: Memory Type: DDR2 533/667/800 Reg. ECC* Memory Size: 512MB 1GB 2GB 4GB e.g. https://www.amazon.com/Precision-Workstation-Buffered-PC2-4200-Tech/dp/B00VO5KWW6 x2 Stretch goal: 2-4hour extended Backup-UPS addon: https://www.amazon.com/APC-Back-UPS-External-Battery-BR24BPG/dp/B0047E5B90 32GB of ram: https://www.amazon.com/dp/B00VO5J5MY Stretch goal would be powerful server and nice to have, but they are optional and not required to complete the build server. For now, we have motherboard [0], CPU + heatinks/fan + thermal paste and 1TB HDD. [0]:https://www.asus.com/us/Commercial-Servers-Workstations/KFSN4DRESAS/specifications/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From lovell.joshyyy at gmail.com Sat Mar 25 15:11:22 2017 From: lovell.joshyyy at gmail.com (Josh Branning) Date: Sat, 25 Mar 2017 15:11:22 +0000 Subject: [Dev] DDNS + parabola.nu sub-domain for our build server In-Reply-To: <82009ec8-1019-fadc-ec37-4da13cf5f3de@riseup.net> References: <82c47761-0175-6440-a76b-4a5f3b28c903@riseup.net> <58D50620.6070909@gmail.com> <27b1cbc2-70cf-803f-cb8e-b8e07350e64b@riseup.net> <82009ec8-1019-fadc-ec37-4da13cf5f3de@riseup.net> Message-ID: <58D6889A.5060806@gmail.com> On 25/03/17 05:29, Andr? Silva wrote: > On 03/24/2017 06:21 PM, Andr? Silva wrote: >> On 03/24/2017 11:42 AM, Josh Branning wrote: >>> For my website, I use http://freedns.afraid.org/ and inadyn as the >>> client. I use a CNAME record to point to the web address. >> >> Cool, thanks for let me know, i'll test inadyn then :) > > Hey guys, Luke .R let me know that DDNS + sub-domain is not needed for > our build server, since we can configure it to upload directly to > winston. Using DDNS on a build server may expose my local area network, > which isn't good for security. Isn't a problem if you have a good firewall. But I agree with Luke, this is probably a better solution. > > We are still in need of several donations in order to complete this build. > > 1) An Uninterruptable Power Supply > > - Preferably 1500VA. > > e.g. > https://www.amazon.com/APC-Back-UPS-Battery-Protector-BR1500G/dp/B003Y24DEU > > 2) A Power Supply for the Build Server > > - Preferably 500W > > e.g. > https://www.amazon.com/EVGA-WHITE-Power-Supply-100-W1-0500-KR/dp/B00H33SFJU > > 3) EEB Form-Factor Compatible Chasis > > e.g. > https://www.newegg.com/Product/Product.aspx?Item=N82E16811854018 > > 4) PC-4200 DDR2 RAM (Preferably 16GB+ for fast building without using swap) > Mobo is Compatible with: > Memory Type: DDR2 533/667/800 Reg. ECC* > Memory Size: 512MB 1GB 2GB 4GB > > e.g. > https://www.amazon.com/Precision-Workstation-Buffered-PC2-4200-Tech/dp/B00VO5KWW6 > x2 > > Stretch goal: > > 2-4hour extended Backup-UPS addon: > https://www.amazon.com/APC-Back-UPS-External-Battery-BR24BPG/dp/B0047E5B90 > > 32GB of ram: https://www.amazon.com/dp/B00VO5J5MY > > Stretch goal would be powerful server and nice to have, but they are > optional and not required to complete the build server. > > For now, we have motherboard [0], CPU + heatinks/fan + thermal paste and > 1TB HDD. > > [0]:https://www.asus.com/us/Commercial-Servers-Workstations/KFSN4DRESAS/specifications/ I've just donated 100 Euro. Could I please request you also publish the code you use for the build server (and bulk building of packages), when it's ready? It would be useful for offline use, testing reproducible builds and such. Thanks, Josh From isacdaavid at isacdaavid.info Sat Mar 25 18:32:02 2017 From: isacdaavid at isacdaavid.info (Isaac David) Date: Sat, 25 Mar 2017 12:32:02 -0600 Subject: [Dev] DDNS + parabola.nu sub-domain for our build server In-Reply-To: <82009ec8-1019-fadc-ec37-4da13cf5f3de@riseup.net> References: <82c47761-0175-6440-a76b-4a5f3b28c903@riseup.net> <58D50620.6070909@gmail.com> <27b1cbc2-70cf-803f-cb8e-b8e07350e64b@riseup.net> <82009ec8-1019-fadc-ec37-4da13cf5f3de@riseup.net> Message-ID: <1490466722.1539.0@plebeian.isacdaavid.info> Le ven. 24 mars 2017 ? 23:29, Andr? Silva: > Hey guys, Luke .R let me know that DDNS + sub-domain is not needed for > our build server, since we can configure it to upload directly to > winston. Using DDNS on a build server may expose my local area > network, > which isn't good for security. what about starting the builds themselves? will it also read the TODO list from another server? do we want more than ssh on that server? one option would be asking that machine to open a reverse ssh tunnel to winston or proton (I will use proton in this example): ssh -f -N -T -R $BURNER_PROTON_PORT:localhost:$PORT_IN_BUILD_SERVER \ -i $KEYFILE_TO_PROTON -p $USUAL_PORT_TO_PROTON \ $BUILD_USER at proton $BUILD_USER and its corresponding $KEYFILE_TO_PROTON would have to be set up in advance. then any user at proton with the ability to `ssh -p $BURNER_PROTON_PORT localhost` would begin to negotiate a connection to the build server; which, at your option, could use hackers.git and the bulk of the login infraestructure being used in winston to spare the need for more credentials. more generally and conveniently, one would: ssh -p $BURNER_PROTON_PORT -i $KEYFILE_TO_BUILD_SERVER \ $SOME_USER_ON_BUILD_SERVER at proton to jump straight to the build server from anywhere, via proton behind the scenes. of course any form of ssh access to the build server would give a select few a free pass to its LAN. you could try to isolate the server to a second LAN daisy-chained to the main one. it only takes an extra router. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C From acaciosc1 at gmail.com Sat Mar 25 21:55:04 2017 From: acaciosc1 at gmail.com (=?UTF-8?Q?Ac=C3=A1cio_Florentino?=) Date: Sat, 25 Mar 2017 18:55:04 -0300 Subject: [Dev] PGP signature key. Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEySuqcTuNU9PK5j/J5pdHUvlwRFYFAljWwqoACgkQ5pdHUvlw RFam+xAA3DVKHUPWE0adyWQlmPeWFpjPUMIIoa3jonvWcZOUdAhnnR7LmPY7IZoZ rG+5dDDIoF+44ogEmI6BRxjqoBygalQSG0LgTTdAtGkvgw0Wup1faOpRFiOArjaS X9ZCfCJxzwxhIkdUopLXhaC0ahNGb5wvbp+1wJz4MmSpgmYxklrB47HVJzK5pm6G rDizRj2n3FMfA2AgBhvqGrEqmPzd2NtPEz5EE7osZsbelCx38N8PY9D+KrRxmhZg HOaZOcYhbNSLmJKtey69kzqV5MwfiLI0coFOs8zoU52EsOTmdfhaY/KhDCvPLkwg 920Z6kgYp+godhPq2bTIz5bx/obsjJWF0RWZmg0NuI7dIqU+iMk8Ciy7fi/SVhLD zoehSBY2RxbLNFCReLKpUzNKU340lMyndzhtp5kV9aZpC+BXb0ueilk2lFDiGIIb Slbm7KFRqWAXCWOSEIwbqY5t8zM2I5HI5BlA8TEPTYKFOfToss9Wjfcc7Cl3vSDc zihSy4MPLLA0KbjAQYX87XlsI2uZsQUAR0+VGMdc+MNcmTGV2KjFE3LfaxfM2zKU fIcbsvMJOylWTEXLynAVFsPnBJdTowuujs/NYyhjdUmcz4JLh1bwM+6uGkG7tTyr ae6Vj8sSUwHCE8xLY1RZv1Oq7Tt4t7hy2xZEy55Fstw24oh91Nk= =aWcU -----END PGP SIGNATURE----- From g4jc at openmailbox.org Sun Mar 26 00:53:26 2017 From: g4jc at openmailbox.org (Luke) Date: Sun, 26 Mar 2017 00:53:26 +0000 Subject: [Dev] DDNS + parabola.nu sub-domain for our build server In-Reply-To: <1490466722.1539.0@plebeian.isacdaavid.info> References: <82c47761-0175-6440-a76b-4a5f3b28c903@riseup.net> <58D50620.6070909@gmail.com> <27b1cbc2-70cf-803f-cb8e-b8e07350e64b@riseup.net> <82009ec8-1019-fadc-ec37-4da13cf5f3de@riseup.net> <1490466722.1539.0@plebeian.isacdaavid.info> Message-ID: <093c239f-721d-3c2e-9e28-6f8b0528fd83@openmailbox.org> On 03/25/2017 06:32 PM, Isaac David wrote: > > Le ven. 24 mars 2017 ? 23:29, Andr? Silva: >> Hey guys, Luke .R let me know that DDNS + sub-domain is not needed for >> our build server, since we can configure it to upload directly to >> winston. Using DDNS on a build server may expose my local area network, >> which isn't good for security. > > what about starting the builds themselves? will it also read the TODO > list from another server? > > do we want more than ssh on that server? one option would be asking > that machine to open a reverse ssh tunnel to winston or proton (I will > use proton in this example): > > ssh -f -N -T -R $BURNER_PROTON_PORT:localhost:$PORT_IN_BUILD_SERVER \ > -i $KEYFILE_TO_PROTON -p $USUAL_PORT_TO_PROTON \ > $BUILD_USER at proton > > $BUILD_USER and its corresponding $KEYFILE_TO_PROTON would have to be > set up in advance. then any user at proton with the ability to `ssh -p > $BURNER_PROTON_PORT localhost` would begin to negotiate a connection > to the build server; which, at your option, could use hackers.git and > the bulk of the login infraestructure being used in winston to spare > the need for more credentials. more generally and conveniently, one > would: > > ssh -p $BURNER_PROTON_PORT -i $KEYFILE_TO_BUILD_SERVER \ > $SOME_USER_ON_BUILD_SERVER at proton > > to jump straight to the build server from anywhere, via proton behind > the scenes. > > of course any form of ssh access to the build server would give a > select few a free pass to its LAN. you could try to isolate the server > to a second LAN daisy-chained to the main one. it only takes an extra > router. > Reverse SSH is a neat idea. Most professional build servers end up using Jenkins or similar though. We would want to limit who can just randomly login to the build server. Ultimately, I'd like to see some script which allows the user to upload/queue a build and then the server just does it and uploads to proton. Either way I don't like the idea of a build-server publicly facing the internet or running any web services unless it's absolutely necessary. This box needs to be kept tight for security and quality of our binaries. Running it on a VLAN / NAT might be an option as well. Related to automation, there is an interesting ongoing discussion here: https://bbs.archlinux.org/viewtopic.php?id=210341 From lukeshu at lukeshu.com Wed Mar 29 03:47:28 2017 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Tue, 28 Mar 2017 23:47:28 -0400 Subject: [Dev] Someone changed the DNS, and didn't know what they were doing Message-ID: <878tnooib3.wl-lukeshu@lukeshu.com> Hi, I while ago, I said we should move most of the user-facing domains to be CNAMEs. Someone decided to go ahead and do that for all the domains. Without regard for how it might affect SPF. But whatever. But, recently, someone decided to change the bare parabola.nu over to a CNAME. THAT WAS A BAD IDEA. A CNAME cannot coexist with any other records. Fine, mistakes happen. But WRITE DOWN WHAT YOU DO! On the bug tracker or the mailing list. -- Happy hacking, ~ Luke Shumaker From lukeshu at lukeshu.com Wed Mar 29 04:27:21 2017 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Wed, 29 Mar 2017 00:27:21 -0400 Subject: [Dev] Someone changed the DNS, and didn't know what they were doing In-Reply-To: <878tnooib3.wl-lukeshu@lukeshu.com> References: <878tnooib3.wl-lukeshu@lukeshu.com> Message-ID: <874lycoggm.wl-lukeshu@lukeshu.com> I've documented the changes I made in response here: https://labs.parabola.nu/issues/1268 -- Happy hacking, ~ Luke Shumaker From nobody at parabola.nu Wed Mar 29 16:42:08 2017 From: nobody at parabola.nu (Parabola Website Notification) Date: Wed, 29 Mar 2017 16:42:08 -0000 Subject: [Dev] Orphan Libre package [linux-libre] marked out-of-date Message-ID: <20170329164208.1102.66927@proton.parabola.nu> eliotime3000 at openmailbox.org wants to notify you that the following packages may be out-of-date: * linux-libre 4.10.5_gnu-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/linux-libre/ * linux-libre 4.10.5_gnu-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/linux-libre/ * linux-libre-docs 4.10.5_gnu-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/linux-libre-docs/ * linux-libre-docs 4.10.5_gnu-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/linux-libre-docs/ * linux-libre-headers 4.10.5_gnu-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/linux-libre-headers/ * linux-libre-headers 4.10.5_gnu-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/linux-libre-headers/ The user provided the following additional text: Please update the kernel to the 4.10.6 version. Actually, Arch Linux haves the 4.10.6 version of the kernel. From fauno at endefensadelsl.org Thu Mar 30 04:27:12 2017 From: fauno at endefensadelsl.org (fauno) Date: Thu, 30 Mar 2017 01:27:12 -0300 Subject: [Dev] Fwd: Re: Article: Chromium's subtle freedom flaws In-Reply-To: <1489897945.8847.0@plebeian.isacdaavid.info> References: <12733671.JIlGi94sWX@kongou> <20170317173745.GA892@athena> <1489897945.8847.0@plebeian.isacdaavid.info> Message-ID: <87o9wjo0db.fsf@endefensadelsl.org> Isaac David writes: > I think _little_ or _much_ evidence aren't the right quantifiers to > approach this issue. a single piece of evidence would suffice, whether > for Chromium or any other software. also, we should be cautious not to > redefine things in order to spare their faults; that would simply beg > the question of whether software foo is guilty of bar or not. along > those lines, was the upcoming article even supposed to touch on > Qt-WebEngine? i think it's not a question of evidence at all, but of who is going to produce a completely libre source tarball of chromium for parabola and others to build on... sometimes it's just too much work! other times i feel people talks like it isn't on anybody's hands to do it, the "can't someone else do it?" attitude a diy distro shouldn't see often :) (i won't argue if removing chromium from kde packages was more or less time consuming than producing such tarball, since i wasn't involved nor even remotely interested in the freedomness of chromium) -- :D -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 617 bytes Desc: not available URL: From lukeshu at lukeshu.com Fri Mar 31 04:59:16 2017 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Fri, 31 Mar 2017 00:59:16 -0400 Subject: [Dev] libglvnd: OK or not? Message-ID: <87inmqm47v.wl-lukeshu@lukeshu.com> Hi, Parabola recently blacklisted Arch's `libglvnd` for freedom reasons; instead opting to build `mesa-libgl`, which had been disabled in Arch's mesa build when `libglvnd` was introduced. When I say that "Parabola" did that, I mean that one Parabola developer did that, without discussing it with anyone else, or documenting any justification. So I'd like to bring it before the wider community, if only to document reasoning. So, the situation, as I understand it: The technicals: libGL (any implementation) provides a stable ABI across any number of implementations for different graphics devices. If you want to have multiple OpenGL drivers installed at once (perhaps you have multiple graphics cards in one desktop), then you must separate libGL from the driver implementations; libGL becomes a simple wrapper that dispatches to the appropriate driver library based on the GL context. Mesa, a free software OpenGL implementation, provides a libGL implementation does this, sort-of: Mesa includes drivers for many graphics devices, and Mesa's libGL implementation can dispatch to any of them. However, it can *only* dispatch to drivers that are part of Mesa. So you won't be able to have a Mesa-supported card and a non-Mesa-supported card in the same box together. So, someone wrote libglvnd, a libGL implementation that should be able to dispatch to any OpenGL driver, regardless of if the vendor is Mesa or someone else. That is; libglvnd is merely a more general version of Mesa's dispatch (and indeed, borrowed much code from it). libglvnd works by looking for shared libraries with the named "lib${ABI}_${VENDOR}.so" for whichever ABI it is trying to shim out (currently just EGL and GLX, but I think it will eventually in the future I expect GLES et c.), and a wildcard for the ${VENDOR}, discovering vendors at runtime. The politics: libglvnd has been received favorably by at least some of the Mesa team; Matt Turner (one of the Mesa developers), even wrote[0] "Hopefully [libglvnd] will allow us to get rid of our API dispatch code in Mesa." For now, Mesa still contains API dispatch code, so when built with libglvnd support, some calls go through 2 layers of indirection, libglvnd, and then Mesa's own dispatch. [0]: https://bugs.freedesktop.org/show_bug.cgi?id=92877#c0 The objection to libglvnd is the motivation: the "someone" that wrote it is NVIDIA, and the implicit goal is to be able to install the non-free NVIDIA drivers alongside Mesa. Most, if not all, free OpenGL implementations are part of Mesa[1]; so the primary beneficiaries of libglvnd's existence are non-free OpenGL implementations. [1]: If any free OpenGL implementations exist outside of Mesa, they are not packaged by Arch or Parabola. So, is it acceptable for FSDG distros to ship libglvnd instead of Mesa's dispatch library? My opinion is that libglvnd is fine. It includes no references to non-free drivers (it won't complain about missing "nonfree.bin" or anything like the Linux kernel will). I expect that in the future, upstream Mesa will have it has a hard dependency. While its existence is of primary use to those using non-free drivers, its use doesn't infringe on the freedom of those using purely free drivers. -- Happy hacking, ~ Luke Shumaker From emulatorman at riseup.net Fri Mar 31 07:13:23 2017 From: emulatorman at riseup.net (=?UTF-8?Q?Andr=c3=a9_Silva?=) Date: Fri, 31 Mar 2017 07:13:23 +0000 Subject: [Dev] libglvnd: OK or not? In-Reply-To: <87inmqm47v.wl-lukeshu@lukeshu.com> References: <87inmqm47v.wl-lukeshu@lukeshu.com> Message-ID: On 03/31/2017 04:59 AM, Luke Shumaker wrote: > Hi, > > Parabola recently blacklisted Arch's `libglvnd` for freedom reasons; > instead opting to build `mesa-libgl`, which had been disabled in Arch's > mesa build when `libglvnd` was introduced. libglvnd has been blacklisted for technical reasons, not freedom one.[0] When libglvnd has been introduced, coadde and me lost full Direct Rendering Manager support (eg. watch videos in mpv without X with Direct Rendering Manager as backend) with nouveau and intel drivers. Some users like me don't like use X to watch mpv or use any similar application, so i think it should be considered too. > When I say that "Parabola" did that, I mean that one Parabola > developer did that, without discussing it with anyone else, or > documenting any justification. So I'd like to bring it before the > wider community, if only to document reasoning. It sounds a bit rude like "hey guys, coadde is a bad guy, so be careful with him". Please, we should be helpful and respectful to each other. Maybe coadde needs be more communicative, but we could help and suggest him to do it. ;) It he reminds me an article in Parabola that i wrote (based on fauno's articles and another Parabola users) about Adhocracy [1]. I suggest for me (mainly), coadde, you and all community read this article that is very good to avoid future discussions to maintain a good contributing environment. :) > My opinion is that libglvnd is fine. It includes no references to > non-free drivers (it won't complain about missing "nonfree.bin" or > anything like the Linux kernel will). I expect that in the future, > upstream Mesa will have it has a hard dependency. While its existence > is of primary use to those using non-free drivers, its use doesn't > infringe on the freedom of those using purely free drivers. It's my suggestion: a) Keep official Arch's mesa (with libglvnd support) unblacklisted. b) Use coadde's version as alternative one with another name in PCR (eg. mesa-vanilla) Then we could reach a consensus for 2 different point of views, what do you think guys? :) [0]:https://git.parabola.nu/blacklist.git/tree/blacklist.txt#n333 [1]:https://wiki.parabola.nu/Adhocracy#Generations_and_cliques -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From emulatorman at riseup.net Fri Mar 31 08:03:13 2017 From: emulatorman at riseup.net (=?UTF-8?Q?Andr=c3=a9_Silva?=) Date: Fri, 31 Mar 2017 08:03:13 +0000 Subject: [Dev] libglvnd: OK or not? In-Reply-To: <87fuhtnahf.wl-lukeshu@lukeshu.com> References: <87inmqm47v.wl-lukeshu@lukeshu.com> <87fuhtnahf.wl-lukeshu@lukeshu.com> Message-ID: <0dcb8f71-18c0-e0eb-49f4-618f440df650@riseup.net> On 03/31/2017 07:58 AM, Luke Shumaker wrote: > [technical] Breaks support for non-DRI (non-Xorg) DRM in Nouveau +1, i suggest put intel (i915 driver) too, since i had problems in my laptop :( eg. [technical] Breaks support for non-DRI (non-Xorg) DRM in Nouveau and Intel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From emulatorman at riseup.net Fri Mar 31 08:17:48 2017 From: emulatorman at riseup.net (=?UTF-8?Q?Andr=c3=a9_Silva?=) Date: Fri, 31 Mar 2017 08:17:48 +0000 Subject: [Dev] libglvnd: OK or not? In-Reply-To: <87efxdna87.wl-lukeshu@lukeshu.com> References: <87inmqm47v.wl-lukeshu@lukeshu.com> <87fuhtnahf.wl-lukeshu@lukeshu.com> <87efxdna87.wl-lukeshu@lukeshu.com> Message-ID: <07820dca-4807-c2aa-5439-f98a823a5ae3@riseup.net> On 03/31/2017 08:04 AM, Luke Shumaker wrote: > On Fri, 31 Mar 2017 03:13:23 -0400, > Andr? Silva wrote: >> It sounds a bit rude like "hey guys, coadde is a bad guy, so be careful >> with him". Please, we should be helpful and respectful to each other. >> Maybe coadde needs be more communicative, but we could help and suggest >> him to do it. ;) >> >> It he reminds me an article in Parabola that i wrote (based on fauno's >> articles and another Parabola users) about Adhocracy [1]. I suggest for >> me (mainly), coadde, you and all community read this article that is >> very good to avoid future discussions to maintain a good contributing >> environment. :) >> >> [1]:https://wiki.parabola.nu/Adhocracy#Generations_and_cliques > > I'm not trying to say that M?rcio (coadde) is a bad guy. But he does > under-document his actions. And he isn't around to answer questions > about what he did or how he did it; the last time he said anything on > IRC was 4 months ago, and the last time he said anything on the (dev@) > mailing list was 7 months ago (while still making regular > contributions all that time). I appreciate his contributions, but > that's not being part of a community. He's formed a clique with him > and whoever he sees in meatspace (just you?). I want him to be part > of the community! :) Of course, i will motivate him to be part of our community to stay online every time in our IRC channel and dev lists, he could begin with Portuguese/Spanish language (since he has difficulties to write in English), then we could help him to learn English or my bad English. :P >> It's my suggestion: >> >> a) Keep official Arch's mesa (with libglvnd support) unblacklisted. >> b) Use coadde's version as alternative one with another name in PCR (eg. >> mesa-vanilla) > > I like that. Yes, i think it is the best way for everyone :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From emulatorman at riseup.net Fri Mar 31 08:37:31 2017 From: emulatorman at riseup.net (=?UTF-8?Q?Andr=c3=a9_Silva?=) Date: Fri, 31 Mar 2017 08:37:31 +0000 Subject: [Dev] libglvnd: OK or not? In-Reply-To: <07820dca-4807-c2aa-5439-f98a823a5ae3@riseup.net> References: <87inmqm47v.wl-lukeshu@lukeshu.com> <87fuhtnahf.wl-lukeshu@lukeshu.com> <87efxdna87.wl-lukeshu@lukeshu.com> <07820dca-4807-c2aa-5439-f98a823a5ae3@riseup.net> Message-ID: On 03/31/2017 08:17 AM, Andr? Silva wrote: > On 03/31/2017 08:04 AM, Luke Shumaker wrote: >> On Fri, 31 Mar 2017 03:13:23 -0400, >> Andr? Silva wrote: >>> It's my suggestion: >>> >>> a) Keep official Arch's mesa (with libglvnd support) unblacklisted. >>> b) Use coadde's version as alternative one with another name in PCR (eg. >>> mesa-vanilla) >> >> I like that. > > Yes, i think it is the best way for everyone :) I forgot about drirc that contains support (maybe an "implicit" recommendation too) to use non-Free Software.[0] I think it's enough to warrant keeping libre/mesa :( [0]:https://cgit.freedesktop.org/mesa/mesa/plain/src/mesa/drivers/dri/common/drirc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From lukeshu at lukeshu.com Fri Mar 31 09:50:14 2017 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Fri, 31 Mar 2017 05:50:14 -0400 Subject: [Dev] Goals/direction for the coming year Message-ID: <87bmshn5bd.wl-lukeshu@lukeshu.com> Hi guys, I though we should maybe have a conversation about where we want Parabola to go. What goals we have. 1 year is an arbitrary length of time that is long enough to accomplish bigish things, but is still short-ish term. These are things burning a whole in my head - Reproducible builds Last year at LibrePlanet I attended h01ger's talk on reproducible builds. I went in with the attitude that reproducible builds were nice, but that Parabola would never have them. But I came out thinking "Parabola will be reproducible by next LibrePlanet." That didn't happen, because I'm a lazy fuck. This involves doing a better job of tracking exactly what source went in to a package. I have the necessary changes to libretools already planned. As far as enforcing reproducible builds (which would be the *very* last step), I was thinking that it should require the package to be built 3 different times: 2 by build servers, and once by a human. This also means we need to redo db-cleanup to not prune packages mentioned in any current package's `.BUILDINFO`. - Build server This is important for reproducible builds, and for i686 support after November. In addition to all of the normal build server things, I think this should borrow techniques from reproducible-builds.org; use disorderfs and such. It is my understanding that we have one physical server being dedicated for this task. - Code reviews So this one is tricky. It requires community buy-in. I'd love to see "mandatory" code reviews on every code and infrastructure change we can viably do that for. This is NOT primarily to catch mistakes. This is more to make sure that at least 2 humans know about every change that is made. This is about documenting changes, and spreading knowledge through the community of developers. This is not about getting a rubber stamp saying "lgtm". I'm not sure what the tooling around this should look like. - Better bug tracker In the last 2 years, I've opposed all proposals to switch bug trackers. Not because I like our tracker. I was tired of change. Our current tracker is the 4th tracker the project has had in the 6 years I've been with the project. I don't want churn. I don't want "let's try X", only for us to decide X is bad a couple months or a year later. I want a good discussion first. I want this to be a carefully considered decision. Our tracker is bad. Maybe the problem is Redmine, maybe the problem is how we have Redmine configured. It's hard for users to report bugs. It's hard for potential contributors to find simple bugs to get started with. And I don't think any of the current devs like it. I think everyone who has opposed a change have opposed it for the same reason I have. I'm not sure that we want to participate in Google Summer of Code, but today at LibrePlanet, I heard a very compelling argument from Tom Callaway that structuring your stuff such as to be eligible for GSoC, is a good way inviting people to be involved. I was persuaded. Now, I think that our community does a better job of turning users into devs than most other communities. I feel like if you hang out on IRC long enough you eventually become a committer. But many users won't hang out on IRC. A user who doesn't hang out on IRC should be able to make a "drive-by" bug report or patch, and I don't feel like that's happening. -- Happy hacking, ~ Luke Shumaker From emulatorman at riseup.net Fri Mar 31 10:07:47 2017 From: emulatorman at riseup.net (=?UTF-8?Q?Andr=c3=a9_Silva?=) Date: Fri, 31 Mar 2017 10:07:47 +0000 Subject: [Dev] Goals/direction for the coming year In-Reply-To: <87bmshn5bd.wl-lukeshu@lukeshu.com> References: <87bmshn5bd.wl-lukeshu@lukeshu.com> Message-ID: <7d595de3-3ec5-1fec-a222-0e97d77d8a08@riseup.net> On 03/31/2017 09:50 AM, Luke Shumaker wrote: > - Build server > > This is important for reproducible builds, and for i686 support > after November. > > In addition to all of the normal build server things, I think this > should borrow techniques from reproducible-builds.org; use > disorderfs and such. > > It is my understanding that we have one physical server being > dedicated for this task. Luke .R is preparing the needed parts to do our build server to ship here in my home that contains a fast connection by optic fibre for those tasks. Nicolas Reynolds is handling with Parabola donations for Power supply and UPS; anon_nor and me are handling with chassis and shipping costs :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From emulatorman at riseup.net Fri Mar 31 10:11:42 2017 From: emulatorman at riseup.net (=?UTF-8?Q?Andr=c3=a9_Silva?=) Date: Fri, 31 Mar 2017 10:11:42 +0000 Subject: [Dev] Goals/direction for the coming year In-Reply-To: <7d595de3-3ec5-1fec-a222-0e97d77d8a08@riseup.net> References: <87bmshn5bd.wl-lukeshu@lukeshu.com> <7d595de3-3ec5-1fec-a222-0e97d77d8a08@riseup.net> Message-ID: On 03/31/2017 10:07 AM, Andr? Silva wrote: > On 03/31/2017 09:50 AM, Luke Shumaker wrote: >> - Build server >> >> This is important for reproducible builds, and for i686 support >> after November. >> >> In addition to all of the normal build server things, I think this >> should borrow techniques from reproducible-builds.org; use >> disorderfs and such. >> >> It is my understanding that we have one physical server being >> dedicated for this task. > > Luke .R is preparing the needed parts to do our build server to ship > here in my home that contains a fast connection by optic fibre for those > tasks. Nicolas Reynolds is handling with Parabola donations for Power > supply and UPS; anon_nor and me are handling with chassis and shipping > costs :) Jorginho will help me with some fees to transfer money from my Swiss bank account to my resident country with MORE transfer or WU :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From deathsbreed at themusicinnoise.net Fri Mar 31 11:52:23 2017 From: deathsbreed at themusicinnoise.net (=?utf-8?B?Tmljb2zDoXMgQS4=?= Ortega) Date: Fri, 31 Mar 2017 13:52:23 +0200 Subject: [Dev] Goals/direction for the coming year In-Reply-To: <87bmshn5bd.wl-lukeshu@lukeshu.com> References: <87bmshn5bd.wl-lukeshu@lukeshu.com> Message-ID: <20170331115223.GB3319@athena> > - Reproducible builds > > Last year at LibrePlanet I attended h01ger's talk on reproducible > builds. I went in with the attitude that reproducible builds were > nice, but that Parabola would never have them. But I came out > thinking "Parabola will be reproducible by next LibrePlanet." That > didn't happen, because I'm a lazy fuck. > > This involves doing a better job of tracking exactly what source > went in to a package. I have the necessary changes to libretools > already planned. > > As far as enforcing reproducible builds (which would be the *very* > last step), I was thinking that it should require the package to be > built 3 different times: 2 by build servers, and once by a human. > > This also means we need to redo db-cleanup to not prune packages > mentioned in any current package's `.BUILDINFO`. I have heard a lot about reproducible builds as of lately, however I fail to see how effective it would actually be against the issue they are trying to solve, especially considering the extremely low risk of the issue existing to begin with. There is a blog post that I believe does a good job at summarizing the issue[0] (if you can get passed all of the smart-ass remarks). My own criticism of it is that it creates the ironically named "chicken or the egg" paradox[1]. How so? Well, how do we know that our checksum tool isn't backdoored either? In fact, that would be quite a more simple solution. What's more, what about the compiler's compiler? And the compiler of that compiler? Another solution (which wouldn't be as costly) would be to reverse engineer the binary (yes, reverse engineering free software). If all else fails, the only actual solution to the *extremely* unlikely chance that these technologies have been recursively backdoored would be to write a compiler in straight up machine code (nope, not assembly, the assembler could be backdoored). Who knows, maybe your editor is backdoored too, time to deal with the wires directly. I feel that lots of energy and time is being put into reproducible builds, something that are vulnerable to the very issue they claim to solve, when in reality there are much more important issues that can be solved when it comes to security (like maybe using BitMessage instead of e-mail, or at least adding a BitMessage chan since BitMessage is much more anonymous). If I am missing something about reproducible builds that makes them important then I would like to know. But from what I have heard and read it's a rather insubstantial fad. Again, please correct me if I am wrong. [0] https://www.tedunangst.com/flak/post/reproducible-builds-are-a-waste-of-time [1] https://en.wikipedia.org/wiki/Chicken_or_the_egg -- Nicol?s A. Ortega (Deathsbreed) https://themusicinnoise.net/ http://uk7ewohr7xpjuaca.onion/ Public PGP Key: https://themusicinnoise.net/deathsbreed at themusicinnoise.net_pub.asc http://uk7ewohr7xpjuaca.onion/deathsbreed at themusicinnoise.net_pub.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From lovell.joshyyy at gmail.com Fri Mar 31 12:59:37 2017 From: lovell.joshyyy at gmail.com (Josh Branning) Date: Fri, 31 Mar 2017 13:59:37 +0100 Subject: [Dev] Goals/direction for the coming year In-Reply-To: <20170331115223.GB3319@athena> References: <87bmshn5bd.wl-lukeshu@lukeshu.com> <20170331115223.GB3319@athena> Message-ID: <58DE52B9.7070404@gmail.com> Instead of 'we know there are lots of different vulnerabilities with software so we should decide to fix none of them' I feel we should aim for 'we know there are lots of different vulnerabilities with software, so we should try and fix all of them, failing that, we should at least try to fix some of them' And that is why I personally like the idea of reproducible builds, because although it doesn't solve all the problems with software, such as the trusting trust compiler problem, it goes a long way to fixing some of them. Also, if the compilers aren't broken with malware up until now or to begin with, a reproducible work-flow could also go a long way to making sure that the compiler and checking tools are never infected for a system and it's user base for long into the future. From deathsbreed at themusicinnoise.net Fri Mar 31 13:59:13 2017 From: deathsbreed at themusicinnoise.net (=?utf-8?B?Tmljb2zDoXMgQS4=?= Ortega) Date: Fri, 31 Mar 2017 15:59:13 +0200 Subject: [Dev] Goals/direction for the coming year In-Reply-To: <58DE52B9.7070404@gmail.com> References: <58DE52B9.7070404@gmail.com> Message-ID: <20170331135913.GA24045@athena> On Fri, Mar 31, 2017 at 01:59:37PM +0100, Josh Branning wrote: > Instead of > > 'we know there are lots of different vulnerabilities with software so we > should decide to fix none of them' > > I feel we should aim for > > 'we know there are lots of different vulnerabilities with software, so we > should try and fix all of them, failing that, we should at least try to fix > some of them' I am not saying to not fix any of them, I'm saying there are better ways in which we can allocate our resources (namely the time we have). Solving an issue that has low risk but requires quite a bit of time, energy, as well as other resources, seems like a waste to me. With reproducible builds it's a decently large cost for almost no return because of all the flaws it has to begin with. In the end we end up trusting our own compilers, which means it's the same as compiling from source. So why not make it easier to install packages from source? Write a quick script for `abs' and alike? It simply does not seem like a pragmatic decision to me, and although the idea is not bad it needs to be elaborated and thought through more thoroughly on a solution to the problem that they are trying to solve. A problem was found and a half-baked solution was created. Yes, I realize that no security system is perfect and there will always be holes, and that that shouldn't stop us from trying to patch that which we can. However, in this case I view the solution as being too premature and requiring further development so that it can cover a good portion of the holes. -- Nicol?s A. Ortega (Deathsbreed) https://themusicinnoise.net/ http://uk7ewohr7xpjuaca.onion/ Public PGP Key: https://themusicinnoise.net/deathsbreed at themusicinnoise.net_pub.asc http://uk7ewohr7xpjuaca.onion/deathsbreed at themusicinnoise.net_pub.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From fauno at endefensadelsl.org Fri Mar 31 14:03:39 2017 From: fauno at endefensadelsl.org (fauno) Date: Fri, 31 Mar 2017 11:03:39 -0300 Subject: [Dev] Goals/direction for the coming year In-Reply-To: <87bmshn5bd.wl-lukeshu@lukeshu.com> References: <87bmshn5bd.wl-lukeshu@lukeshu.com> Message-ID: <8737dto85g.fsf@endefensadelsl.org> Luke Shumaker writes: > Hi guys, > > I though we should maybe have a conversation about where we want > Parabola to go. What goals we have. > > 1 year is an arbitrary length of time that is long enough to > accomplish bigish things, but is still short-ish term. <3 > These are things burning a whole in my head > > - Reproducible builds [...] > As far as enforcing reproducible builds (which would be the *very* > last step), I was thinking that it should require the package to be > built 3 different times: 2 by build servers, and once by a human. does it involve building three autonomous toolchains from scratch? :P > - Build server it's in the works > - Code reviews > > So this one is tricky. It requires community buy-in. I'd love to > see "mandatory" code reviews on every code and infrastructure > change we can viably do that for. This is NOT primarily to catch > mistakes. This is more to make sure that at least 2 humans know > about every change that is made. > > This is about documenting changes, and spreading knowledge through > the community of developers. This is not about getting a rubber > stamp saying "lgtm". > > I'm not sure what the tooling around this should look like. for infrastructure, at least a way to review changes after the fact. it would be interesting to experiment with public configuration (minus secrets such as session keys, privkeys of all sorts, etc) so /etc gets pushed to our public repos, or something built publicly is pushed to /etc. i'm not keen on puppet/ansible/etc but i do think infrastructure needs to be reproducible, so the next urgent server change doesn't take two weeks of our time (which i don't have much lately as you know so i can't help though i'd like to) > - Better bug tracker > > In the last 2 years, I've opposed all proposals to switch bug > trackers. Not because I like our tracker. I was tired of change. > Our current tracker is the 4th tracker the project has had in the 6 > years I've been with the project. > > I don't want churn. I don't want "let's try X", only for us to > decide X is bad a couple months or a year later. I want a good > discussion first. I want this to be a carefully considered > decision. my fault :( > Our tracker is bad. Maybe the problem is Redmine, maybe the > problem is how we have Redmine configured. It's hard for users to > report bugs. It's hard for potential contributors to find simple > bugs to get started with. And I don't think any of the current > devs like it. I think everyone who has opposed a change have > opposed it for the same reason I have. i'm thinking github's issue tracker is simple and featureful enough to be usable by anyone, but of course we won't use that. gitlab is similar and you can also reply by email, but it's very heavy on resources and, at least on the instance i run for work, fairly unstable. i don't know of any issue tracker similar to git{hub,lab}'s that isn't integrated to a vcs. there's autonomous gitlab servers around, we could ask for an account on 0xacab.org for instance. it's run by riseup.net people. were you thinking of any others? based on what i said, the features i'd like to see on an issue tracker are: * minimalistic interface: just the bare needs, title, summary, comments, tags and status * reply by email: i don't want to have to go look at the issue tracker on a browser, log in, etc if i can receive updates via email and quickly reply from there > I'm not sure that we want to participate in Google Summer of Code, > but today at LibrePlanet, I heard a very compelling argument from > Tom Callaway that structuring your stuff such as to be eligible for > GSoC, is a good way inviting people to be involved. I was > persuaded. what would this entail? > Now, I think that our community does a better job of turning users > into devs than most other communities. I feel like if you hang out > on IRC long enough you eventually become a committer. But many > users won't hang out on IRC. A user who doesn't hang out on IRC > should be able to make a "drive-by" bug report or patch, and I > don't feel like that's happening. this should be an item! - Parabola Hackers for years we haven't had a clear policy on who and how can become a parabola hacker and i think the unofficial documentation[0] isn't really in use[1]. by looking at its history[2] it never was a live document though it tries to resume the common sense: you're welcome to make friends and send some patches! i've been seeing random emails saying "here's my pubkey" on this list, where i just assume someone told these people to do it, but then there's no follow up from another parabola hacker. it makes me think it's written down somewhere and people just tries it out. i'd like to see more drive-by patches, but also as a way to become a parabola hacker and expand more than the tiny set of people doing everyday stuff. i know i burned out a few years back, i'm happily surprised other hackers haven't, but i don't like the overall situation where few people does a lot a things and no one knows exactly who does what or has access to. a policy we stablished on another group i participate is for new people to have a "shadow", a sort of sponsor, one or two hackers that can show you the ropes, are ready to be queried when you're in doubt on how to do something and maybe ask you to do things (delegation is really important!). we also have irregular get togethers to have beers and just chat, but i don't see it happening here :P having said this, i don't think we have to obsess over numbers, booming can be very damaging to a community as great as this :) - Donations i think my term as parabola delegate towards ceata has ended a while ago. do we want to review this? i'm happy to keep doing it, since its the only regular task i can contribute to lately. tiberiu has been really helpful and clear on what ceata can and can't do for us, also dedicating a lot of time to keep our books, reading and replying emails, making recommendations and having parabola in mind :) i don't know if you're monitoring the donations page[3] but we're having a small but steady inflow, some people are even donating regularly! - Wiki is it alive? *** [0]: https://wiki.parabola.nu/How_to_become_a_Parabola_hacker [1]: https://wiki.parabola.nu/Special:WhatLinksHere/How_to_become_a_Parabola_hacker [2]: https://wiki.parabola.nu/index.php?title=How_to_become_a_Parabola_hacker&action=history [3]: https://wiki.parabola.nu/Donations -- :{ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 617 bytes Desc: not available URL: From lovell.joshyyy at gmail.com Fri Mar 31 14:38:59 2017 From: lovell.joshyyy at gmail.com (Josh Branning) Date: Fri, 31 Mar 2017 15:38:59 +0100 Subject: [Dev] Goals/direction for the coming year In-Reply-To: <20170331135913.GA24045@athena> References: <58DE52B9.7070404@gmail.com> <20170331135913.GA24045@athena> Message-ID: <58DE6A03.6050103@gmail.com> > In the end we end up trusting our own compilers, which means it's the > same as compiling from source. So why not make it easier to install > packages from source? Write a quick script for `abs' and alike? In regard to making it easier to install and compile packages from source, I believe this is what the build server aspect is partially addressing. I would like to think that anyone can run the same build server software to compile the same packages for parabola. As I have already stated, this would be useful for offline work, or where there is a bad internet connection. But if anyone can compile the packages using the same software, then this also works towards reproducibility too. As (if I understand correctly) the purpose of reproducible builds is to compare two binaries to see if they are identical, that means users have to be able to compile the packages in the first place. So these two goals are not mutually exclusive, one compliments the other. From deathsbreed at themusicinnoise.net Fri Mar 31 16:38:12 2017 From: deathsbreed at themusicinnoise.net (=?utf-8?B?Tmljb2zDoXMgQS4=?= Ortega) Date: Fri, 31 Mar 2017 18:38:12 +0200 Subject: [Dev] Goals/direction for the coming year In-Reply-To: <8737dto85g.fsf@endefensadelsl.org> References: <87bmshn5bd.wl-lukeshu@lukeshu.com> <8737dto85g.fsf@endefensadelsl.org> Message-ID: <20170331163812.GB24045@athena> > > Our tracker is bad. Maybe the problem is Redmine, maybe the > > problem is how we have Redmine configured. It's hard for users to > > report bugs. It's hard for potential contributors to find simple > > bugs to get started with. And I don't think any of the current > > devs like it. I think everyone who has opposed a change have > > opposed it for the same reason I have. > > i'm thinking github's issue tracker is simple and featureful enough to > be usable by anyone, but of course we won't use that. gitlab is similar > and you can also reply by email, but it's very heavy on resources and, > at least on the instance i run for work, fairly unstable. i don't know > of any issue tracker similar to git{hub,lab}'s that isn't integrated to > a vcs. > > there's autonomous gitlab servers around, we could ask for an account on > 0xacab.org for instance. it's run by riseup.net people. > > were you thinking of any others? based on what i said, the features i'd > like to see on an issue tracker are: > > * minimalistic interface: just the bare needs, title, summary, comments, > tags and status > > * reply by email: i don't want to have to go look at the issue tracker > on a browser, log in, etc if i can receive updates via email and > quickly reply from there > May I suggest (if possible) using Savannah[0]? It's most certainly minimal and I believe the issue tracker can be used without the need of an account (which is always very nice). I am unsure of how easy it is to reply by e-mail. [0] https://savannah.nongnu.org/ > i'd like to see more drive-by patches, but also as a way to become a > parabola hacker and expand more than the tiny set of people doing > everyday stuff. i know i burned out a few years back, i'm happily > surprised other hackers haven't, but i don't like the overall situation > where few people does a lot a things and no one knows exactly who does > what or has access to. > > a policy we stablished on another group i participate is for new people > to have a "shadow", a sort of sponsor, one or two hackers that can show > you the ropes, are ready to be queried when you're in doubt on how to do > something and maybe ask you to do things (delegation is really > important!). we also have irregular get togethers to have beers and > just chat, but i don't see it happening here :P > > having said this, i don't think we have to obsess over numbers, booming > can be very damaging to a community as great as this :) At least in packaging it may be a good idea to add info on what needs to be done in packaging (a sort of to-do list) that is easily found so that people can even randomly contribute if they have spare time. Many people may feel intimidated at the aspect of becoming a hacker of a certain community because it tends to mean active involvement (which not everyone has the time for), but they still have the technical ability to give some quick fixes or contribute random packages. Perhaps a way of contributing new packages to Parabola and have Parabola hackers review the PKGBUILD and software? In fact, that could be a way for someone to contribute as a Parabola hacker, reviewing new packages and other kinds of contributions from random contributors. Just some suggestions :) -- Nicol?s A. Ortega (Deathsbreed) https://themusicinnoise.net/ http://uk7ewohr7xpjuaca.onion/ Public PGP Key: https://themusicinnoise.net/deathsbreed at themusicinnoise.net_pub.asc http://uk7ewohr7xpjuaca.onion/deathsbreed at themusicinnoise.net_pub.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From xihh at riseup.net Fri Mar 31 17:29:39 2017 From: xihh at riseup.net (Joshua Haase) Date: Fri, 31 Mar 2017 11:29:39 -0600 Subject: [Dev] libglvnd: OK or not? In-Reply-To: <0dcb8f71-18c0-e0eb-49f4-618f440df650@riseup.net> References: <87inmqm47v.wl-lukeshu@lukeshu.com> <87fuhtnahf.wl-lukeshu@lukeshu.com> <0dcb8f71-18c0-e0eb-49f4-618f440df650@riseup.net> Message-ID: <87bmsh8id8.fsf@riseup.net> Andr? Silva writes: > On 03/31/2017 07:58 AM, Luke Shumaker wrote: >> [technical] Breaks support for non-DRI (non-Xorg) DRM in Nouveau > > +1, i suggest put intel (i915 driver) too, since i had problems in my > laptop :( > > eg. [technical] Breaks support for non-DRI (non-Xorg) DRM in Nouveau and > Intel I think that we should not use the freedom blacklist to solve technical issues. We should document the problem and the solution (i.e. uninstalling or such). Parabola is a DIY distro. From megver83 at openmailbox.org Fri Mar 31 18:21:00 2017 From: megver83 at openmailbox.org (Megver83) Date: Fri, 31 Mar 2017 15:21:00 -0300 Subject: [Dev] libglvnd: OK or not? In-Reply-To: <87bmsh8id8.fsf@riseup.net> References: <87inmqm47v.wl-lukeshu@lukeshu.com> <87fuhtnahf.wl-lukeshu@lukeshu.com> <0dcb8f71-18c0-e0eb-49f4-618f440df650@riseup.net> <87bmsh8id8.fsf@riseup.net> Message-ID: <0773bb2f-53c0-2dd2-61bf-2c6cbc78f597@openmailbox.org> El 31/03/17 a las 14:29, Joshua Haase escribi?: > Andr? Silva writes: > >> On 03/31/2017 07:58 AM, Luke Shumaker wrote: >>> [technical] Breaks support for non-DRI (non-Xorg) DRM in Nouveau >> >> +1, i suggest put intel (i915 driver) too, since i had problems in my >> laptop :( >> >> eg. [technical] Breaks support for non-DRI (non-Xorg) DRM in Nouveau and >> Intel > > I think that we should not use the freedom blacklist to solve technical > issues. There are many packages that are blacklisted for technical reasons. $ cat blacklist.txt | grep technical | cut -d ":" -f 1 acpi_call acpi_call-lts antlr2 apache-ant apache-ant-doc archboot bbswitch bbswitch-dkms bbswitch-lts bbswitch-lts-dkms beanshell blank capi4hylafax clojure closure-compiler ditaa firefox-theme-adwaita firefox-theme-gnome firefox-theme-gnome-tweak gfxboot glsof handbrake handbrake-cli icedtea-web icedtea-web-doc java-avalon-framework java-batik java-bcel java-commons-io java-commons-logging java-commons-net1 java-hamcrest java-jline java-rhino java-xmlgraphics-commons jedit jmol junit libglvnd luxblend25 maven memtest86+ mesa opencl-mesa vulkan-intel vulkan-radeon libva-mesa-driver mesa-vdpau misdnuser pacman pacman-debug proguard python2-antlr2 rhino-javadoc systemd libsystemd systemd-sysvcompat terminix tp_smapi tp_smapi-lts uboot-a10-olinuxino-lime uboot-a10s-olinuxino-micro uboot-a13-olinuxino uboot-a13-olinuxino-micro uboot-a20-olinuxino-lime uboot-a20-olinuxino-lime2 uboot-a20-olinuxino-micro uboot-beagleboard uboot-beaglebone uboot-boundary uboot-cubieboard uboot-cubieboard2 uboot-cubietruck uboot-chiliboard uboot-cubox uboot-cubox-i uboot-pandaboard uboot-pcduino uboot-pcduino3 uboot-pcduino3-nano uboot-trimslice uboot-udoo-dual uboot-udoo-quad uboot-usbarmory uboot-wandboard uboot-zedboard udev-compat vhba-module vim-minimal vim vim-python3 gvim gvim-python3 vncviewer-jar xalan-java xerces2-java > > We should document the problem and the solution (i.e. uninstalling or > such). Parabola is a DIY distro. > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev > -- SIP: megver83 at sip.linphone.org XMPP: megver83 at diasp.org Kontalk: +56 9 5630 2363 Tox: EF62A7ABCFADD97088FFE925A2F17F0711B49CAC155871B9823A9E9D0D4F9A38077AB0FA3791 GNUSocial: @megver82 at gnusocial.net Diaspora*: David P. (same XMPP ID) From lukeshu at lukeshu.com Fri Mar 31 18:49:48 2017 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Fri, 31 Mar 2017 14:49:48 -0400 Subject: [Dev] Goals/direction for the coming year In-Reply-To: <20170331115223.GB3319@athena> References: <87bmshn5bd.wl-lukeshu@lukeshu.com> <20170331115223.GB3319@athena> Message-ID: <878tnlmgc3.wl-lukeshu@lukeshu.com> On Fri, 31 Mar 2017 07:52:23 -0400, Nicol?s A. Ortega wrote: > > - Reproducible builds > > > > Last year at LibrePlanet I attended h01ger's talk on reproducible > > builds. I went in with the attitude that reproducible builds were > > nice, but that Parabola would never have them. But I came out > > thinking "Parabola will be reproducible by next LibrePlanet." That > > didn't happen, because I'm a lazy fuck. > > > > This involves doing a better job of tracking exactly what source > > went in to a package. I have the necessary changes to libretools > > already planned. > > > > As far as enforcing reproducible builds (which would be the *very* > > last step), I was thinking that it should require the package to be > > built 3 different times: 2 by build servers, and once by a human. > > > > This also means we need to redo db-cleanup to not prune packages > > mentioned in any current package's `.BUILDINFO`. > > I have heard a lot about reproducible builds as of lately, however I > fail to see how effective it would actually be against the issue they > are trying to solve, especially considering the extremely low risk of > the issue existing to begin with. There is a blog post that I believe > does a good job at summarizing the issue[0] (if you can get passed all > of the smart-ass remarks). > > [0] https://www.tedunangst.com/flak/post/reproducible-builds-are-a-waste-of-time You are talking about verifiable builds. Reproducible builds (R-B) are a prominant strategy for implementing verifiable builds, and verifiable builds are certainly a large part of the push for R-B. To borrow from from the post you linked: | Of course, there are uses for reproducible builds besides shutting | down the CIA. When migrating from an old build server to a new one, | it definitely helps to know that the same product is being | built. Builds that can?t be reproduced are more likely to | accidentally incorporate hidden dependencies. A reproducible build | is, by necessity, a deterministic build. Having struggled with | ?random? build failures at various times, I?m all in favor of more | deterministic builds. THOSE REASONS. To borrow some more reasons that I find compelling from the Debian wiki page that Ted linked : | - Be able to generate debug symbols for packages which do not have a | ?debug package?. Oh my God, yes please. | - Ensure packages can be built from source. We've had cases where a nescessary file accidentally gets ommitted from abslibre.git. | - Packages with build profiles must offer the exact same | functionality for all profiles. Reproducible builds could be use | to verify that it is the case. To translate into pacman terms: verify that innocent changes to BUILDENV (ccache, distcc, et c.) actually are innocent. | - Validate cross-builds against native builds. > My own criticism of it is that it creates the ironically named "chicken > or the egg" paradox[1]. This problem is called the "trusting trust" problem (named by Ken Thompson). R-B don't try to address trusting trust. That isn't a problem that is even purported to be solved by R-B. However, trusting trust *was* solved in 2005 by David Wheeler with a solution called "Diverse Double-Compilation" (DDC). R-B are a prerequisite for DDC. -- Happy hacking, ~ Luke Shumaker From lukeshu at lukeshu.com Fri Mar 31 19:44:42 2017 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Fri, 31 Mar 2017 15:44:42 -0400 Subject: [Dev] Goals/direction for the coming year In-Reply-To: <8737dto85g.fsf@endefensadelsl.org> References: <87bmshn5bd.wl-lukeshu@lukeshu.com> <8737dto85g.fsf@endefensadelsl.org> Message-ID: <877f35mdsl.wl-lukeshu@lukeshu.com> On Fri, 31 Mar 2017 10:03:39 -0400, fauno wrote: > > - Reproducible builds > > [...] > > > As far as enforcing reproducible builds (which would be the *very* > > last step), I was thinking that it should require the package to be > > built 3 different times: 2 by build servers, and once by a human. > > does it involve building three autonomous toolchains from scratch? :P Oh, I forgot to say that "3 different times" wouldn't apply to packages imported from Arch. So the packager would build the package locally, the same as they do now. When the upload it, it would kick off jobs on 2 different build servers. The package isn't actually published until the 2 build servers finish. If either of those 2 jobs comes back different than what the packager uploaded, then the packager gets a notification that something is probably wrong with their PKGBUILD. If they both come back the same, then it runs db-update and publishes the package. > > - Code reviews > > > > So this one is tricky. It requires community buy-in. I'd love to > > see "mandatory" code reviews on every code and infrastructure > > change we can viably do that for. This is NOT primarily to catch > > mistakes. This is more to make sure that at least 2 humans know > > about every change that is made. > > > > This is about documenting changes, and spreading knowledge through > > the community of developers. This is not about getting a rubber > > stamp saying "lgtm". > > > > I'm not sure what the tooling around this should look like. > > for infrastructure, at least a way to review changes after the fact. it > would be interesting to experiment with public configuration (minus > secrets such as session keys, privkeys of all sorts, etc) so /etc gets > pushed to our public repos, or something built publicly is pushed to > /etc. Everyone in hackers.git should have access to the git repository of `/etc` on either server (`/etc/.git`). It's readable only by root, but everyone should have sudo (a somewhat terrifying thought). It does include secrets. I'm not opposed to pruning the secrets out of the repo and publishing them, but we'd have to be very careful about no secrets ever accidentally getting added. Somewhere in my .bash_history on one of the servers is a pretty exclude good list of secrets passed to `git diff` commands. > > i'm not keen on puppet/ansible/etc but i do think infrastructure needs > to be reproducible, I thought I agreed with you, then I found Holo . Then I found the documentation lacking, so I read the source to figure out how it worked. Then I found a bunch of edge-cases that I care about, and spent way too many hours filing pull requests :) Anyway, I've slowly been trying to move all of the server configuration in to holo (Ansible has playbooks, Holo has holograms) . I'm not using Holo's native language (`holo-build`) though, I'm using plain bash/PKGBUILDs. I think holo-build is valuable if you are deploying your holograms to DPKG or RPM systems, but I don't think that it buys you much on Pacman. > so the next urgent server change doesn't take two > weeks of our time (which i don't have much lately as you know so i can't > help though i'd like to) > > > - Better bug tracker > > > > In the last 2 years, I've opposed all proposals to switch bug > > trackers. Not because I like our tracker. I was tired of change. > > Our current tracker is the 4th tracker the project has had in the 6 > > years I've been with the project. > > > > I don't want churn. I don't want "let's try X", only for us to > > decide X is bad a couple months or a year later. I want a good > > discussion first. I want this to be a carefully considered > > decision. > > my fault :( > > > Our tracker is bad. Maybe the problem is Redmine, maybe the > > problem is how we have Redmine configured. It's hard for users to > > report bugs. It's hard for potential contributors to find simple > > bugs to get started with. And I don't think any of the current > > devs like it. I think everyone who has opposed a change have > > opposed it for the same reason I have. > > i'm thinking github's issue tracker is simple and featureful enough to > be usable by anyone, but of course we won't use that. gitlab is similar > and you can also reply by email, but it's very heavy on resources and, > at least on the instance i run for work, fairly unstable. i don't know > of any issue tracker similar to git{hub,lab}'s that isn't integrated to > a vcs. If we're talking about GitLab, we should probably also consider Gitea (the community fork of Gogs)? We could start doing work on , but I'm happier leaving it as just a dumb mirror. > > I'm not sure that we want to participate in Google Summer of Code, > > but today at LibrePlanet, I heard a very compelling argument from > > Tom Callaway that structuring your stuff such as to be eligible for > > GSoC, is a good way inviting people to be involved. I was > > persuaded. > > what would this entail? Oh man, he made it sound like there was a whole document, but now that I search for it, the answer is "have already published some free software, and have at least 2 people (1 mentor, 1 administrator)." So I'm going to assume the soft requirements: - Decent mentoring program for new contributors - Task tracker that associates difficulty with tasks, so that a would-be contributor can get an idea of what they could possibly do in X ammount of time. I'll re-watch his talk and see what else he specifically said. > > Now, I think that our community does a better job of turning users > > into devs than most other communities. I feel like if you hang out > > on IRC long enough you eventually become a committer. But many > > users won't hang out on IRC. A user who doesn't hang out on IRC > > should be able to make a "drive-by" bug report or patch, and I > > don't feel like that's happening. > > this should be an item! Oh, phrased another way: I feel like our social resources are great for would-be contributors, but our tech/doc/et c. resources aren't. > - Parabola Hackers > > for years we haven't had a clear policy on who and how can become a > parabola hacker and i think the unofficial documentation[0] isn't really > in use[1]. by looking at its history[2] it never was a live document > though it tries to resume the common sense: you're welcome to make > friends and send some patches! > > i've been seeing random emails saying "here's my pubkey" on this list, > where i just assume someone told these people to do it, but then there's > no follow up from another parabola hacker. it makes me think it's > written down somewhere and people just tries it out. I know we love our Adhocracy, but I do think having tiers or categories of developer-ness would help. Going from zero to suddenly having full credentials, same as one of the long-term core developers, is like drinking from a fire hose. "Welcome to Parabola, I've given you access to push packages, also you're now root on the servers. Hopefully you have good opsec!" "WAIT, WHAT!?" > i'd like to see more drive-by patches, but also as a way to become a > parabola hacker and expand more than the tiny set of people doing > everyday stuff. i know i burned out a few years back, i'm happily > surprised other hackers haven't, but i don't like the overall situation > where few people does a lot a things and no one knows exactly who does > what or has access to. Oh, I definitely burn out too. I sometimes dissapear for months at a time. I make up excuses about being busy with other things, but the truth is that I simply burn out for a while. > a policy we stablished on another group i participate is for new people > to have a "shadow", a sort of sponsor, one or two hackers that can show > you the ropes, are ready to be queried when you're in doubt on how to do > something and maybe ask you to do things (delegation is really > important!). +1 > we also have irregular get togethers to have beers and > just chat, but i don't see it happening here :P You don't need to rub it in! :) > > having said this, i don't think we have to obsess over numbers, booming > can be very damaging to a community as great as this :) > > > - Donations > > i think my term as parabola delegate towards ceata has ended a while > ago. do we want to review this? i'm happy to keep doing it, since its > the only regular task i can contribute to lately. If you're happy to keep doing it, I'm happy for you to keep the position. > - Wiki > > is it alive? I'm *actually 100%* burnt out on the wiki. The previous wiki was bad because it didn't have MediaWiki syntax, and so copying things form ArchWiki was hard. This wiki is bad because it doesn't have plain files; everything is locked away in MySQL. Merging from ArchWiki is easier, but tedious. Now newer hackers that have only been around for this wiki are advocating to a return to a files-based non-MediaWiki. Both are bad. For a bit I was working on fork of MediaWiki that uses git as the backend instead of SQL. From fauno at endefensadelsl.org Fri Mar 31 20:38:28 2017 From: fauno at endefensadelsl.org (fauno) Date: Fri, 31 Mar 2017 17:38:28 -0300 Subject: [Dev] Goals/direction for the coming year In-Reply-To: <877f35mdsl.wl-lukeshu@lukeshu.com> References: <87bmshn5bd.wl-lukeshu@lukeshu.com> <8737dto85g.fsf@endefensadelsl.org> <877f35mdsl.wl-lukeshu@lukeshu.com> Message-ID: <87wpb5mbaz.fsf@endefensadelsl.org> Luke Shumaker writes: > So the packager would build the package locally, the same as they do > now. When the upload it, it would kick off jobs on 2 different build > servers. The package isn't actually published until the 2 build > servers finish. If either of those 2 jobs comes back different than > what the packager uploaded, then the packager gets a notification that > something is probably wrong with their PKGBUILD. If they both come > back the same, then it runs db-update and publishes the package. do we have the software for this? > Everyone in hackers.git should have access to the git repository of > `/etc` on either server (`/etc/.git`). It's readable only by root, > but everyone should have sudo (a somewhat terrifying thought). hehe > It does include secrets. I'm not opposed to pruning the secrets out > of the repo and publishing them, but we'd have to be very careful > about no secrets ever accidentally getting added. Somewhere in my > .bash_history on one of the servers is a pretty exclude good list of > secrets passed to `git diff` commands. or a .gitignore maybe? i just thought of a pre-commit hook that inspects commited files to check they don't have pem style headers. it would've to be more smart to find actual password thought. >> i'm not keen on puppet/ansible/etc but i do think infrastructure needs >> to be reproducible, > > I thought I agreed with you, then I found Holo . Then I > found the documentation lacking, so I read the source to figure out > how it worked. Then I found a bunch of edge-cases that I care about, > and spent way too many hours filing pull requests :) > > Anyway, I've slowly been trying to move all of the server > configuration in to holo (Ansible has playbooks, Holo has holograms) > . I'm not using Holo's > native language (`holo-build`) though, I'm using plain > bash/PKGBUILDs. I think holo-build is valuable if you are deploying > your holograms to DPKG or RPM systems, but I don't think that it buys > you much on Pacman. ha! i've been looking at holo for another project, but i dislike toml syntax and i also saw it recommends to put the contents of files inside the package description (instead of having it on a directory and just `install --mode` it) i've been rolling out my own set of makefiles, with great success and some drawbacks, but i won't push it here (i haven't published them either). > If we're talking about GitLab, we should probably also consider Gitea > (the community fork of Gogs)? why was it forked? gogs/gitea could be useful too, though i don't have experience with any of them (i was waiting for the pull request feature and they i waited too long) > I know we love our Adhocracy, but I do think having tiers or > categories of developer-ness would help. Going from zero to suddenly > having full credentials, same as one of the long-term core developers, > is like drinking from a fire hose. "Welcome to Parabola, I've given > you access to push packages, also you're now root on the > servers. Hopefully you have good opsec!" "WAIT, WHAT!?" hahaha >> a policy we stablished on another group i participate is for new people >> to have a "shadow", a sort of sponsor, one or two hackers that can show >> you the ropes, are ready to be queried when you're in doubt on how to do >> something and maybe ask you to do things (delegation is really >> important!). > > +1 i can draft something if others see this useful :) >> we also have irregular get togethers to have beers and >> just chat, but i don't see it happening here :P > > You don't need to rub it in! :) SOON >> - Wiki >> >> is it alive? > > I'm *actually 100%* burnt out on the wiki. > > The previous wiki was bad because it didn't have MediaWiki syntax, and > so copying things form ArchWiki was hard. > > This wiki is bad because it doesn't have plain files; everything is > locked away in MySQL. Merging from ArchWiki is easier, but tedious. > > Now newer hackers that have only been around for this wiki are > advocating to a return to a files-based non-MediaWiki. > > Both are bad. > > For a bit I was working on fork of MediaWiki that uses git as the > backend instead of SQL. we've been over this on another project (i'm on too many projects) and in the end, when we installed mediawiki it turned to be the most used wiki of all. the syntax is horrible, but you can write things on markdown and convert from and back to mediawiki using pandoc. i'd like to see the Translation plugin installed, which helps translators keep up to date with changes in articles. and people can notice when the article on a language is outdated. i don't know how much work would it be to convert the current translation system to it though. it would be interesting to be able to pull and prune articles from archwiki, so you don't have to default to it (i almost never use parabola wiki). also, it seems every attempt to make mediawiki distributed is dead (or as dormant as cthulhu). there're some special arguments to access the article on mediawiki syntax or rendered but without the site theme surrounding it which i think could be useful to build a tool that can pull and push between wikis. such tool could also present diff'ing tools for humans to solve conflicts :) there're also plugins like mediawikifs or vim-mediawiki (iirc) that allow you to edit a mw instance as regular files. -- .o?) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 617 bytes Desc: not available URL: From lukeshu at lukeshu.com Fri Mar 31 21:28:46 2017 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Fri, 31 Mar 2017 17:28:46 -0400 Subject: [Dev] Goals/direction for the coming year In-Reply-To: <87wpb5mbaz.fsf@endefensadelsl.org> References: <87bmshn5bd.wl-lukeshu@lukeshu.com> <8737dto85g.fsf@endefensadelsl.org> <877f35mdsl.wl-lukeshu@lukeshu.com> <87wpb5mbaz.fsf@endefensadelsl.org> Message-ID: <8737dtm8z5.wl-lukeshu@lukeshu.com> On Fri, 31 Mar 2017 16:38:28 -0400, fauno wrote: > Luke Shumaker writes: > > So the packager would build the package locally, the same as they do > > now. When the upload it, it would kick off jobs on 2 different build > > servers. The package isn't actually published until the 2 build > > servers finish. If either of those 2 jobs comes back different than > > what the packager uploaded, then the packager gets a notification that > > something is probably wrong with their PKGBUILD. If they both come > > back the same, then it runs db-update and publishes the package. > > do we have the software for this? Not yet :) But if we're building some custom build server software anyway... > > It does include secrets. I'm not opposed to pruning the secrets out > > of the repo and publishing them, but we'd have to be very careful > > about no secrets ever accidentally getting added. Somewhere in my > > .bash_history on one of the servers is a pretty exclude good list of > > secrets passed to `git diff` commands. > > or a .gitignore maybe? i just thought of a pre-commit hook that > inspects commited files to check they don't have pem style headers. it > would've to be more smart to find actual password thought. Yeah, .gitignore is fine, we'd just have to prune the existing commits first. I do want to track the secrets though; so perhaps have a separate (private) repository for secrets? We used to do that with SSL certs, but that was just to sync them between servers. > >> i'm not keen on puppet/ansible/etc but i do think infrastructure needs > >> to be reproducible, > > > > I thought I agreed with you, then I found Holo . Then I > > found the documentation lacking, so I read the source to figure out > > how it worked. Then I found a bunch of edge-cases that I care about, > > and spent way too many hours filing pull requests :) > > > > Anyway, I've slowly been trying to move all of the server > > configuration in to holo (Ansible has playbooks, Holo has holograms) > > . I'm not using Holo's > > native language (`holo-build`) though, I'm using plain > > bash/PKGBUILDs. I think holo-build is valuable if you are deploying > > your holograms to DPKG or RPM systems, but I don't think that it buys > > you much on Pacman. > > ha! i've been looking at holo for another project, but i dislike toml > syntax and i also saw it recommends to put the contents of files inside > the package description (instead of having it on a directory and just > `install --mode` it) > > i've been rolling out my own set of makefiles, with great success and > some drawbacks, but i won't push it here (i haven't published them > either). > > > If we're talking about GitLab, we should probably also consider Gitea > > (the community fork of Gogs)? > > why was it forked? gogs/gitea could be useful too, though i don't have > experience with any of them (i was waiting for the pull request feature > and they i waited too long) The Gogs developers don't really accept pull requests or contributions. The bus-factor of Gogs is roughly 1. Gitea exists to fork the stewardship and community (well, fork the stewardship in order to enable a community to form), more than it does to fork the code itself. > >> a policy we stablished on another group i participate is for new people > >> to have a "shadow", a sort of sponsor, one or two hackers that can show > >> you the ropes, are ready to be queried when you're in doubt on how to do > >> something and maybe ask you to do things (delegation is really > >> important!). > > > > +1 > > i can draft something if others see this useful :) If you have an idea of what it needs to include, that would be good. > >> - Wiki > >> > >> is it alive? > > > > I'm *actually 100%* burnt out on the wiki. > > > > The previous wiki was bad because it didn't have MediaWiki syntax, and > > so copying things form ArchWiki was hard. > > > > This wiki is bad because it doesn't have plain files; everything is > > locked away in MySQL. Merging from ArchWiki is easier, but tedious. > > > > Now newer hackers that have only been around for this wiki are > > advocating to a return to a files-based non-MediaWiki. > > > > Both are bad. > > > > For a bit I was working on fork of MediaWiki that uses git as the > > backend instead of SQL. > > we've been over this on another project (i'm on too many projects) and > in the end, when we installed mediawiki it turned to be the most used > wiki of all. > > the syntax is horrible, but you can write things on markdown and convert > from and back to mediawiki using pandoc. pandoc is best way of writing mediawiki > i'd like to see the Translation plugin installed, which helps > translators keep up to date with changes in articles. and people can > notice when the article on a language is outdated. i don't know how > much work would it be to convert the current translation system to it > though. Me either. I used to be really invovled with the wiki, but like I said, I've burnt out. > it would be interesting to be able to pull and prune articles from > archwiki, so you don't have to default to it (i almost never use > parabola wiki). also, it seems every attempt to make mediawiki > distributed is dead (or as dormant as cthulhu). Oh, I was also working on a better git-mediawiki-remote. I tried using plain git-mediawiki-remote, but there ended up being problems with that. Being able to handleit as a git merge would be really cool. > there're some special arguments to access the article on mediawiki > syntax or rendered but without the site theme surrounding it which i > think could be useful to build a tool that can pull and push between > wikis. For basic pages, that works well enough, but once you start using transclusion and templates, it starts to be troublesome. > such tool could also present diff'ing tools for humans to solve > conflicts :) > > there're also plugins like mediawikifs or vim-mediawiki (iirc) that > allow you to edit a mw instance as regular files. -- Happy hacking, ~ Luke Shumaker From g4jc at openmailbox.org Fri Mar 31 23:16:35 2017 From: g4jc at openmailbox.org (Luke) Date: Fri, 31 Mar 2017 23:16:35 +0000 Subject: [Dev] Goals/direction for the coming year In-Reply-To: <87bmshn5bd.wl-lukeshu@lukeshu.com> References: <87bmshn5bd.wl-lukeshu@lukeshu.com> Message-ID: <818b4812-626e-110c-722c-7ce090eb78c0@openmailbox.org> On 03/31/2017 09:50 AM, Luke Shumaker wrote: > Hi guys, > > I though we should maybe have a conversation about where we want > Parabola to go. What goals we have. > > 1 year is an arbitrary length of time that is long enough to > accomplish bigish things, but is still short-ish term. > > These are things burning a whole in my head > > - Reproducible builds > +1. For a slew of reasons. As you already mentioned, there are packages with missing dependencies. However, there are also packages from Arch where the maintainer is a non-responsive shill and admits to not having the current PKGBUILD match the current build, packages that only download from HTTP and have 'SKIP' as the hash check in core, etc. It's a complete disaster. I'd like to think that once we get a build server we can actually try to see if it is possible to get a working/functional system using packages built entirely by ourselves. This will involve compiling the compiler as well, something I tried to do and gave up when I figured out all the dependencies have to be built essentially at the same time, which means trusting untrust from upstream, not just trusting trust. > - Build server > > This is important for reproducible builds, and for i686 support > after November. > > In addition to all of the normal build server things, I think this > should borrow techniques from reproducible-builds.org; use > disorderfs and such. > > It is my understanding that we have one physical server being > dedicated for this task. Hardware portion of the build server is in the works, but we really need well-documented software / automation tools to do this. If anyone wants to take this seriously and work full-time I think we should be able to use Parabola funds to make it happen, this needs to be professional work if we're going to maintain a quality build server. > > - Code reviews > > So this one is tricky. It requires community buy-in. I'd love to > see "mandatory" code reviews on every code and infrastructure > change we can viably do that for. This is NOT primarily to catch > mistakes. This is more to make sure that at least 2 humans know > about every change that is made. +1. We need more eyes on the code. I don't like blindly trusting new developers, and I don't like most of the PKGBUILDs from upstream either. I've seen some pretty undocumented hackish stuff. Thusfar most (all?) of the core team we have is solid and has had other devs vouge for them, but if we're going to grow this needs to be made a priority. We also don't need to be giving newbie weekend warriors access to sudo, I was under the impression this was not happening. =-O > > - Better bug tracker > I'm a big fan of GitLab and Bugzilla, both are fairly simple to figure out and work well in self-hosted environments also. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From nobody at parabola.nu Fri Mar 31 23:58:54 2017 From: nobody at parabola.nu (Parabola Website Notification) Date: Fri, 31 Mar 2017 23:58:54 -0000 Subject: [Dev] Orphan Libre package [epiphany] marked out-of-date Message-ID: <20170331235854.1102.12550@proton.parabola.nu> jm.100best at gmail.com wants to notify you that the following packages may be out-of-date: * epiphany 3.22.4-1.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/epiphany/ * epiphany 3.22.6-1.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/epiphany/ * epiphany 3.22.6-1.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/epiphany/ The user provided the following additional text: 3.24 has been released. Awesome :)