[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#969158: marked as done (expeyes: maybe a false positive generated by mail_autoremovals.pl?)

Your message dated Thu, 8 Oct 2020 11:46:30 +0200
with message-id <f3258836-faa8-1827-cf83-d43f6eb82f1c@debian.org>
and subject line Re: expeyes: maybe a false positive generated by mail_autoremovals.pl?
has caused the Debian Bug report #969158,
regarding expeyes: maybe a false positive generated by mail_autoremovals.pl?
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
969158: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969158
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
Severity: normal

Dear members of the release team,

The package expeyes which I maintain is affected repeatedly by announcements
telling that "expeyes is marked for autoremoval from testing", ... on
2020-09-16,
due to the fact that it is supposed to (build-)depend on binutils-avr, which
FTBFS.

I presume that it might be some false positive detection.
Here is the list of its build-dependencies:

 debhelper-compat (=12),
 python3-all,
 dh-python,
 python3-docutils,
 pkg-config,
 wxglade,
 x11proto-randr-dev (>= 1.5.0),
 pyqt5-dev-tools,
 qttools5-dev-tools,
 qt5-qmake

as far as I know, none of them is related with binutils-avr.

The source package expeyes generates one binary package, microhope, which
declares a dependency on avr-libc; should I downgrade this dependency down to
a recommendation? The binary package microhope does not need  binutils-avr
as it is mainly an editor for small C or assembly language snippets. It needs
binutils-avr only when the end user will try to compile and link one one the
edited snippets.

Thank you in advance for any feedback.

Best regards,                     Georges.




-- System Information:
Debian Release: bullseye/sid
  APT prefers stable
  APT policy: (900, 'stable'), (499, 'testing'), (400, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

--- End Message ---
--- Begin Message --- 
Hi,

On Tue, 1 Sep 2020 13:04:04 +0100 Peter Green
<plugwash-urgent@p10link.net> wrote:
> (note: this mail represents my opinions as an ordinary dd, I am not a member of the release team)
> > due to the fact that it is supposed to (build-)depend on binutils-avr, which
> > FTBFS.
> 
> As I understand it "(build-)depends" should be interpreted as
> "depends or build-depends"

Correct.

> > The source package expeyes generates one binary package, microhope, which
> > declares a dependency on avr-libc; should I downgrade this dependency down to
> > a recommendation? The binary package microhope does not need  binutils-avr
> > as it is mainly an editor for small C or assembly language snippets. It needs
> > binutils-avr only when the end user will try to compile and link one one the
> > edited snippets.
> 
> The package description for microhope implies that while it may technically
> be "mostly an editor" it's reason for existing is avr development. Downgrading
> the dependency to a reccomends is arguably correct (reccomends is described as
> "The Recommends field should list packages that would be found together with
> this one in all but unusual installations.") and would get the autoremovals
> tool out of your hair, but I would still question if a package that can't
> fulfill it's primary purpose belongs in a Debian release.
> 
> IMO what really needs to happen here is that binutils-avr needs to be fixed,
> either by changing the actual code or by changing the compiler flags to make
> gcc less picky.

Agreed, and it seems to have happened.

This bug is not actionable, so closing.

Paul

Attachment: signature.asc
Description: OpenPGP digital signature


--- End Message ---
Reply to: