Bug#935787: general: RaLink RT2870 usb wifi cannot connect (worked on Jessie)

2019-08-26 Thread Geoffrey Ferrari
Package: general
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   I recently did a fresh upgrade from Debian 9 Stable to Debian 10 Stable. On 
Debian 9, my usb wifi (D-Link System DWA-140 RangeBooster N Adapter(rev.B1) 
[Ralink RT2870]) worked fine after installing firmware-misc-nonfree. However, 
on Debian 10 it can no longer make a connection to my wifi router. The system 
log reports that authentication and associated are successful, but the 
connection attempt times out report 'ip-config-unavailable'.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Package firmware-misc-nonfree was installed.
 
 I amended /etc/NetworkManager/NetworkManager.conf to add the lines:

 [device]
 scan-rand-mac-address=no

   * What was the outcome of this action?
   The above actions did not solve the problem - the same error message 
occurred.
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 10.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled



Bug#911940: "apt-purge postgresql-10" on debian-testing appears to delete the postgresql data directory

2018-11-04 Thread Geoffrey Ferrari
To add further weight to my previous attempt to persuade whoever is in
charge of this that this behaviour is currently incorrect, I quote from the
man pages for apt-get purge (same as for apt purge):

Removing a package removes all packaged data, but leaves usually small
(modified) user configuration files behind, in case the remove was an
accident. Just issuing an installation request for the accidentally removed
package will restore its function as before in that case. On the other hand
you can get rid of these leftovers by calling purge even on already removed
packages. Note that this does not affect any data or configuration stored
in your home directory.


I accept that this is not 100% clear in the case of postgres where user
created data is stored in /var/lib. On the other hand, the behaviour
whereby purge deletes every database the user has created certainly does
not amount to removing "usually small configuration files".

What is supposed to be the good reason for ensuring that purge does remove
the user's databases?


On Mon, 29 Oct 2018 at 14:01, Geoffrey Ferrari <
geoffrey.ferr...@oriel.oxon.org> wrote:

> Hi Christoph,
>
> Thanks for replying.
>
> I think this is deeply mistaken, as well as dangerous and irresponsible.
>
> Yes, I expect apt-purge to remove all system-level traces of a package -
> but never user-level data.
>
> If I apt-purge libreoffice, should I expect it to delete all my office
> files? If I apt-purge emacs, should I expect it to delete every file I've
> ever edited?
>
> Who do we need to speak to in order to persuade them to change this
> behaviour?
>
> (FWIW, I haven't lost any important data - thank goodness. But I think
> this is such a bad decision that it's worth making a fuss over it before
> someone does lose something important.)
>
> Kind regards,
>
> Geoffrey
>
> On Mon, 29 Oct 2018 at 12:40, Christoph Berg  wrote:
>
>> Re: Geoffrey Ferrari 2018-10-26 > ahbmpktaxa...@mail.gmail.com>
>> > Yesterday I ran: sudo apt-purge postgresql-10*
>> >
>> > This appears to have deleted my postgresql-10 data directory in
>> > /var/lib/postgresql/10...
>> >
>> > Is this expected behaviour? It seems highly undesirable.
>>
>> Hi Geoffrey,
>>
>> the difference between "apt remove" and "apt purge" is that the latter
>> is supposed to remove all traces of the package on the system, so it
>> works as intended.
>>
>> As this question keeps popping up from time to time, I'll see if we
>> can add a debconf question about removing the PGDATA directory on
>> purge. (Chances are it isn't possible, though.)
>>
>> Christoph
>>
>


Bug#911940: "apt-purge postgresql-10" on debian-testing appears to delete the postgresql data directory

2018-10-29 Thread Geoffrey Ferrari
Hi Christoph,

Thanks for replying.

I think this is deeply mistaken, as well as dangerous and irresponsible.

Yes, I expect apt-purge to remove all system-level traces of a package -
but never user-level data.

If I apt-purge libreoffice, should I expect it to delete all my office
files? If I apt-purge emacs, should I expect it to delete every file I've
ever edited?

Who do we need to speak to in order to persuade them to change this
behaviour?

(FWIW, I haven't lost any important data - thank goodness. But I think this
is such a bad decision that it's worth making a fuss over it before someone
does lose something important.)

Kind regards,

Geoffrey

On Mon, 29 Oct 2018 at 12:40, Christoph Berg  wrote:

> Re: Geoffrey Ferrari 2018-10-26  ahbmpktaxa...@mail.gmail.com>
> > Yesterday I ran: sudo apt-purge postgresql-10*
> >
> > This appears to have deleted my postgresql-10 data directory in
> > /var/lib/postgresql/10...
> >
> > Is this expected behaviour? It seems highly undesirable.
>
> Hi Geoffrey,
>
> the difference between "apt remove" and "apt purge" is that the latter
> is supposed to remove all traces of the package on the system, so it
> works as intended.
>
> As this question keeps popping up from time to time, I'll see if we
> can add a debconf question about removing the PGDATA directory on
> purge. (Chances are it isn't possible, though.)
>
> Christoph
>


Bug#911940: "apt-purge postgresql-10" on debian-testing appears to delete the postgresql data directory

2018-10-26 Thread Geoffrey Ferrari
Package: postgresql-10
Version: 10.5-2.pgdg90+1
OS: Debian Stable

Yesterday I ran: sudo apt-purge postgresql-10*

This appears to have deleted my postgresql-10 data directory in
/var/lib/postgresql/10...

Is this expected behaviour? It seems highly undesirable.

Geoff Ferrari


Bug#886401: evince: Evince does not start: Error in `evince': double free or corruption (fasttop)

2018-01-05 Thread Geoffrey Ferrari
Hi Jason,

Sorry, I think that's beyond my expertise - there is no installable
package for evince-dbgsym and several in the debug repository and I'm
not competent enough to build these packages from scratch.

Geoffrey

On 5 January 2018 at 15:57, Jason Crain <ja...@inspiresomeone.us> wrote:
> Control: tags -1 + moreinfo
>
> On Fri, Jan 05, 2018 at 11:48:21AM +, Geoffrey Ferrari wrote:
>>* What led up to the situation?
>> Trying to run evince from command line or from gnome desktop, without or
>> without a pdf file to view.
>>
>>* What exactly did you do (or not do) that was effective (or
>>  ineffective)?
>> Tried executing "evince" from command line with no pdf file specified.
>>* What was the outcome of this action?
>>
>> The following error message is reported:
>> *** Error in `evince': double free or corruption (fasttop): 
>> 0x55884b31a380
>> ***
>
> Can you provide a backtrace with debug symbols?  You'll need to install
> at least evince-dbgsym, libevdocument3-4-dbgsym, libevview3-3-dbgsym,
> libglib2.0-0-dbgsym, libgtk-3-0-dbgsym, libpango-1.0-0-dbgsym,
> libpangoft2-1.0-0-dbgsym, libpangocairo-1.0-0-dbgsym,
> libfontconfig1-dbgsym, and libexpat1-dbgsym.
>
> https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
> describes how to enable the repo for the dbgsym packages.



Bug#886401: evince: Evince does not start: Error in `evince': double free or corruption (fasttop)

2018-01-05 Thread Geoffrey Ferrari
Package: evince
Version: 3.26.0-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
Trying to run evince from command line or from gnome desktop, without or
without a pdf file to view.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Tried executing "evince" from command line with no pdf file specified.
   * What was the outcome of this action?

The following error message is reported:
*** Error in `evince': double free or corruption (fasttop): 0x55884b31a380
***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x722fb)[0x7fe7fcdcf2fb]
/lib/x86_64-linux-gnu/libc.so.6(+0x7895e)[0x7fe7fcdd595e]
/lib/x86_64-linux-gnu/libc.so.6(+0x791be)[0x7fe7fcdd61be]
/usr/lib/x86_64-linux-
gnu/libfontconfig.so.1(FcConfigParseAndLoad+0x13a)[0x7fe7f9ccdd4a]
/usr/lib/x86_64-linux-gnu/libfontconfig.so.1(+0x2415e)[0x7fe7f9cce15e]
/lib/x86_64-linux-gnu/libexpat.so.1(+0xade8)[0x7fe7f6550de8]
/lib/x86_64-linux-gnu/libexpat.so.1(+0xbbbc)[0x7fe7f6551bbc]
/lib/x86_64-linux-gnu/libexpat.so.1(+0x9803)[0x7fe7f654f803]
/lib/x86_64-linux-gnu/libexpat.so.1(+0xa4c5)[0x7fe7f65504c5]
/lib/x86_64-linux-gnu/libexpat.so.1(XML_ParseBuffer+0x7d)[0x7fe7f655407d]
/usr/lib/x86_64-linux-gnu/libfontconfig.so.1(+0x23b43)[0x7fe7f9ccdb43]
/usr/lib/x86_64-linux-
gnu/libfontconfig.so.1(FcConfigParseAndLoad+0x366)[0x7fe7f9ccdf76]
/usr/lib/x86_64-linux-
gnu/libfontconfig.so.1(FcConfigParseAndLoad+0x3d8)[0x7fe7f9ccdfe8]
/usr/lib/x86_64-linux-gnu/libfontconfig.so.1(+0x2415e)[0x7fe7f9cce15e]
/lib/x86_64-linux-gnu/libexpat.so.1(+0xade8)[0x7fe7f6550de8]
/lib/x86_64-linux-gnu/libexpat.so.1(+0xbbbc)[0x7fe7f6551bbc]
/lib/x86_64-linux-gnu/libexpat.so.1(+0x9803)[0x7fe7f654f803]
/lib/x86_64-linux-gnu/libexpat.so.1(+0xa4c5)[0x7fe7f65504c5]
/lib/x86_64-linux-gnu/libexpat.so.1(XML_ParseBuffer+0x7d)[0x7fe7f655407d]
/usr/lib/x86_64-linux-gnu/libfontconfig.so.1(+0x23b43)[0x7fe7f9ccdb43]
/usr/lib/x86_64-linux-
gnu/libfontconfig.so.1(FcConfigParseAndLoad+0x366)[0x7fe7f9ccdf76]
/usr/lib/x86_64-linux-gnu/libfontconfig.so.1(+0x16d34)[0x7fe7f9cc0d34]
/usr/lib/x86_64-linux-gnu/libfontconfig.so.1(+0x16f86)[0x7fe7f9cc0f86]
/usr/lib/x86_64-linux-gnu/libfontconfig.so.1(+0xaa57)[0x7fe7f9cb4a57]
/usr/lib/x86_64-linux-
gnu/libfontconfig.so.1(FcConfigSubstituteWithPat+0xa15)[0x7fe7f9cb6ae5]
/usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0(+0x9728)[0x7fe7feaf6728]
/usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0(+0xa562)[0x7fe7f9ef9562]
/usr/lib/x86_64-linux-gnu/libpango-1.0.so.0(+0x17a67)[0x7fe7fe8b7a67]
/usr/lib/x86_64-linux-
gnu/libpango-1.0.so.0(pango_itemize_with_base_dir+0xa0)[0x7fe7fe8b90c0]
/usr/lib/x86_64-linux-gnu/libpango-1.0.so.0(+0x2175d)[0x7fe7fe8c175d]
/usr/lib/x86_64-linux-
gnu/libpango-1.0.so.0(pango_layout_get_unknown_glyphs_count+0x32)[0x7fe7fe8c2b42]
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0(+0x1a3aaa)[0x7fe7ff195aaa]
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0(+0x1a3b18)[0x7fe7ff195b18]
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0(+0x1a3c88)[0x7fe7ff195c88]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_type_create_instance+0x1e5)[0x7fe7fd979735]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x155d8)[0x7fe7fd95a5d8]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_object_new_with_properties+0x2f5)[0x7fe7fd95bd75]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_object_new+0xc1)[0x7fe7fd95c7f1]
evince(+0x4dd15)[0x558849189d15]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_type_create_instance+0x1e5)[0x7fe7fd979735]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x155d8)[0x7fe7fd95a5d8]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_object_new_with_properties+0x2f5)[0x7fe7fd95bd75]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_object_new+0xc1)[0x7fe7fd95c7f1]
evince(+0x2cfe0)[0x558849168fe0]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x15790)[0x7fe7fd95a790]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_object_new_valist+0x3d0)[0x7fe7fd95c450]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_object_new+0x99)[0x7fe7fd95c7c9]
evince(+0x2d4f2)[0x5588491694f2]
evince(+0x39ba3)[0x558849175ba3]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_type_create_instance+0x1e5)[0x7fe7fd979735]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x155d8)[0x7fe7fd95a5d8]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_object_new_valist+0x3d0)[0x7fe7fd95c450]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_object_new+0x99)[0x7fe7fd95c7c9]
evince(+0x3ba7b)[0x558849177a7b]
evince(+0x24015)[0x558849160015]
evince(+0x1fc44)[0x55884915bc44]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fe7fcd7d561]
evince(+0x1fdaa)[0x55884915bdaa]
=== Memory map: 
55884913c000-5588491a3000 r-xp  08:01 1060629
/usr/bin/evince
5588493a2000-5588493a7000 r--p 00066000 08:01 1060629
/usr/bin/evince
5588493a7000-5588493a8000 rw-p 0006b000 08:01 1060629
/usr/bin/evince
55884aff-55884b32f000 

Bug#687390: notmuch: Quoted text inserted incorrectly by notmuch-search-reply-to-thread-sender

2012-09-12 Thread Geoffrey Ferrari
Package: notmuch
Version: 0.13.2-1
Severity: normal

Dear Maintainer,

When I reply to a message in notmuch, the automatically composed reply buffer 
takes the following form:

HEADERS
QUOTED TEXT
--text follows this line--
(Position of cursor)
SIGNATURE

However, when I use exactly the same emacs and notmuch setup on Ubuntu, it 
takes the following form:

HEADERS
--text follows this line--
(Position of cursor)
QUOTED TEXT
SIGNATURE

The setup with notmuch under Debian seems to me to be incorrect for two 
reasons: (1) the debian setup puts the quoted text before the --text follows 
this line-- divider; (2) the cursor should be positioned before the quoted 
text, not after. (I think there's really only one problem here though - the 
position of the quoted text).

This problem happens in emacs23 from debian testing and emacs24 from debian 
unstable.

Best wishes,

Geoffrey Ferrari


*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these lines ***


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages notmuch depends on:
ii  libc6   2.13-35
ii  libglib2.0-02.32.3-1
ii  libgmime-2.6-0  2.6.10-1
ii  libnotmuch3 0.13.2-1
ii  libtalloc2  2.0.7+git20120207-1

Versions of packages notmuch recommends:
ii  gnupg-agent2.0.19-1
ii  notmuch-emacs  0.13.2-1

notmuch suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org