Mostly due to x86 and acpi conversion, several documentation
links are still pointing to the old file. Fix them.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/acpi/dsd/leds.txt | 2 +-
Documentation/admin-guide/kernel-parameters.rst | 6 +++---
flight 137052 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137052/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xen-freebsd 7 xen-build-freebsdfail REGR. vs. 136901
version
flight 137041 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137041/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore fail REGR. vs. 136516
Tests which
[ Upstream commit 0383ad4374f7ad7edd925a2ee4753035c3f5508a ]
xen_biovec_phys_mergeable() only needs .bv_page of the 2nd bio bvec
for checking if the two bvecs can be merged, so pass page to
xen_biovec_phys_mergeable() directly.
No function change.
Cc: ris Ostrovsky
Cc: Juergen Gross
Cc:
[ Upstream commit 0383ad4374f7ad7edd925a2ee4753035c3f5508a ]
xen_biovec_phys_mergeable() only needs .bv_page of the 2nd bio bvec
for checking if the two bvecs can be merged, so pass page to
xen_biovec_phys_mergeable() directly.
No function change.
Cc: ris Ostrovsky
Cc: Juergen Gross
Cc:
[ Upstream commit db5ebd6edd2627d7e81a031643cf43587f63e66c ]
XEN has special page merge requirement, see xen_biovec_phys_mergeable().
We can't merge pages into one bvec simply for XEN.
So move XEN's specific check on page merge into __bio_try_merge_page(),
then abvoid to break XEN by multi-page
flight 137033 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137033/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 137003
Fix several warnings and broken links.
This series was generated against linux-next, but was rebased to be applied at
docs-next. It should apply cleanly on either tree.
There's a git tree with all of them applied on the top of docs/docs-next
at:
flight 137026 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137026/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-buildfail REGR. vs. 130965
Referencing the expanding the thread I started several months ago entitled
"Xen 4.12.0-rc Hangs Around masked ExtINT on CPU#", I installed a fresh hard
drive on my Supermicro Atom server class unit and did the following:
per:
branch xen-unstable
xenbranch xen-unstable
job build-amd64-xen-freebsd
testid xen-build-freebsd
Tree: freebsd git://github.com/freebsd/freebsd.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios
flight 137079 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137079/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
Hi,
On Wed, May 29, 2019 at 11:17 PM Julien Grall wrote:
>
> Hi Amit,
>
> Just a quick follow-up. Is there any plan to send a new version of this patch?
>
Sorry for late on this, I would be able to send it(with a comment for
PPI's range) on coming weekend.
Thanks,
-Amit
flight 137020 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137020/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 132889
On 29/05/2019 18:58, Oleksandr wrote:
>
> On 29.05.19 20:44, Julien Grall wrote:
>> Hi Oleksandr,
>
> Hi, Julien
>
>
>>
>> On 21/05/2019 18:37, Oleksandr Tyshchenko wrote:
>>> From: Oleksandr Tyshchenko
>>>
>>> The "interrupts-extended" property is a special form for use when
>>> a node
On 29.05.19 20:44, Julien Grall wrote:
Hi Oleksandr,
Hi, Julien
On 21/05/2019 18:37, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The "interrupts-extended" property is a special form for use when
a node needs to reference multiple interrupt parents. >
According to the:
NIT:
flight 137072 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137072/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
Hi Amit,
Just a quick follow-up. Is there any plan to send a new version of this patch?
Cheers,
On 03/05/2019 18:02, Amit Singh Tomar wrote:
XEN should not forward PPIs to Dom0 as it only support SPIs.
One of solution to this problem is to skip any device that
uses PPI source completely while
Hi Oleksandr,
On 21/05/2019 18:37, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The "interrupts-extended" property is a special form for use when
a node needs to reference multiple interrupt parents. >
According to the:
NIT: s/the//
Hi Oleksandr,
On 21/05/2019 18:37, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Port Linux helper of_count_phandle_with_args for counting
number of phandles in a property.
Please note, this helper is ported from Linux v4.6.
Signed-off-by: Oleksandr Tyshchenko
Acked-by: Julien
Hi,
My understanding is that currently xen hypervisor supports vTPM, but
supports only vTPM1.2. i.e. vTPM can work with TPM 2.0 hardware, but vTPM
as such will support only 1.2 SAPI calls in the frontend-driver. Is that
right? If yes, can you please share if there is a roadmap for supporting
2.0
Hi,
Gentle ping...
Cheers,
On 14/05/2019 13:31, Julien Grall wrote:
Hi all,
This is the third part of the boot/memory rework for Xen on Arm. At the
moment, the update to Xen PT is scattered all around mm.c. This makes
difficult to rework Xen memory layout or even ensuring we are following
Hi,
I am missing some reply/review from Stefano (see below).
On 14/05/2019 13:24, Julien Grall wrote:
Julien Grall (19):
xen/arm: Rework HSCTLR_BASE
More details input on his claim... and review for the following patches:
xen/arm: Remove parameter cpuid from start_xen
xen/arm32:
Hi,
On 20/05/2019 23:56, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
None of the parameters of secondary_start are actually used. So turn
secondary_start to a function with no parameters.
Also modify the assembly code to avoid setting-up the registers before
calling
Ping, it would be good to know which bits I dropped...
On 21/05/2019 11:09, Julien Grall wrote:
Hi,
On 5/20/19 11:56 PM, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
The current value of HSCTLR_BASE for Arm64 is pretty wrong. It would
actually turn on SCTLR_EL2.nAA (bit
Gentle ping
On 14/05/2019 13:11, Julien Grall wrote:
Now that we dropped flush_xen_text_tlb_local(), we have only one set of
helpers acting on Xen TLBs. There naming are quite confusing because the
TLB instructions used will act on both Data and Instruction TLBs.
Take the opportunity to rework
Gentle ping.
On 20/05/2019 20:53, Julien Grall wrote:
Hi,
On 20/05/2019 19:56, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
The AIVIVT is a type of instruction cache available on Armv7. This is
the only cache not implementing the IVIPT extension and therefore
requiring
On 5/29/19 5:27 PM, Julien Grall wrote:
> Hi George,
>
> On 24/05/2019 17:24, George Dunlap wrote:
>> On 5/10/19 2:21 PM, Jan Beulich wrote:
@@ -1099,19 +1100,19 @@ long p2m_pt_audit_p2m(struct p2m_domain *p2m)
entry_count++;
Hi George,
On 24/05/2019 17:24, George Dunlap wrote:
On 5/10/19 2:21 PM, Jan Beulich wrote:
@@ -1099,19 +1100,19 @@ long p2m_pt_audit_p2m(struct p2m_domain *p2m)
entry_count++;
continue;
}
-
flight 137031 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137031/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 136987
On Wed, May 29, 2019 at 10:06:00AM -0600, Jan Beulich wrote:
> >>> On 29.05.19 at 17:57, wrote:
> > Linux 3.18 no longer boots under Xen.
> >
> > This has been true for over half a year. The Xen project CI has been
> > sending automatic mails including bisection reports (see below).
> > I
There is a bug in llvm that needs to be fixed before switching to use
the alternative assembly macros in inline assembly call sites.
Therefore alternative_callN using inline assembly to generate the
alternative patch sites should be using the ALTERNATIVE C preprocessor
macro rather than the
>>> On 29.05.19 at 17:57, wrote:
> Linux 3.18 no longer boots under Xen.
>
> This has been true for over half a year. The Xen project CI has been
> sending automatic mails including bisection reports (see below).
> I emailed Xen kernel folks and got no takers for fixing this.
>
> Unless this
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 29 May 2019 17:00
> To: Paul Durrant
> Cc: Andrew Cooper ; Roger Pau Monne
> ; xen-devel de...@lists.xenproject.org>; WeiLiu
> Subject: Re: [PATCH v3] x86/hvm/hpet: avoid 'small' time diff test on resume
>
>
>>> On 29.05.19 at 16:07, wrote:
> It appears that even 64-bit versions of Windows 10, when not using syth-
> etic timers, will use 32-bit HPET non-periodic timers. There is a test
> in hpet_set_timer(), specific to 32-bit timers, that tries to disambiguate
> between a comparator value that is in
Linux 3.18 no longer boots under Xen.
This has been true for over half a year. The Xen project CI has been
sending automatic mails including bisection reports (see below).
I emailed Xen kernel folks and got no takers for fixing this.
Unless this is fixed soon, or at least someone shows some
On 29/05/2019 11:31, Andrii Anisov wrote:
Hello Julien,
Hi,
On 28.05.19 20:07, Julien Grall wrote:
Title: Interrupts are still unmasked when executing action for interrupt
routed to Xen. So you need to be more specific. How about
"xen/arm: gic: Defer the decision to unmask interrupts to
Hi Volodymyr,
On 29/05/2019 12:40, Volodymyr Babchuk wrote:
On 20/05/2019 14:41, Volodymyr Babchuk wrote:
Julien Grall writes:
If you read my previous e-mail, I didn't completely reject the
approach in my previous e-mail. I pointed out that the user may be
misled of the name and hence
> After a series of tests on 1 or 4 VCPUs, my domain end up in 2 possible
> states:
> - frozen: the mouse doesn't move: so I would guess the VCPU are blocked.
You probably have events pending on the ring that you didn't process.
After you pause the domain and remove the registered evenst,
> > There are three views being used: the default (hostp2m); the
> > execute-view which is active by default and has the remapped
> > shadow-copies of the pages with breakpoints injected at the very end
> > of the guests' physmap; and the read-only view that is only used when
> > someone is trying
It appears that even 64-bit versions of Windows 10, when not using syth-
etic timers, will use 32-bit HPET non-periodic timers. There is a test
in hpet_set_timer(), specific to 32-bit timers, that tries to disambiguate
between a comparator value that is in the past and one that is sufficiently
far
Hi all,
Is there a way to map a region of physical memory to dom0/domU?
Let's say I have a custom device mapped at that memory region and I want
either dom0 or a domU to have full access to this device.
There seems to be a way to share memory between dom0 and a domU, maybe
also between domU
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 29 May 2019 14:37
> To: Paul Durrant
> Cc: Andrew Cooper ; Roger Pau Monne
> ; xen-devel de...@lists.xenproject.org>; WeiLiu
> Subject: Re: [PATCH] x86/hvm/hpet: avoid 'small' time diff test on resume
>
> >>>
>>> On 29.05.19 at 15:09, wrote:
> I notice that we seemingly don't handle main counter wrap in the HPET code.
> The spec. says that timers should fire at the point the counter wraps at the
> timer's width. I think the need for the 'small' time test would go away if
> this was implemented, but
It appears that even 64-bit versions of Windows 10, when not using syth-
etic timers, will use 32-bit HPET non-periodic timers. There is a test
in hpet_set_timer(), specific to 32-bit timers, that tries to disambiguate
between a comparator value that is in the past and one that is sufficiently
far
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 29 May 2019 14:10
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Jan Beulich ;
> Andrew Cooper
> ; Wei Liu ; Roger Pau Monne
>
> Subject: [PATCH] x86/hvm/hpet: avoid 'small' time diff test on
>>> On 29.05.19 at 14:51, wrote:
> On 15/03/2019 10:56, Jan Beulich wrote:
>> @@ -9681,6 +9696,21 @@ x86_emulate(
>> op_bytes = 4;
>> goto simd_imm8_zmm;
>>
>> +case X86EMUL_OPC_EVEX_66(0x0f3a, 0x26): /* vgetmantp{s,d}
>> $imm8,[xyz]mm/mem,[xyz]mm{k} */
>> +case
It appears that even 64-bit versions of Windows 10, when not using syth-
etic timers, will use 32-bit HPET non-periodic timers. There is a test
in hpet_set_timer(), specific to 32-bit timers, that tries to disambiguate
between a comparator value that is in the past and one that is sufficiently
far
On 5/29/19 5:23 AM, Andrew Cooper wrote:
> Drop introduced trailing whitespace, excessively long lines, mal-indention,
> superfluous use of PRI macros for int-or-smaller types, and incorrect PRI
> macros for gfns and mfns.
>
> Signed-off-by: Andrew Cooper
Acked-by: George Dunlap
Sorry about
On 15/03/2019 10:56, Jan Beulich wrote:
> @@ -9681,6 +9696,21 @@ x86_emulate(
> op_bytes = 4;
> goto simd_imm8_zmm;
>
> +case X86EMUL_OPC_EVEX_66(0x0f3a, 0x26): /* vgetmantp{s,d}
> $imm8,[xyz]mm/mem,[xyz]mm{k} */
> +case X86EMUL_OPC_EVEX_66(0x0f3a, 0x54): /*
flight 137014 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137014/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 7 xen-boot fail REGR. vs. 128858
>>> On 29.05.19 at 13:52, wrote:
> Jan Beulich writes:
> On 29.05.19 at 13:35, wrote:
>>> From: Joe Perches
>>>
>>> From: Joe Perches
>>>
>>> There are mode change and rename only patches that are unrecognized
>>> by the get_maintainer.pl script.
>>>
>>> Recognize them.
>>>
>
> [
flight 137047 xen-4.7-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/137047/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 133596
flight 137018 xen-4.6-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/137018/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 127792
Hi Jan,
Jan Beulich writes:
On 29.05.19 at 13:35, wrote:
>> From: Joe Perches
>>
>> From: Joe Perches
>>
>> There are mode change and rename only patches that are unrecognized
>> by the get_maintainer.pl script.
>>
>> Recognize them.
>>
[ Upstream commit
Hi Julien,
Julien Grall writes:
> Hi Volodymyr,
>
> Sorry for the late reply.
It's okay, no worries.
> On 5/20/19 3:57 PM, Volodymyr Babchuk wrote:
>>
>> Julien Grall writes:
>>
>>> Hi,
>>>
>>> On 20/05/2019 14:41, Volodymyr Babchuk wrote:
Julien Grall writes:
> Hi,
>
>
Hi George,
On 28/05/2019 18:29, George Dunlap wrote:
On 5/20/19 4:13 PM, Julien Grall wrote:
Hi,
On 10/05/2019 14:25, Julien Grall wrote:
On 10/05/2019 14:24, Jan Beulich wrote:
On 10.05.19 at 15:02, wrote:
On 10/05/2019 12:35, Jan Beulich wrote:
On 07.05.19 at 17:14, wrote:
---
Ian Jackson writes ("Stable trees (4.6 and 4.7), building on stretch, osstest,
redux"):
> I am still struggling with this. 4.7 and 4.6 still do not build.
I have now pushed all of these to 4.6 and 4.7 and it builds for me.
I will kill the current, doomed, 4.6 and 4.7 flights.
> 1. That old
From: Joe Perches
From: Joe Perches
There are mode change and rename only patches that are unrecognized
by the get_maintainer.pl script.
Recognize them.
Reported-by: Heinrich Schuchardt
CC: Julien Grall
Signed-off-by: Joe Perches
Signed-off-by: Volodymyr Babchuk
---
flight 137050 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137050/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 9abcac7ff14506b934e55d1cfd86575f182b77b7
baseline version:
xen
flight 137022 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137022/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 136910
test-armhf-armhf-libvirt-raw 13
Jan Beulich writes ("Re: Stable trees (4.6 and 4.7), building on stretch,
osstest, redux"):
> On 28.05.19 at 21:59, wrote:
> > 1. That old ipxe is just too badly broken. I spent a long while
> > trying to backport compiler fixes but it is totally ridiculous. IMO
> > our only sensible option is
Hello Julien,
On 28.05.19 20:07, Julien Grall wrote:
Title: Interrupts are still unmasked when executing action for interrupt routed
to Xen. So you need to be more specific. How about
"xen/arm: gic: Defer the decision to unmask interrupts to do_{LPI, IRQ}()"?
Looks good.
On 5/27/19 10:29
flight 137016 qemu-upstream-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137016/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken in 134504
On 29/05/2019 11:57, Jan Beulich wrote:
On 29.05.19 at 11:04, wrote:
>> @@ -345,8 +346,11 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t
>> size, void *vaddr,
>> size = 1UL << (order + XEN_PAGE_SHIFT);
>>
>> if (!WARN_ON((dev_addr + size - 1 > dma_mask) ||
>> -
In particular with an enabled IOMMU (but not really limited to this
case), trying to invoke fixup_irqs() after having already done
disable_IO_APIC() -> clear_IO_APIC() is a rather bad idea:
RIP:e008:[] amd_iommu_read_ioapic_from_ire+0xde/0x113
RFLAGS: 00010006 CONTEXT: hypervisor
flight 137021 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137021/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ec56fa27842835e69a2b89b602866c3d652315eb
baseline version:
ovmf
On 27/05/2019 09:02, Jan Beulich wrote:
On 24.05.19 at 22:48, wrote:
>> On 24/05/2019 07:43, Jan Beulich wrote:
>> On 23.05.19 at 18:15, wrote:
On 15/03/2019 10:55, Jan Beulich wrote:
> Also include the only other AVX512ER insn pair, VEXP2P{D,S}.
>
> Note that despite
>>> On 29.05.19 at 11:04, wrote:
> @@ -345,8 +346,11 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t
> size, void *vaddr,
> size = 1UL << (order + XEN_PAGE_SHIFT);
>
> if (!WARN_ON((dev_addr + size - 1 > dma_mask) ||
> -
>>> On 29.05.19 at 11:04, wrote:
> The condition in xen_swiotlb_free_coherent() for deciding whether to
> call xen_destroy_contiguous_region() is wrong: in case the region to
> be freed is not contiguous calling xen_destroy_contiguous_region() is
> the wrong thing to do: it would result in
flight 137015 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137015/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 133580
Tests which did
Instead of always calling xen_destroy_contiguous_region() in case the
memory is DMA-able for the used device, do so only in case it has been
made DMA-able via xen_create_contiguous_region() before.
This will avoid a lot of xen_destroy_contiguous_region() calls for
64-bit capable devices.
As the
The condition in xen_swiotlb_free_coherent() for deciding whether to
call xen_destroy_contiguous_region() is wrong: in case the region to
be freed is not contiguous calling xen_destroy_contiguous_region() is
the wrong thing to do: it would result in inconsistent mappings of
multiple PFNs to the
range_straddles_page_boundary() is open coding several macros from
include/xen/page.h. Use those instead. Additionally there is no need
to have check_pages_physically_contiguous() as a separate function as
it is used only once, so merge it into range_straddles_page_boundary().
Signed-off-by:
While hunting an issue in swiotlb-xen I stumbled over a wrong test
and found some areas for improvement.
Juergen Gross (3):
xen/swiotlb: fix condition for calling xen_destroy_contiguous_region()
xen/swiotlb: simplify range_straddles_page_boundary()
xen/swiotlb: remember having called
>>> On 29.05.19 at 06:10, wrote:
> This also introduced the top-level Guest Documentation section.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
with one further remark / question:
> +Hypercall Page
> +==
> +
> +The hypercall page is a page of guest RAM into which Xen
>>> On 29.05.19 at 06:23, wrote:
> Drop introduced trailing whitespace, excessively long lines, mal-indention,
> superfluous use of PRI macros for int-or-smaller types, and incorrect PRI
> macros for gfns and mfns.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
>>> On 29.05.19 at 06:43, wrote:
> On 29/05/2019 05:23, Andrew Cooper wrote:
>> Drop introduced trailing whitespace, excessively long lines, mal-indention,
>> superfluous use of PRI macros for int-or-smaller types, and incorrect PRI
>> macros for gfns and mfns.
>>
>> Signed-off-by: Andrew Cooper
>>> On 28.05.19 at 21:59, wrote:
> Ian Jackson writes ("[PATCH STABLE] tools/firmware: update OVMF Makefile,
> when necessary"):
>> Now done, including for staging-4.6. 4.6 is out of security support,
>> but osstest wants to be able to build 4.6 so that it can test
>> migration from 4.6 to 4.7,
flight 137024 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137024/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 133596
build-i386-xsm
Am Tue, 28 May 2019 20:59:24 +0100
schrieb Ian Jackson :
> I am still struggling with this. 4.7 and 4.6 still do not build.
I maintain the various staging-X.Y branches for various releases,
just for my own entertainment. The remaining build error in SLE_15
(and Tumbleweed) is some asm error in
81 matches
Mail list logo
