The workaround I described above is actually not the good one, because
of this check occurring just before:
if (!all_cpu_threads_idle()) {
return;
}
The exit request setting must be done before, so my code looks like
this:
CPUState *cpu;
CPU_FOREACH(cpu) {
atomic
Public bug reported:
A basic program runs fine if compiled with flag -O0 with gcc, but triggers a
qemu abort when compiled with -O1 and run with icount:
"qemu: fatal: IO on conditional branch instruction"
I also noticed the problem on C source like this with -O0:
"int foo = *bar; bar++;" : OK
"i
I just tested the patch and it resolves this problem. Thanks!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1755479
Title:
Cortex M:qemu abort with optimized code and icount
Status in QEMU:
New
Hi Peter,
I just tested your patch, I confirm it is also working on my side. Many
thanks.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1754038
Title:
ARM M: Systick first wrap delayed (qemu-timer
Public bug reported:
When running this kind of code with qemu:
static void SysTickISR(void)
{
printf("SysTick\n");
}
void main()
{
volatile int i, j;
printf("setup timer\n");
*(uint32_t*) 0xE000E014 = 0x8F; //reload value
*(uint32_t*) 0xE000E018 = 0;
I tried to insert an ISB in the loop but I get more or less the same
result.
However, I guess from your response that I did not explain the problem
well enough. I understand that qemu will not be cycle accurate, however,
here, we are not even "one million cycles accurate"! The counter would
have t
Please find the binary attached.
I have been trying several versions and it looks like the regression
occured between v2.8.0 and v2.9.0.
** Attachment added: "Binary showing systick /timers/icount problem"
https://bugs.launchpad.net/qemu/+bug/1754038/+attachment/5072853/+files/hello.bin
--
Ok I spent more time trying to identify the commits giving problem.
So before 8d04fb5, qemu is executing the binary as expected:
setup timer
cnt 007a --7
cnt 006998a2 --7
cnt 00566479 --7
cnt 0043304f --7
cnt 002ffc26 --7
cnt 001cc7fd --7
I finally implemented a workaround to correct the problem:
in cpus.c : qemu_start_warp_timer(), in the "if (deadline > 0) { ... }"
part, I added:
CPUState *cpu;
CPU_FOREACH(cpu) {
atomic_mb_set(&cpu->exit_request, 1);
}
I do not understand more than 5% of the
On 12/04/2012 06:42 PM, Peter Maydell wrote:
This looks good as far as the logic goes, but I think we could use
some symbolic constants for the 12-hour and PM bits rather than all
the literal 0x20 0x40 0x60. thanks -- PMM
I refrained from using symbolic constants for three reasons:
1. You need
This is the second version of my series of patch to hw/ds1338.c
It should address the various points that were made. The main difference
with the previous version is that I dropped some stuff that will only be
useful once we implement clock enable/disable.
Signed-off-by: Antoine Mathys
---
hw/ds1338.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index b576d56..faaa4a0 100644
--- a/hw/ds1338.c
+++ b/hw/ds1338.c
@@ -57,9 +57,9 @@ static void capture_current_time(DS1338State *s)
} else
Signed-off-by: Antoine Mathys
---
hw/ds1338.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index faaa4a0..69018bc 100644
--- a/hw/ds1338.c
+++ b/hw/ds1338.c
@@ -17,6 +17,12 @@
*/
#define NVRAM_SIZE 64
+/* Flags definitions */
+#define SECONDS_CH
Per the datasheet, the mapping between 12 and 24 hours modes is:
0 <-> 12 PM
1-12 <-> 1-12 AM
13-23 <-> 1-11 PM
Signed-off-by: Antoine Mathys
---
hw/ds1338.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-
Signed-off-by: Antoine Mathys
---
hw/ds1338.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index 0f88720..b4d5b74 100644
--- a/hw/ds1338.c
+++ b/hw/ds1338.c
@@ -179,6 +179,15 @@ static int ds1338_init(I2CSlave *i2c)
return 0;
}
+static void
The previous patch has the side effect of clearing the control register.
That's already its proper power-on-reset value.
Signed-off-by: Antoine Mathys
---
hw/ds1338.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
Per the datasheet, the DAY (wday) register is user defined. Implement this.
Signed-off-by: Antoine Mathys
---
hw/ds1338.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index 319c341..c5cee99 100644
--- a/hw/ds1338.c
+++ b/hw
On 12/12/2012 01:05 PM, Peter Maydell wrote:
I think we need to reset ptr and addr_byte too...
The initial value of the register pointer is unspecified.
addr_byte is only used when receiving user data. It is written in
ds1338_event() then read in ds1338_send(). Setting it in ds1338_reset()
is
It's true that it probably doesn't make much difference, but
both the addr_byte and ptr are part of the migration state
listed in the vmstate struct. I think it is cleaner and
more straightforward to reason about if resetting the
device returns it to an exact known state. The state may be
undefi
Signed-off-by: Antoine Mathys
---
hw/ds1338.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index faaa4a0..69018bc 100644
--- a/hw/ds1338.c
+++ b/hw/ds1338.c
@@ -17,6 +17,12 @@
*/
#define NVRAM_SIZE 64
+/* Flags definitions */
+#define SECONDS_CH
Signed-off-by: Antoine Mathys
---
hw/ds1338.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index b576d56..faaa4a0 100644
--- a/hw/ds1338.c
+++ b/hw/ds1338.c
@@ -57,9 +57,9 @@ static void capture_current_time(DS1338State *s)
} else
Signed-off-by: Antoine Mathys
---
hw/ds1338.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index d2f52fc..94a2f54 100644
--- a/hw/ds1338.c
+++ b/hw/ds1338.c
@@ -125,7 +125,8 @@ static int ds1338_send(I2CSlave *i2c, uint8_t
Per the datasheet, the mapping between 12 and 24 hours modes is:
0 <-> 12 PM
1-12 <-> 1-12 AM
13-23 <-> 1-11 PM
Signed-off-by: Antoine Mathys
---
hw/ds1338.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-
Per the datasheet, the DAY (wday) register is user defined. Implement this.
Signed-off-by: Antoine Mathys
---
hw/ds1338.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index 94a2f54..1aefa3b 100644
--- a/hw/ds1338.c
+++ b/hw
Signed-off-by: Antoine Mathys
---
hw/ds1338.c | 51 ++-
1 file changed, 38 insertions(+), 13 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index b576d56..d2f52fc 100644
--- a/hw/ds1338.c
+++ b/hw/ds1338.c
@@ -17,6 +17,12 @@
*/
#define
Oops. There was a problem in the patch. Resending the series.
Signed-off-by: Antoine Mathys
---
hw/ds1338.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index b576d56..faaa4a0 100644
--- a/hw/ds1338.c
+++ b/hw/ds1338.c
@@ -57,9 +57,9 @@ static void capture_current_time(DS1338State *s)
} else
Signed-off-by: Antoine Mathys
---
hw/ds1338.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index faaa4a0..69018bc 100644
--- a/hw/ds1338.c
+++ b/hw/ds1338.c
@@ -17,6 +17,12 @@
*/
#define NVRAM_SIZE 64
+/* Flags definitions */
+#define SECONDS_CH
Per the datasheet, the mapping between 12 and 24 hours modes is:
0 <-> 12 PM
1-12 <-> 1-12 AM
13-23 <-> 1-11 PM
Signed-off-by: Antoine Mathys
---
hw/ds1338.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-
Signed-off-by: Antoine Mathys
---
hw/ds1338.c | 12
1 file changed, 12 insertions(+)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index 0f88720..d2f52fc 100644
--- a/hw/ds1338.c
+++ b/hw/ds1338.c
@@ -179,6 +179,17 @@ static int ds1338_init(I2CSlave *i2c)
return 0;
}
+static
Per the datasheet, the DAY (wday) register is user defined. Implement this.
Signed-off-by: Antoine Mathys
---
hw/ds1338.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index 94a2f54..1aefa3b 100644
--- a/hw/ds1338.c
+++ b/hw
Signed-off-by: Antoine Mathys
---
hw/ds1338.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index d2f52fc..94a2f54 100644
--- a/hw/ds1338.c
+++ b/hw/ds1338.c
@@ -125,7 +125,8 @@ static int ds1338_send(I2CSlave *i2c, uint8_t
On 12/13/2012 03:09 PM, Peter Maydell wrote:
I certainly will send further patches.
As you noticed I am new to git. Thanks for your patience and advice.
Public bug reported:
get_next_alarm() doesn't read the RTC_HOURS_ALARM field correctly.
- Bit 7 must be masked before conversion from BCD.
- Care must be taken to check the don't care condition before masking.
- The PM bit must be read from RTC_HOURS_ALARM, not from RTC_HOURS (as is done
in conv
The proper mapping between 24 hours and 12 hours modes is:
0 12 AM
1-111-11 AM
12 12 PM
13-23 1-11 PM
Fix code accordingly.
Signed-off-by: Antoine Mathys
---
hw/ds1338.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
This patch consolidates the bit twidling involved in reading and
writing the time registers to four functions that are used consistently.
This also has the effect of fixing bug 1090558.
Signed-off-by: Antoine Mathys
---
hw/mc146818rtc.c | 163
On 02/14/2013 10:30 AM, Paolo Bonzini wrote:
Nice. Do you have a testcase?
No, but the refactoring makes the code very easy to audit.
Please also test this patch with the two rtc-test patches at
http://thread.gmane.org/gmane.comp.emulators.qemu/188244.
I did and the tests pass.
First, the ds1338 code was in a poor state and never handled the 12 hour
clock correctly. My first patch failed to fully fix the problem so I had
to write a second one, but at no point did Peter or I introduce a
regression, quite the opposite.
Second, I don't know where you got the idea that I
On 02/15/2013 12:24 PM, Andreas Färber wrote:
The expected answer would've been "take guest X and do Y to see Z", or
better to extend the existing qtest cases to prove something was broken
before and fixed afterwards and to avoid the same bug being reintroduced
later.
If we are talking about ad
Signed-off-by: Antoine Mathys
---
hw/ds1338.c | 156 ---
1 file changed, 95 insertions(+), 61 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index 1da0f96..5a93fb6 100644
--- a/hw/ds1338.c
+++ b/hw/ds1338.c
@@ -48,17 +48,32
Per the datasheet, the mapping between 12 and 24 hours modes is:
0 <-> 12 PM
1-12 <-> 1-12 AM
13-23 <-> 1-11 PM
Signed-off-by: Antoine Mathys
---
hw/ds1338.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git
Minor fixes in the handling of the RTC registers.
Signed-off-by: Antoine Mathys
---
hw/ds1338.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index 1274b22..1fb152e 100644
--- a/hw/ds1338.c
+++ b/hw/ds1338.c
@@ -62,9 +62,9
Per the datasheet, the OSF bit in the control register can only be
cleared. Attempts to set it have no effect. Implement this.
Signed-off-by: Antoine Mathys
---
hw/ds1338.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index 1fb152e
supposed to set these bits it is safer to check
anyway. In order not to duplicate this logic I thus chose to enforce it
at read time.
Note that currently we don't preserve what the user sends in (2). We
will have to once we support stopping the clock (CH bit).
Signed-off-by: Antoine Mathys
--
Per the datasheet, the DATE (wday) register is user defined. Implement this.
Signed-off-by: Antoine Mathys
---
hw/ds1338.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index 8f85635..c502934 100644
--- a/hw/ds1338.c
+++ b/hw
From: Antoine Damhet
The new `qcrypto_tls_session_check_pending` function allows the caller
to know if data have already been consumed from the backend and is
already available.
Signed-off-by: Antoine Damhet
---
crypto/tlssession.c | 14 ++
include/crypto/tlssession.h | 11
From: Antoine Damhet
At least with the TCP backend the tls implementation can stall because
the current notification mechanism is based on the readyness status of
the underlying file descriptor but gnutls can read all the data
available while the consumer has only handled part (eg: the TCP
From: Antoine Damhet
Since the TLS backend can read more data from the underlying QIOChannel
we introduce a minimal child GSource to notify if we still have more
data available to be read.
Signed-off-by: Antoine Damhet
Signed-off-by: Charles Frey
---
io/channel-tls.c | 66
e done
> before sending bytes to a character device to see how much it can handle,
> so the s->max_size in tcp_chr_read() still contains the old value from the
> previous read. Let's make sure that we use the up-to-date value by calling
> tcp_chr_read_poll() again here.
>
> Fixes:
ing GLOBAL_STATE_CODE in IO_CODE is allowed, since GSC callers are
> allowed to call IO_CODE.
>
> Resolves: #1272
>
> Signed-off-by: Emanuele Giuseppe Esposito
Tested-by: Antoine Damhet
> ---
> block/block-backend.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
--
Antoine 'xdbob' Damhet
signature.asc
Description: PGP signature
On Wed, Nov 16, 2022 at 10:52:20AM +, Daniel P. Berrangé wrote:
> On Tue, Nov 15, 2022 at 03:23:29PM +0100, antoine.dam...@shadow.tech wrote:
> > From: Antoine Damhet
> >
> > Since the TLS backend can read more data from the underlying QIOChannel
> > we introduce
> The docs for `g_source_add_child_source(source, child_source)` says
> "source will hold a reference on child_source while child_source is
> attached to it." Therefore, we should unreference the child source at
> `qio_channel_tls_read_watch()` after attaching it to `source`. Wit
good. Which leads me to ask,
what should I do when I get such a failed access? What can I do so that qemu
somehow allocate or wire up the device access?
I work on x86_64 frontend and backend.
Thanks for your time,
Antoine.
From: Antoine Damhet
The `detect-zeroes=unmap` option may issue unaligned
`FALLOC_FL_PUNCH_HOLE` requests, raw block devices can (and will) return
`EINVAL`, qemu should then write the zeroes to the blockdev instead of
issuing an `IO_ERROR`.
Signed-off-by: Antoine Damhet
---
block/file-posix.c
From: Antoine Damhet
The `detect-zeroes=unmap` option may issue unaligned
`FALLOC_FL_PUNCH_HOLE` requests, raw block devices can (and will) return
`EINVAL`, qemu should then write the zeroes to the blockdev instead of
issuing an `IO_ERROR`.
Signed-off-by: Antoine Damhet
---
I am resending
On Mon, Jul 20, 2020 at 04:07:26PM +0200, Kevin Wolf wrote:
> Am 17.07.2020 um 15:56 hat antoine.dam...@blade-group.com geschrieben:
> > From: Antoine Damhet
> >
> > The `detect-zeroes=unmap` option may issue unaligned
> > `FALLOC_FL_PUNCH_HOLE` requests, raw block de
f the signature is found in any of the
exposed tables.
[1]:
https://lore.kernel.org/qemu-devel/1441220618-4750-1-git-send-email-rjo...@redhat.com/
--
Antoine 'xdbob' Damhet
On Wed, Nov 25, 2020 at 11:04:55AM -0500, Michael S. Tsirkin wrote:
> On Wed, Nov 25, 2020 at 01:32:51PM +, Richard W.M. Jones wrote:
> > On Wed, Nov 25, 2020 at 02:27:11PM +0100, Antoine Damhet wrote:
> > > Hello,
> > >
> > > We recently found out that som
On Thu, Nov 26, 2020 at 06:09:11AM -0500, Michael S. Tsirkin wrote:
> On Wed, Nov 25, 2020 at 09:13:22PM +0100, Antoine Damhet wrote:
> > On Wed, Nov 25, 2020 at 11:04:55AM -0500, Michael S. Tsirkin wrote:
> > > On Wed, Nov 25, 2020 at 01:32:51PM +, Richard W.M. Jones wro
On Thu, Nov 26, 2020 at 08:29:41AM -0500, Michael S. Tsirkin wrote:
> On Thu, Nov 26, 2020 at 01:50:12PM +0100, Antoine Damhet wrote:
> > On Thu, Nov 26, 2020 at 06:09:11AM -0500, Michael S. Tsirkin wrote:
> > > On Wed, Nov 25, 2020 at 09:13:22PM +0100, Antoine Damhet wrote:
>
On Thu, Nov 26, 2020 at 12:09:13PM -0500, Michael S. Tsirkin wrote:
> On Thu, Nov 26, 2020 at 05:34:50PM +0100, Antoine Damhet wrote:
> > On Thu, Nov 26, 2020 at 08:29:41AM -0500, Michael S. Tsirkin wrote:
> > > On Thu, Nov 26, 2020 at 01:50:12PM +0100, Antoine Damhet wrote:
>
on migration.
> Use KVM_CAP_ADJUST_CLOCK check instead of CPUID feature bits.
>
> Reported-by: Antoine Damhet
> Suggested-by: Paolo Bonzini
> Signed-off-by: Vitaly Kuznetsov
Tested-by: Antoine Damhet
> ---
> hw/i386/kvm/clock.c| 7 +--
> hw/i386/microvm.c
ow to keep migration compatibility between qemu versions.
Thank you all,
--
Antoine 'xdbob' Damhet
signature.asc
Description: PGP signature
On Wed, Sep 16, 2020 at 12:29:56PM +0100, Dr. David Alan Gilbert wrote:
> cc'ing in Vitaly who knows about the hv stuff.
Thanks
>
> * Antoine Damhet (antoine.dam...@blade-group.com) wrote:
> > Hi,
> >
> > We are experiencing timestamp rollbacks during live-mi
On Wed, Sep 16, 2020 at 01:59:43PM +0200, Vitaly Kuznetsov wrote:
> "Dr. David Alan Gilbert" writes:
>
> > cc'ing in Vitaly who knows about the hv stuff.
> >
>
> cc'ing Marcelo who knows about clocksources :-)
>
> > * Antoine D
>
> (I don't think we need to remove all 'if (kvm_enabled())' checks from
> machine types as 'kvm=off' should not be related).
Indeed (I didn't look at the macro, it was just quick & dirty).
>
> --
> Vitaly
>
>
--
Antoine 'xdbob' Damhet
signature.asc
Description: PGP signature
onally, it seems
> to always make sense to call KVM_GET_CLOCK/KVM_SET_CLOCK on migration.
> Use KVM_CAP_ADJUST_CLOCK check instead of CPUID feature bits.
>
> Reported-by: Antoine Damhet
> Suggested-by: Paolo Bonzini
> Signed-off-by: Vitaly Kuznetsov
> ---
> hw/i386/kvm/c
he migration stream - what is this clock going to do?
I guess that if the migration succeed (and the VMState keeps it's
initial value) the timestamp will be restored to 0 which is the current
behavior.
>
> Dave
[...]
--
Antoine 'xdbob' Damhet
signature.asc
Description: PGP signature
; > The other question is in the incoming direction from an older VM;
> > > you'll have a kvm clock created here, but you won't load the kvm clock
> > > state from the migration stream - what is this clock going to do?
> >
> > This is not really a problem I believe: the clock was absent on the
> > source and things somehow worked for the guest so even if we don't
> > initialize kvmclock properly on the destination nothing bad is expected.
>
> OK.
>
> Dave
[...]
--
Antoine 'xdbob' Damhet
signature.asc
Description: PGP signature
rest of the payload) producing an invalid one
and making guests fail to acquire a DHCP lease.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2727
Cc: qemu-sta...@nongnu.org
Signed-off-by: Antoine Damhet
---
v2: Rebased on master due to conflict with c17ad4b11bd2 (
"virtio-net
On Fri, Apr 11, 2025 at 05:01:01PM +0900, Akihiko Odaki wrote:
> On 2025/04/07 17:29, Antoine Damhet wrote:
> > On Sat, Apr 05, 2025 at 05:04:28PM +0900, Akihiko Odaki wrote:
> > > The goal of commit 7987d2be5a8b ("virtio-net: Copy received header to
> > > buffer&q
>
> Fixes: 7987d2be5a8b ("virtio-net: Copy received header to buffer")
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2727
> Cc: qemu-sta...@nongnu.org
> Signed-off-by: Akihiko Odaki
Tested-By: Antoine Damhet
> ---
> This patch aims to resolves the iss
ert
> "virtio-net: Copy received header to buffer""), with a fix in the
> superseded patch. It also renames identifiers according to the
> discussion with Antoine Damhet.
> ---
> Changes in v2:
> - Rewrote the message avoiding archeology as suggested by
> Michael
rest of the payload) producing an invalid one
and making guests fail to acquire a DHCP lease.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2727
Cc: qemu-sta...@nongnu.org
Signed-off-by: Antoine Damhet
---
hw/net/virtio-net.c | 85 +
1 file
Any chance to get this reviewed/applied any time soon ? It currently
does not build without it with gcc 4.6.0
On 29 April 2011 17:59, Marc-Antoine Perennou wrote:
> pulse/simple.h does not include stdlib.h
> We cannot use NULL since it may not be defined
> Use 0 instead
>
> Sign
On 4 June 2011 00:54, malc wrote:
> On Sat, 4 Jun 2011, Aurelien Jarno wrote:
>
>> On Sat, Jun 04, 2011 at 01:57:23AM +0400, malc wrote:
>> > On Fri, 3 Jun 2011, Aurelien Jarno wrote:
>> >
>> > > On Fri, Apr 29, 2011 at 05:59:19PM +0200, Marc-Antoine Pe
On 10 June 2011 09:14, Markus Armbruster wrote:
> Peter Maydell writes:
>
>> On 9 June 2011 18:44, Andreas Färber wrote:
>>> Am 09.06.2011 um 17:52 schrieb Marc-Antoine Perennou:
>>>> Manually including stddef.h or replacing NULL by 0 or (void*)0 makes it
>&g
pulse/simple.h does not include stdlib.h
We cannot use NULL since it may not be defined
Use 0 instead
Signed-off-by: Marc-Antoine Perennou
---
configure |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure b/configure
index ea8b676..d67c3ce 100755
--- a/configure
80 matches
Mail list logo
