Re: [obs submit-request 163623] devel:libraries:c_c++/hxtools: accepted by dirkmueller
Am 11.04.2013 19:00, schrieb Jan Engelhardt:
> - there is a package maintainer defined, and you gave
> him a measly 74 minutes to respond.
Sorry, I didn't realize that, the webui does not show this information
to me while accepting the request and I didn't remember it off hand
(while I read commits in that project, the last commit was a quarter ago
and I simply didn't match the information).
It is a build fix for aarch64, as you might have guesst already. Given
that you're the maintainer, could you work with Andreas on upstreaming
the patch? This fix(or a similar one) is needed anyway, be it with
opensuse policy correctness or not :-)
I'm just maintaining it on a project level, ensuring that stuck requests
are being handled. as I went through the pending submitrequests (which I
do rarely once a week, if at all), I just picked this one as well as it
looked obvious to me.
I see you already reverted the change, I've revoked the submitrequest to
factory and now I would like to ask you to work with Andreas on getting
the fix upstream.
> Am 11.04.2013 19:00, schrieb Jan Engelhardt:
> Hi Jan,
>> - there is a package maintainer defined, and you gave
>> him a measly 74 minutes to respond.
> Sorry, I didn't realize that, the webui does not show this information to me
Ok, I was under the assumption people would react to Hermes email
notifications; I am not sure what other information the webui hides.
However, I do see a "Modified" column next to "Source", "Requester",
"Type" and "State" in
On Friday 2013-04-12 16:39, Andreas Schwab wrote:
>Jan Engelhardt <[hidden email]> writes:
>> - the patch has no description or author info whatsoever
>You mean this?
># PATCH-FIX-UPSTREAM Avoid conflicting use of implementation namespace - [hidden email] >Patch: hxtools-namespace.patch
That is just a summary to me. A description would be like
"xfs_irecover.c defines typedef uint8_t __u8, but __u8 is already provided
by way of #include <signal.h> -> <asm/signal.h> -> <linux/types.h>
(this include chain is the same for asm-arm and asm-x86).",
perhaps including the compiler error message that was generated.
At first I guessed that asm-arm/ had different includes than
asm-x86/, but that does not seem to be the case, so the current guess
is that the __u8 is something different than uint8_t/unsigned char on
ARM, but that would then raise the question “why?”.
Hence, the compiler error is really desirable.
To unsubscribe, e-mail: [hidden email] To contact the owner, e-mail: [hidden email]