Package: firefox-esr
Version: 60.6.1esr-1~deb9u1
Severity: grave
Tags: upstream
Justification: causes non-serious data loss
>From Bugzilla 1548973
https://bugzilla.mozilla.org/show_bug.cgi?id=1548973
Steps to reproduce:
Wait until it's past midnight on 2019-05-04 UTC.
Actual results:
All
On Wed, Apr 24, 2019 at 05:37:24PM +0100, Steve McIntyre wrote:
>On Wed, Apr 24, 2019 at 05:26:00PM +0100, Steve McIntyre wrote:
>>Source: grub2
>>Version: 2.02+dfsg1-16
>>Severity: serious
>>Tags: security
>>
>>In discussion with upstream EFI and arm64 folks, it's become clear
>>that in SB mode
tags 926182 + patch
thanks
Hi.
/usr/bin/guile uses alternatives system and the real binary is under
/usr/lib, as well as providing /usr/bin/guile-2.2 as a symlink.
My patch gives the same treatment for the binaries in guile-2.2-dev.
diff -Nru guile-2.2-2.2.4+1/debian/changelog
Processing commands for cont...@bugs.debian.org:
> tags 926182 + patch
Bug #926182 [guile-2.2-dev] guile-2.2-dev: autoreconf'ed scripts using guile.m4
cannot find guild & guile-config/tools
Bug #926676 [guile-2.2-dev] guile-2.2-dev: Missing binary symlink `guild-2.2`
(and others)
Added tag(s)
Package: libwebkit2gtk-4.0-37
Version: 2.24.1-1
Severity: grave
Dear Maintainer,
I find a problem of libwebkit2gtk-4.0-37, which doesn't show all white
spaces in rendering text plain document under the locales except for
"C" locale.
I checked below,
* Invoke
What about starting a xvfb during the build?
Does it fix the issue?
S
Le 03/05/2019 à 16:50, Alexis Murzeau a écrit :
Hi,
Indeed, I tried in a virtual machine:
- install scilab
- run `LANG=en_US.UTF-8 LC_ALL=C SCI_DISABLE_TK=1
SCI_JAVA_ENABLE_HEADLESS=1
Processing control commands:
> severity -1 important
Bug #928390 [virtualbox-ext-pack] unable to remove/upgrade where installed
version is not operational
Severity set to 'important' from 'grave'
--
928390: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928390
Debian Bug Tracking System
control: severity -1 important
On Fri, 3 May 2019 16:12:40 +0200 Eduard Bloch wrote:
> Control: retitle 928390 unable to remove/upgrade where installed version is
> not operational
> Control: severity 928390 grave
please don't play the severity game, thanks.
VBoxManage: error: The installer
Hi,
Antoine Beaupré:
> On 2019-05-03 17:15:59, intrigeri wrote:
>>> 1. maintain through backports (seems to have been the option taken for
>>> stretch)
>>
>> That might be viable if the AppArmor profiles are disabled by default.
> Why would we disable apparmor profiles?
See the "2." part
Control: severity -1 important
Control: reassign -1 ruby-bootsnap
On Tue, 23 Apr 2019 14:11:09 +0200 Gianfranco Costamagna
wrote:
> Source: rails
> Version: 2:5.2.2+dfsg-6
> Severity: important
> tags: patch
>
> Hello, as said, ruby+bootsnap is completely broken on at least armhf platform.
>
>
Processing control commands:
> severity -1 important
Bug #927796 [src:rails] rails: please disable bootsnap on at least armhf
Severity set to 'important' from 'serious'
> reassign -1 ruby-bootsnap
Bug #927796 [src:rails] rails: please disable bootsnap on at least armhf
Bug reassigned from package
Your message dated Fri, 03 May 2019 15:48:28 +
with message-id
and subject line Bug#928140: fixed in pygalmesh 0.3.1-2
has caused the Debian Bug report #928140,
regarding pygalmesh: FTBFS on 32-bit architectures: virtual memory exhausted
to be marked as done.
This means that you claim that
On 2019-05-03 17:15:59, intrigeri wrote:
> Hi,
>
> (slightly reordering quoted text)
>
> Antoine Beaupre:
>> So what will be the way forward for Debian users in buster?
>
>> TL;DR: TBL in backports or install by hand from TPO, AFAIK.
>
> Agreed.
>
>> What does Tails do with this?
>
> Tails only
Control: tags 925395 + patch
Control: tags 925395 + pending
Control: tags 926091 + patch
Control: tags 926091 + pending
Dear maintainer,
I've prepared an NMU for imagemagick (versioned as 8:6.9.10.23+dfsg-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it
Hi,
On Fri, May 3, 2019 at 2:14 PM Salvatore Bonaccorso wrote:
> Not yet decided, and might need imput from stable release managers as
> well, but the issue might be worth fixing before a next point release
> already via stretch-updates and a SUA.
Agreed.
> I have already cherry-picked the
Processing control commands:
> tags 925395 + patch
Bug #925395 [src:imagemagick] imagemagick: CVE-2019-9956
Ignoring request to alter tags of bug #925395 to the same tags previously set
> tags 925395 + pending
Bug #925395 [src:imagemagick] imagemagick: CVE-2019-9956
Ignoring request to alter tags
Processing control commands:
> tags 925395 + patch
Bug #925395 [src:imagemagick] imagemagick: CVE-2019-9956
Added tag(s) patch.
> tags 925395 + pending
Bug #925395 [src:imagemagick] imagemagick: CVE-2019-9956
Added tag(s) pending.
> tags 926091 + patch
Bug #926091 [src:imagemagick] imagemagick:
Hi,
(slightly reordering quoted text)
Antoine Beaupre:
> So what will be the way forward for Debian users in buster?
> TL;DR: TBL in backports or install by hand from TPO, AFAIK.
Agreed.
> What does Tails do with this?
Tails only uses the torbrowser-launcher source package as a way to get
Source: mariadb-10.3
Version: 1:10.3.14-1
Severity: grave
Tags: security upstream
Justification: user security hole
Hi,
The following vulnerabilities were published for mariadb-10.3.
CVE-2019-2614[0]:
| Vulnerability in the MySQL Server component of Oracle MySQL
| (subcomponent: Server:
Hi,
Indeed, I tried in a virtual machine:
- install scilab
- run `LANG=en_US.UTF-8 LC_ALL=C SCI_DISABLE_TK=1
SCI_JAVA_ENABLE_HEADLESS=1 _JAVA_OPTIONS='-Djava.awt.headless=true'
HOME=/tmp scilab-adv-cli -noatomsautoload -nb -l en_US -nouserstartup -e
"try xmltojar([],[],'en_US');catch
Ansgar wrote:
On Fri, 2019-05-03 at 19:49 +0800, Drew Parsons wrote:
> The first -g is the problem (in "-DNDEBUG -g -fwrapv -O2 -Wall").
Not sure about setup.py, but `-g0` (after `-g`) should also disable
debug information:
+---
| Level 0 produces no debug information at all. Thus, -g0
Control: retitle 928390 unable to remove/upgrade where installed version is not
operational
Control: severity 928390 grave
Even worse:
The following packages will be REMOVED:
virtualbox-ext-pack
0 upgraded, 0 newly installed, 1 to remove and 1062 not upgraded.
3 not fully installed or
Processing control commands:
> retitle 928390 unable to remove/upgrade where installed version is not
> operational
Bug #928390 [virtualbox-ext-pack] unable to upgrade if previous version was not
operational
Changed Bug title to 'unable to remove/upgrade where installed version is not
Package: virtualbox-ext-pack
Version: 6.0.6-1
Severity: serious
Just what the subject says. Tries to upgrade from 6.0.4-1, and fails.
What it's doing there? No idea, looks like it tries to do some checks
but stumbles on the results if they are not what it has expected.
The recommendation to
On Sat, Mar 30, 2019 at 07:14:38PM +0100, intrig...@debian.org wrote:
> Source: torbrowser-launcher
> Version: 0.3.1-2
> Severity: serious
>
> Hi,
>
> for basically the same reasons that made us not include
> torbrowser-launcher in Stretch, IMO it should not be part of Buster
> either:
[...all
Your message dated Fri, 03 May 2019 13:04:23 +
with message-id
and subject line Bug#925986: fixed in jruby 9.1.17.0-2.1
has caused the Debian Bug report #925986,
regarding CVE-2018-173: directory Traversal vulnerability in
install_location
to be marked as done.
This means that you claim
Hi Jochen,
Am 03.05.19 um 13:47 schrieb Jochen Sprickerhof:
[...]
> This is due to libnb-javaparser-java which is still on the jdk-9
> version.
[...]
> So one way would be to get this packaged (maybe rename nb-javac-9-*.jar
> to nb-javac-11-*.jar) and convince the release team to include
Hi Romain,
On Thu, May 02, 2019 at 04:55:25PM +, Romain Francoise wrote:
> v4.9.172 is out with the offending commit reverted. Is there a stretch
> update with the same revert planned soon to address this? And via which
> suite?
Not yet decided, and might need imput from stable release
Hi Markus,
* Jochen Sprickerhof [2019-05-02 23:05]:
The other option is to fix the nb-javac-9-(api|impl).jar. Starting the
upstream version of netbeans results in the same error for nb-javac
and let's you download
~/.netbeans/10.0/modules/ext/nb-javac-(api|impl).jar. Placing those in
Dear Debian Python community,
how does one control or override the default flags used by setup.py
(setuptools module) when compiling a C extension for a python module?
The intention is to switch off -g in pygalmesh, because of memory
constraints on 32 bit systems when compiling against CGAL,
On 2019-05-03 16:54, Nico Schlömer wrote:
cf.
https://stackoverflow.com/questions/55801777/set-compile-flags-when-installing-python-c-project
Disturbingly bad help these people are giving us :( Do they ever try
the "solutions" they're providing?
Even the sysconfig version, all it does is
Your message dated Fri, 03 May 2019 10:03:40 +
with message-id
and subject line Bug#927810: fixed in python-molotov 1.6-4
has caused the Debian Bug report #927810,
regarding python-molotov: FTBFS randomly (failing tests)
to be marked as done.
This means that you claim that the problem has
cf.
https://stackoverflow.com/questions/55801777/set-compile-flags-when-installing-python-c-project
On Fri, May 3, 2019 at 10:29 AM Drew Parsons wrote:
>
> On 2019-05-03 16:24, Nico Schlömer wrote:
> >> Do you know how to control it?
> >
> > I'd been looking at this once, to no avail. Locally
Your message dated Fri, 03 May 2019 08:34:07 +
with message-id
and subject line Bug#924096: fixed in suricata 1:4.1.4-2
has caused the Debian Bug report #924096,
regarding suricata: fails to upgrade from 'testing' - trying to overwrite
/usr/bin/suricata-update
to be marked as done.
This
On 2019-05-03 16:24, Nico Schlömer wrote:
Do you know how to control it?
I'd been looking at this once, to no avail. Locally I just use
CC=clang++ now.
It's very odd that they make it difficult to deal with.
The offending definition looks like OPT in
> Do you know how to control it?
I'd been looking at this once, to no avail. Locally I just use CC=clang++ now.
On Fri, May 3, 2019 at 10:11 AM Drew Parsons wrote:
>
> On 2019-04-29 15:49, Nico Schlömer wrote:
> >> No easy way around it.
> >
> > Indeed.
> >
> >> Building with -g -O1 (or -O2
On Fri, 3 May 2019 01:22:37 +0200 Andreas Beckmann wrote:
> On 2019-05-02 18:41, guillaume raffy wrote:
> > Indeed, on our server, "linux-headers-4.9.0-8-all-amd64" was
installed but not "linux-headers-amd64". I believe that if the package
"linux-headers-amd64" was installed in the first
On 2019-04-29 15:49, Nico Schlömer wrote:
No easy way around it.
Indeed.
Building with -g -O1 (or -O2 without -g) helps mshr, we can test if it
helps pygalmesh too.
Removing `-g` almost certainly improves things. Using clang++ instead
of c++ also helps.
I can remove Debian's -g flag
tag 927152 pending
tag 928110 pending
thanks
Hi,
https://salsa.debian.org/games-team/teeworlds/merge_requests/1/diffs
Not yet uploaded, I will do it later, excepted if someone is faster :-).
Best,
Dylan
Processing commands for cont...@bugs.debian.org:
> tag 927152 pending
Bug #927152 [teeworlds] teeworlds: CVE-2019-10877 CVE-2019-10878 CVE-2019-10879
Added tag(s) pending.
> tag 928110 pending
Bug #928110 [teeworlds-server] Teeworlds server fails to start because of
missing directory
Added
40 matches
Mail list logo
