Dear Maintainer,

  would it be possible for aptitude in TUI to catch debtags errors/warnings, instead of let them to mess up the interface ? Specifically, I have a problem where certain old (but still usefull) apt-lists contains non-UTF8 characters. That triggers debtags to report a warning that messes up the TUI. It would be nice if aptitude was able to catch such errors and show them in a red dialog instead.

Thanks,
Pavel

Hi Pavel,

Pavel Reznicek wrote:

Is that APT repository public? If so, please tell us the according
line from sources.list so that we can try to reproduce this.

		Regards, Axel

Hi Pavel,

2015-09-02 15:06 Axel Beckert:

So, as Axel said, could you please tell us about the repository, or tell
a way to reproduce it with some file that you can produce?


Cheers.

2015-10-05 23:32 To Pavel Reznicek:

Closing now, please reopen if you can provide the requested information.

Hi Manuel,

   sorry for the delay. These are the repositories where I experience
the problem:

deb [arch=i386] http://www.rarewares.org/debian/packages/unstable/ ./

deb [arch=i386] http://repository.elivecd.org/ lenny drivers efl elive games main multimedia other ports tests

Each of them containing a single non-UTF8 character in one of the
package descriptions, easily to be found by running:

grep -axvn '.*' /var/lib/apt/lists/*

Best regards,
Pavel

Hi Pavel,

2016-01-08 08:33 Pavel Reznicek:

Thanks for the further info.

I cannot reproduce it with aptitude 0.7.5, en_GB.UTF-8 and konsole or
xterm, these characters simply show as a question mark '?' (the name of
the developer) and '®' (for "Registered (R)") in my system.

How/when does the errors show, when viewing the package information
screen, or with other operations?


Cheers.

Hi,

The error messages appears after running "Update package list" from the
aptitude ncruses gui. Attached is a screenshot.

I am using this locale settings:

LANG=en_US.UTF-8
LANGUAGE=''
LC_CTYPE=cs_CZ.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8

Best regards,
Pavel

@ APT deities: could you please have a look at the bug report and tell
      	       me your opinion?


Hi,

2016-01-10 16:56 Pavel Reznicek:

Oh, I see, I can reproduce it now.  It happens the same with "apt-get
update" (see below).

The problem seems to be that the in the function RunScripts() from
libapt, when executing debtags (it has to be installed on the system),
the output of the program doesn't get silenced/captured in any way, just
printed to the terminal as it is.

I don't know if the APT team can or will want to change this behaviour
(to add this output to the apt error mechanism, for example).  It
doesn't seem to be a big problem for apt, not having curses interfaces,
but this might affect other users of the library.

I am not sure if we can do much about this from aptitude's side,
otherwise.


  # apt-get update
  Get:1 http://repository.elivecd.org lenny InRelease [16.9 kB]
  Ign:4 http://www.rarewares.org/debian/packages/unstable ./ InRelease
  Ign:1 http://repository.elivecd.org lenny InRelease
  Hit:5 http://repository.elivecd.org lenny/drivers i386 Packages
  Hit:6 http://debug.mirrors.debian.org/debian-debug unstable-debug InRelease
  Hit:7 http://www.rarewares.org/debian/packages/unstable ./ Release
  Hit:8 http://repository.elivecd.org lenny/efl i386 Packages
  Ign:9 http://www.rarewares.org/debian/packages/unstable ./ Release.gpg
  [...]
  Fetched 16.9 kB in 2s (6,067 B/s)
  Traceback (most recent call last):
  File "/usr/bin/debtags", line 699, in <module>
  main()
  File "/usr/bin/debtags", line 693, in main
  sys.exit(action.main(args))
  File "/usr/bin/debtags", line 637, in main
  for pkg, tags in self.tags_from_apt():
  File "/usr/bin/debtags", line 260, in tags_from_apt
  tags = tags_from_apt_record(cand.record)
  File "/usr/lib/python3/dist-packages/apt/package.py", line 592, in record
  return Record(self._records.record)
  UnicodeDecodeError: 'utf-8' codec can't decode byte 0xae in position 681: invalid start byte
  Reading package lists... Done
  W: GPG error: http://repository.elivecd.org lenny InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 1C79A27CD5E81909
  W: The repository 'http://repository.elivecd.org lenny InRelease' is not signed.
  N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use.
  N: See apt-secure(8) manpage for repository creation and user configuration details.
  W: There is no public key available for the following key IDs:
  1C79A27CD5E81909
  W: The repository 'http://www.rarewares.org/debian/packages/unstable ./ Release' is not signed.
  N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use.
  N: See apt-secure(8) manpage for repository creation and user configuration details.


Cheers.

Well, you could.

You could open a pipe for stderr and read from it, and display
that in an aptitude window. That is, do the following:

1. dup(STDERR_FILENO) = stderr_backup
2. pipe(&fds)
3. dup2(fd[1], STDERR_FILENO)

Then you can read any stderr output from fd[0] and display it
inside aptitude.

2016-01-10 21:36 GMT+00:00 Julian Andres Klode <jak@debian.org>:

Yes, something like that would be possible.  It would have to be
repeated for every call to RunScripts() (3 at the moment) or similar
functions, if they exhibit the same problem.

But thinking about it, it looks a bit silly to me to do it in this
way, and RunScripts() itself seems like a better place to centralise
this.

This message doesn't seem like something that front-ends are
interested in, but in other cases it might be.  For example in
synaptic this message gets lost or printed in the terminal if launched
from there (perhaps to .xsession-errors if not).

On the other hand, if the scripts shouldn't print anything under any
circumstance, maybe it's better to close the output FDs.


Cheers.

Vaše kompenzační platba.

Dovoluji si Vás informovat, že Vaše kompenzační platba ze dne 2.5
milionů dolarů schválila centrální banka prostřednictvím víza
ATM karta, která vám umožní vybrat všechny peníze z jakékoli ATM CARD
Stroj kdekoli na světě, autorizovali jsme U B A banku k odeslání
ATM KARTU a PIN KÓD. Kontaktujte reverenda Jamese Edwarda na adrese
edwardrevjamessi@gmail.com, dejte mu vědět, že jste obdrželi tuto zprávu
z kanceláře pana Marka E Johna.

Děkujeme, že jste se řídili tímto pokynem.

Pan Mark E John
Za vaši kompenzační platbu.