From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2925 Path: news.gmane.org!not-for-mail From: Isaac Dunham Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl setup attempt Date: Fri, 15 Mar 2013 14:11:41 -0700 Message-ID: <20130315141141.1f14e6a4.idunham@lavabit.com> References: <5140CA2B.2060902@barfooze.de> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1363382013 27816 80.91.229.3 (15 Mar 2013 21:13:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Mar 2013 21:13:33 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2926-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 15 22:13:57 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UGbwl-00064u-Vl for gllmg-musl@plane.gmane.org; Fri, 15 Mar 2013 22:13:52 +0100 Original-Received: (qmail 30278 invoked by uid 550); 15 Mar 2013 21:13:28 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 30270 invoked from network); 15 Mar 2013 21:13:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=FQTSFY2+5n/nbdudvjr0jMebPGI7U67ApIuEpQV+OuWDBoWKoV1UAcB535azOOej8XaaZGVAgsz9wYCkquGz90SYnMhPx09zFwQESWjVC18X9SzdBYn+MhMg1+xJTqL/zRaXdV9aF6BB/emE4tIOYzKG5Cwu1k1gvdweDtsJOQw=; h=Date:From:To:Subject:Message-Id:In-Reply-To:References:X-Mailer:Mime-Version:Content-Type:Content-Transfer-Encoding; In-Reply-To: X-Mailer: Sylpheed 3.0.2 (GTK+ 2.20.1; i486-pc-linux-gnu) Xref: news.gmane.org gmane.linux.lib.musl.general:2925 Archived-At: On Fri, 15 Mar 2013 07:54:39 -0400 LM wrote: > I have really mixed results with reporting portability bugs. More > often than not, projects refuse to accept the bugs unless they're for > platforms they officially support. I typically work with > cross-platform software, but many of the cross-platform projects still > only officially support a limited number of systems. Some of them > have even been down-right nasty when I submit a patch to fix an issue > for my platform. (Of course, I've run across some projects where the > developers have been very nice too and fix things extremely quickly.) > Am very curious if anyone else has had problems with this sort of > thing and how you handle the situation. A few points: 1) Patches beat bug reports. Make sure that you note upstream policy about copyright assignments and so on, though. Also follow the code style upstream uses. 2) Make sure it's not going to break upstream policy. Examples: don't change -std=c89 3) Make sure it doesn't disable something for other platforms (eg, breaking tests for uclibc) 4) Make it as little change as appropriate 5) If at all possible, test on other platforms. The best response I had was a trivial patch for libnl (adding a couple headers) which I prepared, tested on musl and glibc, then sent with a comment that it fixed build on musl and worked on glibc. It was applied almost immediately. -- Isaac Dunham