reassign 1052197 xorgxrdp
affects 1052197 xrdp
found 1052197 1:0.2.12-1
fixed 1052197 1:0.2.12-1+deb11u1
fixed 1052197 1:0.9.19-1
thanks
Gürkan Myczko dixit:
> This bug has been closed upstream, and upstream packages have been in
> the archive for a while.
No, the bug has been fixed by
Bastian Germann dixit:
>dietlibc includes the sunrpc code from old glibc versions, which is
>demonstrated to be non-free in #181493.
The text in dietlibc reads thusly though:
Users
* may copy or modify Sun RPC without charge,
Emanuele Rocca dixit:
>The attached patch by Vladimir Petko was sent upstream and fixes the
>FTBFS on armhf/armel.
The patch is catastrophically wrong.
+- snprintf(flushtime, sizeof(flushtime), "%ld\n", now);
++ snprintf(flushtime, sizeof(flushtime), "%lld\n", now);
Change that to:
Andrey Rakhmatullin dixit:
>OPAL_THREAD_ADD_FETCH64 is defined under #if OPAL_HAVE_ATOMIC_MATH_64
Yes.
>, and I suspect not all of its uses also are.
That’s what I get from this, yes.
>And I assume this arch doesn't have 64-bit atomics.
No native ones, yes.
I *think* either libatomic or
Package: openjdk-17-jre
Version: 17.0.11~6ea-1
Severity: serious
Justification: uninstallable
Depends: openjdk-17-jre-headless (= 17.0.11~6ea-1),
libglib2.0-0t64 (>= 2.24), […], libcups2, […]
This must of course be libcups2t64.
Source: pulseaudio
Version: 16.1+dfsg1-3
Severity: serious
Justification: FTBFS
Tags: ftbfs
X-Debbugs-Cc: t...@mirbsd.de
Unfortunately, as with umockdev, I have no idea what is going on
here… does it #undef _FILE_OFFSET_BITS or something?
Source: umockdev
Version: 0.18.0-1
Severity: serious
Justification: FTBFS on t64-affected archs
X-Debbugs-Cc: t...@mirbsd.de
Tags: ftbfs
cc -Ilibumockdev-preload.so.0.0.0.p -I. -I.. -fdiagnostics-color=always -Wall
-Winvalid-pch -std=gnu11 -Werror=missing-prototypes -Werror=strict-prototypes
Matthias Klose dixit:
> the Debian build log doesn't show this error message, so this sphinx
> inventory is fetched from the website during the build.
Huh? Does sbuild/buildd not unshare the network?
I added that to pbuilder some time ago and vaguely recall
that there was an expectation that
Package: libgts-0.7-5t64
Version: 0.7.6+darcs121130-5.1
Severity: grave
Justification: uninstallable
X-Debbugs-Cc: t...@mirbsd.de, vor...@debian.org
Control: affects -1 src:graphviz libgvc6
When building against libgts-0.7-5t64, the generated packages
get a shlib:Depends of 'libgts-0.7-5 (>=
Source: openmpi
Version: 4.1.6-7
Severity: serious
Justification: ftbfs
Tags: ftbfs
Tag: ftbfs
X-Debbugs-Cc: t...@mirbsd.de
[…]
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../../../../../opal/mca/btl/ofi
-I../../../../opal/include -I../../../../ompi/include
-I../../../../oshmem/include
Hi Andreas,
>Afaict ghostscript/fig2dev have stopped being blockers so I do not plan
>on doing another upload (with more work for the other autobuilders) just
>to temporarily disable these b-ds.
Indeed, that’s fine. But including that in the n̲e̲x̲t̲ upload
you do anyway would be nice.
Thanks,
Dixi quod…
>Suggested fix:
>
>+ AC_CHECK_HEADERS(gssapi/gssapi_krb5.h)
> AC_CHECK_FUNCS(gsskrb5_register_acceptor_identity)
> if test "$ac_cv_func_gsskrb5_register_acceptor_identity" = no ; then
>- AC_CHECK_HEADERS(gssapi/gssapi_krb5.h)
>
>If it’s really that, anyway.
At least it allows the
Dixi quod…
>I just tested the 2.2 patch on gnupg1, and it applies cleanly,
>[…]
>For gnupg1, the B-D are also already installable, so there’s no
>current need to modify them there, just apply the same patch as
>was applied in gnupg2 2.2 and upload.
It finished building with the patch, so please
Andrey Rakhmatullin dixit:
>On Wed, Mar 13, 2024 at 12:36:37PM +0100, Lucas Nussbaum wrote:
>> > gssapi.c:1600:9: error: implicit declaration of function
>> > ‘gsskrb5_register_acceptor_identity’
>> > [-Werror=implicit-function-declaration]
>> > 1600 |
Hi again,
>on 1.x or 2.4 before the weekend.
I just tested the 2.2 patch on gnupg1, and it applies cleanly,
and configure also seems happy:
[…]
checking whether the resolver is usable... yes
checking whether LDAP via "-lldap" is present and sane... yes
checking for ldap_get_option... yes
Source: cyrus-sasl2
Version: 2.1.28+dfsg1-4
Severity: serious
Justification: breaks
X-Debbugs-Cc: t...@mirbsd.de
cyrus-sasl2, before aborting the build due to #1066214, spews
several warnings like the following:
[…]
otp.c:648:43: warning: format '%ld' expects argument of type 'long int', but
Hi Andreas
>I have upload a fix for 2.2
OK, that should help.
>probably will not be able to spend any time on 1.x or 2.4 before the weekend.
They can probably wait until then, no worries.
>It is fixed in 2.4 and I am very reluctant to backport major packaging
>updates to 2.2
For some values
clone 1066137 -1
reassign -1 gnupg1 1.4.23-1.1
retitle -1 gnupg1: fails to build gpgkeys_ldap, probably due to
-Werror=implicit-function-declaration
thanks
Dixi quod…
>This matches the following failure mode at the end of the build:
Same for gnupg1 according to the buildd page:
Source: gnupg2
Version: 2.2.40-1.1
Severity: serious
Justification: ftbfs
X-Debbugs-Cc: t...@mirbsd.de
Trying to binNMU gnupg2 to make it installable during t64 transition,
I notice the following configury output:
[…]
checking for library containing dn_skipname... none required
checking whether
close 1066051
thanks
Fab Stz dixit:
>I usually install openjdk-8 from unstable on bookworm.
This has never been officially supported. I’ve had an entire
discussion around that last month, which I will quote parts
from below, for context.
>However this is not possible anymore because now it
Package: molly-guard
Version: 0.8.3
Severity: grave
Justification: renders package unusable
Severity chosen both because this makes the package unusable (I will
have to remove it now) and because it breaks the whole system (boot).
root@aranym:/var/cache/apt/archives # poweroff
W: molly-guard:
>-%(cc1_cpu) -nostdinc -isystem /usr/include/mips64el-linux-musl -isystem
>include%s
>+%(cc1_cpu) -nostdinc -isystem /usr/include/mips64el-linux-musl -isystem
>include%s %(old_cc1)
Since old_cc1 includes cc1_cpu already, it can probably even be dropped.
bye,
//mirabilos
--
you introduced a
Hi musl maintainers,
waldi indeed provided a fix for this bug forgot to Cc me, so I missed
it until now. I tested this:
(sid_mips64el-dchroot)tg@eberlin:~$ sh -x $(which musl-gcc) hello.c
+ exec mips64el-linux-gnuabi64-gcc hello.c -specs
/usr/lib/mips64el-linux-musl/musl-gcc.specs
On Fri, 12 Jan 2024, Rafael Laboissière wrote:
> experimental, the configure script does detect the absence of the
> xmlNanoFTPNewCtxt function in the libxml2 library (version
> 2.12.3+dfsg-0exp1) and disables the call to the xmlNanoFTP* functions.
> However, this rebuilt will not be
On Mon, 25 Dec 2023, Rene Engelhard wrote:
> In any case, *this* bug is about the ABI change: removed symbols/versions
> other
> stuff relies on.
>
> Long story short: libxml2 2.12 has still a long road to go with much work on
> your side until you can upload it to unstable.
Sounds like it
tags 1057550 + pending
thanks
Santiago Vila dixit:
> Hi. I think we can skip the ssh thing, as this one is easy
> to diagnose: Missing Build-Depends on tzdata.
>
> Please use debootstrap from trixie/sid to reproduce. Details here:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837060
Oh,
Hi,
this applies only to Raspian, not to Debian; in Debian, older releases
used /boot/firmware as well. I suggest to go ask the Raspian people to
fix what they broke.
Mixing packages from other distributions (here Raspian) with Debian
packages is not generally supported.
bye,
//mirabilos (not
On Tue, 7 Nov 2023, Helmut Grohne wrote:
>Do you know why Breaks+Replaces has been chosen here? Do you see any
>issues with upgrading to Conflicts?
Probably because lintian indicates that that should be the
normal thing to do in such cases, and before UsrMove it
was the working thing, too…
bye,
On Tue, 31 Oct 2023, Mark Hindley wrote:
>As Ian pointed out[2], there are significant and surprising changes in looping
>order and behaviour between the successful and failing testsuites. The diff is
>attached.
Could this be related to #989284 where we also haven’t figured out
yet why this
On Thu, 21 Sep 2023, Markus Koschany wrote:
>dependency problem between xrdp and xorgxrdp. If you claim that without a
>rebuild of xorgxrdp a new upstream version of xrdp would be broken, then this
>is a strong indication that xorgxrdp should be more than a recommendation in
>Debian terms:
No,
tags 1052197 + patch
thanks
On Wed, 20 Sep 2023, Thorsten Glaser wrote:
>I’ll try binNMU’ing (locally) xorgxrdp, and if that doesn’t help,
OK, that helped! It went fast.
Installing the binNMU’d package xorgxrdp_0.2.12-1+b0.1_amd64.deb
(and killing all /usr/lib/xorg/Xorg processes spawned f
On Wed, 20 Sep 2023, Thorsten Glaser wrote:
>Attached
… and now with.
//mirabilos
--
15:41⎜ Somebody write a testsuite for helloworld :-)
buglogs.tgz
Description: application/gtar-compressed
Hallo Markus,
>the new Bullseye version of xrdp is identical to the version in Bookworm. Thus
>the underlying problem is probably more complex and I don't suspect that
>something is wrong with xrdp itself but more likely with a configuration option
>or related software packages which do something
On Tue, 19 Sep 2023, Thorsten Glaser wrote:
>Then, to test it, I logged in, but all I get is a window with a turquoise
>background, nothing on it. I *can* however see in ps(1) that my session
>(IceWM, kwalletcli) is started; it’s just not transmitted to rdesktop.
It also has funny
Package: xrdp
Version: 0.9.21.1-1~deb11u1
Severity: serious
Justification: does not work
X-Debbugs-Cc: t...@mirbsd.de, t...@security.debian.org
I’ve just upgraded the xrdp package. I had made sure to terminate the
old service before the new version is started.
Then, to test it, I logged in, but
reassign 1050429 gcc-13 13.2.0-2
notfound 1050429 12.3.0-8
affects 1050429 musl-tools
thanks
Dixi quod…
>The -EL is not even musl-specific?!
>
>(sid_mips64el-dchroot)tg@eller:~$ cat
>"/usr/lib/mips64el-linux-musl/musl-gcc.specs"
[…]
Worse, doing mips64el-linux-gnuabi64-gcc{,-12} -dumpspecs and
Dixi quod…
>(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc hi.c -EL
>(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc hi.c -specs
>"/usr/lib/mips64el-linux-musl/musl-gcc.specs"
>mips64el-linux-gnuabi64-gcc: error: unrecognized command-line option '-EL'
Dixi quod…
>According to upstream documentation, -EL is supposed to be supported
>by the compiler driver:
OK so it’s not the compiler *driver*…
(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc hi.c -EL
(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc hi.c -specs
Hm.
According to upstream documentation, -EL is supposed to be supported
by the compiler driver:
https://gcc.gnu.org/onlinedocs/gcc/MIPS-Options.html
bye,
//mirabilos
--
"Using Lynx is like wearing a really good pair of shades: cuts out
the glare and harmful UV (ultra-vanity), and you
Package: musl-tools
Version: 1.2.3-1
Severity: serious
Justification: unusable on release architectures
X-Debbugs-Cc: t...@mirbsd.de, debian-...@lists.debian.org
Control: affects -1 src:mksh
Unsure if it’s musl or gcc-13_13.2.0-2 but building a simple
test program fails on both mips64el and
James Addison dixit:
>AssertionError [ERR_ASSERTION]: The input did not match the regular
> expression /RangeError: Maximum call stack size exceeded/. Input:
>
>'Segmentation fault\n'
You removed the subtraction of V8_STACK_RESERVE when mutilating
my patch; this may be related (if
James Addison dixit:
>... to add something like this:
Ouch, by going via a string?! I wouldn’t have thought of that…
> if (!(flags & ProcessInitializationFlags::kNoAdjustResourceLimits)) {
>struct rlimit lim;
>if (getrlimit(RLIMIT_STACK, ) == 0) {
> char stackSize[32];
32 is
James Addison dixit:
>I'm going to stay involved with this thread, but I think that it is
>upon you to develop or provide further guidance towards a patch if
>it's something you'd like to have implemented, Thorsten.
I actually have looked into that but I don’t understand the nodejs
and v8 source
James Addison dixit:
>So: a fix here won't achieve stack capacity equality across
No. The fix you proposed won’t achieve that but others would
improve the situation much more, so that equality across arches
won’t need to matter any more.
>Or, to put it another way: applying an increase (either
James Addison dixit:
>On Thu, 11 May 2023 at 02:43, Andres Salomon wrote:
>> For ARM64, he says that raising the stack limit is not safe for v8
>> *embedded inside WebView*, and therefore not appropriate for upstream
>> v8. But then he says it could/should be safe for v8 *embedded inside
>>
On Sun, 9 Apr 2023, Markus Koschany wrote:
>maven-compiler-plugin. Usually this just works without changes to the version
>number. I don't think a strict plugin dependency is the true solution but it
>might help future contributors to remember the RC bug.
Also not a real fix but more sustainable
James Addison dixit:
>Based on what I've learned about this bug, I believe that architecture-specific
>behaviour related to stack sizes is inherent in the V8 library vendored by
>upstream NodeJS.
Yes, but the v8 library’s defaults are targetting a browser, and one
whose uses are much wider, e.g.
Jérémy Lal dixit:
>I can build nodejs on amhdal.debian.org if you're not comfortable with that.
The problem with the DSA porterboxen is that you cannot install your own
built packages in the chroot to use them there… unless there’s a
solution not yet known to me?
bye,
//mirabilos
--
“ah that
James Addison dixit:
>Hi - what do you both think of the attached patch, which brings the ARM stack
>size into line with almost all other architectures (= 984 KB)?
It might do the job unless arm64 for some reason uses more stack
elsewhere as well.
Can you test it? I don’t have the bandwidth for
James Addison dixit:
>Maybe it's rare to propose 'do nothing' as a technical suggestion but I think
>it is worth considering here, since we are not the arbiters of Node.
It’s still a release-critical bug in Debian which impacts arm64 builders
including reproducible-builds. I would see this fixed
Hi James,
(you might wish to Cc <${bugnumber}-submit...@bugs.debian.org> so they
actually get the reply…)
>Are you able to determine whether https://github.com/nodejs/node/issues/41163
>(and/or any of the guidance within that thread) seems relevant to this bug?
It appears so. I commented there,
Sebastian Andrzej Siewior dixit:
>How is this getting to work without manpages-fr contributing to it?
By adding a conflict (can’t remember if it has to be Conflicts or Breaks
will also work) plus Replaces on manpages-fr (<< 4.17.0-2~bpo11+1) on
xz-utils in bookworm. (And the others similarily.)
Sebastian Andrzej Siewior dixit:
>Good. So unless Thorsten disagrees this is done ;)
Please also test the upgrade with 4.16.0-1~bpo11+1 installed
on bullseye instead of 4.17.0-2~bpo11+1 (since that is a valid
upgrade path), without going via 4.17.0-2~bpo11+1.
bye,
//mirabilos
--
15:41⎜
Source: klibc
Version: 2.0.11-1
Severity: serious
Justification: ABI issue on release architecture
Tags: patch
On 64-bit MIPS platforms, struct stat’s members st_{a,m,c}time{,nsec}
and following (st_blksize, st_blocks) are mislayouted. Upstream git
commit 12f259dda1ef59b5f1f2fb67631dcbf94c18c56c
Package: nodejs
Version: 18.13.0+dfsg1-1
Severity: serious
Tags: upstream
Justification: breaks on release architecture
X-Debbugs-Cc: t...@mirbsd.de
Control: affects -1 src:dygraphs
During reproducible-builds testing, I found that one of my packages,
the one with nodejs used during build, worked
Debian FTP Masters dixit:
>Changed-By: Sebastian Andrzej Siewior
>Changes:
> xz-utils (5.4.1-0.1) unstable; urgency=medium
> .
> * Non-maintainer upload.
> * Update pt_BR translations.
> * Add lintian overrides and an override for blhc.
This is missing the updated Breaks+Replaces for
Helge Kreutzmann dixit:
>> >odler than stable. It also shipped them in every backport until
>> >4.16.0-3~bpo11+1. It is also in the upcoming 4.17.0-2~bpo11+1.
>> >
>> >But I wonder if I should remove them there.
>>
>> Yes, please. Otherwise it’s impossible to do the package
>Done in the upcoming
Helge Kreutzmann dixit:
>odler than stable. It also shipped them in every backport until
>4.16.0-3~bpo11+1. It is also in the upcoming 4.17.0-2~bpo11+1.
>
>But I wonder if I should remove them there.
Yes, please. Otherwise it’s impossible to do the package
relationships right. This will leave
Hi Andreas,
a bit out of order, but easier to respond (I’m a bit under the
weather so excuse any issues ahead of time):
>By 'disabled' I assume you mean 'Never', right?
Uhm, short walkthrough:
• Native
• Full
• Never
• Yes
>Did it also create 10-no-sub-pixel.conf ?
Sebastian Andrzej Siewior dixit:
>It is bpo but if you look I'd you look at the files for the same
>version in bpo and sid you will see that sid skipped a few man pages
>while bpo created them.
Ouch!
That adds to the problems, of course. That makes fully resolving
this in all possible
Sebastian Andrzej Siewior dixit:
>Then I will update the versions as suggested. My understanding was the
>problem persists because the bpo version was not yet updated. The
>version in sid did not ship the man-pages.
The bpo version was once in both sid and testing and this
is therefore a problem
Sebastian Andrzej Siewior dixit:
>Okay. So I do nothing and just wait for the bpo package to appear which
>will then solve the problem?
No, you must fix the problem in xz-utils in bookworm/sid as well.
It also exists outside of backports.
bye,
//mirabilos
--
22:20⎜ The crazy that persists in
Helge Kreutzmann dixit:
>The problem is that we both upload (conflicting) packages to
>backports. I'm not sure a good solution exists here.
No, you need to fix the package relationships for incremental
and partial upgrades in sid anyway.
As far as I can tell, manpages-fr had the first version
Sebastian Andrzej Siewior dixit:
>> As far as I can tell it must be (<< 4.17.0-1~) instead.
>> (Also do note the tilde, it breaks bpo otherwise.)
>
>Okay. So I add this new suggested version and close 1028375?
I think so. 4.17.0-1 was the first version of -fr to not
ship it any more (from
reopen 1028375
found 1028375 5.4.1-0.0
thanks
Patrice Duroux dixit:
>Was this supposed to be closed? Or will it be with another manpages-fr bpo?
5.4.1-0.0 only conflicts with manpages-fr (<< 4.1.0-1)
so the upload did not fix the problem.
As far as I can tell it must be (<< 4.17.0-1~) instead.
Package: fontconfig
Version: 2.14.1-3
Severity: serious
Justification: Policy 10.7.3
X-Debbugs-Cc: t...@mirbsd.de
> * local changes must be preserved during a package upgrade, and
After an upgrade, etckeeper reports that
/etc/fonts/conf.d/10-sub-pixel-rgb.conf
shows up again, despite the local
# this is for a nōn-release architecture
severity 1026002 important
# this is a bug in the imake buildsystem, not xlax which merely uses it
reassign 1026002 xutils-dev
retitle 1026002 xutils-dev: imake support for riscv64 vanished?
affects 1026002 src:xlax
thanks
sun min dixit:
>xlax failed to
severity 1017760 normal
retitle 1017760 linux: possible data corruption on µSD card, might be the
hardware though?
thanks
Dixi quod…
>I have somewhat reason to at least suspect the µSD card this was
>installed on. But there was never anything in syslog/dmesg about
>it, so the Linux kernel
Paul Eggert dixit:
> Although you sent your email to 36...@debbugs.gnu.org /
> 930247@bugs.debian.9org, your email is reporting a separate bug
Oh OK, I wasn’t aware, it sounded similar enough.
> I fixed it in the development version of GNU grep by installing the
> attached patch. This patch
Hi Paul,
> I looked at the results of the autopkgtest of your package. I noticed that it
> regularly fails. Also the failures on arm64 seem consistent now in testing
> (but
> it has a pass in unstable).
thanks for bringing this to my attention. This is a bug in the
autopkgtest script in that it
Mike Hommey dixit:
>> >Try removing that %eth0 from the ipv6 address.
>>
>> That would invalidate said address and is therefore impossible.
>
>Why would it? Is your setup so complex that the network stack can't find
>the right interface to send packets through?
It’s a link-local address. These
Mike Hommey dixit:
>Try removing that %eth0 from the ipv6 address.
That would invalidate said address and is therefore impossible.
It works in lynx, if knowing that helps.
bye,
//mirabilos
--
> emacs als auch vi zum Kotzen finde (joe rules) und pine für den einzig
> bedienbaren
Package: firefox-esr
Version: 102.5.0esr-1~deb11u1
Severity: serious
Justification: violates a Debian Etch release goal
X-Debbugs-Cc: t...@mirbsd.de
see attached screenshot
-- Package-specific info:
-- Addons package information
-- System Information:
Debian Release: 11.5
APT prefers
Also, where’s the NEWS entry apt-listchanges would have mailed me
to document this change in behaviour?
(Might as well place the documentation I requested in the previous
eMail there, so others will also find it.)
bye,
//mirabilos
--
22:20⎜ The crazy that persists in his craziness becomes a
Kurt Roeckx dixit:
>On Sat, Sep 24, 2022 at 10:34:19PM +0200, Thorsten Glaser wrote:
>> $ openssl s_client -CApath /etc/ssl/certs -connect www.mirbsd.org:443
>> -legacy_renegotiation -tls1
>
>TLS 1.0 is not supported by default because it's insecure. You need
>to change
Package: openssl
Version: 3.0.5-4
Severity: serious
Justification: does not work any more
X-Debbugs-Cc: t...@mirbsd.de
$ openssl s_client -CApath /etc/ssl/certs -connect www.mirbsd.org:443
-legacy_renegotiation -tls1
CONNECTED(0003)
depth=2 C = US, O = Internet Security Research Group, CN =
tags 1020058 + pending
thanks
Hi Lucas,
>Relevant part (hopefully):
>> /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=.
>> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
>> -D_FORTIFY_SOURCE=2 -std=c++0x -g -fPIC -fPIE -Wl,-z,relro -Wl,-z,now
>> -Wl,--as-needed -rdynamic
Thorsten Glaser dixit:
>I’ve recently been getting filesystem corruption on this system, which,
>incidentally, is a fresh-ish installation since I’ve been hit by the
I have somewhat reason to at least suspect the µSD card this was
installed on. But there was never anything in syslog/dmesg
On Sat, 3 Sep 2022, Helge Kreutzmann wrote:
> The upload of manpages-l10n (manpages-fr) was just accepted in
> unstable.
OK, thanks.
AIUI we now need another upload of src:sysvinit in which bin:bootlogd
gets a Replaces and Breaks on manpages-fr (<< 4.15.0-9~), correct?
I can do that this
Hi Helge,
[…]
> Yes, that would be the best option. A few days ago I informed all
> translation teams about the transfer of translations to sysvinit, so
> if the French team could integrate the translation of bootlogd there,
> that'll be great.
ok, great!
> For Debian, as stated above, I can
On Wed, 31 Aug 2022, Mark Hindley wrote:
> > there seems to be one manpage (in bootlogd) missing conflict handling:
> >
> > /usr/share/man/fr/man8/bootlogd.8.gz
>
> Thanks. I was under the impression that manpages-i10n had changed to
> systemd versions (which doesn't have bootlogd.8) but
outlook 1017537 some armel buildds are misconfigured and lack SWP emulation
thanks
Dixi quod…
># if __ARM_ARCH__ < 6
> swp r0, r1, [r2]
># else
And this, after some research, is it. This is needed for armel, which
is v5. Apparently, Linux has SWP emulation for v7/v8 hosts, but at
Dixi quod…
>In case this makes anyone immediately think of whatever it is:
Code looks right enough (with an explanation of why this only
fails on armel but not on armhf which is perfectly fine):
$ cat arm/__testandset.S
#include "arm-features.h"
FUNC_START __testandset
mov r2,
>but it ALSO fails in a bullseye chroot, so this is possibly not related
In case this makes anyone immediately think of whatever it is:
(gdb) r
Starting program: /home/tg/dietlibc-0.34~cvs20160606-el-11/debian/unittests/ttt
Program received signal SIGILL, Illegal instruction.
__testandset () at
outcome 1017537 fails on porterbox/bullseye as well, suspect 64-bit host to be
an issue
tags 1017537 + help
thanks
In contrast to armhf, which works fine on the porterbox (amdahl; abel,
which I normally use, is currently down) for me, this one also fails,
but it ALSO fails in a bullseye chroot,
tags 1017538 + unreproducible
thanks
This builds fine in a sid-armhf chroot on amdahl.
Markus Koschany dixit:
>The --add-opens error message was misleading and it turned out the underlying
>root cause for the FTBFS was a different one. Gradle currently fails to build
>because of a different jansi bug.
OK, so keep that one open and close this one?
>There is still some work to do
Markus Koschany dixit:
>The newly added --add-opens option is only valid for OpenJDK 17. I
>understand that we switch to it for Debian 12 but it currently breaks
>all packages that are built with OpenJDK 11. I am currently in the
Is this true? AFAIK --add-opens is for 11+ (probably even 9+). It
Package: src:linux
Version: 5.10.136-1
Severity: grave
Justification: causes non-serious data loss
X-Debbugs-Cc: t...@mirbsd.de
I’ve recently been getting filesystem corruption on this system, which,
incidentally, is a fresh-ish installation since I’ve been hit by the
“forgot LUKS password for
Arnd Bergmann dixit:
>The way the FPU type gets selected in gcc changed with recent versions,
>this was intentional and won't be reverted but it did break packages that
>used the old method.
Hmph.
>In most cases, it's sufficient to pass
>-march=armv7-a+fp instead of -march=armv7-a to pick the
Arnd Bergmann dixit:
>I tried cross-building it myself now and found the same issue with
>an older arm-linux-gnueabihf-gcc-11, which invokes the assembler as
>
>/usr/lib/gcc-cross/arm-linux-gnueabihf/11/../../../../arm-linux-gnueabihf/bin/as
>-v -march=armv7-a -mfloat-abi=hard -meabi=5 -o
Sebastian Ramacher dixit:
>This is already an issue with 0.34~cvs20160606-12.
It’s an incompatible toolchain change that broke this package.
I’m trying to find out why, but the ARM porters are not helpful.
bye,
//mirabilos
--
Support mksh as /bin/sh and RoQA dash NOW!
‣ src:bash (406 (433)
Arnd Bergmann dixit:
>-march=armv7-a+fp instead of -march=armv7-a to pick the right
“instead of”
We pass nothing there, and we need a solution (or two distinct
ones) for armel and armhf.
bye,
//mirabilos
--
[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
what
tags 1017538 + help
forwarded 1017538 https://lists.debian.org/debian-arm/2022/07/msg00041.html
thanks
Hi Sebastian,
instead of filing a bug with the information we already have…
>arm/__longjmp.S: Assembler messages:
>arm/__longjmp.S:9: Error: selected processor does not support `vldm
Octavio Alvarez dixit:
> On 31/07/22 14:57, Thorsten Glaser wrote:
>> debdiff (±version) attached. Would you prefer for me to NMU, do a
>> maintainer-agreed regular upload (as -2), or handle this yourself,
>> Octavio?
>
> I can handle it. By the way, did the fix work f
p 1.10 compatibility (Closes: #1016129)
+
+ -- Thorsten Glaser Sun, 31 Jul 2022 21:43:23 +0200
+
ipv6toolkit (2.0+ds.1-1) unstable; urgency=medium
* Refreshed patches using gbp pq export. Added:
diff -Nru
ipv6toolkit-2.0+ds.1/debian/patches/03b0fdd42cf36c0070472afbb9b81a9ca62e1109.patch
ipv6toolk
Cc libpcap maintainers; context is #1016129 on debbugs.
From diffing around between a buster and a bullseye system, I could
track this bug down:
libpcap0.8:
1.10.0-2 500
500 http://deb.debian.org/debian bullseye/main amd64 Packages
1.10.0-2~bpo10+1 100
100
Package: libapache2-mod-jk
Version: 1:1.2.48-1
Severity: critical
Justification: breaks unrelated software
X-Debbugs-Cc: t...@mirbsd.de
After upgrading from buster to bullseye, apache2 does not start any more
if libapache2-mod-jk was installed and active prior to the upgrading:
$ sudo cleanenv /
Package: ipv6toolkit
Version: 2.0+ds.1-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: t...@mirbsd.de
Control: forwarded -1 https://github.com/fgont/ipv6toolkit/issues/78
$ sudo tcp6 -i eth1 -d fec0::1 -y 500 -a 13 -P 600
Error while performing Neighbor Discovery for the
Simon McVittie dixit:
>If that's what you want, here are diffs (these are only the xfonts-base
>subset, the remarkably similar diffs for the other packages will follow
>when I get round to it).
Thanks. Looking good.
>Or if you want to try the web UI, closing the file list/search on the
>left
1 - 100 of 1004 matches
Mail list logo
