On 30/08/2020 13:37, Richard Kettlewell wrote:
> On 30/08/2020 13:22, Salvatore Bonaccorso wrote:
>> Hi Richard,
>>>> Would you be able to test 4.19.142?
>>>
>>> If you can give me a route to getting .deb files for that version then
>>>
On 30/08/2020 13:22, Salvatore Bonaccorso wrote:
> Hi Richard,
>>> Would you be able to test 4.19.142?
>>
>> If you can give me a route to getting .deb files for that version then
>> sure - a download or a pointer to instructions.
>
> *unofficial* and *temporary* builds for that version can be fou
On 29/08/2020 15:36, Salvatore Bonaccorso wrote:
> Hi Richard,
>
> On Sat, Aug 22, 2020 at 12:58:47PM +0100, Richard Kettlewell wrote:
>> I've had further crashes under 4.19.0-10-amd64 on a second machine.
>> Again, after reverting to 4.19.0-9-amd64 this second mac
Package: src:linux
Version: 4.19.132-1
Severity: critical
Justification: breaks the whole system
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
Upgraded from 4.19.0-9 to 4.19.0-10.
* What exactly did you do
On 2018-07-21 13:56, Matthew Vernon wrote:
> On 21/07/18 13:22, Richard Kettlewell wrote:
>> In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897852:
>>> I think this is a pangomm bug - see the errors below about incompatible
>>> function type casts.
>>
>>
In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897852:
> I think this is a pangomm bug - see the errors below about incompatible
> function type casts.
To me it looks like a sigc++ bug, and one that is being addressed upstream:
https://github.com/libsigcplusplus/libsigcplusplus/issues/1
t
On 2018-04-07 07:40, Salvatore Bonaccorso wrote:
> Hi Richard,
>
> On Fri, Apr 06, 2018 at 03:44:51PM +0100, Richard Kettlewell wrote:
>> Hi,
>>
>> There's an additional issue, which is that the ability to open arbitrary
>> caller-chosen files represents a
Hi,
There's an additional issue, which is that the ability to open arbitrary
caller-chosen files represents at least an information leak, and maybe
more serious. See the comments starting at:
https://github.com/johnath/beep/issues/11#issuecomment-379215473
ttfn/rjk
This is fixed on master, and will be in the next release.
https://github.com/ewxrjk/rsbackup/commit/2faba794de0d08487d280d85870d294339a138f4
The change is also available on the 3.x branch.
https://github.com/ewxrjk/rsbackup/tree/3.x
I don't plan to make an upstream release just for this issue.
Either the current release (3.1) or
https://github.com/ewxrjk/rsbackup/commit/406aade24a2fabf5806a8b5452fba34e020b893a
address this.
ttfn/rjk
Package: inn2
Severity: critical
As subject. Having done the following, over a period of time:
install inn2
discover it doesn't work at all (bug 655748)
remove inn2
install inn2
purge inn2
The result is that the active, history and newsgroups files are deleted
without warning.
Package: cvs
Version: 1:1.12.13-12+squeeze1
Severity: serious
$ dpkg -S /usr/share/info/dir.gz
cvs: /usr/share/info/dir.gz
$ dpkg --contents
/var/cache/apt/archives/cvs_1%3a1.12.13-12+squeeze1_amd64.deb |grep dir
-rw-r--r-- root/root 472 2012-02-09 11:52 ./usr/share/info/dir.gz
The pract
Vincent Lefevre wrote:
I have no problems with:
[..]
This bug should probably be closed (or reassigned, if the problem
is with some sources).
Evidently someone has uploaded gcc-4.4-doc since I reported the bug l-)
I agree that the bug can be closed.
ttfn/rjk
--
To UNSUBSCRIBE, email t
Thomas Hood wrote:
iface eth0 inet static
address 172.17.207.12
gateway 172.17.207.1
netmask 255.255.255.0
I'll assume that interface eth0 is configured using the "ifup" command.
Add this line to the "iface eth0" stanza in /etc/network/interfaces
dns-nameservers 172.17.207.1 172.17.207
Thomas Hood wrote:
Through which network interface can those nameservers be reached? How
is that network interface configured?
eth0 and as below.
$ ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:16:3e:06:f3:14
inet addr:172.17.207.12 Bcast:172.17.207.255 Mask:255.255.255.0
Thomas Hood wrote:
We need to figure out why resolvconf is not functioning correctly on
your system.
Resolvconf writes the resolver configuration file on the basis of
information provided to it. If nothing provides it with nameserver
addresses then it writes an empty resolv.conf file.
What nam
Package: resolvconf
Version: 1.43
Severity: critical
This is from my unstable VM. I did not explicitly install resolvconf,
perhaps apt followed a 'recommends' or something. Essentially all
network operations after this stop working (hence 'Severity: critical')
as resolv.conf had been replace
Steve Langasek writes:
> On Sat, Mar 10, 2007 at 04:45:52PM +0000, Richard Kettlewell wrote:
> > sfere$ type bash
> > bash is hashed (/bin/bash)
> > sfere$ bash -c 'type printf'
> > printf is a shell builtin
> > sfere$ bash -c 'printf
Package: bash
Version: 2.05b-26
Severity: grave
sfere$ type bash
bash is hashed (/bin/bash)
sfere$ bash -c 'type printf'
printf is a shell builtin
sfere$ bash -c 'printf spong' > /dev/full
sfere$ echo $?
0
Compare:
sfere$ /usr/bin/printf spong > /dev/full
/usr/bin/printf: write
19 matches
Mail list logo
