Package: phpunit
Version: 7.2.4-1
Severity: serious
Justification: package no longer installable in sid
The recent upload of php-phar-io-version broke even the
most recent upload of phpunit.
-- System Information:
Debian Release: buster/sid
APT prefers unreleased
APT policy: (500, 'unreleased
Package: phpunit
Version: 7.2.4-1
Severity: serious
Justification: Policy 3.3
See #899636 et al. for all the gory details.
-- System Information:
Debian Release: buster/sid
APT prefers unreleased
APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'),
(100, 'experimenta
David Prévot dixit:
>pkg-php-pear != pkg-php-maint
But all those Alioth lists no longer exist.
bye,
//mirabilos
--
18:47⎜ well channels… you see, I see everything in the
same window anyway 18:48⎜ i know, you have some kind of
telnet with automatic pong 18:48⎜ haha, yes :D
18:49⎜ th
Hi David,
are you planning to do anything with it? We’d NMU if needed,
perhaps if this is not fixed in a week or so?
Thanks,
//mirabilos
--
Thorsten Glaser (Gründungsmitglied)
Teckids e.V. — Digitale Freiheit mit Jugend und Bildung
https://www.teckids.org/
Hi Salvatore,
> forcemerge 908087 908131
I don’t think these are the same bug.
In #908131 I could report the bug, just the BTS contact for
existing bugs etc. failed.
In #908087 someone could not even report a bug.
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http
On Fri, 7 Sep 2018, Vincent Lefevre wrote:
> I disagree. Both behaviors are caused by the same issue in
> python3-pysimplesoap. These behaviors are different just because the
> users chose different interfaces in their reportbug configuration.
Ah, okay then.
> 100% accessible validated (X)HTML -
Forwarding to the BTS because, apparently, there’s a bug in
jessie-backports or POSSIBLY also in stretch, and so it’s
all archived in the same place. Comments inline, but full quote.
On Thu, 26 Oct 2017, Stefan Seidel wrote:
> Hi,
>
> I think I incorrectly reported this as Followup-For: Bug #8628
Package: xserver-xorg-core
Version: 2:1.19.0-2
Severity: serious
Justification: prevents xrdp from working
tg@leee:~ $ Xorg :10 -config xrdp/xorg.conf -noreset -nolisten tcp -logfile
/dev/null -retro
(EE)
Fatal server error:
(EE)
Invalid argument for -logfile - "/dev/null"
With elevated p
Debian Bug Tracking System dixit:
>#846158: Xorg: -logfile /dev/null not allowed, prevents xrdp from working
>
>It has been closed by Emilio Pozuelo Monfort .
I agree with it not being RC any more (sorry about that),
but not with closing it (as I still believe -logfile /dev/null
should work and t
Package: mocha
Version: 4.1.0+ds3-4
Severity: grave
Justification: renders package unusable
The /usr/bin/mocha command, present in mocha_4.1.0+ds3-3_all.deb, no
longer exists, making the package totally unusable.
-- System Information:
Debian Release: buster/sid
APT prefers buildd-unstable
AP
Hi Magnus,
>I reckon. I just haven't been able to make gbp use my long PGP key id...
any progress with that? Otherwise I’d be willing to NMU your patch.
Greetings from the BSP,
//mirabilos
--
21:12⎜ sogar bei opensolaris haben die von der community so
ziemlich jeden mist eingebaut │ man sollte
Hi Magnus,
>Perhaps wanting to run imapd via remote shell is so rare that there's
>no need to write a NEWS.Debian entry?
in case of doubt just write one, it does not hurt.
Are you going to upload within the next five days or so, or
do you need help? (We’re at a BSP and currently fixing stuff…)
)
+
+ -- Thorsten Glaser Sun, 24 Feb 2019 17:47:26 +0100
+
texlive-extra (2018.20190131-1) unstable; urgency=medium
* new upstream checkout
diff -Nru texlive-extra-2018.20190131/debian/patches/fix-tabu-920459
texlive-extra-2018.20190131/debian/patches/fix-tabu-920459
--- texlive-extra
Hi Norbert,
>Go ahead immediately, you have every approval.
>BTW, changes can be sent to the new development place
> https://github.com/debian-tex/texlive-nonbin
OK, will do so. I’ll give people a bit to review,
although someone on TeX.SE said tabu is broken
enough there’s no way I can make
Hi Debian Linux kernel maintainers,
On Wed, 27 Feb 2019, Dragan Milenkovic wrote:
> > Hello Dragan, do you know if the patch was eventually included upstream and
> > possibly in which version?
>
> Hello, Cesare. It was included in 4.20.11 and 4.19.24.
please do consider uploading 4.19.24 to bust
Package: alpine
Version: 2.21+dfsg1-1.1
Severity: serious
If I take a message, reply to it, then go to the Subject line,
press ^K to remove the existing (possibly damaged) text and type
new text (possibly to change the subthread subject), the eMail
gets sent out AND Fcc’d without both In-Reply-To
Hi Cesare,
> But, in the meantime, doesn't the workaround of disabling blk_mq work
> for you?
I don’t know, because I have no means to trigger the bug. The three
other virtualisators I’ve upgraded at the same time did not trigger it.
My desktop machine also hits it only occasionally.
I’ve reboot
Package: php-yaml
Version: 2.0.2+1.3.1-2
Severity: grave
Justification: renders package unusable
php-yaml (2.0.2+1.3.1-2) has a regression over (2.0.0+1.3.0-2+b1):
root@tglase:~ # /usr/lib/php/sessionclean
PHP Warning: PHP Startup: Unable to load dynamic library
'/usr/lib/php/20160303/yaml.so'
reopen 906744
thanks
Ondřej Surý dixit:
>https://tracker.debian.org/media/packages/p/php-defaults/changelog-61
Meh, but why’s it still in mods-available then?
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228
On Sat, 1 Sep 2018, Debian Bug Tracking System wrote:
> #894970: tomcat8: missing Depends on libservlet3.1-java
>
> It has been closed by Markus Koschany .
Confirm fixed, thanks!
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881
Source: pandas
Version: 0.23.3-1
Severity: serious
See #917418 for “python-nbsphinx (0.4.1+ds-1) is not installable”.
src:nbsphinx (0.4.1+ds-3) now only builds the py3k package.
python-nbsphinx (= 0.3.5+ds-1) is installable and usable, but no
longer in Debian, so please move to python3-nbsphinx
Ben Hutchings dixit:
>the new Debian version crashes on s390x. It looks like this is due to
>an address collision between the build ID in the shared library and
>the code in the executables.
Helge Deller dixit:
>[ 58.612345] 117 (fstype): Uhuuh, elf segment at 0001 requested
>bu
Michael Stone dixit:
> No, that's something else that shouldn't have happened
It’s important to me because the upload of rng-tools (>> 2)
broke things on unstable.
Perhaps letting it migrate to testing wasn’t ideal, but it
will work for people there, and it won’t affect existing
users or those w
Michael Stone dixit:
> Please upload a fixed version of rng-tools instead, reverting the erroneous
> change.
That is impossible because the version changed.
In the tool I’m using, I have a hard version requirement on
rng-tools (<< 3) | rng-tools-debian (<< 3).
At best we could do with an epoch
Michael Stone dixit:
> So use the epoch. They're invented for fixing collosal errors like
> this. Except this time, have the appropriate discussion on -devel
> instead of just uploading something without coordination.
Sounds like an approach, but please see in #919893 my message
first for
an alt
Package: openjdk-11-jdk
Version: 11.0.2+7-1
Severity: grave
Tags: patch
Justification: renders package unusable
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.0.1:jar (attach-javadocs) on
project octopus-rpctunnel: MavenReportException: Error while generating
Jav
On Mon, 21 Jan 2019, Matthias Klose wrote:
> no, why are you exaggerating? Both the jre and the jdk are usable.
The javadoc tool isn’t, and this breaks all builds.
I’ve enacted the workaround in the meantime, even if this
goes against the documented javadoc options…
bye,
//mirabilos
--
tarent
Michael Stone dixit:
> Yes, exactly: it's definitely better for a certain class of hardware, but I'm
> honestly just not sure whether any of those are still relevant. (Like, do they
> work with current kernels, are they in hardware that's otherwise supported,
> etc.?) I'd love to see reports from
Michael Stone dixit:
> So that's basically just the --rng-entropy argument? If we switch rng-tools5
> to
/usr/lib/stunnel/arngc-slrd | runtunnel | \
rngd -f -r /proc/self/fd/0 -H 0.99 -B 2 \
-s 32 -W "$threshold" -t 300 -T 60
I just had the idea of “castling”¹, t
Package: mcabber
Version: 1.1.0-1.1
Severity: serious
Tags: ipv6
Justification: fails release goal
I’m currently in the FOSDEM WLAN (IPv6-only, not FOSDEM-legacy),
and I can neither connect to the Jabber server with SRV RRs nor
when hardcoding commu.teckids.org in mcabberrc.
A netcat on commu.tec
Andreas Metzler dixit:
>commu.teckids.org offers TLS 1.3, so I a suspect the TLS code is not up
>to date for TLS 1.3.
No, I can normally connect. mcabber is my primary client because it
works inside GNU screen. It just didn’t work at FOSDEM in the IPv6-only
network there (the FOSDEM-legacy had IP
latinovic dixit:
> The patch that solves this is attached.
I think the patch is broken, wait4() requires an additional
argument which must be zero for waitpid() emulation, not some
random stack (or register, depending on the architecture) garbage.
bye,
//mirabilos
--
Stéphane, I actually don’t
James Clarke dixit:
>#817236 strikes again; the thread there has various workarounds.
Why is this still not fixed in debootstrap, anyway?
Thanks,
//mirabilos
--
> Wish I had pine to hand :-( I'll give lynx a try, thanks.
Michael Schmitz on nntp://news.gmane.org/gmane.linux.debian.ports.68k
a.k
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
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:
>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:
>... 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:
>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
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
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
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.)
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,
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
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
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:
>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.
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
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 ad
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.
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 reading
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
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
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:
>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
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
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
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
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
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
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 clearl
# 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 bu
Package: musescore
Version: 2.3.2+dfsg2-6
Severity: serious
Tags: security
Justification: phones home
Bugreport for myself and for release tracking.
Dear release team, please indicate whether this is buster release-critical,
I will try to fix it later tonight.
On first startup, MuseScore connec
notfound 931021 musescore-snapshot/3.1+dfsg1-1
thanks
> Bugreport for myself and for release tracking.
MuseScore 3, which is currently sitting in experimental, intending to
hit sid after the release, is NOT affected; disabling the web centre
thingy seems to suffice.
bye,
//mirabilos
--
«MyISAM
Source: gnutls28
Version: 3.6.9-3
Severity: serious
Justification: FTBFS on release arch
From:
https://buildd.debian.org/status/fetch.php?pkg=gnutls28&arch=i386&ver=3.6.9-3&stamp=1564822578&raw=0
[…]
SKIP: p11-kit-trust.sh
Package: libklibc-dev
Version: 2.0.8-6
Severity: serious
Justification: spec violation, affecting release architectures
X-Debbugs-Cc: t...@debian.org
Found during debugging of #943425:
- usr/include/setjmp.h
struct __sigjmp_buf {
jmp_buf __jmpbuf;
sigset_t
Dixi quod…
>So, setjmp/longjmp in klibc save f1/f3/f5/f7 (as shown on Wikipedia
>https://en.wikipedia.org/wiki/Calling_convention#IBM_System/360_and_successors
>“the z/Architecture ABI,[11] used in Linux” a page down), while
>glibc’s save f8–f15 instead.
Jessica Clarke brought out docs saying f8‥
Dixi quod…
>Jessica Clarke brought out docs saying f8‥f15 must be saved, the
>other FPU registers not:
This needs to be fixed in klibc.
>>• klibc does not really support the FPU anyway
>
>… GCC chooses to allocate an FPU register for a pointer value.
This is a curiosity.
>>• the half of v10 th
Hi Andreas,
>>> Jessica Clarke brought out docs saying f8‥f15 must be saved, the
>>> other FPU registers not:
>
>I can confirm this. It is f8-f15 for the z/Architecture (64 bit).
thanks!
>It is f1, f3, f5, f7 for the ESA
>architecture (32 bit) which is still supported by Glibc and GCC.
Is this
,long}jmp always saves the signal mask (Closes: #988027)
+ * [s390x] Fix {set,long}jmp registers to save (Closes: #943425)
+
+ -- Thorsten Glaser Wed, 05 May 2021 21:38:31 +0200
+
klibc (2.0.8-6) unstable; urgency=medium
* Upload to unstable
diff -Nru
klibc-2.0.8/debian/patches/0001-kli
Package: eyed3
Version: 0.8.10-1.1
Severity: serious
Justification: fails to work
X-Debbugs-Cc: t...@mirbsd.de
$ eyeD3 -P display -p %a% *.mp3
eyed3.plugins:WARNING: Plugin '('lastfm.py',
'/usr/lib/python3/dist-packages/eyed3/plugins')' requires packages that are not
installed: cannot import nam
Hello Ben,
any chance to upload at least the patch for s390x?
This affects a release architrecture, so I’d NMU this if
necessary, so we have it fixed in bullseye.
Thanks,
//mirabilos
--
“Having a smoking section in a restaurant is like having
a peeing section in a swimming pool.”
) (Closes: #943425)
+
+ -- Thorsten Glaser Thu, 27 May 2021 00:12:10 +0200
+
klibc (2.0.8-6) unstable; urgency=medium
* Upload to unstable
diff -Nru
klibc-2.0.8/debian/patches/0041-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
klibc-2.0.8/debian/patches/0041-klibc-set-long-jmp
Package: prosody
Version: 0.11.2-1+deb10u2
Severity: serious
Justification: Policy 10.7.3
The recent security upgrade (0.11.2-1 → 0.11.2-1+deb10u2)
overwrote the configuration files prosody/certs/localhost.{crt,key}
without asking, notifying, or anything. This is a Policy violation:
10.7.3. Behav
Hi,
this bug is still open in buster…
bye,
//mirabilos
--
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be
Source: openjdk-8
Version: 8u282-b08-2
Severity: serious
Justification: should not migrate to testing or stable any more
X-Debbugs-Cc: t...@mirbsd.de
Keep this package in unstable (and possibly experimental) for now.
It is to be used officially only for bootstrapping JVM-based languages
like Kotli
Source: telegram-purple
Severity: serious
Justification: FTBFS on release architecture
… just so that nobody else reports this bug (I know about it).
severity 958828 important
outlook 958828 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958828#18
thanks
Hi Ben,
> tl;dr: wontfix (cantfix)
ok. If it’s by design, I can declare the package little-endian-only.
> I'm effectively the maintainer of telegram-purple. Not because I
> actually *deve
Setting ac_cv_path_SED=/bin/sed in the environment
of the configure call might even be easier and less invasive.
YMMV,
//mirabilos
--
Thorsten Glaser (Gründungsmitglied)
Teckids e.V. — Digitale Freiheit mit Jugend und Bildung
https://www.teckids.org/
Package: libjs-jquery
Version: 3.5.1+dfsg+~3.5.5-3
Followup-For: Bug #977960
X-Debbugs-Cc: t...@mirbsd.de
Even for the latest versions of these packages, adequate reports:
node-jquery: broken-symlink /usr/share/nodejs/jquery/dist/jquery.js ->
../../nodejs/jquery/dist/jquery.js
node-jquery: broke
Package: node-jquery
Version: 3.5.1+dfsg+~3.5.5-3
Followup-For: Bug #977960
X-Debbugs-Cc: t...@mirbsd.de
Even for the latest versions of these packages, adequate reports:
node-jquery: broken-symlink /usr/share/nodejs/jquery/dist/jquery.js ->
../../nodejs/jquery/dist/jquery.js
node-jquery: broken
Package: android-sdk-platform-tools-common
Version: 28.0.2+2
Severity: serious
Justification: might not be as severe but fails a release goal
X-Debbugs-Cc: t...@mirbsd.de
I cannot upgrade adb:i386 on my x32 system because adb:i386
Depends android-sdk-platform-tools-common, however, because
android
On Thu, 18 Feb 2021, Salvatore Bonaccorso wrote:
> On Thu, Feb 11, 2021 at 08:33:58AM +0100, Sebastien Delafond wrote:
> > The recently applied patch still creates the file with the default
> > umask[0], before chmod'ing down to 0600, so an attacker could still open
> > it in the meantime.
>
> FTR
Package: ipxe-qemu
Version: 1.0.0+git-20190125.36a4c85-5.1
Followup-For: Bug #929983
X-Debbugs-Cc: t...@mirbsd.de
This is also broken on an up-to-date-enough sid system.
$ qemu-system-x86_64 -device virtio-net-pci,netdev=net0 -netdev user,id=net0
-nographic
boots.
$ qemu-system-x86_64 -device
Dixi quod…
>Downgrading *only* the package ipxe-qemu to 1.0.0+git-20161027.b991c67-1
(the version in stretch)
>on that very sid system…
>
>… doesn’t make this succeed either. Huh.
Downgrading seabios along (need to remove -nographic to make that work)
also doesn’t yield netboot success, so there’
Package: qdbus
Version: 4:5.15.2-4
Severity: serious
Justification: unupgradable
The new qdbus arch:all package is no longer Multi-Arch:foreign,
making it uninstallable on, for example, an amd64 system which
has an i386 package with Depends: qdbus installed.
Given qdbus 4:4.8.7+dfsg-20 (arch:any)
Evgeni Golov dixit:
>> tglase@tglase-nb:~ $ sudo cleanenv / /etc/init.d/thinkfan start
>> Starting fan control tool: thinkfan
>> ERROR: Error scanning
>> /sys/devices/pci:00/:00:03.1/:27:00.0/hwmon: No such file or
>> directory
>> failed!
>
>-3 has a NEWS.Debian explaining the chang
Evgeni Golov dixit:
>> No, this is about the *vanilla* config shipped by the package.
>> It used to work (my adjustment later was only regarding the levels
>> of temperature as I’ve got an SSD, not HDD, so it can become a bit
>> higher for quietness) and now the package doesn’t work at all.
>
>Yea
Evgeni Golov dixit:
>>… without that it’ll also fail, which means it’ll fail package
>>installation, which is a serious (RC) bug.
>
>No, the daemon is not started on install
Did that change recently? Because when I reported this bug first
it was precisely because it was started on install…
>, ex
Evgeni Golov dixit:
>>>, exactly because neither the old nor the new configuration is in a
>>>state where it's supposed to work out of the box.
>>
>>But why? The pre-YAML thing *did* work out of the box, very finely
>>so, and I only changed the config one hot summer to have a little
>>more quiet.
Andreas Beckmann dixit:
>during a test with piuparts I noticed your package fails to remove.
>
>>From the attached log (scroll to the bottom...):
>
> Removing musescore-common (2.3.2+dfsg4-12) ...
> rmdir: failed to remove '/usr/share/sounds/sf2': No such file or directory
> dpkg: error process
Andreas Beckmann dixit:
> Removing musescore-common (2.3.2+dfsg4-12) ...
> rmdir: failed to remove '/usr/share/sounds/sf2': No such file or directory
> dpkg: error processing package musescore-common (--remove):
> installed musescore-common package pre-removal script subprocess returned
> er
Andreas Beckmann dixit:
>during a test with piuparts I noticed your package fails to remove.
According to https://piuparts.debian.org/sid-strict/source/m/musescore2.html
the musescore-common package succeeds piuparts, too… huh… weird.
Fixing it at the moment,
//mirabilos
Andreas Beckmann dixit:
> Which is another point for *shipping* the directories to let dpkg do the
> refcounting, otherwise the manually created directory gets removed by dpkg
> removing a different package.
Hmh, good point.
> On 05/03/2021 16.17, Thorsten Glaser wrote:
>>&g
Source: xterm
Version: 327-2+deb9u1
Severity: serious
Justification: introduces use-after-realloc
debian/patches/CVE-2021-27135.patch changes button.c line (after
patching) 3747 to:
line = realloc(line, screen->selection_size);
But “line” is a local variable, the address of the buffer mus
Sven Joachim dixit:
>I see that this might be a problem (albeit unlikely to happen in
>practice), however I have trouble understanding exactly where a
>use-after-realloc bug comes into play. Maybe Thorsten can help me fix
>my blindness?
The next time something is selected, the code a little furt
retitle 929983 ipxe-qemu: virtio booting broken past jessie
notfound 929983 1.0.0+git-20141004.86285d1-1
notfound 929983 1.0.0+git-20150424.a25a16d-1
found 929983 1.0.0+git-20161027.b991c67-1
found 929983 1.0.0+git-20190125.36a4c85-5.1
thanks
On Fri, 26 Feb 2021, Thorsten Glaser wrote
Hi,
the changelogs seem to differ in re-added certificates:
ca-certificates (20210119) unstable; urgency=medium
[ Michael Shuler ]
* mozilla/blacklist:
Revert Symantec CA blacklist (#911289). Closes: #962596
The following root certificates were added back (+):
+ "GeoTrust P
Hi Julien,
>Yes, they're different. I'm not sure what you're asking.
the reason for the difference; sorry if I was unclear.
Thanks,
//mirabilos
--
18:47⎜ well channels… you see, I see everything in the
same window anyway 18:48⎜ i know, you have some kind of
telnet with automatic pong
Utkarsh Gupta dixit:
>Thanks to Thomas for his help, I've uploaded a fix for this regression
>(by reverting the backport of that part of the patch which was not
>necessary
It’s got some memory impact, but probably neglegible here, true.
> for this CVE fix). And thanks to Thorsten for his
>compre
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
1 - 100 of 1023 matches
Mail list logo
