[
https://issues.apache.org/jira/browse/LOG4J2-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Duft closed LOG4J2-3358.
---
Took the time to do it as fast as you responded xD Closing since JsonLayout it
back to working
[
https://issues.apache.org/jira/browse/LOG4J2-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480847#comment-17480847
]
Markus Duft commented on LOG4J2-3358:
-
Thanks for the very quick response,
[
https://issues.apache.org/jira/browse/LOG4J2-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Duft updated LOG4J2-3358:
Description:
We're creating a RollingFileAppender programmatically using a JsonLayout. This
Markus Duft created LOG4J2-3358:
---
Summary: 2.17.1: JsonLayout Context no longer working.
Key: LOG4J2-3358
URL: https://issues.apache.org/jira/browse/LOG4J2-3358
Project: Log4j 2
Issue Type
mduft 14/04/11 05:27:35
Modified: rex-client-.ebuild
Log:
fixed wrong installation
(Portage version: 2.2.8-r1/cvs/Linux x86_64, unsigned Manifest commit)
Revision ChangesPath
1.2 app-emulation/rex-client/rex-client-.ebuild
file :
http:/
data.xml
===
http://www.gentoo.org/dtd/metadata.dtd";>
md...@gentoo.org
Markus Duft
1.1 app-emulation/rex-client/ChangeLog
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-emulation/rex-client/ChangeLog?rev=1.1&view
mduft 14/04/11 05:16:10
Log:
Directory /var/cvsroot/gentoo-x86/app-emulation/rex-client added to the
repository
[
https://issues.apache.org/jira/browse/SSHD-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13954979#comment-13954979
]
Markus Duft commented on SSHD-305:
--
FYI, I had the same problem now in some code of my
[
https://issues.apache.org/jira/browse/SSHD-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13950445#comment-13950445
]
Markus Duft commented on SSHD-305:
--
also please note that something else in SSHD is
[
https://issues.apache.org/jira/browse/SSHD-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13950445#comment-13950445
]
Markus Duft edited comment on SSHD-305 at 3/28/14 6:37 AM:
---
[
https://issues.apache.org/jira/browse/SSHD-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13950435#comment-13950435
]
Markus Duft commented on SSHD-305:
--
tested, sadly there is no improvement...:
Conne
[
https://issues.apache.org/jira/browse/SSHD-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13949519#comment-13949519
]
Markus Duft commented on SSHD-305:
--
thanks a lot, will test this tomorrow!
> SFTP
[
https://issues.apache.org/jira/browse/SSHD-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13949277#comment-13949277
]
Markus Duft commented on SSHD-305:
--
maven won't work behind our proxy/firew
[
https://issues.apache.org/jira/browse/SSHD-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13949268#comment-13949268
]
Markus Duft edited comment on SSHD-305 at 3/27/14 1:05 PM:
---
I
[
https://issues.apache.org/jira/browse/SSHD-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13949268#comment-13949268
]
Markus Duft commented on SSHD-305:
--
I can try - is there a nightly jar file somew
[
https://issues.apache.org/jira/browse/SSHD-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13949257#comment-13949257
]
Markus Duft edited comment on SSHD-305 at 3/27/14 12:5
[
https://issues.apache.org/jira/browse/SSHD-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13949257#comment-13949257
]
Markus Duft commented on SSHD-305:
--
thats not what i tried...
after connecting
[
https://issues.apache.org/jira/browse/SSHD-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Duft updated SSHD-305:
-
Environment: MINA SSHD on Windows 8.1, Oracle JDK7 (was: MINA SSHD on
Windows 8.1)
> SFTP: wr
Markus Duft created SSHD-305:
Summary: SFTP: wrong directory contents read on windows when
cd'ing to root (C:)
Key: SSHD-305
URL: https://issues.apache.org/jira/browse/SSHD-305
Project: MINA
>
> >
> > what does ~/.xsession-errors
> >
> > say about xinerama? eg:
>
> Interesting; it says nothing about it. I have .xsession-errors and
> Xorg.0.log attached FYI, maybe you can see something about it...? Also, it
> seems that i get a "another compositor is already running on your
display",
>
> what does ~/.xsession-errors
>
> say about xinerama? eg:
Interesting; it says nothing about it. I have .xsession-errors and
Xorg.0.log attached FYI, maybe you can see something about it...? Also, it
seems that i get a "another compositor is already running on your display",
but i just logged
Hey!
Since I could not get a reply on IRC for this issue... here again my
question:
I tried to setup E17 (0.17.1) on gentoo, and actually i'm really surprised
of how much works out of the box (congratulations!). Still i'm stuck with an
issue in screen setup. I have something like this:
On 10/01/11 19:25, Jim Meyering wrote:
> Jim Meyering wrote:
> ...
>> Thanks. I'll review one more time and apply these post-release.
>
> Thanks for your patience.
> I have applied those two change-sets with some minor changes:
> - we prefer to use "ATTRIBUTE_UNUSED" to mark unused variables
>
On 09/08/11 10:17, Jim Meyering wrote:
> Markus Duft wrote:
[snip]
>>
>> gcc is 4.2.4 and there is no chance to get a newer one to work
>> currently (i have big problems forward porting my patches). but i
>> /think/ it's the library support anyway thats broken. it
On 09/09/11 08:55, Markus Duft wrote:
> On 09/08/11 08:09, Markus Duft wrote:
>> On 06/10/11 11:37, Bruno Haible wrote:
> [snip]
>>>
>>> You need to find out what is wrong about that type on your platform. If
>>> you're lucky, it's only s
On 09/08/11 08:09, Markus Duft wrote:
> On 06/10/11 11:37, Bruno Haible wrote:
[snip]
>>
>> You need to find out what is wrong about that type on your platform. If
>> you're lucky, it's only some library functions (like snprintf) which don't
>> support it
On 09/08/11 14:00, Jim Meyering wrote:
> Markus Duft wrote:
>> On 09/08/11 10:17, Jim Meyering wrote:
>>> Markus Duft wrote:
>>>
[snip]
>
> Thanks. I've pointed out a few issues, hoping you'll adjust
> accordingly and resubmit.
sure :)
On 09/08/11 10:17, Jim Meyering wrote:
> Markus Duft wrote:
>
[snip]
>
> A simpler approach might be ok: add a test for existence of the
> _nomembers functions (in m4/jm-macros.m4), and then add code like
> this for each in system.h, inserted after the declaration of getgrgi
On 06/10/11 11:37, Bruno Haible wrote:
> Hi,
>
> Markus Duft wrote:
>> long long double is broken.
>
> You surely mean "long double"? There is no such type as "long long double"
> in C.
>
>> this bites me in the gnulib vasnprintf im
On 09/07/11 16:13, Jim Meyering wrote:
> Markus Duft wrote:
> ...
[snip]
>> also, one more thing i saw from the gentoo ebuilds: we're adding those
>> to CFLAGS for building, as otherwise "id" will be dead slow on
>> domain-controlled windows machines:
>&
On 06/10/11 11:37, Bruno Haible wrote:
> Hi,
>
> Markus Duft wrote:
>> long long double is broken.
>
> You surely mean "long double"? There is no such type as "long long double"
> in C.
right; long long double is too long :)
>
>> this bi
Hi!
While porting glib to interix, i stumbled over a problem i didn't hit for a
while (and in fact forgot that it existed on interix): long long double is
broken. this bites me in the gnulib vasnprintf implementation, which calls
snprintf from libc which immediately crashes ... :(
i fixed this
Hi!
It's been quite a while, but now i'd have a small patch for interix libtool
(again). The background for the patch is building GLIB on interix, which
initially didn't succeed. Actually, libtool did nothing wrong, just the system
linker is broken in so many different ways, that each day a new
On 05/29/11 01:39, James Youngman wrote:
> On Fri, May 27, 2011 at 6:59 AM, Markus Duft wrote:
>> right, that'd be great. now suacomp takes the work :)
>>
>> thanks very much, and apologies for bringing the work up in the first
>> place...
>>
On 05/27/11 00:08, James Youngman wrote:
> On Thu, May 26, 2011 at 12:50 PM, Eric Blake wrote:
>> On 05/26/2011 01:10 AM, Markus Duft wrote:
>>>> 2. modify the configure script to refuse to build findutils at all on
>>>> Interix unless suacomp is i
Hey!
Already some years ago now, i ported readline to interix, and since then
maintained a patch at [1]. Could you please review and comment on the patch?
I'd love to see it go upstream, if that would be ok with you :)
Although the patch name suggests it is for 5.2, it still applies to 6.1 (and
On 05/26/11 12:35, Bruno Haible wrote:
> Markus Duft wrote:
>>> and send us the log files of these three commands, plus config.log and
>>> gltests/config.log.
>>
>> all attached, except make check, as i could not run it, as make already
>> failed :/
>
&g
On 05/26/11 10:51, Andreas Gruenbacher wrote:
> On Thursday 26 May 2011 10:43:41 Markus Duft wrote:
[snip]
>>
>> Trying to find out ;) First of all, patch seems to miss strnlen.c in the
> tarball (2.6.1).
it seems a well known problem, as even gentoo linux has a patch for thi
On 05/26/11 10:51, Andreas Gruenbacher wrote:
> On Thursday 26 May 2011 10:43:41 Markus Duft wrote:
[snip]
>>
>> Trying to find out ;) First of all, patch seems to miss strnlen.c in the
> tarball (2.6.1).
it seems a well known problem, as even gentoo linux has a patch for thi
Hey!
Already some years ago now, i ported readline to interix, and since then
maintained a patch at [1]. Could you please review and comment on the patch?
I'd love to see it go upstream, if that would be ok with you :)
Although the patch name suggests it is for 5.2, it still applies to 6.1 (and
On 05/26/11 01:48, James Youngman wrote:
> On Wed, May 25, 2011 at 10:21 AM, Markus Duft wrote:
>> On 10/28/10 14:43, Markus Duft wrote:
>> [snip]
>>>> another solution that came to my mind: i'm maintaining a library, who's
>>>> sole purpose
Hey!
For quite a while now, i have patch working on x86-interix with a small patch (
:D ). I'd really love to see this patch ([1]) go upstream, if that's ok with
you. Could you please take a look at it, and possibly comment on it?
[1]
http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-ov
On 10/28/10 14:43, Markus Duft wrote:
[snip]
>> another solution that came to my mind: i'm maintaining a library, who's sole
>> purpose is to fix the incorrect behaviour of libc in some regards on interix
>> (libsuacomp [1]). it does some "bad" t
On 05/17/11 00:40, Bruno Haible wrote:
> Hi Markus,
>
>> This is a small patch in reply to [1] to update the DEPENDENCIES for interix
>> accordingly.
>>
>> [1] http://lists.gnu.org/archive/html/bug-gnulib/2011-05/msg00310.html
>> "gnulib should document that libsuacomp is a
>>prerequisite f
On 05/16/11 16:01, Eric Blake wrote:
> On 05/16/2011 01:47 AM, md...@s01en22.salomon.at wrote:
>> From: Markus Duft
>>
>> Hey!
>>
>> This is a small patch in reply to [1] to update the DEPENDENCIES for interix
>> accordingly.
>> suacomp 0.6.8 (whic
On 05/13/11 08:27, Paul Eggert wrote:
> On 05/12/11 23:15, Markus Duft wrote:
>> maybe i could even implement a futimes by memorizing the timestamps and
>> re-setting them after closing the file...
>>
>> would that be better than hacking around in gnulib? libsuacomp is
On 05/13/11 08:27, Paul Eggert wrote:
> On 05/12/11 23:15, Markus Duft wrote:
>> maybe i could even implement a futimes by memorizing the timestamps and
>> re-setting them after closing the file...
>>
>> would that be better than hacking around in gnulib? libsuacomp is
On 05/12/11 18:10, Paul Eggert wrote:
> On 05/12/11 01:38, Markus Duft wrote:
>> this doesn't help, and doesn't even compile, as interix also doesn't have
>> sync()
>
> OK, how about this patch to utimens.c instead?
tested, but doesn't help eithe
On 05/12/11 18:10, Paul Eggert wrote:
> On 05/12/11 01:38, Markus Duft wrote:
>> this doesn't help, and doesn't even compile, as interix also doesn't have
>> sync()
>
> OK, how about this patch to utimens.c instead?
tested, but doesn't help eithe
On 05/12/11 09:20, Paul Eggert wrote:
> On 05/11/11 23:51, Markus Duft wrote:
>> the fd in fdutimensat is 4, whereas in utimens, which is then called from
>> somewhere in there,
>> it is -1, so i can't do a fsync()
>
> If I understand things correctly, there
On 05/12/11 05:41, Paul Eggert wrote:
> On 05/11/11 01:49, Markus Duft wrote:
>> fsync(fd) before setting the timestamp helps, and i have a 1.26 patch
>> (attached),
>> for now limited to interix only, although i saw it on linux too.
>
> Can you describe the GNU/Linux
On 05/12/11 09:20, Paul Eggert wrote:
> On 05/11/11 23:51, Markus Duft wrote:
>> the fd in fdutimensat is 4, whereas in utimens, which is then called from
>> somewhere in there,
>> it is -1, so i can't do a fsync()
>
> If I understand things correctly, there
On 05/12/11 05:41, Paul Eggert wrote:
> On 05/11/11 01:49, Markus Duft wrote:
>> fsync(fd) before setting the timestamp helps, and i have a 1.26 patch
>> (attached),
>> for now limited to interix only, although i saw it on linux too.
>
> Can you describe the GNU/Linux
On 02/02/11 20:28, Paul Eggert wrote:
> On 02/01/11 23:28, Markus Duft wrote:
>> i don't think it's "only" a bug in the filesystem
Hey!
i know it has been a while, but i came back to the problem today...
>
> Yes, most likely it isn't "just" a
Markus Duft added the comment:
since the patch is rather small, and prove to not "fluctuate" too much on
releases, i'd be willing to keep maintaining them, although i think that it
would not cause too much problems to integrate it int
Markus Duft added the comment:
if the buildbot does not need to be reached from the outside, i could provide
one, yes (i'm behind a company firewall/proxy infrastructure)
as for the patch: comments and improvement suggestions welcome :)
as for interix (actually SUA - Subsystem for
New submission from Markus Duft :
Hey!
For a while now, i'm maintaining python build patches for interix for the
gentoo prefix project. I thought maybe i can bring them upstream :) currently i
have python 2.7.1 building, and i'll start testing python 3.2 in a while...
may i ask you
On 02/04/2011 01:51 AM, Paul Eggert wrote:
> On 02/02/11 23:48, Markus Duft wrote:
>> which filesystem is _not_ buggy in this sense?
>
> I haven't run into the problem myself. I normally
> use RHEL 5.5 + NFS, or Solaris 10 + NFS, or Ubuntu 10.10
> + ext4. But I ha
On 02/02/2011 08:28 PM, Paul Eggert wrote:
> On 02/01/11 23:28, Markus Duft wrote:
>> i don't think it's "only" a bug in the filesystem
>
> Yes, most likely it isn't "just" a bug in the file system.
> tar has changed the way that it sets f
On 02/01/2011 10:50 PM, Paul Eggert wrote:
> On 01/31/11 23:23, Markus Duft wrote:
>
>> [1] http://bugs.gentoo.org/show_bug.cgi?id=352254
>
> Ah, OK, so it's a bug in the underlying file system implementation.
> Unfortunately the patch proposed in
> <http://b
On 01/31/2011 06:08 PM, Paul Eggert wrote:
> Thanks for reporting the bug, but I'm afraid that we can't
> easily reproduce it from the info in that message. Also,
> it's not clear what patches have been applied to the Solaris
> distribution of GNU tar. So you may have to provide more
> debugging
I've changed enough
> that I'll wait for an ACK before pushing.
> Below I've included one more patch to clean up some more
> code formatting nits in that same file.
thanks a lot :)
markus
>
> From a481c562988f66f1614206c2f82779aa7835afb8 Mon Sep 17 00:00:00 2001
>
On 10/21/2010 12:35 PM, Jim Meyering wrote:
> Markus Duft wrote:
>> On 10/21/2010 11:59 AM, James Youngman wrote:
>>> On Thu, Oct 21, 2010 at 10:05 AM, Markus Duft wrote:
>>>> Hi!
>>>>
>>>> I just created the attached patch for findutils
Hi!
I just tried updating to make-3.82 (from 3.81), and it turned out, that i have
a build related problem: uintmax_t is defined in stdint.h here, and not in
inttypes.h. configure does seem to check stdint.h too, but make.h does not
include it. Additionally, to complicate things, inttypes.h _is
On 01/03/2011 04:31 PM, Markus Duft wrote:
> Hi!
>
> Another question: Shouldn't the APIC version be 0x14 for CPUs since P4/Xeon?
> At least according to the Intel docs, since then the xAPIC is used, which has
> 0x14 as version (see intel manuals, vol 3a "10.4.8 Local
Hi!
Another question: Shouldn't the APIC version be 0x14 for CPUs since P4/Xeon? At
least according to the Intel docs, since then the xAPIC is used, which has 0x14
as version (see intel manuals, vol 3a "10.4.8 Local APIC Version Register".
reading the APIC version register yields 0x11 for all C
On 10/21/2010 02:30 PM, Jim Meyering wrote:
> Markus Duft wrote:
>>> I see that you have FSF copyright assignments on file
>>> for other projects, but not yet for gnulib.
>>> Can you start that process?
>>> Once that's done, we can proceed.
>>
>
On 01/03/2011 02:00 PM, Jan Kiszka wrote:
> [ please keep CCs ]
>
> Am 03.01.2011 13:27, Markus Duft wrote:
>> On 01/03/2011 01:15 PM, Markus Duft wrote:
>>> On 01/03/2011 12:15 PM, Jan Kiszka wrote:
>>> [snip]
>> [snip]
>>> actually, i find that Te
On 01/03/2011 01:15 PM, Markus Duft wrote:
> On 01/03/2011 12:15 PM, Jan Kiszka wrote:
> [snip]
[snip]
> actually, i find that Ted Harkington was right: in 0.11.1 i can debug 32 bit
> code with qemu-system-x86_64 well enough (which means i debugged all the 32
> bit part of my kern
On 01/03/2011 12:15 PM, Jan Kiszka wrote:
[snip]
>>
>> 1) is this a problem with qemu or was qemu "fixed" and gdb has a problem?
>>(that's why i CCd the gdb list ;)).
>> 2) is there any plan to fix this issue?
>> 3) is there some kind of workaround i can use (i'd be happy with an
>> ugly/unsup
Hi!
I have been playing a little with this: I'm writing a kernel for both x86 and
x86-64. While doing so, i'd like to debug the kernel using qemu (and it's gdb
stub) and gdb. This worked very well until qemu-0.11.1 (gdb version does not
seem to play any role...). From there on, debugging the 64
On 11/14/2010 09:44 PM, Konstantin Tokarev wrote:
> I propose to export variable $EPREFIX in startprefix script to make it
> visible in shell after running it (for use in scripts)
>
for use in scripts you can use
$ portageq envvar EPREFIX
this is safer than exporting EPREFIX. having EPREFIX i
On 11/11/2010 09:13 AM, Torsten Veller wrote:
> * Markus Duft :
>>>>> wrote:
>>>>>> booth registration is not yet open, i will have an eye on this too...
>
>> right now i'm _very_ busy with work (and life ;)), thus i cannot manage
>> all th
On 10/29/2010 01:11 AM, Paolo Bonzini wrote:
> On 10/28/2010 04:59 PM, Markus Duft wrote:
>> thinking of gnulib, i can see a lot of potential problems, starting fex,
>> that gnulib
>> modules are copied into the packages, rather than gnulib beeing an installed
>>
On 10/28/2010 04:16 PM, Eric Blake wrote:
[snip]
>
> That's exactly what gnulib is - a library of source code workarounds for
> broken platform functions. Are you interested in porting your
> libsuacomp fixes into gnulib, so that more GNU programs can support
> Interix out of the box?
(i'll take
On 10/28/2010 04:16 PM, Eric Blake wrote:
[snip]
>
> That's exactly what gnulib is - a library of source code workarounds for
> broken platform functions. Are you interested in porting your
> libsuacomp fixes into gnulib, so that more GNU programs can support
> Interix out of the box?
(i'll take
On 10/28/2010 12:08 PM, Markus Duft wrote:
> On 10/28/2010 12:03 PM, James Youngman wrote:
> [snip]
>> In so far as we're likely ever to fix this problem I'd be inclined to
>> go for the 32K limit that Eric suggested. And perhaps treating
>> ENOMEM like E2
On 10/28/2010 12:03 PM, James Youngman wrote:
[snip]
> In so far as we're likely ever to fix this problem I'd be inclined to
> go for the 32K limit that Eric suggested. And perhaps treating
> ENOMEM like E2BIG when execve fails, for Interix.
mhm - that'd be ok with me.
another solution that cam
On 10/28/2010 10:55 AM, James Youngman wrote:
> On Thu, Oct 28, 2010 at 7:33 AM, Markus Duft wrote:
>> through trial and error, i found out that with a 3K environment, 50K seems
>> to work well, which seems rather odd then - as arguments would be 47K in the
>> worst case
us
>
> Thanks,
> Ralf
>
> docs: mention shell requirement for libtool script.
>
> * doc/libtool.texi (Invoking libtool): Document that the shell
> used to invoke libtool needs to be the same used to configure
> it.
> * THANKS: Update.
> Report
us
>
> Thanks,
> Ralf
>
> docs: mention shell requirement for libtool script.
>
> * doc/libtool.texi (Invoking libtool): Document that the shell
> used to invoke libtool needs to be the same used to configure
> it.
> * THANKS: Update.
> Report
On 10/28/2010 08:33 AM, Markus Duft wrote:
[snip]
> i have no idea how we could be able to reliably find a "real" limit on
> interix, other than a configure check which tries to exec until it works...
> however, the check would need to grow the env to the maximum, too.
i c
On 10/28/2010 01:20 AM, Eric Blake wrote:
> On 10/27/2010 05:12 PM, James Youngman wrote:
>>
>>> AFAIK, the maximum environment size
>>> on interix is 32K, if that's of any interest to you...
>>
>> Does it express the size of this limit in a way that's relevant to the
>> POSIX programming interface
On 10/27/2010 08:42 AM, Markus Duft wrote:
> On 10/23/2010 01:52 PM, James Youngman wrote:
>> Thanks. I adopted a very slightly different approach, see
>> https://savannah.gnu.org/bugs/index.php?31424
>>
>> The updated code is already pushed.
>
> The patch works
On 10/23/2010 09:16 AM, Ralf Wildenhues wrote:
> Hello Markus,
>
> * Markus Duft wrote on Fri, Oct 22, 2010 at 09:59:27AM CEST:
>> I have a question: In the new libtool, $ECHO is checked for in
>> libtool.me, preferring print over printf over a fallback echo. Now, on
>&g
On 10/23/2010 01:52 PM, James Youngman wrote:
> Thanks. I adopted a very slightly different approach, see
> https://savannah.gnu.org/bugs/index.php?31424
>
> The updated code is already pushed.
The patch works as expected, thank you very much - this was really painless ;)
markus
>
> James.
>
On 10/22/2010 03:30 PM, Markus Duft wrote:
> Hey :)
>
[snip]
> It seems that max argument length is too high...
>
> Now, i'm pretty aware that interix is doing _many_ things wrong, and
> sysconf(_SC_ARG_MAX) may well return a much too high number, but to
> consistentl
Hey :)
I recently updated my findutils builds on interix (work without
any patches (except a gnulib patch i already submitted), thanks
for the great work ;) ), and stumbled across a small problem:
mduft xargs $ find /usr/ | ./xargs
./xargs: /bin/echo: Cannot allocate memory
mduft xargs $ ./xar
Hi!
I have a question: In the new libtool, $ECHO is checked for in
libtool.me, preferring print over printf over a fallback echo. Now, on
interix, i have a KSH as /bin/sh which has print builtin, and thus
configure chooses it. now when building, libtool is called using another
shell (a bash), and
Hi!
I just created the attached patch for findutils to build. Any chance to
get this in your git repo? :) The code is as good as it can get with
interix, i think - improvement suggestions welcome!
Thanks!
Markus
diff -ru findutils-4.5.9.orig/gnulib/lib/mountlist.c findutils-4.5.9/gnulib/lib/mount
> I see that you have FSF copyright assignments on file
> for other projects, but not yet for gnulib.
> Can you start that process?
> Once that's done, we can proceed.
phew - the other assignments are quite a while ago - i can't remember
the exact process. can you help me a little? where can i get
On 10/21/2010 11:59 AM, James Youngman wrote:
> On Thu, Oct 21, 2010 at 10:05 AM, Markus Duft wrote:
>> Hi!
>>
>> I just created the attached patch for findutils to build. Any chance to
>> get this in your git repo? :) The code is as good as it can get with
>&g
Hi!
I just created the attached patch for findutils to build. Any chance to
get this in your git repo? :) The code is as good as it can get with
interix, i think - improvement suggestions welcome!
Thanks!
Markus
diff -ru findutils-4.5.9.orig/gnulib/lib/mountlist.c findutils-4.5.9/gnulib/lib/mount
On 09/30/2010 09:04 PM, Al wrote:
>> A small case study:
>> ~x86-interix support, "currently broken" quote from the lead dev. Not likely
>> to get fixed soon. Causes headaches when trying to migrate packages to
>> Gentoo Linux.
>
> I wonder what is wrong with interix as it is that similar to Cygwi
>
> Regards
>
> --------original message-
> From: "Markus Duft" markus.d...@salomon.at
> To: gentoo-dev@lists.gentoo.org
> Date: Thu, 23 Sep 2010 09:48:00 +0200
> ---------
>
>
>>
On 08/30/2010 09:31 AM, Markus Duft wrote:
> On 08/27/2010 04:26 PM, Jorge Manuel B. S. Vicetto wrote:
>> On 26-08-2010 12:07, Alex Legler wrote:
>>> On Thu, 26 Aug 2010 11:01:27 +0200, Markus Duft
>>> wrote:
>>
>>>> booth registration is not yet ope
On 09/15/2010 04:37 PM, Florian CROUZAT wrote:
On 15 sept. 2010, at 14:46, Al wrote:
I needed to fix a shell expression in python.eselect to match
"python2.6.exe". Currently it is "ls python2.?" and would match
"python2.6" but not the Cygwin binary with the .exe suffix.
[...]
Question: What
On 08/27/2010 04:26 PM, Jorge Manuel B. S. Vicetto wrote:
> On 26-08-2010 12:07, Alex Legler wrote:
>> On Thu, 26 Aug 2010 11:01:27 +0200, Markus Duft
>> wrote:
>
>>> booth registration is not yet open, i will have an eye on this too...
>>> (is there any inte
On 08/26/2010 01:47 PM, Fabian Groffen wrote:
> On 26-08-2010 13:42:05 +0200, Al wrote:
>> When doing"emerge --oneshot --nodeps binutils" I run into errors
>> starting with a missing "sys/user.h". I find no direcotry "sys" in
>> the ".../bfd/" direcory. I did run it twice with the same result,
On 08/26/2010 10:54 AM, Markus Duft wrote:
> On 08/26/2010 08:42 AM, Christopher Warrington wrote:
>> "Al" @ 2010-8-25 3:25 AM:
>>> Yes, Cygwin is not ELF but COFF.
>>
>> I've almost always heard Windows executables called Portable Executables
>&g
1 - 100 of 350 matches
Mail list logo
