Package: cups-browsed
Version: 1.28.5-1
Severity: important
X-Debbugs-Cc: t...@mirbsd.de
Nov 23 20:34:11 tglase vmunix: [12181565.392373] cups-browsed[19303]: segfault
at 0 ip f7b5637c sp ffab2890 error 6 in
libcupsfilters.so.1.0.0[f7b3a000+24000]
Nov 23 20:34:11 tglase vmunix: [
Hi vorlon,
> attached patch.
I’d have used PREPEND, not APPEND, for -O2. You already STRIP -O3,
so if dpkg-buildflags contains something like -Os or -Og it would
still be honoured with PREPEND.
But it’s almost certainly not worth changing this again; just for
the future, maybe?
bye,
//mirabilos
Package: openjdk-11-jdk-headless
Version: 11.0.9.1+1-1
Followup-For: Bug #969038
X-Debbugs-Cc: t...@mirbsd.de
Yes, please *do* take care of this, ideally also in buster,
as this seriously degrades the usability of the software.
For example, JDK 8 had javah but JDK 11 doesn’t, and it’s
supposed to
Hi Juhani,
> They've indeed removed src:musescore from unstable but it remains in
> experimental. Do you agree that this bug can be repurposed to request
> musescore be removed from experimental?
yes please.
Thanks,
//mirabilos
Package: firmware-iwlwifi
Version: 20200918-1
Followup-For: Bug #934781
X-Debbugs-Cc: t...@mirbsd.de
It still happens.
[583944.226966] iwl4965 :03:00.0: Microcode SW error detected. Restarting
0x200.
[583944.226974] iwl4965 :03:00.0: Loaded firmware version: 228.61.2.24
[583944.2269
On Thu, 19 Nov 2020, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the libncurses6 package:
>
> #971672: ncurses: please add suitable Breaks for cowdancer (<< 0.89~)
Thanks, this does make apt order the package upgrades
On Thu, 19 Nov 2020, Felix Lechner wrote:
> Lintian points out only line 992, but not line 86 (see below). Does
> that mean Lintian was right but used a misleading tag name? Thanks!
Lintian pointed out the ‘'’ part, but it’s the ‘\\’ part which
this subthread was about for.
Background: I was loo
On Wed, 18 Nov 2020, Matthias Klose wrote:
> On 11/18/20 8:03 PM, Adrian Bunk wrote:
> > New OpenJDK versions tend to cause both buildtime and runtime breakages
> > in reverse dependencies, some of them hard to resolve and requiring
> > updates to new upstream versions which in turn require new dep
Andrea Bolognani dixit:
>I've taken a stab at addressing this:
Thanks!
> https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/78
>
>Thorsten, I would appreciate if you could take a look, especially
>since you seem to have some familiarity with this sort of situation
>already.
I’ve no
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
Dear ftpmasters,
I had to change the package to little-endian only because it
would not work right on big-endian platforms due to hardcoded
assumptions too large to quickly fix. Upstream is informed.
In the meantime, please re
>-- Forwarded message --
>Message-ID: <87k0unhopc@c6.deuxchevaux.org>
[…]
>If that's not possible, you probably need to add a dependency on
>"systemd | opensysusers" and check for "sysusers" or "opensysusers"
>instead of systemd-sysusers, too. opensysusers is an alternative
>i
Package: bc
Version: 1.07.1-2+b2
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
For some reason, bc suddenly displays some lines sometimes in inverse
colour and behaves weird in general.
This happens in xterm directly, but not in GNU screen running in
xterm, so it’s probably $TERM-dependent, and t
On Fri, 13 Nov 2020, Mark Hindley wrote:
> Thanks. This is a known issue and already reported with respect to
> wireshark-common.
Indeed. As a workaround one can keep the old version installed for
now.
> > since rsyslog Version 8.2010.0-1 has a versioned dependency on libsystemd0
> > (>= 246), I
Package: firmware-misc-nonfree
Version: 20200918-1
Severity: minor
X-Debbugs-Cc: t...@mirbsd.de
I’m getting this during an upgrade in sid:
[…]
Processing triggers for initramfs-tools (0.139) ...
update-initramfs: Generating /boot/initrd.img-5.9.0-2-amd64
W: Possible missing firmware /lib/firmware
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
Dear ftpmasters,
please g/c src:musescore from unstable; it’s been renamed
to src:musescore3 fully taking over every binary package
formerly built from there.
Thanks in advance,
//mirabilos
Hi Neil,
>First, regarding the rng-tools version looks rather out of date. From what
yes. As I explicitly wrote in the first message, this is about the
*heavily* patched “Debian classic” version of rng-tools 2.x; the
package with 5.x is called rng-tools5 currently, and updating it
is tracked els
Johannes Berg dixit:
>There's virtio-rng in recent kernels, so you could just boot a VM and
>connect the host's /dev/random to that.
Right, I’d even tested that, but the other changes are still
rather intrusive, and I think testing those with real hardware
would be better.
bye,
//mirabilos
--
1
Hi all,
Henrique de Moraes Holschuh dixit:
>On Thu, Oct 1, 2020, at 21:05, Michael Stone wrote:
>> On Thu, Oct 01, 2020 at 11:20:44PM +, Thorsten Glaser wrote:
>> >Michael Stone dixit:
>> >
>> >> you can fix it right now!
>> >
>> >So
Henrique de Moraes Holschuh dixit:
>On Tue, Nov 10, 2020, at 16:05, Thorsten Glaser wrote:
>> So we additionally have the case where the character device
>> exists but is not usable… oh my.
>
>This was common enough that rngd should know about it and bail out with
>an
close 466946
# housekeeping while here anyway; cf. #911043
reassign 776597 rng-tools-debian
thanks
On Tue, 10 Nov 2020, Trek wrote:
> as far as I know, if the daemon does not have files opened for writing,
> the system should be able to unmount the filesystem correctly
lrwx-- 1 root root 64
Dixi quod…
>among these I (co‑)manage. With “modprobe virtio-rng”, I
>was able to get it on a VM though. Perhaps relevant info:
>
>$ ls -ld /dev/hw*; grep . /sys/devices/virtual/misc/hw_random/*
>crw--- 1 root root 10, 183 Nov 10 17:04 /dev/hwrng
>/sys/devices/virtual/misc/hw_random/dev:10:183
All,
I think due to the complexity of this I’ll postpone
this for after bullseye. Maybe I can get my hands on
systems which Linux /dev/hwrng supports in the mean‐
time, too, and perhaps test both systemd and sysvinit
on those then (help welcome), but for now I’ll leave
this at the refactoring of t
Hi Felipe,
>I'll comment only on the init stuff, as I have no idea what rng-tools does.
that’s fair. Thanks anyway.
>It is difficult to comment on this without more details. Maybe it would be
>possible to configure socket activation here? If not, the best option is
AIUI socket activation is use
Hi *,
I’m copying this eMail to those who requested various starting
methods for rngd and those who can probably help me with it.
Background: I took over the heavily patched 2.x series of
rng-tools as “rng-tools-debian”, which is currently started
from a sysvinit script only.
Now I have got requ
tags 792406 + moreinfo
# while here anyway
tags 969568 + moreinfo
thanks
Hi gebi,
isn’t RDRAND/RDSEED supported/used by Linux itself nowadays?
If so, can I close this bug? (Otherwise I would have to move
it to rng-tools-debian for further consideration.)
Thanks,
//mirabilos
--
(gnutls can also
On Sat, 7 Nov 2020, Mark Hindley wrote:
> On Sat, Nov 07, 2020 at 06:05:18PM +0100, Trek wrote:
> > have pm-utils installed you could try to run pm-hibernate to see if the
Again, I don’t have hibernation set up at all.
This must not be triggered and if auto-triggered must not do anything.
> Yes
Package: openjdk-11-jre-headless
Version: 11.0.9.1+1-1
Followup-For: Bug #972245
X-Debbugs-Cc: t...@mirbsd.de
Just updating the version for this is still present.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'oldsta
On Fri, 6 Nov 2020, Mark Hindley wrote:
> Can you provide the content of /proc/swaps please.
Sure:
tglase@tglase-nb:~ $ cat /proc/swaps
FilenameTypeSizeUsed
Priority
/dev/sda2 partition 320614
Package: cmake
Version: 3.18.4-1
Severity: wishlist
Tags: upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain, username
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
The musescore3 source package uses the following construct…
COMMAND "${CMAKE_COMMAND}" -E
Package: libvirt-daemon-system
Version: 6.8.0-1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
I suspect this file should not have been a conffile, i.e. not
shipped in /etc (but somewhere under /usr and copied to /etc
during postinst).
NOTE: Migrating to _that_ setup is dangerous as well, see #971
Felix Lechner dixit:
>Feel free to try it. The test case is attached.
tglase@tglase-nb:~ $ perl /tmp/x
Wide character in say at /tmp/x line 13.
UTF-8: ✓ (☃)
So lintian maybe behaves different from that testcase?
bye,
//mirabilos
--
15:41⎜ Somebody write a testsuite for helloworld :-)
Felix Lechner dixit:
>The issues have been open since 2007 and 2011. We do not currently
>have a plan for mitigation.
AIUI this only affects buster anyway and not sid?
So it will just go away if we wait long enough.
bye,
//mirabilos
--
(gnutls can also be used, but if you are compiling lynx fo
On Tue, 27 Oct 2020, Andreas Tille wrote:
> > > Caused by: java.io.IOException: Unable to delete file:
> > > targets/unit-test-wd/ch.systemsx.cisd.base.unix.UnixTests/someDanglingLink
> > > at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:1425)
> > > at org.apache.commons.io.File
Felix Lechner dixit:
>"wide-character" Perl warning?
No, the first few lines of lintian’s output are literally:
N: Using profile debian/main.
N: Starting on group musescore2/2.3.2+dfsg3-10
N: Finished processing group musescore2/2.3.2+dfsg3-10
E: musescore2 source: malformed-override Unknown tag
Felix Lechner dixit:
>We are unsure about the last bug, especially because you did not
>report it in unstable (and it would have been hard to miss). The Perl
Ehm, but I’m running unstable and reported it against the version
in unstable. (I was actually seeing this in a cowbuilder buildd
chroot.)
Package: lintian
Version: 2.99.0
I’ve been recompiling musescore2_2.3.2+dfsg3-10.dsc (currently
in sid) on latest sid, to test it for Qt 5.14 compatibility and
latest lintian overrides (modulo #969398, still unfixed).
I’m getting this:
N: Using profile debian/main.
N: Starting on group musescore
>First reported by CrystalMath <~coderain@reactos/developer/theflash>
Here’s the patch they came up with and tested locally.--- ksh-93u+20120801.orig/src/cmd/ksh93/sh/jobs.c
+++ ksh-93u+20120801/src/cmd/ksh93/sh/jobs.c
@@ -,7 +,7 @@ static struct process *job_bystring(regi
int job_kill(
Package: ksh
Version: 2020.0.0+really93u+20120801-8
Severity: normal
File: /bin/ksh93
X-Debbugs-Cc: t...@mirbsd.de
First reported by CrystalMath <~coderain@reactos/developer/theflash>
in IRC:
ksh93 -c 'kill %-4' segfaults (confirmed by me on sid)
03:18⎜«CrystalMath:#ksh» hi all, i may have found
Bernhard Übelacker dixit:
>in options.c:792 the modulus of the rotating degrees is checked to
>be 0. But this is not triggered if degrees is already zero.
>Attached patch should avoid this issue and make xloadimage ignore
>the rotate request.
I’d probably do that for multiples of 360.
Nik, shoul
Package: youtube-dl
Version: 2020.09.14-1
Severity: important
Tags: upstream
X-Debbugs-Cc: t...@mirbsd.de
This is playable from the website.
tglase@tglase-nb:/tmp $ youtube-dl -F
https://www.youtube.com/watch?v=umTVO7IUUJ0
[youtube] umTVO7IUUJ0: Downloading webpage
[
Control: tags -1 - moreinfo
>I've had a closer look now. The cited commit does correctly remove the
>conffile:
>+rm_conffile /etc/apt/apt.conf.d/01autoremove 215~ postgresql-common
Oh, interesting. Yes, I see that in
/var/lib/dpkg/info/postgresql-common.postinst
but while /var/lib/dpkg/info/post
Christoph Berg dixit:
>Re: Thorsten Glaser
>> I’ve not looked at createcluster.conf but it will, most likely, also
>> be caused by a similar packaging fault.
>
>Yes, but renaming is not an option there.
Right.
>I'll look into fixing this properly.
Thanks!
>Tha
Dixi quod…
>Looking at these files, especially the first, I’m honestly not sure
>whether I want to delete them. If they are not in the binary package
>any more but used to be this is probably a bug?
Looking at past changelogs, I found this:
https://salsa.debian.org/postgresql/postgresql-common/-
reassign 971880 dash
affects 971880 debianutils
# focal on WSL 1
found 971880 0.5.10.2-6
# clean sid chroot
found 971880 0.5.10.2-7
retitle 971880 dash: fails to treat export as declaration utility, making
savelog fail with spaces in $PATH
thanks
Dixi quod…
>named 20.04 "focal" running under WSL
Package: debianutils
Version: 4.9.1
Severity: normal
Admittedly, this bugreport comes from Debian derivate which cannot be
named 20.04 "focal" running under WSL 1, but it will certainly apply
to plain Debian as well.
tl;dr: I was trying to run popcon once:
root@DESKTOP-PN6OO9E:~ # /etc/cron.dail
reopen 971672
retitle 971672 ncurses: please add suitable Breaks for cowdancer (<< 0.89~)
severity 971672 normal
thanks
On Thu, 8 Oct 2020, Debian FTP Masters wrote:
> cowdancer (0.89) unstable; urgency=medium
>* Check isatty(3) rather than rely on ncurses/tinfo (Closes: #970555)
Would y
Hi *,
I’ve prepared a patch (MR!6) that fixes this issue by switching to
isatty(2) (unless $TERM is dumb, vt100 or vt220) and tested this.
I’d *really* prefer to upload this as 0.89 to sid, so that ncurses
then can place Breaks in the libraries, hoping that that will be
enough to magically fix th
Package: postgresql-common
Version: 218
Severity: minor
User: debian...@lists.debian.org
Usertags: adequate obsolete-conffile
X-Debbugs-Cc: t...@mirbsd.de
[…]
Preparing to unpack .../30-postgresql-common_218_all.deb ...
Leaving 'diversion of /usr/bin/pg_config to /usr/bin/pg_config.libpq-dev by
p
On Sun, 4 Oct 2020, Sven Joachim wrote:
> Use the --no-cowdancer-update as suggested at the end of your log file.
Hrrm, but that’ll be fun if the upgrade fails.
> IMO this is not a bug in ncurses, libncurses6 and libtinfo6 are unpacked
> in the same dpkg run and the former is not guaranteed to w
On Sun, 4 Oct 2020, Thorsten Glaser wrote:
> I personally am in favour of the latter. We don’t need colours in
It’s even worse: ncurses are only used to initialise terminfo
and determine whether the terminal supports colours, but the
actual colour calls are hardcoded and don’t use setaf and
found 971674 0.81
notfound 971674 0.80
thanks
> Definitively an issue as log.c (part of the DLL) uses curses
> making the whole thing fragile.
Jessica, you added this in e4b477ef7e77316c5171d15ac119b5766ee2ed73.
I think we either need to create a variant of the DLL without the
ncurses dependency
clone 971672 -1
reassign -1 cowdancer
found -1 0.88
retitle -1 cowdancer: uses ncurses in the LD_PRELOADed DLL, making upgrades
unreliable
thanks
On Sun, 4 Oct 2020, Thorsten Glaser wrote:
> > This seems to actually be a cowbuilder problem thus…
Definitively an issue as log.c (part of t
On Sun, 4 Oct 2020, Thorsten Glaser wrote:
> I cannot update my cowbuilder sid chroot, with the following errors:
>
> […]
> Preparing to unpack .../libncursesw6_6.2+20200918-1_i386.deb ...
> Unpacking libncursesw6:i386 (6.2+20200918-1) over (6.2-1) ...
> Preparing to unpack .
> This seems to actually be a cowbuilder problem thus…
It *also* seems to be a bug in ncurses packages (ordering problem):
(pbuild4531-sid/i386)root@tglase:/# apt-get install libtinfo6
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additiona
Package: libncurses6
Version: 6.2+20200918-1
Severity: serious
Justification: does not install/upgrade
X-Debbugs-Cc: t.gla...@tarent.de
I cannot update my cowbuilder sid chroot, with the following errors:
[…]
Preparing to unpack .../libncursesw6_6.2+20200918-1_i386.deb ...
Unpacking libncursesw6:
Mark Hindley dixit:
>Forwarded upstream.
Thanks.
>> Ib ve also just looked at the elogind.conf file I was told to change in
>> one of the two other bugreports I mentioned above. There is some config
>> regarding hibernation, so I guess, now that I know about the problem,
>> I could just turn of
Package: elogind
Version: 243.7-1+debian1
Severity: critical
Justification: causes serious data loss
X-Debbugs-Cc: t...@mirbsd.de
Yay, I found another behavioural difference between just running Debian
(classic, that is, sysvinit withOUT elogind) and Debian with elogind (to
satisfy certain package
Hi Adrian,
could you work around the problem by starting an i386 VM on
your amd64 system, and then running the qemu-user buildds on
that? The return values from the syscalls will natively be
correct 32 bit there…
In the meantime, someone found that this bug also hits without
any qemu involvement:
Package: debianutils
Version: 4.11.2
Severity: wishlist
X-Debbugs-Cc: t...@mirbsd.de
The recent change changes the application to send this
information to stdout. This however is not what normal
Unix users expect *and* probably will break users’ scripts.
The correct fix for #961872 is to do this
Hi,
>Yes, I have made it clear in the past that I am happy with any
>transition plan at all, so I was not under the impression that I had to
>write anything...
ah okay, and I missed *that*. Great that we talked about it,
thanks Michael for pointing us out.
>So, feel free to even become the new u
retitle 919893 rng-tools-debian: please take over rng-tools with a proper
transition
thanks
Michael Stone dixit:
> On Thu, Oct 01, 2020 at 11:20:44PM +0000, Thorsten Glaser wrote:
>> Michael Stone dixit:
>>
>>> you can fix it right now!
>>
>> So, what
Michael Stone dixit:
> you can fix it right now!
So, what do you mean? Take over the rng-tools package?
If so, it has a maintainer, you know. hmh has been quiet so far.
> you keep talking about launchpad, but this is a conversation in debian
> channels
> about a debian package. what ubuntu did
Michael Stone dixit:
> So your position is that rng-tools 2-unofficial-mt.14-1+b2 and
> rng-tools-debian
> 2-unofficial-mt.14-3 both in buster are completely different codebases?
No, no, no, of course not. I’m talking about sid (and therefore testing).
Even before the release of buster, rng-too
Michael Stone dixit:
> No, there were also user confusion, duplication of functionality, and
> increased difficulty in future migration.
So, the name, and that we have two packages.
Oh well, it has happened now.
> So you could have added whatever you needed to rng-tools and skipped the
> unneces
Michael Stone dixit:
> So the package that shouldn't have existed made it into buster, there's a
> ridiculous situation with 3 packages providing essentially the same
> functionality with minor differences and no practical way for a user to figure
> out which to install, and no movement on fixing
Package: automake
Version: 1:1.16.2-4
Followup-For: Bug #964436
X-Debbugs-Cc: t...@mirbsd.de
This bug is still pertinent.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.8.0-1-amd64 (SMP w/4 C
her case
>of prodding maintainers (and, perhaps, looking whether it can’t be
>fixed in qemu as well).
I prodded maintainers, see below, but the latter looks like it’ll be
needed.
-- Forwarded message --
From: Thorsten Glaser
Message-ID:
To: Aurelien Jarno
Cc: 916...@bugs.deb
Hi,
>The patch is basically replacing the getdents64 syscall by the getdents
>one. This means that applying this patch would make debian differ with
>regards to other distributions in the syscalls that are used for the
>same binaries. In turns it is likely going to affect binaries that are
>using
Hello glibc maintainers,
would you please consider including this patch to unbreak things
(fix a regression) until the triangle between qemu, Linux and glibc
has figured out how to best deal with it?
Thanks,
//mirabilos
--
you introduced a merge commit│ % g rebase -i HEAD^^
sorry, no i
Michael Tokarev dixit:
> 17.09.2020 10:56, John Paul Adrian Glaubitz wrote:
>> On 9/17/20 9:49 AM, Michael Tokarev wrote:
>>>17.09.2020 10:08, John Paul Adrian Glaubitz wrote:
>>>> On 9/16/20 8:42 PM, Thorsten Glaser wrote:
>>>>> John Paul Adrian G
Michael Tokarev dixit:
>Since we register binfmt entries in the same package where
>the qemu-user binaries are, we can patch qemu (a one-liner)
>to always expect the P flag. I thin I'll go this route.
Thanks!
bye,
//mirabilos
--
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh
John Paul Adrian Glaubitz dixit:
>That’s been fixed upstream and can be configured with the
>qemu-binfmt.sh script and the option “preserved=yes”.
$ locate qemu-binfmt.sh | wc
0 0 0
Also, why didn’t you fix that on the m68k and sh4 qemu buildds then? ;-)
Meow,
//mirabilos
--
Package: qemu-user
Version: 1:5.1+dfsg-4
Severity: important
X-Debbugs-Cc: t...@mirbsd.de, debian-...@lists.debian.org
I’m attaching a test program that does the following:
• if argv[1] is "-" it just outputs argv[0] and argv[1]
• otherwise it also execve(2)s argv[1] with its argv[0] set to "meow
Michael Hudson-Doyle dixit:
>Hi, thanks for the quick fix, unfortunately the tests now fail because
>there is output on stderr:
AGH!
autopkgtests are… “fun”.
I’ll log into zelenka and have a look. Thanks!
bye,
//mirabilos
--
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam,
Finn Thain dixit:
>I think it would be helpful to everyone if nocheck could be avoided where
>possible. I wonder where is that possible.
I’d prefer if it could be added only for problematic packages, or
done in porter uploads, but on the buildds not for all packages.
>Which architectures are usi
Felix Lechner dixit:
>Uploaded, although I am still looking for it on the buildds:
First it must be ACCEPTED, then the dak run for incoming must
run, then B-Ds are checked, then it gets into Needs-Build status,
and only then the buildds pick it up.
It’s there now: https://buildd.debian.org/statu
Dixi quod…
>It’s there now: https://buildd.debian.org/status/package.php?p=wolfssl
… and already FTBFSing on s390x:
/usr/bin/ld: src/.libs/libwolfssl.so: undefined reference to `ByteReverseWords'
bye,
//mirabilos
--
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergei
Felix Lechner dixit:
>> Is there anything I can help to ensure it’s not autoremoved?
>
>I just saw it this morning and plan to upload 4.5.0 later today. From
>what I understand, closing #969663 should postpone the autoremoval
>process?
Thanks!
The autoremoval will go on until a version with #969
Debian testing autoremoval watch dixit:
>polyphone 2.2.0.20200612+dfsg1-1 is marked for autoremoval from testing on
>2020-10-20
>
>It (build-)depends on packages with these RC bugs:
>969663: wolfssl: CVE-2020-12457 CVE-2020-15309 CVE-2020-24585 CVE-2020-24613
> https://bugs.debian.org/969663
Is
Control: severity -1 wishlist
Control: tags -1 wontfix
John Paul Adrian Glaubitz dixit:
>On m68k and sh4, the buildds are currently configured to pass "nocheck"
Precisely for this reason, some packages in the archive ignore that
on these architectures.
Without the testsuite we cannot reliably b
Version: 1:5.1+dfsg-4
On Sun, 10 May 2020, Michael Tokarev wrote:
> ( https://bugs.debian.org/925358 )
> Can we check please if the issue is still present with qemu 5.0?
> Lots of changes has been made in qemu-user emulation..
It does:
tglase@tglase:~ $ tar xaf 925358.txz # attachment from M
Michael Hudson-Doyle dixit:
>As noted in bug 943425, mksh mis-behaves on s390s when linked against
>klibc. The test suite reacts to this by chmod -x-ing the binary, but the
>test suite then fails:
Gah, of course it does!
Thanks for messaging me, I’ll fix that.
bye,
//mirabilos
--
15:41⎜ Somebo
Package: iceweasel
Version: 68.12.0esr-1~deb9u1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
After upgrading to version 78, after starting iceweasel and
exiting it, I have tons of these messages on the terminal:
[…]
96 4096 1.
Sandbox: unsupported fd-relative fstatat(33, "", 0x7FFC07F20D60, 4096
Sebastian Dr�ge dixit:
>That's a different problem though. I saw that one before on another
>platform (Raspberry Pi IIRC). There it was something broken
>in libsrtp2-1.
Ah, okay.
>You can probably confirm that by running
>
> gst-inspect-1.0
> debian/gstreamer1.0-plugins-bad/usr/lib/x86_64-linu
Debian Bug Tracking System dixit:
>This is an automatic notification regarding your Bug report
>which was filed against the src:gst-plugins-bad1.0 package:
>
>#893813: gst-plugins-bad1.0: FTBFS on x32: wrongly uses amd64 assembly
This unfortunately doesn’t seem to be complete, 1.18.0-1 FTBFS with
Harald Dunkel dixit:
> Package: rng-tools-debian
> Version: 2.1
>
> After a fresh install and reboot rng-tools-debian fails to start with
[…]
> It shouldn't fail by default.
I’m tempted to agree, but if device autodetection fails and you
don’t configure your device as HRNGDEVICE in /etc/default/r
Package: lintian
Version: 2.92.0
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
I get output like this:
X: sfarklib source: debian-watch-does-not-check-gpg-signature
N:
P: debian-watch-does-not-check-gpg-signature
N:
N: This watch file does not specify a means to verify the upstream
N: tarball
On Sun, 30 Aug 2020, Trek wrote:
> this is a chicken-egg problem: init-d-script sources /etc/default/$NAME
> but $NAME is defined inside /etc/init.d/snmpd (that is $SCRIPTNAME)
It could do:
eval "$(grep '^NAME=' "$__init_d_script_name")"
This would cover most cases, and it could be made
Dixi quod…
>Anyway, back to topic: the TWRP update went problemless,
Ah, forgot: the manpage is completely, utterly shot and
probably causes multiple lintian warnings as well ;-) it
doesn’t honour the manpage format and doesn’t help the
user much either. The description of the options is also
mis
Nicholas D Steeves dixit:
>So it looks to me like this bug fell through the cracks during the
>process of changing submitter of your bugs from the former to the
I didn’t, because I have my From set to the mirbsd.de address for
historical reasons and mailing lists that check the Header-From :/
and
Sebastian Ramacher dixit:
>That looks like the expected difference between the amd64 and arm64
>packages. So what issues are you seeing?
Oh, interesting. I was using p.d.o to search for RtMidi.h
and found this divergence in the file lists on p.d.o…
>> https://packages.debian.org/sid/amd64/librtm
Package: librtmidi-dev
Version: 3.0.0~ds1-2+b1
Severity: important
X-Debbugs-Cc: t...@mirbsd.de
The amd64 package…
https://packages.debian.org/sid/amd64/librtmidi-dev/filelist
/usr/include/rtmidi/RtMidi.h
/usr/include/rtmidi/rtmidi_c.h
/usr/lib/x86_64-linux-gnu/librtmidi.so
/usr/lib/x86_64-linux
Hi Felix,
>In version 3.1.38-1 on stable, block reformatting sometimes changes
>the content when the first character in the second line is either an
>asterisk or a slash. Here is how to produce it:
this is, unfortunately, by design.
>The same thing happens when the slash is altered into an aster
Package: links2
Version: 2.20.2-1+b1
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: t...@mirbsd.de
I’ve got serious muscle memory from using a slightly older version of
links+ on MirBSD, where I’d left-click a link to open it in the current
window and right-click+Enter to open it in a new one.
U
On Wed, 19 Aug 2020, Cristian Ionescu-Idbohrn wrote:
> > libelogind0 actually *does* implement much of libsystemd0's ABI.
> > Just wait for the new version.
>
> Nothing pesonal. This has been gone for too long. I'm tired, but
> just let me put it this way:
[…]
I’m in the same boat. But if you
On Wed, 19 Aug 2020, Helmut Grohne wrote:
> I must admit that I find the trade-off proposed by Adrian and Thorsten
> quite reasonable. I've also looked for more options, but none came to my
> mind.
I’m actually in favour of one of the other solutions,
not the package split.
But thanks for the go
On Tue, 18 Aug 2020, Helmut Grohne wrote:
> Thorsten, can you tell more as to what precisely the problem is? I
> looked into https://buildd.debian.org/status/package.php?p=libmaxminddb.
It requires pandoc, which is rather unportable.
> It doesn't look bd-uninstallable anywhere.
That’s because I
On Tue, 18 Aug 2020, Faidon Liambotis wrote:
> with Haskell being particularly hard to bootstrap. Did I get that right?
That, and unportable, exactly.
> 10KB combined. I disagree that splitting off its two manpages into a
> separate package is the reasonable thing to do here, I'm afraid.
This i
On Tue, 18 Aug 2020, Faidon Liambotis wrote:
> If you're looking for ways to help, there is an upstream bug about the
> pandoc dependency -- I think upstream would appreciate any contributions
> folks may have on this particular issue.
Unfortunately, they’re not so willing. All they’d agree to do
On Mon, 17 Aug 2020, Cristian Ionescu-Idbohrn wrote:
> > As a workaround you can use equivs to install a dummy package that
> > Provides: libsystemd0 (99:99) to satisfy wireshark-common's
> I would have expected such a dummy package to be provided in the
No, this does not belong into the distri
901 - 1000 of 4616 matches
Mail list logo
