On Mon, Apr 05, 2021 at 04:55:15PM +1200, Michael Cree wrote:
> On Sun, Apr 04, 2021 at 11:47:58PM -0500, Bob Tracy wrote:
> > On Wed, Mar 31, 2021 at 11:04:42AM +0200, Maciej W. Rozycki wrote:
> > > I think the only feasible way of determining what has happened here is
> > > that you track the
On Sun, Apr 04, 2021 at 11:47:58PM -0500, Bob Tracy wrote:
> On Wed, Mar 31, 2021 at 11:04:42AM +0200, Maciej W. Rozycki wrote:
> > I think the only feasible way of determining what has happened here is
> > that you track the offending change down by bisecting the upstream kernel
> > repository
On Wed, Mar 31, 2021 at 11:04:42AM +0200, Maciej W. Rozycki wrote:
> I think the only feasible way of determining what has happened here is
> that you track the offending change down by bisecting the upstream kernel
> repository with `git bisect'.
That would normally be what I would do, and it
On Thu, 25 Mar 2021, Bob Tracy wrote:
> > Everything worked as well as it's going to for kernel versions up
> > through v5.10.0. When I boot on v5.11.0, "lightdm" starts, the screen
> > goes blank as usual, I get a mouse pointer as usual, and shortly after
> > that, the system locks up solid
On 3/27/21 10:18 PM, Thorsten Glaser wrote:
>> The debian-installer tarballs are completely untested. We have ISO images
>> in the snapshots folder which you should use.
>
> Yeah, I did that later. The tarball there was the first thing I found,
> though, and its ISO subdirectory contains only
John Paul Adrian Glaubitz dixit:
>On 3/27/21 8:32 PM, Thorsten Glaser wrote:
>> -
>> https://cdimage.debian.org/cdimage/ports/debian-installer/2021-01-03/alpha/debian-installer-images_20201202+nmu1_alpha.tar.gz
>> is insufficient, it lacks the ISO which contains nic-modules
>
>The
FYI
-- Forwarded message --
Message-ID: <161687355375.3666.12906764209603803348.reportbug@alpha>
Date: Sat, 27 Mar 2021 20:32:33 +0100
Subject: Bug#986009: installation-reports: document qemu workarounds and bug in
newer d-i image
Package: installation-reports
Severity:
Hi Thorsten!
On 3/27/21 8:32 PM, Thorsten Glaser wrote:
> -
> https://cdimage.debian.org/cdimage/ports/debian-installer/2021-01-03/alpha/debian-installer-images_20201202+nmu1_alpha.tar.gz
> is insufficient, it lacks the ISO which contains nic-modules
The debian-installer tarballs are
On Wed, Mar 24, 2021 at 09:48:46AM -0500, Bob Tracy wrote:
> (...)
> Everything worked as well as it's going to for kernel versions up
> through v5.10.0. When I boot on v5.11.0, "lightdm" starts, the screen
> goes blank as usual, I get a mouse pointer as usual, and shortly after
> that, the
All,
First an apology for being "dark" for so long. There are still a few of
us out here using Alpha computers...
Another apology for the crappy "bug report" that follows, but first, a
little background information. I'm not in the habit of running X11 on
my PWS 433au these days, except for
Hi Debian-alpha,
Happy Chinese New Year！
We’ve back to work, and ready to serve you all the time, thanks.
Have a nice day!
Thanks Regards,
Cherry Hu |Sales Manager
SHENZHEN PLUXLED LIGHTING CO., LIMITED.
4F,Building 4, Huafeng
Source: vim
Severity: normal
Tags: patch
User: debian-alpha@lists.debian.org
Usertags: alpha ia64
X-Debbugs-Cc: debian-alpha@lists.debian.org,debian-i...@lists.debian.org
Hi!
The Ruby interpretor is not fully working on alpha and ia64 and regularly causes
the vim testsuite to fail on these
Bonjour,
En tant que fournisseur de services de nearshoring dans l'industrie du
logiciel, nous souhaitons partager avec vous des solutions logicielles
flexibles et rentables pour soutenir vos opérations commerciales.
Avec plus de 10 ans de présence sur le marché, nous comprenons les besoins
Source: scummvm
Severity: normal
User: debian-powe...@lists.debian.org
Usertags: powerpc ppc64
X-Debbugs-Cc:
On Sun, Dec 06, 2020 at 01:03:17PM +0100, Matthias Klose wrote:
> On 12/1/20 5:02 AM, YunQiang Su wrote:
> > I am sorry for the later response.
> >Hi,
> >
> > I am an active porter for the following architectures and I intend
> > to continue this for the lifetime of the Bullseye release
Hi,
sorry for the late reply and thanks a lot Graham for pinging me
directly. I didn't monitor -devel closely lately, but
I am an active porter for the following architecture and I intend
to continue this for the lifetime of the Bullseye release (est. end
of 2024):
For ppc64el, I
- test most
On 2020-11-02 22:23 +0200, Graham Inggs wrote:
> Hi
>
> We are doing a roll call for porters of all release architectures. If
> you are an active porter behind one of the release architectures [1]
> for the entire lifetime of Debian Bullseye (est. end of 2024), please
> respond with a signed
On Sun, Dec 06, 2020 at 01:03:17PM +0100, Matthias Klose wrote:
> On 12/1/20 5:02 AM, YunQiang Su wrote:
> > I am sorry for the later response.
> >Hi,
> >
> > I am an active porter for the following architectures and I intend
> > to continue this for the lifetime of the Bullseye release
On 12/1/20 5:02 AM, YunQiang Su wrote:
> I am sorry for the later response.
>Hi,
>
> I am an active porter for the following architectures and I intend
> to continue this for the lifetime of the Bullseye release (est. end
> of 2024):
>
> For mipsel and mips64el, I
> - test most
Hi!
I uploaded updated Debian installer CD images today.
These come with the latest versions of the kernel and the debian-installer
application as well as various other updates. The images can be found at
the usual location [1] as well as the debian-installer for netboot [2].
Known issues:
-
On 2020-11-20, Graham Inggs wrote:
> A friendly reminder about the porter roll call for bullseye.
>
> On Mon, 2 Nov 2020 at 22:23, Graham Inggs wrote:
>> We are doing a roll call for porters of all release architectures. If
>> you are an active porter behind one of the release architectures [1]
Hi
A friendly reminder about the porter roll call for bullseye.
On Mon, 2 Nov 2020 at 22:23, Graham Inggs wrote:
> We are doing a roll call for porters of all release architectures. If
> you are an active porter behind one of the release architectures [1]
> for the entire lifetime of Debian
Source: libio-pty-perl
Severity: normal
User: debian-alpha@lists.debian.org
Usertags: alpha
X-Debbugs-Cc: debian-alpha@lists.debian.org
Hi!
The patch Add-termios-data-structures-for-alpha.patch that was introduced in
#82627 [1] in 2001 is no longer necessary and can safely be dropped, the
Hi
We are doing a roll call for porters of all release architectures. If
you are an active porter behind one of the release architectures [1]
for the entire lifetime of Debian Bullseye (est. end of 2024), please
respond with a signed email containing the following before Friday,
November 27:
*
Source: glibc
Version: 2.31-4
Severity: normal
User: debian-sp...@lists.debian.org
Usertags: alpha hppa ia64 m68k sh4 sparc64
Hello!
The two tests:
FAIL: misc/tst-sbrk
FAIL: misc/tst-sbrk-pie
fail on multiple architectures.
According to the discussion in #debian-ports, the tests are broken
BOGAT BREZPLAČEN ANIMACIJSKI PROGRAM
doma smo ustvarjalni (jesensko slikanje z odtisi listov, peka kostanjev ob ognju,
izdelava spominkov..)doma smo aktivni (pohod do Energetskih točk, do Ribniške koče,
nočni pohod, jutranja telovadba..) doma smo zabavni (igra "Zemljo krast",
On 8/17/20 9:42 PM, Michael Cree wrote:
>> As I posted last month, my old version of iceweasel was deleted by apt.
>> I downloaded the deb file for firefox 52.6 alpha, but when trying to install
>> I get the following errors:
>
> I doubt if we ever will have firefox built on Alpha again. It now
On Mon, Aug 17, 2020 at 05:27:53PM +, Ivan C. N. wrote:
> Hello again,
> Had to fix a few things with the DS15: a suspected failing power supply
> turned out to be the front panel power-on button's wires having a flimsy
> connection (probably due to front access storage cage
Hello again,
Had to fix a few things with the DS15: a suspected failing power supply turned
out to be the front panel power-on button's wires having a flimsy connection
(probably due to front access storage cage removal/installation). Also had to
clone my Debian Alpha installation since the
* Florian Weimer:
>> * Concern for mips, mips64el, mipsel and ppc64el: no upstream support
>>in GCC
>>(Raised by the GCC maintainer; carried over from stretch)
>
> I'm surprised to read this. ppc64el features prominently in the
> toolchain work I do (though I personally do not work on
Buonasera,
Sono la Dott.ssa Maria Puccini, consulente aziendale, abbiamo lanciato una
campagna che fa al caso suo.
Le diamo l'opportunità di avere un consulente dedicato che contatterà
potenziali clienti nella zona di suo interesse per promuovere la sua attività
con un unico scopo: trovare
You have the wrong email! Please delete my email
Sent from my iPhone
> On 31 Jul 2020, at 07:34, John Paul Adrian Glaubitz
> wrote:
>
> Hello!
>
>> On 7/31/20 7:51 AM, Ivan Carrillo-Nava wrote:
>> My debian alpha box was off for a long time (over 2 years).
>> When I turned it back on a few
Hello!
On 7/31/20 7:51 AM, Ivan Carrillo-Nava wrote:
> My debian alpha box was off for a long time (over 2 years).
> When I turned it back on a few days ago and tried to update, the keys had
> expired so I got a new one and started updating.
> apt reported several packages had to be deleted
Hello all,
My debian alpha box was off for a long time (over 2 years).
When I turned it back on a few days ago and tried to update, the keys had
expired so I got a new one and started updating.
apt reported several packages had to be deleted (cinnamon amongst them).
So my alpha debian box runs
Debian bullseye will be based on a gcc-10 package taken from the gcc-10 upstream
branch, and binutils based on a binutils package taken from the 2.35 branch.
I'm planning to make gcc-10 the default after gcc-10 (10.2.0) is available
(upstream targets mid July). binutils will be updated before
Bonjour
Je contacte au nom du fabricant de savons, liquides et gels pour la
désinfection des mains et les produits de nettoyage.
Je voudrais vous offrir des produits de désinfection inodores qui nettoient et
désinfectent efficacement la peau, éliminant les virus et les bactéries de vos
mains.
> Why do I need to be helpful to dead architectures unless it's a LO issue?
Because it is what we do as maintainers. So much of what we do, in this case
don't do, has knock-on consequences across open source.
Cheers
Skye
-Original Message-
From: r...@rene-engelhard.de
On 23.06.20 13:22, r...@rene-engelhard.de wrote:
> Am 23. Juni 2020 13:07:42 MESZ schrieb Helge Deller :
>>> Which didn't build since 2018. And is constantly bd-uninststallable.
>>
>> If you apply Adrian's patch which drops dependency on clang,
>> then it maybe get's bd-installable again?
>
> No?
Am 23. Juni 2020 13:07:42 MESZ schrieb Helge Deller :
>Hello Rene,
>
>On 23.06.20 12:33, r...@rene-engelhard.de wrote:
>> Am 23. Juni 2020 12:05:18 MESZ schrieb Helge Deller :
>>> I'm one of the maintainers for the hppa/parisc architecture
>>
>> Which didn't build since 2018. And is constantly
Hello Rene,
On 23.06.20 12:33, r...@rene-engelhard.de wrote:
> Am 23. Juni 2020 12:05:18 MESZ schrieb Helge Deller :
>> I'm one of the maintainers for the hppa/parisc architecture
>
> Which didn't build since 2018. And is constantly bd-uninststallable.
If you apply Adrian's patch which drops
Hi,
Am 23. Juni 2020 12:05:18 MESZ schrieb Helge Deller :
>Hello Rene,
>
>I'm one of the maintainers for the hppa/parisc architecture
Which didn't build since 2018. And is constantly bd-uninststallable.
>On 19.06.20 19:12, Rene Engelhard wrote:
>> Am 19.06.20 um 17:46 schrieb John Paul
Hello Rene,
I'm one of the maintainers for the hppa/parisc architecture
On 19.06.20 19:12, Rene Engelhard wrote:
> Am 19.06.20 um 17:46 schrieb John Paul Adrian Glaubitz:
>> On 6/19/20 1:08 PM, r...@rene-engelhard.de wrote:
>>> Am 19. Juni 2020 12:52:40 MESZ schrieb John Paul Adrian Glaubitz
Hi,
Am 19.06.20 um 19:19 schrieb John Paul Adrian Glaubitz:
> On 6/19/20 7:12 PM, Rene Engelhard wrote:
>> Sorry, I don't believe I don't need to fix stuff here myself. ia64 and
>> m68k even didn't yet do a ICU rebuild or at least make stuff being
>> rebuildable.
>>
>>> Would it be okay if I send
Am 19.06.20 um 17:46 schrieb John Paul Adrian Glaubitz:
> On 6/19/20 1:08 PM, r...@rene-engelhard.de wrote:
>> Am 19. Juni 2020 12:52:40 MESZ schrieb John Paul Adrian Glaubitz
>> :
>>> So nothing that keeps us from using GCC in cases where clang is not
>>> available.
>>
>> Correct. Except
On 6/19/20 7:12 PM, Rene Engelhard wrote:
> Sorry, I don't believe I don't need to fix stuff here myself. ia64 and
> m68k even didn't yet do a ICU rebuild or at least make stuff being
> rebuildable.
>
>> Would it be okay if I send a pull request to make the necessary changes?
>
> I am perfectly
On 6/19/20 1:08 PM, r...@rene-engelhard.de wrote:
> Am 19. Juni 2020 12:52:40 MESZ schrieb John Paul Adrian Glaubitz
> :
>> So nothing that keeps us from using GCC in cases where clang is not
>> available.
>
> Correct. Except staying as close as possible with upstream.
While at the same time,
Am 19. Juni 2020 12:52:40 MESZ schrieb John Paul Adrian Glaubitz
:
>So nothing that keeps us from using GCC in cases where clang is not
>available.
Correct. Except staying as close as possible with upstream.
>>> Not sure why you want to enforce architectures off libreoffice when
>>> it’s
On 6/19/20 10:08 AM, r...@rene-engelhard.de wrote:
> Am 19. Juni 2020 09:58:34 MESZ schrieb John Paul Adrian Glaubitz
> :
>
>> clang isn’t required to build libreoffice [1], it’s just recommend.
>
> I know. That is even documented:
>
>
Source: libreoffice
Version: 1:7.0.0~beta2-1
Severity: normal
User: debian-alpha@lists.debian.org
Usertags: alpha ia64
Hello!
I just noticed that src:libreoffice 7.x has added a build dependency on clang
for alpha and ia64. However, clang is unfortunately no longer available on
these targets
Source: libzstd
Version: 1.4.5+dfsg-1
Tags: ftbfs patch
User: helm...@debian.org
Usertags: rebootstrap
libzstd fails to build from source on alpha. programs/util.c has code
that checks whether st_mtime is defined as a macro. If yes, it uses a
struct timespec. Otherwise a struct utimebuf. alpha is
Hi!
On 4/30/20 11:20 PM, John Paul Adrian Glaubitz wrote:
> The attached patch removes the checks for the LLVM and Rust toolchains from
> the build system and allows to build mozjs68 without LLVM and Rust in the
> build dependencies. With the patch applied, it should be possible to drop the
>
Control: tags -1 +patch
Hi!
The attached patch removes the checks for the LLVM and Rust toolchains from
the build system and allows to build mozjs68 without LLVM and Rust in the
build dependencies. With the patch applied, it should be possible to drop the
patch
Source: mozjs68
Version: 68.6.0-2
Severity: normal
Tags: upstream
User: debian-...@lists.debian.org
Usertags: alpha hppa ia64 m68k sh4
Hi!
mozjs68 build-depends on cargo and rustc, but it doesn't actually build any Rust
code. The configure script just checks for the version of cargo and rustc,
Hi Adrian,
Thank you for your answer.
Sorry for my -not so clear- previous message.
There is an alternative between these two patches : only one of the
two may be merged. Indeed, a choice should be made :
to have the floppy driver built-in (in all stock kernels
or in the alpha-generic flavor
John, I only provided a temporary workaround (a hack, that ugly, but
will work) in case somebody really wants to try it quickly. In no way
it was supposed to be 'official' or 'correct'. Obviously compiling it
into installer kernel or udeb is the only option forward, and this is
what I said in 'or
On 4/21/20 7:59 PM, Witold Baryluk wrote:
>>> It should be relatively easy to put it there manually (unpack,
>>> repack), or fix the iso build scripts to include it too.
>> debian-installer does not use a kernel package, it boots the bare kernel
>> image
>> and loads additional modules either
On Tue, 21 Apr 2020 at 17:57, John Paul Adrian Glaubitz
wrote:
>
> On 4/21/20 7:53 PM, Witold Baryluk wrote:
> > floppy.ko for alpha is in the kernel image deb file,
> >
> >
On 4/21/20 7:53 PM, Witold Baryluk wrote:
> floppy.ko for alpha is in the kernel image deb file,
>
> debian-10.0-alpha-NETINST-1.iso/iso9660://pool-alpha/main/l/linux/linux-image-5.5.0-1-alpha-smp_5.5.13-2_alpha.deb/deb://CONTENTS/lib/modules/5.5.0-1-alpha-smp/kernel/drivers/block
>
> but it is
floppy.ko for alpha is in the kernel image deb file,
debian-10.0-alpha-NETINST-1.iso/iso9660://pool-alpha/main/l/linux/linux-image-5.5.0-1-alpha-smp_5.5.13-2_alpha.deb/deb://CONTENTS/lib/modules/5.5.0-1-alpha-smp/kernel/drivers/block
but it is not present in any udeb file, or in the
Hello!
On 4/21/20 4:00 PM, jhcha54008 wrote:
> PS : it is the opportunity to thank you (and Samuel Thibault) for all your
> work on the alpha kernel and
> towards a working debian installer on alpha - and the other ports !
You're welcome. Although it's sometimes so frustrating that I'm
Hi Adrian and Michael,
Indeed, it would be great to have a floppy driver at installation time. But it
seems that the
floppy-module udeb was removed. Would it be possible to ship it in the udeb
kernel package instead,
either built-in or as a module ?
I wonder if one of the two following
For reference, the recipe at:
The recipe at https://lists.debian.org/debian-alpha/2019/11/msg00033.html
for adding firmware to the install disk did indeed work.
I booted with the modified install disk in the SCSI CD drive and the
original in a second IDE CDROM drive that runs on a PCI card.
On 4/21/20 4:16 AM, Michael Cree wrote:
> So is the floppy module included in the install ISO, and, if so,
> can you run insmod on it to enable the floppy drive while
> installing?
That's an easy fix. I assume there used to be a floppy-modules package
that was removed. We can re-add that. Or just
>
> Interesting. I've just checked on my running XP1000 and I see there
> is no /dev/fd0 either. I'm running a self-compiled 5.6.3 kernel and
> the floppy module is built. Modprobing it loaded it and then I have
> a /dev/fd0 device node. What's more it works --- I managed to list
> the
On Tue, Apr 21, 2020 at 11:37:14AM +1000, Darren Goossens wrote:
> My experience with the April 2020 Alpha iso
>
> Booted fine, asked for me to load qlogic/1040.bin on removable media.
> I downloaded the deb file for buster, exploded it and copied all the
> bin files onto both a floppy and a USB
My experience with the April 2020 Alpha iso
Booted fine, asked for me to load qlogic/1040.bin on removable media.
I downloaded the deb file for buster, exploded it and copied all the
bin files onto both a floppy and a USB stick. The AlphaServer 1200 has
a USB card in a PCI slot.
Put both the USB
Hi Darren!
On 4/20/20 11:49 AM, Darren Goossens wrote:
> The floppy disk controller did not work either, I recall clearly. I
> tried a PCI USB card, IDE CD, SCSI CD and putting the files on a
> second HDD. None of the storage was visible to the Debian installer.
>
> If this might have changed, I
>
> You can add the firmware files manually during installation with a
> floppy disk. The installer asks during installation if you want
> to provide additional firmware using removable media.
>
Thanks for that
The floppy disk controller did not work either, I recall clearly. I
tried a PCI USB
Hi Darren!
On 4/20/20 10:53 AM, Darren Goossens wrote:
> I understand your comment about help being appreciated. I'm afraid I
> am an amateur, and my day job is nothing to do with software. I am
> happy to test things and see how they work and report back, but I am
> not a developer -- not even a
On 4/20/20 10:28 AM, Darren Goossens wrote:
> That's great! Thanks again for all your troubles. A question: When I
> last tried an install on an Alpha, qlogic firmware for the storage was
> missing (eg SCSI disks, CD etc). Does the Alpha image have any new
> firmware compared to the previous
On Mon, Apr 20, 2020 at 4:30 AM John Paul Adrian Glaubitz
wrote:
>
> Hi!
>
> I just uploaded updated installation images 2020-04-19 for the
> following Debian Ports architectures [1]:
>
> * alpha
> * hppa
> * ia64
> * m68k
> * powerpc
> * ppc64
> * sparc64
>
> These images should finally
On Sun, Apr 19, 2020 at 07:11:56PM -0500, Bob Tracy wrote:
> On Sun, Apr 19, 2020 at 01:01:17AM +0200, Matthias Ferdinand wrote:
> > On Sat, Apr 18, 2020 at 07:48:27AM -0500, Bob Tracy wrote:
> > > > If the rules had changed, it should not succeed even without
> > > > O_CREAT. A bug?
> > >
> > >
On Sun, Apr 19, 2020 at 01:01:17AM +0200, Matthias Ferdinand wrote:
> On Sat, Apr 18, 2020 at 07:48:27AM -0500, Bob Tracy wrote:
> > > If the rules had changed, it should not succeed even without
> > > O_CREAT. A bug?
> >
> > That's *my* take on the matter. It will be a day or so before I can
>
Hi!
I just uploaded updated installation images 2020-04-19 for the
following Debian Ports architectures [1]:
* alpha
* hppa
* ia64
* m68k
* powerpc
* ppc64
* sparc64
These images should finally fix the installation process on Apple
PowerMacs and PowerBooks compatible with GRUB, so
On Sat, Apr 18, 2020 at 07:48:27AM -0500, Bob Tracy wrote:
> > If the rules had changed, it should not succeed even without
> > O_CREAT. A bug?
>
> That's *my* take on the matter. It will be a day or so before I can
> check upstream and see if any bug reports have been opened against
> libc6,
On Sat, Apr 18, 2020 at 12:25:11PM +0200, Matthias Ferdinand wrote:
> On Fri, Apr 17, 2020 at 02:17:46PM -0500, Bob Tracy wrote:
> > (directory sticky bit handling strangeness)
>
> it seems the difference lies in handling of O_CREAT.
>
> (...)
>
> not Alpha specific; this was done on x86_64
On Fri, Apr 17, 2020 at 02:17:46PM -0500, Bob Tracy wrote:
> All,
>
> This likely isn't unique to Debian, much less the alpha platform, but
> I first encountered this strangeness on my alpha running Debian unstable.
>
> Best way to explain what I'm seeing is by example. A fairly common
> thing
All,
This likely isn't unique to Debian, much less the alpha platform, but
I first encountered this strangeness on my alpha running Debian unstable.
Best way to explain what I'm seeing is by example. A fairly common
thing to do is create temporary or download directories with octal mode
1777
(Switched back to my main address, accidentally switched to GMail)
On 4/1/20 5:05 PM, Sébastien Villemot wrote:
>> So, the currently only candidate for this scenario is mipsel and I think this
>> is a risk that is bearable, in particular since upstream considers 32-bit
>> mips
>> one of the
Le mercredi 01 avril 2020 à 16:56 +0200, John Paul Adrian Glaubitz a écrit :
> On 4/1/20 4:51 PM, Sébastien Villemot wrote:
> > > FWIW, sbcl builds fine for me on mipsel if clang is used as the C
> > > compiler,
> > > I'll file a separate bug report for that.
> >
> > I have mixed feelings about
Hi,
Le mercredi 01 avril 2020 à 16:43 +0200, John Paul Adrian Glaubitz a écrit :
> On 3/16/20 1:16 AM, John Paul Adrian Glaubitz wrote:
> > sbcl has partial support for alpha, hppa, mips*, ppc64 and riscv64
> > and if we try to build sbcl on any architecture using clisp, we will
> > be able to
Hi!
On 3/16/20 1:16 AM, John Paul Adrian Glaubitz wrote:
> sbcl has partial support for alpha, hppa, mips*, ppc64 and riscv64
> and if we try to build sbcl on any architecture using clisp, we will
> be able to provide upstream with a build log of sbcl on any architecture
> that might be supported
On 3/16/20 5:34 PM, John David Anglin wrote:
> With patch, I get following error:
See [1], the build system is not very smart, unfortunately.
Adrian
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939453
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer -
Source: sbcl
Severity: normal
Tags: patch
Hi!
In order to provide some basic level of continuous integration for
sbcl upstream, it would be great if the sbcl package could be tried
to build on any of the currently unsupported architectures using
clisp.
sbcl has partial support for alpha, hppa,
On 3/12/20 10:23 PM, John Paul Adrian Glaubitz wrote:
>> Moreover, just because we have tried to keep the backends compiling
>> gives no guarantee that they actually run; I'd be slightly surprised if
>> they don't crash pretty quickly in cold-init.
>
> I sent in some fixes, but so far I haven't
Hi Christophe
On 3/12/20 10:15 PM, Christophe Rhodes wrote:
> I would like the SBCL project to try to substantially improve, or else
> retire, support for Alpha and HPPA.
>
> At the moment, those backends in particular are kept in the source more
> for nostalgia than any other reason; and
Hola, bonito día, le escribo para invitarle a participar en el próximo evento
de Seguridad Informática "El Lado Oscuro de la Red".
Será impartido por un Hacker Israelí el próximo 23 de Abril en CDMX. ¿Me
permite enviarle el temario para que pueda evaluar?
Sí le interesa la información espero
On February 24, 2020 8:46:47 PM UTC, John Paul Adrian Glaubitz
wrote:
>On 2/24/20 9:37 PM, Moritz Mühlenhoff wrote:
>> On Sun, Feb 02, 2020 at 02:06:12PM +0100, John Paul Adrian Glaubitz
>wrote:
>>> Hello!
>>>
>>> On 1/29/20 11:49 PM, John Paul Adrian Glaubitz wrote:
One of the Gentoo
On 2/24/20 9:37 PM, Moritz Mühlenhoff wrote:
> On Sun, Feb 02, 2020 at 02:06:12PM +0100, John Paul Adrian Glaubitz wrote:
>> Hello!
>>
>> On 1/29/20 11:49 PM, John Paul Adrian Glaubitz wrote:
>>> One of the Gentoo developers has forked aboot and is maintaing it on
>>> Github [1]. I have filed an
On Sun, Feb 02, 2020 at 02:06:12PM +0100, John Paul Adrian Glaubitz wrote:
> Hello!
>
> On 1/29/20 11:49 PM, John Paul Adrian Glaubitz wrote:
> > One of the Gentoo developers has forked aboot and is maintaing it on
> > Github [1]. I have filed an issue regarding the manpage issue and will
> >
Hello!
On 2/14/20 7:17 AM, Bob Tracy wrote:
> "apt-get upgrade" is failing on "cmake_3.16.3-1_alpha.deb" with the
> following errors for the past day:
Not a packaging error but an inconsistency of the index data on the
FTP server. This started to show last night and affects the build
machines as
"apt-get upgrade" is failing on "cmake_3.16.3-1_alpha.deb" with the
following errors for the past day:
Get:1 http://ftp.ports.debian.org/debian-ports unstable/main alpha cmake alpha
3.16.3-1 [3,531 kB]
Err:1 http://ftp.ports.debian.org/debian-ports unstable/main alpha cmake alpha
3.16.3-1
Control: retitle -1 ITA: aboot
Control: owner -1 !
Changing to ITA and setting myself as owner.
My pull request to switch to docbook-utils for aboot has been
merged [1] upstream in the meantime.
Thanks,
Adrian
> [1]
>
Package: wnpp
Severity: normal
User: debian-alpha@lists.debian.org
Usertags: alpha
Hi!
I am orphaning aboot on behalf of the current maintainer now as he
has agreed on removing the package [1].
I would like to adopt aboot and address the open RC bugs so it can
be kept in the main archive. This
Hello!
On 1/29/20 11:49 PM, John Paul Adrian Glaubitz wrote:
> One of the Gentoo developers has forked aboot and is maintaing it on
> Github [1]. I have filed an issue regarding the manpage issue and will
> coordinate a new release of the bootloader with the aforementioned
> issues addressed.
I
On 1/31/20 2:19 AM, jhcha54008 wrote:
> May I ask if there is a git repository (in salsa ?) following the
> debian variation of aboot ? (and including the history as a bonus ?)
I have not created such a repository yet. I have to ask Steve whether
he's got one for his packaging.
> Three RC bugs
Hi Adrian,
Nice that someone knowledgeable stepped in to salvage aboot.
Thanks in advance !
May I ask if there is a git repository (in salsa ?) following the
debian variation of aboot ? (and including the history as a bonus ?)
Three RC bugs are listed for src:aboot, with at least partial
Hi again!
One of the Gentoo developers has forked aboot and is maintaing it on
Github [1]. I have filed an issue regarding the manpage issue and will
coordinate a new release of the bootloader with the aforementioned
issues addressed.
I didn't know about these RC bugs otherwise I would have
On Wed, Jan 29, 2020 at 11:25:32PM +0100, John Paul Adrian Glaubitz wrote:
> I will look into this issue.
Ok, great!
Cheers,
Moritz
> Please remove aboot. It blocks the sgmltools-lite removal and is RC-buggy
> otherwise for a last
> time (like for the removal of sp). Steve Langasek pointed out as one of the
> last alpha maintainers
> in #949711 that the arch: all binaries can only be built on an alpha buildd,
> which we no
301 - 400 of 10905 matches
Mail list logo
