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
Dixi quod…
>Package: gcc-13
>Version: 13.2.0-1
This is a regression against gcc-12 (= 12.3.0-8); if I install that
and export CC='diet -Os gcc-12' it works.
>./mksh -c 'x=q; x=${ echo a; typeset e=2; return 3; echo x$e;}; echo .$x.'
In case this is relevant: that codepath uses setjmp/longjmp
Package: gcc-13
Version: 13.2.0-1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
I've got miscompiles of mksh with gcc-13 on x32 with dietlibc.
I could reproduce this in a chroot by doing…
export CC='diet -Os gcc'
export CFLAGS='-g -Wformat -Werror=format-security -Wall -Wextra'
export
Package: grub-common
Version: 2.06-3~deb11u5
Followup-For: Bug #911784
X-Debbugs-Cc: t...@mirbsd.de
I just wanted to report this bug, only to find out that I had
already reported it…
-BEGIN cutting here may damage your screen surface-
$ sudo cleanenv / update-grub
Generating grub
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
Package: lintian
Version: 2.116.3
This field was added with bookworm’s dpkg, so AIUI it can now
be used by packages in trixie/sid.
Package: dpkg
Version: 1.21.22
Followup-For: Bug #539617
X-Debbugs-Cc: t...@mirbsd.de
This issue is still present, cluttering logs of CI jobs by a lot.
-- Package-specific info:
This system uses merged-usr-via-aliased-dirs, going behind dpkg's
back, breaking its core assumptions. This can cause
retitle 1046406 polyphone: Fails to build source after build due to qmake
leaving files around
thanks
Lucas Nussbaum dixit:
>> dpkg-source: info: local changes detected, the modified files are:
>> polyphone-2.2.0.20210109+dfsg1/sources/qmake_qmake_qm_files.qrc
>> dpkg-source: error: aborting
Package: src:linux
Version: 5.10.179-3
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: t...@mirbsd.de
I have this in dmesg:
[0.00] microcode: microcode updated early to revision 0xa4, date =
2010-10-02
It would be very nice if this message also showed the revision *from*
which it was
Benjamin Drung dixit:
>Can you point to examples for it? Most of these cases should probably
>use TZ=UTC0 which work without having any timezone data files.
Except that tzif files contain more than DST info, such as the
name of the zone, but also leap second information (not in Debian
Package: tzdata
Version: 2023c-8
Severity: important
X-Debbugs-Cc: t...@mirbsd.de
Please bring back at the *very* least the top-level UTC symlink,
as TZ=UTC is used in *so* many places to get UTC it’s not funny.
A second candidate, although less used recently, is the top-level
GMT symlink.
Hi Guillem,
>I think there's another report about "suboptimal option parsing"
>behavior, which I'll check later whether it makes sense to merge.
oh.
>Otherwise you should use -Pprofile or --build-profiles=profile.
Ah, hmm. I gathered the latter, but the former was somewhat
unexpected,
Package: dpkg-dev
Version: 1.21.22
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
I tried to use build profiles for the first time today, and after
running into trouble with pbuilder I tried to run it manually and
found that even that doesn’t work:
$ dpkg-buildpackage -P nocheck
Package: pbuilder
Version: 0.231
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
I tried to use build profiles for the first time today, and I
found out that pbuilder’s --profiles option advertises to
support them, so I ran (via a wrapper and cowbuilder) it with
--hookdir .h --profiles nocheck
tags 1042855 + pending
thanks
Dixi quod…
>And libjpeg-dev does not appear in this list.
Ahem. That may be because there’s a real package with that name
in all(?) releases.
I’ll change this.
bye,
//mirabilos
--
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the
Vladimir Petko dixit:
>The attached patch updates control and rules to select libjpeg-dev as a
By the way, no need to patch rules for Ubuntu, just regenerate
debian/control is sufficient. I built the package for PPA with
that.
>I think I found the relevant quote:
>"To specify which of a set of
Vladimir Petko dixit:
>openjdk-8 382-ga-1 uses libjpeg-turbo62 as a dependency rather than
>libjpeg-dev that it used before.
No, for Ubuntu it uses libjpeg-turbo8-dev, so why…
>The attached patch updates control and rules to select libjpeg-dev as a
>dependency allowing Ubuntu sync.
… oh,
Holger Wansing dixit:
>>Could this information (valid unit sufficēs) be added to the dialogue
>>where the size is entered? Screen space should suffice.
>
>Yes, I already thought about if changing the template would make sense here.
Thanks!
Could we also get the size output in both formats? I
reopen 684128
retitle 684128 src:debian-installer: show ISO/IEC 60027-2 units (as well); show
valid suffixes
found 684128 226
thanks
Holger Wansing dixit:
>So I guess it works as it should.
>
>The (visual) output is still in MB / GB, apart from this a see no issue.
Hrm, the output being only
Cyril Brulebois dixit:
>https://www.debian.org/devel/debian-installer/News/2023/20230516.en.html
>documents a fix for #913431, which is a duplicate of this bug report.
Huh.
>> In bookworm d-i, entering 512 MiB seems to be using something
>> entirely different
>
>“Something entirely different”
found 684128 226
thanks
Hi,
why is this bug still unfixed?
In bookworm d-i, entering 512 MiB seems to be using something
entirely different, and 512 Mi gives an error “invalid size”.
This still makes d-i unsuitable for most partitioning.
bye,
//mirabilos
--
[...] if maybe ext3fs wasn't a
Michael Tokarev dixit:
>>
>> From the comment, it reserves 16 MiB after the main executable.
>>
>> In klibc/armhf, however, the main executable starts around
>> 0x0001 whereas the interpreter starts after that, around
>> 0x0038…
>
> Aren't it happens on all architectures, not just armhf?
Michael Tokarev dixit:
> commit 6fd5944980f4ccee728ce34bdaffc117db50b34d
From the comment, it reserves 16 MiB after the main executable.
In klibc/armhf, however, the main executable starts around
0x0001 whereas the interpreter starts after that, around
0x0038…
Perhaps the fix here
Ben Hutchings dixit:
>7.2. This introduced regressions for shared-library executables for
I did notice the following:
amd64:
/lib/klibc-YUkGbOClhnaZRUUd4cUed0X2XZI.so: file format elf64-x86-64
/lib/klibc-YUkGbOClhnaZRUUd4cUed0X2XZI.so
architecture: i386:x86-64, flags 0x0102:
EXEC_P,
Dixi quod…
>My guess here is that it’s, as usual, the fault of qemu-user,
Strong evidence for that: doesn’t look like it even executes
one bit of klibc code:
$ qemu-arm-static -d cpu ./fstype --help
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core
Hi Helge,
>Can you check if this patch fixes the problem:
>https://patchew.org/QEMU/mvmpm55qnno@suse.de/
>(linux-user: make sure brk(0) returns a page-aligned value, from Andreas
>Schwab)
I doubt it, klibc malloc uses mmap(2) normally.
(And given I tested it on a bullseye system, the
Dixi quod…
>My guess here is that it’s, as usual, the fault of qemu-user,
>which has multiple outstanding emulation bugs, some of which
>affecting klibc-built binaries especially, though this, since
>a statically linked mksh works, is probably an issue with how
>qemu-user handles .interp *shrug*
retitle 1040981 klibc-utils: segfault executing armhf binaries under qemu-user
thanks
venkata.p...@toshiba-tsip.com dixit:
>Follow below steps to reproduce this issue
>```
>$ sudo debootstrap --arch=arm bookworm arm-bookworm-rootfs/
>http://deb.debian.org/debian/
>$ sudo chroot arm-bookworm/
Helmut Grohne dixit:
>> > rng-tools-debian
>>
>> Also false positive:
>>
>> Replaces: intel-rng-tools, rng-tools
>> Breaks: rng-tools (>= 5migratf), rng-tools (<< 5migrate)
>> Conflicts: intel-rng-tools
>
>This is *not* a false positive, but a real issue. It replaces any
>rng-tools, but
Helmut Grohne dixit:
> openjdk-8 (U)
Should be convered by the Depends lines in the respective
binary packages, e.g:
Depends: openjdk-8-jre (>= ${source:Version}),
openjdk-8-jdk (>= ${binary:Version}),
${misc:Depends}
Replaces: openjdk-8-jdk (<< 8u20~b26-1~)
> rng-tools-debian
Also
On Wed, 5 Jul 2023, g...@libero.it wrote:
>But [o-s-s] should also invoke-rc.d try-restart, for perfection.
I don’t think so. I think the postinst of the services in question
restart the service, and that ought to “just work”, independent of
the init system in use, as long as an
On Wed, 5 Jul 2023, g...@libero.it wrote:
>The section
>
>> # Automatically added by dh_installinit/13.3.4
>> if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
>> "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
>> if [ -x "/etc/init.d/rsyslog" ]; then
>>
On Tue, 4 Jul 2023, g1 wrote:
>The following patch just mentions rsyslogd (newly orphaned script in bookworm),
for t in "$@"; do
But I don’t think the trigger on the binary is necessary,
the trigger on the systemd thing would already catch it.
bye,
//mirabilos
--
Infrastrukturexperte
Dixi quod…
>Indeed. Weird.
>
>Thanks for reporting, I’ll have two or three looks at it… fixing that
>is going to be… fun. Not.
OK so first analysis is showing the cause of the problem:
• the buildd chroots for sid/unstable do not identify themselves as
sid/unstable but instead as
On Sun, 2 Jul 2023, Fab Stz wrote:
>Updating from 8u372-ga-1 which was the previous version in unstable is not
>possible because openjdk-8-jre-headless_8e382~b04-1 depends on libjpeg8
WTF‽
*checks*
Indeed. Weird.
Thanks for reporting, I’ll have two or three looks at it… fixing that
is going
Simon McVittie dixit:
>On Wed, 28 Jun 2023 at 17:24:32 +0000, Thorsten Glaser wrote:
>> Simon McVittie dixit:
>> >On a typical Debian system, restarting `dbus-daemon --system` will
>> >cause system services to stop working
>>
>> WHICH ones?
>
>I don
Simon McVittie dixit:
>> I read through the bugreport and I can see why it should not
>> just be automatically restarted.
>
>This has been discussed at *extensive* length before, and I'm pretty
>sure nothing I say is going to change your opinion anyway, but OK,
I wrote “I can see why”, not “I
Hi,
I got this:
Setting up dbus (1.12.28-0+deb11u1) ...
A reboot is required to replace the running dbus-daemon.
Please reboot the system when convenient.
I read through the bugreport and I can see why it should not
just be automatically restarted.
But I could just restart dbus and then all
retitle 504044 rng-tools-debian: figure out how to best start this
forcemerge 504044 1039350
thanks
bl...@debian.org dixit:
>rng-tools-debian has been flagged by Lintian as shipping a sysv-init
>script without a corresponding systemd unit file.
It does. However, the situation of how to best
Jonathan Wiltshire dixit:
>Please go ahead.
Thanks, uploaded.
bye,
//mirabilos
--
15:41⎜ Somebody write a testsuite for helloworld :-)
tags 1038926 = bullseye-ignore
thanks
Dixi quod…
>Even if changing the configure argument fixes this, it’ll be hard to
>get this updated in stable post-release. I can try but ⓐ don’t hold
It looks like it ⓐ does fix this and ⓑ will get included in
one of the next point releases for bookworm,
cvs-1.12.13+real/debian/changelog cvs-1.12.13+real/debian/changelog
--- cvs-1.12.13+real/debian/changelog
+++ cvs-1.12.13+real/debian/changelog
@@ -1,3 +1,9 @@
+cvs (2:1.12.13+real-28+deb12u1) bookworm; urgency=high
+
+ * configure-time hardcode full path for ssh(1) (Closes: #1038926)
+
+ -- Thorsten
Patrice Duroux dixit:
>I think that everything is here:
>
>https://salsa.debian.org/ssh-team/openssh/-/blob/master/debian/changelog#L193
And:
>Using :extssh: is working but no more is :ext:.
Hmm.
Thanks, this does prove enough information for debugging.
This is… strange. cvs is compiled with
tags 1038926 + unreproducible
thanks
Hello Christian,
>Package: cvs
>Version: 2:1.12.13+real-28
>After the latest Debian update (the new stable release),
>CVS suddenly stopped to function completely for me.
if you’ll have a look at the versions, you’ll see that cvs has
the same version in
On Fri, 23 Jun 2023, Matthew Vernon wrote:
>> Nothing for orphan-sysvinit-scripts, which *really* surprises me,
>> as I’m certain we discussed this earlier.
>
> You may be remembering bullseye? After quite a lot of wrangling, we got a
> short
> note added to the release notes[0] and installation
On Thu, 22 Jun 2023, Mason Loring Bliss wrote:
>What part of the release notes are you referring to? It might be useful to
>reference that specifically, in addition to the pointer.
>
>Nothing relevant is obvious here for rsyslogd:
[-]
>It's not obvious from the release notes that rsyslog is
On Fri, 23 Jun 2023, David Griffith wrote:
> More verbosely: "Which package should have a dependency upon
> orphan-sysvinit-scripts to ensure that if sysvinit is used that rsyslog
> doesn't
> break?"
None because that’s not the scope of dependencies in Debian.
The choice to use a nōn-default
On Thu, 22 Jun 2023, David Griffith wrote:
> This was prompted when I found that rsyslog stopped working on Bullseye when
> upgraded to Bookworm. What sort of depenency would you suggest to implement
> the following?
“Read the release notes.”
Or use inetutils-syslogd ;-)
bye,
//mirabilos
--
On Thu, 22 Jun 2023, David Griffith wrote:
>of no use unless sysvinit is being used and its absence leads to random
>packages (some important) not working at all; orphan-sysvinit-scripts
>should be a prerequisite.
Huh? No. Currently, orphan-sysvinit-scripts doesn’t contain init scripts
for
Martin Pitt dixit:
>/etc/pbuilderrc has
[…]
>So it smells like pbuilder's auto-detection cannot parse the (not-so-)new style
I’d argue to turn this into a request to remove this autodetection
altogether. I’ve had nothing but trouble with it, in some cases
even overwriting/appending the
reassign 1038121 dpkg-dev
thanks
Raphael Hertzog dixit:
>So maybe it's dpkg-source that needs to be tweaked so that such patches
>have a field "Forwarded: not-needed" and an explanation that the patch
>is an auto-generated mess that can't be forwarded as is.
I guess so. I was thinking along
Package: tracker.debian.org
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
Unsure if this is the right pseudopackage; if not, please reassign.
The “new” Debian tracker shows:
debian/patches: 1 patch to forward upstream
The package however uses the single-debian-patch mechanism
to let a diff be
On Tue, 13 Jun 2023, Russ Allbery wrote:
>Ah, I think I understand what you're getting at. You're talking about
>using the init script of a daemon as this sort of wrapper script for
Not really. I was talking about normal programs, not dæmons.
I have the expectation that these, when invoked,
On Tue, 13 Jun 2023, Russ Allbery wrote:
>namely if you're running anything
>in a chroot that needs directories created in /tmp and /run, the chroot
>either needs to have a persistent /tmp and /run or you have to arrange for
>it to run at least some init scripts during boot.
I very much disagree
On Tue, 13 Jun 2023, Thomas Deutschmann wrote:
>> You did upgrade to Debian 10, then Debian 11, in the middle, right?
>
> Yes, of course.
OK.
> apt-get upgrade
> apt-get full-upgrade
I personally tend to use:
apt-get --purge dist-upgrade
This takes care of purging the configuration files
On Tue, 13 Jun 2023, Russ Allbery wrote:
>Thorsten Glaser writes:
>
>> Therefore I belive that Policy ought to *not* recommend any solution
>> that depends on starting dæmons or init scripts to create temporary
>> files/directories that are necessary for programs to
On Tue, 13 Jun 2023, Bill Allombert wrote:
>I agree, chroots are important to consider, and the system should not
>make assumptions how and why there are used.
Thanks!
>Conversely, sometimes I need to use chroots to test init scripts.
>start-stop-daemon should not refuse to run in a chroot if
On Sun, 28 May 2023, Thomas Deutschmann wrote:
> Note: The system was recently upgraded from Debian 8 (without systemd) to
> Debian 9 (where I switched to systemd) to Debian 12.
You did upgrade to Debian 10, then Debian 11, in the middle, right?
Otherwise your system is now completely
On Mon, 5 Jun 2023, Simon McVittie wrote:
>No init system at all, (C.), can only happen when starting with a
>minbase debootstrap or equivalent (because a default debootstrap
>includes the init metapackage due to its Priority: required). In
>this scenario it *usually* doesn't really matter
Package: poppler-utils
Version: 20.09.0-3.1+deb11u1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
Control: found -1 22.12.0-2+b1
The attached PDF contains subset fonts not recognised as subset:
$ pdffonts x.pdf
name type encoding emb sub
uni
Rene Engelhard dixit:
> You as DD should know that stable won't get any updates for this anymore. (And
> it will be oldstable in a short time anyway, even.)
So, who cares?
> So reporting this against stable does not make any sense at all.
It does: it records the issue, so others will know, and
Package: libreoffice-writer
Version: 1:7.0.4-4+deb11u6
Followup-For: Bug #965236
X-Debbugs-Cc: t...@mirbsd.de
This is still pertinent (tested by extracting the font with
mutool then loading the resulting .pfa in FontForge).
-- Package-specific info:
-- System Information:
Debian Release: 11.7
Package: libreoffice-writer
Version: 1:7.0.4-4+deb11u6
Severity: normal
Tags: upstream
X-Debbugs-Cc: t...@mirbsd.de
Using the attached font (yes, libre licences) in a document
then either exporting that to PDF or printing it to a file
results in output that cannot directly be printed.
To add
d the issues reappearing
+ * Cherry-pick more individual fixes from upstream
+- fix shift/rotate for nōn-power-of-two-sized bit quantities
+- correct 59c regression in recursive parser for command
+ substitution and fix the other place it was not reentrant
+ as well (by moving function-st
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 Wed, 26 Apr 2023, Emmanuel Bourg wrote:
> willing to cooperate to ensure the sysvinit integration remains possible
You could start by mergng the (tomcat9) sysvinit branch, then
separating the init script into orphan-init-scripts and removing
the |adduser alternative but keeping the remaining
On Tue, 18 Apr 2023, Per Lundberg wrote:
> A short update on this. This is a known regression in more recent versions of
> Java: https://bugs.openjdk.org/browse/JDK-8226919
>
> One of my colleagues (thanks, Sebastian!) managed to workaround this by
> patching the JDK 17 sources to make it use
On Tue, 28 Mar 2023, Jesse Smith wrote:
>pidof isn't going to chase down multiple layers of symbolic links. If
I consider that a (not release-critical) bug that should be
addressed by a Debian-local patch if upstream is hostile.
bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
On Thu, 23 Mar 2023, Jesse Smith wrote:
>pidof won't
>follow aliases or symbolic links with multiple hops and different names.
Then we’ve found a bug in pidof ;-)
>Or alternatively you could just link /usr/bin/vi to /usr/bin/vim.basic
>and then use "pidof $(which vi)".
No, that breaks several
Package: wiki.debian.org
Followup-For: Bug #980249
X-Debbugs-Cc: t...@mirbsd.de
Same for me and any submissions to
https://wiki.debian.org/DebianEvents/de/2023/DebianReunionHamburg#preview
(both Save Changes and Cancel) just time out. Just, for me, it’s more of
a 0-out-of-10-times thing.
This is
Package: apache2-doc
Version: 2.4.56-1~deb11u1
Followup-For: Bug #1018718
X-Debbugs-Cc: t...@mirbsd.de
Control: severity -1 serious
Justification: Policy §10.7.3
This package overwrites local changes on upgrade,
which is a release-critical bug as it’s a Policy
violation.
-- System
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
I already mentioned this as an aside in #986431 but here’s it
as a separate bugreport.
mksh is only a key package because shunit2 build-depends on it.
(Would be nice if the key package status is shown in tracker or so…
I
Package: libc-bin
Version: 2.36-8
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
Probably a codepage data bug, but I don’t know what package that
would be; please reassign as suitable.
$ printf '%s' '~' | iconv -f ISO-IR-10 -t UTF-16LE | hexdump -e '1/2 "%04X"
"\n"'
203E
This is supposed to
Package: coreutils
Version: 8.32-4+b1
Followup-For: Bug #139861
X-Debbugs-Cc: t...@mirbsd.de
Control: found 139861 9.1-1
Oh wow is this an old bug.
I thought, at first, it’s just character classes…
$ echo mäÄH | tr '[:upper:]' '[:lower:]'
mäÄh
… but apparently, yes, multibyte support is
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
close 705454
thanks
Hi Daniel,
>your problem doesn't affect arrays with superblock 1.x and superblock
>0.9 is really not much used anymore.. do you still have the issue?
as far as I can tell, all RAIDs I have are using metadata=1.2 by now.
>I don't think this has much traction to get ever
Antonio Terceiro dixit:
>Failing on some inputs is not a justification for a `serious` severity.
*Silently* failing, i.e. saying you succeed but not doing so,
however is, in my book. If it at least aborted giving the error
code, I’d accept that somewhat more easily.
>Thus, I am downgrading this
Package: firefox-esr
Version: 102.8.0esr-1~deb11u1
Severity: important
X-Debbugs-Cc: t...@mirbsd.de, t...@security.debian.org
I tagged this as a regression because it must have worked at some point.
Neither the package search installed by default from
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,
Hi,
ping? Please do merge the upstream fix.
Thanks,
//mirabilos
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⎜
Helge Deller dixit:
> Is it ok to keep this bug report open for - let's say -
> a year or so, and then apply it.
Sure, why not?
bye,
//mirabilos
--
15:41⎜ Somebody write a testsuite for helloworld :-)
Helge Deller dixit:
>> No, it needs to have been in the release.
>
> Please help me to understand the dependencies you mention.
> That patch is targetted for dietlibc in unstable.
> Is dietlibc/unstable shipped backwards into oldstable (in which
No, but Debian supports partial upgrades in both
Helge Deller dixit:
>> You know that new kernel features have to be in oldstable before
>> they can be depended on, right?
>
> The kernel patch was backported and is in upstream Linux kernel version 6.2,
> alternatively stable kernels from versions 6.1.6, 5.15.87, 5.10.163,
> 5.4.228, 4.19.270 or
Helge Deller dixit:
>This upstream patch has been downported to all stable kernel trees as
>well.
>Please apply for next upload.
You know that new kernel features have to be in oldstable before
they can be depended on, right?
bye,
//mirabilos
--
(gnutls can also be used, but if you are
Sebastiaan Couwenberg dixit:
>> Why did you close the bug with no explanation?
>
> Because I filed it, and no longer care for OpenLayers 3 and the shit that is
> the Node.js ecosystem.
OK, fair.
> Control: submitter -1 Thorsten Glaser
Also fair.
But other packages will w
affects 774565 src:dygraphs
thanks
Bas Couwenberg dixit:
>close 774565
>thanks
Why did you close the bug with no explanation? According to
https://packages.debian.org/search?keywords=jsdoc this is still
pertinent, so I’m assuming you typo’d the number or something
and accidentally closed the
Harald Dunkel dixit:
> Logfile is attached. If I kick out libpam-tmpdir there is no such
> problem. But this would be very painful. Do you think pbuilder could
> create the missing directory tree in /tmp instead?
This seems to be bogus. Packages cannot rely on specific per-system
configuration,
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
tags 1030285 = patch bookworm sid
thanks
Karel Zak dixit:
>Already reported: https://github.com/util-linux/util-linux/issues/1866
>
>Bugfix:
>http://github.com/util-linux/util-linux/commit/96ccdc00e1fcf1684f9734a189baf90e00ff0c9a
Thanks
Dear Debian maintainers, please apply and upload ☺
201 - 300 of 4551 matches
Mail list logo
