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
prev parent 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