Control: reopen -1
Hi,
looks like this didn't work:
> https://buildd.debian.org/status/fetch.php?pkg=qt6-multimedia=powerpc=6.4.2-11=1705003199=0
Reopening the bug therefore.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0
So I have an ODS-2 SCSI drive connected to my Debain DS10, and there's some
files on there that I'd like to modify. Is it possible? I don't see any ODS
types in the MOUNT man pages, but maybe there's some super-secret ODS <-> Linux
driver/software/voodoo that lurks out in the ether?
Source: graphviz
Version: 2.42.2-9
X-Debbugs-Cc: t...@mirbsd.de, debian-po...@lists.debian.org
librsvg has become extremely unportable, and so only a subset of
architectures have it:
amd64 arm64 armel armhf i386 mips64el ppc64el riscv64 s390x
loong64 powerpc ppc64 sparc64
Please whitelist the
On 3/14/24 06:53, Thorsten Glaser wrote:
Dixi quod…
Is there a chance your team could fork the old python-cryptography
source package (3.4.8-2) and do something like:
Apparently, pyopenssl needs to also be forked as it wraps the above
and, between 21.0.0-1 and 22.1.0-1, it began requiring
Dixi quod…
>Is there a chance your team could fork the old python-cryptography
>source package (3.4.8-2) and do something like:
Apparently, pyopenssl needs to also be forked as it wraps the above
and, between 21.0.0-1 and 22.1.0-1, it began requiring the rust
version of python-cryptography ☹
Source: fsverity-utils
Version: 1.5-1.1
Severity: important
Justification: RC for Debian-Ports
X-Debbugs-Cc: t...@mirbsd.de, debian-po...@lists.debian.org
Recent versions of fsverity-utils (larger than 1.4-1~exp1 anyway)
have a Build-Depends-Arch on pandoc; however, pandoc is an extremely
Jérémy Lal dixit:
>Anyone had experience with the version 3.3 to 38.0 migration ?
>Maybe the API didn't change that much.
We cannot go past 3.4 because newer versions (starting at 38)
have a hard dependency on rust stuff.
bye,
//mirabilos
--
Solange man keine schmutzigen Tricks macht, und ich
Le lun. 11 mars 2024 à 21:53, Thorsten Glaser a écrit :
> Jérémy Lal dixit:
>
> >While I'm very much concerned about architectures and compatibility,
> >it seems that for python-cryptography, it's a sinking boat:
> >The end of a very discussion dates from february, 2021 - 3 years ago:
>
Jérémy Lal dixit:
>While I'm very much concerned about architectures and compatibility,
>it seems that for python-cryptography, it's a sinking boat:
>The end of a very discussion dates from february, 2021 - 3 years ago:
>https://github.com/pyca/cryptography/issues/5771#issuecomment-775990406
Le lun. 11 mars 2024 à 20:17, Thorsten Glaser a écrit :
> Hi,
>
> we have still the situation that the current python-cryptography,
> having rather heavy rust ecosystem dependencies, cannot be built
> on some debian-ports architectures.
>
> This situation is not likely to go away:
>
> • some
Hi,
we have still the situation that the current python-cryptography,
having rather heavy rust ecosystem dependencies, cannot be built
on some debian-ports architectures.
This situation is not likely to go away:
• some ports are unlikely to meet the dependencies soon
• new ports won’t meet them
On Tue, Mar 05, 2024 at 05:42:45PM +0200, Adrian Bunk wrote:
> liburing is Not-For-Us on Alpha since 2022, and if I saw it correctly
> imago was recently twice killed by bfs (which now uses io_uring).
>
> Recent kernels do contain io_uring fixes (e.g. in 5.10.186),
> which might or might not be
Hi,
liburing is Not-For-Us on Alpha since 2022, and if I saw it correctly
imago was recently twice killed by bfs (which now uses io_uring).
Recent kernels do contain io_uring fixes (e.g. in 5.10.186),
which might or might not be related.
Blacklisting liburing and packages build depending on it
On Tue, 2 Jan 2024 at 21:00, John Paul Adrian Glaubitz
wrote:
>
> On Tue, 2024-01-02 at 18:07 +, Dimitri John Ledkov wrote:
> > For cross building, as far as I can tell one needs to build the tool
> > twice - once for the BUILD architecture and once for HOST
> > architecture, use one during
On Tue, 2024-01-02 at 18:07 +, Dimitri John Ledkov wrote:
> For cross building, as far as I can tell one needs to build the tool
> twice - once for the BUILD architecture and once for HOST
> architecture, use one during the build and package the other one into
> the deb.
That's correct and I
On Tue, 2 Jan 2024 at 17:48, John Paul Adrian Glaubitz
wrote:
>
> Hi Dimitri!
>
> On Tue, 2024-01-02 at 17:37 +, Dimitri John Ledkov wrote:
> > a.out support has been dropped in upstream kernel. However a.out.h
> > header is still being using by abootimg tool via objstrip.c. It has
> >
Upstream linux kernel has deprecated a.out object format a while ago.
However aboot tool still has support for it, which is keeping a.out.h
header in the linux kernel.
I'm trying to remove it, but to achieve this somebody needs to test
that upgraded aboot still works.
See details at
Hi Dimitri!
On Tue, 2024-01-02 at 17:37 +, Dimitri John Ledkov wrote:
> a.out support has been dropped in upstream kernel. However a.out.h
> header is still being using by abootimg tool via objstrip.c. It has
> support for both a.out image types and ELF. I have blidly dropped
> a.out.h
Please forward my email to your purchasing department, we appreciate your help
very much.
Dear Sirs,
Nice day !
We are factory with 30 years practice in manufacturing all kinds of wire and
strand,
we focus on providing best materials and solutions,hope we can help you produce
better
Source: gtk4,librsvg
Severity: important
Tags: upstream help
X-Debbugs-Cc: debian-s...@lists.debian.org, debian-po...@lists.debian.org
gtk4 had a recent test failure regression on s390x and other big-endian
architectures like ppc64 (#1057782). I sent this upstream to
On Fri, Nov 24, 2023 at 01:53:04AM +0100, Guillem Jover wrote:
> Hi!
Hi Guillem!
Apologies for not replying to these emails earlier.
> On Tue, 2023-10-31 at 10:52:40 +0100, Guillem Jover wrote:
>...
> > If PIE (via specs files) appears to work on x32, and changing the
> > defaults in gcc is too
Hi!
On Tue, 2023-10-31 at 10:52:40 +0100, Guillem Jover wrote:
> I guess I could do it the other way, and given this is apparently
> causing issues as reported by Adrian, and as seen recently from
> the referenced bug report which might require patching a specific
> package to disable PIE there,
Hi!
On Tue, 2023-07-04 at 13:12:48 +0300, Adrian Bunk wrote:
> On Tue, Jul 04, 2023 at 09:23:43AM +0200, Guillem Jover wrote:
> > On Sun, 2023-07-02 at 00:02:46 +0300, Adrian Bunk wrote:
> > > There are some problems with this:
> > >
> > > 1. PIE should either be default or not be used
> > >
> >
On Sat, Oct 28, 2023 at 03:34:47PM +0300, Adrian Bunk wrote:
> On Fri, Oct 20, 2023 at 07:03:41AM +0100, Julian Gilbey wrote:
> > Hi!
> >
> > I'm completely out of my depth on this one, and I wonder whether
> > anyone might be able to help.
> > [...]
> > /usr/bin/ld:
On Fri, Oct 20, 2023 at 07:03:41AM +0100, Julian Gilbey wrote:
> Hi!
>
> I'm completely out of my depth on this one, and I wonder whether
> anyone might be able to help.
>
> I have just updated pydevd from 2.9.6+ds-1, uploaded 2023-06-23, to
> version 2.10.0+ds-1. But the build of the cython
Ahh I was looking in the wrong place - glibc-sources shows the fix
in 2.36-9+deb12u1:
glibc (2.36-9+deb12u1) bookworm; urgency=medium
[ Aurelien Jarno ]
* debian/patches/git-updates.diff: update from upstream stable branch:
- Affecting bookworm release architectures:
- Improve
Hi,
While updating QEMU's debian-all-test-cross docker image to bookworm I
found "check-tcg" broke for alpha. The docker image is essentially a
slim debian image with minimal qemu build deps and all the cross
compilers Debian packages that support a QEMU guest.
Digging into the failure it was
Hi!
I'm completely out of my depth on this one, and I wonder whether
anyone might be able to help.
I have just updated pydevd from 2.9.6+ds-1, uploaded 2023-06-23, to
version 2.10.0+ds-1. But the build of the cython extension now fails
on alpha: near the end of the build log
Source: mariadb
Version: 1:10.11.5-1
Tags: help, ftbfs
User: debian-alpha@lists.debian.org
Usertags: alpha
X-Debbugs-CC: debian-alpha@lists.debian.org
The alpha build passed once in
https://buildd.debian.org/status/fetch.php?pkg=mariadb=alpha=1%3A10.11.2-1=1678215912=0
because the post-build
On Tue, Jul 04, 2023 at 09:23:43AM +0200, Guillem Jover wrote:
> On Sun, Jul 02, 2023 at 12:02:46AM +0300, Adrian Bunk wrote:
> >...
> > Linking a package with hardening=+all against a static library
> > from a package not using hardening=+all cannot work on the
> > affected architectures.
>...
>
Hi Michael,
On Fri, 6 Oct 2023 09:42:40 +1300 Michael Cree
wrote:
I have tried the suggested script (with a small modification to count
number of failures) running for a few hours on one of the packages
that had failed on the buildd and never saw cmake fail.
But then building a few
On Fri, Sep 15, 2023 at 08:57:15PM +0200, Timo Röhling wrote:
> Hi Adrian,
Hi Timo,
thanks for taking a look (and sorry for the late reply).
> On Mon, 11 Sep 2023 01:20:53 +0300 Adrian Bunk wrote:
> > 1. The problem is about not finding a library,
> > it happens in many packages with many
Package: cmake
Version: 3.26.4-4
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: debian-alpha@lists.debian.org
Many (> 50) have been FTBFS on alpha recently due to
cmake not finding libraries.
This bug is sent against cmake with Cc to the debian-alpha
list to document and track this issue.
On Jul 22 2023, Rene Engelhard wrote:
> Hi,
>
> Am 22.07.23 um 16:09 schrieb Andreas Schwab:
>> On Jul 22 2023, Rene Engelhard wrote:
>>
>>> Am 22.07.23 um 15:53 schrieb Andreas Schwab:
On Jul 22 2023, Rene Engelhard wrote:
> Does opensuse have some public git/$VCS?
On Sat, Jul 22, 2023 at 8:10 AM Rene Engelhard wrote:
>
> Am 22.07.23 um 14:02 schrieb Andreas Schwab:
> > On Jun 18 2023, Rene Engelhard wrote:
> >
> >> For riscv64 I already pointed that out in the thread starting at
> >> https://lists.debian.org/debian-riscv/2023/06/msg0.html, but for the
Hi,
Am 22.07.23 um 16:09 schrieb Andreas Schwab:
On Jul 22 2023, Rene Engelhard wrote:
Am 22.07.23 um 15:53 schrieb Andreas Schwab:
On Jul 22 2023, Rene Engelhard wrote:
Does opensuse have some public git/$VCS?
On Jul 22 2023, Rene Engelhard wrote:
> Am 22.07.23 um 15:53 schrieb Andreas Schwab:
>> On Jul 22 2023, Rene Engelhard wrote:
>>
>>> Does opensuse have some public git/$VCS?
>> https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/libreoffice/standard/riscv64
>
> Thanks...
>
>
On Jul 22 2023, Rene Engelhard wrote:
> Does opensuse have some public git/$VCS?
https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/libreoffice/standard/riscv64
> (Though I would more bet of some system evironment thingy)
Perhaps it is a matter of using a good java. Have
Am 22.07.23 um 15:53 schrieb Andreas Schwab:
On Jul 22 2023, Rene Engelhard wrote:
Does opensuse have some public git/$VCS?
https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/libreoffice/standard/riscv64
Thanks...
But maybe I am too blind.
I don't see the actual
Hi,
Am 22.07.23 um 15:07 schrieb Andreas Schwab:
Which gives the smoketest test failure here I pointed out (again) in my
other mail.
$ find /usr/lib64/libreoffice/ -name "*smoke*"
/usr/lib64/libreoffice/program/classes/smoketest.jar
How can I run that?
You can't from that, ttbomk. You miss
Hi,
Am 22.07.23 um 15:02 schrieb Andreas Schwab:
On Jul 22 2023, Rene Engelhard wrote:
https://lists.debian.org/debian-riscv/2023/07/msg00014.html is for manual
thing. And the IRC log shows that even libreoffice-lightproof-en etc don't
appear as bundled extensions.
$ unopkg list --bundled
On Jul 22 2023, Rene Engelhard wrote:
> Hi,
>
> Am 22.07.23 um 14:28 schrieb Andreas Schwab:
>> On Jul 22 2023, Rene Engelhard wrote:
>>
>>> Yes. _basically_. (Only with -O0 or maybe -Os as upstreams makefile says,
>>> though)
>> On openSUSE Factory, libreoffice is built with the usual compiler
On Jul 22 2023, Rene Engelhard wrote:
> https://lists.debian.org/debian-riscv/2023/07/msg00014.html is for manual
> thing. And the IRC log shows that even libreoffice-lightproof-en etc don't
> appear as bundled extensions.
$ unopkg list --bundled
All deployed bundled extensions:
Identifier:
On Jul 22 2023, Rene Engelhard wrote:
> And that includes LibreOffice-bundled extensions like the
> english,hungarian,russian grammar checker for example. Ot external finnish
> spellchecking, hyphenation and grammer checking. Or turkish spellchecing.
>
> And those are extensions written in python
On Jul 22 2023, Rene Engelhard wrote:
> Yes. _basically_. (Only with -O0 or maybe -Os as upstreams makefile says,
> though)
On openSUSE Factory, libreoffice is built with the usual compiler flags,
wich includes full optimisation and hardening.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key
On Jul 22 2023, Rene Engelhard wrote:
> Just not registering or unregistering *any* extension.
What does that mean? I haven't seen any errors about extensions.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for
Hi,
Am 22.07.23 um 14:34 schrieb Andreas Schwab:
On Jul 22 2023, Rene Engelhard wrote:
And that includes LibreOffice-bundled extensions like the
english,hungarian,russian grammar checker for example. Ot external finnish
spellchecking, hyphenation and grammer checking. Or turkish spellchecing.
Hi,
Am 22.07.23 um 14:28 schrieb Andreas Schwab:
On Jul 22 2023, Rene Engelhard wrote:
Yes. _basically_. (Only with -O0 or maybe -Os as upstreams makefile says,
though)
On openSUSE Factory, libreoffice is built with the usual compiler flags,
wich includes full optimisation and hardening.
Hi,
Am 22.07.23 um 14:25 schrieb Andreas Schwab:
On Jul 22 2023, Rene Engelhard wrote:
Just not registering or unregistering *any* extension.
What does that mean? I haven't seen any errors about extensions.
Do you run the testsuite?
Especially the smoketest?
And you are replying to
Hi,
Am 22.07.23 um 14:09 schrieb Rene Engelhard:
And that included packaged extensions so if they install but don't work
that's a grave bug.
And that includes LibreOffice-bundled extensions like the
english,hungarian,russian grammar checker for example. Ot external
finnish spellchecking,
On Jun 18 2023, Rene Engelhard wrote:
> For riscv64 I already pointed that out in the thread starting at
> https://lists.debian.org/debian-riscv/2023/06/msg0.html, but for the
> other architectures there is the mail now. riscv64 is different because
> the failures are even more big than any
Hi,
Am 22.07.23 um 14:02 schrieb Andreas Schwab:
On Jun 18 2023, Rene Engelhard wrote:
For riscv64 I already pointed that out in the thread starting at
https://lists.debian.org/debian-riscv/2023/06/msg0.html, but for the
other architectures there is the mail now. riscv64 is different
On Fri, Jul 21, 2023 at 06:14:04PM +1000, Finn Thain wrote:
>
> I'm not blaming the unstable API for the bugs, I'm blaming it for the
> workload. A stable API (like a userspace API) decreases the likelihood
> that overloaded maintainers have to orphan a filesystem implementation.
You are
On Fri, 21 Jul 2023, Matthew Wilcox wrote:
>
> You've misunderstood. Google have decided to subject the entire kernel
> (including obsolete unmaintained filesystems) to stress tests that it's
> never had before. IOW these bugs have been there since the code was
> merged. There's nothing to
On Fri, Jul 21, 2023 at 11:03:28AM +1000, Finn Thain wrote:
> On Fri, 21 Jul 2023, Dave Chinner wrote:
>
> > > I suspect that this is one of those catch-22 situations: distros are
> > > going to enable every feature under the sun. That doesn't mean that
> > > anyone is actually _using_ them
On Fri, 21 Jul 2023, Dave Chinner wrote:
> > I suspect that this is one of those catch-22 situations: distros are
> > going to enable every feature under the sun. That doesn't mean that
> > anyone is actually _using_ them these days.
I think the value of filesystem code is not just a question
On Thu, 20 Jul 2023 at 15:37, Matthew Wilcox wrote:
>
> I think you're missing the context. There are bugs in how this filesystem
> handles intentionally-corrupted filesystems. That's being reported as
> a critical bug because apparently some distributions automount HFS/HFS+
> filesystems
On Thu, Jul 20, 2023 at 05:38:52PM -0400, Jeffrey Walton wrote:
> On Thu, Jul 20, 2023 at 2:39 PM Matthew Wilcox wrote:
> >
> > On Thu, Jul 20, 2023 at 07:50:47PM +0200, John Paul Adrian Glaubitz wrote:
> > > > Then we should delete the HFS/HFS+ filesystems. They're orphaned in
> > > >
On Thu, Jul 20, 2023 at 02:27:50PM -0400, Jeff Layton wrote:
> On Thu, 2023-07-20 at 18:59 +0100, Matthew Wilcox wrote:
> > On Thu, Jul 20, 2023 at 07:50:47PM +0200, John Paul Adrian Glaubitz wrote:
> > > > Then we should delete the HFS/HFS+ filesystems. They're orphaned in
> > > > MAINTAINERS
On Thu, Jul 20, 2023 at 2:39 PM Matthew Wilcox wrote:
>
> On Thu, Jul 20, 2023 at 07:50:47PM +0200, John Paul Adrian Glaubitz wrote:
> > > Then we should delete the HFS/HFS+ filesystems. They're orphaned in
> > > MAINTAINERS and if distros are going to do such a damnfool thing,
> > > then we
On Thu, 2023-07-20 at 18:59 +0100, Matthew Wilcox wrote:
> On Thu, Jul 20, 2023 at 07:50:47PM +0200, John Paul Adrian Glaubitz wrote:
> > > Then we should delete the HFS/HFS+ filesystems. They're orphaned in
> > > MAINTAINERS and if distros are going to do such a damnfool thing,
> > > then we
On Thu, Jul 20, 2023 at 07:50:47PM +0200, John Paul Adrian Glaubitz wrote:
> > Then we should delete the HFS/HFS+ filesystems. They're orphaned in
> > MAINTAINERS and if distros are going to do such a damnfool thing,
> > then we must stop them.
>
> Both HFS and HFS+ work perfectly fine. And if
On Mon, Jul 03, 2023 at 09:31:29PM +0200, Rene Engelhard wrote:
> Hi,
>
> Am 25.06.23 um 13:37 schrieb Rene Engelhard:
> > > what about the
> > > following:
> > > - make all test failures fatal on a*64 (since upstream tests these), and
> > > - make smoketest failures fatal on all architectures
On Tue, Jul 04, 2023 at 09:23:43AM +0200, Guillem Jover wrote:
> Hi!
Hi Guillem!
> On Sun, 2023-07-02 at 00:02:46 +0300, Adrian Bunk wrote:
>...
> > There are some problems with this:
> >
> > 1. PIE should either be default or not be used
> >
> > I suspect x32 might be able to default to PIE
Hi!
On Sun, 2023-07-02 at 00:02:46 +0300, Adrian Bunk wrote:
> Package: dpkg-dev
> Version: 1.21.22
> Severity: normal
> X-Debbugs-Cc: debian-alpha@lists.debian.org, debian-i...@lists.debian.org
> Since stretch all release architectures are using PIE by default,
> and all future release
Hi,
Am 03.07.23 um 21:31 schrieb Rene Engelhard:
Am 25.06.23 um 13:37 schrieb Rene Engelhard:
what about the
following:
- make all test failures fatal on a*64 (since upstream tests these), and
- make smoketest failures fatal on all architectures (including ports)
That was implemented (+ two
Hi,
Am 25.06.23 um 13:37 schrieb Rene Engelhard:
what about the
following:
- make all test failures fatal on a*64 (since upstream tests these), and
- make smoketest failures fatal on all architectures (including ports)
That was implemented (+ two more important tests) in experimental. See
Package: dpkg-dev
Version: 1.21.22
Severity: normal
X-Debbugs-Cc: debian-alpha@lists.debian.org, debian-i...@lists.debian.org
[ Cc set to debian-alpha@ and debian-ia64@ since they are most affected ]
Since stretch all release architectures are using PIE by default,
and all future release
Hi,
Am 20.06.23 um 10:25 schrieb Adrian Bunk:
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have
On Tue, 2023-06-20 at 22:46 +0200, Kurt Roeckx wrote:
> Can I suggest that if you file a few bugs and add some information in
> it so that maybe someone can look at it? If it only affects one
> architecture, send a mail to that list asking for help.
PS: when filing architecture-specific bugs,
Can I suggest that if you file a few bugs and add some information in it so
that maybe someone can look at it? If it only affects one architecture, send a
mail to that list asking for help.
Kurt
Hi,
Am 20.06.23 um 16:52 schrieb Kurt Roeckx:
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:
> Hi,
>
> Am 19.06.23 um 23:29 schrieb Rene Engelhard:
> > > The pragmatic option would be to run only a smoketest for build success
> > > on architectures not tested by upstream.
> >
> > And have Format->Character in Impress crash
Stop sending these emails please!
Sent from my iPhone
> On 20 Jun 2023, at 09:42, Adrian Bunk wrote:
>
> On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:
>> Hi,
>>
>> Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:
> Hi,
>
> Am 19.06.23 um 23:29 schrieb Rene Engelhard:
> > > The pragmatic option would be to run only a smoketest for build success
> > > on architectures not tested by upstream.
> >
> > And have Format->Character in Impress crash
On Mon, Jun 19, 2023 at 11:50 PM Rene Engelhard wrote:
>
> Am 20.06.23 um 00:03 schrieb Jeffrey Walton:
> >
> > You can usually uncover them by building the package with CFLAGS=" ...
> > -fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined ...
> > ". The UBsan sanitizer operates on
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.
There
Hi,
Am 20.06.23 um 00:03 schrieb Jeffrey Walton:
You can usually uncover them by building the package with CFLAGS=" ...
-fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined ...
". The UBsan sanitizer operates on real data. There are no false
positives.
I'd personally assume
On Mon, Jun 19, 2023 at 11:29:34PM +0200, Rene Engelhard wrote:
>...
> Am 19.06.23 um 23:19 schrieb Adrian Bunk:
>...
> > For such a complex package I would expect 32bit breakage in every
> > release if upstream no longer tests on 32bit.
> Indeed, though at least for 32bit *build* issues they keep
On Mon, Jun 19, 2023 at 5:30 PM Rene Engelhard wrote:
>
> Hi,
>
> Am 19.06.23 um 23:19 schrieb Adrian Bunk:
> > On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote:
> >> ...
> >> I won't be of much help here unfortunately, except
> >> maybe testing patches, but then again there's
On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote:
>...
> I won't be of much help here unfortunately, except
> maybe testing patches, but then again there's porterboxes
>...
You are the only one who could realistically debug many of these.
E.g. on armel it says:
Fatal exception:
Hi,
Am 19.06.23 um 23:19 schrieb Adrian Bunk:
On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote:
...
I won't be of much help here unfortunately, except
maybe testing patches, but then again there's porterboxes
...
You are the only one who could realistically debug many of these.
Hi,
let me add some additional data point(s):
After some testing on different machines and with different kernel types
it looks like this problem is exclusive to MP kernels. This also when
running a MP kernel on a single processor machine actually (tested on an
AlphaServer 800 5/400 w/EV56).
On Sunday 2023-06-18 23:37, Rob Landley wrote:
>On 6/18/23 14:58, Rene Engelhard wrote:
>>> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3
>>> and
>>> the AGPL have been rejected soundly by most developers" and talked about
>>> how he
>>> regretted the move and the
On 6/18/23 15:19, Rene Engelhard wrote:
> Besides that it would also have been clear from actually reading the IRC
> log which incidentially also says
Good to know what the expectations for participation are.
>> This is the same GPLv3 package that Red Hat just dropped support for?
>
> As I
On June 18, 2023 11:37:55 PM GMT+02:00, Rob Landley wrote:
>On 6/18/23 14:58, Rene Engelhard wrote:
>>> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3
>>> and
>>> the AGPL have been rejected soundly by most developers" and talked about
>>> how he
>>> regretted the
On 6/18/23 14:58, Rene Engelhard wrote:
>> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 and
>> the AGPL have been rejected soundly by most developers" and talked about how
>> he
>> regretted the move and the damage it had done to the project,
>>
Hi again,
some more comments.
Am 18.06.23 um 21:28 schrieb Rob Landley:
No, that's how I read it too. You said getting the _architectures_
removed, not
getting libreoffice removed from those architectures.
That is hilarious. The subject says we are talking about LibreOffice
here, not
Hi,
Am 18.06.23 um 21:28 schrieb Rob Landley:
Of course I mean "getting those architectures removed from unstable"
*for libreoffice*.
This is the same GPLv3 package that Red Hat just dropped support for?
GPLv3 doesn't have anything to do with this here.
https://lwn.net/Articles/933525/
On 6/18/23 03:45, Rene Engelhard wrote:> Am 18.06.23 um 10:32 schrieb Rene
Engelhard:
I don't really like sweeping it under the carpet again and would
actually pursue the "getting those architectures removed from unstable"
way pointed out and (implicitely) approved/suggested by the
> Le 18 juin 2023 à 13:37, Steve McIntyre a écrit :
>
> On Sun, Jun 18, 2023 at 10:32:55AM +0200, Rene Engelhard wrote:
>> Hi,
>>
>>> Am 18.06.23 um 10:19 schrieb John Paul Adrian Glaubitz:
>>> On Sun, 2023-06-18 at 09:31 +0200, Rene Engelhard wrote:
Also note I am not talking about
On Sun, Jun 18, 2023 at 10:32:55AM +0200, Rene Engelhard wrote:
>Hi,
>
>Am 18.06.23 um 10:19 schrieb John Paul Adrian Glaubitz:
>> On Sun, 2023-06-18 at 09:31 +0200, Rene Engelhard wrote:
>> > Also note I am not talking about the debian-ports architectures. Those I
>> > forgot and I have no
Hi again.
Am 18.06.23 um 10:32 schrieb Rene Engelhard:
I don't really like sweeping it under the carpet again and would
actually pursue the "getting those architectures removed from unstable"
way pointed out and (implicitely) approved/suggested by the release
team...
You want Debian to drop
Hi,
Am 18.06.23 um 10:19 schrieb John Paul Adrian Glaubitz:
On Sun, 2023-06-18 at 09:31 +0200, Rene Engelhard wrote:
Also note I am not talking about the debian-ports architectures. Those I
forgot and I have no problems making them stay into "testsuite ran but
results ignored" set.
Why did
Hello!
On Sun, 2023-06-18 at 09:31 +0200, Rene Engelhard wrote:
> Also note I am not talking about the debian-ports architectures. Those I
> forgot and I have no problems making them stay into "testsuite ran but
> results ignored" set.
Why did you send this mail exclusively to debian-ports then?
Hi,
I originally wanted to send the mail after all the architectures got
result but now even after 6d mips64el didn't try it so I send it now.
Prompted by riscv64 supposed to be added to the archive and even
as a release arch for trixie - see
Hello!
I have created updated installation images for Debian Ports.
These can be found here:
- https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-14/
On ia64, these images should be usable on all machines again since
the previous regression in kernel 6.1 has been fixed in 6.3 which
is
I'm going to test Alpha port on distinct models. I will report!
El mar., 6 jun. 2023 15:52, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> escribió:
> Hello!
>
> I have created updated installation images for Debian Ports.
>
> These can be found here:
>
> -
Hello!
I have created updated installation images for Debian Ports.
These can be found here:
- https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-06/
I have already successfully tested the sparc64 installer.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `'
On Sat, Jun 3, 2023 at 6:30 AM Frank Scheiner wrote:
>
> On 29.05.23 01:00, Song Liu wrote:
> > Frank reported boot regression in ia64 as:
> >
> > ELILO v3.16 for EFI/IA-64
> > ..
> > Uncompressing Linux... done
> > Loading file AC100221.initrd.img...done
> > [0.00] Linux version
1 - 100 of 10904 matches
Mail list logo
