Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Jörg Krause" <joerg.krause@embedded.rocks>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] package/macchanger: fix musl build
Date: Fri, 06 May 2016 08:26:58 +0200	[thread overview]
Message-ID: <1462516018.2064.1.camel@embedded.rocks> (raw)
In-Reply-To: <18bdd441-ce98-cdb6-b233-5c97b328ad9e@mind.be>

Dear Arnout,

On Mo, 2016-05-02 at 23:32 +0200, Arnout Vandecappelle wrote:
> On 05/02/16 21:40, J?rg Krause wrote:
> > Hi,
> > 
> > On Sa, 2016-01-23 at 23:43 +0100, Bernd Kuhls wrote:
> [snip]
> > > +@@ -113,7 +113,7 @@ mc_net_info_get_permanent_mac (const net
> > > +?	epa->size = IFHWADDRLEN;
> > > +
> > > +?	memcpy(&req, &(net->dev), sizeof(struct ifreq));
> > > +-	req.ifr_data = (caddr_t)epa;
> > > ++	req.ifr_data = (char *)epa;
> > > +
> > > +?	if (ioctl(net->sock, SIOCETHTOOL, &req) < 0) {
> > > +?		perror ("[ERROR] Could not read permanent
> > > MAC");
> > 
> > any reason why this patch is marked as "Changes Requested"? The
> > build
> > error is still present...
> 
> ? IIRC, Bernd posted almost a hundred patches at the time for musl
> fixes, most?
> of which were taken from Alpine Linux, and almost all of which had
> insufficient?
> explanation of the problem and of the fix (nothing more than "fix
> musl build"?
> and a reference to the alpine patch). Also many of them were simply
> incorrect:?
> they would maybe fix the build, but possibly introducing other bugs
> or sometimes?
> just breaking the code. So after reviewing and rejecting a dozen of
> them,?
> ThomasP just made a generic comment that all of them should be done
> more?
> carefully and marked all of them as Changes Requested.
> 
> ? If you would like to recover and review them, just select in
> patchwork patches?
> from Bernd that are marked as changes requested and that have musl in
> the?
> subject. Feel free to repost (with better commit messages of course).

I see! Yes, I will do this for some packages.

> ? This one specifically does look good to me - except for the commit
> message,?
> which should be something like:
> 
> caddr_t is a BSD type. POSIX usually uses void* instead, but
> specifically in?
> struct ifreq the type of ifr_data is char*.
> 

Many thanks!

Best regards
J?rg Krause

      reply	other threads:[~2016-05-06  6:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-23 22:43 [Buildroot] [PATCH 1/1] package/macchanger: fix musl build Bernd Kuhls
2016-05-02 19:40 ` Jörg Krause
2016-05-02 21:32   ` Arnout Vandecappelle
2016-05-06  6:26     ` Jörg Krause [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1462516018.2064.1.camel@embedded.rocks \
    --to=joerg.krause@embedded.rocks \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox