control: severity -1 important
Downgrading to important this is not RC I should have done this on
previous email.
/Andy
control: tag -1 unreproducible
control: severity -1 important
A clean chroot build does not reproduce this bug pulls in:
libssl1.1 (= 1.1.1b-1)
current build logs suggest this also builds successfully with:
openssl_1.1.1a-1
Suspect that this was a transient bug
/Andy (with help from
Bug reproduces on build tests as of 2019-03-07
Possibly a regression in whatever library this calls in, as these tests
do not appear to have been touched in some time.
Upsteam has sime activity - an a yearly(ish) basis.
This will need more experienced C++ / QT / Archaeologist skills than we
have
I have had a look at this as part of the Cambridge BSP 2019-03-09
I am able to reproduce this 'bug', on multiple architectures the
following is copy/paste from buster on my AMD64 laptop :-p
Simply running the test by hand
Assuming you have a working / reliable resolver / untainted cache then
the
Package: linux-image-4.19.0-1-arm64
Severity: critical
Justification: breaks the whole system
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
upgrading kernel in Buster from 4.18.0-3-arm64 via apt-get dist-upgrade
Ben
I have tested against the following kernels on snapshot.d.o
Pass
4.2.1-1
4.0.0-1
3.16.36-1
Fails
3.16.7-ckt4-3
/Andy
Hi,
it has been a while since there has been any activity against this bug.
it is marked as grave, this means that it is Release Critical for Stretch.
I have just run Cyril's md-mirror-resync-broken-v2.sh script on a
machine running stretch rc1 (Linux debian 4.4.0-2amd64 #1 SMP Debian
4.8.15-2 (2
Hi there,
Back in August *2015* there was a short discussion regarding removing
sonsord from lm-sensors as a result of this bug.
Because it is marked as GRAVE, this bug is release critical for Stretch.
Is this really a grave bug, should it be down graded? Can Sensord be
removed? Is there anoth
On 29/01/17 13:18, Paul Wise wrote:
> On Sun, Jan 29, 2017 at 7:35 PM, Andy Simpkins wrote:
>
>> It is our belief that this is sufficient; that the package FontForge,
>> and type 1 fonts generated by this package are now DFSG compliant
>> because Apache 2.0 is GPL
Hi Anibal,
It has been a long time since we last caught up!
As part of the Cambridge BSP this weekend [1] I have been looking at
lisence violations such as the one in this bug that is marked as RC.
It is my understanding that there is no problems with the "All rights
reserved" statement included
Hi Ted,
I am currently sat at the Cambridge BSP looking at Debian RC bugs [1].
Looking at this bug report we believe that on balance the best course of
action would be to remove lib/et/test_cases/imap_err.et from e2fsprogs.
As you have offered to do this in your capacity as "upstream" [2]
may we
Hi Karen,
At the Cambridge BSP (Jan 27/28 2017) we have been looking at the
following bugs pertaining to non-DFSG compliance with fonts embedded
with non-free code:
* http://bugs.debian.org/665334
opened 23 Mar 2012, last update 01 Aug 2016 modulo spam
* http://bugs.debian.org/694320
o
As part of cambridge bsp we have investigated this bug.
The suggested patch does not actuly fix the bug (the -B option still
includes /usr/share/info/dir.gz) // info and is not just limited to arm64
Problem was caused by build rules missing build-arch target, and
therefore not applying patched du
Hi Salvo,
I am looking back though open bugs at the moment and see that the mail
traffic for the bug you reported stopped back at the end of October,
with people suggesting that this has now gone away.
Have you seen this?
Have recent updates fixed the problem for you?
If so can you please respo
Ran into this problem today at the cambridge BSP when performing a
dist-upgrade from squeeze.
again the reported problem was:
E: Could not perform immediate configuration on 'phonon-backend-vlc'. Please
see man 5 apt.conf under APT::Immediate-Configure for details.
I performed
15 matches
Mail list logo
