Bug#1026430: profanity: If an OMEMO msg to 2+ recipients & 1 recipient’s pubkey is bad, the msg is sent anyway (a logistical mess)

[debbug . 1026430]

It looks like bug 2 is similar to upstream bug 1185:

  https://github.com/profanity-im/profanity/issues/1185

Bug#1071610: pm-utils: with molly-guard, pm-suspend.no-molly-guard won't suspend

[debbug]

Package: pm-utils
Version: 1.4.1-21
Severity: important

Dear Maintainer,


   * What led up to the situation?
 Install molly-guard:
  ii  molly-guard0.8.4
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 With molly-guard installed, /sbin/pm-suspend is replaced:
 ~# ll /sbin/pm-suspend*
 lrwxrwxrwx 1 root root 30  9. Mär 22:38 /sbin/pm-suspend -> 
../lib/molly-guard/molly-guard*
 lrwxrwxrwx 1 root root 30  9. Mär 22:38 /sbin/pm-suspend-hybrid -> 
../lib/molly-guard/molly-guard*
 lrwxrwxrwx 1 root root 31 26. Jan 12:14 
/sbin/pm-suspend-hybrid.no-molly-guard -> /usr/lib/pm-utils/bin/pm-action*
 lrwxrwxrwx 1 root root 31 26. Jan 12:14 /sbin/pm-suspend.no-molly-guard -> 
/usr/lib/pm-utils/bin/pm-action*

   * What was the outcome of this action?
 Calling /sbin/pm-suspend.no-molly-guard is not suspending the system.

   * What outcome did you expect instead?
 Calling /sbin/pm-suspend.no-molly-guard should suspend the system.

Rationale:
molly-guard will create symlinks upon installation. These symlinks may be 
used in cirumstances. pm-action is not aware of those links and fails
to suspend. 

With the patch supplied below pm-action is molly-guard-aware and the 
/sbin/pm-suspend.no-molly-guard link is usable to suspend the system.


proposed PATCH:
--- /usr/lib/pm-utils/bin/pm-action 2024-05-22 10:25:03.506813817 +0200
+++ /usr/lib/pm-utils/bin/pm-action.bkp 2024-05-22 10:24:11.605425986 +0200
@@ -26,7 +26,7 @@
 
 # The rule here? Simplicity.

 export STASHNAME=pm-suspend
-export METHOD="$(echo ${0##*pm-} |tr - _)"
+export METHOD="$(echo ${0##*pm-} | sed 's/\.no-molly-guard//g' |tr - _)"
 . "/usr/lib/pm-utils/pm-functions"
 
 # return code tracking for when suspend fails



-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pm-utils depends on:
ii  powermgmt-base  1.37

-- no debconf information

Bug#628815: coreutils: pinky makes crazy DNS queries

[debbug]

/etc/acpi/lid.sh calls getXuser, that's defined in
/usr/share/acpi-support/power-funcs 
which has on line 36
plist=$(pinky -fw) || pwf_error "pinky lost"


On Tue, Mar 19, 2024 at 08:50:59AM -0400, Michael Stone wrote:
> On Tue, Mar 19, 2024 at 11:54:30AM +0100, you wrote:
> > For example on a debian system with acpi-support, /etc/acpi/lid.sh will
> > make many requests to find the host $WAYLAND_DISPLAY every time the lid
> > is opened.
> 
> I don't see anything in lid.sh that calls pinky.

Bug#628815: coreutils: pinky makes crazy DNS queries

[debbug]

I looked into this and found that
pinky tries to canonicalize the information in the "Where" column
automaticaly, and it has no option to disable this behaviour.
see line 285 pinky.c:
if (*ut_host)
/* See if we can canonicalize it.  */
host = canon_host (ut_host);
this results in many unnecessary dns queries.
For example on a debian system with acpi-support, /etc/acpi/lid.sh will
make many requests to find the host $WAYLAND_DISPLAY every time the lid
is opened.

"who" has the --lookup (attempt to canonicalize hostnames via DNS)
option, and doesn't do it by default.
Maybe it would be more lightweight to forget about canonicalization
altogether.

Bug#1067057: tcpdump: Environment undocumented in the man page, yet the TZ variable has effect on the timezone

[debbug . tcpdump]

Package: tcpdump
Version: 4.99.0-2+deb11u1
Severity: minor
Tags: upstream
X-Debbugs-Cc: debbug.tcpd...@sideload.33mail.com

Normally by convention useful environmental variables are documented
in an ENVIRONMENT section of the man page. There is no coverage of any
env vars in the man page. I was trying to work out how to make
timestamps print in terms of the UTC timezone. It’s undocumented. As a
guess, I tried:

  $ env TZ=UTC tcpdump -r session.pcap
 
It worked as expected. Is that because tcpdump reads the TZ variable?
Or does tcpdump make a system call to obtain the time and the system
uses the TZ variable?

If it’s the former, then TZ should be documented in the man page. If
it’s the latter, then it’s unclear to me how to document that but
nonetheless users should be informed somehow.

Along these lines, it’s worth noting that the man page says this:

  “A packet trace that crosses a daylight savings time change will
   give skewed time stamps (the time change is ignored).”

Perhaps a TZ that’s shifted by 12 hours or set to a timezone that does
not honor daylight savings will work around that problem?  If so, the
man page could suggest that.

-- System Information:
Debian Release: 11.5
  APT prefers oldstable-updates
  APT policy: (990, 'oldstable-updates'), (990, 'oldstable-security'), (990, 
'testing'), (990, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tcpdump depends on:
ii  adduser 3.118
ii  libc6   2.31-13+deb11u5
ii  libpcap0.8  1.10.0-2
ii  libssl1.1   1.1.1n-0+deb11u3

tcpdump recommends no packages.

Versions of packages tcpdump suggests:
ii  apparmor  2.13.6-10

-- no debconf information

Bug#1067056: libpcap0.8: man page gives incorrect syntax specification for 'proto ICMP'

[debbug . libpcap0 . 8]

Package: libpcap0.8
Version: 1.10.0-2
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.libpcap...@sideload.33mail.com

>From the pcap-filter man page:

> proto  proto qualifiers restrict the match to a particular protocol.
>Possible protos are: ether, fddi, tr, wlan, ip, ip6, arp,
>rarp, decnet, tcp and udp.  E.g., `ether src foo', `arp net
>128.3', `tcp port 21', `udp portrange 7000-7009', `wlan addr2
>0:2:3:4:5:6'.  If there is no proto qualifier, all protocols
>consistent with the type are assumed.  E.g., `src foo' means
>`(ip or arp or rarp) src foo' (except the latter is not legal
>syntax), `net bar' means `(ip or arp or rarp) net bar' and
>`port 53' means `(tcp or udp) port 53'.
> …
> 
> proto protocol
>
>   True if the packet is an IPv4 or IPv6 packet of protocol type
>   protocol.  Note that this primitive does not chase the protocol
>   header chain.
>
> tcp, udp, icmp
>   Abbreviations for:
>proto \protocol
>   where protocol is one of the above protocols.

It’s a bit screwy because the “proto” conditional is specified twice
in the man page. The first time it presents a mostly different set of
possible arguments than the 2nd time. When a user searches the man
page for “ICMP” they only see the 2nd syntax spec for “proto”. This
2nd occurance does not supply the BNF for the argument. The very next
paragraph is not intented but appears to list the arguments. A
speed-reading user sees “tcp, udp, icmp” and stops reading. Not that
it matters, because this abbreviation clause seems to suggest “tcp,
udp, icmp” are in fact valid parameters for “proto”. Yet this fails:

  $ tcpdump -Avvv -r session.pcap 'proto icmp'
  reading from file session.pcap, link-type LINUX_SLL2 (Linux cooked v2), 
snapshot length 262144
  Warning: interface names might be incorrect
  tcpdump: can't parse filter expression: syntax error

I was stumped. I could not work out why my usage was syntactically
incorrect. I had to get support from someone who suggested simply
removing “proto”. That worked. But according to the man page my
original attempt should have also worked.

-- System Information:
Debian Release: 11.5
  APT prefers oldstable-updates
  APT policy: (990, 'oldstable-updates'), (990, 'oldstable-security'), (990, 
'testing'), (990, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libpcap0.8 depends on:
ii  libc62.31-13+deb11u5
ii  libdbus-1-3  1.12.24-0+deb11u1

libpcap0.8 recommends no packages.

libpcap0.8 suggests no packages.

-- no debconf information

Bug#1067053: qa.debian.org: Documented policy needed for bug archival + archival transparency needed

[debbug . qa . debian . org]

Package: qa.debian.org
Severity: normal
X-Debbugs-Cc: debbug.qa.debian@sideload.33mail.com
Control: affects -1 +www.debian.org

There are essentially no documented policies or procedures for bug
report archival. The only disclosure on the website is here:

  https://www.debian.org/Bugs/server-control#unarchive

It’s so minimal I will just copy it here:

> archive bugnumber
> 
>   Archives a bug that had been archived at some point in the past but
>   is currently not archived if the bug fulfills the requirements for
>   archival, ignoring time.
> 
> unarchive bugnumber
> 
>   Unarchives a bug that was previously archived. Unarchival should
>   generally be coupled with reopen and found/fixed as
>   appropriate. Bugs that have been unarchived can be archived using
>   archive assuming the non-time based archival requirements are
>   met. You should not be using unarchive to make trivial changes to
>   archived bugs, such as changing the submitter; its primary purpose
>   is to allow for the reopening of bugs which have been archived
>   without the intervention of BTS administrators.

That’s it. There is no further guidance in the www.debian.org/Bugs/*
tree. It seems to say artificial archival can only be requested on
bugs that were previously archived. Yet there are bugs that have been
archived just 1 month after opening. This indicates undisclosed /
non-transparent procedures are in play. Then it says unarchival should
only be requested on naturally archived bugs (due to aging). Should
that “policy” be revisited?

Is archival a synonym for bug closure?  What are the reasons a bug
report can or should be artificially archived by intervention?

The Debian Social Contract (DSC) has a transparency clause:

> 3. We will not hide problems
>
>We will keep our entire bug report database open for public view
>at all times. Reports that people file online will promptly
>become visible to others.

That’s a good start but IMO it would improve quality if that were to
go a step further and (by extension) state that open public
/discussion/ of problems will also be facilitated.

The archival of a bug report has the speech/idea-chilling effect of
closing it and blocking further discussion.

This bug report is motivated by another. I thought of a new feature
that would improve the reportbug application. A search of bug reports
showed that someone already put forward the same idea (bug
1002906). There’s more to say on that, so I responded. My contribution
was suppressed because the bug was archived. In fact it was archived
just a month or so after it was opened.

Big transparency problem: even the verbose view of the bug report
showing extraneous control messages gives no indication of /how/ or
/why/ the bug was archived, or /who/ initiated it. We can only guess
that based on the very short timeframe open that it was archived by
intervention. Which means requesting unarchival goes against what I
quoted from the server control page.

I don’t imagine that whoever initiated the archival actually intended
to suppress the discussion. It was likely maintainers looking to get
the bug report out of their view (out of sight, out of mind) for
organizational reasons. But since archival has the effect of
suppressing discussion, it’s not a proper mechanism for that.

** Proposal **

I propose several actions to remedy all this.

① Revision to the DSC to include public discourse w.r.t bug reports.

② Drafting a clear and comprehensive policy informing everyone as to
proper and improper usage of bug archival and unarchival. Adapt
Bugs/server-control#unarchive as needed.

③ Modify the BTS as needed to include basic archival information in
the public views of bug reports, such as:

  * who initiated the archival

  * why it was archived (age or intervention; and if intervention then
the rationale for the intervention)

④ Reopen bug 1002906 if it’s deemed to have been archived without good
cause.

Bug#1066034: tech-ctte: proposed constitution fix and social contract chg to make documentation accessible to all people

[debbug . tech-ctte]

Package: tech-ctte
Severity: normal
Tags: a11y
X-Debbugs-Cc: debbug.tech-c...@sideload.33mail.com

# The DSC needs to become meaningful

Chuck Zmudzinski filed a bug report saying that the Debian Social
Contract (DSC) is “meaningless”:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028557

He is correct in the sense that there is no enforcement mechanism. At
the same time, the Debian Constitution (DC) also neglects to
acknowledge jurisdiction over DSC enforcement. This is a bug. I think
it’s assumed that the technical committee is tasked with DSC
enforcement. But this should be explicit and without guesswork.

Is the DSC a guaranteed protection whereby non-compliances have a
complaint mechanism and corrective procedure?  Or is the DSC actually
intended to be comparable to a meaningless pushover license?

# Transparency

In a sense, the transparency problem is joined with a dog food
problem. Consider ¶3:

> “3. We will not hide problems
> 
> We will keep our entire bug report database open for public view at
> all times. Reports that people file online will promptly become
> visible to others.”

(off-topic bug: “others” should be changed to “the public”,
 but security bugs should be exempt from “promptly”)

Problems in the DSC and calls for improvement thereof should itself be
a transparent process. It was unclear to me where to submit this bug
herein: tech-ctte, qa.debian.org, or general?

The DSC shows “Version 1.2 ratified on October 1st, 2022.” But where
and how?  The public should have transparent access to the
discussions, decisions, and changes.

# DSC change proposal: make documentation accessible to ALL people

There is a growing problem of documentation being locked into walled
gardens which discriminate against several demographics of people,
such as blind people being forced to solve a CAPTCHA that requires
vision. The access-restricted documentation problem is particularly
rampant on the Linux Mint and (ironically) Ubuntu projects. Debian
does not proactively impose any walled gardens on people at the moment
but whenever a package makes reference to external documentation
served from an access-restricted location, Debian passively allows
this. Debian can (and should) do better than this. The problem and
proposal is described in detail here:

  * https://linux.community/post/649372
  * 
https://kbin.social/m/debian/t/889598/Debian-Social-Contract-Should-all-Debian-users-inclusively-have-open

Those two links ↑ give two different views of the same article. I
reference both because of a minor formatting bug in kbin.

Bug#620756: Please adapt code of conduct

[debbug . 620756]

* Carsten Hey  [2011-04-03 22:08]:
>
>  * Because some new Debian users (i.e., not Debian Developers nor people
>posting to Debian lists regularly) might expect to get a carbon copy
>even without explicitly requesting one, sending a CC to them could be
>appropriate in rare cases.

Some would consider that negative training, whereby new users are
taught bad habits and form wrong expectations.

There is also a risk of missed messages. If just one person breaks the
rule in that circumstance and others follow the rule, the OP might
only see messages from the rule breaker. If Adrian had uniquely
followed the rules, the OP might see only Henrique’s reply and look no
further. If they had both followed the rules, the OP would have
received no reply (if unsubscribed) which would potentially prompt
them to check the list.

“Potentially” is a key there.. The current policy facilitates a /zero
personal reply zero check/ anomaly, where the user does not consider
checking the list for replies and misses all replies. I wonder if a
technical change could mitigate that.

In principle, when an unsubscribed author sends a message, perhaps the
mailing list should autorespond saying:

  “Your message was posted here: $URL. That is where you should check
   for replies.”

That would be a good enhancement request for whatever mailing list
software they are using.

Or alternatively/additionally, the mailing list software could go
above and beyond and track msgs by non-subscribers and either signal
them on replies to just their message or send a periodic digest of
replies. That feature could even be user-togglable. Maybe overkill,
but worth consideration IMO.

> Additionally the following could be added:
>
>  * Explicitly setting Mail-Followup-To: to the list's address reduces
>the chance to wrongly receive an unwanted carbon copy.

Good point.. I would concur with that amendment. (not that it
matters.. I have no sway on these changes)

Bug#1065879: openvpn: protocol configs have contradictory and confusing meanings in the man page + broken link + links to walled gardens

[debbug . openvpn]

Package: openvpn
Version: 2.5.1-3
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.open...@sideload.33mail.com

The --proto option is documented to accept these args:

  udp
  tcp-client
  tcp-server

The --remote option is documented to accept these args in the last position:

  udp / udp4 / udp6
  tcp / tcp4 / tcp6

The --proto-force option is documented to accept these args:

  udp
  tcp

What happens when you have:

  remote 198.19.34.56 443 # host 1
  proto tcp-client
  remote 198.19.34.57 1194 udp4   # host 2

  
  remote 198.19.34.58 1194# host 3
  http-proxy 192.168.0.8 8080
  proto udp
  

?

The proto parameter is documented to specify a default setting when a
connection profile is used. But the above example has two profile-free
connections. Users can (hopefully) assume that “tcp-client” will be
internally modified to “tcp” when connecting to host 1. But what
happens when host 2 is tried?  In principle if proto is not merely
specifying a /default/, then this is a conflict that should cause an
error. The man page should state whether proto is:

  1) a default (overridden by the remote setting);
  2) an override (to replace the remote setting); or
  3) a mutually weighted option that errors upon conflicts

The option “--proto tcp” often appears in configuration files given to
users by VPN suppliers. OpenVPN accepts it without error despite
contradiction with the man page. So it seems the man page needs to
clarify what that means. If openVPN is able to disambiguate *-client /
*-server, then do those suffixes even serve a necessary purpose?

W.r.t. connection profiles, the man page states that the “proto”
option can be embedded in the grouping, and as a consequence when
proto is specified /outside/ the grouping, it serves as a default
/only/ if it comes before the profile. Is it safe to assume that
sequence is irrelevant when it comes to interplay between profile-free
connections and the proto setting?

Another interesting example:

  proto-force tcp
  proto   tcp-client
  
  remote 198.19.34.56 443  tcp4
  remote 198.19.34.58 1194 udp

The proto parameter gives no way to specify IPv4 or IPv6. So would the
above indicate an option conflict, or does the tcp4 take precedence?
Or is “tcp4” overridden by “tcp-client”? And which protocol is used on
port 1194?

And considering proto-force only has effect on connection profiles, is
it simply ignored in this case?

Users can perhaps experiment to work out which of the various possible
behaviors result, but the man page should be written unambiguously.

The man page mentions this bad URL:

  http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

Naturally some users would try the InternetArchive version, which
first redirects to:

  
https://web.archive.org/web/20240114052848/http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

and then that redirects to a page telling users to visit a Github
profile belonging to Barbarossa. From there, it’s unclear where to go.

** Docs in access-restricted walled gardens **

Many of the man page URLs link into an access-restricted walled
garden. E.g. all openvpn.net links go to a Cloudflare site that is not
open to all people. It’s an injustice for a Debian man page to refer
users to exclusive resources that may exclude them. This is perhaps
something that should be fixed in the Debian version as the upstream
project has no duty to the users. Debian has a quality standard as
well as a social contract and users to give equitable treatment
to. Therefore IMO the Debian project should remove the
access-restricted links from the man page and ideally replace them
with openly accessible links. The most convenient way to do that would
be to find mirrored versions of the pages in the Wayback Machine.

This one-liner would perhaps do the job well enough:

  sed -e 
'/http.*.openvpn.net/s@https://\([[:alnum:].]*openvpn.net\)@https://web.archive.org/web/\1@'

ietf.org has the same problem.

-- System Information:
Debian Release: 11.5
  APT prefers oldstable-updates
  APT policy: (990, 'oldstable-updates'), (990, 'oldstable-security'), (990, 
'testing'), (990, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openvpn depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  iproute2   5.10.0-4
ii  libc6  2.31-13+deb11u5
ii  liblz4-1   1.9.3-2
ii  liblzo2-2  2.10-2
ii  libpam0g   1.4.0-9+deb11u1
ii  libpkcs11-helper1  1.27-1
ii  libssl1.1  1.1.1n-0+deb11u3
ii  libsystemd0247.3-7+deb11u1
ii  lsb-base   11.1.0

Versions of packages openvpn recommends:
ii  easy-rsa  3.0.8-1

Versions of 

Bug#1028557: general: The Debian Social Contract is enforced extrajudicially but wording is missing

[debbug . 1028557]

Package: general
Followup-For: Bug #1028557
X-Debbugs-Cc: debbug.1028...@sideload.33mail.com

Why do you say enforcement is necessarily bound to the judicial system
of a state?

Rules can be written and enforced entirely without a state-backed
authority. Consider a scenario as simple as a bar having rules and
then bouncing a rule-breaking customer. Or more formally, a university
campus has their own rules. If you break the rules they have an
arbitration process where you can address a panel of your peers and
argue your case. The school argues their case, and the panel of peers
decides the outcome. That process happens entirely without any
lawyers, judges, or state actors involved.

The Debian Project is staffed and those people have powers¹. E.g. the
“technical committee” can:

  4. Overrule a Developer (requires a 3:1 majority).

 The Technical Committee may ask a Developer to take a particular
 technical course of action even if the Developer does not wish
 to; this requires a 3:1 majority. For example, the Committee may
 determine that a complaint made by the submitter of a bug is
 justified and that the submitter's proposed solution should be
 implemented.

It’s a bit vague though in terms of the actions and penalties. But I
guess it’s implied that a project can be removed from the Debian
system. The procedures are described here:

  https://www.debian.org/devel/tech-ctte

** Still a bug **

I agree there is a bug here. The Debian Social Contract does not refer
to the Debian Constitution as the enforcement mechanism, and the
Debian Constitution does not claim jurisdiction over enforcement of
the Debian Social Contract. It seems a bit sloppy that the Debian
Constitution only says statements may be made about the social
contract in paragraph 4.1.5.2. Some verbiage needs to be added to both
docs to establish enforcability.

(footnotes)

① https://www.debian.org/devel/constitution

Bug#1064836: rsync: Escape code %P treated literally in --out-format spec

[debbug . rsync]

Package: rsync
Version: 3.2.3-4+deb11u1
Severity: normal
X-Debbugs-Cc: debbug.rs...@sideload.33mail.com

The following simplified command was used to backup a whole drive:

  $ rsync -vahHAXS --out-format='%i %n%L %P' --delete --relative --numeric-ids 
--prune-empty-dirs --dry-run\
--exclude '/proc/'\
--exclude '/dev/'\
--exclude '/sys/'\
--exclude '/run/'\
--exclude '/mnt/'\
--exclude '/tmp/'\
/ /mnt/backup/

The --out-format supplied above is essentially the same as the -i
option but with “ %P” appended, which is documented in the rsyncd.conf
manpage as follows:

  %P the module path

This term “module” is non-intuitive and the first occurance of the
word in the rsync manpage is unexplained (which should be fixed.. the
first use of a term like that should be explained on the spot). It’s
explained further down on the manpage. In any case, I just wanted to
see what %P would show because there seems to be no mechanism to print
the filename on the *receiving* destination side (%f is the long form
of the sender side, and %n is a short form [apparently on the sender
side though this is not specified and thus should be clarified]). I
ultimately need to troubleshoot a problem of files being dumped one
directory level higher than expected on the receiving side. The output
looks like this:

===8<
…
>f+ /home/user/foo.txt %P
…
===8<

So %P is being printed literally.

In summary, these are the bugs:

  * --out-format='%i %n%L %P' results in %P being printed literally.
  * “module” is mentioned on the rsync man page before it’s defined.
  * %n on the rsyncd.conf manpage omits sender/receiver.
  * Neither manpage states how to print the full *receiving* side filename.

-- System Information:
Debian Release: 11.5
  APT prefers oldstable-updates
  APT policy: (990, 'oldstable-updates'), (990, 'oldstable-security'), (990, 
'testing'), (990, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rsync depends on:
ii  init-system-helpers  1.60
ii  libacl1  2.2.53-10
ii  libc62.31-13+deb11u5
ii  liblz4-1 1.9.3-2
ii  libpopt0 1.18-2
ii  libssl1.11.1.1n-0+deb11u3
ii  libxxhash0   0.8.0-2
ii  libzstd1 1.4.8+dfsg-2.1
ii  lsb-base 11.1.0
ii  zlib1g   1:1.2.11.dfsg-2+deb11u2

rsync recommends no packages.

Versions of packages rsync suggests:
ii  openssh-client  1:8.4p1-5+deb11u1
ii  openssh-server  1:8.4p1-5+deb11u1
ii  python3 3.9.2-3

-- no debconf information

Bug#1060012: rsync: docs insufficient for --partial, -W, --no-whole-file, and SIGNALS

[debbug . rsync]

Package: rsync
Version: 3.2.3-4+deb11u1
Severity: minor
X-Debbugs-Cc: debbug.rs...@sideload.33mail.com

Rsync was producing some baffling behavior. But after some
investigation, it turns out rsync is apparently well-behaved. The docs
are lacking in ways that slowed down my ability to figure out what was
going wrong and hindered my ability to work out the needed parameters
going forward.

In the case at hand, I ran a command like this:

  $ rsync -va -P $local_source_file $local_destination

A ~20gb file was being pushed through a USB2 bus which can be quite
slow. I had to shutdown in the middle of the transfer thus hit
ctrl-c. The partial file was left as expected (though hard to find
because the date was 1970 and I did an “ls -ltr” to look for recent
files). So at first I thought the partial file was not saved. This
caused me to distrust ctrl-c as a signal that would be treated as an
“interruption” (vs. a deliberate cancelation by a user which might
cause an assumption that the user does not want the effects of the
transfer to play out). Kill signals are not well documented. I later
realized the partial file was in fact present but with a 1970
timestamp. Then I later ran the original command, but it started
transferring from zero and did not crash-recover. Again I was
astonished and thought there was a functionality bug. It’s finally
clear that there are no functionality bugs in this episode.

In the interest of mitigating user astonishment, I suggest the
following man-page updates:

1. The docs for --partial should state the requirements for
   crash-recovery to function. Specifically, it should state that -W
   must be switched off in the recovery session. This is particularly
   important because it’s certainly not obvious from the summary of
   options that there is interplay between -W and --partial.

2. The docs for --whole-file should also mention its affect after
   --partial is used. Someone searching the man-page for partial should
   also be brought to the --whole-file option, and vice versa. The docs
   for --whole-file also neglect to state how to disable the option. The
   only reason I was able to discover the existence of the
   --no-whole-file option was because it incidentally happened to be an
   example given in the docs for --no-OPTION. Otherwise if that example
   had not existed, I would have been at a dead-end.

3. Man-pages normally have a “SIGNALS” section. I looked for that
   section because I wanted to see what signal results in a graceful
   abort that respects the --partial option. So a “SIGNALS” section
   should be created with that in mind.

-- System Information:
Debian Release: 11.5
  APT prefers oldstable-updates
  APT policy: (990, 'oldstable-updates'), (990, 'oldstable-security'), (990, 
'testing'), (990, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rsync depends on:
ii  init-system-helpers  1.60
ii  libacl1  2.2.53-10
ii  libc62.31-13+deb11u5
ii  liblz4-1 1.9.3-2
ii  libpopt0 1.18-2
ii  libssl1.11.1.1n-0+deb11u3
ii  libxxhash0   0.8.0-2
ii  libzstd1 1.4.8+dfsg-2.1
ii  lsb-base 11.1.0
ii  zlib1g   1:1.2.11.dfsg-2+deb11u2

rsync recommends no packages.

Versions of packages rsync suggests:
ii  openssh-client  1:8.4p1-5+deb11u1
ii  openssh-server  1:8.4p1-5+deb11u1
ii  python3 3.9.2-3

-- no debconf information

Bug#1026430: more bugs to account for than upstream is aware of

[debbug . 1026430]

Package: profanity
Version: 0.13.1-1~bpo11+1
Followup-For: Bug #1026430
X-Debbugs-Cc: debbug.1026...@sideload.33mail.com

The scenario captured in bug 1026430 actually expands into 4 bugs. Upstream bug 
report 1615¹ seems to capture sub bug 1 (the mere fact that fingerprints are 
lost) but not sub bugs 2—4.

If upstream bug 1615 is resolved by merely mitigating the key loss, what 
happens when there is no key for someone to begin with?  Or when a key expires? 
 More guard conditionals are needed to ensure a msg doesn’t go out to a group 
without everyone’s pubkey first being completely resolved. This check should 
ideally be performed before the sender even begins typing a msg.

1. https://github.com/profanity-im/profanity/issues/1615

Bug#1043109: imagemagick: metadata leaks into body on TIFF → PDF conversion

[debbug . imagemagick]

Package: imagemagick
Version: 8:6.9.11.60+dfsg-1.3
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.imagemag...@sideload.33mail.com

Metadata from a TIFF file is being transfered to the *body* of the
target file when “converting” to a PDF file. This results in a PDF
file that falsely appears to have searchable text. One side-effect of
that is OCR programs raise errors saying the PDF has already been
OCR-processed.

Steps to reproduce:

① Use Gimp to save a TIFF file. The options to save metadata should
probably be enabled.

② Verify that the “PageName” field is populated:

  $ tiffinfo gimp_output.tif
  TIFFReadDirectory: Warning, Unknown field with tag 326 (0x146) encountered.
  TIFFReadDirectory: Warning, Unknown field with tag 327 (0x147) encountered.
  TIFFReadDirectory: Warning, Unknown field with tag 328 (0x148) encountered.
  TIFF Directory at offset 0x8 (8)
Image Width: 3544 Image Length: 6240
Resolution: 204, 196 pixels/inch
Bits/Sample: 1
Sample Format: unsigned integer
Compression Scheme: None
Photometric Interpretation: min-is-white
Orientation: row 0 top, col 0 lhs
Samples/Pixel: 1
Rows/Strip: 128
Planar Configuration: single image plane
SubIFD Offsets:  5392
PageName: pg04-5.tiff
Software: GIMP 2.10.22
DateTime: 2023:08:05 20:24:13
XMLPacket (XMP Metadata):

③ Use ImageMagick-convert to produce a PDF:

  $ convert gimp_output.tif imagemagick_output.pdf
  convert-im6.q16: Unknown field with tag 326 (0x146) encountered. 
`TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/985.
  convert-im6.q16: Unknown field with tag 327 (0x147) encountered. 
`TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/985.
  convert-im6.q16: Unknown field with tag 328 (0x148) encountered. 
`TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/985.
  convert-im6.q16: Unknown field with tag 327 (0x147) encountered. 
`TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/985.
  convert-im6.q16: Unknown field with tag 328 (0x148) encountered. 
`TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/985.

④ Use pdf2txt to see the stray text that was injected into the PDF body:

  $ pdf2txt imagemagick_output.pdf
  pg04-5.tiff

⑤ Use pdfinfo to prove that the TIFF metadata (“PageName:”) did not make it 
into the PDF metadata:

  $ pdfinfo imagemagick_output.pdf 
  Title:  imagemagick_output
  Producer:   https://imagemagick.org
  CreationDate:   Sun Aug  6 10:14:34 2023 CEST
  ModDate:Sun Aug  6 10:14:34 2023 CEST
  Tagged: no
  UserProperties: no
  Suspects:   no
  Form:   none
  JavaScript: no
  Pages:  1
  Encrypted:  no
  Page size:  1250.82 x 2292.24 pts
  Page rot:   0
  File size:  27485613 bytes
  Optimized:  no
  PDF version:1.7

⑥ Use ocrmypdf to attempt making the text contained within the PDF searchable:

  $ ocrmypdf imagemagick_output.pdf searchable.pdf
  Scanning contents: 
100%||
 1/1 [00:00<00:00, 68.27page/s]
  Using Tesseract OpenMP thread limit 2
  OCR:   0%|
  | 0.0/1.0 [00:00https://imagemagick.org
compare:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
convert:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
composite:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
conjure:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
display:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
identify:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
import:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
mogrify:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
montage:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
stream:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org

-- System Information:
Debian Release: 11.5
  APT prefers oldstable-updates
  APT policy: (990, 'oldstable-updates'), (990, 'oldstable-security'), (990, 
'testing'), (990, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages imagemagick depends on:
ii  imagemagick-6.q16  8:6.9.11.60+dfsg-1.3

imagemagick recommends no packages.

imagemagick suggests no packages.

-- no debconf information

Bug#1042487: neomutt: ANSI headers not decoded

[debbug . neomutt]

Package: neomutt
Version: 20201127+dfsg.1-1.2
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.neom...@sideload.33mail.com

When the From: field contains an umlaut (“ö”), such as:

  Andreas Rönnquist 

it then gets encoded for transport and the literal
text is:

  From: Andreas =?UTF-8?B?UsO2bm5xdWlzdA==?= 

Neomutt properly treats that UTF-8 encoding. However, the 33mail.com
forwarding service apparently re-encodes it in ANSI as follows:

  From: "=?ANSI_X3.4-1968?Q?Andreas_R=3Fnnquist?= 'redacted' via 33Mail" 


Neomutt does not decode that particular string. In Neomutt the
=?ANSI… junk appears literally.

Steps to reproduce:

1. Download the mbox file for the following comment:
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027753;msg=10

2. Replace the /From:/ field with:
   From: "=?ANSI_X3.4-1968?Q?Andreas_R=3Fnnquist?= 'redacted' via 33Mail" 


3. Launch neomutt: $ neomutt -f "$mbox_file"

I am probably running an old version of neomutt, but I have searched both bug 
trackers (Debian & upstream) for “ANSI” & found no mention of this bug. I also 
searched the debian change logs. So AFAICT the latest neomutt would have this 
bug as well.

-- Package-specific info:
NeoMutt 20201127
Copyright (C) 1996-2020 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.

System: Linux 5.10.0-19-amd64 (x86_64)
ncurses: ncurses 6.2.20201114 (compiled with 6.2.20201114)
libidn: 1.33 (compiled with 1.33)
GPGME: 1.14.0-unknown
GnuTLS: 3.7.1
libnotmuch: 5.3.0
storage: tokyocabinet

Configure options: --build=x86_64-linux-gnu --prefix=/usr 
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man} 
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
{--libdir=${prefix}/lib/x86_64-linux-gnu} 
{--libexecdir=${prefix}/lib/x86_64-linux-gnu} --disable-maintainer-mode 
--disable-dependency-tracking --mandir=/usr/share/man --libexecdir=/usr/libexec 
--with-mailpath=/var/mail --gpgme --lua --notmuch --with-ui --gnutls --gss 
--idn --mixmaster --sasl --tokyocabinet --sqlite --autocrypt

Compilation CFLAGS: -g -O2 
-ffile-prefix-map=/build/neomutt-aFsTyZ/neomutt-20201127+dfsg.1=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include 
-I/usr/include/lua5.4 -DNCURSES_WIDECHAR -isystem /usr/include/mit-krb5

Default options:
  +attach_headers_color +compose_to_sender +compress +cond_date +debug 
  +encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color 
  +initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop 
  +progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar 
  +skip_quoted +smtp +status_color +timeout +tls_sni +trash 

Compile options:
  +autocrypt +bkgdset +color +curs_set +fcntl -flock -fmemopen +futimens 
  +getaddrinfo +gnutls +gpgme +gss +hcache -homespool +idn +inotify 
  -locales_hack +lua +meta +mixmaster +nls +notmuch -openssl +pgp +regex +sasl 
  +smime +sqlite +start_color +sun_attachment +typeahead 
MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"

To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to: 

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages neomutt depends on:
ii  libc6 2.31-13+deb11u5
ii  libgnutls30   3.7.1-5+deb11u2
ii  libgpg-error0 1.38-2
ii  libgpgme111.14.0-1+b2
ii  libgssapi-krb5-2  1.18.3-6+deb11u3
ii  libidn11  1.33-3
ii  liblua5.4-0   5.4.2-2
ii  libncursesw6  6.2+20201114-2
ii  libnotmuch5   0.31.4-2
ii  libsasl2-22.1.27+dfsg-2.1+deb11u1
ii  libsqlite3-0  3.34.1-3
ii  libtinfo6 6.2+20201114-2
ii  libtokyocabinet9  1.4.48-13
ii  sensible-utils0.0.14

Versions of packages neomutt recommends:
ii  libsasl2-modules  2.1.27+dfsg-2.1+deb11u1
ii  locales   2.31-13+deb11u5
ii  mime-support  3.66

Versions of packages neomutt suggests:
ii  aspell  0.60.8-3
ii  ca-certificates 20210119
ii  gnupg   2.2.27-2+deb11u2
ii  ispell  3.4.02-2
pn  mixmaster 

Bug#1041769: geeqie: TIFF renders as an upside-down mirror of former CCITT docs

[debbug . geeqie]

Package: geeqie
Version: 1:1.6-9+deb11u1
Severity: important
X-Debbugs-Cc: debbug.gee...@sideload.33mail.com

TIFF files display as an upside-down mirror image. The reproduction steps are:

  1. Scan a text document on a Konica Minolta bizhub C360i MFD & save to USB
  2. $ pdfimages -all $scanned_pdf innards
  3. $ fax2tiff $(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646982

Bug 646982 reports a problem with correcting the orientation, but we
have to ask why the TIFF orientation needed correction in the first
place. This entry in the release notes looks interesting:

===8<--
geeqie (1:1.5.1+git20200708-1) unstable; urgency=medium

  * Update README.Debian - mention GDK_CORE_DEVICE_EVENT, remove obsolete
info about gqview
  * New upstream git snapshot 1.5.1+git20200708 - Fixes rendering
under wayland (Closes: #964441)
  * Remove patches applied upstream:
  0001-Fix-710-Apply-the-orientation-to-image-content-not-w.patch
  0002-Fix-736-Please-migrate-from-gnome-doc-tool-to-yelp-b.patch
  0004-Fix-741-Crash-when-creating-new-dir-with-same-name-a.patch
  fix_multiple_definitions_with_gcc_10.patch
  * Refresh patch 0003-Remove-changelog-from-menu-item.patch
  * Add patch to fix version number on git snapshot and
add Forwarded: not-needed to silence lintian
===8<--

Might that removed patch (0001-…) be related?  Because of that
possibility, I did not mark this bug as upstream.

Unfortunately I have no sample to attach. Perhaps I can scan an
arbitrary non-personal document in the future to supply a sample, if
needed.

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages geeqie depends on:
ii  geeqie-common1:1.6-9+deb11u1
ii  libc62.31-13+deb11u5
ii  libcairo21.16.0-5
ii  libchamplain-0.12-0  0.12.20-1
ii  libchamplain-gtk-0.12-0  0.12.20-1
ii  libclutter-1.0-0 1.26.4+dfsg-2
ii  libclutter-gtk-1.0-0 1.8.4-4
ii  libcogl201.22.8-2
ii  libdjvulibre21   3.5.28-2
ii  libexiv2-27  0.27.3-3+deb11u1
ii  libffmpegthumbnailer4v5  2.1.1-0.2+b1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1+deb11u1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4+deb11u2
ii  libheif1 1.11.0-1
ii  libjpeg62-turbo  1:2.0.6-4
ii  liblcms2-2   2.12~rc1-2
ii  liblirc-client0  0.10.1-6.3
ii  liblua5.1-0  5.1.5-8.1+b3
ii  libopenjp2-7 2.4.0-3
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpoppler-glib8 20.09.0-3.1+deb11u1
ii  libstdc++6   10.2.1-6
ii  libtiff5 4.2.0-1+deb11u1
ii  libwebp6 0.6.1-2.1
ii  sensible-utils   0.0.14

Versions of packages geeqie recommends:
ii  cups-bsd [lpr]   2.3.3op2-3+deb11u2
ii  exiftran 2.10-4
ii  exiv20.27.3-3+deb11u1
ii  imagemagick  8:6.9.11.60+dfsg-1.3
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3
ii  librsvg2-common  2.50.3+dfsg-1
ii  zenity   3.32.0-6

Versions of packages geeqie suggests:
pn  geeqie-dbg 
ii  gimp   2.10.22-4
pn  libjpeg-progs  
pn  xpaint 

-- no debconf information

Bug#1041373: toot: bug suppression must be thwarted

[debbug . 1041373]

Package: toot
Version: 0.27.0-1
Followup-For: Bug #1041373
X-Debbugs-Cc: debbug.1041...@sideload.33mail.com

> yet you wont receive any updates

There are countless factors in determining the version that best
serves any particular user. It is not for you to decide or control
what version a user runs. When you suggest that users upgrade their
whole system in order to run a more recent version of a social media
app to overcome a trivial flaw, this is reckless advice. You need to
understand that every package has dependencies. Those version
dependencies either support or break other packages. Every dist
upgrade results in gains /and losses/. You cannot competently
prescribe arbitrarily to all users that they “chase the shiny” at all
costs. It’s an absurdity to impose this on others most particularly
when they are still running officially supported versions.

> and instead you spam the debian bug tracking system with "reports"
> that are just noise (like this one, since it's fixed upstream).

You’ve misidentified the problem. The problem was not with the version
I was running; it’s that I did not check the release notes
first. Please re-read my message from the top. I admitted to that
error which AFAIK only involves bug 1041373, not the others.

Users can run a range of different officially supported versions and
the Debian BTS is rightfully designed to accommodate this.

> if i go in a bakery and scream "my chair broke, i want a new one!"
> it serves no one purpose.

The misunderstanding here is that you think I am an individual looking
for personalized support. The bugs I have reported are *community*
bugs. So the /fallacy of analogy/ here is that you say “my” chair
broke, when in fact it’s a community resource that broke. By
extension, community bug reports serve the community, not the
individual.

In fact the individual bug submitter finds workarounds because bugs
are not fixed overnight and a Debian user won’t often see the change
for years out. By the time the lifecycle of the bug runs its course,
any benefit to the original submitter is marginal since their
workaround or alternate workflow is already established. The
beneficiaries of fixes are future users.

> You need to submit the requests in the right place for the right
> people to act on.

The “right place” differs from one user to the next. It is walled
gardens who decide who may enter, not users who decide whether a
walled garden must serve them. Often there is no “right place” for a
given user. Some bugs go entirely unreported because of obnoxious
CAPTCHAs or surveillance capitalist MitMs. Yes it’s clear that you’re
a gmail pawn but try not to view everyone through the “surveillance
capitalism is fine for everyone” lens. That’s not for you to control.

Users will contribute bug reports wherever they /can/. It’s rightfully
their choice. Demanding that voluntary contributors bend to your needs
is quite obnoxious.

> yeah which you conveniently omitted to report the big `if` before
> hand: "If you file a bug in Debian, don't send a copy to the upstream
> software maintainers yourself"

I simply pointed you to the whole document. How can that be an
omission?  The only omission I see is in your cherry picked requoting
of the doc, which omitted:

  “If necessary, the maintainer of the package will forward the bug
   upstream.”

> -- what we are telling you

Speak for youself please.

> is to NOT file these bugs at all in the debian bts, but directly
> upstream.

On what authority do you believe you can override the bug reporting
procedure document?  Clearly the policy you were shown gives
contributors a choice. If you don’t like that, it’s on you to change
it. This is not the appropriate place for that.

> you dont like github?

Github doesn’t like me either. Red herring nonetheless. Who likes who
is irrelevent when the Debian procedure gives contributors a choice.

> If i were the maintainer of this package, i'd bulk close all your
> report and invalid and ask the BTS maintainer to temporarily ban you
> from submitting more.

Then you would be a reckless maintainer. Nothing is worse for quality
than a bug suppressing emotionally hot-headed maintainer.

Bug#1041373: toot: release notes overlooked

[debbug . 1041373]

Package: toot
Version: 0.27.0-1
Followup-For: Bug #1041373
X-Debbugs-Cc: debbug.1041...@sideload.33mail.com

Ivan Habunek said:

> This has been fixed in 0.28.1 (2022-11-12).
> 
> -- Ivan

Thanks Ivan. I searched for this bug both in Github and in the Debian
BTS and found nothing prior to filing the report, but I did not review
the release notes. Sorry about that.  In attempt to improve my own
procedure, I found the Debian release notes here:

  
https://metadata.ftp-master.debian.org/changelogs//main/t/toot/toot_0.34.1-1_changelog

They neglect to mention the fix, which is documented here:

  https://github.com/ihabunek/toot/releases?page=2

In the future, I will try to remember to check both sets of release
notes (Debian & upstream) before filing.

Since the upstream release notes are made available, the Debian policy
suggests that maintainers to include them in the distro release notes.
So I have submitted a separate (downstream) bug report for this but it
has not yet been assigned a number.

--

Sandro Tosi said:

> this is the version in oldstable, it's probably time to upgrade to
> something newer,

Perhaps eventually. I appreciate the information. But it’s important
to realize that upgrading a whole Debian system is not to be taken
lightly. People like myself keep various quite fragile pkgs on
life-support which are easily broken in upgrades. I’ve seen the havoc
and catastrophe dist upgrade can cause. Risks often far outweight the
benefits particularly in this case. It also requires having high-speed
unlimited broadband access. Sometimes either a hot site or cold site,
backups, roll-back contingencies, etc. It’s a big deal. The
undertaking would a crazy remedy to the bug herein, or for anything
toot related for that matter.

Most importantly: oldstable is still officially supported for another
year¹ from now.

> which hopefully will stop this stream of bug reports

Bug reports are essential for QA. It’s better to advocate for bug
reports, not push for their suppression.

> that do not belong to the debian tracking system (as mentioned
> before already).

Please read the “Don't file bugs upstream” section of the bug
reporting procedure².

Footnotes:

① https://wiki.debian.org/DebianReleases
② https://www.debian.org/Bugs/Reporting#filedalready

Bug#1041403: toot: upstream release notes not imported

[debbug . toot]

Package: toot
Version: 0.27.0-1
Severity: wishlist
X-Debbugs-Cc: debbug.t...@sideload.33mail.com

The downstream release notes here:

  
https://metadata.ftp-master.debian.org/changelogs//main/t/toot/toot_0.34.1-1_changelog

exclude the upstream release notes which are available here:

  https://github.com/ihabunek/toot/releases

Section 12.7 of the Debian policy states¹:

  “If an upstream release notes file is available, containing a
   summary of changes between upstream releases intended for end users
   of the package and often called NEWS, it should be accessible as
   /usr/share/doc/package/NEWS.gz”
  …
  “If there is an upstream changelog available, it may be made
   available as /usr/share/doc/package/changelog.gz.”
  …
  “[10] Rationale: People should not have to look in places for
   upstream changelogs merely because they are given different names
   or are distributed in HTML format.”

Note that the Debian policy language does not strictly require² the
above (which uses wording like “should” and “may” and not “must”). So
it’s optional and hence why this bug herein is filed with /wishlist/
severity. Even if the upstream release notes continue to be excluded,
it would be useful if the Debian release notes would at least link to
the upstream notes in light of footnote 10 above.

One benefit to comprehensive release notes is that it might mitigate
reports of fixed bugs, apart from helping users determine which
version is best for their situation.

Footnotes:

① 
https://www.debian.org/doc/debian-policy/ch-docs.html#changelog-files-and-release-notes
② https://www.debian.org/doc/debian-policy/ch-scope.html#definitions

Bug#1041373: toot: posts cannot begin with a hashtag

[debbug . toot]

Package: toot
Version: 0.27.0-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.t...@sideload.33mail.com

When posting from the commandline, if -e is used then a template
states that lines beginning with a hash (“#”) are ignored. This is a
problem because it’s very often useful to begin a line with a
hashtag. It’s in fact common to write just hashtags on the last line
of a message.

It’s unclear¹ why users would want to put comments in a temporary text
file that will be destroyed right after posting, but certainly a hash
symbol should be avoided. Possible alternatives:

  % LaTeX and Erlang comments go from percent symbol to EOL
  /* comments in C, graphviz and many other languages² begin with forward slash 
asterisk and end with */
  // C++ comments go from // to EOL
  -- Ada comments go from -- to EOL
  ; Forgot where I’ve seen this but some app’s comments go from semicolon to EOL
  
  [//]: # (markdown comments are complicated)

Considering some simplified subset of HTML is specified for
activitypub posts, HTML comments may be the most suitable.

Possible other bugs:

I’ve only identified this bug in the CLI version specifically in
conjunction with using an editor. I have not tested what happens to
lines beginning with hash when the text body is supplied on the
commandline, or what happens in the TUI. If the pure non-interactive
CLI approach is affected, then it would be a bug that the man page
does not cover it.

footnotes:

① implementation of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038664 
would make comments more useful
② https://web.archive.org/web/20230301231734/geekflare.com/how-to-add-comments/

Bug#1040640: toot: crash with stack dump when posting a JPEG

[debbug . toot]

Package: toot
Version: 0.27.0-1
Severity: important
Tags: upstream
X-Debbugs-Cc: debbug.t...@sideload.33mail.com

I tried to post a JPG image and it crashed with a stack dump:

===8<--
$ torsocks toot post -u b...@example.com -m ./some_pic.jpg -e emacs
Uploading media: ./some_pic.jpg
Traceback (most recent call last):
  File "/usr/bin/toot", line 11, in 
load_entry_point('toot==0.27.0', 'console_scripts', 'toot')()
  File "/usr/lib/python3/dist-packages/toot/console.py", line 550, in main
run_command(app, user, command_name, args)
  File "/usr/lib/python3/dist-packages/toot/console.py", line 532, in 
run_command
return fn(app, user, parsed_args)
  File "/usr/lib/python3/dist-packages/toot/commands.py", line 104, in post
args.text = "\n".join(m['text_url'] for m in media)
TypeError: sequence item 0: expected str instance, NoneType found
===8<--

Notice that it was over a Tor circuit though I don’t suppose that’s
likely a factor.

===8<--
$ identify ./some_pic.jpg 
./some_pic.jpg JPEG 1024x763 1024x763+0+0 8-bit sRGB 26324B 0.000u 0:00.000
===8<--


-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages toot depends on:
ii  python3   3.9.2-3
ii  python3-bs4   4.9.3-1
ii  python3-requests  2.25.1+dfsg-2
ii  python3-urwid 2.1.2-1
ii  python3-wcwidth   0.1.9+dfsg1-2

toot recommends no packages.

toot suggests no packages.

-- no debconf information

Bug#1040221: dealing with upstream bugs

[debbug . 1040221]

Package: toot
Version: 0.27.0-1
Followup-For: Bug #1040221
X-Debbugs-Cc: debbug.1040...@sideload.33mail.com

I have added the “upstream” tags to a couple bug reports and noticed
the search form provides a tag criteria. So if you want to filter out
upstream bugs, this link does that:

  
https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;exclude=tags%3Aupstream;package=toot

We can also filter out downstream bug reports by including bugs tagged
“upstream”:

  
https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;include=tags%3Aupstream;package=toot

Perhaps it would be useful to submit just one bug report upstream,
call it a meta bug report of sorts, which simply references the link
above. Ideally the upstream maintainer would then just leave that bug
report open indefinitely and pin it to the top if possible so all
upstream users are steered toward browsing upstream bugs in the Debian
BTS as well.

Bug#1040221: toot: auth output needs a raw option

[debbug . 1040221]

control: tags -1 upstream

* Jonathan Carter 'j...@debian.org' via 33Mail  
[2023-07-07 17:34]:
> On 2023/07/03 19:51, Sandro Tosi wrote:
> > It would be nice if you could report all the issues you opened
> > upstream at the link above and forward
> > (https://www.debian.org/Bugs/server-control#forwarded) the debian bugs
> > to the upstream once.
> 
> +1, that would be ideal, we don't write code for toot or add new features
> for it in Debian, we package the upstream version, and might carry some bug
> fixes in the form of patches until they're fixed upstream, but other than
> that, I suggest filing ideas for improvement on the upstream bug tracker.
> 
> thanks and keep well!

I’m not keen on using MS Github. The 2fa system blocks me because the
registered email address there forces me to login to an account with a
typically broken CAPTCHA. I also have ethical problems with using
Microsoft assets.

I understand the frustration though. I wouldn’t want your job. I’m
glad the Debian BTS gives an easy way to report bugs so they are at
least captured somewhere.

There are plans to move the toot upstream bug tracker to a more
accessible location (Sourceforge). Is there any issue with letting the
bugs sit until that happens?  I suppose the worst that could happen is
they get archived during the wait, but at least they’re still
reachable after archiving.

I’ve noticed other maintainers being (understandably) reluctant to
forward bugs upstream. What can be improved in the Debian BTS?  It
seems automation is lacking. Shouldn’t there be a simple control
signal to the BTS to say “forward this upstream”, and the machinery
does the rest?

There is a developer tag “upstream”:

  https://www.debian.org/Bugs/Developer#tags

Suppose that tag is applied to the bug reports I submitted. Would it
help the management of the bug reports?  Perhaps we could use that to
tag bug reports waiting to be forwarded so they can be filtered out in
searches, and so someone willing and able to use MS assets could
perhaps use that tag to query bugs to forward. 

Bug#1040577: toot: color lost when piping

[debbug . toot]

Package: toot
Version: 0.27.0-1
Severity: minor
Tags: upstream
X-Debbugs-Cc: debbug.t...@sideload.33mail.com

CLI output is normally in color but when piping the output to another
tool, the color is lost. It’s useful to be able to pipe to “less -R”,
which is a pager that preserves ANSI control codes and thus
color. Apparently toot is detecting the pipeline as non-interactive
and automatically stripping out the color codes even when the
“--no-color” option is not supplied.

It may be deliberate & it’s probably a sensible default behavior. But
if that’s going to be the default then we need a way to force
color. The convention is typically a “--color=always” option.

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages toot depends on:
ii  python3   3.9.2-3
ii  python3-bs4   4.9.3-1
ii  python3-requests  2.25.1+dfsg-2
ii  python3-urwid 2.1.2-1
ii  python3-wcwidth   0.1.9+dfsg1-2

toot recommends no packages.

toot suggests no packages.

-- no debconf information

Bug#1040221: toot: auth output needs a raw option

[debbug . toot]

Package: toot
Version: 0.27.0-1
Severity: wishlist
X-Debbugs-Cc: debbug.t...@sideload.33mail.com

The “auth” command outputs a banner line followed by an
asterisk-prefixed list of accounts. It’s readable to humans but
requires some extra work to make usable for scripts. A common need is
to see the notifications on all accounts. For that I run:

  $ toot auth | awk '/^[*]/{print $2}' | while read acct; do toot notifications 
-r -u "$acct"; done

The status quo of human-readable output could be beautified at any
point, or perhaps more information could be added to the auth output
in the future. Whenever that changes, it may break scripts and
complicate the above hack to act on all accounts.

So I suggest adding a “--raw” option of sorts to make the awk command
pipe above unnecessary.

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages toot depends on:
ii  python3   3.9.2-3
ii  python3-bs4   4.9.3-1
ii  python3-requests  2.25.1+dfsg-2
ii  python3-urwid 2.1.2-1
ii  python3-wcwidth   0.1.9+dfsg1-2

toot recommends no packages.

toot suggests no packages.

-- no debconf information

Bug#1040218: toot: superscript digits replaced with full-sized digits

[debbug . toot]

Package: toot
Version: 0.27.0-1
Severity: minor
X-Debbugs-Cc: debbug.t...@sideload.33mail.com

When a message contains a superscript digit¹, the superscript is enlarged to a 
full-sized character.

¹ So “digit¹” is printed as “digit1”, even though the terminal can handle 
superscripts just fine.


-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages toot depends on:
ii  python3   3.9.2-3
ii  python3-bs4   4.9.3-1
ii  python3-requests  2.25.1+dfsg-2
ii  python3-urwid 2.1.2-1
ii  python3-wcwidth   0.1.9+dfsg1-2

toot recommends no packages.

toot suggests no packages.

-- no debconf information

Bug#1039563: qa.debian.org: Bug vs. feature bug suppression tactic

[debbug . 1039563]

Package: qa.debian.org
Followup-For: Bug #1039563
X-Debbugs-Cc: debbug.1039...@sideload.33mail.com

>> This is an example of different opinions about bug >< feature.
> …
> Trying to pick apart the example is an unhelpful distraction to the
> discussion of whether the Debian project should have a procedure for
> tracking mishandled bugs.

I should elaborate further. The “bug vs. feature” bug suppression
tactic is so effective and common that it has become a knee-jerk
response by anyone looking to refuse a bug report, or those just
looking for a quick and dirty way to push bugs out of the triage
effort.

Bug 1026922 demonstrates an abuse of the bug-feature bug-swatting
technique. So actually the “bug vs. feature” debate is relevant to
1039563 in the sense that it showcases an irrational action-- one that
solving bug 1039563 mitigates. That is, if bugs reach the wontfix
stage as a consequence of a bug-vs-feature tactic, it could be marked
as such. The quality of Debian packages can then improve by isolating
these cases and counting them. If it’s happening often enough, the QA
team could draft a criteria which would distinguish the more genuine
bug-vs-feature cases from the irrational ones like that of bug
1026922.

Bug#1039563: qa.debian.org: Procedure needed to report mishandled bug reports

[debbug . 1039563]

Package: qa.debian.org
Followup-For: Bug #1039563
X-Debbugs-Cc: debbug.1039...@sideload.33mail.com

* Bart Martens 'ba...@debian.org' via 33Mail  
[2023-06-29 07:39]:
> 
> This is an example of different opinions about bug >< feature.

Do you really believe it’s an /opinion/ to say a SOCKS proxy is an
HTTP proxy?  It’s not a matter of opinion. It’s a factual matter. When
someone botches the facts, we don’t call it an opinion. It’s a
falsehood. An HTTP proxy is not a SOCKS proxy, and a SOCKS proxy is
not an HTTP proxy.

Trying to pick apart the example is an unhelpful distraction to the
discussion of whether the Debian project should have a procedure for
tracking mishandled bugs.

> Quoting from 1026922:
> > Directing users to report bugs upstream goes against Debian
> > conventions. It’s the duty of the maintainer to mirror bugs upstream:
> >   https://www.debian.org/Bugs/Reporting
> 
> This text is about preventing duplicate effort.

No it’s not. It’s about following Debian guidelines. Whether those
guidelines call for “duplicate effort” is irrelevant here. If someone
doesn’t like the documented Debian procedure of reporting bugs to the
Debian BTS first and then escalating upstream from there, bug 1039563
is not the place for that discussion.

> I understand your frustration. I doubt however that wrapping 1026922
> in a request for addressing mishandled bugs would be helpful.

Bug 1026922 is about as perfect of an example as you’re going to get
because unlike most bug reports there is little room for
subjectivity. Proper handling of the bug was to mirror upstream and
send “control: forwarded 1026922 http://github.com/…”. That did not
happen.

There needs to be a mechanism by which these cases can be flagged so
the community can assess the quality of a package and so developers
can easily find and fix suppressed bugs.

Bug#1039563: qa.debian.org: Procedure needed to report mishandled bug reports

[debbug . app]

Package: qa.debian.org
Severity: wishlist
X-Debbugs-Cc: debbug@sideload.33mail.com

Control: affects -1 +www.debian.org

When a bug report is mishandled there should be a documented procedure
in place by which the mishandling can be reported to the Debian QA
team. There should be metrics in place to make it easy to look for
patterns of bug mishandling. And there should be some oversight so a
QA member can intervene on specific bugs if a constructive action can
be taken.

Currently there is no such procedure (or I failed to find it). I
expected to find it in these locations:

  https://wiki.debian.org/BTS
  https://www.debian.org/Bugs

Debian bugs are mishandled too often, which suggests there is no
oversight of mishandled cases. I have an example at hand:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026922

A valid, credible bug report was tagged “wontfix”, which in itself is
often fair enough but in this case the action /should/ have been to
mirror the bug report upstream because upstream is the source of the
bug. “wontfix” would only be sensible if the source of the bug was in
the debian pkging & the Debian maintainer opts not to fix it in
Debian. A possible secondary mishandling of that bug was early
archival as a means of suppression:

  “Bug archived. Request was from Debbugs Internal Request
to internal_cont...@bugs.debian.org.
   (Sat, 04 Mar 2023 07:26:51 GMT) (full text, mbox, link).”

Whether an intervention on bug 1026922 is a good move or not doesn’t
matter. Perhaps it’d be over-the-top. But regardless, there should be
some record of the mishandling so if a pattern develops it can be
noticed & acted on summarily. Or at least users could use bug
mishandling stats to appraise the quality of a package before deciding
to depend on it.

Bug#1038664: toot: save local copies of every new outbound message

[debbug . toot]

Package: toot
Version: 0.27.0-1
Severity: wishlist
X-Debbugs-Cc: debbug.t...@sideload.33mail.com

The Mastodon export feature is insufficient:

 * countless events can separate users from their data at any unannounced 
spontaneous moment
 * users can only request archives once every 7 days, thus ≥3½ days of dataloss 
is expected on avg.
 * the request is a cumbersome manual process (thus not done every 7 days)

There is a request to implement CLI-driven archival:

  https://github.com/ihabunek/toot/issues/201

That feature would be useful, but it’s still only a partial
solution. In addition to periodic archivals it would be very useful
for individual messages to be stored locally to mitigate the loss of
data generated since the last fetched archival, just as an email
client would do.

Bonus points if those messages are formatted in mbox format or maildir
format, so we can simply use a mail user agent to browse recent
outbound msgs.

Optionally, it would be interesting if users had the /option/ of
having these cached msgs deleted upon the successful fetching of their
archive (assuming GH bug 201 is satisfied).

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages toot depends on:
ii  python3   3.9.2-3
ii  python3-bs4   4.9.3-1
ii  python3-requests  2.25.1+dfsg-2
ii  python3-urwid 2.1.2-1
ii  python3-wcwidth   0.1.9+dfsg1-2

toot recommends no packages.

toot suggests no packages.

-- no debconf information

Bug#1038659: toot: polls are useless in the CLI

[debbug . toot]

Package: toot
Version: 0.27.0-1
Severity: normal
X-Debbugs-Cc: debbug.t...@sideload.33mail.com

Polls are void in CLI output. The body is there, but the ballot is
simply omitted. And it’s omitted in a such a way that you don’t even
know there is a poll. So you end up seeing /part/ of a status that
ends up being confusing & useless.

I’m sure it’s not an oversight at this point. Perhaps there is some
complexity involved. If so, I suggest doing a quick placeholder of
some kind so users at least know that a poll is missing. E.g. print in
red letters somewhere: “[poll output not implemented in this
version]”. Users would at least then know to get a dump of the raw
post whenever this feature gets added:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038651

or to view it in the tui.

In the long term, it’s worth noting that *no client* does polls
well. You only ever see the votes that your server has received. In
principle, these are subset and can be misleading. So ideally the
votes should be counted at the server that hosted the poll, not the
local server (if possible).

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages toot depends on:
ii  python3   3.9.2-3
ii  python3-bs4   4.9.3-1
ii  python3-requests  2.25.1+dfsg-2
ii  python3-urwid 2.1.2-1
ii  python3-wcwidth   0.1.9+dfsg1-2

toot recommends no packages.

toot suggests no packages.

-- no debconf information

Bug#1038651: toot: a CLI mechanism to dump the raw source of a status would be useful

[debbug . toot]

Package: toot
Version: 0.27.0-1
Severity: wishlist
X-Debbugs-Cc: debbug.t...@sideload.33mail.com

The plaintext of a status given on the commandline is an incomplete
representation of the status. There are lots of metadata attributes
being hidden from view as well as poll data. Most of the time it’s
sufficient. But it would be very useful to be able to dump the raw
JSON record for a given status.  As the app matures, the need for raw
record dumps will diminish. But until then the full contents of the
JSON record would be useful.

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages toot depends on:
ii  python3   3.9.2-3
ii  python3-bs4   4.9.3-1
ii  python3-requests  2.25.1+dfsg-2
ii  python3-urwid 2.1.2-1
ii  python3-wcwidth   0.1.9+dfsg1-2

toot recommends no packages.

toot suggests no packages.

-- no debconf information

Bug#1038629: toot: whois command lacks follow status & follower/following lists unreachable

[debbug . toot]

Package: toot
Version: 0.27.0-1
Severity: wishlist
X-Debbugs-Cc: debbug.t...@sideload.33mail.com

The /whois/ command gives the profile of a user as expected, but it
neglects to state whether that user follows me & also neglects to
disclose whether I am following that other account. It would be *very*
useful if that information were included in the whois output. It’s the
most basic info you generally want to know when visiting a profile.

Apart from the /whois/ command (which operates on one account at a
time), it would also be very useful to query for the whole list of
accounts who follow me and accounts I am following.

One use-case (apart from account migration) is follow reciprocity. If
someone follows me, I look at their timeline. If a substantial portion
of their posts are in a language I understand and the content is
generally acceptible, I follow back. If I do not follow back
(e.g. they have no timeline at the time), it would be useful to
periodically examine the asymetric follow cases and re-review whether
to follow or unfollow.

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages toot depends on:
ii  python3   3.9.2-3
ii  python3-bs4   4.9.3-1
ii  python3-requests  2.25.1+dfsg-2
ii  python3-urwid 2.1.2-1
ii  python3-wcwidth   0.1.9+dfsg1-2

toot recommends no packages.

toot suggests no packages.

-- no debconf information

Bug#1038379: toot: display name sticks after erasure

[debbug . toot]

Package: toot
Version: 0.27.0-1
Severity: minor
X-Debbugs-Cc: debbug.t...@sideload.33mail.com

I created a new Mastodon account with a display name. Then established
that account in /toot/ using the “login” CLI command. I later erased
the display name in the web client. But in subsequent usage of the
/toot/ app, references to the original display name still persisted. I
don’t recall where, but likely when doing a “toot post” from the
CLI. It’s a bit surprising that /toot/ would keep a copy of it since
it’s unlikely needed for any operations. In principle it should be the
server that conveys that sort of profile information.

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages toot depends on:
ii  python3   3.9.2-3
ii  python3-bs4   4.9.3-1
ii  python3-requests  2.25.1+dfsg-2
ii  python3-urwid 2.1.2-1
ii  python3-wcwidth   0.1.9+dfsg1-2

toot recommends no packages.

toot suggests no packages.

-- no debconf information

Bug#1038378: toot: Capability to import external statuses needed

[debbug . toot]

Package: toot
Version: 0.27.0-1
Severity: normal
X-Debbugs-Cc: debbug.t...@sideload.33mail.com

When viewing posts in a logged-out GUI browser and there is a need to
interact with some arbitrary post, toot is nearly useless. All the
toot interaction commands rely on having a local msg ID which may or
may not exist. And even when it exists it’s sometimes impossible to
obtain. It’s a serious hassle to search hashtags within /toot/ in
attempt to reveal the local msg ID. If no hashtag exists & the user is
unknown to the local instance, toot users are stuffed.

The web client is capable of searching using the URL of an external
post as the query. If a local copy of the msg does not exist, it is
imported so users can interact with it. Toot needs this import
capability. Running this:

  $ toot search "$URL_to_post"

yields the response “nothing found”. Running:

  $ toot timeline --help

reveals that there is no way to specify an URL to a post, only tags or
the typical timeline selections. Ideally users should be able to run:

  $ toot search "$URL_to_post"

and it should either respond with:

  “that post has a local copy with an ID of 1234…”

OR

  “that post does not exist locally. Would you like to import it? [Y/n]”

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages toot depends on:
ii  python3   3.9.2-3
ii  python3-bs4   4.9.3-1
ii  python3-requests  2.25.1+dfsg-2
ii  python3-urwid 2.1.2-1
ii  python3-wcwidth   0.1.9+dfsg1-2

toot recommends no packages.

toot suggests no packages.

-- no debconf information

Bug#1038338: toot: “toot post --media” lacks URL support

[debbug . toot]

Package: toot
Version: 0.27.0-1
Severity: wishlist
X-Debbugs-Cc: debbug.t...@sideload.33mail.com

It’s quite cool that we can simply upload an image using the CLI
“upload” command and make no reference to it in a toot, effectively
using any Mastodon node as an image pastebin. But surely this was not
the intent. There should be an in-band usage for the URL that is
returned after uploading media. There is no documented way to use
those URLs.

Naturally the CLI /post/ command should be able to make use of media
URLs. Intuitively, this should do the job:

 $ toot post --media "$media_url"; ← does not work

The parameter supplied with the --media option must be a path to a
local file. So what happens is users upload an image using the
/upload/ CLI command, they get a useless URL back, and then they use
the /post/ command which forces them to specify a local filename
again. The user does so, which then presumably results in two copies
of the same media on the server.

If the --media option is coded to support URLs, this would not only
make the /upload/ command more useful, it would even make it possible
for multiple posts to refer to the same media file, thus not wasting
disk space on the server. It would also enable users to embed
references to external images without storing them on the local server
at all.

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages toot depends on:
ii  python3   3.9.2-3
ii  python3-bs4   4.9.3-1
ii  python3-requests  2.25.1+dfsg-2
ii  python3-urwid 2.1.2-1
ii  python3-wcwidth   0.1.9+dfsg1-2

toot recommends no packages.

toot suggests no packages.

-- no debconf information

Bug#1038337: sway: mouse clicking dead region on external display device (negative Y coordinates zeroized)

[debbug . sway]

Package: sway
Version: 1.5-7
Severity: important
X-Debbugs-Cc: debbug.s...@sideload.33mail.com

Laptop has a larger external display positioned to the right of the
laptop and raised a bit, like this:

 +-+
 | |
 | |
  +---+  | |
  |   |  | external display|
  |  laptop   |  | |
  |   |  +-+
  +---+

The configuration requires using a negative coordinate so the pointer
arrow can move seamlessly between the displays.

~/.config/sway/config:

===8<--
output LVDS-1 pos 0 0
output VGA-1 pos 1280 -275
===8<--

The top area on the external display is non-responsive to clicks. This
is likely the whole area where the Y coordinate is negative.

This is perhaps slightly related to this issue:

  https://github.com/swaywm/sway/issues/7528

But in my case, the output is fine. It’s just the mouse clicking that
is clipped. The mouse can move the pointer around in dead area fine--
it’s apparently just clicking that is not possible. Keyboard input is
also fine in that region. If a text editor is open with the cursor is
low on the screen and the dead region is clicked, the cursor moves to
the first line below the dead region. Clicking on a scrollbar in the
dead area causes the top of the scrollbar to jump to the top of the
non-dead region, but never higher. So clicking is not entirely ignored
but rather treated as if clicked on the zero Y coordinate screen.

===8<--
$ swaymsg -t get_version
sway version v1.5

$ swaymsg -t get_outputs
Output LVDS-1 'Lenovo…'
  Current mode: 1280x800 @ 60.001999 Hz
  Position: 0,0
  Scale factor: 1.00
  Scale filter: nearest
  Subpixel hinting: rgb
  Transform: normal
  Workspace: 1
  Max render time: off
  Adaptive sync: disabled
  Available modes:
1280x800 @ 50.002998 Hz
1280x800 @ 60.001999 Hz

Output VGA-1 'Dell Inc.…'
  Current mode: 1920x1080 @ 60.00 Hz
  Position: 1280,-275
  Scale factor: 1.00
  Scale filter: nearest
  Subpixel hinting: unknown
  Transform: normal
  Workspace: 2
  Max render time: off
  Adaptive sync: disabled
  Available modes:
720x400 @ 70.082001 Hz
640x480 @ 59.93 Hz
640x480 @ 75.00 Hz
800x600 @ 60.317001 Hz
800x600 @ 75.00 Hz
1024x768 @ 60.004002 Hz
1024x768 @ 75.028999 Hz
1152x864 @ 75.00 Hz
1280x1024 @ 60.02 Hz
1280x1024 @ 75.025002 Hz
1920x1080 @ 60.00 Hz
===8<--

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sway depends on:
ii  libc62.31-13+deb11u5
ii  libcairo21.16.0-5
ii  libevdev21.11.0+dfsg-1
ii  libgdk-pixbuf2.0-0   2.40.2-2
ii  libgl1-mesa-dri  20.3.5-1
ii  libgles2 1.3.2-1
ii  libglib2.0-0 2.66.8-1
ii  libinput10   1.16.4-3
ii  libjson-c5   0.15-2
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpcre3 2:8.39-13
ii  libpixman-1-00.40.0-1.1~deb11u1
ii  libsystemd0  247.3-7+deb11u1
ii  libwayland-client0   1.18.0-2~exp1.1
ii  libwayland-cursor0   1.18.0-2~exp1.1
ii  libwayland-server0   1.18.0-2~exp1.1
ii  libwlroots6  0.11.0-3
ii  libxcb1  1.14-3
ii  libxkbcommon01.0.3-2
ii  policykit-1  0.105-31+deb11u1
ii  swaybg   1.0-2

Versions of packages sway recommends:
ii  foot  1.6.4-1
ii  suckless-tools46-1
ii  sway-backgrounds  1.5-7

Versions of packages sway suggests:
pn  swayidle
pn  swaylock
pn  xdg-desktop-portal-wlr  

-- no debconf information

Bug#1026922: golang-go: how HTTP*_PROXY should work v.s. how it operates currently

[debbug . 1026922]

Package: golang-go
Version: 2:1.15~1
Followup-For: Bug #1026922
X-Debbugs-Cc: debbug.1026...@sideload.33mail.com

HD> I’d suppose there is a misunderstanding: HTTP_PROXY is used to
HD> specify the proxy options of all HTTP connections, and HTTPS_PROXY
HD> is used by HTTPS connections. Only in this way the names of
HD> ALL_PROXY and NO_PROXY could make sense.

What you describe is how the HTTP*_PROXY variables *should* work. But
that’s not the case. For example, users of the Hydroxide app (written
in Go) are being told to run:

  HTTPS_PROXY='socks5://127.0.0.1:9050' hydroxide $args

See the problem?  SOCKS has nothing to do with HTTP(S). SOCKS proxies
cannot serve as an HTTP proxy because HTTP proxies are
protocol-specific. A SOCKS proxy is protocol independant.

Bug#1026922: golang-go: more action needed

[debbug . 1026922]

Package: golang-go
Version: 2:1.15~1
Followup-For: Bug #1026922
X-Debbugs-Cc: debbug.1026...@sideload.33mail.com

> This is exactly feature that Go upstream provides for a long time.
> If you think differently, you should open a "proposal" in Go upstream,
> https://github.com/golang/proposal#the-proposal-process

“Feature” is the wrong word here. Use of incorrect terminology &
misstating a usage is a plainly obvious defect. The incorrectness of
(e.g.) calling a “potato” a “tomato” leaves no room for
subjectivity. It’s a bug. Consequently, a bug report was filed (not a
feature proposal).

To say it’s been that way “a long time” is known as a /Conventional
Wisdom/ fallacy. The bug does not become less of a bug over time. The
only effect that time has in this case is to do more damage, as more
and more code creates dependencies on the defect. Go lang itself is
also a quite young language, coming into existence in 2009. So nothing
about the language has existed for “a long time”.

Directing users to report bugs upstream goes against Debian
conventions. It’s the duty of the maintainer to mirror bugs upstream:

  https://www.debian.org/Bugs/Reporting

Not everyone has MS Github. Not everyone is willing to have
transactions with Microsoft. I cannot login to Github because the 2fa
process forces me to check an account that blocks access to the
verification code with a broken CAPTCHA.

Please follow the Debian procedure and mirror this bug report
upstream; not as a proposed new feature but as a bug report.

Thank you.

Bug#1027985: tesseract-ocr: document gets rotated on its side when converting from jpg to pdf

[debbug . tesseract]

Package: tesseract-ocr
Version: 4.1.1-2.1
Severity: normal
X-Debbugs-Cc: debbug.tesser...@sideload.33mail.com

When tesseract is fed a JPG image of an upright document and
instructed to produce a searchable PDF, it flips the image on its
side. The rotation apparently happens before OCR is performed judging
from the text produced (as pdf2txt shows it as one character per
line). This is the syntax used:

  $ tesseract color_document.jpg sideways_doc -l eng+nld pdf

The workaround is quite ugly:

  $ pdftk doc_sideways_doc.pdf cat 1-r1east output upright_doc.pdf
  $ ocrmypdf --force-ocr -l eng+nld upright_doc.pdf proper.pdf

I don’t think this bug affects every document. It’s perhaps trying to
be smart and detect the orientation of the doc & misjudging it. If
that’s true, it’s a shame that tesseract does this automatically and
beyond the control of the user. There is no option to force tesseract
to leave the orientation as-is.

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tesseract-ocr depends on:
ii  libarchive13 3.4.3-2+deb11u1
ii  libc62.31-13+deb11u5
ii  libcairo21.16.0-5
ii  libfontconfig1   2.13.1-4.2
ii  libgcc-s110.2.1-6
ii  libglib2.0-0 2.66.8-1
ii  libicu67 67.1-7
ii  liblept5 1.79.0-1.1
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpangoft2-1.0-01.46.2-3
ii  libstdc++6   10.2.1-6
ii  libtesseract44.1.1-2.1
ii  tesseract-ocr-eng1:4.00~git30-7274cfa-1.1
ii  tesseract-ocr-osd1:4.00~git30-7274cfa-1.1

tesseract-ocr recommends no packages.

tesseract-ocr suggests no packages.

-- no debconf information

Bug#1027923: vorbis-tools: Ogg123 fails to play streams (“Error opening - using the oggvorbis module. The file may be corrupted.”)

[debbug . vorbis-tools]

Package: vorbis-tools
Version: 1.4.0-11+b1
Severity: normal
X-Debbugs-Cc: debbug.vorbis-to...@sideload.33mail.com

Ogg streams cannot be played. Three different approaches were tested:

  $ ogg123 http://ice.audionow.com/4692NationwideNewsNetworkLtdopus.ogg
  $ curl -L -v http://ice.audionow.com/4692NationwideNewsNetworkLtdopus.ogg | 
ogg123 -

  2-step approach also fails:
  
  $ curl -L -v http://ice.audionow.com/4692NationwideNewsNetworkLtdopus.ogg > 
/tmp/stream.ogg
  $ ogg123 /tmp/stream.ogg

Output:

  Error opening - using the oggvorbis module.  The file may be corrupted.

Diagnosis:

  $ file /tmp/stream.ogg
  /tmp/stream.ogg: Ogg data, Opus audio,

  $ ogginfo /tmp/stream.ogg
  Processing file "/tmp/stream.ogg"...

  New logical stream (#1, serial: 09e3c2b7): type unknown
  WARNING: sequence number gap in stream 1. Got page 75226 when expecting page 
2. Indicates missing data.
  WARNING: EOS not set on stream 1

FWIW, some info on the audio stream used in the above tests can be found here:

  https://www.radio-browser.info/history/96149bcc-0601-11e8-ae97-52543be04c81

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages vorbis-tools depends on:
ii  libao4   1.2.2+20180113-1.1
ii  libc62.31-13+deb11u5
ii  libcurl3-gnutls  7.74.0-1.3+deb11u3
ii  libflac8 1.3.3-2+deb11u1
ii  libogg0  1.3.4-0.1
ii  libspeex11.2~rc1.2-1.1
ii  libvorbis0a  1.3.7-1
ii  libvorbisenc21.3.7-1
ii  libvorbisfile3   1.3.7-1
ii  sensible-utils   0.0.14

vorbis-tools recommends no packages.

vorbis-tools suggests no packages.

-- no debconf information

Bug#1026928: wget: “Cannot write to ‘myfile.mp3’ (Permission denied).” when using the default profile.

[debbug . firejail]

Package: firejail
Version: 0.9.64.4-2
Followup-For: Bug #1026928
X-Debbugs-Cc: debbug.firej...@sideload.33mail.com

> I can't reproduce it yet. What do you mean with "local directory"?
> Your home directory? Is there anything special about this directory?
> Please provide full output when running firejail with --debug.

I meant the "$CWD", which was something like /collection/music. There
is nothing special about the directory. I have write permission and in
fact it has no problem writing the file if I use --noprofile.

I ran it again using --debug. There is a huge amount of output which
would be cumbersome to sanitize, but not enough output at the very end
where it fails:

===8<--
Current directory: /collection/music
…
Connecting to web.archive.org (web.archive.org)|207.241.237.3|:80... connected.
HTTP request sent, awaiting response... 302 FOUND
Location: http://web.archive.org/web/«url» [following]
--«timestamp»--   http://web.archive.org/web/«url»
Reusing existing connection to web.archive.org:80.
HTTP request sent, awaiting response... 200 OK
Length: 33763692 (35M) [audio/mpeg]
myfile.mp3: Permission denied

Cannot write to ‘myfile.mp3’ (Permission denied).
Sandbox monitor: waitpid 15 retval 15 status 768
===8<--

Perhaps it was fixed in a later version. I’m using Firejail 0.9.64.4-2
(apparently with cgroup=no for some reason) & GNU Wget 1.21.

Bug#1026928: wget: “Cannot write to ‘myfile.mp3’ (Permission denied).” when using the default profile.

[debbug . firejail]

Package: firejail
Version: 0.9.64.4-2
Severity: normal
X-Debbugs-Cc: debbug.firej...@sideload.33mail.com

There is no problem if the --noprofile option is given.  But if
firejail is allowed to use the default profile
(/etc/firejail/wget.profile), fetched files cannot be written to the
local directory.

===8<--
  $ firejail --net=vnet0 --dns="$mydns" --noblacklist=. wget --no-netrc "$url"
  --«timestamp»--  «url»
  Resolving web.archive.org (web.archive.org)... 207.241.237.3
  Connecting to web.archive.org (web.archive.org)|207.241.237.3|:80... 
connected.
  HTTP request sent, awaiting response... 302 FOUND
  Location: http://web.archive.org/web/«url» [following]
  --«timestamp»--  http://web.archive.org/web/«url»
  Reusing existing connection to web.archive.org:80.
  HTTP request sent, awaiting response... 200 OK
  Length: 33763692 (36M) [audio/mpeg]
  myfile.mp3: Permission denied

  Cannot write to ‘myfile.mp3’ (Permission denied).
===8<--

This is /etc/firejail/wget.profile:

===8<--
  # Firejail profile for wget
  # Description: Retrieves files from the web
  # This file is overwritten after every install/update
  quiet
  # Persistent local customizations
  include wget.local
  # Persistent global definitions
  include globals.local

  noblacklist ${HOME}/.netrc
  noblacklist ${HOME}/.wget-hsts
  noblacklist ${HOME}/.wgetrc

  blacklist /tmp/.X11-unix
  blacklist ${RUNUSER}

  include disable-common.inc
  include disable-devel.inc
  include disable-exec.inc
  include disable-interpreters.inc
  include disable-passwdmgr.inc
  include disable-programs.inc
  include disable-shell.inc
  # depending on workflow you can uncomment the below or put 'include 
disable-xdg.inc' in your wget.local
  #include disable-xdg.inc

  include whitelist-usr-share-common.inc
  include whitelist-var-common.inc

  apparmor
  caps.drop all
  ipc-namespace
  machine-id
  netfilter
  no3d
  nodvd
  nogroups
  nonewprivs
  noroot
  nosound
  notv
  nou2f
  novideo
  protocol unix,inet,inet6
  seccomp
  seccomp.block-secondary
  shell none
  tracelog

  private-bin wget
  private-cache
  private-dev
  # depending on workflow you can uncomment the below or put this private-etc 
in your wget.local
  #private-etc 
alternatives,ca-certificates,crypto-policies,pki,resolv.conf,ssl,wgetrc
  #private-tmp

  dbus-user none
  dbus-system none

  memory-deny-write-execute
===8<--

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firejail depends on:
ii  libapparmor1  2.13.6-10
ii  libc6 2.31-13+deb11u5
ii  libselinux1   3.1-3

Versions of packages firejail recommends:
ii  firejail-profiles  0.9.64.4-2+deb11u1
ii  iproute2   5.10.0-4
ii  iptables   1.8.7-1
ii  xauth  1:1.1-1
ii  xdg-dbus-proxy 0.1.2-2
ii  xpra   3.0.13+dfsg1-1
ii  xvfb   2:1.20.11-1+deb11u3

firejail suggests no packages.

-- Configuration Files:
/etc/firejail/firejail.config changed:
cgroup no


-- no debconf information

Bug#1026922: golang-go: The HTTP_PROXY variable is incorrectly implemented to accept SOCKS proxies. HTTP≠SOCKS

[debbug . golang]

Package: golang-go
Version: 2:1.15~1
Severity: normal
X-Debbugs-Cc: debbug.gol...@sideload.33mail.com

The go standard libraries apparently include some automatic proxy
support for /go/ apps when the HTTPS_PROXY variable is populated. The
problem is that SOCKS proxies are accepted. A SOCKS proxy is a
different beast than an HTTP proxy. The HTTP*_PROXY variables are
conventially used by browsers to specify HTTP proxies. It’s misleading
and wrong to use it to specify SOCKS proxies.

Here is an example of an app that uses the /go/ standard libs in this
way:

  https://github.com/emersion/hydroxide/issues/110#issuecomment-751387567

URLs with the socks*:// scheme should be refused & trigger an error.

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages golang-go depends on:
ii  golang-1.15-go  1.15.15-1~deb11u4
ii  golang-src  2:1.15~1

golang-go recommends no packages.

Versions of packages golang-go suggests:
ii  git  1:2.30.2-1

-- no debconf information

Bug#1026430: profanity: If an OMEMO msg to 2+ recipients & 1 recipient’s pubkey is bad, the msg is sent anyway (a logistical mess)

[debbug . profanity]

Package: profanity
Version: 0.13.1-1~bpo11+1
Severity: normal
X-Debbugs-Cc: debbug.profan...@sideload.33mail.com

If a message is sent in a chat room with multiple recipients, and
Profanity fails to get a handle on the public key for one of the
recipients, Profanity simply neglects to use the key it needs and
sends the msg anyway to all recipients. So the recipient whose pubkey
was neglected receives a non-decryptable message which then manifests
into a bogus error falsely telling the recipient that their XMPP
client does not support OMEMO (which apparently is the text portion of
the message).

Scenario:

  Suppose Rob & Rennae are recipients of Sam’s msg, and Rennae’s
  pubkey was lost. Rob receives the msg okay but he does not likely
  know that the msg failed for Rennae. Sam expected both recipients to
  receive the same msg at roughly the same time. So Sam is forced to
  scramble to solve the pubkey problem and quickly send a copy to
  Rennae. But Sam does not want Rob to recieve duplicate copy of the
  same message, so Sam must resend the msg just to Rennae. Sam also
  must tell Rennae that he botched the transmission, and also tell
  Rennae that Rob already received the same message. Rennae must trust
  that Sam did not alter the message. This nightmare of a bug causes
  embarrassment for Sam and demoralizes Rob & Rennae as far as XMPP
  goes.

There are actually 4 bugs here:

1. (already reported) Profanity failed to find the public key for
recipient even though Profanity recently just used the pubkey
successfully. This bug has already been reported separately (bug
1024899)

2. All or nothing policy needed-- when a msg is known to fail for a
group, Profanity should not send the msg to anyone. Profanity did not
even warn the sender of the problem; it just took the liberty of
encrypting the msg to X recipients and transmitting it to Y
recipients, where X > Y. Only after the transmission does Profanity
inform the sender of the problem. This creates a logistical mess for
the sender. In the scenario given, Profanity should either refuse the
send the message entirely, or it should give Sam an informed choice to
send the message anyway knowing that delivery will be botched and
problematic.

3. When a msg is expected to fail for one recipient among many,
Profanity should not send it to recipients where it is known to
fail. Notwithstanding bug 2 above, even if a sender opts to send a
message anyway, there is still no reason to transmit the msg to the
recipient who Profanity knows cannot decrypt it.

4. The error msg seen by the recipient is (apparently) the text
portion of the encrypted payload, which generically tells the
recipient that their client does not support OMEMO. The receiving
client simply presents that text to the user of that client. This
message is bogus. Just because Profanity cannot find the pubkey does
not mean the receiving client does not support OMEMO. The text msg
should not take liberties of making speculative or unlikely claims
about what the issue is. Profanity also should not assume when
phrasing the text that the bug or deficiency is necessarily on the
recipient’s side.


-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages profanity depends on:
ii  libc6  2.31-13+deb11u5
ii  libcurl3-gnutls7.74.0-1.3+deb11u3
ii  libgcrypt201.8.7-6
ii  libgdk-pixbuf-2.0-02.42.2+dfsg-1+deb11u1
ii  libglib2.0-0   2.66.8-1
ii  libgpgme11 1.14.0-1+b2
ii  libgtk-3-0 3.24.24-4+deb11u2
ii  libncursesw6   6.2+20201114-2
ii  libnotify4 0.7.9-3
ii  libotr54.1.1-4
ii  libpython3.9   3.9.2-1
ii  libreadline8   8.1-1
ii  libsignal-protocol-c2.3.2  2.3.3-1
ii  libsqlite3-0   3.34.1-3
ii  libstrophe00.12.2-1~bpo11+1
ii  libtinfo6  6.2+20201114-2

profanity recommends no packages.

profanity suggests no packages.

-- no debconf information

Bug#1026109: firejail: “Error fbuilder: invalid program” when pairing --build & --env options together

[debbug . firejail]

Package: firejail
Version: 0.9.64.4-2
Severity: normal
X-Debbugs-Cc: debbug.firej...@sideload.33mail.com

Ran this:

  ===8<--
  $ LC_ALL=C firejail --build=kalium.profile --net=vnet0 --dns=$mydns 
--env=XDG_CONFIG_HOME="${myconfig_dir}" /usr/local/src/kalium/gradlew jvmTest
  ===8<--

Output:

  ===8<--
  Error fbuilder: invalid program
  Firejail profile builder
  Usage: firejail [--debug] --build[=profile-file] program-and-arguments
  ===8<--

Omitting “--build=kalium.profile” is syntactically accepted, but it
craps out with lots of other errors. Omitting “--env=…” is also
syntactically accepted. Apparently “--build=kalium.profile” &
“--env=…” options cannot be used together.

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firejail depends on:
ii  libapparmor1  2.13.6-10
ii  libc6 2.31-13+deb11u5
ii  libselinux1   3.1-3

Versions of packages firejail recommends:
ii  firejail-profiles  0.9.64.4-2+deb11u1
ii  iproute2   5.10.0-4
ii  iptables   1.8.7-1
ii  xauth  1:1.1-1
ii  xdg-dbus-proxy 0.1.2-2
ii  xpra   3.0.13+dfsg1-1
ii  xvfb   2:1.20.11-1+deb11u3

firejail suggests no packages.

-- Configuration Files:
/etc/firejail/firejail.config changed:
cgroup no

-- no debconf information

Bug#1025856: tesseract-ocr: (regression) File descriptors no longer work for input (“Error in fopenReadStream: file not found”)

[debbug . tesseract]

Package: tesseract-ocr
Version: 4.1.1-2.1
Severity: normal
X-Debbugs-Cc: debbug.tesser...@sideload.33mail.com

I have this line in an old shell script:

  $ tesseract <(convert "$jpgFile" +dither -colors 2 -normalize -resize 1 
pbm:-) - -l eng

Today that line fails with this output:

  =8<--
  Error in fopenReadStream: file not found
  Error in pixRead: image file not found: P4
  Image file P4 cannot be read!
  Error during processing.
  =8<--

The fact that the command was in an old shell script suggests that it
likely worked at one point in time. But certainly version 4.1.1-2.1 of
tesseract-ocr cannot handle shell-substituted files.

This report actually covers two bugs:

  1) tesseract-ocr fails to process shell-substituted files.
  
  2) tesseract-ocr does not inform the user. It should give a graceful
 error msg. That is, if there is no intent to support
 shell-substituted files, then the app should detect when such a
 file is specified and inform the user using plain English in the
 error msg stating that shell-substituted files are unsupported.
 The man page should also disclose this limitation either in the
 paragraph that covers the input file spec and/or in a new section
 titled “LIMITATIONS”.  Or if there is intent to support
 substitution files, then it should be explicitly stated in the
 man page.

Workaround:

  If ImageMagick is executed separately to populate a regular file,
  tesseract has no problem with using that regular file as input.

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tesseract-ocr depends on:
ii  libarchive13 3.4.3-2+deb11u1
ii  libc62.31-13+deb11u5
ii  libcairo21.16.0-5
ii  libfontconfig1   2.13.1-4.2
ii  libgcc-s110.2.1-6
ii  libglib2.0-0 2.66.8-1
ii  libicu67 67.1-7
ii  liblept5 1.79.0-1.1
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpangoft2-1.0-01.46.2-3
ii  libstdc++6   10.2.1-6
ii  libtesseract44.1.1-2.1
ii  tesseract-ocr-eng1:4.00~git30-7274cfa-1.1
ii  tesseract-ocr-osd1:4.00~git30-7274cfa-1.1

tesseract-ocr recommends no packages.

tesseract-ocr suggests no packages.

-- no debconf information

Bug#1024899: profanity: some Profanity → Beagle OMEMO msgs give “This message cannot be decrypted for any recipient.”

[debbug . profanity]

Package: profanity
Version: 0.13.1-1~bpo11+1
Severity: important
X-Debbugs-Cc: debbug.profan...@sideload.33mail.com

Configuration:

  Bob has 2 clients   → linux:Profanity & Android:Snikket
  Alice has 2 clients → macos:Beagle & iOS:Snikket
  server  → snikket.org

Bob’s Profanity and Snikket installations both trust both of Alice’s
fingerprints.

Alice   → Bob works
Bob (Snikket)   → Alice works
Bob (Profanity) → Alice broken

When Bob executes:

  /msg al...@foo.snikket.org Some text here.

Profanity gives:

===8<--
  01:23:45 ! This message cannot be decrypted for any recipient.
  
 You should trust your recipients' device fingerprint(s) using 
"/omemo trust FINGERPRINT".
 It could also be that the key bundle of the recipient(s) have not 
been received. In this case, you could try "omemo end", "omemo 
 start", and send the message again.
  
===8<--

The error msg suggestion to do “omemo end…start” worked, but it should
not have been necessary because the chat session was working
previously. That is, Bob successfully sent msgs already, then this
error came out of the blue.  A snip of the OMEMO session went like
this:

===8<--
  Alice (text) → Bob [success]
  Bob (text from Profanity) → Alice [success]
  Alice (images) → Bob [success]
  Bob (text from Profanity) → Alice [success]
  Bob (text from Profanity) → Alice [success]
  Alice (text) → Bob [success]
  Bob (text from Profanity) → Alice [failure!]
  Bob (text from Snikket) → Alice [success]
  (Bob) /omemo end
  (Bob) /omemo start
  Bob (text from Profanity) → Alice [apparent success from sending side but not 
yet confirmed by Alice]
===8<--

Bob must have had Alice’s keys all along since the past msgs were sent
without issue. It looks as if Profanity lost Alice’s keys
spontaneously. Bob should not have been interrupted with the missing
keys error which then forced Bob to stop & start OMEMO all of the
sudden.

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages profanity depends on:
ii  libc6  2.31-13+deb11u5
ii  libcurl3-gnutls7.74.0-1.3+deb11u3
ii  libgcrypt201.8.7-6
ii  libgdk-pixbuf-2.0-02.42.2+dfsg-1+deb11u1
ii  libglib2.0-0   2.66.8-1
ii  libgpgme11 1.14.0-1+b2
ii  libgtk-3-0 3.24.24-4+deb11u2
ii  libncursesw6   6.2+20201114-2
ii  libnotify4 0.7.9-3
ii  libotr54.1.1-4
ii  libpython3.9   3.9.2-1
ii  libreadline8   8.1-1
ii  libsignal-protocol-c2.3.2  2.3.3-1
ii  libsqlite3-0   3.34.1-3
ii  libstrophe00.12.2-1~bpo11+1
ii  libtinfo6  6.2+20201114-2

profanity recommends no packages.

profanity suggests no packages.

-- no debconf information

Bug#1017049: profanity: version 0.13 status

[debbug . 1017049]

Package: profanity
Version: 0.13.1-1~bpo11+1
Followup-For: Bug #1017049
X-Debbugs-Cc: debbug.profan...@sideload.33mail.com

After upgrading, bugs 1 & 3 from the OP still exist in version
0.13.1-1~bpo11+1. Bug 2 seems to be resolved. That is, “[OMEMO]”
indeed appears in the title bar when the channel is encrypted and
“[unencrypted]” appears in red otherwise. That’s good.

Bug 1: One could suggest that the title bar indicator is sufficient,
but I’d say it’s still too subtle to serve as acknowdgement to a
command. It’s important that the “[OMEMO]” continuously show how the
conversation is secured, but also when a user enters a command it’s a
better UX if an ack is received like other non-msg info (leading with
a bang “!”).

Bug 3: The /help omemo page still does not make it clear that for
group chats the command must be entered from within the window and the
“[]” must be omitted.

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages profanity depends on:
ii  libc6  2.31-13+deb11u5
ii  libcurl3-gnutls7.74.0-1.3+deb11u3
ii  libgcrypt201.8.7-6
ii  libgdk-pixbuf-2.0-02.42.2+dfsg-1+deb11u1
ii  libglib2.0-0   2.66.8-1
ii  libgpgme11 1.14.0-1+b2
ii  libgtk-3-0 3.24.24-4+deb11u2
ii  libncursesw6   6.2+20201114-2
ii  libnotify4 0.7.9-3
ii  libotr54.1.1-4
ii  libpython3.9   3.9.2-1
ii  libreadline8   8.1-1
ii  libsignal-protocol-c2.3.2  2.3.3-1
ii  libsqlite3-0   3.34.1-3
ii  libstrophe00.12.2-1~bpo11+1
ii  libtinfo6  6.2+20201114-2

profanity recommends no packages.

profanity suggests no packages.

-- no debconf information

Bug#1018218: bugs.debian.org: Pseudo-header needed for “affects” relationship

[debbug . 1018218]

> Yes, you can, because this:
> 
> > 3) add support for a placeholder bug number like “-1” (similar to how
> > the clone command works)
> 
> is an intrinsic part of how the "Control" pseudo-header works.

Somehow I missed that, even though I was looking. There are several
docs on the bug tracker and the doc I found seemed to only indicate
that -1 was used in the cloning context.

Sorry for the trouble.

Bug#1018218: bugs.debian.org: Pseudo-header needed for “affects” relationship

[debbug . debbug]

Package: bugs.debian.org
Severity: wishlist
X-Debbugs-Cc: debbug.deb...@sideload.33mail.com

When composing a bug report where another package is affected by the
bug, there is no way to express that because the control command makes
bug number a required field:

  
http://5ekxbftvqg26oir5wle3p27ax3wksbxcecnm6oemju7bjra2pn26s3qd.onion/Bugs/server-control#affects

So you cannot write the header:

  control: affects $bugNumber $otherPkg

because you don’t yet have a bug# for the report you are writing. The
workaround is cumbersome: You must submit the bug report and wait for
a bug# to be generated. Then you must compose a separate control msg
that references the new bug number. It shouldn’t be that tedious
because you know at the time of composition what other pkgs are
affected.

I can see 3 possible solutions:

1) introduce a new pseudo-header “Affects”

and/or

2) make the  field optional so that it defaults to the bug number 
being processed

and/or

3) add support for a placeholder bug number like “-1” (similar to how the clone 
command works)

Bug#1018216: xwayland: Impossible to resize column widths in the LibreOffice spreadsheet (localc) by dragging a mouse

[debbug . xwayland]

Package: xwayland
Version: 2:1.20.11-1+deb11u1
Severity: normal
X-Debbugs-Cc: debbug.xwayl...@sideload.33mail.com

In the localc GUI the way to resize a column is to hover the pointer
over the divider/boundary line between two columns until “←→” appears,
click, and drag left or right.  When clicking and holding, dialog
shows the current width, but dragging is ineffective. The pointer does
not keep a grasp on the divider/boundary line.

The only resizing action that works with the mouse is to double click
on the divider line, which results in whatever width fits the
text. This is not always the ideal size.

Workaround:

There is a workaround but it’s very cumbersome. You must right click
on the column label and choose “column width…” to hand-type a size. If
you don’t like the results, you generally have to repeat that trial &
error process several times until it’s right.

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xwayland depends on:
ii  libaudit1   1:3.0-2
ii  libbsd0 0.11.3-1
ii  libc6   2.31-13+deb11u3
ii  libdrm2 2.4.104-1
ii  libepoxy0   1.5.5-1
ii  libgbm1 20.3.5-1
ii  libgcrypt20 1.8.7-6
ii  libgl1  1.3.2-1
ii  libpixman-1-0   0.40.0-1
ii  libselinux1 3.1-3
ii  libsystemd0 247.3-7
ii  libunwind8  1.3.2-2
ii  libwayland-client0  1.18.0-2~exp1.1
ii  libxau6 1:1.0.9-1
ii  libxdmcp6   1:1.1.2-3
ii  libxfont2   1:2.0.4-1
ii  libxshmfence1   1.3-1
ii  xserver-common  2:1.20.11-1+deb11u1

xwayland recommends no packages.

xwayland suggests no packages.

-- no debconf information

Bug#1018049: libreoffice-writer: PDF export fails to dump the file where instructed; and in one case writes no file at all

[debbug . lowriter]

Package: libreoffice-writer
Version: 1:7.0.4-4+deb11u1
Severity: normal
X-Debbugs-Cc: debbug.lowri...@sideload.33mail.com

When performing an “export as…”, we are given a couple choices:

1) “export as PDF”
2) “export directly as PDF”

It’s unclear what direct means, and what’s implied by the first option
(apparently indirect). So that’s consfusing; but whatever. I chose the
first option. Then I navigated by manually editing the path in the
first field (because it was not obvious how to navigate graphically).
When I saved the file, it did not appear in the specified place.
Instead it dumped the PDF in the same directory as the original
doc. This is bug 1.

Since I did not find the file initially, I tried again, this time
choosing “export directly as PDF”.  I discovered the graphical way of
navigating. It’s non-intuitive: a down arrow in the top right of he
window. I used that to navigate to the place where I wanted the file
written.  The default filename was good as-is, so I clicked “export”,
and instead of exporting the file in the directory that is showing,
the UI simply navigated one level deeper.  I could not make it dump
the file in the directory that I chose. I had to abandon the
operation. This is bug 2.

When I repeat the above procedures, sometimes an item on the screen
blinks rapidly, such as the “export” button or the field holding the
path, and the window is frozen and refuses input. I have to kill
lowriter at that point.  I’ll call this bug 3, but note that I’m using
Sway which is a tiled window manager that’s not too mature, so this
3rd bug could actually be a bug outside of lowriter.

-- Package-specific info:

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libreoffice-writer depends on:
ii  libabw-0.1-1 0.1.3-1
ii  libc62.31-13+deb11u3
ii  libe-book-0.1-1  0.1.3-2
ii  libepubgen-0.1-1 0.1.1-1
ii  libetonyek-0.1-1 0.1.9-4
ii  libgcc-s110.2.1-6
ii  libicu67 67.1-7
ii  libmwaw-0.3-30.3.17-1
ii  libodfgen-0.1-1  0.1.8-2
ii  libreoffice-base-core1:7.0.4-4+deb11u1
ii  libreoffice-common   1:7.0.4-4+deb11u1
ii  libreoffice-core 1:7.0.4-4+deb11u1
ii  librevenge-0.0-0 0.0.4-6+b1
ii  libstaroffice-0.0-0  0.0.7-1
ii  libstdc++6   10.2.1-6
ii  libuno-cppu3 1:7.0.4-4+deb11u1
ii  libuno-cppuhelpergcc3-3  1:7.0.4-4+deb11u1
ii  libuno-sal3  1:7.0.4-4+deb11u1
ii  libuno-salhelpergcc3-3   1:7.0.4-4+deb11u1
ii  libwpd-0.10-10   0.10.3-1
ii  libwpg-0.3-3 0.3.3-1
ii  libwps-0.4-4 0.4.12-1
ii  libxml2  2.9.10+dfsg-6.7+deb11u2
ii  ucf  3.0043
ii  uno-libs-private 1:7.0.4-4+deb11u1
ii  zlib1g   1:1.2.11.dfsg-2+deb11u1

Versions of packages libreoffice-writer recommends:
ii  libreoffice-math  1:7.0.4-4+deb11u1

Versions of packages libreoffice-writer suggests:
ii  default-jre [java8-runtime] 2:1.11-72
ii  fonts-crosextra-caladea 20130214-2.1
ii  fonts-crosextra-carlito 20130920-1.1
ii  libreoffice-base1:7.0.4-4+deb11u1
ii  libreoffice-java-common 1:7.0.4-4+deb11u1
ii  openjdk-11-jre [java8-runtime]  11.0.15+10-1~deb11u1

Versions of packages libreoffice-core depends on:
ii  fontconfig  2.13.1-4.2
ii  fonts-opensymbol2:102.11+LibO7.0.4-4+deb11u1
ii  libboost-locale1.74.0   1.74.0-9
ii  libc6   2.31-13+deb11u3
ii  libcairo2   1.16.0-5
ii  libclucene-contribs1v5  2.3.3.4+dfsg-1+b1
ii  libclucene-core1v5  2.3.3.4+dfsg-1+b1
ii  libcmis-0.5-5v5 0.5.2-3
ii  libcups22.3.3op2-3+deb11u2
ii  libcurl3-gnutls 7.74.0-1.3+deb11u1
ii  libdbus-1-3 1.12.20-2
ii  libdconf1   0.38.0-2
ii  libeot0 0.01-5+b1
ii  libepoxy0   1.5.5-1
ii  libexpat1   2.2.10-2+deb11u3
ii  libexttextcat-2.0-0 3.4.5-1
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.4+dfsg-1+deb11u1
ii  libgcc-s1   10.2.1-6
ii  libglib2.0-02.66.8-1
ii  libgpgmepp6 1.14.0-1+b2
ii  libgraphite2-3  1.3.14-1
ii  libgstreamer-plugins-base1.0-0  1.18.4-2
ii  libgstreamer1.0-0   1.18.4-2.1
ii  

Bug#1017086: ledger: no longer reads gnucash files (regression → undead bug #740757)

[debbug . 740757]

Package: ledger
Version: 3.2.1-7+b2
Followup-For: Bug #740757
X-Debbugs-Cc: debbug.740...@sideload.33mail.com
X-Debbugs-Cc: hel...@subdivi.de
Control: unarchive 740757
Control: reopen 740757
Control: found 740757 3.2.1-7+b2
Control: affects 740757 gnucash

For the past ~7 or so years I have been using my own manually compiled
version of ledger to escape bug# 740757:

  ===8<--
  $ /usr/local/bin/ledger -v
  Ledger 2.6.2, the command-line accounting tool

  Copyright (c) 2003-2009, John Wiegley.  All rights reserved.

  This program is made available under the terms of the BSD Public License.
  See LICENSE file included with the distribution for details and disclaimer.

  (modules: gmp, pcre, xml)
  ===8<--

This old version of ledger still works on the current stable version of gnucash 
(ver.4.4):

  ===8<--
  $ /usr/local/bin/ledger --file "$datafile" --register-format '%D!!%P!!%t\n' 
--begin 2020/12/31 --end 2022/01/01 --sort date --display 't>0' register 
exp.\*cycl
  2021/03/17!! derailleur + chain pliers!!$27.93
  2021/04/04!! trigger shifters!!$24.99
  ===8<--

But the current version of ledger (3.2.1-7+b2) does NOT operate on
gnucash data:

  ===8<--
  /usr/bin/ledger --file "$datafile" --register-format '%D!!%P!!%t\n' --begin 
2020/12/31 --end 2022/01/01 --sort date --display 't>0' register exp.\*cycl
  While parsing file "$datafile", line 2:
  Error: Directive '' requires an argument
  While parsing file "$datafile", line 66:
  Error: Directive '' requires an argument
  …
  ===8<--

I don’t know if this is a regression, or if it was never actually
fixed. But the current status is that it’s broken.

(BTS issue)

This bug is a recurrance of bug# 740757. I tried to unarchive that bug
but messages to do so were sent to cont...@bugs.debian.org and they
were ignored. It’s unclear why because control messages get no ack. So
I was forced to open this new bug report, which is the same bug.

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ledger depends on:
ii  libboost-filesystem1.74.0   1.74.0-9
ii  libboost-iostreams1.74.01.74.0-9
ii  libboost-python1.74.0 [libboost-python1.74.0-py39]  1.74.0-9
ii  libboost-regex1.74.0 [libboost-regex1.74.0-icu67]   1.74.0-9
ii  libc6   2.31-13+deb11u3
ii  libgcc-s1   10.2.1-6
ii  libgmp102:6.2.1+dfsg-1+deb11u1
ii  libicu6767.1-7
ii  libmpfr64.1.0-3
ii  libpython3.93.9.2-1
ii  libstdc++6  10.2.1-6

ledger recommends no packages.

Versions of packages ledger suggests:
pn  elpa-ledger 
pn  python3-ledger  

-- no debconf information

Bug#1017082: neomutt: (security) The sender’s timezone is exposed in the Date: header

[debbug . neomutt]

Package: neomutt
Version: 20201127+dfsg.1-1.2
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.neom...@sideload.33mail.com

The “Date:” field is added after the user instructs neomutt to send
their message, so there is no opportunity for the user to edit the
timestamp of the message. Perhaps rightly so, for RFC-compliance.  But
the timestamp that mutt generates exposes the timezone of the
author. It’s too much information.  E.g. this reveals to the recipient
and all mail servers enroute that the sender is physically in the
central Europe timezone:

  Date: Fri, 12 Aug 2022 13:21:24 +0200

This exposes the presence of senders in the eastern US timezone:

  Date: Fri, 12 Aug 2022 13:21:24 -0400

It would be surprising if Google or Microsoft did not exploit that
information in some way.  For privacy, users need control over the
format of that date. The RFC likely dictates the format, but the time
should be expressed in UTC. And UTC should in fact be the *default*
timezone as well.

If a user really wants to reveal the timezone they are in for some
reason (i.e. the status quo), perhaps there should be a new config
parameter for that case.  The parameter could be an enum that enables
you to name a timezone, or perhaps it could be a simple boolean like
“compose_timezone_local” or “compose_timezone_zulu”.

FWIW, it’s perhaps also worth mentioning that it might be useful to be
able to dynamically select the timezone of the /recipient/, as a
courtesy to them in cases where the recipient’s timezone is known by
the sender. Of course that brings in a bit of complexity.

But in any case, the current behavior is a security issue because
confidentiality is compromized.

-- Package-specific info:
NeoMutt 20201127
Copyright (C) 1996-2020 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.

System: Linux 5.10.0-16-amd64 (x86_64)
ncurses: ncurses 6.2.20201114 (compiled with 6.2.20201114)
libidn: 1.33 (compiled with 1.33)
GPGME: 1.14.0-unknown
GnuTLS: 3.7.1
libnotmuch: 5.3.0
storage: tokyocabinet

Configure options: --build=x86_64-linux-gnu --prefix=/usr 
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man} 
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
{--libdir=${prefix}/lib/x86_64-linux-gnu} 
{--libexecdir=${prefix}/lib/x86_64-linux-gnu} --disable-maintainer-mode 
--disable-dependency-tracking --mandir=/usr/share/man --libexecdir=/usr/libexec 
--with-mailpath=/var/mail --gpgme --lua --notmuch --with-ui --gnutls --gss 
--idn --mixmaster --sasl --tokyocabinet --sqlite --autocrypt

Compilation CFLAGS: -g -O2 
-ffile-prefix-map=/build/neomutt-aFsTyZ/neomutt-20201127+dfsg.1=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include 
-I/usr/include/lua5.4 -DNCURSES_WIDECHAR -isystem /usr/include/mit-krb5

Default options:
  +attach_headers_color +compose_to_sender +compress +cond_date +debug 
  +encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color 
  +initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop 
  +progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar 
  +skip_quoted +smtp +status_color +timeout +tls_sni +trash 

Compile options:
  +autocrypt +bkgdset +color +curs_set +fcntl -flock -fmemopen +futimens 
  +getaddrinfo +gnutls +gpgme +gss +hcache -homespool +idn +inotify 
  -locales_hack +lua +meta +mixmaster +nls +notmuch -openssl +pgp +regex +sasl 
  +smime +sqlite +start_color +sun_attachment +typeahead 
MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"

To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to: 

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages neomutt depends on:
ii  libc6 2.31-13+deb11u3
ii  libgnutls30   3.7.1-5+deb11u1
ii  libgpg-error0 1.38-2
ii  libgpgme111.14.0-1+b2
ii  libgssapi-krb5-2  1.18.3-6+deb11u1
ii  libidn11  1.33-3
ii  liblua5.4-0   5.4.2-2
ii  libncursesw6  6.2+20201114-2
ii  libnotmuch5   0.31.4-2
ii  libsasl2-22.1.27+dfsg-2.1+deb11u1
ii  

Bug#1017049: profanity: No acknowledgement when running “/omemo start” in a chat room; also no docs on this

[debbug . profanity]

Package: profanity
Version: 0.10.0-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.profan...@sideload.33mail.com

To send encrypted messages to a chat room, the following steps are
necessary:

  1) OMEMO must be switched on for that room (enter “/omemo start” within that 
room)
  2) the fingerprint of every person in that room must be trusted
  «OR»
  2) enable blind trust (“/help omemo trustmode” in some versions)

When step 1 is performed, there is no response from the app in that
window. There is also no response in window 1. No error message
either. So it appears to the user that their command was ignored. In
my case, the command had proper effect (so egress messages thereafter
were encrypted). But the user should be told something like:

  “OMEMO enabled for outbound messages to this channel.
   To reverse this action, run `\omemo end`”

It would perhaps also be useful when entering a chat room that has
OMEMO disabled to automatically print a banner saying:

  “Warning: messages sent to this room will be unencrypted.
   To enable e2ee run `\omemo start` in this window.”

Also, “/help omemo” does not cover this use case. The page gives the
proper BNF syntax (“/omemo start []”), but it fails to
mention that “” cannot be a /room/, and that the only way to
start a session for a room is to do “/omemo start” in that room.

So there are three bugs here:
  1) lack of command acknowledgement
  2) lack of warning banner in unencrypted rooms
  3) lack of help docs

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages profanity depends on:
ii  libc6  2.31-13+deb11u3
ii  libcurl3-gnutls7.74.0-1.3+deb11u1
ii  libgcrypt201.8.7-6
ii  libglib2.0-0   2.66.8-1
ii  libgpgme11 1.14.0-1+b2
ii  libgtk-3-0 3.24.24-4+deb11u2
ii  libncursesw6   6.2+20201114-2
ii  libnotify4 0.7.9-3
ii  libotr54.1.1-4
ii  libpython3.9   3.9.2-1
ii  libreadline8   8.1-1
ii  libsignal-protocol-c2.3.2  2.3.3-1
ii  libsqlite3-0   3.34.1-3
ii  libstrophe00.10.1-1
ii  libtinfo6  6.2+20201114-2
ii  libx11-6   2:1.7.2-1
ii  libxss11:1.2.3-1

profanity recommends no packages.

profanity suggests no packages.

-- no debconf information

Bug#947143: RFS: wordpress/5.3.2+dfsg1-0.1 [NMU] [RC] -- weblog manager

[DebBug]

Hi Markus,

Thank you for clarifying the situation.

On 2019-12-23 18:24:08, Markus Koschany wrote:

Hello Niels,

Am 23.12.19 um 15:04 schrieb DebBug:


Anyone to chime in? Craig? Markus?


There is a bit of confusion here, so I try to explain the situation and
how we should proceed. Thank you for filing bug report #947212 to track
the security issues in Wordpress. This will help to answer those
questions raised by Adam. However there was already #946905 that you
could have been used as well.

Must have missed that one.


You have only recently added me to CC, presumably because I have done

IIRC, Craig added you initially, FWIW.


some security uploads in the past for Wordpress. I don't know what you
have discussed with Craig and if he wants to review your work and
sponsor it later. Then you actually don't need to open a sponsorship
request on debian-mentors.
I yet ignore how the process continues, whether Craig will upload 
the updated package or someone else. And when.



Sponsorship requests are either of severity normal or important. Here it
would be ok to use important but the severity is merely an indicator and
it doesn't automatically guarantee that a bug is prioritized. Security
related bugs like #947212/#946905 are either of severity important or
grave.
OK. From my perspective, regarding the wordpress issue and being responsible 
for maintenance of a number of exposed instances, it is *critical* 
security releases get integrated on short terms' notice. As 
explained, system and data is at elevated risk in the particular 
case of wordpress having a considerable share of worldwide CMS 
instances. This also entails liability in case of data loss and/or 
successful exploitation of local and/or remote resources. In terms 
of legal obligation of care of user data, customer data and systems as 
well as in terms of GDPR. This direct consequence is driving a severity 
"critical". It is also the reason for my providing an updated debian 
wordpress package for NMU. I prefer debian packages over upstream 
packaging and if I'm packaging deb package updates locally I might 
as well let others profit from it.



Version 5.3.2 seems to fix a couple of security vulnerabilities. No CVE
has been assigned yet. This version should be uploaded to unstable.

My intention.


If you want to fix Wordpress in Buster and Stretch as well, then you
have to go a different route. The security team is responsible for that.
As previously discussed I recommend to base security updates on upstream
releases for specific Wordpress branches.

https://wordpress.org/download/releases/

Buster should be updated to version 5.0.8 and Stretch to 4.7.16. In both
cases you would base your work on the Wordpress packages in Buster and
Stretch. The changes to the debian files should be minimal, you would
merely rebase existing patches and repack the tarball to make it
compliant with the DFSG.
Not so much my intention. Basically, not at all, for now. I'm depending on 
the latest upstream releases so I'm sticking with unstable wordpress 
packages.



In short:

Version 5.3.2 -> unstable
Did Craig agree with the upload?
If there is simply no response because of the holiday season we could do
a NMU with a delay of 5 to 10 days. I assume you haven't made any major
changes to the package.
Well, as detailed above, those delays -- for this particular package -- 
are inacceptable, at least for me. At that, it's on top of the delay 
from the point in time upstream released to bug reported. Is there a way 
to speed up this whole process for future releases? Sure, I locally feed the 
updated packages to archive mirrors, although I'd prefer not preempting 
debian package releases.



After that:
Version 5.0.8 -> buster-security
Version 4.7.16 -> stretch-security

You can already prepare the packages, then we contact the security team
and ask for approval.

For the time being, I am time-constraint on provision for unstable.



Regards,

Markus


Thanks again for your explanation and efforts. Have a nice holiday.

Cheers

Nils


signature.asc
Description: PGP signature

Bug#947143: RFS: wordpress/5.3.2+dfsg1-0.1 [NMU] [RC] -- weblog manager

[DebBug]

Adam,

On 2019-12-21 23:32:57, Adam Borowski wrote:

Control: tags +moreinfo

On Sat, Dec 21, 2019 at 11:08:46PM +0100, deb...@think-future.com wrote:

Severity: critical


If it's indeed this serious, shouldn't this update go via security channels
first?

I guess so. Sounds reasonable. But, you tell me.


On 2019-12-21 22:29:06, DebBug wrote:
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I am looking for a sponsor for the package "wordpress"
>
> * Package name: wordpress
>  Version : 5.3.2+dfsg1-0.1



> Changes since the last upload:
>
>  * Non-maintainer upload.
>  * New upstream release


So you're trying to upload merely a new release, rather than a fix for a
security bug (which would warrant such expedience).  There might be
bugfix-only upstream releases (for good upstreams) or hopelessly-tied-with-
unrelated-features releases (for bad upstreams), but at the very least you'd
need to point to specific reasons to hurry.

First off, I sense a bit of a tone here. I'm feeling accused.
Just explain what you think and I'm fine with it.

Now, regarding the matter at hand, it occurs to me not everyone 
is familiar with wordpress: There was a new release upstream in 
november, two security updates in december but not a single deb pkg 
update.


For someone conscious about security issues, for a CMS that popular, 
more than a month down the road, even after security related releases, 
it's rather a long time without deb updates.


So, it seems this would warrant an update for a new (security) release. 
I am willing to support the packages' maintainers, to contribute for 
others to profit from it, because that's the spirit of opensource, right?

So there's the updated package, the sponsored NMU and its RFS. No
cherry-picking fixes for outdated versions' security bugs, as 
wordpress security fixes are released as is, and I cannot intend on 
starting to backport bug fixes to outdated versions.


You're asking for reasons.
The reasons are obvious. There are flaws in a piece of software, 
being actively exploited (observedly, even before any SA was out), 
the software being widely deployed putting users' systems and data at 
unnecessary and avoidable risk.


Anyone to chime in? Craig? Markus?


But here, you're apparently going with a whole new upstream branch, over the

Latest deb pkg version: 5.2.4
upstream, november 12: 5.3
latest upstream security release, december 18

That's the way the wordpress devs handle it, and the previous deb 
pkg version seems to do the same thing as this NMU.


Frankly, I don't get your point here. It seems to me like:
[X] not applicable.


head of the maintainer, who seems to be active -- and all of that without

Woah. Easy. Accusive, again.
How do you know, I am "going over the head of the maintainer"? You 
cannot. Yet, you assume so.



even trying to follow the procedure.

And again.

What procedure are _you_ referring to? I'd like to have a read on 
this. You know, let's keep this on the factual side, this way it may 
be beneficial to the Debian project. Handling motivated, interested 
people like this doesn't seem to me as beneficial to the Debian 
project as it should be. Sadly, as it is, the Debian project as 
since suffered from exactly this kind of treatment for other people.


Technical expertise and soft skills often seem not to be living 
under the same tree. We must strive for those virtues to be 
flatmates.


I am adhering to the procedure for debian package upload 
sponsorship, NMU, new members doc, new maintainers packaging doc

and probably a couple more.

Cheers

Nils



signature.asc
Description: PGP signature

Bug#947212: wordpress: 5.3.2 new upstream bug-fixing release available.

[debbug]

Package: wordpress
Version: 5.2.4
Severity: critical

Dear Maintainer,

   * What led up to the situation?
   Wordpress 5.3 was released on November 12, 2019 with the latest
   maintenance/security release on December 18, 2019. Since then the
   Debian wordpress package has not been updated from 5.2.4 leaving 
   instances at unnecessary and avoidable risk.


Please consider updating Debian wordpress packages to upstream versions.

To reduce exposure of wordpress instances deploying Debian wordpress 
packages I am offering updated and packaged versions of the 
Debian wordpress packages (tested OK) for sponsored [2] NMU [1]. I intend 
on contributing updates on a regular basis.


Severity "critical" is chosen for this issue being security-related on a large
scale putting many users' systems and data at risk.

@Craig In addition to our past PMs, I'm merely formally reporting this 
critical bug for public reference on 3rd party advise.


--
1: https://mentors.debian.net/package/wordpress
2: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D947143


signature.asc
Description: PGP signature

Bug#947143: RFS: wordpress/5.3.2+dfsg1-0.1 [NMU] [RC] -- weblog manager

[debbug]

Severity: critical

On 2019-12-21 22:29:06, DebBug wrote:

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "wordpress"

* Package name: wordpress
 Version : 5.3.2+dfsg1-0.1
 Upstream Author : Hard to find for https://wordpress.org
* URL : https://wordpress.org
* License : GPL-2+
* Vcs : https://salsa.debian.org/debian/wordpress
 Section : web

It builds those binary packages:

wordpress - weblog manager
wordpress-l10n - weblog manager - language files
wordpress-theme-twentysixteen - weblog manager - twentysixteen theme files
wordpress-theme-twentyseventeen - weblog manager - twentyseventeen theme files
wordpress-theme-twentynineteen - weblog manager - twentynineteen theme files

To access further information about this package, please visit the following 
URL:

https://mentors.debian.net/package/wordpress

Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/w/wordpress/wordpress_5.3.2+dfsg1-0.1.dsc

Changes since the last upload:

 * Non-maintainer upload.
 * New upstream release

Thank you.

Regards,

Nils



signature.asc
Description: PGP signature

Bug#947143: RFS: wordpress/5.3.2+dfsg1-0.1 [NMU] -- weblog manager

[DebBug]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "wordpress"

* Package name: wordpress
  Version : 5.3.2+dfsg1-0.1
  Upstream Author : Hard to find for https://wordpress.org
* URL : https://wordpress.org
* License : GPL-2+
* Vcs : https://salsa.debian.org/debian/wordpress
  Section : web

It builds those binary packages:

 wordpress - weblog manager
 wordpress-l10n - weblog manager - language files
 wordpress-theme-twentysixteen - weblog manager - twentysixteen theme files
 wordpress-theme-twentyseventeen - weblog manager - twentyseventeen theme files
 wordpress-theme-twentynineteen - weblog manager - twentynineteen theme files

To access further information about this package, please visit the following 
URL:

 https://mentors.debian.net/package/wordpress

Alternatively, one can download the package with dget using this command:

 dget -x 
https://mentors.debian.net/debian/pool/main/w/wordpress/wordpress_5.3.2+dfsg1-0.1.dsc

Changes since the last upload:

  * Non-maintainer upload.
  * New upstream release

Thank you.

Regards,

Nils

Bug#914370: cups-daemon: AppArmor profile allows cupsd to create setuid binaries under /etc

[debbug]

Package: cups-daemon
Version: 2.3~b5-2
Severity: normal

Dear Maintainer,

The AppArmor profile supplied with cupsd isn't much use against local
attackers, as it allows cupsd to create setuid binaries at paths it
can write to (e.g. under /etc/cups).  Since cupsd is run as root by
default, these binaries can be setuid root.

In the following example, I replace cupsd with a shell and run it as
root to test the confinement.  As you can see, AppArmor stops the
process writing to an unlisted path in /etc, but does allow it to
write and and set permissions under /etc/cups.

# mv -i /usr/sbin/cupsd /usr/sbin/cupsd.bak
# cp /bin/sh /usr/sbin/cupsd
# PS1='confined# ' /usr/sbin/cupsd
confined# cp /bin/true /etc
cp: cannot create regular file '/etc/true': Permission denied
confined# cp /bin/true /etc/cups
confined# chmod 4555 /etc/cups/true
confined# exit
# ls -l /etc/cups/true
-r-sr-xr-x 1 root root 35424 Nov 22 14:16 /etc/cups/true

(Creating a setuid binary at /etc/printcap also works, as does
removing any existing symlink there.)

In default installations /etc is not on a nosuid mount, so provided
that they have a suitable exploit, local attackers who are unconfined
but non-root can use cupsd to create a setuid binary, then run the
binary themselves to gain unconfined root privileges.


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-2-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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cups-daemon depends on:
ii  adduser   3.118
ii  bc1.07.1-2+b1
ii  libavahi-client3  0.7-4+b1
ii  libavahi-common3  0.7-4+b1
ii  libc6 2.27-8
ii  libcups2  2.3~b5-2
ii  libcupsmime1  2.3~b5-2
ii  libdbus-1-3   1.12.10-1
ii  libgssapi-krb5-2  1.16.1-1
ii  libpam0g  1.1.8-3.8
ii  libpaper1 1.1.24+nmu5
ii  libsystemd0   239-13
ii  lsb-base  9.20170808
ii  procps2:3.3.15-2
ii  ssl-cert  1.0.39

Versions of packages cups-daemon recommends:
ii  avahi-daemon  0.7-4+b1
ii  colord1.4.3-3+b1
ii  cups-browsed  1.21.3-3

Versions of packages cups-daemon suggests:
ii  cups   2.3~b5-2
ii  cups-bsd   2.3~b5-2
ii  cups-client2.3~b5-2
ii  cups-common2.3~b5-2
ii  cups-filters [foomatic-filters]1.21.3-3
pn  cups-pdf   
ii  cups-ppdc  2.2.9-2
ii  cups-server-common 2.3~b5-2
ii  foomatic-db-compressed-ppds [foomatic-db]  20180921-1
ii  ghostscript9.26~dfsg-1
pn  hplip  
ii  poppler-utils  0.69.0-2
ii  printer-driver-gutenprint  5.3.1-2
pn  printer-driver-hpcups  
pn  smbclient  
ii  udev   239-13

-- no debconf information

Bug#908553: potential solution (found by smilie)

[debbug]

Please remove --with-intl from the configure line in debian/rules.

Regards,

Igor2

Bug#887008: Problem solved

[debbug]

It appears that the problem got fixed in the next kernel version 
(4.9.0-6-amd64) so this bug can be closed.


  --jtg

Bug#879805: Bug 879805

[debbug . dovecot . imap . zlib . nospam . plz]

On Sun, Mar 04, 2018 at 23:40:32 +0200, Apollon Oikonomopoulos wrote:
> Good catch, this appears to be the following commit:
> https://github.com/dovecot/core/commit/c27f060a08d3bbf89fadd58baf61f5ba97a47e3a
> 
> > Is there a chance that the "mbox,zlib" fix from 2.2.33 could be included in 
> > a
> > later Debian 9.x point release? I'm not keen on running a backports package
> > that does not appear to get timely security updates.
> 
> Yes, I could include this in a stable update. Would you be willing to 
> test the proposed update?
> 

I can try! If an armel(!) binary .deb is available, it should be fairly easy 
to test here.

Bug#879805: Bug 879805

[debbug . dovecot . imap . zlib . nospam . plz]

I was also hit hard by this bug after a recent upgrade from debian 8.x to
debian 9.x.

Dovecot spams the following lines multiple times per second and my .gz
compressed mbox archives do not appear to work properly over imap:

Mar  3 18:37:28 hostname dovecot: imap(username): Panic: file istream-zlib.c: 
line 416 (i_stream_zlib_seek): assertion failed: (ret == -1)
Mar  3 18:37:28 hostname dovecot: imap(username): Fatal: master: service(imap): 
child 2768 killed with signal 6 (core dumps disabled)

It would appear that Dovecot 2.2.33 contains a likely fix, based on
https://www.dovecot.org/doc/NEWS 
"mbox, zlib: Fix assert-crash when accessing compressed mbox"

Stretch only contains 2.2.27, but there is a 2.2.33.2-1~bpo9+1 in
stretch-backports. It looks like the stretch-backports package was last
uploaded on 15 Nov 2017, so it probably does not contain the security fixes
included in DSA-4130-1 which was published on 02 Mar 2018.

Is there a chance that the "mbox,zlib" fix from 2.2.33 could be included in a
later Debian 9.x point release? I'm not keen on running a backports package
that does not appear to get timely security updates.

In the meantime, I have disabled the zlib plugin and decompressed all .gz
mboxes server-side.

While this bug is a little unfortunate, thanks again for all the work you 
do on this package.

Bug#883938: linux-image-3.16.0-4-amd64: Kernel panic on boot after upgrading to debian 8.10 kernel 3.16.51

[debbug]

On Sat, Dec 09, 2017 at 18:46:08 +0100, Rene Engelhard wrote:
> On Sat, Dec 09, 2017 at 06:23:04PM +0100, debbug wrote:
> > Package: src:linux
> > Version: 3.16.43-2+deb8u5
> > Severity: grave
> > Justification: renders package unusable
> > 
> > (Note: This bug affects version 3.16.51-2, not 3.16.43-2+deb8u5,
> > but that's the version that "reportbug" filled in after downgrading
> > to get this system back up running)
> 
> Then you should have edited the report accordingly...
> 

I was going to, but I wasn't sure about the proper version number or 
syntax to put in (3.16.51 or 3.16.51-2 or something else) and I didn't 
want to risk losing the bug in a void or failing to submit. 

Thanks for fixing up the version number!

Bug#883938: linux-image-3.16.0-4-amd64: Kernel panic on boot after upgrading to debian 8.10 kernel 3.16.51

[debbug]

Package: src:linux
Version: 3.16.43-2+deb8u5
Severity: grave
Justification: renders package unusable

(Note: This bug affects version 3.16.51-2, not 3.16.43-2+deb8u5,
but that's the version that "reportbug" filled in after downgrading
to get this system back up running)

After upgrading from Debian 8.9 to Debian 8.10, this Dell PowerEdge R430 server
immediately and consistently throws a kernel panic on boot. (kernel 3.16.51-2)

Booting from debian-8.9.0-amd64-netinst.iso in rescue mode let me drop into 
a shell for the target installation, where I performed something like:
  cd /var/cache/apt/archives
  dpkg -i *3.16.43*deb8u5*
  reboot
which restored the previous kernel (3.16.43-deb8u5). This kernel works fine.

I only have a terrible java KVM app available for seeing the console, and from
what I can see, it logs with timestamps [0.811] through [0.841] (typing in
from an image - excuse any typos, and leaving out long hexadecimal numbers
that might not be interesting)
  general protection fault:  [#1] SMP
  CPU: 0 PID: 1 Comm: swapper/0 Tainted: G   W  3.16.0-4-amd64 #1 Debian 
3.16.51-2
  Hardware name: Dell PowerEdge R430/03XKDV, BIOS 1.2.6 06/08/2015
  task: 88085fa532d0 ti: 88085fa58000 task.ti: 88085fa58000
  RIP: 0010:[] [<8109be3d)> 
build_sched_domains+0x72d/0cf0
  (lots of x86_64 registers)
  Call trace:
sched_init_smp+0x398/0x452
mutex_lock+0xe/0x2a
put_online_cpus+...
stop_machine+...
kernel_init_freeable+...
rest_init+...
kernel_init+...
ret_from_fork+...
rest_init+...
  Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
  ---[ end Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x000b

I also stopped by #debian on irc.debian.org and other people mentioned getting
similar (or same) panics on different types of hardware (HP ProLiant DL380 G7,
and a Supermicro server). Downgrading to 3.16.43-deb8u5 seemed to work for them
as well.

-- Package-specific info:
** Version:
Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 
4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.43-2+deb8u5 (2017-09-19)

** Command line:
BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 
root=UUID=89e3af9f-5bf1-4e93-99c0-0eca2f4fd312 ro quiet

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

** Kernel log:
[5.957932] systemd[1]: Starting udev Kernel Device Manager...
[5.961475] ipmi message handler version 39.2
[5.961963] ipmi device interface
[5.962401] Copyright (C) 2004 MontaVista Software - IPMI Powerdown via 
sys_reboot.
[5.963211] IPMI System Interface driver.
[5.963253] ipmi_si: probing via SMBIOS
[5.963255] ipmi_si: SMBIOS: io 0xca8 regsize 1 spacing 4 irq 10
[5.963256] ipmi_si: Adding SMBIOS-specified kcs state machine
[5.963259] ipmi_si: Trying SMBIOS-specified kcs state machine at i/o 
address 0xca8, slave address 0x20, irq 10
[5.978757] systemd-udevd[396]: starting version 215
[5.978816] systemd[1]: Started udev Kernel Device Manager.
[5.978877] systemd[1]: Starting Copy rules generated while the root was 
ro...
[5.979249] systemd[1]: Starting LSB: Set preliminary keymap...
[6.010575] systemd[1]: Started Copy rules generated while the root was ro.
[6.031435] systemd[1]: Mounted FUSE Control File System.
[6.055061] wmi: Mapper loaded
[6.060621] input: Power Button as 
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input3
[6.060626] ACPI: Power Button [PWRF]
[6.082592] ACPI Error: No handler for Region [SYSI] (88107ec271e8) 
[IPMI] (20140424/evregion-163)
[6.082600] ACPI Error: Region IPMI (ID=7) has no handler 
(20140424/exfldio-297)
[6.082605] ACPI Error: Method parse/execution failed [\_SB_.PMI0._GHL] 
(Node 88107ec26310), AE_NOT_EXIST (20140424/psparse-536)
[6.082617] ACPI Error: Method parse/execution failed [\_SB_.PMI0._PMC] 
(Node 88107ec262c0), AE_NOT_EXIST (20140424/psparse-536)
[6.082628] ACPI Exception: AE_NOT_EXIST, Evaluating _PMC 
(20140424/power_meter-755)
[6.120161] ipmi_si ipmi_si.0: Using irq 10
[6.123175] ipmi_si ipmi_si.0: Couldn't set irq info: cc.
[6.123177] ipmi_si ipmi_si.0: Maybe ok, but ipmi might run very slowly.
[6.142529] ipmi_si ipmi_si.0: Found new BMC (man_id: 0x0002a2, prod_id: 
0x0100, dev_id: 0x20)
[6.145569] IPMI poweroff: ATCA Detect mfg 0x2A2 prod 0x100
[6.145571] IPMI poweroff: Found a chassis style poweroff function
[6.145613] ipmi_si ipmi_si.0: IPMI kcs interface initialized
[6.189769] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[6.229237] mei_me :00:16.0: Device doesn't have valid ME Interface
[6.237853] IPMI Watchdog: driver initialized
[6.288912] systemd[1]: Mounted Debug File System.
[6.288984] systemd[1]: Mounted Huge Pages File System.
[6.289004] systemd[1]: Mounted POSIX Message Queue File System.
[6.289448] systemd[1]: Started Increase datagram queue length.
[6.289850] 

Bug#859183: (no subject)

[debbug]

Package: cgilib
Version: 0.6-1
Severity: important
Tags: patch
Content-Type: multipart/mixed; boundary="===1572526208=="
MIME-Version: 1.0
From: deb...@igor2.repo.hu
To: Debian Bug Tracking System 
X-Debug: to=sub...@bugs.debian.org from="mih...@igor2.repo.hu"
From: mih...@igor2.repo.hu
Subject: cgilib.patch: Typo in array indexing causes segfault on multi-value
 parameters
X-Debbugs-Cc: deb...@igor2.repo.hu

This is a multi-part MIME message sent by reportbug.


--===1572526208==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Package: cgilib0.6-1
Severity: important
Tags: patch

Dear Maintainer,

   * What led up to the situation?

HTTP post parameter with the same name appears multiple times crashes
the lib in cgiInit() because of a typo in the array index of a debug
message.

   * What was the outcome of this action?

Segfault.


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 4.5.1retfie (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

--===1572526208==
Content-Type: text/x-diff; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cgilib.patch"

diff -uri cgilib-0.6-orig/cgi.c cgilib-0.6/cgi.c
--- cgilib-0.6-orig/cgi.c   2017-03-31 08:49:39.0 +0200
+++ cgilib-0.6/cgi.c2017-03-31 08:54:30.990919349 +0200
@@ -637,7 +637,7 @@
free (result[k]->value);
free (value);
result[k]->value = sptr;
-   cgiDebugOutput (1, "%s: %s", result[i]->name, result[i]->value);
+   cgiDebugOutput (1, "%s: %s", result[k]->name, result[k]->value);
}
}
cp = ++ip;

--===1572526208==--

Bug#858590: Similar experience here

[debbug]

I have similar experience here: no core dumps, but after upgrading from  
2:4.2.14+dfsg-0+deb8u2 to 2:4.2.14+dfsg-0+deb8u4 I cannot access shares 
that have shadow_copy2 vfs module enabled. The rest of the shares work 
OK.  Downgrading solves the problem.


It may not be a completely isolated issue.

  --jtg

Bug#843561: certbot: Skip use perl in cron-script, just use shell

[debbug]

Second that using 

-0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && 
perl -e 'sleep int(rand(3600))' && certbot -q renew
+0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && /
bin/sh -c "/bin/sleep $((RANDOM%3600))" && certbot -q renew

Corb

Bug#843839: RFP: pcb-rnd -- modular, interactive printed circuit board designer, compatible with gEDA/PCB and kicad and various other import/export formats.

[debbug]

Package: wnpp
Severity: wishlist

* Package name: pcb-rnd
  Version : 1.1.3
  Upstream Author : Tibor Palinkas (deb...@igor2.repo.hu)
* URL : http://repo.hu/projects/pcb-rnd
* License : GPLv2+
  Programming Lang: C
  Description : modular, interactive printed circuit board designer, 
compatible with gEDA/PCB and kicad and various other import/export formats.

pcb-rnd is an interactive printed circuit board editor for the X11 window 
system. pcb-rnd includes a rats nest feature, design rule checking, and can 
provide industry standard RS-274-X (Gerber), NC drill, and centroid data 
(X-Y data) output for use in the board fabrication and assembly process.


pcb-rnd is load/save compatible with gEDA/PCB and kicad and offers various
auxiliary import/export formats.

Originally forked from gEDA/PCB.

Why is this package useful/relevant: pcb-rnd is an actively developed 
alternative
to already packaged pcb. It offers a lot more features, including compatibility
with kicad.

Is it a dependency for another package: no.

Do you use it: yes. I am also the lead developer.

If there are other packages providing similar functionality: yes; pcb and kicad

How does it compare: vs pcb: pcb-rnd is much more modular and offers
more features. An almost complete summary of the extra features can
be found at: http://repo.hu/projects/pcb-rnd/features . Kicad: pcb-rnd
is much smaller with fewer dependencies; more suitable for scripted/automated
processing.

How do you plan to maintain it: I am currently maintaining a set of
home-grown debian packages, part of the upstream repository.

Are you looking for co-maintainers/sponsor: yes.

Bug#838881: Actual python module files missing

[debbug]

Package: python-parsedatetime
Version: 2.1-1
Severity: critical

Upgrade from 1.4-1 to 2.1-1 made certbot fail. Short investigation reveals the 
package contains only files in /usr/share/doc/python-parsedatetime/* but is 
missing any file in /usr/lib/.

-- System Information:
Debian Release: stretch/sid
Architecture: i386 (i686)

Bug#795407: libmruby-dev: static library compield without -fPIC on x86_64

[debbug]

Subject: libmruby-dev: static library compield without -fPIC on x86_64
Package: libmruby-dev
Version: 1.0.0+20141015+gitb4cc962c-1
Severity: important
Tags: newcomer upstream

Dear Maintainer,

   * What led up to the situation?

I was trying to compile a dynamic library (.so) that linked against
libmruby. libmruby comes as a static library (.a). For a dynamic
lib on x86_64, the -fPIC compiler flag needs to be used on all object
files. In my case this includes the object files in libmruby.a

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

gcc -shared -o foo.so foo.o -lmruby -lm

   * What was the outcome of this action?

on x86_64 gcc error message that all objects need to be compiled
with -fPIC. On i386 it worked.

   * What outcome did you expect instead?

I'd expect all static libraries installed from -dev packages be
compiled with -fPIC on x86_64, since a random user project
may want to link them in a dynamic lib.

   * My local hack to solve the problem

apt-get source libmruby-dev

edit build_config.rb: uncomment the conf.cc do |cc| line and its
end, then add cc.flags = '-fPIC'

rebuild the package and install

Proposed solution: enable -fPIC on x86_64 only and/or also compile a
.so of the mruby lib.

   * Upstream

Downloaded the official release pack for 1.0.0 and 1.0.1, they both
compiled without -fPIC by default, so the problem is present in
the upstream.


-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

-- no debconf information


Best regards,

Tibor Palinkas

Bug#770984: apcaccess does not work on ARM

[debbug . apcupsd . arm . nospam . plz]

Control: severity -1 serious

I am also seeing this, on armel, in version 3.14.12-1.

Would it be appropriate to mark this bug severity as grave or serious?
I'm not sure if it is proper etiquette, but I might give it a shot with a
control message here (hope this works) 

It would be nice if the jessie release could avoid shipping a broken 
apcaccess binary.

Thanks.


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

Bug#781886: qcontrol failure to start on boot sometimes (jessie, systemd?)

[debbug . jessie . qcontrol . systemd . nospam . plz]

On Sat, Apr 04, 2015 at 14:43:23 +0100, Ian Campbell wrote:
 On Sat, 2015-04-04 at 14:48 +0200, reportbug wrote:
 [...]
  Apr 02 12:08:28 hostname qcontrol[617]: qcontrol 0.5.4 daemon starting.
  Apr 02 12:08:28 hostname qcontrold[480]: Starting qcontrol daemon: qcontrol.
  Apr 02 12:08:28 hostname qcontrol[617]: evdev: Error opening 
  /dev/input/by-path/platform-gpio-keys-event: No such file or directory
  Apr 02 12:08:28 hostname qcontrol[617]: register() - Error loading module
 
 I think this is probably the root cause, this path doesn't exist for
 some reason, so qcontrold doesn't start.
 
 Do you have that device path now? I suppose you must since a later
 manual start of qcontrold worked. If not then do you have anything
 similar (i.e. tr - _ perhaps)?

I do, it is a symlink to ../event0: 

0 lrwxrwxrwx 1 root root 9 2015-04-02 12:08 
/dev/input/by-path/platform-gpio-keys-event - ../event0

When I do a stat on this /dev/input/event0 file, it curiously displays 
a filestamp being one second later than the qcontrol journalctl error 
entries:

% stat /dev/input/event0
  File: '/dev/input/event0'
  Size: 0   Blocks: 0  IO Block: 4096   character
special file
Device: 5h/5d   Inode: 5272Links: 1 Device type: d,40
Access: (0660/crw-rw)  Uid: (0/root)   Gid: (  113/   input)
Access: 2015-04-02 12:08:29.72800 +0200
Modify: 2015-04-02 12:08:29.72800 +0200
Change: 2015-04-02 12:08:29.72800 +0200
 Birth: -

 


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

Bug#775575: guile-enabled gdb package

[gdb-debbug@discard.email]

X-Debbugs-CC: zu...@debian.org
 
Hector Oron zu...@debian.org wrote:
Sorry, but there are already too many GDB packages,
 
You don't need to add another package, just enable guile support in the 
existing gdb package.
People who want a gdb with minimal dependencies can install gdb-minimal

Bug#775575: guile-enabled gdb package

[gdb-debbug@discard.email]

Package: src:gdb
Version: 7.7.1+dfsg-5
Severity: wishlist
 
Since upstream version 7.8, GDB can be compiled with support for Guile as an 
extension language. It would be nice to have a guile-enabled gdb available in 
Debian.
thanks

Bug#775341: chuck: new upstream version 1.3.5.0 available

[chuck-debbug@discard.email]

Package: chuck
Version: 1.2.0.8.dfsg-1.4
 
There is a new upstream version available: 1.3.5.0
http://chuck.cs.princeton.edu/release/

Bug#750360: jessie nfsroot diskless broken? 180 second delay before root is

[debbug . jessie . nfsroot . broken . nospam]

mounted?
Reply-To: 

Hello, I recently upgraded a debian unstable system that runs diskless with
pxe netboot / nfsroot, and now every boot spends 180 seconds with repeated 
logging of mount: Device or Resource busy error messages in the initramfs
scripts before things kick off and the main boot proceeds. 

Is this the bug causing that?


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

Bug#736944: nvidia-legacy-304xx-driver: vdpau driver missing, causes floating point exception

[debbug . nvidia . legacy . nospam . plz]

By the way, I tried extracting the *vdpau* files from the nvidia .run
installer (using option -x), without any further success 
(that's why they appear in the file listings in the original report)


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

Bug#702504: python-gi: none

[debbug]

Package: python-gi
Version: 3.2.2-2
Severity: normal

Dear Maintainer,

The user_data property of the TreeIter is always set to None, when returning it 
from the do_get_iter function. Here a minimal example:

from gi.repository import Gtk, GObject 

class Model(GObject.Object, Gtk.TreeModel):
    def do_get_iter(self, path):
        it = Gtk.TreeIter()
        it.user_data = 23
        return (True, it)
    def do_get_value(self, it, column):
        return it.user_data

m = Model()
it = m.get_iter_first()
it.user_data  # returns None
m.get_value(it, 0)  # returns None

Bug seems to be known and fixed in newer versions, see also: 
http://old.nabble.com/Problem-understanding-how-to-port-GenericTreeModel-to-gi-td34846802.html


-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-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 python-gi depends on:
ii  gir1.2-glib-2.0        1.32.1-1
ii  libc6                  2.13-38
ii  libffi5                3.0.10-3
ii  libgirepository-1.0-1  1.32.1-1
ii  libglib2.0-0           2.33.12+really2.32.4-5
ii  python                 2.7.3-4

python-gi recommends no packages.

Versions of packages python-gi suggests:
ii  python-gi-cairo  3.2.2-2

-- 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

Bug#695587: apache2.2-common: apache2ctl fullstatus drops .elinks / .links2 dotfiles in current dir

[debbug . apache2ctl]

Package: apache2.2-common

Running apache2ctl fullstatus drops a directory .links2 in the 
current working directory. I assume this happens because apache2ctl 
runs /etc/apache2/envvars which unsets HOME, which then causes the 
www-browser to create preference files in the current directory. 

(On another machine, the same script appears to drop .elinks directories into 
the current directory; it has probably a different setting for the www-browser 
alternative)

-- Package-specific info:
List of /etc/apache2/mods-enabled/*.load:
  alias auth_basic authn_file authz_default authz_groupfile
  authz_host authz_user autoindex cgi deflate dir env expires mime
  negotiation php5 proxy proxy_http reqtimeout rewrite setenvif ssl
  status vhost_alias
List of enabled php5 extensions:
  curl gd gmp imagick mcrypt mysql mysqli pdo pdo_mysql pdo_sqlite
  pspell sqlite sqlite3 suhosin tidy

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

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=nb_NO.iso88591 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages apache2.2-common depends on:
ii  apache2-utils 2.2.16-6+squeeze10 utility programs for webservers
ii  apache2.2-bin 2.2.16-6+squeeze10 Apache HTTP Server common binary f
ii  libmagic1 5.04-5+squeeze2File type determination library us
ii  lsb-base  3.2-23.2squeeze1   Linux Standard Base 3.2 init scrip
ii  mime-support  3.48-1 MIME files 'mime.types'  'mailcap
ii  perl  5.10.1-17squeeze3  Larry Wall's Practical Extraction 
ii  procps1:3.2.8-9squeeze1  /proc file system utilities

Versions of packages apache2.2-common recommends:
ii  ssl-cert  1.0.28 simple debconf wrapper for OpenSSL

Versions of packages apache2.2-common suggests:
pn  apache2-doc  none  (no description available)
pn  apache2-suexec | apa none  (no description available)
ii  elinks [www-browser] 0.12~pre5-2 advanced text-mode WWW browser
ii  links [www-browser]  2.3~pre1-1+squeeze1 Web browser running in text mode
ii  w3m [www-browser]0.5.2-9 WWW browsable pager with excellent

Versions of packages apache2.2-common is related to:
pn  apache2-mpm-event none (no description available)
pn  apache2-mpm-itk   none (no description available)
ii  apache2-mpm-prefork   2.2.16-6+squeeze10 Apache HTTP Server - traditional n
pn  apache2-mpm-workernone (no description available)

-- Configuration Files:
/etc/apache2/apache2.conf changed [not included]
/etc/apache2/conf.d/security changed [not included]
/etc/apache2/ports.conf changed [not included]
/etc/apache2/sites-available/default changed [not included]
/etc/apache2/sites-available/default-ssl changed [not included]

-- 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

Bug#673971: (no subject)

[jmroth+debbug]

tags 673971 + pending
reopen 673971
thanks

oops... forget the previous comment, messed up bug id



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

Bug#673971: serendipity: unowned files after purge (policy 6.8, 10.8): /etc/apache2/conf.d/serendipity.conf

[jmroth+debbug]

tags 673971 + pending
thanks

postrm checks if the webserver it is trying to remove the config for is
used at all.
At that time in your test, apache2 has already been removed, otherwise
it would have performed the purge correctly.

I don't remember why it performs that check and I have now loosened it.




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

Bug#655509: update fails in preconfig stage: /etc/cron.d/prey failing to meet update expectation

[debbug]

Package: prey
Version: 0.5.3-6
Severity: important
Tags: patch


  Hi,

ERROR: 
  - update fails

CAUSE: 
  - I temporarily changed /etc/cron.d/prey: deactivated
regular exec. See below for the change.

PATCH: 
  - only try to update cron config if there's an active entry or skip.

--- config.orig 2012-01-11 20:34:09.022612405 +0100
+++ config  2012-01-11 20:35:03.690928954 +0100
@@ -65,7 +65,7 @@
done
 fi
 
-if [ -f /etc/cron.d/prey ]
+if [ -f /etc/cron.d/prey -a -n $(grep 'prey.sh' /etc/cron.d/prey | egrep -v 
'^#|^#$|^\s+#') ]
 then
# Frequency of reports and actions

   prey suggests no packages.

   -- Configuration Files:
   /etc/cron.d/prey changed:
   # /etc/cron.d/prey: crontab entries for the prey package

   PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
   SHELL=/bin/bash

   #*/20 * * * * root /usr/lib/prey/prey.sh /var/log/prey.log




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

Bug#644965: reportbug -Q -N bug-ID, subsequent choice o - stacktrace

[debbug]

Package: reportbug
Version: 6.2.1
Severity: serious

Description:
  - Using query mode -Q w/ -N 1234, viewing report, then selecting
o in the menu crashes reportbug.

Trace:
What do you want to do now? [N|x|o|r|b|e|q|?]? ?
N - (default) Show next message (followup).
x - Provide extra information.
o - Show other bug reports (return to bug listing).
r - Redisplay this message.
b - Launch web browser to read full log.
e - Launch e-mail client to read full log.
q - I'm bored; quit please.
? - Display this help.
What do you want to do now? [N|x|o|r|b|e|q|?]? o
Traceback (most recent call last):
  File /usr/bin/reportbug, line 2186, in module
main()
  File /usr/bin/reportbug, line 1073, in main
return iface.user_interface()
  File /usr/bin/reportbug, line 1354, in user_interface
package = exinfo.package or exinfo.source
AttributeError: 'NoneType' object has no attribute 'package'


-- Package-specific info:
** Environment settings:
EDITOR=/usr/bin/vi
INTERFACE=text

** /home/user/.reportbugrc:
reportbug_version 3.31
mode expert
ui text
realname debbug
email l...@think-future.com
paranoid

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.39.3 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages reportbug depends on:
ii  apt   0.8.15.8
ii  python2.7.2-8
ii  python-reportbug  6.2.1

reportbug recommends no packages.

Versions of packages reportbug suggests:
ii  debconf-utils1.5.40
ii  debsums  2.0.49
ii  dlocate  none
ii  emacs22-bin-common | emacs23-bin-common  none
ii  file 5.08-1
ii  gnupg1.4.11-3
ii  pgpgpg [pgp] 0.13-9
ii  postfix [mail-transport-agent]   2.8.3-1
ii  python-gtk2  2.24.0-2
ii  python-gtkspell  none
ii  python-urwid 0.9.9.2-1
ii  python-vte   1:0.28.1-2
ii  xdg-utils1.1.0~rc1-2

-- 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

Bug#644930: bad LANG env crashes gnucash on File-New account

[debbug]

Package: gnucash
Version: 1:2.4.7-3+b1
Severity: serious
Tags: l10n

Problem description:
  Using export LANG=de_DE; gnucash to start gnucash. gnucash crashes upon
  Selecting File - New account.
  Same valid for de_DE@UTF-8 maybe others as well.
  export LANG=de_DE.UTF-8; gnucash however works as intended.

Further problem properties: 
  - exists iirc since 2008 or earlier
  - gnucash devs at #gnucash hint this might be related to libc or gtk.

Stack trace:
  - gnucash-lang-segfault: http://pastebin.com/4h2Cv0La

#0  __strncmp_ssse3 () at ../sysdeps/i386/i686/multiarch/strcmp-ssse3.S:2064
#1  0xb6c7813e in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#2  0xb6de0fc7 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#3  0xb6de5677 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#4  0xb6de59f6 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#5  0xb6ddf4e0 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#6  0xb6de079b in gtk_tree_model_foreach () from /usr/lib/libgtk-x11-2.0.so.0
#7  0xb6de4f8c in gtk_tree_model_filter_refilter () from 
/usr/lib/libgtk-x11-2.0.so.0
#8  0xb6c79566 in gtk_entry_completion_complete () from 
/usr/lib/libgtk-x11-2.0.so.0
#9  0xb6c65d9c in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#10 0xb678af1c in ?? () from /usr/lib/libgobject-2.0.so.0
#11 0xb676d9f2 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#12 0xb678afb7 in ?? () from /usr/lib/libgobject-2.0.so.0
#13 0xb66b2a41 in ?? () from /lib/libglib-2.0.so.0
#14 0xb66b7252 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#15 0xb66b7a30 in ?? () from /lib/libglib-2.0.so.0
#16 0xb66b80f3 in g_main_loop_run () from /lib/libglib-2.0.so.0
#17 0xb6ceabd9 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#18 0xb7695974 in gnc_ui_start_event_loop () at gnc-gnome-utils.c:668
#19 0x0804d4d4 in inner_main (closure=0x0, argc=1, argv=0xbfa77ae4) at 
gnucash-bin.c:735
#20 0xb73a4416 in ?? () from /usr/lib/libguile.so.17
#21 0xb7376022 in ?? () from /usr/lib/libguile.so.17
#22 0xb73eb518 in scm_c_catch () from /usr/lib/libguile.so.17
#23 0xb7376657 in scm_i_with_continuation_barrier () from 
/usr/lib/libguile.so.17
#24 0xb7376733 in scm_c_with_continuation_barrier () from 
/usr/lib/libguile.so.17
#25 0xb73e9d99 in scm_i_with_guile_and_parent () from /usr/lib/libguile.so.17
#26 0xb73e9dee in scm_with_guile () from /usr/lib/libguile.so.17
#27 0xb73a44ff in scm_boot_guile () from /usr/lib/libguile.so.17
#28 0x0804d8b1 in main (argc=1, argv=0xbfa77ae4) at gnucash-bin.c:879

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.39.3 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gnucash depends on:
ii  gnucash-common 1:2.4.7-3
ii  guile-1.8  1.8.8+1-6
ii  guile-1.8-libs 1.8.8+1-6
ii  libaqbanking33 5.0.16-1
ii  libart-2.0-2   2.3.21-1
ii  libatk1.0-02.2.0-1
ii  libbonobo2-0   2.24.3-1
ii  libbonoboui2-0 2.24.3-1
ii  libc6  2.13-21
ii  libcairo2  1.10.2-6.1
ii  libcrypt-ssleay-perl   0.57-2+b2
ii  libdate-manip-perl 6.25-1
ii  libdbi10.8.4-5.1
ii  libfinance-quote-perl  1.17+git20110918-1
ii  libfontconfig1 2.8.0-3
ii  libfreetype6   2.4.6-2
ii  libgconf2-42.32.4-1
ii  libgdk-pixbuf2.0-0 2.24.0-1
ii  libglade2-01:2.6.4-1
ii  libglib2.0-0   2.28.6-1
ii  libgmp10   2:5.0.2+dfsg-1
ii  libgnome-keyring0  3.2.0-2
ii  libgnome2-02.32.1-1
ii  libgnomecanvas2-0  2.30.3-1
ii  libgnomeui-0   2.24.5-2
ii  libgnomevfs2-0 1:2.24.4-1
ii  libgoffice-0.8-8   0.8.17-1
ii  libgtk2.0-02.24.4-3
ii  libgwengui-gtk2-0  4.3.0-1
ii  libgwenhywfar604.3.0-1
ii  libhtml-tableextract-perl  2.11-1
ii  libhtml-tree-perl  4.2-1
ii  libice62:1.0.7-2
ii  libktoblzcheck1c2a 1.35-1
ii  libltdl7   2.4-4
ii  libofx41:0.9.4-2
ii  liborbit2  1:2.14.18-0.2
ii  libpango1.0-0  1.28.4-3
ii  libpopt0   1.16-1
ii  libsm6 2:1.2.0-2
ii  libsoup2.4-1   2.34.3-1
ii  libwebkitgtk-1.0-0 1.4.2-2
ii  libwww-perl6.02-1
ii  libx11-6   2:1.4.4-2
ii  libxml22.7.8.dfsg-4
ii  perl   5.12.4-4
ii  slib   3b1-3.1
ii  zlib1g 1:1.2.3.4.dfsg-3

Versions of packages gnucash recommends:
ii  gnucash-docs  2.2.0-3

Versions of packages gnucash suggests:
pn  libdbd-mysqlnone
pn  libdbd-pgsqlnone
pn  libdbd-sqlite3  none

-- no debconf information




-- 
To UNSUBSCRIBE, email 

Bug#608232: flpsed does not save text on certain input documents

[debbug-flpsed . 5 . iridos]

Package: flpsed
Version: 0.5.2-1
Severity: grave
Tags: lenny, squeeze

flpsed does not save text on postscript produced by xsane in squeeze.
The saved document only has

/PSEditWidgetPageCount 1 def % PSEditWidget

added in line 12 compared to the original. Re-opening the saved
document in flpsed another time,
adding text and saving again as postscript yields a document with no
changes. PDF export has the
same result (i.e. the added text is not saved).

Running ps2ps or eps2eps on the postscript document yields a several
times bigger postscript
document that is handled correctly by flpsed.

I stripped the image out of a small sample postscript file generated
by xsane and attached the
result below and as an attachment.

Cheers,
Karsten


=== sample postscript  ===
%!PS-Adobe-3.0
%%Creator: XSane version 0.997 (sane 1.0) - by Oliver Rauch
%%DocumentData: Clean7Bit
%%LanguageLevel: 3
%%BoundingBox: 0 0 69 23
%%Pages: 1
%%EndComments
%%BeginDocument: xsane.ps

20 dict begin

%%Page: 1 1
%%PageBoundingBox: 0 0 70 24
/DeviceGray setcolorspace
0 rotate
0 0 translate
69.120003 23.76 scale

 /ImageType 1
 /Width 96
 /Height 33
 /BitsPerComponent 8
 /Decode [0 1]
 /ImageMatrix [96 0 0 -33 0 33]
 /DataSource currentfile /ASCII85Decode filter /FlateDecode filter


showpage
%%PageTrailer
end
%%EOF
%%EndDocument

=== sample postscript


-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686-bigmem (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages flpsed depends on:
ii  ghostscript-x   8.71~dfsg2-6 The GPL Ghostscript PostScript/PDF
ii  libc6   2.11.2-7 Embedded GNU C Library: Shared lib
ii  libfltk1.1  1.1.10-2+b1  Fast Light Toolkit - shared librar
ii  libgcc1 1:4.4.5-8GCC support library
ii  libstdc++6  4.4.5-8  The GNU Standard C++ Library v3
ii  libx11-62:1.3.3-4X11 client-side library

Versions of packages flpsed recommends:
ii  poppler-utils [xpdf-utils]0.12.4-1.2 PDF utilitites (based on libpopple

flpsed suggests no packages.

-- no debconf information


example.ps
Description: PostScript document

Bug#604028: signing-party: Missing dependency ) for siggraph

[debbug-signing-party . 6 . iridos]

Package: signing-party
Version: 1.1.3-1
Severity: normal

Can't locate GD.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 
/usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 
/usr/share/perl/5.10 /usr/local/lib/site_perl .) at /usr/bin/springgraph line 
187.

GD.pm is in 
libgd-gd2-noxpm-perl: /usr/lib/perl5/GD.pm

libgd-gd2-perl: /usr/lib/perl5/GD.pm
... it is also found in a couple of other packages, which I think are 
all unrelated here:

libgd-securityimage-perl: /usr/share/perl5/GD/SecurityImage/GD.pm
libpdf-api2-perl: /usr/share/perl5/PDF/API2/Resource/XObject/Image/GD.pm
libtemplate-plugin-gd-perl: /usr/share/perl5/Template/Plugin/GD.pm
pdl: /usr/lib/perl5/PDL/IO/GD.pm
wml: /usr/lib/wml/perl/lib/i486-linux-gnu-thread-multi/WML/GD.pm


As a sidenote (I can fill a separate wishlist bug on this if you like) - I 
think it would be better to have springgraph in a separate springgraph 
package, on which signing-party depends.


The man-page of apt-rdepends explicitely mentions springgraph:
   -d, --dotty
   dotty takes a list of packages on the command line and gener-
   ates output suitable for use by springgraph.
...and there is no reason why one would want to install signing-party for 
apt-rdepends.

Cheers,
Karsten

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686-bigmem (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages signing-party depends on:
ii  gnupg   1.4.10-4 GNU privacy guard - a free PGP rep
ii  libc6   2.11.2-7 Embedded GNU C Library: Shared lib
ii  libclass-methodmaker-perl   2.15-2   Perl module for creating generic m
ii  libgnupg-interface-perl 0.42-3   Perl interface to GnuPG
ii  libmailtools-perl   2.06-1   Manipulate email in perl programs
ii  libmime-tools-perl  5.428-1  Perl5 modules for MIME-compliant m
ii  libterm-readkey-perl2.30-4   A perl module for simple terminal 
ii  libtext-template-perl   1.45-1   Text::Template perl module
ii  perl5.10.1-16Larry Wall's Practical Extraction 
ii  qprint  1.0.dfsg.2-2 encoder and decoder for quoted-pri


Versions of packages signing-party recommends:
pn  exim4 | mail-transport-agent  none (no description available)
pn  libgd-gd2-noxpm-perl | libgd- none (no description available)
pn  libpaper-utilsnone (no description available)
ii  libtext-iconv-perl1.7-2  converts between character sets in
ii  whiptail  0.52.11-1  Displays user-friendly dialog boxe

Versions of packages signing-party suggests:
ii  imagemagick8:6.6.0.4-2.2 image manipulation programs
pn  mutt   none(no description available)
pn  texlive-latex-recommended  none(no description available)
pn  wipe   none(no description available)

-- 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

Bug#564926:

[jmroth+debbug]

[ Please address all mail to 564...@bugs.debian.org too. ]

An update from phpbb2 is not supported anyhow, as the documentation
clearly says.

Greetings,
JM


On 6/2/2010 9:44 PM, Nigel Horne wrote:
 Would that lose my phpbb2 database?
 
 -Nigel
 




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

Bug#564926: (no subject)

[jmroth+debbug]

Since the original install already seems to have been faulty I would
recommend purging the package completely and installing from scratch.

Greetings
JM



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

Bug#573524: (no subject)

[jmroth+debbug]

Wouldn't this rather be a bug in dbconfig-common?

Maybe also the priority of debconf messages to be shown is set too
high on your system?



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

Bug#574976: (no subject)

[jmroth+debbug]

tags 574976 wontfix
thanks

AFAIK:
- upstream is AWOL
- this package would contain ONE actual file
- it is not used anywhere else in Debian that we could find out

Therefore we have agreed to just keep this one file in the serendipity
package directly.

JM



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

Bug#579144: (no subject)

[jmroth+debbug]

forwarded 579144 
http://sourceforge.net/tracker/?func=detailaid=2992079group_id=75065atid=542822
thanks

FWIW, I have made a few recommendations on how to make our lifes easier in the 
upstream issue tracker.



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

Bug#547456: (no subject)

[jmroth+debbug]

If this is really the case, wouldn't it rather be a bug in aptitude or
dpkg or such?



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

Bug#565738: (no subject)

[jmroth+debbug]

Yeah, probably debconf should be used to ask which webservers should
be configured (or not).
However, this doesn't strike me as being that important since Drupal
has a quite good multisite behavior, i.e. it won't show anything under
a domain for which it hasn't been configured.



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

Bug#499765: (no subject)

[jmroth+debbug]

tags 499765 +moreinfo
owner 499765 !
thanks

I believe your first problem might be a duplicate of #519713.

As far as your second problem is concerned, what action did you
exactly carry out to trigger it?



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

Bug#519713: (no subject)

[jmroth+debbug]

tags 519713 +pending
thanks

Actually, it does not only happen for the users, but also for groups
etc. ;-)
This is due to the corresponding postgres sequences/serial datatypes
not being updated after prepopulating the DB.
The next version will have the fix.

Why this doesn't trigger any key violations in the DB at runtime, I do
not know. I guess it actually does but there must be something inside
serendipity that handles this exception silently.



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