Dixi quod:
>Justification: Policy 10.4
Policy has an extra requirement on top of POSIX that -a is supported,
but /etc/profile can be read by shells not suitable for /bin/sh in
Debian, so a fix would still be appreciated, but I don’t insist on rc
severity.
bye,
//mirabilos
--
“It is inappropriat
Package: bash-completion
Version: 1:2.11-6
Severity: serious
Justification: Policy 10.4
Tags: bookworm trixie sid
Control: found -1 1:2.16.0-7
X-Debbugs-Cc: t...@mirbsd.de
/etc/profile.d/bash_completion.sh has:
if [ "x${BASH_VERSION-}" != x -a "x${PS1-}" != x -a
"x${BASH_COMPLETION_VERSINFO-}" =
On Fri, 14 Feb 2025, Guillem Jover wrote:
>> >This bug does not count as RC just because Debian upload bureaucracy
>> >hasn't been performed yet.
>>
>> If packagers cannot rely on Policy to give correct information, what
>> *can* they rely on?
>
>This is not how Debian Policy has ever worked. By t
On Fri, 14 Feb 2025, Guillem Jover wrote:
>As was discovered in bug #1095746, this package misbuilds when calling
>for example «fakeroot debian/rules binary-arch» w/o first calling
>«debian/rules build-arch», which is a policy violation:
Yes. I noticed yesterday (or so… memory is a bit fuzzy) and
On Fri, 14 Feb 2025, Sean Whitton wrote:
>Policy has to go through binary-NEW in order to be released. So there
Technicalities.
>isn't a quick fix here.
Not looking for one. dpkg should revert this until then.
>This bug does not count as RC just because Debian upload bureaucracy
>hasn't been
Dixi quod…
>One thing I do can see is that the older build called
>debian/rules build-arch before debian/rules binary-arch,
>the newer calls only the latter. So, perhaps, some value
>that got reobtained is now cached? (But why only the one?)
>
>Investigation continues.
It’s an incompatible change
Source: dpkg
Version: 1.22.13
Severity: serious
Justification: Policy §5.6.31
X-Debbugs-Cc: t...@mirbsd.de
dpkg 1.22.13 implemented a backwards-incompatible change,
violating Policy (which states the default value is most
certainly *not* “no”) and breaking builds of packages.
dpkg (1.22.13) unsta
>These seem to be the only ones affected, from the apt-get install
>output, though I’ll also look at the packages. I’ll investigate.
Best I can say at this point is that the wildcard in…
all_jre_tools = $(filter-out javaws, $(notdir $(wildcard
$(builddir)/$(jreimg)/bin/*)))
jre_tools = $
reassign 1095746 openjdk-8-jre-headless
thanks
On Tue, 11 Feb 2025, Matthias Mueller wrote:
>The Link from /etc/alternatives/java ->
>/usr/lib/jvm/java-8-openjdk-amd64/bin/java is missing in 8u442-ga-1.
Ouch, indeed. This is… surprising, there’s not been a deliberate
change even near that area.
Source: vim
Version: 2:9.0.1378-2+deb12u1
Severity: serious
Justification: FTBFS
Tags: security bookworm
James McCoy indicated that…
>Indeed, upstream ended up disabling the test that 9.0.1532 introduced
>because it took too long:
>
>https://github.com/vim/vim/compare/v9.0.1533...v9.0.1535
What
severity 1085065 serious
found 1085065 2:9.0.1378-2+deb12u1
thanks
This is now affecting stable-security builds.
On Thu, 16 Jan 2025, Luca Boccassi wrote:
>This is an anti-pattern, and best avoided. What's the problem if the
>script runs twice? If it just detects things it should be just fine,
Extra effort, though. And, in general, TOCTOU, but probably not
applicable here.
bye,
//mirabilos
--
den AGP ste
On Thu, 16 Jan 2025, Sven Geuer wrote:
>> If not, I’d lean towards one (which?) of the errorlevel-using ones,
>> because otherwise we’d have to run the detection code twice.
>
>Not sure what you mean by 'one of the errorlevel-using ones'. Please
>explain your idea in more details.
SuccessExitStat
On Wed, 15 Jan 2025, Sven Geuer wrote:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504044#162
>Applying ExecCondition to me seems the most reasonable solution to this
>bug.
Can the script behind ExecCondition pass variables to the script
behind ExecStart or, even better, the unit itself
On Tue, 14 Jan 2025, Luca Boccassi wrote:
>It looks like this is doing some checks, and intends to skip. But just
>exiting means the service is recorded as failed, and this will likely
>trip other tests, hence the severity to stop migrating to testing for
>now.
Ah, ouch. Agreed.
>There are sever
On Tue, 24 Sep 2024, Ben Hutchings wrote:
>> Two, say people are expected to create the directories first.
>> But in that case, copy_exec also must not create any missing
>> directories any more *at all*,
>
>No, it was documented to do that for the case where no target argument
>was given, and cha
On Tue, 24 Sep 2024, Ben Hutchings wrote:
>I suppose I can make this work again for bookworm, but I won't do so
>for unstable.
Then, perhaps issue a visible warning so that people can change
their scripts?
>This was not an intended feature. When specifiing a diectory as the
>target you are supp
Package: initramfs-tools-core
Version: 0.142+deb12u1
Severity: serious
Justification: hidden breakage for users, ought to be fixed in stable-pu
X-Debbugs-Cc: t...@mirbsd.de
In bullseye, this would work:
copy_exec /usr/lib/klibc/bin/rnd_shuf /usr/libexec/
copy_exec /usr/sbin/rdate /usr/libexec/
I
reassign 1006451 ftp.debian.org
retitle 1006451 RM: minify-maven-plugin -- RoM; only remaining user gone
severity 1006451 normal
thanks
guacamole-client was RoQA'd in #926276
so this can be garbage-collected
Dixi quod…
>stracing shows that, despite the -m option being passed by
>the pmake wrapper, it still accesses /usr/share/mk/.
Hm, but I just tested with pmake_1.111-3.2_armel.deb from
the archive, and it also failed.
Is it possible that it doesn’t work right under qemu-user?
(Which would also be
Package: bmake
Version: 20200710-14+deb11u1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: t...@mirbsd.de
Building a package that Build-Depends on pmake and uses it
in its debian/rules build targets in a clean bullseye chroot
completely fails with:
bmake: no system rules (s
Paul Gevers dixit:
> The Release Team considers packages that ship files in /usr-merged aliased
> locations RC buggy.
>
> We have put our trust in Helmut to come up with the right solutions during the
> preparation for trixie
Hmpf. He’s doing the dirty work for Md and bluca now.
>, so I'm asking
Helmut Grohne dixit:
>> Maybe the protective diversions also protect against this problem as well
>> as the problem of moved files? I unfortunately failed to spot where the
>> protective diversions were added in dh_movetouser (if that even is the
>> right place to be looking), so I'm fairly sure
(Another data point is that there’s versions of mksh with
version numbers larger than what’s in sid around in my own
repo, for those wanting to follow CVS snapshots more closely,
backported to all versions up to sarge, so bookworm users
can very well have mksh packages with a version number that
is
Helmut Grohne dixit:
>that the way people tend to use mksh is by adding a local diversion for
Unfortunately not.
The way we have to do it since squeeze, when dash unilaterally broke
cross-package coordination, is:
dpkg-reconfigure dash ⇒ remove its owning of /bin/sh
(so it reverts to bash)
ln
Russ Allbery dixit:
>Thorsten Glaser writes:
>
>> You got your merged /usr already, and to force packages to move their
>> files WILL break users’ systems. In particular, mksh as /bin/sh is a
>> supported configuration.
>
>Could you explain how this would break a us
Helmut Grohne dixit:
>I expect this policy change to come into effect before trixie is
>released and the current mksh and pax will be violating said policy.
I’m veto’ing this.
>> 1. the /bin symlink
>>
>> The implicit Pre-Depends on the Essential set being unpacked,
>> where base-files contains
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Helmut Grohne dixit:
>I would like to take the opportunity make you aware of a Debian policy
>change #1074014 about merged-/usr. I mentioned your approach in mksh and
>pax and the consensus among discussion participants was that policy
>should not a
Halmut,
we have exchanged numerous eMails, and you’ve not disagreed with
the last points you raised. I did get a disagreement from guillem
about omitting the top-level directory (which was only a workaround
for the “dpkg-deb -x mksh.deb / will break a /usr-merged system”
thing you said.
There are
tags 1069365 + confirmed pending
thanks
Lucas Nussbaum dixit:
>> E: Build killed with signal TERM after 150 minutes of inactivity
Indeed, it busy-spins in diet(1):
include/sys/cdefs.h:#define __likely(foo) __expect((foo),1)
29 size_t strlen(const char *s)
30 {
42 register si
On Mon, 17 Jun 2024, Aron Xu wrote:
>Control: tags -1 - pending
Oops, right.
>It looks that this libxml2 update is causing more troubles than
>expected, I would like to ask for your opinion whether it's better to
>revert to an older version for the moment?
Might be useful while you ask upstream
On Sun, 16 Jun 2024, Thorsten Glaser wrote:
>Better prevent this from landing in trixie until the package
>gets its soname bumped.
In fact, unless someone has the tuits to diff every single
API and ABI surface of the package between trixie (ideally
bookworm) and sid versions, it would be b
clone 1073313 -1
reassign -1 libxml2
found -1 2.12.7+dfsg-3
retitle -1 libxml2: just another API+ABI break; please bump soname
severity -1 serious
tags -1 sid
thanks
On Sun, 16 Jun 2024, Thorsten Glaser wrote:
>This is not the first time in *very* recent history that libxml2
>has an ABI
On Sun, 16 Jun 2024, Yavor Doganov wrote:
>IMVHO removing a public struct member constitutes an API break.
Definitely. I just took a peek at this.
>It is also an ABI break, because if a program or a library accesses
>such member and is compiled against an old libxml2 version that is
>supposed to
Bastian Germann dixit:
>> Do you have a link?
>
> No. It is not a public address.
Ah, yes, that is unfortunate. I used to be subscribed and have no
idea why I’m not, but I re-subscribed (though have not yet seen any
traffic in the last couple of days).
>> What did upstream say?
>
> No upstream r
Hi Bastian,
>I have already informed upstream about it.
did you do that on a mailing list? Do you have a link?
What did upstream say?
Still unconvinced,
//mirabilos
--
If Harry Potter gets a splitting headache in his scar
when he’s near Tom Riddle (aka Voldemort),
does Tom get pain in the arse
tags 1069678 + pending
thanks
I’m working on it. Upload should come RSN.
AIUI the security team can feel free to ignore openjdk-8
as it’s in sid for bootstrapping and preparing ELTS upgrades
and downstreams purposes, and not “as is” security-supported
in Debian, so if it helps lowering the worklo
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 binNMUing
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, but
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 liba
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
-We
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 the
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 (>= 0.7.6
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
-I..
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 b
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 d
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 | gsskrb5_register_acceptor_identity
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
checkin
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
arg
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 o
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:
https://buildd.d
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 t
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 depe
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: SSH
>-%(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 me
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
mips64el-lin
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 automatically
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 needs
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 sp
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 happ
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, ju
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 me
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 a
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'
>(sid_mips64el-d
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
"/usr/
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 feel
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 mipsel
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 it
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, &lim) == 0) {
> char stackSize[32];
32 is m
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 s
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
>> Node
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 re
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⎜ Somebody
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 f
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 o
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 manpa
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 use
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 ?
(sid-amd64)root@tglase:/etc
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 combinatio
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 hi
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 of
1 - 100 of 1019 matches
Mail list logo
