select proper boot device or insert boot media in selected boot
>device and press a key.
Why are you trying to boot DVD#3? DVD#1 is the bootable disk, the rest
of the media set just contain extra packages...
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Googl
al
>information.
>If you are not the addressee of this message, please delete this message and
>kindly
>notify the sender as soon as possible, do not copy, use, or disclose this
>message.
If you're contributing to open source projects, you should probably do
something about this daft message,
main
>#deb-src http://deb.debian.org/debian/ buster main
Right, that's as expected. The only non-free bit about those images is
that they include some non-free firmware packages too. Otherwise
they're just the same as the normal free images. Is there a problem
with that?
--
Steve McIn
ort key verification on kernels, I guess there is no secure way to
>get syslinux booting under secure boot without compromising secure boot,
>but I might be missing an important point about SB here...).
No, you're correct. syslinux is not in a state to do SB at all, and I
can't see it happeni
[ Gah, missed this bit... ]
On Thu, Feb 14, 2019 at 05:35:48PM +0100, Thomas Schmitt wrote:
...
>Maybe Steve McIntyre can contribute an anecdote how he came to the
>decision in debian-cd to use GRUB2 for EFI and thus to create the need
>for two independent boot menu configurations.
W
option,
>Matthew J. Garrett equipped his Fedora ISOs by EFI software from GRUB2
>together with BIOS software from SYSLINUX. (Plus some HFS+ filesystem
>image pointed to by an Apple Partition Map.)
>Maybe Steve McIntyre can contribute an anecdote how he came to the
>decision in debia
Hi Hideki,
On Tue, Feb 12, 2019 at 02:16:30AM +, Steve McIntyre wrote:
>Control: reopen -1
>
>Hi Hideki,
>
>I'm afraid your fix in choose_partition/lvm/do_option is broken. It's
>causing problems for other people trying to use LVM in d-i. See
>#922100, which I've just con
belongs to this package.
It does, yes.
Maybe you're seeing another instance of what was reported as #922100,
caused by the broken bugfix for #911036. I'm about to revert that
change.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"The problem with
TF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
From: Steve McIntyre <93...@debian.org>
Date: Tue, 12 Feb 2019 02:23:14 +
Subject: grub-install: check for arm-efi as a default target
Much like on x86, we can work out if the system is running on top of
EFI firmwa
t;4. select "論理ボリュームマネージャーの設定 (Configure the Logical Volume Manager)"
>-> "論理ボリュームの削除 (Delete logical volue)" and any volume
>5. Got error
>6. select "戻る (go back) and "言語の選択/Change language" to "English"
>7. select "Confi
ot;inVGbuster-vg"
>when the volume group is actually named "buster-vg".
>The rest of the install went OK. I only do a minimal install though.
ACK, confirmed. This is down to an apparently buggy fix for another
reported issue (#911036). Re-opening that now.
Thanks for you
On Mon, Feb 11, 2019 at 03:34:24PM +0100, Wolfgang Schweer wrote:
>On Mon, Feb 11, 2019 at 02:06:33PM +0000, Steve McIntyre wrote:
>> >Yes. And I guess Debian Edu could get around the scan issuue using this
>> >additional preseeding:
>> >
>> >apt-cdrom-s
ot;
will all sort before "libc".
Should we at least simply rename libc.conf to 00libc.conf to make this
bit work? Adding a simple rename for that would seem to be the right
answer as a start?
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Who needs computer imagery when you've got Brian Blessed?
On Mon, Feb 11, 2019 at 01:32:58PM +0100, Wolfgang Schweer wrote:
>Hi Steve,
>
>On Mon, Feb 11, 2019 at 02:27:47AM +0000, Steve McIntyre wrote:
>> With a type of bluray/not_complete, we'll then get the following
>> behaviour from the current apt-setup code:
>>
>>
[ Dropping Lucas from CC here... ]
Hi Wolfgang,
Finally getting back to this - it's been a busy couple of weeks...!
On Sat, Jan 26, 2019 at 11:24:40AM +0100, Wolfgang Schweer wrote:
>Hi Steve,
>
>On Fri, Jan 25, 2019 at 11:58:08PM +0000, Steve McIntyre wrote:
>> So I've been
>
>The HDMI audio didn't work, but restarting PulseAudio fixed that.
>
>Before anyone asks: yes, I'm going to submit this through reportbug. I
>wanted this here as well, at least partly to help anyone experiencing the
>same problems (since this mailing list is more likely to turn
Package: geeqie
Version: 1:1.3-1+b1
Severity: important
Hi,
My system has a few auutofs mounts configured as mount points on the
root filesystem, which normally resolve to network shares on my home
network. When I'm away from home, prodding them incurs a delay as
remote mounts timeout/fail.
On Mon, Jan 28, 2019 at 10:34:54AM -0800, Steve Langasek wrote:
>On Mon, Jan 28, 2019 at 12:45:22PM +0000, Steve McIntyre wrote:
>> Hi Alastair,
>
>> On Mon, Jan 28, 2019 at 09:50:30AM +, Alastair McKinstry wrote:
>
>> >Yes, thanka for this patch. I'm reluctant t
ay soon. Our plan is to
switch to building for armel and armhf using arm64 machines before too
long, which would reliably break all packages with bugs like this.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Into the distance, a ribbon of black
Stretched
On Sun, Jan 27, 2019 at 08:28:41PM +, Brian Potkin wrote:
>On Sun 27 Jan 2019 at 17:56:34 +0000, Steve McIntyre wrote:
>
>> On Sun, Jan 20, 2019 at 04:22:41PM -0800, Tassia Camoes Araujo wrote:
>> >Hi folks,
>> >
>> >I would add to the issue the port
st recent uploaders of
lilo-installer, I'm instead thinking that it's time we remove the
package instead. Upstream lilo development looks to have stopped
again, and I'm not convinced we're helping our users if we continue to
claim to support lilo.
--
Steve McIntyre, Cambridge, UK.
quot;Automatic account creation disabled to stop spammers signing
up. Please contact $admin_private and describe what you want to do in
the wiki."
How does that sound?
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"I can't ever sleep on planes ... ca
ome back to this again shortly. To help with that, could you
describe exactly what debian-edu is expecting here please, i.e. what
the settings in cd_type mean for the debian-edu installer? I'm worried
that we may not have a clear solution here that can match the current
expectations of both d-i and and the debian-edu setup.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Who needs computer imagery when you've got Brian Blessed?
[ Please make sure you CC the Debian BTS on replies too, so other
people can see responses too ]
On Tue, Jan 22, 2019 at 11:53:15AM +, Mikaela Suomalainen wrote:
>Hi,
>
>On Tue, 22 Jan 2019 at 00:30, Steve McIntyre wrote:
>> Has the Windows update somehow re-enabled Secure
be a problem with UEFI
Secure Boot. We don't (quite) have Secure Boot working in Debian, so
you would have had to disable it to get Debian working in the first
place.
Has the Windows update somehow re-enabled Secure Boot? Could you check
in yor firmware/BIOS settings please?
--
Steve McIntyre, Cambr
Package: tracker.debian.org
Severity: normal
Hi folks,
Thanks for the great service on tracker. It really makes my life
easier when doing Debian work!
I've just been looking at the details for sbsigntool
(https://tracker.debian.org/pkg/sbsigntool) It looks like the tracker
code is confused by
find such setups. One of my own test systems at home
has root on LVM, no issues.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"Arguing that you don't care about the right to privacy because you have
nothing to hide is no different than saying you do
Forgot to add the bug in on the mails I just sent. Wookey has been
working through how to do some of this. See:
* https://lists.debian.org/debian-boot/2019/01/msg00183.html
* https://lists.debian.org/debian-boot/2019/01/msg00184.html
and my responses there.
--
Steve McIntyre, Cambridge, UK
o access this!/p
Hi Howard,
What you're seeing is that the wiki is blocking access from your IP,
most likely due to spammy behaviour from it or a nearby IP
address. Please mail w...@debian.org with your IP address (so it will
stay private rather than shared in the bug log here) and we can w
)
Booting from Floppy...
Boot failed: could not read the boot disk
Booting from Hard Disk...
...
and then things hang. What am I missing? If I remove the "if=virtio"
from both drive stanzas, I at least get to the isolinux menu.
--
Steve McIntyre, Cambridge, UK.st...@einval
nds to abuse reports. Please find a better
ISP if you can.
I've removed the block on that network block for now, but if spam
attacks resume then it may be re-added.
--
Steve McIntyre93...@debian.org
Debian wiki admin - wiki.debian.org
; esac
This would clearly be the right thing to do too if we changed the
grub_package setting at the top. Maybe if we just change that to match
grub-efi-amd64 for now?
I'm about to test this lot locally and double-check it DTRT for both
amd64/efi with -signed and i386/efi (without), anyway.
--
Steve
On Sun, Jan 13, 2019 at 05:34:41PM +, Steve McIntyre wrote:
>
>I'm about to test this lot locally and double-check it DTRT for both
>amd64/efi with -signed and i386/efi (without), anyway.
And all looks good in both cases. Committing now.
--
Steve McIntyre, Camb
On Sat, Jan 12, 2019 at 03:09:57PM +, Colin Watson wrote:
>On Sat, Jan 12, 2019 at 02:20:49PM +0000, Steve McIntyre wrote:
>> I'd possibly do both? grub-installer is one obvious place to make d-i
>> add things (and the patch there also looks fairly obvious, roughly
>> w
On Sat, Jan 12, 2019 at 01:51:41PM +, Colin Watson wrote:
>On Sat, Jan 12, 2019 at 12:58:52PM +0000, Steve McIntyre wrote:
>> NB: Ubuntu doesn't have the depends/recommends here, so I can only
>> assume that some other method is used to ensure that shim-signed is
>> ins
On Sat, Jan 12, 2019 at 01:06:22AM +0100, Andreas Henriksson wrote:
>On Tue, Dec 04, 2018 at 02:53:22AM +0000, Steve McIntyre wrote:
>> ACK, thanks for the pointer. I'm a few releases behind due to lack of
>> time. Hoping to get that fixed shortly...
>
>For your convenince I
Package: grub-efi-amd64-signed
Version: 1+2.02+dfsg1+9
Severity: normal
Tags: patch
Hi!
Working through the last pieces of secure boot support for Buster, I
have a working installer build and a working netinst that boot with SB
enabled and do all the right things. Yay!
The're only one thing
lab,
elpa and p4est.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
< Aardvark> I dislike C++ to start with. C++11 just seems to be
handing rope-creating factories for users to hang multiple
instances of themselves.
On Tue, Jan 08, 2019 at 02:12:06PM +, Steve McIntyre wrote:
>On Tue, Jan 08, 2019 at 10:42:01AM +, Alastair McKinstry wrote:
>>Hi Steve
>>
>>On 05/01/2019 15:40, Steve McIntyre wrote:
>>> Package: src:p4est
>>> Version: 1.1-5
>>> Severity: i
On Tue, Jan 08, 2019 at 10:42:01AM +, Alastair McKinstry wrote:
>Hi Steve
>
>On 05/01/2019 15:40, Steve McIntyre wrote:
>> Package: src:p4est
>> Version: 1.1-5
>> Severity: important
>>
>> I've been doing a full rebuild of the Debian archive, building
On Mon, Jan 07, 2019 at 06:24:23PM +, Steve McIntyre wrote:
>On Sun, Jan 06, 2019 at 10:38:55AM +0200, Yavor Doganov wrote:
>>
>>I see that libffi was also built on arm-arm-01. It would help a lot
>>if you can retry the gnustep-base build with libffi built on armhf.
>
On Mon, Jan 07, 2019 at 06:17:58PM +, Steve McIntyre wrote:
>On Sat, Jan 05, 2019 at 03:56:50PM +, Richard Frith-Macdonald wrote:
>>> On 5 Jan 2019, at 15:00, Steve McIntyre wrote:
>
>...
>
>>> I'm honestly not sure about what casues the failures. Is a
On Sun, Jan 06, 2019 at 10:38:55AM +0200, Yavor Doganov wrote:
>Steve McIntyre wrote:
>> Package: src:gnustep-base
>> Version: 1.25.1-4
>> Severity: important
>
>> I've tried to build gnustep-base for armhf on top of arm64, and AFAICS
>> it's failing some of
On Sat, Jan 05, 2019 at 03:56:50PM +, Richard Frith-Macdonald wrote:
>> On 5 Jan 2019, at 15:00, Steve McIntyre wrote:
...
>> I'm honestly not sure about what casues the failures. Is a "dashed
>> hope" a test fail? :-(
>
>That's a test skipped because it'
On Sat, Jan 05, 2019 at 06:46:33AM -0400, David Bremner wrote:
>Steve McIntyre writes:
>
>> I'd be happy to help debug as much as I can here, but the lack of info
>> in the core file is a bit of a hurdle up-front!
>
>I tried configuring with
>
>./configure --enabl
But we might
>need to run this inside gdb to find out where that occurs.
>
>I hope this detailed response is helpful... if I could reproduce the error
>that would make it easier to fix.
>
>I don't have any arm hardware though. How do you typically ha
this issue.
ACK. As far as I can see from the kernel source, KASLR has been around
for arm64 since 2016. I'm rebuilding now with the 'world' tests
disabled to verify that's the only problem.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Dance like no one's watchin
Package: src:thumbor
Version: 6.5.1-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
Package: src:spark
Version: 2012.0.deb-11
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
Source: ruby-ferret
Version: 0.11.8.6-2
Severity: important
User: debian-...@lists.debian.org
Usertags: alignment
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our
Source: nsis
Version: 3.03-2
Severity: important
Tags: ftbfs
User: debian-...@lists.debian.org
Usertags: alignment
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our
Package: src:p4est
Version: 1.1-5
Severity: important
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our 32-bit armel/armhf builds to
using arm64 machines, so this rebuild
Package: src:gnustep-base
Version: 1.25.1-4
Severity: important
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our 32-bit armel/armhf builds to
using arm64 machines,
Package: src:elpa
Version: 2016.05.001-6
Severity: important
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our 32-bit armel/armhf builds to
using arm64 machines, so
Package: src:dune-pdelab
Version: 2.6~20180302-1
Severity: important
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our 32-bit armel/armhf builds to
using arm64
Package: src:dune-grid
Version: 2.6.0-3
Severity: important
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our 32-bit armel/armhf builds to
using arm64 machines, so
Package: src:dune-grid-glue
Version: 2.6~20180130-1
Severity: important
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our 32-bit armel/armhf builds to
using arm64
On Fri, Jan 04, 2019 at 08:37:24PM +0200, Graham Inggs wrote:
>This sounds like #918157.
Nod. I'm seeing similar behaviour in a few more packages since tihs
point, too. :-(
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Google-bait: http://www.debian.
Source: hddemux
Version: 0.4-7
Severity: important
User: debian-...@lists.debian.org
Usertags: alignment
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our 32-bit
Package: src:dune-common
Version: 2.6.0-3
Severity: important
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our 32-bit armel/armhf builds to
using arm64 machines, so
Package: src:frown
Version: 0.6.2.3-6
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
Package: src:criu
Version: 3.8.1-1
Severity: important
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our 32-bit armel/armhf builds to
using arm64 machines, so this
On Fri, Jan 04, 2019 at 11:34:04AM +, Steve McIntyre wrote:
>On Thu, Jan 03, 2019 at 07:43:03AM -0500, James McCoy wrote:
>>On Wed, Jan 02, 2019 at 06:53:29PM +0000, Steve McIntyre wrote:
>>>
>>> amdahl is the arm64 porterbox, and I've just checked - it has a
On Thu, Jan 03, 2019 at 07:43:03AM -0500, James McCoy wrote:
>On Wed, Jan 02, 2019 at 06:53:29PM +0000, Steve McIntyre wrote:
>>
>> amdahl is the arm64 porterbox, and I've just checked - it has armel
>> and armhf schroots configured too. That should hopefully cover what
>&
Control: reopen -1
Control: subject -1 FTBFS building for armel on arm64, alignment problems
Hi Matteo, and Happy New Year to you too!
On Tue, Jan 01, 2019 at 08:34:49PM +0100, Matteo F. Vescovi wrote:
>Version: 2.0.3~dfsg0-3
>
>Hi Steve!
>
>On 2018-12-24 at 17:20 (+00), Steve
Package: src:bali-phy
Version: 3.4+dfsg-1
Severity: important
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our 32-bit armel/armhf builds to
using arm64 machines, so
Hi James, and Happy New Year to you and yours!
On Mon, Dec 31, 2018 at 10:50:25AM -0500, James McCoy wrote:
>On Mon, Dec 31, 2018 at 04:38:10AM +0000, Steve McIntyre wrote:
...
>> From test_alot.vim:
>> Found errors in Test_compiler():
>> function RunTheTest[40]..Test_comp
ld a
single-CD installer image for xfce. If that's now looking too small
and is missing key packages, I'll check and see what we can do. But we
may now be forced to drop it - we've already worked on minimisation
several times in the last few years.
--
Steve McIntyre, Cambridge, UK.
Hi David, and Happy New Year!
On Sun, Dec 30, 2018 at 09:14:35AM -0400, David Bremner wrote:
>Steve McIntyre writes:
>
>> Package: src:racket
>> Version: 7.1+dfsg1-1
>> Severity: important
>>
>> Hi!
>>
>> I've been doing a full rebuild of the
On Wed, Jan 02, 2019 at 11:28:19AM +0200, Timo Lindfors wrote:
>Hi,
>
>On Sat, 29 Dec 2018, Steve McIntyre wrote:
>> Package: src:qi
>> Version: 2013-1
>> Severity: serious
>> Justification: fails to build from source (but built successfully in the
>
Package: src:vim
Version: 2:8.1.0549-1
Severity: important
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our 32-bit armel/armhf builds to
using arm64 machines, so
Source: seqan2
Version: 2.4.0+dfsg-9
Severity: important
User: debian-...@lists.debian.org
Usertags: alignment
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our
Package: src:snapd
Version: 2.30-5
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to
Package: src:rkt
Version: 1.30.0+dfsg-7
Severity: important
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our 32-bit armel/armhf builds to
using arm64 machines, so
On Sun, Dec 30, 2018 at 12:26:08PM +, Steve McIntyre wrote:
>Package: src:racket
>Version: 7.1+dfsg1-1
>Severity: important
>
>Hi!
>
>I've been doing a full rebuild of the Debian archive, building all
>source packages targeting armel and armhf using arm64 hardware. We
Package: src:racket
Version: 7.1+dfsg1-1
Severity: important
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our 32-bit armel/armhf builds to
using arm64 machines, so
Source: pywavelets
Version: 0.5.1-1.1
Severity: important
User: debian-...@lists.debian.org
Usertags: alignment
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our
Package: src:qi
Version: 2013-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to
Source: pythonqt
Version: 3.2-10
Severity: important
User: debian-...@lists.debian.org
Usertags: alignment
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our 32-bit
Package: src:mlton
Version: 20180207-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future
if you like?
>It is a fork of percona-xtrabackup with additional features so it
>supports the latest versions of MariaDB Server and Galera.
ACK.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"I've only once written 'SQL is my bitch' in a comment. Bu
Source: python-fitsio
Version: 0.9.11+dfsg-4
Severity: important
User: debian-...@lists.debian.org
Usertags: alignment
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of
Package: src:softhsm
Version: 2.4.0-0.1
Severity: important
Hi!
Several times today on my build farm I've seen this problem occur when
installing packages, mostly via "apt-get build-dep ." .
...
dpkg: unrecoverable fatal error, aborting:
unknown group 'softhsm' in statoverride file
E:
tax
>
> dpkg: error processing package python3-applicationinsights (--configure):
> installed python3-applicationinsights package post-installation script
> subprocess returned error exit status 1
>
>
>"async" has become a reserved keyword in Python 3.7
>
>
Package: src:pytest-qt
Version: 2.3.1-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
Package: src:plainbox
Version: 0.25-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
On Fri, Dec 28, 2018 at 10:29:35PM +, Steve McIntyre wrote:
>Package: src:mod-gnutls
>Version: 0.8.4-2
>Severity: serious
>Justification: fails to build from source (but built successfully in the past)
>
>Hi!
>
>I've been doing a full rebuild of the Debian archi
Package: src:mod-gnutls
Version: 0.8.4-2
Severity: serious
Tags: ftbfs
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our 32-bit armel/armhf builds to
using arm64 machines,
Package: src:mod-gnutls
Version: 0.8.4-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in
Package: src:memleax
Version: 1.1.1-1
Severity: important
User: debian-...@lists.debian.org
Usertags: architecture-detection
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move
test failures after that, though.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"I suspect most samba developers are already technically insane... Of
course, since many of them are Australians, you can't tell." -- Linus Torvalds
On Wed, Dec 26, 2018 at 10:27:35PM +0100, Cyril Brulebois wrote:
>Steve McIntyre (2018-12-26):
>> >Philipp Kern (2018-12-26):
>> >> I'm not sure, though, if there is some philosophical objection here in
>> >> that fwupd downloads non-free blobs and/or that
bs themselves.
>
>FWIW both parts seem unacceptable to me, esp. in a default installation.
They're not all necessarily non-free, but it's a useful service for
people to make safe firmware updates easy.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane
Package: src:llvmlite
Version: 0.26.0-1
Severity: important
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our 32-bit armel/armhf builds to
using arm64 machines, so
Package: src:openimageio
Version: 1.8.15~dfsg0-1
Severity: important
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our 32-bit armel/armhf builds to
using arm64 machines,
Package: src:pocl
Version: 1.1-7
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to
Source: ndpi
Version: 2.2-1
Severity: important
User: debian-...@lists.debian.org
Usertags: alignment
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our 32-bit
Source: nanomsg
Version: 1.1.5+dfsg-1
Severity: important
User: debian-...@lists.debian.org
Usertags: alignment
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our
Package: src:libmcrypt
Version: 2.5.8-3.3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
Package: src:libkqueue
Version: 2.0.3-1.1
Severity: important
Tags: ftbfs
Doing a rebuild on arm64, I saw the following failure:
/bin/bash ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-Wdate-time -D_FORTIFY_SOURCE=2 -I./src/common -I./include -Wall -Wextra
601 - 700 of 2266 matches
Mail list logo
