All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.