From nobody Thu Mar 28 17:59:51 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mail.wilcox-tech.com (mail.wilcox-tech.com [45.32.83.9]) by lists.alpinelinux.org (Postfix) with ESMTP id 367AD5C4BBF for ; Mon, 24 Jul 2017 11:58:02 +0000 (GMT) Received: (qmail 20970 invoked from network); 24 Jul 2017 11:57:53 -0000 Received: from ip68-13-242-69.ok.ok.cox.net (HELO ?10.1.1.57?) (awilcox@wilcox-tech.com@68.13.242.69) by mail.wilcox-tech.com with ESMTPA; 24 Jul 2017 11:57:53 -0000 To: alpine-devel@lists.alpinelinux.org From: "A. Wilcox" Subject: [alpine-devel] =?UTF-8?Q?Ad=c3=a9lie_on_Alpine=2c_two_months_later?= X-Enigmail-Draft-Status: N1110 Organization: =?UTF-8?Q?Ad=c3=a9lie_Linux?= Message-ID: <5975E0C0.1030008@adelielinux.org> Date: Mon, 24 Jul 2017 06:57:52 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCkhpIHRo ZXJlIEFscGluaXN0cywNCg0KVGhpcyBpcyBhIHNvcnQgb2Ygc3RhdHVzIHVwZGF0ZSBhbmQgd2lz aCBsaXN0IGFmdGVyIG5lYXIgdHdvIG1vbnRocyBvZg0KYXR0ZW1wdGluZyB0byBiYXNlIEFkw6ls aWUgb24gQWxwaW5lIExpbnV4Lg0KDQoxLiAgc2NyaXB0cy9ib290c3RyYXAuc2ggY2Fubm90ICJm YWtlIiBjcm9zcy4gIFNpbmNlIEFkw6lsaWUgdXNlcyBhDQpzbGlnaHRseSBkaWZmZXJlbnQgR0ND IGNvbmZpZ3VyYXRpb24gZnJvbSBBbHBpbmUsIEkgYXR0ZW1wdGVkIHRvIHJ1bg0KYm9vdHN0cmFw LnNoIG9uIHg4Nl82NCwgZnJvbSBteSB4ODZfNjQgc3lzdGVtOg0KDQoNCkVSUk9SOiB1bnNhdGlz ZmlhYmxlIGNvbnN0cmFpbnRzOg0KICBnY2MtNi4zLjAtcjQ6DQogICAgY29uZmxpY3RzOiBnY2Mt eDg2XzY0LTYuMy4wLXI0W3NvOmxpYmNpbGtydHMuc28uNT01LjAuMF0NCiAgICBzYXRpc2ZpZXM6 IHdvcmxkW2djY10gZysrLTYuMy4wLXI0W2djYz02LjMuMC1yNF0NCmdjYy1nbmF0LTYuMy4wLXI0 W2djYz02LjMuMC1yNF0gYnVpbGQtYmFzZS0wLjUtcjBbZ2NjXQ0KICBnY2MteDg2XzY0LTYuMy4w LXI0Og0KICAgIGNvbmZsaWN0czogZ2NjLTYuMy4wLXI0W3NvOmxpYmNpbGtydHMuc28uNT01LjAu MF0NCiAgICBzYXRpc2ZpZXM6IHdvcmxkW2djYy14ODZfNjRdDQoNCg0KU2luY2Ugd2UgaGF2ZSBv dGhlciBDUFUgdHlwZXMgdGhhdCB3ZSB3aXNoIHRvIHN1cHBvcnQsIEkgd2VudCBhaGVhZA0KYW5k IHNpbXBseSBib290c3RyYXBwZWQgUG93ZXJQQy4gIFRoaXMgaXMgdGhlcmVmb3JlIG5vdCBhIGZh dGFsIGVycm9yLA0KYnV0IG9uZSB0aGF0IGhhcyBjYXVzZWQgYSBsb3Qgb2YgdGltZSB0byBidXJu OyBhIGxvdCBvZiBwYWNrYWdlcyBhcmUNCmp1c3Qgbm90IHJlYWR5IGZvciBwcGMgYW5kIG5lZWRl ZCBzb21lIGZpeGluZy4gIFNwZWNpZmljYWxseSwgR0NDIGFuZA0KT3BlblNTTCBuZWVkZWQgdG8g YmUgbWFkZSBhd2FyZSBvZiB0aGUgUG93ZXJQQyBhcmNoaXRlY3R1cmUuDQoNCg0KMi4gVGhlIHZp cnR1YWwgc3lzdGVtIGlzIHBhdGhldGljLiAgT25lIG9mIHRoZSB2ZXJ5IGNvcmUgdGVuZXRzIG9m DQpBZMOpbGllIGlzIGdpdmluZyB0aGUgdXNlciBwb3dlciB0aHJvdWdoIGNob2ljZS4gIFRoYXQg Y2hvaWNlIGlzIGFsbW9zdA0KaW1wb3NzaWJsZSB0byBwcm92aWRlIHVzaW5nIHRoZSBjdXJyZW50 IGFidWlsZC9hcGsgZnJhbWV3b3JrLiAgSSBrZWVwDQpoZWFyaW5nIG9mIGEgRGViaWFuLXN0eWxl IGFsdGVybmF0aXZlcyBzeXN0ZW0sIGFuZCBzdXBwb3NlZGx5IGl0IHdhcw0Kc3BlY2lmaWVkIHNv bWV3aGVyZSwgYnV0IEkgY2Fubm90IGZpbmQgdGhlIHNwZWNpZmljYXRpb24gbm9yIGFuDQppbXBs ZW1lbnRhdGlvbi4gIElmIEkgY291bGQgcmVhZCB0aGUgc3BlY2lmaWNhdGlvbiBJIHdvdWxkIGJl IGhpZ2hseQ0KbW90aXZhdGVkIHRvIHdyaXRlIGFuIGltcGxlbWVudGF0aW9uLg0KDQpSZWQgSGF0 IGhhcyBgYWx0ZXJuYXRpdmVzYCwgRGViaWFuIGhhcyBgdXBkYXRlLWFsdGVybmF0aXZlc2AsIGFu ZA0KR2VudG9vIGhhcyBgZXNlbGVjdGAuICBUaGUgQWxwaW5lIHN5c3RlbSBkZXNwZXJhdGVseSBu ZWVkcyBzb21ldGhpbmcNCmxpa2UgdGhpcyBhbmQgSSB3b3VsZCBsb3ZlIHRvIGNvbnRyaWJ1dGUg dG8gc3VjaC4NCg0KQ29uc2lkZXIgYSBmZXcgZGlmZmVyZW50IHVzZSBjYXNlczoNCg0KbXRhOiBh bnkgcGFja2FnZSB0aGF0IG5lZWRzIGBzZW5kbWFpbGAgaGFzIHRvIGVpdGhlciBoYXJkLWRlcGVu ZCBvbg0KcG9zdGZpeCwgb3IgZGlzYWJsZSBtYWlsIHNlcnZpY2VzLiAgVGhpcyBpcyB1bmFjY2Vw dGFibGUgaW4gbXkNCm9waW5pb24uICBPdGhlciBkaXN0cm9zIGxldCB5b3Ugc2VsZWN0IHdoYXQg cGFja2FnZSB5b3Ugd2FudCB0bw0KcHJvdmlkZSBgc2VuZG1haWxgLg0KDQphd2s6IG1hd2sgdnMg Z2F3ayB2cyBidXN5Ym94IGF3ay4gIEFsbCBoYXZlIGJlbmVmaXRzIGFuZCBkcmF3YmFja3MgYW5k DQp0aGUgdXNlciBzaG91bGQgYmUgYWJsZSB0byBjaG9vc2Ugd2hpY2ggcHJvdmlkZXMgL3Vzci9i aW4vYXdrLg0KDQpzaGVsbDogL2Jpbi9zaCBhcyBidXN5Ym94IGlzIG9mIGNvdXJzZSBkZWZhdWx0 LCBidXQgc29tZSB1c2VycyBtYXkNCndhbnQgYmFzaCBvciBhbm90aGVyIHNoZWxsLiAgSSBkb24n dCBzZWUgYW55IHJlYXNvbiB0aGF0IGNhbid0IGJlDQpzdXBwb3J0ZWQuDQoNCnZpOiBidXN5Ym94 LCB2aW0sIG5lb3ZpbSwgZWx2aXMsIC4uLiAgVGhlcmUgYXJlIGFsbW9zdCBhIGRvemVuDQpwcm92 aWRlcnMgb2YgYHZpYCBpbiBEZWJpYW4gYW5kIG1vcmUgdGhhbiBhIGRvemVuIG9uIEdlbnRvby4g IEkNCmJlbGlldmUgQWxwaW5lIGl0c2VsZiBwYWNrYWdlcyBmb3VyIG9mIHRoZW0uDQoNCkkgc3Rh cnRlZCB0byB0cnkgYW5kIG1ha2UgJ3Y6bXRhJyBidXQgSSdtIHZlcnkgY29uY2VybmVkIGFib3V0 DQpkaXZlcmdpbmcgc28gbXVjaCBmcm9tIHRoZSBBbHBpbmUgYXBvcnRzIHRyZWUuICBBbHNvLCBh cGsgZG9lc24ndA0Kc3VwcG9ydCBhbiBhdXRvbWF0aWMgY2hvaWNlIGZvciBhIHZpcnR1YWwgaWYg dGhlIHVzZXIgaGFzbid0IGFscmVhZHkNCmluc3RhbGxlZCBvbmUgKHNvbWV0aGluZyBsaWtlIHJl cGxhY2VzX3ByaW9yaXR5IGJ1dCBmb3IgdmlydHVhbHMgd291bGQNCmJlIGdvb2QgaGVyZSBpbW8p LiAgVGhhdCBtZWFucyB0aGF0IHdoZW4gSSAqZG8qIG1hbmFnZSB0byBnZXQgcGFja2FnZXMNCnRv IGRlcGVuZCBvbiB2Om10YSwgdGhlIHVzZXIgbm93IGhhcyB0byByZWFkIHRocm91Z2ggYW4gJ3Vu c2F0aXNmaWFibGUNCmNvbnN0cmFpbnRzJyBlcnJvciBhbmQgcGljayBhIHBhY2thZ2Ugb3V0IG9m IHRoZSBsaXN0IG9mIHByb3ZpZGVycy4NCg0KDQozLiBJdCBpcyB2ZXJ5IGhhcmQgdG8ga25vdyB3 aGVyZSB0byBzZW5kIHNvbWUgdGhpbmdzLiAgRm9yIGV4YW1wbGUsDQp0aGUgR0NDIEFQS0JVSUxE IGRvZXMgbm90IGZ1bmN0aW9uIHByb3Blcmx5IHJpZ2h0IG5vdzogaXQgZG9lcyBub3QNCmRlY2xh cmUgYSBtYWtlZGVwZW5kcyBvbiBnY2MtZ25hdCwgYW5kIHRoZSBHQ0MgY29uZmlndXJlIHByb2Nl c3MgYmFpbHMNCm91dCB3aGVuIGl0IGRvZXMgbm90IGZpbmQgaXQgYmVjYXVzZSBMQU5HX0FEQSBp cyB0cnVlIHdoZW5ldmVyIENCVUlMRA0KPT0gQ0hPU1QgPT0gQ1RBUkdFVC4gIEkgYW0gbm90IDEw MCUgY29uZmlkZW50IGluIG15IGFiaWxpdHkgdG8gZWRpdA0KdGhlIEFQS0JVSUxEIGZvciBHQ0Mg Y29uc2lkZXJpbmcgaG93IGZpbmlja3kgaXQgaXMsIHNvIEkgd291bGQgbGlrZQ0KaGVscC4gIEkg cG9zdGVkIG9uIHRoZSBJUkMgY2hhbm5lbCBidXQgSSBtYWlubHkgb25seSBoYXZlIHRoZSB3ZWVr ZW5kcw0KdG8gd29yayBvbiBBZMOpbGllLCBhbmQgbW9zdCBvZiB0aGUgY2hhbm5lbCBpcyBhd2F5 IG9uIHdlZWtlbmRzLiAgVGhpcw0KcmVhbGx5IGlzbid0IGEgZGlzdHJvIHRvcGljLCBzbyBpdCBk b2Vzbid0IGJlbG9uZyBvbiBhbHBpbmUtZGV2ZWwgZnJvbQ0Kd2hhdCBJIGhhdmUgYmVlbiBhYmxl IHRvIGdhdGhlciBhYm91dCB0aGlzIGxpc3QuICBUaGUgYXBvcnRzIGxpc3QNCnNlZW1zIHRvIGJl IGZvciBwYXRjaGVzIG9ubHksIGZyb20gd2hhdCBJIGhhdmUgZ2F0aGVyZWQgYWJvdXQgdGhhdA0K bGlzdC4gIE1heWJlIHRoaXMgYmVsb25ncyBvbiB0aGUgYnVnIHRyYWNrZXIsIGJ1dCB0aGVyZSBy ZWFsbHkgaXNuJ3QgYQ0KYnVnIGNhdGVnb3J5IGZvciBidWlsZCBmYWlsdXJlcyB0aGF0IEkgY291 bGQgZmluZC4NCg0KQWRkaXRpb25hbGx5LCBjaGFuZ2VzIG1hZGUgdG8gYWJ1aWxkIG9yIGFway10 b29scyBhcmUgY3VycmVudGx5IGJlaW5nDQpzZW50IHZpYSBHaXRIdWIgcHVsbCByZXF1ZXN0cy4g IEhvd2V2ZXIsIG5vbmUgb2YgdXMgaW4gQWTDqWxpZSByZWFsbHkNCndhbnQgdG8gdXNlIEdpdEh1 YiBhcyBpdCBpcyBhIGNsb3NlZCBwbGF0Zm9ybS4gIFRoZSBhcG9ydHMgbWFpbGluZw0KbGlzdCBl eGlzdHMgZm9yIGFwb3J0cywgYnV0IHdoZXJlIGNvdWxkIHdlIHNlbmQgYWJ1aWxkIG9yIGFway10 b29scw0KY2hhbmdlcyBpZiB3ZSB3YW50ZWQgYW4gYWx0ZXJuYXRpdmUgdG8gR2l0SHViPw0KDQoN CjQuIFdlIGhhdmUgbWFuYWdlZCB0byBtYWtlIGEgc3BsaXQgZnVuY3Rpb24gJ29wZW5yYycgdGhh dCB0YWtlcw0KL2V0Yy9pbml0LmQgYW5kIC9ldGMvY29uZi5kIGRpcmVjdG9yaWVzLiAgSXQgaGFz IGluc3RhbGxfaWY9IiRwa2duYW1lDQpvcGVucmMiIHNvIGl0IGlzIHRyYW5zcGFyZW50IHdoZW4g eW91IGhhdmUgT3BlblJDIGluc3RhbGxlZCwgYW5kDQphbGxvd3MgZnV0dXJlIG1pZ3JhdGlvbnMg dG8gYSBkaWZmZXJlbnQgaW5pdCBzeXN0ZW0uICBJIGRvbid0IGtub3cgaWYNCnRoaXMgaXMgb2Yg YW55IGludGVyZXN0IHRvIEFscGluZS4NCg0KDQo1LiBBZnRlciBiZWluZyBhbm5veWVkIGJ5IGJ1 Z3MgaW4gdGhlIFBvd2VyUEMgYnVpbGQgb2YgR05VIHRhciwgd2UNCm1hbmFnZWQgdG8gc3dhcCBv dXQgL3Vzci9iaW4vdGFyIGZvciBic2R0YXIgcHJvdmlkZWQgYnkgbGliYXJjaGl2ZSBpbg0KYWJ1 aWxkLiAgSXQgbmVlZGVkIGEgcGF0Y2ggdG8gb3V0cHV0IHRoZSBmb3JtYXQgYXBrIGV4cGVjdHMg YnkNCmRlZmF1bHQsIGJ1dCBvdGhlcndpc2UgaXQgc2VlbXMgdG8gd29yayBxdWl0ZSB3ZWxsLiAg VGhpcyBtYXkgYmUgb2YNCmludGVyZXN0IHRvIHRob3NlIHdobyB3YW50IHRvIGRvIGEgR05VLWZy ZWUgQWxwaW5lIHNwaW4uDQoNCg0KQmVzdCwNCi0gLS1hcncNCg0KLSAtLSANCkEuIFdpbGNveCAo YXdpbGZveCkNClByb2plY3QgTGVhZCwgQWTDqWxpZSBMaW51eA0KaHR0cDovL2FkZWxpZWxpbnV4 Lm9yZw0KLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYyDQoN CmlRSWNCQUVCQ0FBR0JRSlpkZUM5QUFvSkVNc3B5MUdTSzUwVTVHc1FBSXVzbnZxVmtIZ1EwSWR2 UnVUbmdiTUQNCjY1ajBWQWRxU2VDMCtpdUsveUt4a0h2OVllQlRhNk9FUGJad0N4em9pbFlhUGVt M0c3R2pGYzZXYVR3U3dHYXoNCkcxWEpHRVlqN1hJQThMUVoyY1NLd00rTzhGZkJ5WElLeGFPTHY0 N2htNTloaUMzbUZYTFAwWmw3TjJRWEY5TmsNCmVNMFlIOERibkZpeXowb2FuVVM5T0ZPWVM5Nm5Z RUdvZzlxakdxZEhYMXczRU5wYWdXVS9GUmJhUkNEWlFTenoNCk5OYmhYK3lIWVVyRkxHL0QxemVZ YWRIcXdzdENjdUF2OU1nV1k4RGQyZk1LTWRJckFXWXpoajh5MWY0RHUyMTUNCmtVVm1YKzRVUlVm U1VHVkxkZXl3OG1tNDlXTWdLMFhpdmRyNnBoRWZhNDk4eGZRcllhVzMwSlFYbzNwdXpXWmMNCjV0 YWJmRHhtb2xNOXhOS0VBOUsvd2VjZ3VTbnBoa2R6MTFZTWU4RENGOUtQaURhYmJwQWRoV2Rja21a QU5neG0NCjd2ekFmdHF1Skt3bk4yclcyb0tmdVZGWDY1WEt4WElGRUo4MkJ5RTUyQm5WUlg1L0Ro VUtEbjN1cCt5WGJPWWwNCkloSGZUbHlBYmF4VGk1b3ZTaFBiNE1LZ084Z2RzRE15cnlqL0dWUXlv aXZzSHA1ek5GNWdoSENPeEFqNE4razENCkZBaW5JVkpGUkloUnJtdjVmSFBjdmhldFV6UWRkK1Jv VllOU0owUUMzQWgzOHlxWkZ3bmt4RVp6MENlMDZBWlQNCmg5cGp6WFNzb2dOMFVCaVNkcXVzdHh2 YUNnWWxtTG9kOVhRZW1hcUVPS3QrN05uNkFmWjVIVzBmdFZ5OEdXZzcNCkFDMU5hMXJxSWNrMEhH VXFVWWtODQo9S0dIOA0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tDQoNCg0KLS0tDQpVbnN1 YnNjcmliZTogIGFscGluZS1kZXZlbCt1bnN1YnNjcmliZUBsaXN0cy5hbHBpbmVsaW51eC5vcmcN CkhlbHA6ICAgICAgICAgYWxwaW5lLWRldmVsK2hlbHBAbGlzdHMuYWxwaW5lbGludXgub3JnDQot LS0NCg== From nobody Thu Mar 28 17:59:51 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mail.shiz.me (immunity.shiz.me [62.210.12.63]) by lists.alpinelinux.org (Postfix) with ESMTP id 8CCC55C4C46 for ; Mon, 24 Jul 2017 14:53:58 +0000 (GMT) Received: from [10.1.10.227] (185.82.186.24 [185.82.186.24]) by mail.shiz.me (OpenSMTPD) with ESMTPSA id ea2de975 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Mon, 24 Jul 2017 14:53:57 +0000 (UTC) From: Shiz Message-Id: <57A1A151-0352-40DA-BC91-52980CEE99C3@shiz.me> Content-Type: multipart/signed; boundary="Apple-Mail=_B77D143C-DF16-490B-AA77-65FC7653DB84"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_=5Balpine-devel=5D_Ad=C3=A9lie_on_Alpine=2C_two_m?= =?utf-8?Q?onths_later?= Date: Mon, 24 Jul 2017 16:53:50 +0200 In-Reply-To: <5975E0C0.1030008@adelielinux.org> Cc: alpine-dev To: "A. Wilcox" References: <5975E0C0.1030008@adelielinux.org> X-Mailer: Apple Mail (2.3273) --Apple-Mail=_B77D143C-DF16-490B-AA77-65FC7653DB84 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Thanks for sharing your experiences! I=E2=80=99ll comment on the = specific cases below. > 1. scripts/bootstrap.sh cannot "fake" cross. Since Ad=C3=A9lie uses = a > slightly different GCC configuration from Alpine, I attempted to run > bootstrap.sh on x86_64, from my x86_64 system: >=20 >=20 > ERROR: unsatisfiable constraints: > gcc-6.3.0-r4: > conflicts: gcc-x86_64-6.3.0-r4[so:libcilkrts.so.5=3D5.0.0] > satisfies: world[gcc] g++-6.3.0-r4[gcc=3D6.3.0-r4] > gcc-gnat-6.3.0-r4[gcc=3D6.3.0-r4] build-base-0.5-r0[gcc] > gcc-x86_64-6.3.0-r4: > conflicts: gcc-6.3.0-r4[so:libcilkrts.so.5=3D5.0.0] > satisfies: world[gcc-x86_64] >=20 >=20 > Since we have other CPU types that we wish to support, I went ahead > and simply bootstrapped PowerPC. This is therefore not a fatal error, > but one that has caused a lot of time to burn; a lot of packages are > just not ready for ppc and needed some fixing. Specifically, GCC and > OpenSSL needed to be made aware of the PowerPC architecture. I=E2=80=99m in general not a huge fan of how bootstrapping works at the = moment, but I don=E2=80=99t see a direct way to improve it without rewriting it = entirely and adding significant new functionality (like proper multiline) to APK. > 2. The virtual system is pathetic. One of the very core tenets of > Ad=C3=A9lie is giving the user power through choice. That choice is = almost > impossible to provide using the current abuild/apk framework. I keep > hearing of a Debian-style alternatives system, and supposedly it was > specified somewhere, but I cannot find the specification nor an > implementation. If I could read the specification I would be highly > motivated to write an implementation. This is correct and something that has been bothering us for a while. A while back I wrote up a rough sketch of how such a system would = function in APK, which is likely what you are referring to. It can be found here: https://txt.shiz.me/ZDNkNTY3MD.txt I have no specific experience with apk-tools=E2=80=99s internals, but = would be open to looking into them to see what=E2=80=99s needed, possibly/preferably = with kaniini and fabled=E2=80=99s assistance and insights as well. > Red Hat has `alternatives`, Debian has `update-alternatives`, and > Gentoo has `eselect`. The Alpine system desperately needs something > like this and I would love to contribute to such. >=20 > Consider a few different use cases: >=20 > mta: any package that needs `sendmail` has to either hard-depend on > postfix, or disable mail services. This is unacceptable in my > opinion. Other distros let you select what package you want to > provide `sendmail`. >=20 > awk: mawk vs gawk vs busybox awk. All have benefits and drawbacks and > the user should be able to choose which provides /usr/bin/awk. >=20 > shell: /bin/sh as busybox is of course default, but some users may > want bash or another shell. I don't see any reason that can't be > supported. >=20 > vi: busybox, vim, neovim, elvis, ... There are almost a dozen > providers of `vi` in Debian and more than a dozen on Gentoo. I > believe Alpine itself packages four of them. Something I=E2=80=99d like to see is file: dependencies (in the same = vein as so:, but for full file paths), but that=E2=80=99d require encoding = the entire file listing of a package in its `provides` metadata, which I=E2=80= =99m not sure we want due to APKINDEX file size bloat. > I started to try and make 'v:mta' but I'm very concerned about > diverging so much from the Alpine aports tree. Also, apk doesn't > support an automatic choice for a virtual if the user hasn't already > installed one (something like replaces_priority but for virtuals would > be good here imo). That means that when I *do* manage to get packages > to depend on v:mta, the user now has to read through an 'unsatisfiable > constraints' error and pick a package out of the list of providers. I=E2=80=99m not sure what the best way to approach this would be in the = system sketch I laid out above. > 3. It is very hard to know where to send some things. For example, > the GCC APKBUILD does not function properly right now: it does not > declare a makedepends on gcc-gnat, and the GCC configure process bails > out when it does not find it because LANG_ADA is true whenever CBUILD > =3D=3D CHOST =3D=3D CTARGET. I am not 100% confident in my ability to = edit > the APKBUILD for GCC considering how finicky it is, so I would like > help. I posted on the IRC channel but I mainly only have the weekends > to work on Ad=C3=A9lie, and most of the channel is away on weekends. = This > really isn't a distro topic, so it doesn't belong on alpine-devel from > what I have been able to gather about this list. The aports list > seems to be for patches only, from what I have gathered about that > list. Maybe this belongs on the bug tracker, but there really isn't a > bug category for build failures that I could find. This would be a bug against aports in the bug tracker. Generally most of us are somewhat busy, especially considering the time of the year. Pinging specific people can work however =E2=80=94 don=E2=80=99t take = our lack of response as lack of interest. :) > Additionally, changes made to abuild or apk-tools are currently being > sent via GitHub pull requests. However, none of us in Ad=C3=A9lie = really > want to use GitHub as it is a closed platform. The aports mailing > list exists for aports, but where could we send abuild or apk-tools > changes if we wanted an alternative to GitHub? These kind of changes should be sent to alpine-devel if you do not wish to use GitHub. > 4. We have managed to make a split function 'openrc' that takes > /etc/init.d and /etc/conf.d directories. It has install_if=3D"$pkgname > openrc" so it is transparent when you have OpenRC installed, and > allows future migrations to a different init system. I don't know if > this is of any interest to Alpine. I=E2=80=99d like to see this, yes. It seems like a good addition in = light of the things discussed at FOSDEM with regards to init systems. > 5. After being annoyed by bugs in the PowerPC build of GNU tar, we > managed to swap out /usr/bin/tar for bsdtar provided by libarchive in > abuild. It needed a patch to output the format apk expects by > default, but otherwise it seems to work quite well. This may be of > interest to those who want to do a GNU-free Alpine spin. I=E2=80=99m not personally interested in bsdtar as I consider libarchive = fairly bloated, but if the patch is backwards-compatible with GNU tar I would see no issue with including it at all. > Best, > --arw Hope this helped a bit, - Shiz --Apple-Mail=_B77D143C-DF16-490B-AA77-65FC7653DB84 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZdgoEAAoJEI8YjKeZk+kHxRQQAMkPV5IpXdUcgfjez/pH5aRm 6yh7k9U5gAceMIO2jS3502957s1/yDo7cZRmoKNFFdYX56GIFn+977h/LM8xUszK ZHI2BgphjcwKBmUpdnzGaAfv7jw9Hm1tzTYX8KngdquPSexFuhK7DbLerckTO/RP 8VYDpN41rgHY3OX7YHZO9aVf49gwm3IWVJN1HgVweqV9/+C3E70W+xIQ64bUKbAe wgd6ME2mjQVEXDTchNKllJV7jnw7clI7DpEuEdscya5mj6h9DlJfwyFWY8+fuf2F yMZDHPrs1uF2zuFL+HLNjToScj06QK3mXdh3Ei9rDfSZPvjcNpyQnO2L12V2LZUF 48rCumHeexatEB9VoI6svtZ+VamG/t5hGTV+yz+Eh5DauAQmjpyoOnr9LTEnEJm4 UD4MvX4v66gmNlWAVwWt50WJ5Sp0WH4pmki0btYGU8t22g5apQJmM3R8K/eU4SuG t0DdfcIR81hgbsCOVcIEApgOZ3kdNg/gqKSR6g/Rd537SKdGCZ76mujpuAYOIlrj xVzaA5Zaw0xAtUaT9bnwOYXeWXVlng+RHWXL6FbfIHmHch/qy2CSh9AsBRqx/s7q bvINtIHEfA8WEtglB/ySpNZQkDdz+w/uJfSvBRNKBMSgU0e1bwjM4ctymwOobqie 5gCVufDFbLVei1k6MLic =vK+s -----END PGP SIGNATURE----- --Apple-Mail=_B77D143C-DF16-490B-AA77-65FC7653DB84-- --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org --- From nobody Thu Mar 28 17:59:51 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mail-lf0-f68.google.com (mail-lf0-f68.google.com [209.85.215.68]) by lists.alpinelinux.org (Postfix) with ESMTP id 43F5C5C4C64 for ; Tue, 25 Jul 2017 06:07:55 +0000 (GMT) Received: by mail-lf0-f68.google.com with SMTP id 65so272168lfa.0 for ; Mon, 24 Jul 2017 23:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=8HO/ctiKWyQTeTQ3syZwI/2+547bWjbcA0LV3H2ncJw=; b=p5ld3NmM+jdqhznNOqQHtY+AxY1ntMnHOc13v9dmWTuTzjOdUxB46gOrS1ZpXKB5sS GrcR/KUTI0+m8FCa2UZanQ8aPus2Et22Ad2q1cgTtwBZoopI6DlbGSplfuoGsTfbgtqJ qKDttE+G1nk16jwOL2Pjnuuzok7+t8qu2NGqSOAOlKKZRa/2DAL2ixkpAkbA6QOjHXkx 0UvNNfyHUXWyHiq4q1o4vSpXsMoC51AFaILi7sHbiGJbvTfPMy1LAh+Rz+qlcMsGyynv 36ixnrgnLF19zuvnJYceYgum6V9kSbpeAM9VukNgmzTGx13ToOW1Fz10zdqkKt8Cr3FC z+Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :in-reply-to:references:mime-version:content-transfer-encoding; bh=8HO/ctiKWyQTeTQ3syZwI/2+547bWjbcA0LV3H2ncJw=; b=csFIMF3vbZ3+o1P244kbcP0F2kJiwgPrMUU5GWFpOyUQbXnNY6wK49Fa1sDdIUhcyS NRKMrgtt0uhXYiNqzN4sv6Pwna3lwdcA4TFK4mkVRHY1zVlAVFS9QIr90lz+OcOvEnsx 03IbTjjU3pEgWeKJDbFiiUZPc4UQ6CT7Gf0qpipvYLZ58d33oZ1NyyIRIHMVn6VfZWCZ QXOPG8Nk/ocokbId5wqW+JyfrF23jkkTCAr6fwuR7eSDqoO0T1kOBquwLlcmuIfufCbR 6WflYxoUji/4XgKukIPUq1uIJRqWGtic/eVox22UHO13EGUPDwR56+L1AVzCV0RM03u3 zvtQ== X-Gm-Message-State: AIVw1104mvP13NSjeyZ9AtqwNSXpmh6iR1jLqcLiMcaEwKzJg895L3EA orchPMMpQktNeAYt X-Received: by 10.46.70.10 with SMTP id t10mr3557653lja.183.1500962874196; Mon, 24 Jul 2017 23:07:54 -0700 (PDT) Received: from vostro ([2001:1bc8:101:f402:e66f:13ff:fef3:8cd0]) by smtp.gmail.com with ESMTPSA id 2sm2697217ljg.70.2017.07.24.23.07.53 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 24 Jul 2017 23:07:53 -0700 (PDT) Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= Date: Tue, 25 Jul 2017 09:07:51 +0300 From: Timo Teras To: Shiz Cc: "A. Wilcox" , alpine-dev Subject: Re: [alpine-devel] =?UTF-8?B?QWTDqWxpZQ==?= on Alpine, two months later Message-ID: <20170725090742.61793ff2@vostro> In-Reply-To: <57A1A151-0352-40DA-BC91-52980CEE99C3@shiz.me> References: <5975E0C0.1030008@adelielinux.org> <57A1A151-0352-40DA-BC91-52980CEE99C3@shiz.me> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-alpine-linux-musl) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, 24 Jul 2017 16:53:50 +0200 Shiz wrote: > > 1. scripts/bootstrap.sh cannot "fake" cross. Since Ad=C3=A9lie uses a > > slightly different GCC configuration from Alpine, I attempted to run > > bootstrap.sh on x86_64, from my x86_64 system: > >=20 > >=20 > > ERROR: unsatisfiable constraints: > > gcc-6.3.0-r4: > > conflicts: gcc-x86_64-6.3.0-r4[so:libcilkrts.so.5=3D5.0.0] > > satisfies: world[gcc] g++-6.3.0-r4[gcc=3D6.3.0-r4] > > gcc-gnat-6.3.0-r4[gcc=3D6.3.0-r4] build-base-0.5-r0[gcc] > > gcc-x86_64-6.3.0-r4: > > conflicts: gcc-6.3.0-r4[so:libcilkrts.so.5=3D5.0.0] > > satisfies: world[gcc-x86_64] > >=20 > > Since we have other CPU types that we wish to support, I went ahead > > and simply bootstrapped PowerPC. This is therefore not a fatal > > error, but one that has caused a lot of time to burn; a lot of > > packages are just not ready for ppc and needed some fixing. > > Specifically, GCC and OpenSSL needed to be made aware of the > > PowerPC architecture. The above error is mostly due to GCC having strict versioned dependencies for the exact pkgversion + pkgrel. And probably the gcc APKBUILD you tried to use to bootstrap did not match the gcc installed on your system. I am not entirely sure how the dependencies should be fixed. Additionally the crossbuild mechanism is triggered by build arch being different from host arch. So bootstrapping same architecture is not so trivial. This is also how it works on gcc, though it's using the arch triplets. As such the bootstrap script is currently really intended for bootstrapping new architectures only. > I=E2=80=99m in general not a huge fan of how bootstrapping works at the > moment, but I don=E2=80=99t see a direct way to improve it without rewrit= ing > it entirely and adding significant new functionality (like proper > multiline) to APK. Could you elaborate this a bit? We actually now properly cross-build and package .apk package at each step. While it's not polished, it does actually technically the correct thing in most cases. > > 2. The virtual system is pathetic. One of the very core tenets of > > Ad=C3=A9lie is giving the user power through choice. That choice is > > almost impossible to provide using the current abuild/apk > > framework. I keep hearing of a Debian-style alternatives system, > > and supposedly it was specified somewhere, but I cannot find the > > specification nor an implementation. If I could read the > > specification I would be highly motivated to write an > > implementation. =20 >=20 > This is correct and something that has been bothering us for a while. > A while back I wrote up a rough sketch of how such a system would > function in APK, which is likely what you are referring to. It can be > found here: https://txt.shiz.me/ZDNkNTY3MD.txt >=20 > I have no specific experience with apk-tools=E2=80=99s internals, but wou= ld > be open to looking into them to see what=E2=80=99s needed, > possibly/preferably with kaniini and fabled=E2=80=99s assistance and insi= ghts > as well. Yes, this has been discussed couple of times. I've been designing apk v3 with different implementation for resolving file conflicts. The basic idea being as described in Shiz's note (though this is the first time I see it). The plan was to resolve conflicts first based on the 'replaces priority' but have some sort of manual override. > > Red Hat has `alternatives`, Debian has `update-alternatives`, and > > Gentoo has `eselect`. The Alpine system desperately needs something > > like this and I would love to contribute to such. > >=20 > > Consider a few different use cases: > >=20 > > mta: any package that needs `sendmail` has to either hard-depend on > > postfix, or disable mail services. This is unacceptable in my > > opinion. Other distros let you select what package you want to > > provide `sendmail`. > >=20 > > awk: mawk vs gawk vs busybox awk. All have benefits and drawbacks > > and the user should be able to choose which provides /usr/bin/awk. > >=20 > > shell: /bin/sh as busybox is of course default, but some users may > > want bash or another shell. I don't see any reason that can't be > > supported. > >=20 > > vi: busybox, vim, neovim, elvis, ... There are almost a dozen > > providers of `vi` in Debian and more than a dozen on Gentoo. I > > believe Alpine itself packages four of them.=20 Yes. Currently the way it works busybox is a hack. I'd love to get this fixed too. > Something I=E2=80=99d like to see is file: dependencies (in the same vein > as so:, but for full file paths), but that=E2=80=99d require encoding the > entire file listing of a package in its `provides` metadata, which I=E2= =80=99m > not sure we want due to APKINDEX file size bloat. We have some intent to add full DB of files, as separate index files. I'd rather not depend file directly. But nothing prevents adding "provides=3Dfile:/bin/foo" from multiple packages and have packages depend on it. In fact this is how the automatic dso dependencies work; they scan for the .so files, and create provides for it, and depends on them. > > I started to try and make 'v:mta' but I'm very concerned about > > diverging so much from the Alpine aports tree. Also, apk doesn't > > support an automatic choice for a virtual if the user hasn't already > > installed one (something like replaces_priority but for virtuals > > would be good here imo). That means that when I *do* manage to get > > packages to depend on v:mta, the user now has to read through an > > 'unsatisfiable constraints' error and pick a package out of the > > list of providers. =20 Correct. The automatic choice is done only if the provided dependency is versioned, but that also automatically conflicts with other providers of the same dependency. It was intentional design choice to not do automatic choice for the versionless provided names. Replaces priority or similar work here. But I would like to give a bit more thought to this. > I=E2=80=99m not sure what the best way to approach this would be in the s= ystem > sketch I laid out above. >=20 > > 3. It is very hard to know where to send some things. For example, > > the GCC APKBUILD does not function properly right now: it does not > > declare a makedepends on gcc-gnat, and the GCC configure process > > bails out when it does not find it because LANG_ADA is true > > whenever CBUILD =3D=3D CHOST =3D=3D CTARGET. I am not 100% confident i= n my > > ability to edit the APKBUILD for GCC considering how finicky it is, > > so I would like help. I posted on the IRC channel but I mainly > > only have the weekends to work on Ad=C3=A9lie, and most of the channel > > is away on weekends. This really isn't a distro topic, so it > > doesn't belong on alpine-devel from what I have been able to gather > > about this list. The aports list seems to be for patches only, > > from what I have gathered about that list. Maybe this belongs on > > the bug tracker, but there really isn't a bug category for build > > failures that I could find. =20 >=20 > This would be a bug against aports in the bug tracker. Generally most > of us are somewhat busy, especially considering the time of the year. > Pinging specific people can work however =E2=80=94 don=E2=80=99t take our= lack of > response as lack of interest. :) Agreed. Alpine-devel mailing list like you did now is also good :) Toolchain assumes to have toolchain on builders. gcc-gnat is somehow nasty, it should be in build-base *or* in makedepends explicitly. But IIRC, the build scripts had some limitations on this originally. Perhaps this is fixed now. @ncopa Could we just add gcc-gnat to gcc's makedepends, or build-base? > > Additionally, changes made to abuild or apk-tools are currently > > being sent via GitHub pull requests. However, none of us in Ad=C3=A9lie > > really want to use GitHub as it is a closed platform. The aports > > mailing list exists for aports, but where could we send abuild or > > apk-tools changes if we wanted an alternative to GitHub? =20 >=20 > These kind of changes should be sent to alpine-devel if you do not > wish to use GitHub. We've picked up patches to abuild and apk-tools from alpine-devel and alpine-aports mailing lists. Perhaps we should have alpine-patches or similar for non-aports patches. Thanks! Timo --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org --- From nobody Thu Mar 28 17:59:51 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mail.wilcox-tech.com (mail.wilcox-tech.com [45.32.83.9]) by lists.alpinelinux.org (Postfix) with ESMTP id 615AC5C4C6C for ; Tue, 25 Jul 2017 12:30:40 +0000 (GMT) Received: (qmail 28199 invoked from network); 25 Jul 2017 12:30:33 -0000 Received: from ip68-13-242-69.ok.ok.cox.net (HELO ?10.1.1.57?) (awilcox@wilcox-tech.com@68.13.242.69) by mail.wilcox-tech.com with ESMTPA; 25 Jul 2017 12:30:33 -0000 Subject: =?UTF-8?Q?Re:_[alpine-devel]_Ad=c3=a9lie_on_Alpine=2c_two_months_la?= =?UTF-8?Q?ter?= To: Timo Teras , Shiz References: <5975E0C0.1030008@adelielinux.org> <57A1A151-0352-40DA-BC91-52980CEE99C3@shiz.me> <20170725090742.61793ff2@vostro> Cc: alpine-dev From: "A. Wilcox" X-Enigmail-Draft-Status: N1110 Organization: =?UTF-8?Q?Ad=c3=a9lie_Linux?= Message-ID: <597739E9.9080006@adelielinux.org> Date: Tue, 25 Jul 2017 07:30:33 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 In-Reply-To: <20170725090742.61793ff2@vostro> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCk9uIDI1 LzA3LzE3IDAxOjA3LCBUaW1vIFRlcmFzIHdyb3RlOg0KPiBPbiBNb24sIDI0IEp1bCAyMDE3IDE2 OjUzOjUwICswMjAwIFNoaXogPGhpQHNoaXoubWU+IHdyb3RlOg0KPiANCj4+PiAxLiAgc2NyaXB0 cy9ib290c3RyYXAuc2ggY2Fubm90ICJmYWtlIiBjcm9zcy4gIFNpbmNlIEFkw6lsaWUNCj4+PiB1 c2VzIGEgc2xpZ2h0bHkgZGlmZmVyZW50IEdDQyBjb25maWd1cmF0aW9uIGZyb20gQWxwaW5lLCBJ DQo+Pj4gYXR0ZW1wdGVkIHRvIHJ1biBib290c3RyYXAuc2ggb24geDg2XzY0LCBmcm9tIG15IHg4 Nl82NA0KPj4+IHN5c3RlbToNCj4+PiANCj4gDQo+IFRoZSBhYm92ZSBlcnJvciBpcyBtb3N0bHkg ZHVlIHRvIEdDQyBoYXZpbmcgc3RyaWN0IHZlcnNpb25lZCANCj4gZGVwZW5kZW5jaWVzIGZvciB0 aGUgZXhhY3QgcGtndmVyc2lvbiArIHBrZ3JlbC4gQW5kIHByb2JhYmx5IHRoZSANCj4gZ2NjIEFQ S0JVSUxEIHlvdSB0cmllZCB0byB1c2UgdG8gYm9vdHN0cmFwIGRpZCBub3QgbWF0Y2ggdGhlIGdj YyANCj4gaW5zdGFsbGVkIG9uIHlvdXIgc3lzdGVtLiBJIGFtIG5vdCBlbnRpcmVseSBzdXJlIGhv dyB0aGUNCj4gZGVwZW5kZW5jaWVzIHNob3VsZCBiZSBmaXhlZC4NCj4gDQo+IEFkZGl0aW9uYWxs eSB0aGUgY3Jvc3NidWlsZCBtZWNoYW5pc20gaXMgdHJpZ2dlcmVkIGJ5IGJ1aWxkIGFyY2gNCj4g YmVpbmcgZGlmZmVyZW50IGZyb20gaG9zdCBhcmNoLiBTbyBib290c3RyYXBwaW5nIHNhbWUgYXJj aGl0ZWN0dXJlDQo+IGlzIG5vdCBzbyB0cml2aWFsLiBUaGlzIGlzIGFsc28gaG93IGl0IHdvcmtz IG9uIGdjYywgdGhvdWdoIGl0J3MNCj4gdXNpbmcgdGhlIGFyY2ggdHJpcGxldHMuIEFzIHN1Y2gg dGhlIGJvb3RzdHJhcCBzY3JpcHQgaXMgY3VycmVudGx5DQo+IHJlYWxseSBpbnRlbmRlZCBmb3Ig Ym9vdHN0cmFwcGluZyBuZXcgYXJjaGl0ZWN0dXJlcyBvbmx5Lg0KDQoNCkhvdyBkb2VzIG9uZSBi b290c3RyYXAgYSBuZXcgZGlzdHJvPyAgRXNwZWNpYWxseSBvbmUgd2l0aCBhIHNsaWdodGx5DQpk aWZmZXJlbnQgdHJpcGxldCAoaTQ4Ni0qLCBwb3dlcnBjNjQtKiwgZXRjKSB0aGFuIEFscGluZSdz LCBub3QgdG8NCm1lbnRpb24gZGlmZmVyZW50IGNvbmZpZ3VyYXRpb24gb3B0aW9ucz8gIFNob3Vs ZCBJIGp1c3QgYnVpbGQgYSBuZXcNCkdDQyBhbmQgaW5zdGFsbCBpdCBvdmVyIHRoZSBjdXJyZW50 IG9uZT8NCg0KSSBmaWd1cmVkIHJ1bm5pbmcgYm9vdHN0cmFwLnNoIHdvdWxkIGJlIHRoZSBxdWlj a2VzdCAvIGVhc2llc3Qgd2F5IHRvDQpkbyB0aGF0LiAgQnV0IG1heWJlIEkgd2FzIHdyb25nLg0K DQoNCj4+IEEgd2hpbGUgYmFjayBJIHdyb3RlIHVwIGEgcm91Z2ggc2tldGNoIG9mIGhvdyBzdWNo IGEgc3lzdGVtDQo+PiB3b3VsZCBmdW5jdGlvbiBpbiBBUEssIHdoaWNoIGlzIGxpa2VseSB3aGF0 IHlvdSBhcmUgcmVmZXJyaW5nIHRvLg0KPj4gSXQgY2FuIGJlIGZvdW5kIGhlcmU6IGh0dHBzOi8v dHh0LnNoaXoubWUvWkROa05UWTNNRC50eHQNCj4gDQo+IFllcywgdGhpcyBoYXMgYmVlbiBkaXNj dXNzZWQgY291cGxlIG9mIHRpbWVzLiBJJ3ZlIGJlZW4gZGVzaWduaW5nDQo+IGFwayB2MyB3aXRo IGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbiBmb3IgcmVzb2x2aW5nIGZpbGUgY29uZmxpY3RzLg0K PiBUaGUgYmFzaWMgaWRlYSBiZWluZyBhcyBkZXNjcmliZWQgaW4gU2hpeidzIG5vdGUgKHRob3Vn aCB0aGlzIGlzDQo+IHRoZSBmaXJzdCB0aW1lIEkgc2VlIGl0KS4gVGhlIHBsYW4gd2FzIHRvIHJl c29sdmUgY29uZmxpY3RzIGZpcnN0DQo+IGJhc2VkIG9uIHRoZSAncmVwbGFjZXMgcHJpb3JpdHkn IGJ1dCBoYXZlIHNvbWUgc29ydCBvZiBtYW51YWwNCj4gb3ZlcnJpZGUuDQoNCg0KV291bGQgdGhl cmUgc3RpbGwgYmUgYSB3YXkgdG8gY2hvb3NlIGEgZGlmZmVyZW50IHByb3ZpZGVyIGxhdGVyPw0K DQoNCj4+IFRoaXMgd291bGQgYmUgYSBidWcgYWdhaW5zdCBhcG9ydHMgaW4gdGhlIGJ1ZyB0cmFj a2VyLiBHZW5lcmFsbHkNCj4+IG1vc3Qgb2YgdXMgYXJlIHNvbWV3aGF0IGJ1c3ksIGVzcGVjaWFs bHkgY29uc2lkZXJpbmcgdGhlIHRpbWUgb2YNCj4+IHRoZSB5ZWFyLiBQaW5naW5nIHNwZWNpZmlj IHBlb3BsZSBjYW4gd29yayBob3dldmVyIOKAlCBkb27igJl0IHRha2UNCj4+IG91ciBsYWNrIG9m IHJlc3BvbnNlIGFzIGxhY2sgb2YgaW50ZXJlc3QuIDopDQo+IA0KPiBBZ3JlZWQuIEFscGluZS1k ZXZlbCBtYWlsaW5nIGxpc3QgbGlrZSB5b3UgZGlkIG5vdyBpcyBhbHNvIGdvb2QgOikNCj4gDQo+ IFRvb2xjaGFpbiBhc3N1bWVzIHRvIGhhdmUgdG9vbGNoYWluIG9uIGJ1aWxkZXJzLiBnY2MtZ25h dCBpcw0KPiBzb21laG93IG5hc3R5LCBpdCBzaG91bGQgYmUgaW4gYnVpbGQtYmFzZSAqb3IqIGlu IG1ha2VkZXBlbmRzDQo+IGV4cGxpY2l0bHkuIEJ1dCBJSVJDLCB0aGUgYnVpbGQgc2NyaXB0cyBo YWQgc29tZSBsaW1pdGF0aW9ucyBvbg0KPiB0aGlzIG9yaWdpbmFsbHkuIFBlcmhhcHMgdGhpcyBp cyBmaXhlZCBub3cuDQo+IA0KPiBAbmNvcGEgQ291bGQgd2UganVzdCBhZGQgZ2NjLWduYXQgdG8g Z2NjJ3MgbWFrZWRlcGVuZHMsIG9yDQo+IGJ1aWxkLWJhc2U/DQoNCg0KSSBrbm93IHRoYXQgYnVp bGQtYmFzZSBpcyBwcm9iYWJseSBhbHJlYWR5IGEgYml0IGxhcmdlciB0aGFuIGl0IG5lZWRzDQp0 byBiZS4uLiBidXQgaG93IG1hbnkgQWRhIHBhY2thZ2VzIGFyZSBvbiBBbHBpbmUgdG8ganVzdGlm eSB0aGUNCmFkZGl0aW9uYWwgc2l6ZSBpbiBidWlsZC1iYXNlPyAgQUZBSUsgbm8gb3RoZXIgZGlz dHJvIGhhcyBBZGEgc3VwcG9ydA0KaW4gdGhlIGJhc2UgYnVpbGQgcGFja2FnZS4gIEl0IHByb2Jh Ymx5IGJlbG9uZ3MgaW4gbWFrZWRlcGVuZHMuDQoNCg0KPj4+IEFkZGl0aW9uYWxseSwgY2hhbmdl cyBtYWRlIHRvIGFidWlsZCBvciBhcGstdG9vbHMgYXJlDQo+Pj4gY3VycmVudGx5IGJlaW5nIHNl bnQgdmlhIEdpdEh1YiBwdWxsIHJlcXVlc3RzLiAgSG93ZXZlciwgbm9uZQ0KPj4+IG9mIHVzIGlu IEFkw6lsaWUgcmVhbGx5IHdhbnQgdG8gdXNlIEdpdEh1YiBhcyBpdCBpcyBhIGNsb3NlZA0KPj4+ IHBsYXRmb3JtLiAgVGhlIGFwb3J0cyBtYWlsaW5nIGxpc3QgZXhpc3RzIGZvciBhcG9ydHMsIGJ1 dCB3aGVyZQ0KPj4+IGNvdWxkIHdlIHNlbmQgYWJ1aWxkIG9yIGFway10b29scyBjaGFuZ2VzIGlm IHdlIHdhbnRlZCBhbg0KPj4+IGFsdGVybmF0aXZlIHRvIEdpdEh1Yj8NCj4+IA0KPj4gVGhlc2Ug a2luZCBvZiBjaGFuZ2VzIHNob3VsZCBiZSBzZW50IHRvIGFscGluZS1kZXZlbCBpZiB5b3UgZG8N Cj4+IG5vdCB3aXNoIHRvIHVzZSBHaXRIdWIuDQo+IA0KPiBXZSd2ZSBwaWNrZWQgdXAgcGF0Y2hl cyB0byBhYnVpbGQgYW5kIGFway10b29scyBmcm9tIGFscGluZS1kZXZlbA0KPiBhbmQgYWxwaW5l LWFwb3J0cyBtYWlsaW5nIGxpc3RzLiBQZXJoYXBzIHdlIHNob3VsZCBoYXZlDQo+IGFscGluZS1w YXRjaGVzIG9yIHNpbWlsYXIgZm9yIG5vbi1hcG9ydHMgcGF0Y2hlcy4NCg0KDQorMSBmb3IgYWxw aW5lLXBhdGNoZXMsIGJ1dCBhbHBpbmUtZGV2ZWwgd29ya3MganVzdCBhcyB3ZWxsIGFuZCBhbHJl YWR5DQpoYXMgdGhlIHN1YnNjcmliZXJzIHNvIGl0IGlzIHByb2JhYmx5IGZpbmUuDQoNCg0KPiAN Cj4gVGhhbmtzISBUaW1vDQo+IA0KDQoNCkJlc3QsDQotIC0tYXJ3DQoNCg0KLSAtLSANCkEuIFdp bGNveCAoYXdpbGZveCkNClByb2plY3QgTGVhZCwgQWTDqWxpZSBMaW51eA0KaHR0cDovL2FkZWxp ZWxpbnV4Lm9yZw0KLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBH IHYyDQoNCmlRSWNCQUVCQ0FBR0JRSlpkem5sQUFvSkVNc3B5MUdTSzUwVTBXUVFBS05kK3JVbU1V Wk1uWHlTSmoxdzJKN3QNCnhlRnhtLzhLRnYvZ045Um5xN0dOZFoxTzZxdnNIYm5OR3RkTUtIcTM5 eWhYSmUyalBSUHVncCs1WituK0lIU3QNClREcU1ZeTlFTlVkK01BbUpJS1pjSjVRczd2Qzl2a25N SnRvUEw2NzRBMFZWc0loamZqUTJGU09VNUtyRlgzeVENCk1qUzcrMS9McXFEUG5JTmdXZnNXVXd2 U256QlBkMnFXZkRXYnNsRHRCQi91azEzanVIemdWT21tRS9Gam45VWoNCm1BdTZvaE12OVVrQnJU UzRpeGh2azJidXRNZFo4TXJsbERVZXdmTEZmaXZsV0dTZmZmMnBPT01rUTFFMWdGUFcNClIwbmZx V0w4R2g2bUozN1VKYnVuWG0vSTBVMGFjdzF2WERFM2pxcGZHSVh1MVI5eDRLNkV1RnY0YWV5WHlm OW8NCjlXbkZMcjFkMGh3TmZleFdxWUZya0FOa09sZVMrcTJ0UkRFMFMvellHMmF5TXhWYS9iYndo UU9kSU14U1V6a1QNCmZYaXJmdE9FRnptcnFXSi9oVWltUndMZzlzT2NVNkd6SXdKNlJaSkQ5RW1I RS9rUCtueDlPd3Q5ME4vQjVrUXkNCjNMczUvaitlM2c3QzFMcEhrSDNCKzM4TkFCQkJjb050QjNa cVI5WWVWMjIzbTVYUW1ONm44aWpOTnA4MG5WVGkNCk0vUytqRHpCR3diYTdyQVJjZ0VhYnZyOW1y ODZzQlJ1QTRYcHQ5Si9WVWs0OUxyZFZXRXpMRWwremJUWXNJWVgNClBJSjU5Z3pBWklxcGsvWUVj WG5GZlZ2MHdtZmdQRXpkRkI1V3p0Mnkwak5idHBJTldiS3pzc21XU3NuMnQwNFgNCmdDNTlLY3VF WGlTdkRnb2J2Kzd0DQo9Y0JZNg0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tDQoNCg0KLS0t DQpVbnN1YnNjcmliZTogIGFscGluZS1kZXZlbCt1bnN1YnNjcmliZUBsaXN0cy5hbHBpbmVsaW51 eC5vcmcNCkhlbHA6ICAgICAgICAgYWxwaW5lLWRldmVsK2hlbHBAbGlzdHMuYWxwaW5lbGludXgu b3JnDQotLS0NCg== From nobody Thu Mar 28 17:59:51 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by lists.alpinelinux.org (Postfix) with ESMTP id 6A6C85C4C70 for ; Tue, 25 Jul 2017 15:10:59 +0000 (GMT) Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v6PFAsBv133631 for ; Tue, 25 Jul 2017 11:10:58 -0400 Received: from e17.ny.us.ibm.com (e17.ny.us.ibm.com [129.33.205.207]) by mx0b-001b2d01.pphosted.com with ESMTP id 2bx87urt31-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 25 Jul 2017 11:10:54 -0400 Received: from localhost by e17.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 25 Jul 2017 11:10:37 -0400 Received: from b01cxnp23033.gho.pok.ibm.com (9.57.198.28) by e17.ny.us.ibm.com (146.89.104.204) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 25 Jul 2017 11:10:36 -0400 Received: from b01ledav002.gho.pok.ibm.com (b01ledav002.gho.pok.ibm.com [9.57.199.107]) by b01cxnp23033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v6PFAUcC65994958 for ; Tue, 25 Jul 2017 15:10:35 GMT Received: from b01ledav002.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DA80212403F for ; Tue, 25 Jul 2017 11:08:00 -0400 (EDT) Received: from [9.80.202.132] (unknown [9.80.202.132]) by b01ledav002.gho.pok.ibm.com (Postfix) with ESMTP id A0975124037 for ; Tue, 25 Jul 2017 11:08:00 -0400 (EDT) Subject: =?UTF-8?Q?Re:_[alpine-devel]_Ad=c3=a9lie_on_Alpine=2c_two_months_la?= =?UTF-8?Q?ter?= To: alpine-devel@lists.alpinelinux.org References: <5975E0C0.1030008@adelielinux.org> <57A1A151-0352-40DA-BC91-52980CEE99C3@shiz.me> <20170725090742.61793ff2@vostro> <597739E9.9080006@adelielinux.org> From: Breno Leitao Date: Tue, 25 Jul 2017 12:10:34 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 In-Reply-To: <597739E9.9080006@adelielinux.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17072515-0040-0000-0000-00000385778F X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007423; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000214; SDB=6.00892721; UDB=6.00446231; IPR=6.00672885; BA=6.00005492; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00016372; XFM=3.00000015; UTC=2017-07-25 15:10:36 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17072515-0041-0000-0000-000007799585 Message-Id: <498c3b7f-0363-8236-ee97-625d4a0993c3@br.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-07-25_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707250240 Hello, On 07/25/2017 09:30 AM, A. Wilcox wrote: > How does one bootstrap a new distro? Especially one with a slightly > different triplet (i486-*, powerpc64-*, etc) than Alpine's, not to > mention different configuration options? Should I just build a new > GCC and install it over the current one? > > I figured running bootstrap.sh would be the quickest / easiest way to > do that. But maybe I was wrong. That is what I found during the ppc64le bootstrap. During the ppc64le bootstrap time, I tried two different strategies: 1) Cross-distro compile Alpine packages from Debian/ppc64le. This strategy seemed better at that time, because I could have delayed or even avoid GCC bootstrap. I.e, I was using Debian's GCC to compile Alpine's package, and I would like to have compiled GCC from the inside an already created Alpine rootfs, without doing the GCC bootstrap process. Since Debian had Musl, it would not be a problem, I thought. 2) Use the bootstrap script and start on Alpine/x86 and starting build from the begining, i.e, doing GCC bootstrap and moving up. What I found later is that it was quite hard to avoid GLIBC contamination during the cross-distro compilation process. I was never able to get rid of the GLIBC symbols using the first strategy. When I switched to the second strategy, it was much easier to find the problem and solve them, seeing progress at every new bug. Anyway, this was my personal experience, and, as you should expect, your mileage may vary. --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org --- From nobody Thu Mar 28 17:59:51 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mail.wilcox-tech.com (mail.wilcox-tech.com [45.32.83.9]) by lists.alpinelinux.org (Postfix) with ESMTP id 47AA45C4C44 for ; Mon, 24 Jul 2017 15:20:40 +0000 (GMT) Received: (qmail 307 invoked from network); 24 Jul 2017 15:20:17 -0000 Received: from ip68-13-242-69.ok.ok.cox.net (HELO ?10.1.1.57?) (awilcox@wilcox-tech.com@68.13.242.69) by mail.wilcox-tech.com with ESMTPA; 24 Jul 2017 15:20:17 -0000 Subject: =?UTF-8?Q?Re:_[alpine-devel]_Ad=c3=a9lie_on_Alpine=2c_two_months_la?= =?UTF-8?Q?ter?= To: Shiz References: <5975E0C0.1030008@adelielinux.org> <57A1A151-0352-40DA-BC91-52980CEE99C3@shiz.me> Cc: alpine-dev From: "A. Wilcox" X-Enigmail-Draft-Status: N1110 Organization: =?UTF-8?Q?Ad=c3=a9lie_Linux?= Message-ID: <59761031.6000605@adelielinux.org> Date: Mon, 24 Jul 2017 10:20:17 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 In-Reply-To: <57A1A151-0352-40DA-BC91-52980CEE99C3@shiz.me> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCkhlbGxv IHRoZXJlLA0KDQpPbiAyNC8wNy8xNyAwOTo1MywgU2hpeiB3cm90ZToNCj4gSGksDQo+IA0KPiBU aGFua3MgZm9yIHNoYXJpbmcgeW91ciBleHBlcmllbmNlcyEgSeKAmWxsIGNvbW1lbnQgb24gdGhl IHNwZWNpZmljIA0KPiBjYXNlcyBiZWxvdy4NCj4gDQo+PiAxLiAgc2NyaXB0cy9ib290c3RyYXAu c2ggY2Fubm90ICJmYWtlIiBjcm9zcy4gIFNpbmNlIEFkw6lsaWUgdXNlcyANCj4+IGEgc2xpZ2h0 bHkgZGlmZmVyZW50IEdDQyBjb25maWd1cmF0aW9uIGZyb20gQWxwaW5lLCBJIGF0dGVtcHRlZCAN Cj4+IHRvIHJ1biBib290c3RyYXAuc2ggb24geDg2XzY0LCBmcm9tIG15IHg4Nl82NCBzeXN0ZW06 DQo+IA0KPiBJ4oCZbSBpbiBnZW5lcmFsIG5vdCBhIGh1Z2UgZmFuIG9mIGhvdyBib290c3RyYXBw aW5nIHdvcmtzIGF0IHRoZSANCj4gbW9tZW50LCBidXQgSSBkb27igJl0IHNlZSBhIGRpcmVjdCB3 YXkgdG8gaW1wcm92ZSBpdCB3aXRob3V0IA0KPiByZXdyaXRpbmcgaXQgZW50aXJlbHkgYW5kIGFk ZGluZyBzaWduaWZpY2FudCBuZXcgZnVuY3Rpb25hbGl0eSANCj4gKGxpa2UgcHJvcGVyIG11bHRp bGluZSkgdG8gQVBLLg0KDQoNCkFQSyBhbHJlYWR5IGtub3dzIGFib3V0IGFyY2hpdGVjdHVyZXMu ICBBbmQgdGhhdCB3b24ndCByZWFsbHkgaGVscCB0aGUNCmZha2UgY3Jvc3M6IHg4Nl82NCA9PSB4 ODZfNjQuICBNYXliZSBhIGhhY2sgd291bGQgYmUgdG8gZG8gc29tZXRoaW5nDQpsaWtlIHJlcGxh Y2VzPSJnY2MiIGluIGdjYy0kYXJjaCBwYWNrYWdlcz8gIFRoZW9yZXRpY2FsbHkgdGhleSBzaG91 bGQNCmJlIGluIHNlcGFyYXRlIGRpcmVjdG9yaWVzIGFueXdheSwgYnV0IEkgYW0gbm90IHN1cmUg aWYgdGhhdCB3b3VsZCBiZQ0Kc2FmZS4NCg0KDQo+PiAyLiBUaGUgdmlydHVhbCBzeXN0ZW0gaXMg cGF0aGV0aWMuICBPbmUgb2YgdGhlIHZlcnkgY29yZSB0ZW5ldHMgDQo+PiBvZiBBZMOpbGllIGlz IGdpdmluZyB0aGUgdXNlciBwb3dlciB0aHJvdWdoIGNob2ljZS4gIFRoYXQgY2hvaWNlIA0KPj4g aXMgYWxtb3N0IGltcG9zc2libGUgdG8gcHJvdmlkZSB1c2luZyB0aGUgY3VycmVudCBhYnVpbGQv YXBrIA0KPj4gZnJhbWV3b3JrLiAgSSBrZWVwIGhlYXJpbmcgb2YgYSBEZWJpYW4tc3R5bGUgYWx0 ZXJuYXRpdmVzDQo+PiBzeXN0ZW0sIGFuZCBzdXBwb3NlZGx5IGl0IHdhcyBzcGVjaWZpZWQgc29t ZXdoZXJlLCBidXQgSSBjYW5ub3QNCj4+IGZpbmQgdGhlIHNwZWNpZmljYXRpb24gbm9yIGFuIGlt cGxlbWVudGF0aW9uLiAgSWYgSSBjb3VsZCByZWFkDQo+PiB0aGUgc3BlY2lmaWNhdGlvbiBJIHdv dWxkIGJlIGhpZ2hseSBtb3RpdmF0ZWQgdG8gd3JpdGUgYW4gDQo+PiBpbXBsZW1lbnRhdGlvbi4N Cj4gDQo+IFRoaXMgaXMgY29ycmVjdCBhbmQgc29tZXRoaW5nIHRoYXQgaGFzIGJlZW4gYm90aGVy aW5nIHVzIGZvciBhIA0KPiB3aGlsZS4gQSB3aGlsZSBiYWNrIEkgd3JvdGUgdXAgYSByb3VnaCBz a2V0Y2ggb2YgaG93IHN1Y2ggYSBzeXN0ZW0gDQo+IHdvdWxkIGZ1bmN0aW9uIGluIEFQSywgd2hp Y2ggaXMgbGlrZWx5IHdoYXQgeW91IGFyZSByZWZlcnJpbmcgdG8uIA0KPiBJdCBjYW4gYmUgZm91 bmQgaGVyZTogaHR0cHM6Ly90eHQuc2hpei5tZS9aRE5rTlRZM01ELnR4dA0KDQoNClRoaXMgc2Vl bXMgbGlrZSBhIGRlY2VudCBzdGFydC4gIEkgbGlrZSBob3cgeW91IGNhbiBzZWxlY3QgYWxsDQpw cm92aWRlZCBwYXRocyBmcm9tIGEgcGFja2FnZSBvciBqdXN0IGEgc3Vic2V0LiAgVGhpcyB3YXMg YWN0dWFsbHkNCnJlcXVlc3RlZCBieSBvbmUgb2Ygb3VyIGVhcmx5IGFscGhhIHRlc3RlcnMuDQoN CldvdWxkIHRoZSByZWxvY2F0aW9ucyBkYXRhYmFzZSBoYXZlICpldmVyeSogZmlsZSwgb3Igb25s eSB0aG9zZSBpbg0KY29uZmxpY3Q/ICBJIGNhbiBzZWUgdGhlIGFyZ3VtZW50IGVpdGhlciB3YXku DQoNCg0KPiBJIGhhdmUgbm8gc3BlY2lmaWMgZXhwZXJpZW5jZSB3aXRoIGFway10b29sc+KAmXMg aW50ZXJuYWxzLCBidXQNCj4gd291bGQgYmUgb3BlbiB0byBsb29raW5nIGludG8gdGhlbSB0byBz ZWUgd2hhdOKAmXMgbmVlZGVkLCANCj4gcG9zc2libHkvcHJlZmVyYWJseSB3aXRoIGthbmlpbmkg YW5kIGZhYmxlZOKAmXMgYXNzaXN0YW5jZSBhbmQgDQo+IGluc2lnaHRzIGFzIHdlbGwuDQoNCg0K SSBoYXZlIHNvbWUgZXhwZXJpZW5jZSB3aXRoIHRoZSBpbnRlcm5hbHMgb2YgYXBrLXRvb2xzLCBi dXQgbm90IHNvDQptdWNoIHRoZSBkYXRhYmFzZSBwb3J0aW9uLiAgUGVyaGFwcyB0aGF0IGlzIGEg dGFzayBmb3IgdGhpcyB3ZWVrZW5kIDopDQoNCg0KPiBTb21ldGhpbmcgSeKAmWQgbGlrZSB0byBz ZWUgaXMgZmlsZTogZGVwZW5kZW5jaWVzIChpbiB0aGUgc2FtZSB2ZWluIA0KPiBhcyBzbzosIGJ1 dCBmb3IgZnVsbCBmaWxlIHBhdGhzKSwgYnV0IHRoYXTigJlkIHJlcXVpcmUgZW5jb2RpbmcgdGhl IA0KPiBlbnRpcmUgZmlsZSBsaXN0aW5nIG9mIGEgcGFja2FnZSBpbiBpdHMgYHByb3ZpZGVzYCBt ZXRhZGF0YSwgd2hpY2ggDQo+IEnigJltIG5vdCBzdXJlIHdlIHdhbnQgZHVlIHRvIEFQS0lOREVY IGZpbGUgc2l6ZSBibG9hdC4NCg0KDQpJIGtub3cgdGhhdCBib3RoIERlYmlhbiBhbmQgUmVkIEhh dCBiYXNlZCBzeXN0ZW1zIGhhdmUgc29tZXRoaW5nIGxpa2UNCnRoaXMgc3RvcmVkIGluIGFub3Ro ZXIgaW5kZXg7IGBhcHQtZmlsZWAgYW5kIGB5dW0gcHJvdmlkZXNgLiAgVGhlDQpkYXRhYmFzZXMg YXJlIHNvbWV3aGVyZSBhcm91bmQgMTAwIE1CIGNvbXByZXNzZWQsIHNvIHRoZXkgb2J2aW91c2x5 DQphcmUgbm90IGEgcGFydCBvZiB0aGUgc3RhbmRhcmQgaW5zdGFsbGF0aW9uIG9mIGFwdC95dW0s IGJ1dCB0aGV5IGFyZQ0KYXZhaWxhYmxlIHRvIGVuYWJsZSBhdCBhbnkgdGltZSBmb3IgdGhlIHVz ZXJzLiAgSSdtIG5vdCBzdXJlIGlmIEFscGluZQ0Kd291bGQgd2FudCB0byBkbyBzb21ldGhpbmcg c2ltaWxhci4gIE9uZSBtZXRob2Qgd291bGQgYmUgdG8gaGF2ZSBzb21lDQpzb3J0IG9mICdzaW1w bGlmaWNhdGlvbicgc3RlcCB3aGVuIGdlbmVyYXRpbmcgQVBLSU5ERVg6IG9ubHkgaW5jbHVkZQ0K ZmlsZTogZnJvbSB0aGUgbWFzdGVyIGZpbGUgZGF0YWJhc2Ugd2hlbiBhIHBhY2thZ2UgcmVmZXJl bmNlcyBpdC4gIEZvcg0KZXhhbXBsZToNCg0KZGVwZW5kcz0iZmlsZTovdXNyL2Jpbi9hd2siDQoN CndvdWxkIGNhdXNlIGV2ZXJ5IGBhd2tgIHByb3ZpZGVyIHRvIGhhdmUgYSBwcm92aWRlczogbGlu ZSBpbiBBUEtJTkRFWA0KZm9yIGZpbGU6L3Vzci9iaW4vYXdrLiAgVGhleSB3b3VsZG4ndCBuZWVk IHRvIGhhdmUgYSBwcm92aWRlczogZm9yDQpldmVyeSBmaWxlLCBvbmx5IHRoZSBvbmVzIHRoYXQg b3RoZXIgcGFja2FnZXMgcmVmZXJlbmNlLg0KDQoNCj4+IEkgc3RhcnRlZCB0byB0cnkgYW5kIG1h a2UgJ3Y6bXRhJyBidXQgSSdtIHZlcnkgY29uY2VybmVkIGFib3V0IA0KPj4gZGl2ZXJnaW5nIHNv IG11Y2ggZnJvbSB0aGUgQWxwaW5lIGFwb3J0cyB0cmVlLiAgQWxzbywgYXBrIGRvZXNuJ3QNCj4+ IHN1cHBvcnQgYW4gYXV0b21hdGljIGNob2ljZSBmb3IgYSB2aXJ0dWFsIGlmIHRoZSB1c2VyIGhh c24ndA0KPj4gYWxyZWFkeSBpbnN0YWxsZWQgb25lIChzb21ldGhpbmcgbGlrZSByZXBsYWNlc19w cmlvcml0eSBidXQgZm9yDQo+PiB2aXJ0dWFscyB3b3VsZCBiZSBnb29kIGhlcmUgaW1vKS4gIFRo YXQgbWVhbnMgdGhhdCB3aGVuIEkgKmRvKg0KPj4gbWFuYWdlIHRvIGdldCBwYWNrYWdlcyB0byBk ZXBlbmQgb24gdjptdGEsIHRoZSB1c2VyIG5vdyBoYXMgdG8NCj4+IHJlYWQgdGhyb3VnaCBhbiAn dW5zYXRpc2ZpYWJsZSBjb25zdHJhaW50cycgZXJyb3IgYW5kIHBpY2sgYSANCj4+IHBhY2thZ2Ug b3V0IG9mIHRoZSBsaXN0IG9mIHByb3ZpZGVycy4NCj4gDQo+IEnigJltIG5vdCBzdXJlIHdoYXQg dGhlIGJlc3Qgd2F5IHRvIGFwcHJvYWNoIHRoaXMgd291bGQgYmUgaW4gdGhlIA0KPiBzeXN0ZW0g c2tldGNoIEkgbGFpZCBvdXQgYWJvdmUuDQoNCg0KVGhlIGFib3ZlLWxpbmtlZCBzcGVjaWZpY2F0 aW9uIGRvZXNuJ3QgcmVzb2x2ZSB0aGlzIGluIGFueSB3YXkuDQpUaGF0J3MgZmluZSBiZWNhdXNl IGl0IGRvZXNuJ3QgbmVlZCB0by4gIFRoYXQgY2FuIGJlIGEgc2VwYXJhdGUNCmRpc2N1c3Npb24g LyBzcGVjaWZpY2F0aW9uLiAgKEFQSyBpcyBhbHJlYWR5IGRlZmljaWVudCBpbiB0aGF0IHJlZ2Fy ZCwNCnNvIGl0IHNob3VsZCBiZSBmaXhlZCBpbmRlcGVuZGVudGx5IG9mIGFkZGluZyBhbiBhbHRl cm5hdGl2ZXMgc3lzdGVtLA0KSU1PLikNCg0KDQo+PiAzLiBJdCBpcyB2ZXJ5IGhhcmQgdG8ga25v dyB3aGVyZSB0byBzZW5kIHNvbWUgdGhpbmdzLiAgRm9yIA0KPj4gZXhhbXBsZSwgdGhlIEdDQyBB UEtCVUlMRCBkb2VzIG5vdCBmdW5jdGlvbiBwcm9wZXJseSByaWdodCBub3c6IA0KPj4gaXQgZG9l cyBub3QgZGVjbGFyZSBhIG1ha2VkZXBlbmRzIG9uIGdjYy1nbmF0LCBhbmQgdGhlIEdDQyANCj4+ IGNvbmZpZ3VyZSBwcm9jZXNzIGJhaWxzIG91dCB3aGVuIGl0IGRvZXMgbm90IGZpbmQgaXQgYmVj YXVzZSANCj4+IExBTkdfQURBIGlzIHRydWUgd2hlbmV2ZXIgQ0JVSUxEID09IENIT1NUID09IENU QVJHRVQuDQo+IA0KPiBUaGlzIHdvdWxkIGJlIGEgYnVnIGFnYWluc3QgYXBvcnRzIGluIHRoZSBi dWcgdHJhY2tlci4gR2VuZXJhbGx5IA0KPiBtb3N0IG9mIHVzIGFyZSBzb21ld2hhdCBidXN5LCBl c3BlY2lhbGx5IGNvbnNpZGVyaW5nIHRoZSB0aW1lIG9mIA0KPiB0aGUgeWVhci4gUGluZ2luZyBz cGVjaWZpYyBwZW9wbGUgY2FuIHdvcmsgaG93ZXZlciDigJQgZG9u4oCZdCB0YWtlDQo+IG91ciBs YWNrIG9mIHJlc3BvbnNlIGFzIGxhY2sgb2YgaW50ZXJlc3QuIDopDQoNCg0KSSBuZXZlciB0b29r IGl0IGFzIGEgbGFjayBvZiBpbnRlcmVzdC4gIEkga25vdyB0aGF0IHBlb3BsZSBhcmUgYnVzeQ0K YW5kIGhhdmUgam9icyBhbmQgZmFtaWxpZXMgYW5kIGxpdmVzOyBmb3IgbW9zdCBvZiB1cywgQWxw aW5lIGFuZA0KcmVsYXRlZCBvcGVuLXNvdXJjZSBwcm9qZWN0cyBhcmUgdGhpbmdzIHdlIGRvIGJl Y2F1c2Ugd2UgbGlrZSBkb2luZw0KdGhlbSwgYXMgYSBob2JieS4gIEkgd2lsbCBnbyBhaGVhZCBh bmQgZmlsZSB0aGUgYnVnIGluIHRoYXQgc2VjdGlvbg0KYW5kIGtlZXAgdGhhdCBpbiBtaW5kIGlm IEkgY29tZSBhY3Jvc3MgYW55IGluIHRoZSBmdXR1cmUuDQoNCg0KPj4gQWRkaXRpb25hbGx5LCBj aGFuZ2VzIG1hZGUgdG8gYWJ1aWxkIG9yIGFway10b29scyBhcmUgY3VycmVudGx5IA0KPj4gYmVp bmcgc2VudCB2aWEgR2l0SHViIHB1bGwgcmVxdWVzdHMuICBIb3dldmVyLCBub25lIG9mIHVzIGlu IA0KPj4gQWTDqWxpZSByZWFsbHkgd2FudCB0byB1c2UgR2l0SHViIGFzIGl0IGlzIGEgY2xvc2Vk IHBsYXRmb3JtLg0KPj4gVGhlIGFwb3J0cyBtYWlsaW5nIGxpc3QgZXhpc3RzIGZvciBhcG9ydHMs IGJ1dCB3aGVyZSBjb3VsZCB3ZQ0KPj4gc2VuZCBhYnVpbGQgb3IgYXBrLXRvb2xzIGNoYW5nZXMg aWYgd2Ugd2FudGVkIGFuIGFsdGVybmF0aXZlIHRvIA0KPj4gR2l0SHViPw0KPiANCj4gVGhlc2Ug a2luZCBvZiBjaGFuZ2VzIHNob3VsZCBiZSBzZW50IHRvIGFscGluZS1kZXZlbCBpZiB5b3UgZG8g bm90IA0KPiB3aXNoIHRvIHVzZSBHaXRIdWIuDQoNCg0KRHVseSBub3RlZC4gIEkgd291bGQgYXNr IGlmIHRoZXJlIGFyZSBhbnkgcGxhbnMgdG8gaW5zdGFsbCBzb21ldGhpbmcNCmxpa2UgR2l0TGFi LCBQYWd1cmUsIG9yIFBoYWJyaWNhdG9yIGZvciBBbHBpbmUgYXQgc29tZSBwb2ludCwgYnV0IEkN CmRvbid0IHJlYWxseSB3YW50IHRvIG9wZW4gc3VjaCBhIGNhbiBvZiB3b3JtcyA6KQ0KDQoNCj4+ IDQuIFdlIGhhdmUgbWFuYWdlZCB0byBtYWtlIGEgc3BsaXQgZnVuY3Rpb24gJ29wZW5yYycgdGhh dCB0YWtlcyANCj4+IC9ldGMvaW5pdC5kIGFuZCAvZXRjL2NvbmYuZCBkaXJlY3Rvcmllcy4gIEl0 IGhhcyANCj4+IGluc3RhbGxfaWY9IiRwa2duYW1lIG9wZW5yYyIgc28gaXQgaXMgdHJhbnNwYXJl bnQgd2hlbiB5b3UgaGF2ZSANCj4+IE9wZW5SQyBpbnN0YWxsZWQsIGFuZCBhbGxvd3MgZnV0dXJl IG1pZ3JhdGlvbnMgdG8gYSBkaWZmZXJlbnQgDQo+PiBpbml0IHN5c3RlbS4gIEkgZG9uJ3Qga25v dyBpZiB0aGlzIGlzIG9mIGFueSBpbnRlcmVzdCB0byBBbHBpbmUuDQo+IA0KPiBJ4oCZZCBsaWtl IHRvIHNlZSB0aGlzLCB5ZXMuIEl0IHNlZW1zIGxpa2UgYSBnb29kIGFkZGl0aW9uIGluIGxpZ2h0 IA0KPiBvZiB0aGUgdGhpbmdzIGRpc2N1c3NlZCBhdCBGT1NERU0gd2l0aCByZWdhcmRzIHRvIGlu aXQgc3lzdGVtcy4NCg0KDQpJIHdpbGwgc2VuZCB0aGUgcGF0Y2ggdG8gdGhpcyBsaXN0IGxhdGVy IHRvZGF5LiAgSXQgaXMgdmVyeSBzaW1pbGFyIHRvDQp0aGUgZG9jIHNwbGl0IGZ1bmN0aW9uLCBz byBob3BlZnVsbHkgaXQgaXMgYWNjZXB0YWJsZS4gIElmIGl0IGlzDQphY2NlcHRlZCwgSSB3aWxs IGdsYWRseSBmb3J3YXJkIG9uIHRoZSBwYWNrYWdlcyB0aGF0IEkgaGF2ZSBhbHJlYWR5DQpzcGxp dCBvdXQgLW9wZW5yYyBmb3IgQWTDqWxpZS4NCg0KDQo+PiA1LiBBZnRlciBiZWluZyBhbm5veWVk IGJ5IGJ1Z3MgaW4gdGhlIFBvd2VyUEMgYnVpbGQgb2YgR05VIHRhciwgDQo+PiB3ZSBtYW5hZ2Vk IHRvIHN3YXAgb3V0IC91c3IvYmluL3RhciBmb3IgYnNkdGFyIHByb3ZpZGVkIGJ5IA0KPj4gbGli YXJjaGl2ZSBpbiBhYnVpbGQuICBJdCBuZWVkZWQgYSBwYXRjaCB0byBvdXRwdXQgdGhlIGZvcm1h dA0KPj4gYXBrIGV4cGVjdHMgYnkgZGVmYXVsdCwgYnV0IG90aGVyd2lzZSBpdCBzZWVtcyB0byB3 b3JrIHF1aXRlDQo+PiB3ZWxsLiBUaGlzIG1heSBiZSBvZiBpbnRlcmVzdCB0byB0aG9zZSB3aG8g d2FudCB0byBkbyBhIEdOVS1mcmVlDQo+PiBBbHBpbmUgc3Bpbi4NCj4gDQo+IEnigJltIG5vdCBw ZXJzb25hbGx5IGludGVyZXN0ZWQgaW4gYnNkdGFyIGFzIEkgY29uc2lkZXIgbGliYXJjaGl2ZSAN Cj4gZmFpcmx5IGJsb2F0ZWQsIGJ1dCBpZiB0aGUgcGF0Y2ggaXMgYmFja3dhcmRzLWNvbXBhdGli bGUgd2l0aCBHTlUgDQo+IHRhciBJIHdvdWxkIHNlZSBubyBpc3N1ZSB3aXRoIGluY2x1ZGluZyBp dCBhdCBhbGwuDQoNCg0KVGhlIHBhdGNoIGlzIG5vdCBmb3IgYWJ1aWxkLiAgSXQgaXMgZm9yIGxp YmFyY2hpdmUgaXRzZWxmLiAgUmVuYW1pbmcNCmJzZHRhciB0byB0YXIgaXMgc3VmZmljaWVudCBm b3IgYWJ1aWxkIHRvIHVzZSBpdC4NCg0KDQo+IEhvcGUgdGhpcyBoZWxwZWQgYSBiaXQsIC0gU2hp eg0KPiANCg0KDQpJdCBkaWQgaW5kZWVkLiAgVGhhbmsgeW91IHZlcnkgbXVjaCENCg0KDQpBbGwg dGhlIGJlc3QsDQotIC0tYXJ3DQoNCi0gLS0gDQpBLiBXaWxjb3ggKGF3aWxmb3gpDQpQcm9qZWN0 IExlYWQsIEFkw6lsaWUgTGludXgNCmh0dHA6Ly9hZGVsaWVsaW51eC5vcmcNCi0tLS0tQkVHSU4g UEdQIFNJR05BVFVSRS0tLS0tDQpWZXJzaW9uOiBHbnVQRyB2Mg0KDQppUUljQkFFQkNBQUdCUUpa ZGhBeEFBb0pFTXNweTFHU0s1MFVZczhQLzNLc2RkSmJEYjFHKzl2Zkt2c1VwdHlwDQorU2d6c3hN S01mcXZaRzRtQnJnRnhVTjYxcnliVDB2b0ZjTENaclVHdmVveEhpaWIvSVVCckh3Z1BsdkRDSVZR DQpqaWt1blB1Y3BXT2ZJU0ZkQ1dFL3RwaFpDWmZyV1hrZlBBR3RFN1labFlWNmdWdS9Va2Z4bUNi U3gzSnpYQW5nDQpzcUl1Z3VQNVNtQk5qN1JXRlU5cVpuTGhUM2N3NkVNREp3RXozNnRmY3Zoa0dI VHd4cjRyQ3RXdmJ0R2tUUUJNDQpJRUdLL1ZXQTRNYXVCM3A2dmdlQVBSWlRPWHVLUkJLL2tPdDRl R1FVaDR2TlpwNTVFc1NpYVJoY3JoWktFeFo3DQpEdkY2NkFmdFVXVUo5VkU3cXBkbTFkWUJZdVNx RDIxb29YemVLV2lBZmNZZ21tc1VxUTJ1K2JKOEZ3SGNPa0ZWDQpRd1RSbWZ0NGtoSmxRR0xMOWVP dHZMNzh6bU1LWGJuajlXQzNUTnZnN3drVERlZ1NENXVNb1J0QjlqczRaa3E1DQpUTUhNTTJ4dkJI cHB1bkl2ZjhUaGxLa0NqZkVZbHlPUjNGYkN3VzRmRGNWNUVoK1NlZnYxRkUrMkZKZlBJdTkwDQpU b3lHRkhhNkttV1krcmdQNEc4ZWEyUFZpNTBTYzZlL0krRGVjQTM1TS8rWlRYemd1K3dwRkRKVzJG T2dncllsDQoyVlJhQjN4aHZ3YkNxYkZYTGt3K0hkRk1aaG5lNUkvUDloK25uZEt1dFdCVE54L3dG YVAxcFBRcXJOMlQyQXkrDQpvRDh0blVYWGtocG14MVY0RnY4S1lEbW4vWUpSa0ZjYmR2MVVDMjNi TFVEUk5zY21iaEw2ZGt6UkgxZUdNUlp4DQpqK2FZbyt1S0tGSjc3MXJrbkdXRg0KPUY2N2sNCi0t LS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0KDQoNCi0tLQ0KVW5zdWJzY3JpYmU6ICBhbHBpbmUt ZGV2ZWwrdW5zdWJzY3JpYmVAbGlzdHMuYWxwaW5lbGludXgub3JnDQpIZWxwOiAgICAgICAgIGFs cGluZS1kZXZlbCtoZWxwQGxpc3RzLmFscGluZWxpbnV4Lm9yZw0KLS0tDQo= From nobody Thu Mar 28 17:59:51 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com [209.85.220.171]) by lists.alpinelinux.org (Postfix) with ESMTP id BDBE45C4C64 for ; Tue, 25 Jul 2017 05:17:16 +0000 (GMT) Received: by mail-qk0-f171.google.com with SMTP id k2so24764089qkf.0 for ; Mon, 24 Jul 2017 22:17:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dereferenced-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dEHYUTCheAmmXbzEy/LNXRrpLMBwCiCi5uJa2hKDUog=; b=NbAbgf7E3vou+ODI/maF+qq1yX99K37Bbsl+HBOWvGlIMN2gplbxCzzV6vrPLv4wJ+ VKrthIZDjcHJ8PogxfWa4wsu423rHBEY3WSof54gowi7/qTXx2rbRVaO8z0YHPw28xWr O1K+tdwBzdv7LYkIuAEEnr3ZwGtbXbFbVAF0CuaROiOhxNhJwnN5iihwwJbjVqIXoSU+ VhLX1/6wAE2neaFuxAkA0mkyWPWgN7YHRWHpi6O/eZIOk59oz53e3AHvb9GoTQ/XYL5h cnKxmPNJxruqPGfGWvKkelFLxDW5I2nVJdSXghbCBhXO5fdxGqqfmsb+sKR/wJNCXtDd hpbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dEHYUTCheAmmXbzEy/LNXRrpLMBwCiCi5uJa2hKDUog=; b=aCMVtL2SCoqiiIp0dh/+Uxu5V3CF52ChB0Jq2tPTr7p3znxQgzEYrEnPalPN0m8joL 5SE6N2NBn1j7x726gjz02n0cslvD5Y8P1Sz7q76dZzrn6wWJnSxn9YtdOKLYbA1pmrKk pW1Nc9e1tdMoBoWV2xTpjkp3NkJTiuyWj5+ECumt8Z9h3UcTLCHO463OwvmxOi+ZM5b4 8MXB7Bt0TqAwnRkqq7mmvytoHoRkuMTkB12NtJm0VqySdiPAdvl41kx2ipRnI/x9z5hx RwqNKcLxb8AkawhdgHwATEDFNLAE3a8oQ6v1CTtsbq8bJkNT0aFakD6531fk6YnDSRQs QO8Q== X-Gm-Message-State: AIVw111fo+lHMOoI2VXt/1+mTwTB6wBVIt/sx5SavSiLXtLbUKjXpbJl S54Dg3s8jcIpzLjtWDA+fM+xfi102Q7w X-Received: by 10.55.119.131 with SMTP id s125mr20963050qkc.255.1500959836051; Mon, 24 Jul 2017 22:17:16 -0700 (PDT) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Received: by 10.200.46.10 with HTTP; Mon, 24 Jul 2017 22:17:15 -0700 (PDT) In-Reply-To: <59761031.6000605@adelielinux.org> References: <5975E0C0.1030008@adelielinux.org> <57A1A151-0352-40DA-BC91-52980CEE99C3@shiz.me> <59761031.6000605@adelielinux.org> From: William Pitcock Date: Tue, 25 Jul 2017 00:17:15 -0500 Message-ID: Subject: =?UTF-8?Q?Re=3A_=5Balpine=2Ddevel=5D_Ad=C3=A9lie_on_Alpine=2C_two_months_lat?= =?UTF-8?Q?er?= To: "A. Wilcox" Cc: Shiz , alpine-dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, On Mon, Jul 24, 2017 at 10:20 AM, A. Wilcox wrote= : >>> 2. The virtual system is pathetic. One of the very core tenets >>> of Ad=C3=A9lie is giving the user power through choice. That choice >>> is almost impossible to provide using the current abuild/apk >>> framework. I keep hearing of a Debian-style alternatives >>> system, and supposedly it was specified somewhere, but I cannot >>> find the specification nor an implementation. If I could read >>> the specification I would be highly motivated to write an >>> implementation. >> >> This is correct and something that has been bothering us for a >> while. A while back I wrote up a rough sketch of how such a system >> would function in APK, which is likely what you are referring to. >> It can be found here: https://txt.shiz.me/ZDNkNTY3MD.txt > > > This seems like a decent start. I like how you can select all > provided paths from a package or just a subset. This was actually > requested by one of our early alpha testers. > > Would the relocations database have *every* file, or only those in > conflict? I can see the argument either way. APK already stores all files available to it in the installed-db. Thusly, we would only need to store the redirections. I think this should be a component of apk-tools. >> I have no specific experience with apk-tools=E2=80=99s internals, but >> would be open to looking into them to see what=E2=80=99s needed, >> possibly/preferably with kaniini and fabled=E2=80=99s assistance and >> insights as well. > > > I have some experience with the internals of apk-tools, but not so > much the database portion. Perhaps that is a task for this weekend :) > > >> Something I=E2=80=99d like to see is file: dependencies (in the same vei= n >> as so:, but for full file paths), but that=E2=80=99d require encoding th= e >> entire file listing of a package in its `provides` metadata, which >> I=E2=80=99m not sure we want due to APKINDEX file size bloat. > > > I know that both Debian and Red Hat based systems have something like > this stored in another index; `apt-file` and `yum provides`. The > databases are somewhere around 100 MB compressed, so they obviously > are not a part of the standard installation of apt/yum, but they are > available to enable at any time for the users. I'm not sure if Alpine > would want to do something similar. One method would be to have some > sort of 'simplification' step when generating APKINDEX: only include > file: from the master file database when a package references it. For > example: > > depends=3D"file:/usr/bin/awk" > > would cause every `awk` provider to have a provides: line in APKINDEX > for file:/usr/bin/awk. They wouldn't need to have a provides: for > every file, only the ones that other packages reference. This would severely bloat the APKINDEX. We should probably not do this. >>> I started to try and make 'v:mta' but I'm very concerned about >>> diverging so much from the Alpine aports tree. Also, apk doesn't >>> support an automatic choice for a virtual if the user hasn't >>> already installed one (something like replaces_priority but for >>> virtuals would be good here imo). That means that when I *do* >>> manage to get packages to depend on v:mta, the user now has to >>> read through an 'unsatisfiable constraints' error and pick a >>> package out of the list of providers. >> >> I=E2=80=99m not sure what the best way to approach this would be in the >> system sketch I laid out above. > > > The above-linked specification doesn't resolve this in any way. > That's fine because it doesn't need to. That can be a separate > discussion / specification. (APK is already deficient in that regard, > so it should be fixed independently of adding an alternatives system, > IMO.) This could probably be solved by 'preference levels'. The package with the highest preference level and lowest depgraph solution cost would be selected. >>> 3. It is very hard to know where to send some things. For >>> example, the GCC APKBUILD does not function properly right now: >>> it does not declare a makedepends on gcc-gnat, and the GCC >>> configure process bails out when it does not find it because >>> LANG_ADA is true whenever CBUILD =3D=3D CHOST =3D=3D CTARGET. >> >> This would be a bug against aports in the bug tracker. Generally >> most of us are somewhat busy, especially considering the time of >> the year. Pinging specific people can work however =E2=80=94 don=E2=80= =99t take >> our lack of response as lack of interest. :) > > > I never took it as a lack of interest. I know that people are busy > and have jobs and families and lives; for most of us, Alpine and > related open-source projects are things we do because we like doing > them, as a hobby. I will go ahead and file the bug in that section > and keep that in mind if I come across any in the future. > > >>> Additionally, changes made to abuild or apk-tools are currently >>> being sent via GitHub pull requests. However, none of us in >>> Ad=C3=A9lie really want to use GitHub as it is a closed platform. >>> The aports mailing list exists for aports, but where could we >>> send abuild or apk-tools changes if we wanted an alternative to >>> GitHub? >> >> These kind of changes should be sent to alpine-devel if you do not >> wish to use GitHub. > > > Duly noted. I would ask if there are any plans to install something > like GitLab, Pagure, or Phabricator for Alpine at some point, but I > don't really want to open such a can of worms :) > > >>> 4. We have managed to make a split function 'openrc' that takes >>> /etc/init.d and /etc/conf.d directories. It has >>> install_if=3D"$pkgname openrc" so it is transparent when you have >>> OpenRC installed, and allows future migrations to a different >>> init system. I don't know if this is of any interest to Alpine. >> >> I=E2=80=99d like to see this, yes. It seems like a good addition in ligh= t >> of the things discussed at FOSDEM with regards to init systems. > > > I will send the patch to this list later today. It is very similar to > the doc split function, so hopefully it is acceptable. If it is > accepted, I will gladly forward on the packages that I have already > split out -openrc for Ad=C3=A9lie. Once sent over, I see no reason why it wouldn't be accepted. >>> 5. After being annoyed by bugs in the PowerPC build of GNU tar, >>> we managed to swap out /usr/bin/tar for bsdtar provided by >>> libarchive in abuild. It needed a patch to output the format >>> apk expects by default, but otherwise it seems to work quite >>> well. This may be of interest to those who want to do a GNU-free >>> Alpine spin. >> >> I=E2=80=99m not personally interested in bsdtar as I consider libarchive >> fairly bloated, but if the patch is backwards-compatible with GNU >> tar I would see no issue with including it at all. > > > The patch is not for abuild. It is for libarchive itself. Renaming > bsdtar to tar is sufficient for abuild to use it. Lets go ahead and integrate this patch, I suppose. William --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org --- From nobody Thu Mar 28 17:59:51 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mailauth4.nine.ch (mailauth4.nine.ch [94.230.211.190]) by lists.alpinelinux.org (Postfix) with ESMTP id BF09F5C3482 for ; Mon, 24 Jul 2017 19:50:43 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by mailauth4.nine.ch (Postfix) with ESMTP id 31C2FC01B3; Mon, 24 Jul 2017 21:50:42 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mailauth4.nine.ch X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5.6 tests=[ALL_TRUSTED=-1] autolearn=disabled Received: from mailauth4.nine.ch ([127.0.0.1]) by localhost (mailauth4.nine.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhC7J2y8KvC4; Mon, 24 Jul 2017 21:50:41 +0200 (CEST) Received: from vimes (174.180.4.85.dynamic.wline.res.cust.swisscom.ch [85.4.180.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pf@1042.ch) by mailauth4.nine.ch (Postfix) with ESMTPSA; Mon, 24 Jul 2017 21:50:41 +0200 (CEST) Received: by vimes (Postfix, from userid 1000) id F0A91808C3; Mon, 24 Jul 2017 21:50:40 +0200 (CEST) Date: Mon, 24 Jul 2017 21:50:40 +0200 From: Jean-Louis Fuchs To: "A. Wilcox" Cc: alpine-devel@lists.alpinelinux.org Subject: Re: [alpine-devel] =?iso-8859-1?Q?Ad=E9li?= =?iso-8859-1?Q?e?= on Alpine, two months later Message-ID: <20170724195040.GA18090@vimes.1042.ch> References: <5975E0C0.1030008@adelielinux.org> <57A1A151-0352-40DA-BC91-52980CEE99C3@shiz.me> <59761031.6000605@adelielinux.org> X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline In-Reply-To: <59761031.6000605@adelielinux.org> User-Agent: Mutt/1.8.3 (2017-05-23) --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi On Mon, Jul 24, 2017 at 10:20:17AM -0500, A. Wilcox wrote: > Duly noted. I would ask if there are any plans to install something > like GitLab, Pagure, or Phabricator for Alpine at some point, but I > don't really want to open such a can of worms :) http://patchwork.alpinelinux.org/project/aports/list/ Alpine uses patchwork, which is a great tool developed at ozlabs. Patchwork 2.0 will support RESTAPI events, so you can plugin almost anything into patchwork (Jenkins for example). I love the mailinglist/patchwork approach, because I am a hopeless minimalist (using only terminal programs and a browser). I hope Alpine will continue into build into that direction. I have use GitHub a lot, while disliking it for various reasons. Best, Jean-Louis --+QahgC5+KEYLbs62 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEEfg6heaevSn5VXbPVQ5WfaECIbUUFAll2T41fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDdF MEVBMTc5QTdBRjRBN0U1NTVEQjNENTQzOTU5RjY4NDA4ODZENDUACgkQQ5WfaECI bUVVXA/+LReC4yWtia3TJNsiKFdC9Y2WqwTCWocxcHDd0EFjZUwQNq+YuKtfOmgz CwHJtRlGcvAqEScmabguxZR0ntX8pRuOgLUDMFmQQnUVvdjOKFssXmiju7lYkewI WPS17sVPw59pM5+4XXJeO2H1rvZpfmObkL54nv1yOdbuqBvJHLHvrZBB2dSnRBP9 cp+5w9JpIKQcGU62iWekqI04lhUDj3844bLIGSaDy+qjwgnwzTrNnHgQI8ZgBBDr BxnYORKZETBWne6W3jSmUfQQJK6E645hHCCYtmGS++sqxFC17FByPIQCu9yhbmUM 0/LazxULZx3zWSuqwC43wv3FueqcwefeuX3jSAPvbsU2J1hOAgpvURk1FhXNFWFj X9bp3Xjky273oIwlTnkB8s3LCE7KmyLNdCCOPGIEZTvywP0cq1L0l3ifnlw/kkAv jQJuKJVekLtFd/v1xgYfeR2dbue28tFTf+3fzY0H6TGQ1/M1NqTVaItwYHggt7g/ Zn0XsKT6Xs23ScOu1PVcBnnKKyRqjQppS0rZxKmK3R47kBYbvj+twY30sTd8TEFN YC9+ARakjFDJwV0q3Ph1eoEnl1vcgrWnZffxl8KokJRYDxwlper1BjBsJrQKl3q4 HV1JukYWOsrpIpOzdrc3KWCOo/ROmOIAGnjv1fhEOV0kGddFKiA= =sSfw -----END PGP SIGNATURE----- --+QahgC5+KEYLbs62-- --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org --- From nobody Thu Mar 28 17:59:51 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Received: from luna.geeknet.cz (luna.geeknet.cz [37.205.9.141]) by lists.alpinelinux.org (Postfix) with ESMTP id 221FA5C4C50 for ; Mon, 24 Jul 2017 20:46:46 +0000 (GMT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by luna.geeknet.cz (Postfix) with ESMTPSA id EB45E524BF; Mon, 24 Jul 2017 22:46:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jirutka.cz; s=mail; t=1500929204; bh=zeb73p/Ug4660T1vL3yFTFkCBTsCZ2kWP3Ax0+P2BU4=; h=Subject:From:In-Reply-To:Date:References:To; b=n7zEQLWJoS5HfIBRsiqoaS6ZC5dGj97qeImAuY4xbAQgp1matIzxeWvvMBDzQeb9/ 3TFkrOtkgn5Uz93fiL8uloYTekNTinKuvDvncqVGyeWJb2Zn3Gps0Oq/altMXZBCdd 934x9+XtPmrI5aHSbo6H+7Dfbo0ILOkvCUotIGL8= Content-Type: text/plain; charset=utf-8 X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: =?utf-8?Q?Re=3A_=5Balpine-devel=5D_Ad=C3=A9lie_on_Alpine=2C_two_?= =?utf-8?Q?months_later?= From: Jakub Jirutka In-Reply-To: <20170724195040.GA18090@vimes.1042.ch> Date: Mon, 24 Jul 2017 22:46:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5301B93A-A3AA-4AD3-8191-EBA542A6C3D3@jirutka.cz> References: <5975E0C0.1030008@adelielinux.org> <57A1A151-0352-40DA-BC91-52980CEE99C3@shiz.me> <59761031.6000605@adelielinux.org> <20170724195040.GA18090@vimes.1042.ch> To: Alpine-devel , Jean-Louis Fuchs HI, I strongly disagree that Patchwork is a great tool, at least the current = version we have. I can=E2=80=99t imagine something that can be worse, less productive = than Patchwork. It=E2=80=99s more or less just bad a web UI for mailbox. = There=E2=80=99s no clear relation between related patches, =E2=80=99cause = it=E2=80=99s just nearly impossible to reconstruct such information from = separated patches in mail. It=E2=80=99s simply not possible to set any = reasonable integration with CI on top of this. Not even talking about = its =E2=80=9Csupport=E2=80=9D for code-reviews, that is more or less = non-existing. Patchwork is based on ancient workflow from CVS era. Pull/Merge request, = the feature in GitHub, GitLab and other git-based tools, is proper = git-way. It starts and ends with git. You create new branch in your = clone of the repository, push some commits and opens a pull request = (this can be done from CLI ofc, but well only via vendor-specific API). = On git level, pull request is a reference in the target git repository. = Maintainer can work with it directly via git (see = https://gist.github.com/piscisaureus/3342247), without leaving terminal. = When the contributor push new changes to the pull request, maintainer = can simply pull them via git and view in context, it=E2=80=99s just a = branch. Comments on pull requests are unfortunately not stored in git (they can = be, but GH/GL don=E2=80=99t do that), so this happens outside of git = (yet still can work with it from CLI). I=E2=80=99m one of the Alpine devs who interacts with user contributions = the most. I don=E2=80=99t use our Patchwork at all, because it=E2=80=99s = unreasonable waste of my time to work with such bad tool. Mostly for = lack of CI integration, but not just that. It=E2=80=99s really horrible = for reviews. I understand that it may be quite comfortable for = contributors (that don=E2=80=99t know git), but I believe that only to = the moment when changes are requested. I understand why some ppl don=E2=80=99t like GitHub (it=E2=80=99s = third-party commercial service after all), but what I really don=E2=80=99t= understand is how can anyone say minimalism and Mailing-List/Patchwork = in one sentence. Have you ever considered the =E2=80=9Cmail=E2=80=9D = part of it? Mails are insanely complex nowadays. Sorry for grammar, I wrote it in hurry. Jakub > On 24. Jul 2017, at 21:50, Jean-Louis Fuchs = wrote: >=20 > Hi >=20 > On Mon, Jul 24, 2017 at 10:20:17AM -0500, A. Wilcox wrote: >> Duly noted. I would ask if there are any plans to install something >> like GitLab, Pagure, or Phabricator for Alpine at some point, but I >> don't really want to open such a can of worms :) >=20 > http://patchwork.alpinelinux.org/project/aports/list/ >=20 > Alpine uses patchwork, which is a great tool developed at ozlabs. > Patchwork 2.0 will support RESTAPI events, so you can plugin almost > anything into patchwork (Jenkins for example). I love the > mailinglist/patchwork approach, because I am a hopeless minimalist > (using only terminal programs and a browser). I hope Alpine will > continue into build into that direction. >=20 > I have use GitHub a lot, while disliking it for various reasons. >=20 > Best, > Jean-Louis --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org --- From nobody Thu Mar 28 17:59:51 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mailauth4.nine.ch (mailauth4.nine.ch [94.230.211.190]) by lists.alpinelinux.org (Postfix) with ESMTP id 5D9175C4C56 for ; Mon, 24 Jul 2017 21:46:11 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by mailauth4.nine.ch (Postfix) with ESMTP id 4B785BFC50; Mon, 24 Jul 2017 23:46:10 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mailauth4.nine.ch X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5.6 tests=[ALL_TRUSTED=-1] autolearn=disabled Received: from mailauth4.nine.ch ([127.0.0.1]) by localhost (mailauth4.nine.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaVSuA45ydDb; Mon, 24 Jul 2017 23:46:09 +0200 (CEST) Received: from vimes (174.180.4.85.dynamic.wline.res.cust.swisscom.ch [85.4.180.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pf@1042.ch) by mailauth4.nine.ch (Postfix) with ESMTPSA; Mon, 24 Jul 2017 23:46:09 +0200 (CEST) Received: by vimes (Postfix, from userid 1000) id 1BEB3808C3; Mon, 24 Jul 2017 23:46:09 +0200 (CEST) Date: Mon, 24 Jul 2017 23:46:09 +0200 From: Jean-Louis Fuchs To: Jakub Jirutka Cc: Alpine-devel Subject: Re: [alpine-devel] =?iso-8859-1?Q?Ad=E9li?= =?iso-8859-1?Q?e?= on Alpine, two months later Message-ID: <20170724214609.GB18090@vimes.1042.ch> References: <5975E0C0.1030008@adelielinux.org> <57A1A151-0352-40DA-BC91-52980CEE99C3@shiz.me> <59761031.6000605@adelielinux.org> <20170724195040.GA18090@vimes.1042.ch> <5301B93A-A3AA-4AD3-8191-EBA542A6C3D3@jirutka.cz> X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TRYliJ5NKNqkz5bu" Content-Disposition: inline In-Reply-To: <5301B93A-A3AA-4AD3-8191-EBA542A6C3D3@jirutka.cz> User-Agent: Mutt/1.8.3 (2017-05-23) --TRYliJ5NKNqkz5bu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Jakub On Mon, Jul 24, 2017 at 10:46:44PM +0200, Jakub Jirutka wrote: > I strongly disagree that Patchwork is a great tool, at least the > current version we have. In the end the process/tools has to fit the most active commiters, not non-commiters like me. Since you are a power-user, know better then I. I am someone who likes "git send-email" and mailinglists. For me patchwork is more or less the tool that creates RESTAPI events from a patch-mailinglist (not in alpine though). I also use GitLab a lot and like it a lot. I just wanted to say that a minimalistic approach (meaning simple tools like git send-email + a mailinglist), is liked by a non-commiter like me and I know commiters in other projects who like it too. But as I said, the process has to be optimized for the active commiters. And I guess I am strange and a exception, since I prefer TUIs to GUIs. Best, Jean --TRYliJ5NKNqkz5bu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEEfg6heaevSn5VXbPVQ5WfaECIbUUFAll2ap5fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDdF MEVBMTc5QTdBRjRBN0U1NTVEQjNENTQzOTU5RjY4NDA4ODZENDUACgkQQ5WfaECI bUXCzxAAnZcIvLcxsaeAawxucZreO4YXYUWK66LQFZ+EUM3eesMXSpMmcsVdTtNP +aAOOQn1ZEytxXIQqr1kBpltUn3u70EjHgDw2Qt4Wu5JEUNAGrXMPeDDtUHX4cea gBkNVAemm7+FcwMGHJ+njoAo7iBboUWxJUn7CW6qcNxJi/fAfD+svnxZ1+nexVsL BcPpc9Ct9pVcOgXMKP98Hds1wPxIAUN24tGmgww8+LX2CSkiXG0VyWox0BXA+1pi P/GYvDC5yGWINUDmOidUS9UKg9Leq555nWrjDNTgzEBFROXXmJBsFLSyWpt8wOYV dPjhOnzhM5qV6O8a3O4rWM8O79746qIKRk4x5yGG04U1Vfajz0t4TPiCwscumWLv R2b2rWScyVBtyQf8Sef7yt1gEeIX9ur1gnM+2yrK0TxE/S2agKDisMQvt/Dq7qPd SpL1ZNBdaJpXvZPHbbx8uwD0CYwmsYXaEQWn6wX8+Awm6894EEeEVpiN7vJiqF8U xkO++9Yoymrf1kLV2L1VozmQrE65ZMxLzS1Cv5OOXKJwTWWUkFnA4Xgyhs1oL0r2 jJ8CRv182rKv0ZLKy5oYZq1Gsrp42V7oPcrPULMPecvHb9d0Z1NuD+7uLA0gYvmZ 8EkaTqHqn54Q9W0+IyMKf0ieNf+HURjUwrwDyEpT2ilW6ty4mtU= =lSWD -----END PGP SIGNATURE----- --TRYliJ5NKNqkz5bu-- --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org --- From nobody Thu Mar 28 17:59:51 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Received: from luna.geeknet.cz (luna.geeknet.cz [37.205.9.141]) by lists.alpinelinux.org (Postfix) with ESMTP id A909E5C4C60 for ; Mon, 24 Jul 2017 22:31:14 +0000 (GMT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by luna.geeknet.cz (Postfix) with ESMTPSA id 2F6D052C5F; Tue, 25 Jul 2017 00:31:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jirutka.cz; s=mail; t=1500935473; bh=J620RSq1SPLZLGIo+dXSIUZXRi1EDh1UIGHECOyN+sQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=H1gpGDxM4pxbuQouKgs0jyA52GWfJWK78aKalB7E1WRLyDt8UKGW7mU3jcwxPnRJS 3nDW3F7mcGeIHa3wT/DWRWd0EsiqNxr2i/ZDkqnQV4tTXx+Pyw7u6x7KYsbu+RXJ2a WaMz83OoMa/QkBBkDxk2mjyzVd93BZ5nu8RMaUm0= Content-Type: text/plain; charset=utf-8 X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: =?utf-8?Q?Re=3A_=5Balpine-devel=5D_Ad=C3=A9lie_on_Alpine=2C_two_?= =?utf-8?Q?months_later?= From: Jakub Jirutka In-Reply-To: <20170724214609.GB18090@vimes.1042.ch> Date: Tue, 25 Jul 2017 00:31:11 +0200 Cc: Alpine-devel Content-Transfer-Encoding: quoted-printable Message-Id: <2E417C1D-0F8D-4DBD-B283-5C5798D13D81@jirutka.cz> References: <5975E0C0.1030008@adelielinux.org> <57A1A151-0352-40DA-BC91-52980CEE99C3@shiz.me> <59761031.6000605@adelielinux.org> <20170724195040.GA18090@vimes.1042.ch> <5301B93A-A3AA-4AD3-8191-EBA542A6C3D3@jirutka.cz> <20170724214609.GB18090@vimes.1042.ch> To: Jean-Louis Fuchs Hi Jean, > I just wanted to say that a minimalistic approach (meaning simple = tools like git send-email + a mailinglist)=E2=80=A6 git send-email is indeed minimalistic, but mailing-list is really not. > And I guess I am strange and a exception, since I prefer TUIs to GUIs. Actually you=E2=80=99re not, many Alpinists prefer TUIs to GUIs, = including myself. What I wanted to say is that pull requests workflow is = even more suitable for TUIs than ML. You can use tools like = https://hub.github.com/ + plain git or build your own tools suitable for = your workflow, without need to deal with bunch of unstructured = information in emails. > =E2=80=A6is liked by a non-commiter like meand I know commiters in = other projects who like it too. =E2=80=A6the process has to be optimized = for the active commiters=E2=80=A6 Well, we need to optimize the process for maintainers, active = contributors and even less active / new contributors like you. That=E2=80=99= s one of the reasons why we still support both GitHub and Patchwork. I admit that I=E2=80=99d personally love to get rid of Patchwork, but = 1st others don=E2=80=99t allow me to do that, 2st no one, including = myself, wants to depend on third-party service as the only option. = Currently we don=E2=80=99t have any sane alternative (simple, = lightweight yet powerful). We know that the current process is not = ideal, but there are too many issues and too little time=E2=80=A6 About GitLab, I know it very well and it makes me very sad what insane = bloatware it became after years. Complex beasts rules the world, not = many people value simplicity. Best regards, Jakub > On 24. Jul 2017, at 23:46, Jean-Louis Fuchs = wrote: >=20 > Hi Jakub >=20 > In the end the process/tools has to fit the most active commiters, not > non-commiters like me. >=20 > Since you are a power-user, know better then I. I am someone > who likes "git send-email" and mailinglists. For me patchwork is more > or less the tool that creates RESTAPI events from a patch-mailinglist > (not in alpine though). I also use GitLab a lot and like it a lot. >=20 > I just wanted to say that a minimalistic approach (meaning simple > tools like git send-email + a mailinglist), is liked by a non-commiter > like me and I know commiters in other projects who like it too. >=20 > But as I said, the process has to be optimized for the active > commiters. And I guess I am strange and a exception, since I prefer > TUIs to GUIs. >=20 > Best, > Jean --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org --- From nobody Thu Mar 28 17:59:51 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mail-qt0-f181.google.com (mail-qt0-f181.google.com [209.85.216.181]) by lists.alpinelinux.org (Postfix) with ESMTP id 4E6B85C4FD2 for ; Tue, 25 Jul 2017 05:23:35 +0000 (GMT) Received: by mail-qt0-f181.google.com with SMTP id s6so32505948qtc.1 for ; Mon, 24 Jul 2017 22:23:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dereferenced-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=WzQoukTGoev8WYhhsrUqUbXa/qy3pM4PJAPPc5wL6OI=; b=OZ10BKkpR9/PuJl5apm92S6ASLlSv7bThljGZgyn8ELXPkBxwaUJPOv5EBwoJks34T AakypimoM++eoHnhSUUiO0SqaAwyLQGxphes7aYCzFWnzcOZ0t7Sa0SQ0N4qYEu3qDFG /zvEhvAFFnt5Q2QGy2O6WXV8k4bXwZVav50l4MJoEXahJvqQBBhkeGk66FaY9uJk1feP N7YftJTT3vv4LlXzFHXexrMHaHEdCK0oKIew8r/+NQmAuEhf0C4yPF3RxHAHCrVxq6mA Pyqa02y9wg9i2zqDfEfREVahw24S2HUJbugXyrswLNOHaqG0YX4h6DjgSGNpp2UFIMnO NTOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=WzQoukTGoev8WYhhsrUqUbXa/qy3pM4PJAPPc5wL6OI=; b=hke+bAmmpqLMqb9ZxE+Y2tof80HFIx9NVamjl2WMQirknyMoGdbGjyJJkaE1pdd15I EGL9n+6TfuXeWfZ07gQWhUSgnpmCAyGVpaYLIRVB98pX2W7BB4LmfiKhcNz6a9h1RAXW rmXZUBtCHISBdiOXryStOTxAv31CbZXTPzhXer8UhUR37r82dCZtha3sNc+ABc95bfnb m6+Ium+sLsky6aSsRIJriO2cGWDwgrrJ2mMKR+diF7ZwgFEd6oOG0jrzxTrep46nw0bP wmqmbTRnKeYUc5pYTZYy8OEEI1fsSlO5RaXIinsR07QRE22cs/+TGIuvCfMqRZUwLl3n FETw== X-Gm-Message-State: AIVw111LxNiWYQTd15tcCwK6vq89iOhiparfP8tEunvdQbXq9bap5bgC QmYzG4afez/la+4J/h2oe5mLg3eE8MoB X-Received: by 10.200.2.65 with SMTP id o1mr25713484qtg.288.1500960214587; Mon, 24 Jul 2017 22:23:34 -0700 (PDT) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Received: by 10.200.46.10 with HTTP; Mon, 24 Jul 2017 22:23:34 -0700 (PDT) In-Reply-To: <2E417C1D-0F8D-4DBD-B283-5C5798D13D81@jirutka.cz> References: <5975E0C0.1030008@adelielinux.org> <57A1A151-0352-40DA-BC91-52980CEE99C3@shiz.me> <59761031.6000605@adelielinux.org> <20170724195040.GA18090@vimes.1042.ch> <5301B93A-A3AA-4AD3-8191-EBA542A6C3D3@jirutka.cz> <20170724214609.GB18090@vimes.1042.ch> <2E417C1D-0F8D-4DBD-B283-5C5798D13D81@jirutka.cz> From: William Pitcock Date: Tue, 25 Jul 2017 00:23:34 -0500 Message-ID: Subject: =?UTF-8?Q?Re=3A_=5Balpine=2Ddevel=5D_Ad=C3=A9lie_on_Alpine=2C_two_months_lat?= =?UTF-8?Q?er?= To: Jakub Jirutka Cc: Jean-Louis Fuchs , Alpine-devel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, On Mon, Jul 24, 2017 at 5:31 PM, Jakub Jirutka wrote: > Hi Jean, > >> I just wanted to say that a minimalistic approach (meaning simple tools = like git send-email + a mailinglist)=E2=80=A6 > > git send-email is indeed minimalistic, but mailing-list is really not. > >> And I guess I am strange and a exception, since I prefer TUIs to GUIs. > > Actually you=E2=80=99re not, many Alpinists prefer TUIs to GUIs, includin= g myself. What I wanted to say is that pull requests workflow is even more = suitable for TUIs than ML. You can use tools like https://hub.github.com/ += plain git or build your own tools suitable for your workflow, without need= to deal with bunch of unstructured information in emails. > >> =E2=80=A6is liked by a non-commiter like meand I know commiters in other= projects who like it too. =E2=80=A6the process has to be optimized for the= active commiters=E2=80=A6 > > Well, we need to optimize the process for maintainers, active contributor= s and even less active / new contributors like you. That=E2=80=99s one of t= he reasons why we still support both GitHub and Patchwork. > > I admit that I=E2=80=99d personally love to get rid of Patchwork, but 1st= others don=E2=80=99t allow me to do that, 2st no one, including myself, wa= nts to depend on third-party service as the only option. Currently we don= =E2=80=99t have any sane alternative (simple, lightweight yet powerful). We= know that the current process is not ideal, but there are too many issues = and too little time=E2=80=A6 I think our requirements are more specialised and I am wondering if it would be possible to build a simple application which merges the github PRs and patchwork patches in such a way that they can be tested. Once we have a solution to the CI problems, building such a site seems trivial to me. Debian has a similar website: mentors.debian.org, which does some checks on incoming contributions. Building something like that seems like something that would give us the best of all worlds, really. William --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org --- From nobody Thu Mar 28 17:59:51 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mail.wilcox-tech.com (mail.wilcox-tech.com [45.32.83.9]) by lists.alpinelinux.org (Postfix) with ESMTP id 358D75C4C56 for ; Tue, 25 Jul 2017 12:13:15 +0000 (GMT) Received: (qmail 27155 invoked from network); 25 Jul 2017 12:13:12 -0000 Received: from ip68-13-242-69.ok.ok.cox.net (HELO ?10.1.1.57?) (awilcox@wilcox-tech.com@68.13.242.69) by mail.wilcox-tech.com with ESMTPA; 25 Jul 2017 12:13:12 -0000 Subject: =?UTF-8?Q?Re:_[alpine-devel]_Ad=c3=a9lie_on_Alpine=2c_two_months_la?= =?UTF-8?Q?ter?= To: alpine-devel@lists.alpinelinux.org References: <5975E0C0.1030008@adelielinux.org> <57A1A151-0352-40DA-BC91-52980CEE99C3@shiz.me> <59761031.6000605@adelielinux.org> <20170724195040.GA18090@vimes.1042.ch> <5301B93A-A3AA-4AD3-8191-EBA542A6C3D3@jirutka.cz> <20170724214609.GB18090@vimes.1042.ch> <2E417C1D-0F8D-4DBD-B283-5C5798D13D81@jirutka.cz> From: "A. Wilcox" Organization: =?UTF-8?Q?Ad=c3=a9lie_Linux?= Message-ID: <597735D8.5030603@adelielinux.org> Date: Tue, 25 Jul 2017 07:13:12 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 In-Reply-To: <2E417C1D-0F8D-4DBD-B283-5C5798D13D81@jirutka.cz> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCk9uIDI0 LzA3LzE3IDE3OjMxLCBKYWt1YiBKaXJ1dGthIHdyb3RlOg0KPiBDdXJyZW50bHkgd2UgZG9u4oCZ dCBoYXZlIGFueSBzYW5lIGFsdGVybmF0aXZlIChzaW1wbGUsIGxpZ2h0d2VpZ2h0DQo+IHlldCBw b3dlcmZ1bCkuIFdlIGtub3cgdGhhdCB0aGUgY3VycmVudCBwcm9jZXNzIGlzIG5vdCBpZGVhbCwg YnV0DQo+IHRoZXJlIGFyZSB0b28gbWFueSBpc3N1ZXMgYW5kIHRvbyBsaXR0bGUgdGltZeKApg0K PiANCj4gQWJvdXQgR2l0TGFiLCBJIGtub3cgaXQgdmVyeSB3ZWxsIGFuZCBpdCBtYWtlcyBtZSB2 ZXJ5IHNhZCB3aGF0DQo+IGluc2FuZSBibG9hdHdhcmUgaXQgYmVjYW1lIGFmdGVyIHllYXJzLiBD b21wbGV4IGJlYXN0cyBydWxlcyB0aGUNCj4gd29ybGQsIG5vdCBtYW55IHBlb3BsZSB2YWx1ZSBz aW1wbGljaXR5Lg0KPiANCj4gQmVzdCByZWdhcmRzLCBKYWt1Yg0KPiANCg0KDQpIYXZlIHlvdSBs b29rZWQgaW4gdG8gUGFndXJlPyAgSXQgaXMgZGVzaWduZWQgdG8gYmUgYSBsaWdodHdlaWdodCBH aXQNCmZvcmdlLCBtYWRlIGJ5IHRoZSBGZWRvcmEgcGVvcGxlLiAgUmlnaHQgbm93IGl0IHN0aWxs IGhhcyBzb21lDQpGZWRvcmEtc3BlY2lmaWMgc3R1ZmYsIGJ1dCBEZWJpYW4gaGFzIGEgdGVzdGlu ZyBwYWNrYWdlIGZvciBpdCBhbmQgSSdtDQpob3BpbmcgdG8gdHJ5IGFuZCBtYWtlIGFuIEFscGlu ZSBwb3J0IGZvciBpdCBvbmNlIEkgbWFuYWdlIHRvIGhhdmUgYQ0KZGVza3RvcCBnb2luZy4NCg0K SXQgaXMgd3JpdHRlbiBpbiBQeXRob24gYnV0IGhhcyB2ZXJ5IGZldyBkZXBlbmRlbmNpZXM7IGp1 c3QgZmxhc2sNCihsaWdodHdlaWdodCBXZWIgZnJhbWV3b3JrKSwgcmVkaXMsIGFuZCBsaWJnaXQy LiAgSSBhbSB2ZXJ5IGhvcGVmdWwgdG8NCmhhdmUgaXQgcnVubmluZyBhcyBhIHJlcGxhY2VtZW50 IGZvciBvdXIgKEFkw6lsaWUpIEdpdExhYiBpbnN0YW5jZSBzb21lDQp0aW1lIGluIFE0IDE3IG9y IFExIDE4Lg0KDQoNCkFsbCB0aGUgYmVzdCwNCi0gLS1hcncNCg0KDQotIC0tIA0KQS4gV2lsY294 IChhd2lsZm94KQ0KUHJvamVjdCBMZWFkLCBBZMOpbGllIExpbnV4DQpodHRwOi8vYWRlbGllbGlu dXgub3JnDQotLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLQ0KVmVyc2lvbjogR251UEcgdjIN Cg0KaVFJY0JBRUJDQUFHQlFKWmR6WFJBQW9KRU1zcHkxR1NLNTBVWmFjUC8yaThTOTZIdXVxcGNK c1FJcEE5QWhCMw0KN0VSZFk4UWFiR1pnUXFXWkprYkU4NGNqUDlEbUpmNTAwWXNvUW9OUlVONHA3 MjlZaXpSYjhPREg5c1ZCYmVUZg0KRGpIVHVYVi9WN3YweUtJVmtOckJVcVAyY2VTc3haK0w3ajN1 TVM5U3YwTDMraTdiU05RaitNM0FZVHRpTzVMYg0KMWlaWnhwVmhxZUlCc01oTDRLY2t1MXdlVVJI eUxTSHNMa3FuZ1oxdDVXNXoyNmMyeFVsQlk3NlFDYlZpWVdZdg0KVnN3czNUeHZqVmlFdjRTTTgr amFGL3hENS9XOVFuOTVxaVUxdFc0ZU5qbXdjd2pYZUhUYlJSU3BMYmtBSkNaYQ0KSkVXQ1ZaOThD b3B1SXR1VFRrTUNwYTRXL1h1dTl5ME9zYkNLUHl1M1lqQ0Zic0xGNGpybldjWDZnSzIwb244TA0K UjI1L1ZjL1RBUTZxZnBPTml2cjdtZHdoMjBnMW9QdTBKQmErNnZ1VlFwcmF2REVKUU1sSTkydzhB OG93LzdYYg0KTVJWYVViNitCNmt1b1lZZ3VGUUpqMU5GL01udS81OHcwcTFyWUU5NnV1ZmtBQ005 L1daaVJmNEZ4MHIxZUFGVw0KdUZyMGwxaDgwVEUwUXBzOUtVK1FtTW9PZTJjakNzdzQ0UDZyUDFi ZUNpdm44ODM3cHVCRHNKWlE0czBsVTdILw0KOU5hdVhBdXlQOEpUNnEwUElmcDNYOUdoQUR5UHhW OS9NTzQvd1ZFNjZqelJVSXkvQlR3ODFmMFg0cVI2NzZSSw0KOHUwc2FKbUtWZnJtcXJsb0VPU3la Q0RIVXJuUXYwMHRVVzNFU3hmY1FPUDJWWkMwTmxyL3RzKzl1Y3NISVlYQw0KME9vN1l0MDBzcVNY UUI5T2NMVEINCj00NkQzDQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg0KDQotLS0NClVu c3Vic2NyaWJlOiAgYWxwaW5lLWRldmVsK3Vuc3Vic2NyaWJlQGxpc3RzLmFscGluZWxpbnV4Lm9y Zw0KSGVscDogICAgICAgICBhbHBpbmUtZGV2ZWwraGVscEBsaXN0cy5hbHBpbmVsaW51eC5vcmcN Ci0tLQ0K From nobody Thu Mar 28 17:59:51 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mx1.tetrasec.net (mx1.tetrasec.net [74.117.190.25]) by lists.alpinelinux.org (Postfix) with ESMTP id EB7B05C4C70 for ; Thu, 27 Jul 2017 10:55:43 +0000 (GMT) Received: from mx1.tetrasec.net (mail.local [127.0.0.1]) by mx1.tetrasec.net (Postfix) with ESMTP id 56E839E260D; Thu, 27 Jul 2017 10:55:43 +0000 (GMT) Received: from ncopa-desktop.copa.dup.pw (15.63.200.37.customer.cdi.no [37.200.63.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: n@tanael.org) by mx1.tetrasec.net (Postfix) with ESMTPSA id A4F3B9E2154; Thu, 27 Jul 2017 10:55:42 +0000 (GMT) Date: Thu, 27 Jul 2017 12:55:36 +0200 From: Natanael Copa To: "A. Wilcox" Cc: alpine-devel@lists.alpinelinux.org Subject: Re: [alpine-devel] =?ISO-8859-1?B?QWTpbGll?= on Alpine, two months later Message-ID: <20170727125536.16e0591d@ncopa-desktop.copa.dup.pw> In-Reply-To: <597735D8.5030603@adelielinux.org> References: <5975E0C0.1030008@adelielinux.org> <57A1A151-0352-40DA-BC91-52980CEE99C3@shiz.me> <59761031.6000605@adelielinux.org> <20170724195040.GA18090@vimes.1042.ch> <5301B93A-A3AA-4AD3-8191-EBA542A6C3D3@jirutka.cz> <20170724214609.GB18090@vimes.1042.ch> <2E417C1D-0F8D-4DBD-B283-5C5798D13D81@jirutka.cz> <597735D8.5030603@adelielinux.org> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-alpine-linux-musl) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 25 Jul 2017 07:13:12 -0500 "A. Wilcox" wrote: > Have you looked in to Pagure? It is designed to be a lightweight Git > forge, made by the Fedora people. Right now it still has some > Fedora-specific stuff, but Debian has a testing package for it and I'm > hoping to try and make an Alpine port for it once I manage to have a > desktop going. > > It is written in Python but has very few dependencies; just flask > (lightweight Web framework), redis, and libgit2. I sort of knew that they were replacing whatever they used before for hosted projects, but I had not looked to close to it. It does look pretty nice. python is nice (or at lease acceptable). A few comments on first impression: - Docs section is sluggish and I don't like that the scrollbar inside the page (iframe?) (https://pagure.io/docs/pagure/) - Releases says: "If the developers have upload one or more tarball(s), you will be able to find them in the release folder." I would like to automatically create the tarballs when you push a new git tag. I would likely switch right away if it had support for multi-gitbranch tickets. That is, you file a ticket, lets say a CVE, and mark off which git branches that needs to be fixed. When you git push a commit with "fixes issue #X" the marked branch will get "checked" or hooked off. Once all affected branches are fixed, the ticket is autoclosed. That would be the killer feature. -nc --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org --- From nobody Thu Mar 28 17:59:51 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mout.gmx.com (mout.gmx.com [74.208.4.201]) by lists.alpinelinux.org (Postfix) with ESMTP id 212235C502F for ; Mon, 24 Jul 2017 22:55:02 +0000 (GMT) Received: from [192.168.1.2] ([178.8.77.185]) by mail.gmx.com (mrgmxus001 [74.208.5.15]) with ESMTPSA (Nemesis) id 0LfSiF-1dyKPq1s7t-00p62x; Tue, 25 Jul 2017 00:54:51 +0200 Subject: =?UTF-8?Q?Re:_[alpine-devel]_Ad=c3=a9lie_on_Alpine=2c_two_months_la?= =?UTF-8?Q?ter?= To: Jean-Louis Fuchs , alpine-devel@lists.alpinelinux.org References: <5975E0C0.1030008@adelielinux.org> <57A1A151-0352-40DA-BC91-52980CEE99C3@shiz.me> <59761031.6000605@adelielinux.org> <20170724195040.GA18090@vimes.1042.ch> <5301B93A-A3AA-4AD3-8191-EBA542A6C3D3@jirutka.cz> <20170724214609.GB18090@vimes.1042.ch> From: 7heo <7heo@mail.com> Message-ID: <74c1d09b-3a2c-5023-0036-a8f067ddae37@mail.com> Date: Tue, 25 Jul 2017 00:54:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 In-Reply-To: <20170724214609.GB18090@vimes.1042.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:9TYk6bhJQYt+AOSKGRsdJ85DXe0JTXfvuPU10ndCE70ZRNPvPp/ RNVYTAP+JCF+iD7gYGpI5aQkRzoHy0bnAjFjqQ2pKeEQxix5stGscBCCD3g+vs/ADTjO1Dc 7Rui41QCGrYpqrGhlE2W4pdggXs7rZ+cD3mANNOTcoNEj94Ga6dA6eLiLWYTBzyy5iKd5+W 4pWf7W37esjc2erZehNsA== X-UI-Out-Filterresults: notjunk:1;V01:K0:pPaSo0nLsAo=:vHWl1WKLv6L2jYkMqdJ2De ho1ZsQNUAAkQ1G+NSj3oyjBeRnDZsruDcwifaXsmszbiDcsBIhaR6jawHojFzH6mwXMsz0ZTc BIOvm8ICxWWBSCx7DehXNaOK8i/pByBFoor0+tTibnHY0R9xwN5MwmKfvyu8C6FlHRKR7yz6W iPn6mFTTlH8KO3Ai5NCrfq94pmgg1llW8ORXqmKfoSO5Bulc6grpyL/occ1h2IcN8D11Cz+cB /kr58hj+8OxIkIdMmu/mo3x2A9q0ZbdW2MlHFWKnMHw04LyX/+au4bjMdfoGHphUBksJt5j4E L4v7+PoCzTaeyDbCsJj6kQ86M4+r/tk0LBBo7AtK5zXmAFlz1S0kfnryfvQWRRbEiFjeRBmZ7 Tvs8VVNxIljkzXwu9fercZ+dty5uvUd+CHTLzJkt4waVFMjWdEQ2DVq2QgGGuclPDqwLOhBHJ chYfz+uUDEj8GI2LM18Wu8aqxkekiUPAd0N6epIyGtebA07omL2frd/2AEszQA/AlZbRb28Qu iCciSRwdbKbQIKFbzDN6z9n9Y78CaEZWWvRinZxywp8x8tofjFNek/kId5BkGsV/1DRoCUvY0 4mUhcxxDuShuwkNbhSyHQ3m9/7Ry9RsaXdcF8OIJnKwLQYzPfsJGOHjlI9HD6sfoVOPCI7PIj 2FDOeiCmgMhlsKJhd41H+tNmvSicTnFhTaSkXsI/xSmvkvwP2Ds1cc0CQWcJtndnSS50pl6QY tdXHnMyntSwbJcLDGKorfjPyA7md6FI5mpySUoMMnpW+VG0FZafc56NLCzdbX6FXmlahafGJe TbDWMsZ6WuY3qH5fsK4lOuzRevqFrKJZWOKJh8dl8WFLESYbEU= Perfect example of a post hoc ergo propter hoc fallacy. I am orders of magnitude more active on github than on patchwork, because it really, really sucks. I'm pretty sure that I'm not the only one. You can say whatever you want about the next version of patchwork, as it's not yet there, and therefore might very well suck less; but please do not infer that the not-so-active contributors wouldn't be more active under different (in the case of patchwork - less painful) conditions. HTH, 7heo. On 7/24/2017 11:46 PM, Jean-Louis Fuchs wrote: > Hi Jakub > > On Mon, Jul 24, 2017 at 10:46:44PM +0200, Jakub Jirutka wrote: > >> I strongly disagree that Patchwork is a great tool, at least the >> current version we have. > > In the end the process/tools has to fit the most active commiters, not > non-commiters like me. > > Since you are a power-user, know better then I. I am someone > who likes "git send-email" and mailinglists. For me patchwork is more > or less the tool that creates RESTAPI events from a patch-mailinglist > (not in alpine though). I also use GitLab a lot and like it a lot. > > I just wanted to say that a minimalistic approach (meaning simple > tools like git send-email + a mailinglist), is liked by a non-commiter > like me and I know commiters in other projects who like it too. > > But as I said, the process has to be optimized for the active > commiters. And I guess I am strange and a exception, since I prefer > TUIs to GUIs. > > Best, > Jean > --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org --- From nobody Thu Mar 28 17:59:51 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mx1.tetrasec.net (mx1.tetrasec.net [74.117.190.25]) by lists.alpinelinux.org (Postfix) with ESMTP id 0B0095C4C6A for ; Thu, 27 Jul 2017 10:32:06 +0000 (GMT) Received: from mx1.tetrasec.net (mail.local [127.0.0.1]) by mx1.tetrasec.net (Postfix) with ESMTP id C24149E22F1; Thu, 27 Jul 2017 10:32:05 +0000 (GMT) Received: from ncopa-desktop.copa.dup.pw (15.63.200.37.customer.cdi.no [37.200.63.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: n@tanael.org) by mx1.tetrasec.net (Postfix) with ESMTPSA id 96B4A9E2154; Thu, 27 Jul 2017 10:32:03 +0000 (GMT) Date: Thu, 27 Jul 2017 12:31:59 +0200 From: Natanael Copa To: Jakub Jirutka Cc: Alpine-devel , Jean-Louis Fuchs Subject: Re: [alpine-devel] =?ISO-8859-1?B?QWTpbGll?= on Alpine, two months later Message-ID: <20170727123159.015956f7@ncopa-desktop.copa.dup.pw> In-Reply-To: <5301B93A-A3AA-4AD3-8191-EBA542A6C3D3@jirutka.cz> References: <5975E0C0.1030008@adelielinux.org> <57A1A151-0352-40DA-BC91-52980CEE99C3@shiz.me> <59761031.6000605@adelielinux.org> <20170724195040.GA18090@vimes.1042.ch> <5301B93A-A3AA-4AD3-8191-EBA542A6C3D3@jirutka.cz> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-alpine-linux-musl) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, 24 Jul 2017 22:46:44 +0200 Jakub Jirutka wrote: > There*s no clear relation between related patches, *cause it*s just > nearly impossible to reconstruct such information from separated > patches in mail. That depends on how you send them. Use --in-reply-to=3D to send the patch to a previous email thread. > Patchwork is based on ancient workflow from CVS era. No. It's based on the linux kernel development workflow, the people who invented git in the first place. > Maintainer can work with it directly via git (see > https://gist.github.com/piscisaureus/3342247), without leaving > terminal. When the contributor push new changes to the pull request, > maintainer can simply pull them via git and view in context, it*s > just a branch. This was great news for me. I have looked for something like that, without installing hub to provide github specific functionality to the cli. > It*s really horrible for reviews. Then you are using it wrong. Patchwork is not designed to make reviews. It is designed to help maintainer to keep track of the state of the patch, and to make sure that patches are not forgotten. You do the review, commenting and interaction via email, using your favorite email client. Using emails has some benefits. For example, you can read and write reviews while you are offline (on an airplane for example). You don't need sign up to any service. (github has critical mass now days so you cannot really be involved in open source without having github account anyway - I'm not convinced that is a good thing) > I understand why some ppl don*t like GitHub (it*s third-party > commercial service after all) Yes. I don't want be locked in to a service provider. I don't want make it a requirement that you sell your soul to github (or facebook or twitter or whatever) to be able to contribute to alpine. I also find the github web interface sluggish at times. Some pages can take various seconds to load. And if content or directory is to bit it will simply not show anything at all. The major problem with supporting both github and email submissions is that different people may send same patch. It is inconvenient for users that they need to check patchwork before making a github PR and it is inconventient that you need to search github PRs before you `git send-email`. I suppose that is the price we pay. I cannot claim that I love patchwork, but I want make it possible for people to `git send-email` patches. -nc PS. interestingly patchwork itself is hosted on github. --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org --- From nobody Thu Mar 28 17:59:51 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mx1.tetrasec.net (mx1.tetrasec.net [74.117.190.25]) by lists.alpinelinux.org (Postfix) with ESMTP id E980E5C4C62 for ; Thu, 27 Jul 2017 09:46:44 +0000 (GMT) Received: from mx1.tetrasec.net (mail.local [127.0.0.1]) by mx1.tetrasec.net (Postfix) with ESMTP id 6D7569E2158; Thu, 27 Jul 2017 09:46:44 +0000 (GMT) Received: from ncopa-desktop.copa.dup.pw (15.63.200.37.customer.cdi.no [37.200.63.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: n@tanael.org) by mx1.tetrasec.net (Postfix) with ESMTPSA id C98059E2154; Thu, 27 Jul 2017 09:46:43 +0000 (GMT) Date: Thu, 27 Jul 2017 11:46:38 +0200 From: Natanael Copa To: "A. Wilcox" Cc: alpine-devel@lists.alpinelinux.org Subject: Re: [alpine-devel] =?ISO-8859-1?B?QWTpbGll?= on Alpine, two months later Message-ID: <20170727114638.0917dbd2@ncopa-desktop.copa.dup.pw> In-Reply-To: <5975E0C0.1030008@adelielinux.org> References: <5975E0C0.1030008@adelielinux.org> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-alpine-linux-musl) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, 24 Jul 2017 06:57:52 -0500 "A. Wilcox" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > Hi there Alpinists, >=20 > This is a sort of status update and wish list after near two months of > attempting to base Ad=E9lie on Alpine Linux. Thank you for sharing your experiences. >=20 > 1. scripts/bootstrap.sh cannot "fake" cross. Since Ad=E9lie uses a > slightly different GCC configuration from Alpine, I attempted to run > bootstrap.sh on x86_64, from my x86_64 system: >=20 >=20 > ERROR: unsatisfiable constraints: > gcc-6.3.0-r4: > conflicts: gcc-x86_64-6.3.0-r4[so:libcilkrts.so.5=3D5.0.0] I wonder if it would make sense to add provides=3D"$pkgname-$arch" to gcc. That way "gcc-x86_64" would be provided from "gcc" on x86_64. > 2. The virtual system is pathetic. One of the very core tenets of > Ad=E9lie is giving the user power through choice. That choice is almost > impossible to provide using the current abuild/apk framework. I keep > hearing of a Debian-style alternatives system, and supposedly it was > specified somewhere, but I cannot find the specification nor an > implementation. If I could read the specification I would be highly > motivated to write an implementation. >=20 > Red Hat has `alternatives`, Debian has `update-alternatives`, and > Gentoo has `eselect`. The Alpine system desperately needs something > like this and I would love to contribute to such. I think something like update-alternatives or eselect makes sense. For example, you may want select which java implementation you should use as the "system" java. But I think we can divide it in 2 different cases: 1) symlinks (eg /usr/bin/lua -> /usr/bin/lua$version and /usr/bin/php -> /usr/bin/php$version). Selecting system java also goes here. 2) provides and dependencies in apk I am not convinced we should let apk handle the select/alternatives and mix that into the dependency calculation. > Consider a few different use cases: >=20 > mta: any package that needs `sendmail` has to either hard-depend on > postfix, or disable mail services. This is unacceptable in my > opinion. Other distros let you select what package you want to > provide `sendmail`. It has been mentioned already, but I think for sendmail we want provides=3D/usr/sbin/sendmail in the different providers and the packages that needs it should do depends=3D/usr/sbin/sendmail. (we could do provides=3Dfile:/usr/sbin/sendmail too but i think that a leading '/' is enought to indicate that its a file) =20 > awk: mawk vs gawk vs busybox awk. All have benefits and drawbacks and > the user should be able to choose which provides /usr/bin/awk. Also mentioned before that awk is a part of the base system and is expected to be there. So adding depends=3D/usr/bin/awk to all packages needing it would be cumbersome. However, we could maybe do symlinks trick using alternatives/select functionality. =20 > shell: /bin/sh as busybox is of course default, but some users may > want bash or another shell. I don't see any reason that can't be > supported. Same as awk. > vi: busybox, vim, neovim, elvis, ... There are almost a dozen > providers of `vi` in Debian and more than a dozen on Gentoo. I > believe Alpine itself packages four of them. I don't know if I see the problem here. You can use the EDITOR env var to select any editor, even non-vi like nano. > I started to try and make 'v:mta' but I'm very concerned about > diverging so much from the Alpine aports tree. Also, apk doesn't > support an automatic choice for a virtual if the user hasn't already > installed one (something like replaces_priority but for virtuals would > be good here imo). That means that when I *do* manage to get packages > to depend on v:mta, the user now has to read through an 'unsatisfiable > constraints' error and pick a package out of the list of providers. I don't think 'v:mta' makes much sense (mta with tcp port 25 does not even need to run on local host), but I think provides=3D/usr/sbin/sendmail makes sense. Currently you can have unversioned provides and have them installed in parallel, but then apk will not autoselect anything for you or you can have the provides versioned and apk will select one for you. But then you will not be able to have both installed at the same time. Maybe apk could, when the provides is unversioned and no provides installed, auto-select the provides with smallest size? Then you atleast get something installed (for example ssmtp), which you can manually replace if you want. =20 > 3. It is very hard to know where to send some things. For example, > the GCC APKBUILD does not function properly right now: it does not > declare a makedepends on gcc-gnat, and the GCC configure process bails > out when it does not find it because LANG_ADA is true whenever CBUILD > =3D=3D CHOST =3D=3D CTARGET. I am not 100% confident in my ability to ed= it > the APKBUILD for GCC considering how finicky it is, so I would like > help. I posted on the IRC channel but I mainly only have the weekends > to work on Ad=E9lie, and most of the channel is away on weekends. This > really isn't a distro topic, so it doesn't belong on alpine-devel from > what I have been able to gather about this list. The aports list > seems to be for patches only, from what I have gathered about that > list. Maybe this belongs on the bug tracker, but there really isn't a > bug category for build failures that I could find. >=20 > Additionally, changes made to abuild or apk-tools are currently being > sent via GitHub pull requests. However, none of us in Ad=E9lie really > want to use GitHub as it is a closed platform. The aports mailing > list exists for aports, but where could we send abuild or apk-tools > changes if we wanted an alternative to GitHub? It is mentioned before that you can use alpine-devel for that. I'd also suggest that you use --subject-prefix=3D"PATCH apk-tools" or "PATCH abuild" so its clear what project it belongs to. > 4. We have managed to make a split function 'openrc' that takes > /etc/init.d and /etc/conf.d directories. It has install_if=3D"$pkgname > openrc" so it is transparent when you have OpenRC installed, and > allows future migrations to a different init system. I don't know if > this is of any interest to Alpine. I like this. Just make sure that the pkgname is versioned. eg install_if=3D"$pkgname-$pkgver-r$pkgrel openrc" Otherwise interesting things will happen if you have older versions of $pkgname in you local build repository. (older versions will see it and, "hey openrc and $pkgname is installed. i want be installed too!") > 5. After being annoyed by bugs in the PowerPC build of GNU tar, we > managed to swap out /usr/bin/tar for bsdtar provided by libarchive in > abuild. It needed a patch to output the format apk expects by > default, but otherwise it seems to work quite well. This may be of > interest to those who want to do a GNU-free Alpine spin. libarchive seems a bit bigger that gnu tar, otherwise I don't have strong opinions. I would prefer to get the needed functionality added to busybox tar if possible. -nc --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org --- From nobody Thu Mar 28 17:59:51 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mail.wilcox-tech.com (mail.wilcox-tech.com [45.32.83.9]) by lists.alpinelinux.org (Postfix) with ESMTP id 515F85C4C7C for ; Thu, 27 Jul 2017 13:18:34 +0000 (GMT) Received: (qmail 13241 invoked from network); 27 Jul 2017 13:18:12 -0000 Received: from ip68-13-242-69.ok.ok.cox.net (HELO ?10.1.1.57?) (awilcox@wilcox-tech.com@68.13.242.69) by mail.wilcox-tech.com with ESMTPA; 27 Jul 2017 13:18:12 -0000 Subject: =?UTF-8?Q?Re:_[alpine-devel]_Ad=c3=a9lie_on_Alpine=2c_two_months_la?= =?UTF-8?Q?ter?= To: alpine-devel@lists.alpinelinux.org References: <5975E0C0.1030008@adelielinux.org> <20170727114638.0917dbd2@ncopa-desktop.copa.dup.pw> From: "A. Wilcox" X-Enigmail-Draft-Status: N1110 Organization: =?UTF-8?Q?Ad=c3=a9lie_Linux?= Message-ID: <5979E814.2050301@adelielinux.org> Date: Thu, 27 Jul 2017 08:18:12 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 In-Reply-To: <20170727114638.0917dbd2@ncopa-desktop.copa.dup.pw> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On 27/07/17 04:46, Natanael Copa wrote: > On Mon, 24 Jul 2017 06:57:52 -0500 "A. Wilcox"=20 > wrote: >> This is a sort of status update and wish list after near two=20 >> months of attempting to base Ad=E9lie on Alpine Linux. >=20 > Thank you for sharing your experiences. I am glad to be a part of a community where sharing is acceptable. :) >> 1. scripts/bootstrap.sh cannot "fake" cross. Since Ad=E9lie uses=20 >> a slightly different GCC configuration from Alpine, I attempted=20 >> to run bootstrap.sh on x86_64, from my x86_64 system: >>=20 >>=20 >> ERROR: unsatisfiable constraints: gcc-6.3.0-r4: conflicts:=20 >> gcc-x86_64-6.3.0-r4[so:libcilkrts.so.5=3D5.0.0] >=20 > I wonder if it would make sense to add provides=3D"$pkgname-$arch" to > gcc. That way "gcc-x86_64" would be provided from "gcc" on x86_64. That might be an interesting way around it. I will play with that over this weekend and see how that works. >> 2. The virtual system is pathetic. One of the very core tenets=20 >> of Ad=E9lie is giving the user power through choice. That choice=20 >> is almost impossible to provide using the current abuild/apk=20 >> framework. I keep hearing of a Debian-style alternatives >> system, and supposedly it was specified somewhere, but I cannot >> find the specification nor an implementation. If I could read >> the specification I would be highly motivated to write an=20 >> implementation. >>=20 >> Red Hat has `alternatives`, Debian has `update-alternatives`, and >> Gentoo has `eselect`. The Alpine system desperately needs=20 >> something like this and I would love to contribute to such. >=20 > I think something like update-alternatives or eselect makes sense.=20 > For example, you may want select which java implementation you=20 > should use as the "system" java. >=20 > But I think we can divide it in 2 different cases: >=20 > 1) symlinks (eg /usr/bin/lua -> /usr/bin/lua$version and=20 > /usr/bin/php -> /usr/bin/php$version). Selecting system java also=20 > goes here. >=20 > 2) provides and dependencies in apk >=20 > I am not convinced we should let apk handle the > select/alternatives and mix that into the dependency calculation. apk doesn't necessarily need to be the tool used to select the alternative, but I'm not sure how packages that depend on something like PHP or Java or Lua would work if apk wasn't somewhat aware. Something like Gentoo's slots may work for some of them but I don't think that's something that needs to be added to the APK format. There needs to be a way to depend on "php" and have apk accept that there are multiple PHP interpreters (such as a virtual or file path). >> Consider a few different use cases: >>=20 >> mta: any package that needs `sendmail` has to either hard-depend=20 >> on postfix, or disable mail services. This is unacceptable in my >> opinion. Other distros let you select what package you want to >> provide `sendmail`. >=20 > It has been mentioned already, but I think for sendmail we want=20 > provides=3D/usr/sbin/sendmail in the different providers and the=20 > packages that needs it should do depends=3D/usr/sbin/sendmail. (we=20 > could do provides=3Dfile:/usr/sbin/sendmail too but i think that a=20 > leading '/' is enought to indicate that its a file) So would that be manual (you put in the package provides=3D line that it provides sendmail)? That would probably be fine. >> awk: mawk vs gawk vs busybox awk. All have benefits and=20 >> drawbacks and the user should be able to choose which provides=20 >> /usr/bin/awk. >=20 > Also mentioned before that awk is a part of the base system and is > expected to be there. So adding depends=3D/usr/bin/awk to all=20 > packages needing it would be cumbersome. However, we could maybe > do symlinks trick using alternatives/select functionality. But then how would the dependency be satisfied? If a package requires 'awk', then how would APK know that 'mawk' or 'busybox' satisfies it? I have noticed that in general there is a deep expectation in aports that BusyBox will always be present. This really does not work too well for Ad=E9lie, but I'm willing to take on the additional work of fixing up aports if that work would be welcome. If it wouldn't be welcome, the trees will likely diverge much more. As I said in my opening email, Ad=E9lie wants the user to have the maximum amount of freedom, and that includes the ability to choose whether or not to use BusyBox. [I will note here that "awk" in some form is required by POSIX; since virtuals don't exist right now, 'mawk' is pulled in by adelie-base and therefore the lack of explicit awk dependency does not break building packages on Ad=E9lie. Still, implicit dependencies are always a bad thing IMO.] >> shell: /bin/sh as busybox is of course default, but some users=20 >> may want bash or another shell. I don't see any reason that=20 >> can't be supported. >=20 > Same as awk. My concern is for people to be able to choose what works for them. Maybe they want to use sash+toybox+ubase or bash+coreutils or such, instead of BusyBox. All packages with shell scripts have an explicit dependency to BusyBox[1] so that package effectively cannot be uninstalled on an Alpine system. If there was a 'shell' provider in the index, this could be solved quite easily. [1]: https://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n897 Consider also a very very tiny run-from-RAM instance that only needed an emergency shell and no other user interaction. If sash could replace busybox there could be a size benefit as well. BusyBox is 900 kB installed and sash is 280 kB installed. >> vi: busybox, vim, neovim, elvis, ... There are almost a dozen=20 >> providers of `vi` in Debian and more than a dozen on Gentoo. I=20 >> believe Alpine itself packages four of them. >=20 > I don't know if I see the problem here. You can use the EDITOR env=20 > var to select any editor, even non-vi like nano. Some programs do not obey EDITOR, but that is a good point. Still, most distros do allow you to choose the provider of `vi` and if everything else is being fixed up I don't see any reason to ignore vi. >> I started to try and make 'v:mta' but I'm very concerned about=20 >> diverging so much from the Alpine aports tree. Also, apk doesn't >> support an automatic choice for a virtual if the user hasn't >> already installed one (something like replaces_priority but for >> virtuals would be good here imo). That means that when I *do* >> manage to get packages to depend on v:mta, the user now has to >> read through an 'unsatisfiable constraints' error and pick a=20 >> package out of the list of providers. >=20 > I don't think 'v:mta' makes much sense (mta with tcp port 25 does=20 > not even need to run on local host), but I think=20 > provides=3D/usr/sbin/sendmail makes sense. Yes, if such a format is allowed, that would be the ideal solution. > Currently you can have unversioned provides and have them > installed in parallel, but then apk will not autoselect anything > for you or you can have the provides versioned and apk will select > one for you. But then you will not be able to have both installed > at the same time. >=20 > Maybe apk could, when the provides is unversioned and no provides=20 > installed, auto-select the provides with smallest size? I feel like it could still output a message such as: apk: selecting 'ssmtp' for provider of '/usr/sbin/sendmail' That way the user knows what is happening and that they can select another provider if they want. > Then you atleast get something installed (for example ssmtp), > which you can manually replace if you want. Yes, that is the goal. >> Additionally, changes made to abuild or apk-tools are currently=20 >> being sent via GitHub pull requests. However, none of us in=20 >> Ad=E9lie really want to use GitHub as it is a closed platform. >> The aports mailing list exists for aports, but where could we >> send abuild or apk-tools changes if we wanted an alternative to=20 >> GitHub? >=20 > It is mentioned before that you can use alpine-devel for that. I'd=20 > also suggest that you use --subject-prefix=3D"PATCH apk-tools" or=20 > "PATCH abuild" so its clear what project it belongs to. Okay. I will do that in the future. Thanks for the guidance. >> 4. We have managed to make a split function 'openrc' that takes=20 >> /etc/init.d and /etc/conf.d directories. It has=20 >> install_if=3D"$pkgname openrc" so it is transparent when you have=20 >> OpenRC installed, and allows future migrations to a different=20 >> init system. I don't know if this is of any interest to Alpine. >=20 > I like this. Just make sure that the pkgname is versioned. eg >=20 > install_if=3D"$pkgname-$pkgver-r$pkgrel openrc" >=20 > Otherwise interesting things will happen if you have older > versions of $pkgname in you local build repository. (older versions > will see it and, "hey openrc and $pkgname is installed. i want be > installed too!") Yes, I did the same as the doc function which does the same :) >> 5. After being annoyed by bugs in the PowerPC build of GNU tar,=20 >> we managed to swap out /usr/bin/tar for bsdtar provided by=20 >> libarchive in abuild. It needed a patch to output the format >> apk expects by default, but otherwise it seems to work quite >> well. This may be of interest to those who want to do a GNU-free >> Alpine spin. >=20 > libarchive seems a bit bigger that gnu tar, otherwise I don't have > strong opinions. I would prefer to get the needed functionality=20 > added to busybox tar if possible. That is understandable. I took a look at the BusyBox tar code and it was a bit over my head. Perhaps someone else can add the requisite functionality to it. As far as I can tell, that would be: * write pax format * full xattr support Everything else seems to be supported. Best, - --arw >=20 > -nc >=20 - --=20 A. Wilcox (awilfox) Project Lead, Ad=E9lie Linux http://adelielinux.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZeegTAAoJEMspy1GSK50UBl4P/11U24hRv++2Ye8bl/KRAw8G bTZ6gNF5Olcr8QQPonEnCxooV7FhNp+toaDuyNV+a8vMWkRohf/Yv3iSoIForpX4 EQCqn4YM+1lR2MK98peqg7R7sMhRCK/QL1r2+lSoARQTWn0c8T/c3Umee9HsrTUJ pDTISw93hL1p+2YTxtGy3SH3/Ck6bTPnuU3YnD1VIYtb9MQlurojuUeaEVapSvdw Mipaf2stmbqvq4xz6tj5uW3Ke/Kv76syv4bt00ruhE9Yit3O9QxTRdjtP+zxkmJ7 clZd0YPoK4y3kKZX7+j1oRGpDWANrPUmwMfQjh3FhENuf3rhxHrCxfpWHFzM0TbA FfsoEDuHLN7pGksTXLlC4FZh32863KFxZs+GCWmhudTLk8BQXcFEZbEeHplZB8rF FNGYAHotPU4L4+sl5Et4v/u1U87A3fC/bdsNagDhr+SykldhH7MA0qrOMtjUJsJg YfHR8jD4Ef09BvHsiXUt9ocHTWpaAy6fG2lD5Zd7j+rihVwSV1/Ze8/uQGgEI098 q3dYva9G8dIj3tzE9/bJX/J9QvAnxVXNJ7WiU7qxYBcq7ewF+Zdxxq9jtIl9Ohdb Xsx1RO2No+LJED9nsydEGgWJ6kf44dgcQ+5tGc6HwfKIHTTmyawk4NAso92NYOY9 QSVE4RF1RRvL1AhBtann =3DBBov -----END PGP SIGNATURE----- --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---