On Sat, 2013-12-21 at 08:49 -0800, Russ Allbery wrote:
> Tollef Fog Heen writes:
> > sd-daemon.c is also intentionally designed to not have dependencies on
> > the rest of the systemd source and to be portable to non-linux
> > architectures too (but basically just stubs then) just so people can pu
Josh Triplett wrote:
> I upgraded OpenSSL and OpenSSH stopped working. Since the SONAME didn't
> change, kinda by definition this seems like a bug in OpenSSL, not
> OpenSSH.
That "by definition" only holds if you assume all applications are
perfect software with no bugs whatsoever, and use librar
On Thu, 2013-12-26 at 21:42 +, Colin Watson wrote:
> On Thu, Dec 26, 2013 at 08:49:11AM +0100, Tollef Fog Heen wrote:
> > In this particular case, as you write, I hadn't really given it any
> > consideration before, but what I think would make sense is to extend
> > systemd to support the same
On Sat, 2013-12-28 at 17:24 -0800, Russ Allbery wrote:
> * systemd synchronization support added via sd_notify.
> * systemd socket activation support.
Does sd_notify() actually give any positive effect compared to just
using type=simple, given that you already have socket activation? The
UDP socke
On Sat, 2013-12-28 at 21:29 -0800, Russ Allbery wrote:
> Uoti Urpala writes:
> > Does sd_notify() actually give any positive effect compared to just
> > using type=simple, given that you already have socket activation? The
> > UDP socket should buffer packets until the daemon
On Sun, 2013-12-29 at 01:10 -0800, Steve Langasek wrote:
> However, I think this gets to the heart of why upstart upstream has avoided
> ever recommending the use of socket-based activation. There are some fairly
> fundamental problems that basically halted development of socket-based
> activation
On Sun, 2013-12-29 at 10:37 -0800, Steve Langasek wrote:
> It's quite possible that I am doing something wrong, but I don't think this
> is it. Each of the .service units in question already had
> 'WantedBy=multi-user.target', and each of the .socket units had
> 'WantedBy=sockets.target'; on Fedor
On Sun, 2013-12-29 at 14:02 +, Colin Watson wrote:
> I was referring more to Tollef's position, really. Debian systemd
> maintenance ought to take into account matters of Debian integration,
> which includes whether it fits well into best-of-breed Debian practice.
>
> If it's easy enough to o
On Mon, 2013-12-30 at 18:58 +, Ian Jackson wrote:
> Also, I get the impression me that the "integration" of much of this
> functionality into the systemd source package has been done for
> political rather than technical reasons. Indeed to the extent that
> there is a problematically tight tec
On Tue, 2013-12-31 at 02:55 +, Colin Watson wrote:
> My main concerns with systemd relate to its broad scope regarding units
> it provides for system initialisation tasks currently performed by other
> packages, and the potential for that to interfere with past and future
> work elsewhere in De
On Wed, 2014-01-01 at 17:17 +, Colin Watson wrote:
> On Wed, Jan 01, 2014 at 05:52:03PM +0100, Ansgar Burchardt wrote:
> > Colin Watson writes:
> > > Basically, systemd would be more compelling to me if it tried to do
> > > less. I don't expect to persuade systemd advocates of this, as I thin
On Thu, 2014-01-02 at 12:31 +, Colin Watson wrote:
> On Wed, Jan 01, 2014 at 08:15:46PM +0200, Uoti Urpala wrote:
> > You can simply not install any of these additional services if you don't
> > want them. This is completely trivial to do.
>
> It is indeed technic
On Fri, 2014-01-03 at 10:02 -0800, Nikolaus Rath wrote:
> Ian Jackson writes:
> > | 3. At least in jessie, unless a satisfactory compatibility approach is
> > |developed and deployed (see paragraph 10), packages must continue
> > |to provide sysvinit scripts. Lack of a sysvinit script (fo
On Fri, 2014-01-03 at 16:40 -0800, Russ Allbery wrote:
> Ian Jackson writes:
> > I've written a version of Niklaus's rule about dependencies:
>
> >Likewise, packages must not Depend on or Recommend (directly or
> >indirectly) a specific init(1). Violations of this are also an RC
> >b
On Fri, 2014-01-03 at 20:26 -0800, Nikolaus Rath wrote:
> Clint Adams writes:
> > On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote:
> >> or alternatively
> >>
> >> 4. Packages may, however, depend on a specific init system (which may
> >>not be the default init) for features t
On Thu, 2014-01-16 at 17:00 -0800, Russ Allbery wrote:
> Uoti Urpala writes:
> > I think the divergence has gone too far in things like non-Linux ports.
> > They have had an overall negative effect on people working on Linux
> > within Debian and people creating derivatives
On Tue, 2014-01-28 at 22:20 +0200, Adrian Bunk wrote:
> On Tue, Jan 28, 2014 at 12:08:19PM -0800, Don Armstrong wrote:
> > On Tue, 28 Jan 2014, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Tue, Jan 28, 2014 at 11:23:11AM -0800, Don Armstrong wrote:
> > > > The former. So :
> > > >
> > > >Where
On Sat, 2014-02-01 at 17:10 +, Ian Jackson wrote:
> Sébastien Villemot writes ("Bug#727708: TC resolution revised draft"):
> > P1: DT > UT > DL > UL
> > P2: DL > UL > DT > UT
> > P3: UT > UL > DL > DT
> > P4: UT > UL > DL > DT
>
> This is a nice example which actually demonstrates why these qu
On Sat, 2014-02-01 at 15:24 -0800, Steve Langasek wrote:
> While I think the Depends: systemd should be dropped (via a split of the
> systemd package), that's not required for fixing the present problem. That
> can be addressed by having gnome-settings-daemon Depends: systemd,
> systemd-shim | sys
On Tue, 2014-02-04 at 16:53 +, Colin Watson wrote:
> On Sun, Feb 02, 2014 at 12:57:39PM +0100, Tollef Fog Heen wrote:
> > You mean, like installing the systemd-sysv package?
>
> Indeed; but people earlier in this thread have said that this isn't the
> preferred approach, so I was arguing that
On Sat, 2014-02-08 at 22:52 +1100, Dmitry Smirnov wrote:
> Also I'd like to notice that shopping for most feature-rich init system
> might be not our goal after all. OpenRC may be the safest choice that might
> satisfy majority of developers as it appears to have the least number of
> objections
On Sat, 2013-12-14 at 21:45 +, Ian Jackson wrote:
> I've just been reading sd_listen_fds(3). It's vaguely similar to
> upstart's socket activation protocol. It supports multiple sockets
> (which is obviously important).
>
> But I have a few questions about the details:
>
> Why do only some
On Wed, 2013-12-18 at 13:34 +0200, Adrian Bunk wrote:
> On Tue, Dec 17, 2013 at 06:02:50PM -0500, Sam Hartman wrote:
> > I'm confused, when I hear you say that this risk is unique to the
> > systemd option and not shared by other options. I would understand that
> > statement if we thought we coul
On Wed, 2013-12-18 at 16:27 +0100, Josselin Mouette wrote:
> Such stances are untenable whenever the kernel is concerned. We need to
> be able to use a kernel from the previous stable distribution, or from
> the next one, to support proper chroots. This part of the support for
> upgrades is needed
This setting was removed in systemd v205 as a part of the control group
rework. Improving documentation of what it did in v204 is likely not
worth the effort.
My guess is that it did not have effects like "result in all descendants
of the main service daemon to be killed", but only mattered if you
On Fri, 2013-12-20 at 07:53 -0800, Steve Langasek wrote:
> On Thu, Dec 19, 2013 at 11:26:19PM +0100, Josselin Mouette wrote:
> > Le jeudi 19 décembre 2013 à 12:35 -0800, Steve Langasek a écrit :
> > > ecosystem. This needs to be resolved before logind v205 can reasonably be
> > > adopted, because
Christoph Anton Mitterer wrote:
> Now since I switched to systemd, it tries to start fail2ban before
> iptables-persistent,
> thus the rules are missing and thus starting fail2ban fails.
Is there any reason to believe that there actually is an issue with
"wrong order"? I don't see any in the give
Now this broken version is in unstable too. It keeps looping on poll()
to read from socketpair status fd from child; the child closes its side
when exec()ing the actual command to run, so the socket is readable due
to EOF. There seems to no code whatsoever to stop further reading
attempts at EOF (e
Christoph Anton Mitterer wrote:
> I tried it with log level debug now...
>
> As you can see from there... systemd actually schedules
> iptables-persistend first... but it seems that this get's only executed
> much later (i.e. after fail2ban).
I think the log shows your conclusions were (and are)
On Thu, 2014-01-16 at 19:12 +, Ian Jackson wrote:
> AFAICT we are all agreed that:
> * Applications which aren't part of the init system must not require a
> particular init to be pid 1. (So in particular a desktop
> environment may not require a particular pid 1.)
I read the log, and I
On Thu, 2014-01-16 at 17:52 +, Ian Jackson wrote:
> * Debian is a forum for cooperation and technical development.
> * Debian, as a piece of software, tries to be all things to all
> people (within reason).
> This flexibility and tolerance for divergence has made Debian an
> extremely attra
On Fri, 2014-01-17 at 16:08 +0100, Ihar Filipau wrote:
> Uoti Urpala wrote:
> > Even the upstart proponents do not seem to have significant arguments
> > about upstart having better functionality, and there don't seem to be
> > all that many people who would have a reason
Ian Jackson wrote:
> It isn't always 100% clear to me from reading these which of them
> apply to systemd's init replacement. But reading the systemd debate
> page makes it clear that the other components in the systemd upstream
> package are seen by systemd proponents as part of their offering, a
On Fri, 2013-11-29 at 12:37 +, Ian Jackson wrote:
> Uoti Urpala writes ("Bug#727708: systemd (security) bugs (was: init system
> question)"):
> > My guess is that most people do not consider that "exciting" or really
> > care - thinking of system st
On Mon, 2013-12-02 at 15:32 -0800, Don Armstrong wrote:
> On Tue, 03 Dec 2013, Josselin Mouette wrote:
> > Le lundi 02 décembre 2013 à 13:41 -0700, Bdale Garbee a écrit :
> > > Josselin Mouette writes:
> > >
> > > > There are two implied assumptions here:
> > > > * that the same people ar
to systemd could help. I haven't tried running it at
all, but at least the existing code looks suspicious, so if correct the
patch could fix the same issue.
>From 6d575f18437dd5bfd02c4736dbd3e6a8a1286ab2 Mon Sep 17 00:00:00 2001
From: Uoti Urpala
Date: Mon, 23 Jun 2014 08:14:22 +0300
Sub
Petter Reinholdtsen wrote:
> [Ferdinand Thommes]
> > I tried to install the package ddclient, that relies on a sysvinit
> > script. The install was interupterd by an error:
> > update-rc.d: warning: start and stop actions are no longer supported;
> > falling
> > back to defaults
> > insserv: Loop
On Sat, 2014-03-08 at 13:11 -0500, Reinhard Tartler wrote:
> On Sat, Mar 1, 2014 at 7:05 AM, wrote:
> >
> > Hi,
> > the attached patch should fix this bug.
>
> Thanks for providing this patch for the debian mplayer2 packages.
> Unfortunately, it does not apply cleanly against the upstream versio
Ed Swierk wrote:
> I found that adding RemainAfterExit=yes to the service file prevents
> this from happening. But nothing in the systemd documentation (nor in
> the code, to the extent I understand it) indicates that this is
> necessary for oneshot services.
This has been a known issue for some s
On Wed, 2012-09-26 at 07:21 +0200, Reinhard Tartler wrote:
> > wvc1 videos are unseekable in mplayer2. For example if I try to seek 10
> > seconds
> > forward using right key, then the video freezes. A sample video is here:
> >
> > http://ftyps.com/unrelated/vc1_in_wmv.wmv
>
> I can reproduce the
Another thing which seems to reliably lose state:
- setup apt-listchanges to show changelogs and prompt for confirmation
- start an upgrade which would remove some now unused packages
- answer 'n' to the apt-listchanges prompt
The packages that would have been removed have now lost automatic
statu
I encountered this bug, though the system still booted successfully with
some error messages.
"grub-install /dev/sda" and "update-grub" fixed the problem.
'dpkg-reconfigure grub-pc' was NOT useful.
I think grub-pc.postinst failed to run any of the code paths that would
run update-grub. The scrip
This is most likely caused by misbehaving audio output. Especially
PulseAudio is known to have bugs which cause such problems. However,
you're using the mplayer2 version from experimental which has
workarounds for those PulseAudio issues and should work for most people
(unfortunately, Debian unstab
On Thu, 2012-05-24 at 13:47 +0200, Martin Ziegler wrote:
> mplayer said that the output device was pulse:
>
> AO: [pulse]
>
> Wenn I use mplayer with the option "-ao alsa" everything
> works fine. Thanks!
This is most likely a Pulseaudio bug then.
> It might be interesting that the version of
ff_codec_wav_tags is not part of the ABI (all symbols with ff_ prefix in
Libav are internal and may not be used in outside applications).
MPlayer1 is designed to be compiled with an embedded copy of FFmpeg
rather than use shared libraries for libavformat etc. It does not stay
within the API export
On Sat, 2012-05-12 at 12:52 +0200, Kurt Roeckx wrote:
> On Sun, Apr 15, 2012 at 07:17:34PM +0300, Uoti Urpala wrote:
> > This is expected behavior with ALSA dmix. It has a fixed hardware output
> > frequency, in your case 48000 Hz.
>
> As far as I know this is just a defau
As far as I can see there is no bug.
This is expected behavior with ALSA dmix. It has a fixed hardware output
frequency, in your case 48000 Hz. Anything played through dmix will be
resampled to 48000 Hz. mplayer2 could feed data to ALSA at 44100 Hz if
it left ALSA resampling enabled, but the only
The issue in the log is due to the file being so short (0.5 seconds).
This is the same as
http://devel.mplayer2.org/ticket/166
The total amount of audio is not enough to trigger automatic start of
playback. However, for some weird reason setting that amount lower
triggered yet another Pulseaudio b
Are you using Pulseaudio output (or ALSA redirected through Pulseaudio)?
My first guess is that you're hitting one of Pulseaudio's numerous bugs,
where it keeps falsely reporting that there's still a significant amount
of unplayed audio left; the player keeps waiting for the audio to finish
playing
Fixed upstream in bb908027178fe8bfd7d6e3fc255dea8c5051cd4a.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
This is a limitation reported by libXv. It's likely due to limitations
of your graphics hardware. You can try other output methods such as gl,
but it's likely they won't work well either on such hardware.
Using --xy=0.5 won't help, because that will try to do the scaling in
hardware, but the limit
If I've understood the issue correctly, the current "forwarded" tag on
this bug is wrong, in the sense that the fundamental underlying problem
is in sudo, and so any possible forwarding waiting for "upstream fix"
should point to a sudo bug.
AFAIK this problem with libpam-systemd is caused by the s
On Tue, 8 Nov 2016 15:33:32 +1030 Ron wrote:
> On Mon, Nov 07, 2016 at 12:09:21PM -0800, Nikolaus Rath wrote:
> > It seems you're only interested in impartial and non-partisan voices
> > when they happen to back your position. I am impartial and non-partisan,
> > and formed my opinion by reading t
On Tue, 17 Nov 2015 13:47:29 +0100 Miroslav Urbanek
wrote:
> > What's the result type of float * int ? Definitively not double, but
> > float. (Just the intermediate result in the x87 fpu has extended
> > precision.)
>
> True, according to C11 standard, section 6.3.1.8, the result type of
> floa
On Fri, 21 Nov 2014 20:20:45 + Simon McVittie wrote:
> dependency: systemd logs that there was a loop, and which arbitrary point
> it tried to use to break it. However, it does not log (an example of) the
> whole path around the loop before it started trying to break it.
IIRC it does log that
This is a kernel/dash issue. In kernel 4.0, the md sysfs implementation
does not work with partial reads from /sys/block/md0/md/sync_action;
the read syscall returns the entire contents of the file even if you
try to read less. Dash has an inefficient implementation which reads
input one byte at a
I checked that this did not happen on a system I just updated from 204
to 215; contents of /run/user/1000 remained unchanged after the upgrade.
Are you sure that the upgrade actually *removed* contents? A possibly
relevant change is that logind started to mount a per-user tmpfs
in /run/user/* (for
On Thu, 2014-09-18 at 12:23 -0700, Steve Langasek wrote:
> On Thu, Sep 18, 2014 at 11:36:54AM -0700, Josh Triplett wrote:
> > I agree completely that it doesn't make sense for the transition from
> > sysvinit to systemd to take place via libpam-systemd rather than via
> > some core package like "in
On Thu, 2014-09-18 at 17:14 -0700, Cameron Norman wrote:
> On Thu, Sep 18, 2014 at 2:10 PM, Josh Triplett wrote:
> > Personally, in this case, I'd argue that the desirable dependency (which
> > we can't easily express) would be "sysvinit-core ? systemd-shim :
> > systemd-sysv".
>
> To be more pre
Marco d'Itri wrote:
> On Sep 23, 積丹尼 Dan Jacobson wrote:
> > Why the \x2d in one 'slice' but not the other?
> Because one contains / and the other does not.
2d hex is '-', not '/'. The actual reason is that '-' in slice names has
a special meaning to separate hierarchical components, and '-' with
Marc Bonnor wrote:
> I have run the strace command as suggested and attached the output.
> 18:58:28 open("/tmp",
> O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_NOFOLLOW|O_NOATIME|O_CLOEXEC) = 4
> 18:58:28 fstat(4, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=117604352, ...}) = 0
> 18:58:28 fcntl(4, F_GETFL)
On Mon, 20 Oct 2014 10:06:31 -0400 Martin Pitt wrote:
> I'll leave this to the Debian maintainers, as I'm mostly responsible
> for the Ubuntu side, haven't really discussed this with the two
> Michaels/Tollef/Marco, and I don't feel qualified to speak for the
> Debian systemd team.
>
> My persona
On Wed, 22 Oct 2014 18:23:54 +1100 Marc Bonnor wrote:
> The command ls -l /tmp also blocks ...
That pretty much confirms that it is a filesystem problem not directly
related to systemd.
> The line before the lines shown in the file extract has an odd looking
> path "//tmp", do you think this may
On Thu, 23 Oct 2014 17:36:15 + Matthias Klose wrote:
>* Change B-D to libjpeg-dev to finish the transition to libjpeg-turbo
> (Ondřej Surý). Closes: #763489.
openjdk-7-jre-headless version 7u71-2.5.3-1 depends on libjpeg8 AND
libjpeg62-turbo. I assume this isn't right...
--
To UNS
Marc Bonnor wrote:
> I have also poked around in the debug shell during boot and there is almost no
> cpu activity and the systemd-tmpfiles command has statuts 'D' uniteruptable
> sleep.
>
> I used iotop to view io activity during the boot and this 'Executing: /bin
> /systemd-tmpfiles --create --r
The following keybinding should do this:
cycle options/audio-pitch-correction
With "cycle" this will switch between on and off.
On Sat, 10 Dec 2016 06:54:17 +1030 Ron wrote:
> You then had the gall to angrily insist that while you thought he might
> be a better maintainer than me, it was still my responsibility to do the
> work to fix all the obvious things that others had missed in their fork
> (which he hadn't contribute
Note: this is written as an outsider who doesn't have any direct stake
in the issue.
On Sun, 6 Nov 2016 05:00:12 +1030 Ron wrote:
> > And I think the latter is basically what the "just ship multiple
> versions and hope the future gets clearer" option boils down to.
> All it really does is take th
On Mon, 21 Nov 2016 17:16:34 +1030 Ron wrote:
> If we run with your proposal, what are you actually suggesting we tell
> the people who'd be upset by the loss of htags without notice in Stretch?
> Because I don't really see how you've addressed that here.
>
> AFAICS, there's just either an implic
On Sat, 16 Jul 2016 00:02:55 +0100 Neil Williams
wrote:
> On Fri, 15 Jul 2016 23:45:01 +0530
> Pirate Praveen wrote:
>> If this argument is accepted, we will not be able to package a fork
>> because the original upstream won't accept a patch against the fork.
>> Similarly we'd be able to package
On Mon, 18 Jul 2016 09:02:08 +1000 Ben Finney wrote:
> On 17-Jul-2016, Uoti Urpala wrote:
> > If you want to argue "upstream convenience" as a reason for the
> > second,
>
> Maybe if that were the only justification offered. That's not the case
> though.
&
On Mon, 18 Jul 2016 11:15:59 +0200 Philip Hands wrote:
> Uoti Urpala writes:
>
> > In what sense couldn't everyone modify the concatenated form?
>
> Perhaps if I frame my question from:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978#90
>
>
mplayer2
> Version : 2.0beta1
> Upstream Author : Uoti Urpala pp1.inet.fi>
> * URL : http://www.mplayer2.org/
> * License : GPL
> Programming Lang: C
> Description : next generation movie player for Unix-like systems
>
>MPlayer plays most MPE
On Thu, 24 May 2018 09:14:34 -0500 Phil Miller wrote:
> At present, this doesn't hurt functionality of a default configuration system,
> but it would prevent someone using the nvidia driver from enabling the
> kernel's
> usercopy protections. In future kernel releases where those protections are
On Tue, 16 Oct 2018 11:32:34 -0400 "Ryan C. Gordon" wrote:
>
> Can someone humor me and make a quick change to Neverball for me?
>
> In neverball/share/fs_physfs.c, there are three calls to
> PHYSFS_setBuffer(). Just comment them out and rebuild Neverball with
> PhysicsFS support and see if th
On Sun, 24 Feb 2019 14:16:03 +0100 Johannes Schauer wrote:
> I found that some important arguments are still missing. A recent mail by
> Guillem [1] nicely summarizes also many of my own thoughts. I'm going to paste
> the relevant content into this mail for convenience of the reader:
I think thos
Package: grub-pc
Version: 2.02+dfsg1-11
Severity: normal
>From logs, the following events seem to have happened:
grub-pc was upgraded under unattended-upgrades. This was when the udev
bug changed disk path. Grub-pc appears to have tried installing in the
old nonexistent path; I assume this part d
On Thu, 22 Oct 2020 11:47:44 +0200 Thomas Schwinge wrote:
> ..., that is, SIGSEGV, supposedly when bash tries to expand the last path
> component glob ('*'):
I also encountered this bug. After installing bash-dbgsym, gdb says it
crashes at glob.c line 487 in wdequote_pathname(). The immediate cau
On Wed, 07 Feb 2018 01:12:57 +0100 Andreas Beckmann wrote:
> File "/usr/share/lyx/scripts/TeXFiles.py", line 112
> print(root.replace('\\', '/') + '/' + file, file=out)
> ^
> SyntaxError: invalid syntax
That error is a bit surprising as it
Package: jupyter-notebook
Version: 6.0.0-1
Severity: normal
The package now seems to enable the jupyter-notebook.service user unit
by default (I think this has changed?). Due to how Debian gdm3 is
packaged, this means also starting a server for the Debian-gdm user.
Since the service listens on a
Package: neverball
Version: 1.6.0-8
Severity: important
Neverball automatically saves a replay of the latest run on disk while
playing. In the Debian package, the binary constantly calls fsync() on
this file, which very seriously degrades performance. If the issue is
not obvious when trying to rep
On Sun, 2018-08-26 at 17:59 +0200, Markus Koschany wrote:
> On Thu, 23 Aug 2018 17:56:01 +0300 Uoti Urpala
> wrote:
> > Neverball automatically saves a replay of the latest run on disk while
> > playing. In the Debian package, the binary constantly calls fsync() on
> &g
On Mon, 2018-08-27 at 23:13 +0200, Markus Koschany wrote:
> Am 27.08.2018 um 03:36 schrieb Uoti Urpala:
> > Neverball is broken so at least a bug blocked by a physfs bug would be
> > appropriate in any case, and I assume that the easiest way to fix the
> > problem would be to
On Wed, 2018-08-29 at 15:27 +0200, Markus Koschany wrote:
> Am 29.08.2018 um 15:08 schrieb Uoti Urpala:
> > If FPS stays sufficiently high that it's not a visible issue, you could
> > try running the binary under strace for example and verify that there
> > are lots of
On Thu, 2018-11-29 at 14:57 +, Debian Bug Tracking System wrote:
>* Add upstream patch 02-fsync.
This patch file is completely broken:
> # Upstream patch to fix a performance problem.
> # Closes: #907429
> # URL: https://hg.icculus.org/icculus/physfs/rev/c17f025e7a92
>
> diff -Naur libph
On Tue, 06 Nov 2018 11:34:18 + Christoph Martin wrote:
>* set a higher limit for the hash stacksize in perl Storable (closes:
> #912695, #912709, #912970, #898090)
Upgrade and reinstall still fail.
On Tue, 06 Nov 2018 11:34:18 + Christoph Martin wrote:
>* set a higher limit for the hash stacksize in perl Storable (closes:
> #912695, #912709, #912970, #898090)
Upgrade and reinstall still fail.
On Wed, 2018-11-07 at 09:25 +0100, Christoph Martin wrote:
> Am 07.11.18 um 00:30 schrieb Uoti Urpala:
> > Upgrade and reinstall still fail.
>
> Please do some tests for me with the new apt-show-versions. I set a
> higher limit in line 271. The default value on amd64 is 8552. I
Package: sagemath
Version: 9.0-4+b1
Severity: normal
It seems the basic sagemath integer objects do not release memory
properly when freed. Quick way to reproduce:
while 1: x=divisors(factorial(15))
running the above line leaks memory at around 100 MB/s order of
magnitude.
A bit longer demonstr
I investigated this more, and came to the conclusion that Sage is
incompatible with libgmp 6.2 due to the following commit:
https://gmplib.org/repo/gmp-6.2/rev/299ec6187305
This invalidates the assumptions Sage's rings/integer.pyx makes about
libgmp internals. The "global_dummy_Integer" object cr
Michael Biebl wrote:
> b/ enabling mDNS functionality globally (i.e. having MulticastDNS=yes
> as default in /etc/systemd/resolved.conf) does not mean it will work
> out of the box. One has to enable it explicitly "per link" as well.
> If you are using networkd, you can achieve that by setting
>
91 matches
Mail list logo
