Bug#1041447: comitup: fails to install, remove, distupgrade, and install again

[Dave Steele]

On Tue, Jul 18, 2023 at 10:39 PM Andreas Beckmann  wrote:
>
> Package: comitup
> Version: 1.38-1.1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package failed to install
> (in 'bullseye'), remove (but not purge), distupgrade to 'bookworm',
> and install again.
> Before the second installation the package is in config-files-remaining
> state. The configuration is remaining from the last version that was
> successfully configured - which is from the previous release.
>

What piuparts section is this?

Bug#1037612: control

[Dave Steele]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/cryfs/cryfs/issues/458

Bug#1019208: Fwd: ITP: viagee -- support for Gmail as the preferred email application in GNOME

[Dave Steele]

Package: wnpp
Severity: wishlist
Owner: David Steele 

* Package name: viagee
  Version : 3.0-1
  Upstream Author : David Steele 
* URL : https://github.com/davesteele/viagee/tree/debian
* License : GPL
  Programming Lang: Python
  Description : support for Gmail as the preferred email
application in GNOME

This is a rename of the existing package "gnome-gmail". The name had
to be changed due to branding contention.

A transitional gnome-gmail package is included in the repository [1].

[1]: https://github.com/davesteele/viagee/tree/debian

Bug#1014684: FTBFS with fmtlib 9.0.0

[Dave Steele]

Control: forwarded -1 https://github.com/cryfs/cryfs/issues/432

Bug#1014684: FTBFS with fmtlib 9.0.0

[Dave Steele]

Control: -1 forwarded https://github.com/cryfs/cryfs/issues/432
Thanks

On Sun, Jul 10, 2022 at 5:33 AM Shengjing Zhu  wrote:
> I have uploaded fmtlib 9.0.0 to experimental. During rebuild the reverse
> dependencies, your package FTBFS.
>

Bug#1003496: Relinquish

[Dave Steele]

Control: noowner -1

I no longer intend to package this software.

Bug#802260: gnome-gmail: Installation experience on KDE

[Dave Steele]

Control: severity -1 wishlist
thanks

Bug#976402: Proposed official virtual packages - todo and todo.txt

[Dave Steele]

Update. No todo, and suggest the following for todo.txt text:

command-line task management utility compatible with todo.txt CLI (
http://todotxt.org)

On Tue, Dec 8, 2020 at 2:57 PM Dave Steele  wrote:

> Please update the Authoritative List of Virtual Package Names to
> include "todo" and "todo.txt".
>
> Discussion of the change is documented in [#976402].
>
> [#976402]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976402
>
>
> Suggested content:
>
> # Miscellaneous
>
> virtualPackages:
>   - name: todo
> description: a command-line task management utility
>   - name: todo.txt
> description: task management based on a standard free-form text format
>

Bug#976402: Bug#976902: topydo: provides /usr/bin/todo with incompatible interface compared to devtodo

[Dave Steele]

I see two complaints about the "todo" virtual package:
  1) it encompasses applications that may not have sufficiently identical
interfaces, and/or
  2) it uses Conflicts as a transition mechanism.

Resolving (2) exceeds my threshold. I'll drop the todo package.

That leaves todo.txt, implemented by topydo and (hopefully, soon)
todotxt-cli. Unfortunately, (1) has been invoked here as well - the command
sets of the two packages are close, but not identical. Also, I'm on record
saying an emacs script could comply if:
  - it properly supports the "--info" argument
  - it supports calling the hooks in the optional todo.txt-base package
  - it provides a means to add/modify/delete/show tasks housed in a
todo.txt-format file, noting that the format does not have to be strictly
enforced by the package.

My latest stake in the ground - I claim that the functionality of the
todo.txt virtual package, from a Policy perspective, is defined, here, and
that the candidates are compliant.

I'm trying to do this in good faith.

Any objections? Actions? Suggestion for the description?

>

Bug#976402: Bug#976902: topydo: provides /usr/bin/todo with incompatible interface compared to devtodo

[Dave Steele]

On Wed, Dec 9, 2020 at 12:40 PM Bill Allombert  wrote:

> On Wed, Dec 09, 2020 at 12:00:23PM -0500, Dave Steele wrote:
>
> /usr/bin/todo is not registered as an alternative by devtodo,
> so you cannot register it as an alternative in another package.
> The conflict between devtodo and topydo is not justified.
>

Well, OK, but that's not the issue this bug introduced.

> I would have preferred a discussion on #976402 in advance of an RC bug
> > report.
>
> Sorry, policy does not work that way. A policy proposal never delays a RC
> bug.
>

I thought we were having an active discussion on the validity of the policy
claim.
That discussion is moot?

Bug#976402: Bug#976902: topydo: provides /usr/bin/todo with incompatible interface compared to devtodo

[Dave Steele]

On Wed, Dec 9, 2020 at 3:54 AM Ansgar  wrote:

> Package: topydo
> Version: 0.13-5
> Severity: serious
>
> Example use of `todo` from devtodo:
>
> +---
> | Add a task, like so:
> |
> | $ todo -a I should really update my homepage
> |
> | List all open tasks:
> |
> | $ todo
> |
> | Mark a task as complete:
> |
> | $ todo -d 1.2
> +---[ https://swapoff.org/devtodo1.html ]
>
> Example use of `topydo`:
>
> +---
> | topydo add "Water the flowers @Home rec:1w"
> | topydo ls
> | topydo do 2
> +---[ https://github.com/topydo/topydo ]
>
> But postinst registers topydo as an alternative for /usr/bin/todo.
>
> Debian Policy[1] requires binaries with the same name to provide the
> same functionality; given the command-line interfaces are
> incompatible, this doesn't seem to be the case here.
>
> I've reported this bug against topydo as it seems to just have taken
> over the name, but already has topydo and wouldn't need to take over
> the todo binary.
>
> Ansgar
>
>   [1]: https://www.debian.org/doc/debian-policy/ch-files.html#binaries



I disagree. The two packages provide the same functionality - the ability
to add, remove, modify and display todo lists. Alternatives routinely offer
different option sets and commands.

I would have preferred a discussion on #976402 in advance of an RC bug
report.

Bug#976402: Proposed official virtual packages - todo and todo.txt

[Dave Steele]

Please update the Authoritative List of Virtual Package Names to
include "todo" and "todo.txt".

Discussion of the change is documented in [#976402].

[#976402]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976402


Suggested content:

# Miscellaneous

virtualPackages:
  - name: todo
description: a command-line task management utility
  - name: todo.txt
description: task management based on a standard free-form text format

Bug#976111: topydo 0.13-3 upload seems to hang ci.debian.net workers while testing todo.txt-base

[Dave Steele]

On Mon, Nov 30, 2020 at 2:51 PM Paul Gevers  wrote:

>
> Happens. Glad you're able to point us at the problem so quickly. I have
> blocklisted todo.txt-base already yesterday, so the infrastructure is
> somewhat protected now. I'll lift the block once you close this bug.
>
>
Could you lift the block now? There is a version submitted that passes all
autopkgtests.

Note that the block did not stop the tests from running (which passed).

Bug#976072: Upcoming fix

[Dave Steele]

Preparing to unpack topydo_0.13-5_all.deb ...
Unpacking topydo (0.13-5) over (0.13-2) ...
Setting up topydo (0.13-5) ...
update-alternatives: using /usr/bin/topydo to provide /usr/bin/todo.txt
(todo.txt) in auto mode
update-alternatives: using /usr/bin/topydo to provide /usr/bin/todo (todo)
in auto mode
Processing triggers for man-db (2.9.3-2) ...

Bug#532150: Bug#865792: reportbug: Allow an arbitrary MUA to be configured (patch)

[Dave Steele]

On Mon, Jun 22, 2020 at 9:27 AM Paul Wise  wrote:
>
> On Mon, 2020-06-22 at 12:31 +0200, Nis Martensen wrote:
>
> > The current MUA support in reportbug has two main limitations:
>
> Just importing the MUA handling from reportbug-ng would solve most of
> these, including the gmail case. Preferably the MUA handling
> from reportbug-ng and reportbug should be factored out into a Python
> MUA module that reportbug would then switch to.

Unfortunately, the patch under discussion is three years old. I made it
after
determining that reportbug-ng wouldn't do it for me, but I don't remember
what the problem was, and don't know what might have happened since to
resolve my issue. Not much help there.

> > We could provide an example wrapper script in
> > /usr/share/doc/reportbug/examples/custom-mua that turns this into a
> > mailto URL and calls xdg-open with that. Users could copy that
> > somewhere and make it executable. It would be great if this scheme
> > would even allow using webmail services as mailto handlers. Hello,
> > gnome-gmail.
>
> A script for opening a mail in the email composer of the user's
> preferred MUA already exists and is called xdg-email.

xdg-open and xdg-email are pretty much equivalent as far as this
discussion goes.

Again - three years. I don't remember if it was lack of foresight that led
me to not incorporate xdg-* up front, or if there was a real problem. I
seem to remember an issue with body formatting. That may have been
gnome-gmail specific.

On Mon, Jun 22, 2020 at 6:37 AM Nis Martensen  wrote:
>
> ...Here my thoughts so far. I'm hoping to find time to get a solution
into reportbug soon.
>
> The current MUA support in reportbug has two main limitations:
> 1. It only allows a small fixed set of MUAs.
> 2. It does not support passing attachments to the MUA.
>
...
> Comments, suggestions?

If I can interpret, it sounds like there are two options on the table -
something looking like
https://salsa.debian.org/reportbug-team/reportbug/-/merge_requests/24,
or a reportbug-ng port. The MR needs, at a minimum, elimination
of the version option, and clarity in the documentation re supported
and unsupported MUAs. More complete attachment support would be gravy.

Eliminating the concept of the MUA from reportbug would be attractive.
Require xdg support?

My needs follow the patch path. If consensus favors that, I can work it.

Bug#954169: sirikali: Encrypted containers can not be opened

[Dave Steele]

severity 954169 normal
tags 954169 = moreinfo unreproducible
thanks

I cannot reproduce this either. I usually do not use gocryptfs, but
installed it to test.

I also do not use dash, but that is not likely to be the source of the problem.

Bug#954171: sirikali: Containers can not be created

[Dave Steele]

severity 954171 normal
tags 954171 = moreinfo unreproducible
thanks

I am unable to reproduce the described behavior.

Bug#935154: goopg depends on cruft package

[Dave Steele]

You may want to file this upstream.

https://github.com/LeoIannacone/goopg/issues

On Tue, Aug 20, 2019 at 5:39 AM peter green  wrote:
>
> Package: goopg
> Version: 0.3.1-9
> Severity: serious
>
> goopg depends on the python-oauth2client binary package which is no longer 
> built by the python-oauth2client source package.
>
> If you want your package to be in bullseye you need to migrate to python 3 
> (and fix the other rc bug)

Bug#865792:

[Dave Steele]

> I like your patch, but it doesn't apply anymore (apologies it took so
> long to review) - would you please re-base it against the current
> master? thanks!

My apologies as well. I missed this message. I've rebased the
patch. I haven't looked closely at the code recently, but the merge
was clean enough, it runs cleanly with my mua (gnome-gmail)
and does not introduce new test failures.
From 6066867522181da0efdc0968e35af4a7df856dca Mon Sep 17 00:00:00 2001
From: David Steele 
Date: Sat, 6 Jul 2019 15:45:21 -0400
Subject: [PATCH] Add support for a custom mua command

The "mua" option allowed a custom mua command to be defined, but it
was only permitted for the list of 5 supported muas. This patch allows
an arbitrary mua command string to be defined.

The defined mua is set to default, and is added to the list of available
MUAs.

This also adds a 'mua-version' option, which specifies the mua
command-line argument for 'no action', which is used in utils.mua_exists(),
as an 'are you there?" check. This only applies to custom muas. The option
defaults to "--version".

As a side effect, the overloaded definition of 'mua' in utils, where
it could either be a string or a Mua object, depending on user options,
is eliminated.
---
 bin/reportbug|  14 +++---
 conf/reportbug.conf  |   9 +++-
 man/reportbug.1  |   9 +++-
 man/reportbug.conf.5 |  12 -
 reportbug/utils.py   | 111 ++-
 test/test_utils.py   |  29 ++-
 6 files changed, 96 insertions(+), 88 deletions(-)

diff --git a/bin/reportbug b/bin/reportbug
index 2baca08..766b590 100755
--- a/bin/reportbug
+++ b/bin/reportbug
@@ -800,7 +800,8 @@ def main():
 editor='', offline=False, verify=True, check_uid=True,
 testmode=False, attachments=[], keyid='', body=None,
 bodyfile=None, smtptls=False, smtpuser='', smtppasswd='',
-paranoid=False, mbox_reader_cmd=None)
+paranoid=False, mbox_reader_cmd=None,
+mua_version="--version")
 
 # Convention: consider `option.foo' names read-only; they always contain
 # the original value as determined by the cascade of command-line options
@@ -868,6 +869,8 @@ def main():
   dest='bugnumber', help='specify a bug number to look for')
 parser.add_option('--mua', dest='mua',
   help='send the report using the specified mail user agent')
+parser.add_option('--mua-version', dest='mua_version',
+  help='an mua option that results in no action (to verify mua is available)')
 parser.add_option('--mta', dest='mta', help='send the report using the '
 'specified mail transport agent')
 parser.add_option('--list-cc', action='append', dest='listcc',
@@ -1062,17 +1065,14 @@ def main():
 ewrite("The directory %s does not exist; exiting.\n" % options.draftpath)
 sys.exit(1)
 
-if options.mua and not options.template:
-if not utils.mua_is_supported(options.mua):
-ewrite("Specified mail user agent is not supported; exiting.\n")
-sys.exit(1)
+if isinstance(options.mua, str):
+options.mua = utils.mua_create(options.mua, options.mua_version)
 
+if options.mua and not options.template:
 if not utils.mua_exists(options.mua):
 ewrite("Selected mail user agent cannot be found; exiting.\n")
 sys.exit(1)
 
-options.mua = utils.mua_name(options.mua)
-
 # try to import the specified UI, but only if template
 # is not set (it's useful only in 'text' UI).
 if options.interface and not options.template:
diff --git a/conf/reportbug.conf b/conf/reportbug.conf
index f4f67b2..c69e89e 100644
--- a/conf/reportbug.conf
+++ b/conf/reportbug.conf
@@ -19,9 +19,16 @@ submit
 # mh
 # nmh
 
-# You can also use 'mua'; it takes an argument like that to --mua
+# You can also use 'mua'; it takes an argument like that to --mua.
+# '%s' is replaced with the path to the message file. It is appended if
+# not present.
 # mua 'mutt'
 
+# If you use the 'mua' option, you can also specify an mua option that
+# causes the mua to exit without action. This is used to verify that the
+# mua is present and available. It defaults to "--version".
+# mua_version '--version'
+
 # Additional headers to add:
 # header "X-Debbugs-CC: debian...@lists.debian.org"
 # header "X-Silly-Header: I haven't edited my /etc/reportbug.conf"
diff --git a/man/reportbug.1 b/man/reportbug.1
index 6bf2d2d..da0b656 100644
--- a/man/reportbug.1
+++ b/man/reportbug.1
@@ -294,7 +294,14 @@ Specify an alternate \fIMTA\fP, instead of \fB/usr/sbin/sendmail\fP
 .B \-\-mua=MUA
 Instead of spawning an editor to revise the bug report, use the
 specified \fIMUA\fP (mail user agent) to edit and send
-it. \fB--mutt\fP and \fB--nmh\fP options are processed.
+it. The string \fI%s\fP is replaced with 

Bug#929075: golang-github-jacobsa-crypto: Salsa CI failure

[Dave Steele]

Package: golang-github-jacobsa-crypto
Severity: minor
thanks

The golang-github-jacobsa-crypto package is currently failing the Salsa CI
test [1]. This happens
because uscan on Salsa is returning a different derived latest (git)
version tag than the one on my
build system [2]. This appears to be due to #910762 [3].

Issue logged with the go-team [4].


[1] -
https://salsa.debian.org/go-team/packages/golang-github-jacobsa-crypto/pipelines
[2] -
https://salsa.debian.org/go-team/packages/golang-github-jacobsa-crypto/-/jobs/173319
[3] - https://bugs.debian.org/910762
[4] - https://salsa.debian.org/go-team/ci/issues/2

Bug#927985: gnome-gmail sometimes deletes message body

[Dave Steele]

Package: gnome-gmail
Severity: normal
thanks

There is a bug in gnome-gmail that causes message bodies to be absent when
the capitalized "BODY" tag is used in the mailto query string. This has
caused "Send Link" messages from browsers to have no links in the resulting
messages.

Bug#916702: Merge request

[Dave Steele]

Upstream upgrade available as a merge request.

https://salsa.debian.org/debian/python-freezegun/merge_requests

Bug#918144: Goopg API Error

[Dave Steele]

Package: goopg
Severity: serious
thanks

Goopg Gmail API calls are failing, returning a 400 code. e.g,

2019-01-03 14:43:12,509:INFO:Gmail:getting message
#msg-a:r-505788724173301
2019-01-03 14:43:12,587:ERROR:CommandHandler:https://www.googleapis.com/gmail/v1/users/me/messages/%23msg-a%3Ar-505788724173301?alt=json=raw
returned "Invalid id value">
Traceback (most recent call last):
  File "/usr/share/goopg/commandhandler.py", line 87, in sign
draft = self.gmail.get(id)
  File "/usr/share/goopg/gmail/__init__.py", line 132, in get
message = self.messages.get(userId='me', id=id, format='raw').execute()
  File "/usr/lib/python2.7/dist-packages/oauth2client/_helpers.py", line
133, in positional_wrapper
return wrapped(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/googleapiclient/http.py", line
838, in execute
raise HttpError(resp, content, uri=self.uri)
HttpError: https://www.googleapis.com/gmail/v1/users/me/messages/%23msg-a%3Ar-505788724173301?alt=json=raw
returned "Invalid id value">


Filed upstream as https://github.com/LeoIannacone/goopg/issues/34.

Severity set to 'serious' since this makes the package unusable, and to
keep this problem from being added to Stretch Stable.

Bug#862876: Obsolete watch file for libcrypto++

[Dave Steele]

On Tue, Jun 27, 2017 at 4:43 PM, László Böszörményi (GCS)
 wrote:
> Hi David,
>
> On Thu, May 18, 2017 at 3:34 AM, David Steele  wrote:

>> This is a problem for me, because the cryfs package has less functionality 
>> when
>> compiled against 5.6.4, relative to 5.6.3 or 5.6.5.
>  Can you give me some details what do you mean under this functionality?


https://github.com/cryfs/cryfs/blob/develop/src/cpp-utils/crypto/symmetric/ciphers.cpp#L30



-- 
Amateurs and zealots both have strong incentives not merely to
misrepresent reality, but to actually misunderstand it.

Shirky

Bug#840750: RFS: picocoin/0.1-2.gbp43047g

[Dave Steele]

Sorry for the delay.

Concerning your latest upload, 0.1-2+nmu1:

- The yellow flags on the mentors page should be cleared
  - This is not an NMU (non-maintainer upload). Look at
the help message associated with the lintian issue.
  - the home page and Vcs links are commented out in
control. Those should be enabled.
  - The watch file is important, and not complicated in
this case. Google 'debian watch github'.

- The package failed to build from source (FTBFS), using
  pdebuild. Is there a missing build dependency?

I haven't looked much farther than that.

Bug#855889: gnome-gmail: /usr/bin/gnome-gmail uses any available python

[Dave Steele]

On Wed, Feb 22, 2017 at 4:56 PM, Jan Schulz  wrote:
> Package: gnome-gmail
> Version: 2.3.1-1
> Severity: normal
>
...
>
> It would be nice if /usr/bin/gnome-gmail could use the full path of the system
> python interpreter /usr/bin/python or as it simply does
> `/usr/share/gnome-gmail/gnomegmail.py`, it could also simply put the py file
> itself into the path (the py file already has teh right hashbang:
> `#!/usr/bin/python -tt`.


I've made the fix to the repository. There won't be a new release
until after the next Debian stable release.


-- 
"Le mieux est l'ennemi du bien" - Voltaire

Bug#843126: gpg2 bug encountered

[Dave Steele]

The bug I encountered appears to be #46, which is still open:

https://github.com/freight-team/freight/issues/46


-- 
"Le mieux est l'ennemi du bien" - Voltaire

Bug#850100: Authentication broken when using Mozilla

[Dave Steele]

Package: gnome-gmail
Version: 2.3-3
Severity: important

The browser 'new window' behavior is broken for Mozilla
(Firefox/Iceweasel). This has the effect of breaking the
authentication process
when that browser is the default http application, rendering the
package unusable.

Bug#847476: Go language build dependency

[Dave Steele]

Package: golang-github-hanwen-go-fuse-dev
Version: 0.0~git20150627.0.324ea17-1

Replacing the golang-go build dependency with golang-any would improve
cross-architecture support, by allowing the use of gccgo on
architectures that do not support the native toolchain. In particular,
this affects the mips family.

E.g. - https://buildd.debian.org/status/package.php?p=gocryptfs

Also, there has also been quite a bit of upstream activity since the
last release.

-- 
"Le mieux est l'ennemi du bien" - Voltaire

Bug#847368: Watch file version handling

[Dave Steele]

Source: golang-github-jacobsa-crypto
Version: 0.0~git2016.0.293ce0c-1-2
Severity: normal
thanks

Note to self, for the next source release:

1) The repacked source tar version should include 'dfsg'

see https://wiki.debian.org/BenFinney/software/repack

This will involved watch options:
dversionmangle
oversionmangle

2) watch file version comparisons are currently broken

Per uscan:

debian_mangled_uversion: 0.0_git2016.0.293ce0c
debian_uversion: 0.0~git2016.0.293ce0c
distribution: debian
source: golang-github-jacobsa-crypto
status: only older package available
upstream_version: 0.0~git2016.0.293ce0c
version: 0.0~git2016.0.293ce0c-1
watch_file: version=3
opts=mode=git,dversionmangle=s/~/_/,uversionmangle=s/_git/~git/ \
https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-jacobsa-crypto.git
\ refs/tags/master/(.*) debian

Note that the status is 'not ok', despite upstream_version = debian_uversion

This information is derived from a call in UDD rimporters/upstream.rb:

uscan --pasv --dehs --no-download --watchfile debian/watch --package
#{source} --upstream-version #{version}"

... where 'version' is the version reported above. Running this
command shows that a '~' version is being compared with a '_' version.

Version handling is complicated by git, which does not allow '~', and
gbp, for a reason I don't remember.


-- 
"Le mieux est l'ennemi du bien" - Voltaire

Bug#843886: goopg: fails to sign and send email

[Dave Steele]

On Fri, Nov 11, 2016 at 3:04 AM, Arturo Borrero Gonzalez
 wrote:
> 2016-11-10 14:05:58,766:DEBUG:gnupg:gpg: gpg-agent is not available in
> this session

This is the problem. The agent is installed as a dependency, but not
sufficiently configured, See the README for guidance.

https://github.com/LeoIannacone/goopg

I don't recall running into this. I think you just need to specify
pinentry-gnome3. Let me know if there is something else needed.


-- 
"Le mieux est l'ennemi du bien" - Voltaire

Bug#843886: goopg: fails to sign and send email

[Dave Steele]

On Thu, Nov 10, 2016 at 8:15 AM, Arturo Borrero Gonzalez
 wrote:
> ...
>
> Then, in Gmail, if I create a new email a push 'Sign and Send', a yellow
> message box appears in the gmail window with:
>
>  Your message was not sent. Please retry.
>
> Any hint?
>

Can you verify that
/etc/opt/chrome/native-messaging-hosts/com.leoiannacone.goopg.json
(Chrome) or /etc/chromium/native-messaging-hosts/com.leoiannacone.goopg.json
(Chromium) is present?

Also, take a look at $HOME/.cache/goopg/log.

-- 
"Le mieux est l'ennemi du bien" - Voltaire

Bug#799227: Block 799227 by 800163

[Dave Steele]

block 799227 by 800163
thanks

-- 
"Le mieux est l'ennemi du bien" - Voltaire

Bug#805926: GNOME GMail broken on Jessie

[Dave Steele]

On Tue, Nov 24, 2015 at 9:25 PM, Dave Steele <dste...@gmail.com> wrote:

> See 806176
>

Removal request at 814860 and 806176.

-- 
"Le mieux est l'ennemi du bien" - Voltaire

Bug#814860: RM: gnome-gmail/stable -- ROM; Broken package

[Dave Steele]

On Tue, Feb 16, 2016 at 12:39 AM, Adam D. Barratt
 wrote:
> Removals from {,old*}stable are handled by the Release Team;
> reassigning.

The Developer Reference section 5.9.2 and reportbug should be updated
to reflect that.

-- 
"Le mieux est l'ennemi du bien" - Voltaire

Bug#814860: RM: gnome-gmail/stable -- ROM; Broken package

[Dave Steele]

On Tue, Feb 16, 2016 at 12:39 AM, Adam D. Barratt
 wrote:
>
> On Mon, 2016-02-15 at 21:21 -0500, David Steele wrote:
>>
>> The [gnome-gmail] package has been broken for some time, due to the
>> deprecation of it's old authentication mechanism ([#805926]). The proposed
>> patch fixing the package has been deemed too intrusive([#806176]). I
>> propose resolving the situation by removing the package from stable.
>
> Removals from {,old*}stable are handled by the Release Team;
> reassigning.

In that case add old-stable to the list. Again, the version in
testing/unstable should not be removed.


-- 
"Le mieux est l'ennemi du bien" - Voltaire

Bug#806176: jessie-pu: package gnome-gmail/1.8.3-1

[Dave Steele]

On Fri, Jan 1, 2016 at 11:10 PM, Dave Steele <dste...@gmail.com> wrote:
> On Fri, Jan 1, 2016 at 12:28 PM, Julien Cristau <jcris...@debian.org> wrote:
>>
>> On Tue, Nov 24, 2015 at 20:52:56 -0500, Dave Steele wrote:
>>
>>
>> > A diff of the changes is a bit problematic. An interactive compare is
>> > available at
>> >
>> > https://github.com/davesteele/gnome-gmail/compare/debian/1.8.3-1...updates-jessie
>> >
>> "problematic" is putting it nicely.  I don't think we're ready to accept
>> a complete rewrite as a stable update, sorry.
>>
>> Cheers,
>> Julien
>
>
> It's not a rewrite - the changes are not as extensive as the patch makes them 
> look. The main script had a name change that git didn't catch.
>
> Moving on, this leaves stable with a totally broken package. I'd like to 
> resolve that. Can we remove gnome-gmail from stable, without affecting the 
> status in testing or sid?
>

Removal request submitted as #814860.

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

-- 
"Le mieux est l'ennemi du bien" - Voltaire

Bug#806176: jessie-pu: package gnome-gmail/1.8.3-1

[Dave Steele]

On Fri, Jan 1, 2016 at 12:28 PM, Julien Cristau <jcris...@debian.org> wrote:

> On Tue, Nov 24, 2015 at 20:52:56 -0500, Dave Steele wrote:
>
>
> > A diff of the changes is a bit problematic. An interactive compare is
> > available at
> >
> >
> https://github.com/davesteele/gnome-gmail/compare/debian/1.8.3-1...updates-jessie
> >
> "problematic" is putting it nicely.  I don't think we're ready to accept
> a complete rewrite as a stable update, sorry.
>
> Cheers,
> Julien
>

It's not a rewrite - the changes are not as extensive as the patch makes
them look. The main script had a name change that git didn't catch.

Moving on, this leaves stable with a totally broken package. I'd like to
resolve that. Can we remove gnome-gmail from stable, without affecting the
status in testing or sid?

-- 
"Le mieux est l'ennemi du bien" - Voltaire

Bug#800163: jessie-pu: package cloudprint/0.11-5

[Dave Steele]

Control: tag -1 -moreinfo


On Fri, Jan 1, 2016 at 12:04 PM, Julien Cristau  wrote:
>
> Control: tag -1 moreinfo
>
>
> So I have a few questions:
> - what's the point of the new cps-auth script?


It was added to provide a UI for authentication in the systemd
environment. I kept it here to provide more visibility to the need for
authentication (an issue for some).

> - why did upstream require requests 2.7.0 (and what makes it not
>   actually needed)?


2.7.0 was the current version on pypi when upstream first invoked it.
In the pip install environment used upstream it's not a problem to
just require the latest. I tested against the Jessie version (and
other older releases), and found no compatibility problems.

>
> - why the build-depends change?


I added dh-python per a "Python Library Style Guide" on the wiki.
Looking at the reverse dependencies, it seems reasonable include it
explicitly. I'll delete it if you like - IIRC it pbuilds fine without
it.

>
> - why is -u removed from the default DAEMON_ARGS?


The -u option was removed from the utility itself, as part of the
paradigm shift from username/passwords to OAuth2. Username/password
storage was previously required to work-around a two-week expiration
of the pre-OAuth2 authentication token. There is no longer a need to
use or retain the password.

>
> > +The program will attemp to log in. If it is not successful, it will
>
> attempt
>

Ok.


Let me know when I should upload again.

-- 
"Le mieux est l'ennemi du bien" - Voltaire

Bug#806176: jessie-pu: package gnome-gmail/1.8.3-1

[Dave Steele]

On Sun, Nov 29, 2015, 4:23 PM Adam D. Barratt <a...@adam-barratt.org.uk>
wrote:

> On Tue, 2015-11-24 at 20:52 -0500, Dave Steele wrote:
> > Per 805926, gnome-gmail is broken on Jessie due to a lack of support
> > for OAuth2, and a reliance on GNOME 2 for configuration data. I went
> > through the exercise of crafting a minimal upgrade to address these
> > two issues, and have come to the conclusion that it makes more sense
> > to backport July's 1.9.3-1 release instead.
>
> A package for this was uploaded, and I've just flagged it for rejection.
>
> Aside from the lack of discussion, the package was incorrectly versioned
> as 1.9.3-1+deb8u1, making it higher than the 1.9.3 package currently in
> unstable (as would have become evident had a full diff been provided and
> discussed).
>
> Regards,
>
> Adam
>
> The diff is available via the URL provided. I'm available for discussion,
and to follow direction.

Bug#806176: jessie-pu: package gnome-gmail/1.8.3-1

[Dave Steele]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
thanks


Per 805926, gnome-gmail is broken on Jessie due to a lack of support
for OAuth2, and a reliance on GNOME 2 for configuration data. I went
through the exercise of crafting a minimal upgrade to address these
two issues, and have come to the conclusion that it makes more sense
to backport July's 1.9.3-1 release instead.

Basing the stable release on 1.9.3 adds other changes that make sense in stable:

 - Adapt to the changing levels of default mailer support required by
LibreOffice
 - Replace the partially-deprecated GMail IMAP extensions with the
more robust/secure GMail API
 - Improve the reverse-engineered GMail simple draft access URL
 - Support for multiple GMail accounts
 - Support for source tar signatures
 - Support for additional languages

External repo access to GNOME Gmail 1.9.3 has been available for some
time. I've tested this release against Jessie. There have been no
problem reports from Jessie users.

https://davesteele.github.io/gnome-gmail/ppa.html

A diff of the changes is a bit problematic. An interactive compare is
available at

https://github.com/davesteele/gnome-gmail/compare/debian/1.8.3-1...updates-jessie

-- 

"Le mieux est l'ennemi du bien" - Voltaire

Bug#805926: GNOME GMail broken on Jessie

[Dave Steele]

See 806176

Bug#805926: GNOME GMail broken on Jessie

[Dave Steele]

Package: gnome-gmail
Version: 1.8.3-1
Severity: grave


The gnome-gmail package is broken in Jessie for a couple of
reasons.First, IMAP authentication, which used for file attachments,
now requires OAuth2 authentication. OAuth2 support was first added in
1.9-1. Second, access to configuration settings is broken for a fresh
Jessie install. Version 1.8.3 still used GNOME 2's gconf for
configuration data.

Later versions of gnome-gmail, through at least 1.9.3, resolve these
problems and retain compatibility with Jessie.

-- 
"Le mieux est l'ennemi du bien" - Voltaire

Bug#800163: jessie-pu: package cloudprint/0.11-5

[Dave Steele]

Control: tags -1 - moreinfo


On Mon, Sep 28, 2015 at 10:03 PM, David Steele  wrote:
>
> Updated debdiff attached (deleted file detail again removed):
>
> Changes
>
>   - Version fixed
>   - systemd implementation reverted to init script
>   - fixed self reference in cps-auth(1)
>   - use {Python:Depends}
>   - systemd dependency removed
>   - revert to the stable version of python-daemon

Removing moreinfo. All issues addressed.

Bug#802260: gnome-gmail: Installation experience on KDE

[Dave Steele]

On Tue, Oct 20, 2015 at 2:49 PM, Mario Blättermann
<mario.blaetterm...@gmail.com> wrote:
> Hi Dave,
>
> 2015-10-20 15:24 GMT+02:00 Dave Steele <dste...@gmail.com>:
>>
>>
>> GNOME Gmail was developed for GNOME. It's behavior with KDE is
>> currently undefined. Getting it to work with KDE is 'wishlist'. Making
>> it clear that it is or is not compatible is 'normal'.
>
>
> OK, you are the upstream author, and of course you have designed gnome-gmail
> for Gnome. Maybe you haven't tested it under other desktop environments...
> Now I've installed Gnome to test the behavior in its home. Surprising, after
> installing gnome-core with all of its dependencies gnome-gmail works as
> expected! But I was too lazy to log out and log in again to switch the DE,
> it works under KDE!
>
...
>
> I'm quite sure the problem can be solved by adding some new runtime
> dependencies. I don't have any coding skills, but as the upstream author you
> should know which extra packages gnome-gmail needs. It would be somewhat odd
> to force users to install the whole gnome-core only for using gnome-gmail.

My point was simply to say that this issue should not be labeled
'grave', meaning that the problem rates package removal from the
repository to resolve.

Bug#802260: gnome-gmail: Some dependencies missing

[Dave Steele]

Control: -1 severity normal
Control: -1 retitle Installation experience on KDE


On Sun, Oct 18, 2015 at 4:10 PM, Mario Blättermann
 wrote:
> Package: gnome-gmail
> Version: 1.9.3-1
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> after installing gnome-gmail in Stretch, I was a bit surprised about the few
> extra dependencies which have to be installed on a KDE-only system. After
> launching gnome-gmail then, I got some error messages, gnome-gmail didn't
> start:

GNOME Gmail was developed for GNOME. It's behavior with KDE is
currently undefined. Getting it to work with KDE is 'wishlist'. Making
it clear that it is or is not compatible is 'normal'.

Bug#799227: cloudprint: Uses obsolete "ClientLogin" protocol

[Dave Steele]

 See #800163  for
the Jessie update submission.

Bug#800163: jessie-pu: package cloudprint/0.11-5

[Dave Steele]

On Tue, Sep 29, 2015 at 12:45 AM, Adam D. Barratt
 wrote:
> On Mon, 2015-09-28 at 22:03 -0400, David Steele wrote:
>> Updated debdiff attached (deleted file detail again removed):
>
> someone's uploaded a version to stable that looks like it was
> intended for unstable:
...
> I'm going to mark that version for rejection so it can be re-uploaded to
> the correct suite.

Thanks. Sorry.

-- 
"Le mieux est l'ennemi du bien" - Voltaire

Bug#800082: cloudprint-service: Why was the init script removed?

[Dave Steele]

On Sun, Sep 27, 2015 at 11:34 AM, Graham Knap  wrote:

> Why was the init script removed?
> Was it broken and no longer feasible to maintain?
>

It broke for me, and was getting in the way of OAuth2 work.


> As for my second question, you seem to have implied that the answer is
> "You can't". Please correct me if I'm wrong.
>

This has been discussed on the package dev site:

https://github.com/davesteele/cloudprint-service/issues/35

https://github.com/davesteele/cloudprint-service/issues/24#issuecomment-107965757

https://github.com/davesteele/cloudprint-service/issues/25#issuecomment-109652090

Tested patches with a fix would be most welcome, perhaps as a
cloudprint-service-sysv package.


> The fact that sysvinit is still available in testing/unstable
> indicates to me that other programs should maintain compatibility,
> when reasonably possible. If there's an incompatibility, the user
> needs to be told about it; IMHO ideally through a package conflict.
>

Sorry, things got a little crazy when the package broke.


> Currently, on systems running sysvinit, your package is non-functional
> after installation or upgrade, and no explanation is given. That's
> really not friendly.


I did the original work for my own benefit, and released it in the hopes it
would help others. If it is not helpful to you, please know that the return
policy is in effect.

I erred in providing visibility to the work outside of official
repositories. I'll rethink that policy in the future.

Bug#800082: cloudprint-service: Why was the init script removed?

[Dave Steele]

>
> Why was the init script removed? How can I use this package with sysvinit?
>
>
Debian stable/jessie supports systemd. Command to interact are e.g.
'systemctl {start|stop|status} cloudprintd'.

There is problem with running the latest versions of cloudprint on Jessie,
which is unrelated to OAuth2 and systemd. An updates release is in the
works.

-- 
"Le mieux est l'ennemi du bien" - Voltaire

Bug#800163: jessie-pu: package cloudprint/0.11-5

[Dave Steele]

On Sun, Sep 27, 2015 at 2:42 PM, Adam D. Barratt
<a...@adam-barratt.org.uk> wrote:
>
> On Sun, 2015-09-27 at 14:21 -0400, Dave Steele wrote:
> > On Sun, Sep 27, 2015 at 12:24 PM, Adam D. Barratt

> > I don't have a strong reason for making the systemd change. I can
> > revert it, if it is deemed necessary. It means a larger patch against
> > 0.13-1. OTOH, I am getting a fair amount of grief outside of
> > Jessie/testing/sid for requiring systemd.
>
> What do you mean? (Also what's happening outside of Debian isn't really
> relevant in the majority of cases.)

Just that I can go with reverting to sysv-init, or not. Reverting is
more work, which means risk. Ignoring outside influences is fine.

> > > Why does the python version need to be explicitly declared?
> >
> > Jessie+ ${python:Depends} defines a dependency which includes a
> > multiarch reference. This breaks compatibility with outside
> > distributions that could otherwise run the package just fine (e.g.
> > Raspberry Pi/Raspbian  is a popular target).
>
> Well, it includes a multiarch-dependency because that's how the Python
> packagers in Debian have arranged things. I have to admit to not being
> 100% sure of the consequences of dropping it, which makes me uneasy
> about doing it in stable.

With my change, the package is no longer, say, compatible with an
i386-compiled python on an AMD64 system. It requires a python using
the same architecture as the installation. I'm saying that I'm fine
with that distinction - I seriously doubt there's any real-world
scenario where this would cause a problem.

> > > Why does this need an explicit dependency on systemd?
> >
> > To make sure I have told e.g. Raspbian users that there is a
> > compatibility issue. Looks like I didn't need it.
>
> I'm not immediately convinced that adding dependencies in Debian to make
> sure that users outside of Debian are aware of something really makes
> sense.

OK


-- 
"Le mieux est l'ennemi du bien" - Voltaire

Bug#800163: jessie-pu: package cloudprint/0.11-5

[Dave Steele]

On Sun, Sep 27, 2015 at 12:24 PM, Adam D. Barratt
 wrote:

>
> +cloudprint (0.13-1+deb8u3) UNRELEASED; urgency=medium
>
> Where did you get that version number from? (specifically the "u3" bit.)

>From my attempt to understand updates versioning. It is a Jessie
updates candidate, which is modified from 0.13-1. I was unable to find
documentation leading me to a better understanding of what to put for
either part.

> I have to admit that I'm not personally particularly keen on the init
> system changes in a stable update - presumably there's nothing wrong
> with the sysvinit support in the package in Jessie?

I don't have a strong reason for making the systemd change. I can
revert it, if it is deemed necessary. It means a larger patch against
0.13-1. OTOH, I am getting a fair amount of grief outside of
Jessie/testing/sid for requiring systemd.

> +Depends: python-cups, cups, python-daemon, ${misc:Depends},
> + python (>= 2.7), python-pkg-resources, rsyslog | system-log-daemon,
> + python-requests
>
> Why does the python version need to be explicitly declared? Isn't that
> part of what ${python:Depends} is supposed to do?

Jessie+ ${python:Depends} defines a dependency which includes a
multiarch reference. This breaks compatibility with outside
distributions that could otherwise run the package just fine (e.g.
Raspberry Pi/Raspbian  is a popular target). I maintained a parallel
'ppa' distribution for some time which only included that change, and
eventually decided the extra work wasn't worth it.

This release will likely be the go-to release for those outside the
supported Debian ecosystem. I'd prefer to leave this as-is.

> -Depends: cloudprint, ${misc:Depends},
> - initscripts (>= 2.88dsf-13.3)
> +Depends: cloudprint, ${misc:Depends}, systemd
>
> Why does this need an explicit dependency on systemd?

To make sure I have told e.g. Raspbian users that there is a
compatibility issue. Looks like I didn't need it.

> +.TH cps-auth 1 2015-05-31 Linux "User Commands"
> +.SH SEE ALSO
> +cps-auth(1)
>
> Self-referential?


A bit.


In retrospect, I should have added a NEWS file as well.  I'll work a
rev based on the response to this message.

-- 
"Le mieux est l'ennemi du bien" - Voltaire

Bug#800163: jessie-pu: package cloudprint/0.11-5

[Dave Steele]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu


Google has removed support for SASL authentication for Cloud Print services,
and is now requiring OAuth2 authentication. This breaks the version of
cloudprint which is in Jessie, making the package totally non-functional.

I attempted a targeted patch of upstream changes to pull in only
OAuth2-relevant content. It was neither clean, concise, nor stable.
Instead, I
am proposing to modify the 3-month-old upstream 0.13 release for Jessie.

Changes required:
 - revert to support for the older python-daemon module
 - remove a setup.py version restriction on 'requests'

Debdiff attached, with patch detail on deleted files removed.


The change relative to 0.13 is here:

https://github.com/davesteele/cloudprint-service/compare/debian/0.13-1...updates-jessie


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

Kernel: Linux 4.0.0-2-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
diff -Nru cloudprint-0.11/cloudprint/cloudprint.py cloudprint-0.13/cloudprint/cloudprint.py
--- cloudprint-0.11/cloudprint/cloudprint.py	2014-01-05 19:29:25.0 -0500
+++ cloudprint-0.13/cloudprint/cloudprint.py	2015-07-08 23:10:28.0 -0400
@@ -1,231 +1,264 @@
 #!/usr/bin/env python
-import rest
-import platform
+# Copyright 2014 Jason Michalski 
+#
+# This file is part of cloudprint.
+#
+# cloudprint is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# cloudprint is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with cloudprint.  If not, see .
+
+import argparse
 import cups
+import datetime
 import hashlib
-import time
-import urllib2
-import tempfile
-import shutil
-import os
 import json
-import getpass
-import stat
-import sys
-import getopt
 import logging
 import logging.handlers
+import os
+import re
+import requests
+import shutil
+import stat
+import sys
+import tempfile
+import time
+import uuid
 
 import xmpp
 
 XMPP_SERVER_HOST = 'talk.google.com'
-XMPP_USE_SSL = True
 XMPP_SERVER_PORT = 5223
 
 SOURCE = 'Armooo-PrintProxy-1'
 PRINT_CLOUD_SERVICE_ID = 'cloudprint'
 CLIENT_LOGIN_URL = '/accounts/ClientLogin'
-PRINT_CLOUD_URL = '/cloudprint/'
+PRINT_CLOUD_URL = 'https://www.google.com/cloudprint/'
 
 # period in seconds with which we should poll for new jobs via the HTTP api,
 # when xmpp is connecting properly.
 # 'None' to poll only on startup and when we get XMPP notifications.
 # 'Fast Poll' is used as a workaround when notifications are not working.
-POLL_PERIOD=3600.0
-FAST_POLL_PERIOD=30.0
+POLL_PERIOD = 3600.0
+FAST_POLL_PERIOD = 30.0
 
 # wait period to retry when xmpp fails
-FAIL_RETRY=60
+FAIL_RETRY = 60
 
 # how often, in seconds, to send a keepalive character over xmpp
-KEEPALIVE=600.0
+KEEPALIVE = 600.0
+
+# failed job retries
+RETRIES = 1
+num_retries = 0
 
 LOGGER = logging.getLogger('cloudprint')
 LOGGER.setLevel(logging.INFO)
 
-class CloudPrintProxy(object):
+CLIENT_ID = '607830223128-rqenc3ekjln2qi4m4ntudskhnsqn82gn.apps.googleusercontent.com'
+CLIENT_KEY = 'T0azsx2lqDztSRyPHQaERJJH'
 
-def __init__(self, verbose=True):
-self.verbose = verbose
-self.auth = None
-self.cups= cups.Connection()
-self.proxy =  platform.node() + '-Armooo-PrintProxy'
-self.auth_path = os.path.expanduser('~/.cloudprintauth')
-self.xmpp_auth_path = os.path.expanduser('~/.cloudprintauth.sasl')
-self.username = None
-self.password = None
-self.sleeptime = 0
 
-def get_auth(self):
-if self.auth:
-return self.auth
-if not self.auth:
-auth = self.get_saved_auth()
-if auth:
-return auth
-
-r = rest.REST('https://www.google.com', debug=False)
-try:
-auth_response = r.post(
-CLIENT_LOGIN_URL,
-{
-'accountType': 'GOOGLE',
-'Email': self.username,
-'Passwd': self.password,
-'service': PRINT_CLOUD_SERVICE_ID,
-'source': SOURCE,
-},
-'application/x-www-form-urlencoded')
-xmpp_response = r.post(CLIENT_LOGIN_URL,
-{
-'accountType': 'GOOGLE',

Bug#799227: cloudprint: Uses obsolete "ClientLogin" protocol

[Dave Steele]

 WIP at https://github.com/davesteele/cloudprint-service/tree/updates-jessie

On Wed, Sep 16, 2015 at 9:44 PM, Vagrant Cascadian  wrote:
> Package: cloudprint
> Version: 0.11-5
> Severity: grave
> Control: fixed -1 0.13-1
>
> $ cloudprint
> Google username: ghkjadhsg
> Password:
> Traceback (most recent call last):
>   File "/usr/bin/cloudprint", line 9, in 
> load_entry_point('cloudprint==0.11', 'console_scripts', 
> 'cloudprint-cmd')()
>   File "/usr/share/cloudprint/cloudprint/cloudprint.py", line 496, in main
> sync_printers(cups_connection, cpp)
>   File "/usr/share/cloudprint/cloudprint/cloudprint.py", line 330, in 
> sync_printers
> remote_printers = dict([(p.name, p) for p in cpp.get_printers()])
>   File "/usr/share/cloudprint/cloudprint/cloudprint.py", line 177, in 
> get_printers
> r = self.get_rest()
>   File "/usr/share/cloudprint/cloudprint/cloudprint.py", line 173, in get_rest
> auth = self.get_auth()
>   File "/usr/share/cloudprint/cloudprint/cloudprint.py", line 99, in get_auth
> 'application/x-www-form-urlencoded')
>   File "/usr/share/cloudprint/cloudprint/rest.py", line 122, in post
> return self.rest_call('POST', path, data, content_type, headers, 
> response_type)
>   File "/usr/share/cloudprint/cloudprint/rest.py", line 105, in rest_call
> raise REST.RESTException('REST Error', resp.status, data)
> cloudprint.rest.RESTException: REST Error:404
> Message: https://developers.google.com/accounts/docs/AuthForInstalledApps
>
>
> Going to the URL reveals the following:
>
>   Important: ClientLogin has been officially deprecated since April 20,
>   2012 and is now no longer available. Requests to ClientLogin will fail
>   with a HTTP 404 response. We encourage you to migrate to OAuth 2.0 as
>   soon as possible.
>
>
> Seems OAuth 2.0 support needs to be backported (it works in cloudprint
> 0.13-1), or cloudprint should be removed from Debian jessie.
>
>
> live well,
>   vagrant
>
> -- System Information:
> Debian Release: 8.2
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages cloudprint depends on:
> ii  cups 1.7.5-11+deb8u1
> ii  python-cups  1.9.63-1
> ii  python-daemon1.5.5-1
> ii  python-pkg-resources 5.5.1-1
> pn  python:any   
> ii  rsyslog [system-log-daemon]  8.4.2-1+deb8u1
>
> cloudprint recommends no packages.
>
> cloudprint suggests no packages.
>
> -- no debconf information



-- 
"Le mieux est l'ennemi du bien" - Voltaire

Bug#797505: cloudprint: Should not ship .pyc files

[Dave Steele]

Nevermind. I see what's going on in your logs.

The spelling thing is still valid, though :-)

On Mon, Aug 31, 2015 at 10:23 AM, Dave Steele <dste...@gmail.com> wrote:

> Hi Chris,
>
> On Mon, Aug 31, 2015 at 3:58 AM, Chris Lamb <la...@debian.org> wrote:
>
>>
>> While working on the "reproducible builds" effort [0], we have noticed
>> that cloudprint could not be built reproducibly as it ships pyc files
>> instead of using an install-time helper to compile them.
>>
>
> Actually, it didn't ship with pyc -
>
> https://packages.debian.org/sid/cloudprint
> https://packages.debian.org/sid/all/cloudprint/filelist
>
> This is additonally against Policy 3.7 [1].
>>
>
> As an aside, spelling.
>
>
>> The attached patch removes these files from the build system, but there
>> is really no obvious reason not to switch to dh-python, etc. If there
>> is, please document it in debian/rules or debian/README.Source.
>>
>
> I do use dh-python -
>
>
> https://github.com/davesteele/cloudprint-service/blob/master/debian/rules
>
> I wouldn't mind adding the explicit delete, but I'd like to understand why
> we are getting different results. How are you building?
>
> --
> "Le mieux est l'ennemi du bien" - Voltaire
>



-- 
"Le mieux est l'ennemi du bien" - Voltaire

Bug#792055: Cloudprint crashes after an hour of idle time

[Dave Steele]

Package: cloudprint
Version: 0.12-3
Severity: important
thanks

The service crashes after an hour of idle processing, with the queue check.

Service is crashing after an hour.

Jul  9 22:42:49 debian-testing cloudprintd[8392]: Updated Printer MFCJ5910DW
Jul  9 22:42:50 debian-testing cloudprintd[8392]: Updated Printer MFC490CW
Jul  9 22:42:50 debian-testing cloudprintd[8392]: Polling for jobs
on MFC490CW
Jul  9 22:42:51 debian-testing cloudprintd[8392]: Polling for jobs
on MFCJ5910DW
Jul  9 22:42:51 debian-testing cloudprintd[8392]: Establishing
connection to xmpp server talk.google.com:5223
Jul  9 22:42:51 debian-testing cloudprintd[8392]: xmpp connection
established
Jul  9 23:42:51 debian-testing cloudprintd[8392]: Traceback (most
recent call last):
Jul  9 23:42:51 debian-testing cloudprintd[8392]: File
/usr/sbin/cloudprintd, line 9, in module
Jul  9 23:42:51 debian-testing cloudprintd[8392]:
load_entry_point('cloudprint==0.12', 'console_scripts',
'cloudprint-cmd')()
Jul  9 23:42:51 debian-testing cloudprintd[8392]: File
/usr/share/cloudprint/cloudprint/cloudprint.py, line 500, in main
Jul  9 23:42:51 debian-testing cloudprintd[8392]:
process_jobs(cups_connection, cpp)
Jul  9 23:42:51 debian-testing cloudprintd[8392]: File
/usr/share/cloudprint/cloudprint/cloudprint.py, line 400, in
process_jobs
Jul  9 23:42:51 debian-testing cloudprintd[8392]: printers =
cpp.get_printers()
Jul  9 23:42:51 debian-testing cloudprintd[8392]: File
/usr/share/cloudprint/cloudprint/cloudprint.py, line 208, in
get_printers
Jul  9 23:42:51 debian-testing cloudprintd[8392]: 'proxy': self.auth.guid,
Jul  9 23:42:51 debian-testing cloudprintd[8392]: File
/usr/local/lib/python2.7/dist-packages/requests/models.py, line 819,
in json
Jul  9 23:42:51 debian-testing cloudprintd[8392]: return
json.loads(self.text, **kwargs)
Jul  9 23:42:51 debian-testing cloudprintd[8392]: File
/usr/local/lib/python2.7/dist-packages/simplejson/__init__.py, line
505, in loads
Jul  9 23:42:51 debian-testing cloudprintd[8392]: return
_default_decoder.decode(s)
Jul  9 23:42:51 debian-testing cloudprintd[8392]: File
/usr/local/lib/python2.7/dist-packages/simplejson/decoder.py, line
370, in decode
Jul  9 23:42:51 debian-testing cloudprintd[8392]: obj, end =
self.raw_decode(s)
Jul  9 23:42:51 debian-testing cloudprintd[8392]: File
/usr/local/lib/python2.7/dist-packages/simplejson/decoder.py, line
400, in raw_decode
Jul  9 23:42:51 debian-testing cloudprintd[8392]: return
self.scan_once(s, idx=_w(s, idx).end())
Jul  9 23:42:51 debian-testing cloudprintd[8392]:
simplejson.scanner.JSONDecodeError: Expecting value: line 1 column 1
(char 0)


 This problem appears to be problem in upstream as well.


-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#787102: Cloudprint authentication stopped working

[Dave Steele]

Package: cloudprint
Version: 0.11-6
Severity: Serious


The authentication mechanism used by cloudprint is no longer supported
by Google. It will need to be upgraded to OAuth2 before the service is
again functional.

This upgrade is in process.

-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#637871: This bug can be closed since it's no longer valid.

[Dave Steele]

Agreed


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

Bug#786371: Traceback if no access token found

[Dave Steele]

Package: gnome-gmail
Severity: serious
Version:1.9-2

On the first run of gnome-gmail, the software will fail because no
oauth token is found in the keyring. Once the first authentication is
established, no further problems will be found - a Catch 22.

-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#785767: gnome-gmail rampant OAuth2 failures

[Dave Steele]

Package: gnome-gmail
Version: 1.9-2
Severity: serious

Upon further testing, OAuth2 started throwing off many errors, making
the package unusable. This bug is being entered to stop the migration
of the current version to testing.


-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#715083: Broken library symlink detected in libgrok-dev

[Dave Steele]

On Mon, Feb 23, 2015 at 8:54 AM, Vincent Bernat ber...@debian.org wrote:

  ❦  6 juillet 2013 05:01 GMT, David Steele dste...@gmail.com :

  This is being filed as Serious because it represents a violation
  of Policy

 Why was the severity downgraded then?


https://lists.debian.org/debian-devel/2013/07/threads.html#00209

-- 
Le mieux est l'ennemi du bien - Voltaire

Bug#695188: Multiple Bug# references in subject

[Dave Steele]

Control: tag -1 newcomer
thanks

The git source code repository is referenced from the wiki page [1].

The problem appears to be in the Perl 'process' script. There are a number
of places where the bug number and $newsubject are concatenated to make a
new subject, without checking to see if the bug number is already there.
Replace those occurrences with a function that does the check first? ... or
strip the bug number from $newsubject.

1 - https://wiki.debian.org/BTS

-- 
Le mieux est l'ennemi du bien - Voltaire

Bug#706190: Rework packaging to remove deprecated python-support

[Dave Steele]

From Ben Finney ben+deb...@benfinney.id.au

 Can you give more information on what exactly is happening and why
 this bug is “important” severity?

It appeared as a broken package (method not found), but was caused by
a module name collision. I renamed and re-prioritized in April 2013.
Now it just contains a patch to upgrade from python-support.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706190#10

You can modify the bug as you see fit.

-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#756845: [DRE-maint] Bug#756845: Independent verification of jekyll failure

[Dave Steele]

That works. I'm able to create a blog site now. Thanks.

On Wed, Aug 27, 2014 at 10:22 PM, Cédric Boutillier bou...@debian.org wrote:
 Hi Dave,

 On Mon, Aug 25, 2014 at 01:06:58PM -0700, Dave Steele wrote:
 I am also see this, with a fresh install on jessie.

 $ jekyll --version
 /usr/lib/ruby/vendor_ruby/jekyll/converters/sass.rb:6:in
 `module:Converters': uninitialized constant Jekyll::Converters::Scss
 (NameError)
 from /usr/lib/ruby/vendor_ruby/jekyll/converters/sass.rb:5:in 
 `module:Jekyll'
 from /usr/lib/ruby/vendor_ruby/jekyll/converters/sass.rb:4:in `top 
 (required)'
 from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
 from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
 from /usr/lib/ruby/vendor_ruby/jekyll.rb:11:in `block in require_all'
 from /usr/lib/ruby/vendor_ruby/jekyll.rb:10:in `each'
 from /usr/lib/ruby/vendor_ruby/jekyll.rb:10:in `require_all'
 from /usr/lib/ruby/vendor_ruby/jekyll.rb:132:in `top (required)'
 from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
 from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
 from /usr/bin/jekyll:6:in `main'

 jekyll/converters/sass.rb seems to need to require
 jekyll/converters/scss.rb. Can you add the following line at the
 beginning of /usr/lib/ruby/vendor_ruby/jekyll/converters/sass.rb:

 require 'jekyll/converters/scss'

 (e.g. after require 'jekyll/utils')

 and try again?

 Cheers,

 Cédric



-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#756845: More information on Jekyll startup bug

[Dave Steele]

tags 756845 -moreinfo
thanks

Here's moreinfo.

caveat - I don't know Ruby or Jekyll.

Running on up-to-date Jessie.

The error appears to be a subclass request, in
jekyll/converters/sass.rb, of Scss, which isn't defined. The Scss
class is defined in sass.rb, in the same directory. BTW, Ruby doesn't
like it when a 'require scss' is added to sass.rb ('require cannot
load such file).

I don't have any 'RUBY*' environment variables defined, nor any
config.yml's in the working directory path or home directory path.

# dpkg --list | grep jekyll
ii  jekyll2.2.0+dfsg-1
 all  Simple, blog aware, static site generator
ii  ruby-jekyll-coffeescript  1.0.0-1
 all  CoffeeScript converter for Jekyll
ii  ruby-jekyll-gist  1.1.0-1
 all  Liquid tag for displaying GitHub Gists in Jekyll
sites
ii  ruby-jekyll-paginate  1.0.0-1
 all  Default pagination generator for Jekyll
ii  ruby-jekyll-sass-converter1.0.0-1
 all  Basic Sass converter for Jekyll
ii  ruby-jekyll-watch 1.0.0-1



$ dpkg --list | grep ruby
ii  libruby2.1:amd64  2.1.2-3
 amd64Libraries necessary to run Ruby 2.1
ii  ruby  1:2.1.0.4
 all  Interpreter of object-oriented scripting language
Ruby (default version)
ii  ruby-afm  0.2.2-1
 all  Ruby library to read Adobe Font Metrics files
ii  ruby-ascii85  1.0.2-2
 all  Ruby library to encode/decode the Ascii85 format
ii  ruby-blankslate   2.1.2.4-4
 all  Ruby library providing a class with no predefined
methods
ii  ruby-celluloid0.15.2-2
 all  actor-based concurrent object framework for ruby
ii  ruby-classifier   1.3.4-1
 all  Ruby module to allow Bayesian and other types of
classifications
ii  ruby-coderay  1.1.0-1
 all  Ruby library for syntax highlighting
ii  ruby-coffee-script2.2.0-2
 all  Ruby CoffeeScript Compiler
ii  ruby-coffee-script-source 1.3.3-2
 all  CoffeeScript Compiler - Ruby integration
ii  ruby-colorator0.1-3
 all  String core extensions for terminal coloring
ii  ruby-execjs   2.2.1-1
 all  Run JavaScript code from Ruby
ii  ruby-fast-stemmer 1.0.2-1+b3
 amd64Fast Porter stemmer based on a C version of
algorithm for Ruby
ii  ruby-ffi  1.9.3debian-2
 amd64load dynamic libraries, bind functions from within
ruby code
ii  ruby-gsl  1.15.3+dfsg-2+b1
 amd64Ruby bindings for the GNU Scientific Library (GSL)
ii  ruby-hashery  2.1.1-1
 all  facets-bread collection of Hash-like classes
ii  ruby-jekyll-coffeescript  1.0.0-1
 all  CoffeeScript converter for Jekyll
ii  ruby-jekyll-gist  1.1.0-1
 all  Liquid tag for displaying GitHub Gists in Jekyll
sites
ii  ruby-jekyll-paginate  1.0.0-1
 all  Default pagination generator for Jekyll
ii  ruby-jekyll-sass-converter1.0.0-1
 all  Basic Sass converter for Jekyll
ii  ruby-jekyll-watch 1.0.0-1
 all  Rebuild your Jekyll site when a file changes
ii  ruby-json 1.8.1-1+b1
 amd64JSON library for Ruby
ii  ruby-kramdown 1.4.1-1
 all  Fast, pure-Ruby Markdown-superset converter
ii  ruby-liquid   2.6.1-1
 all  Ruby library for rendering safe HTML and email
templates
ii  ruby-listen   2.4.0-4
 all  Ruby library listening to file modifications
ii  ruby-mercenary0.3.4-1
 all  Lightweight and flexible library for writing
command-line apps in Ruby
ii  ruby-multi-json   1.10.0-1
 all  Ruby library to provide easy switching between
different JSON backends
ii  ruby-mysql2.8.2+gem2deb-4+b2
 amd64MySQL module for Ruby
ii  ruby-narray   0.6.0.9-1
 amd64Numerical N-dimensional Array library for Ruby
ii  ruby-oj   2.9.4-1
 amd64fast JSON parser and serializer for Ruby
ii  ruby-parslet  1.6.1-1
 all  Parser construction library with great error
reporting in Ruby
ii  ruby-pdf-core 0.2.5-2
 all  Ruby library to render PDF documents
ii  ruby-pdf-reader   1.3.3-1
 all  Ruby library for accessing the content of 

Bug#756845: Independent verification of jekyll failure

[Dave Steele]

I am also see this, with a fresh install on jessie.

$ jekyll --version
/usr/lib/ruby/vendor_ruby/jekyll/converters/sass.rb:6:in
`module:Converters': uninitialized constant Jekyll::Converters::Scss
(NameError)
from /usr/lib/ruby/vendor_ruby/jekyll/converters/sass.rb:5:in `module:Jekyll'
from /usr/lib/ruby/vendor_ruby/jekyll/converters/sass.rb:4:in `top (required)'
from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/lib/ruby/vendor_ruby/jekyll.rb:11:in `block in require_all'
from /usr/lib/ruby/vendor_ruby/jekyll.rb:10:in `each'
from /usr/lib/ruby/vendor_ruby/jekyll.rb:10:in `require_all'
from /usr/lib/ruby/vendor_ruby/jekyll.rb:132:in `top (required)'
from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/bin/jekyll:6:in `main'


-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#746621: DDPO: Integrate Piuparts (w/ patches)

[Dave Steele]

On Thu, May 1, 2014 at 10:04 PM, David Steele dste...@gmail.com wrote:
 Package: qa.debian.org
...
 Piuparts has a new summary file format, visible at
 https://piuparts.debian.org/summary.json.

 The attached patches use that data to integrate piuparts into the DDPO
 report, to the right of the lintian results...

This is a reminder that patches are available to integrate
piuparts.d.o results into DDPO.

Note that pejacevic currently tests 17 distinct distribution
combinations, and that maintainers must currently inspect each of
these individually to find all published installation errors for their
packages. The patches submitted with this wishlist item integrate
maintainer results across all of the tests into the DDPO output.

Again, comments are welcome.

-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#746711: piupartslib choking on arch Depends

[Dave Steele]

Package: piuparts-common
Severity: important
thanks

I was checking to see if there was a problem with 'https' in
summary.json, and ran into this.

It's coughing on the syntax of an architecture-specific dependency.
That's odd, since ${python:Depends}  has resolved to an arch-specific
reference in sid for some time.

http://lists.alioth.debian.org/pipermail/piuparts-reports/Week-of-Mon-20140428/008222.html

...
13:38:43 Copying log files
13:38:44 Removing old log files
13:38:45 Writing per-dir HTML pages
13:38:45 Writing counts.txt
Traceback (most recent call last):
  File /srv/piuparts.debian.org/share/piuparts/piuparts-report
, line 1687, in module
main()
  File /srv/piuparts.debian.org/share/piuparts/piuparts-report, line
1660, in main
section.generate_output(output_directory, section_names,
problem_list, web_host)
  File /srv/piuparts.debian.org/share/piuparts/piuparts-report, line
1518, in generate_output
self.generate_html()
  File /srv/piuparts.debian.org/share/piuparts/piuparts-report, line
1454, in generate_html
total_packages = self.write_counts_summary()
  File /srv/piuparts.debian.org/share/piuparts/piuparts-report, line
962, in write_counts_summary
count = len(self._binary_db.get_pkg_names_in_state(state))
  File 
/srv/piuparts.debian.org/lib/python2.7/dist-packages/piupartslib/packagesdb.py,
line 593, in get_pkg_names_in_state
self._compute_package_states()
  File 
/srv/piuparts.debian.org/lib/python2.7/dist-packages/piupartslib/packagesdb.py,
line 554, in _compute_package_states
db._compute_package_states()
  File 
/srv/piuparts.debian.org/lib/python2.7/dist-packages/piupartslib/packagesdb.py,
line 562, in _compute_package_states
state = self._compute_package_state(self._packages[package_name])
  File 
/srv/piuparts.debian.org/lib/python2.7/dist-packages/piupartslib/packagesdb.py,
line 462, in _compute_package_state
alt_deps = package.all_dependencies(header)
  File 
/srv/piuparts.debian.org/lib/python2.7/dist-packages/piupartslib/packagesdb.py,
line 108, in all_dependencies
vlist += self._parse_alternative_dependencies(header)
  File 
/srv/piuparts.debian.org/lib/python2.7/dist-packages/piupartslib/packagesdb.py,
line 86, in _parse_alternative_dependencies
parser = DependencyParser(self[header_name])
  File 
/srv/piuparts.debian.org/lib/python2.7/dist-packages/piupartslib/dependencyparser.py,
line 190, in __init__
self._list = self._parse_dependencies()
  File 
/srv/piuparts.debian.org/lib/python2.7/dist-packages/piupartslib/dependencyparser.py,
line 219, in _parse_dependencies
raise DependencySyntaxError(Expected comma, self._cursor)
piupartslib.dependencyparser.DependencySyntaxError: Error: pos 6:
Expected comma (text at error: ':all, libg', full text being parsed:
'python:all, libgtest-dev (= 1.6.0)')
Fri May  2 13:38:48 UTC 2014


-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#746711: [Piuparts-devel] Bug#746711: piupartslib choking on arch Depends

[Dave Steele]

Control: retitle -1 dependencyparser should not crash on questionable Depends
Control: severity -1 normal

On Fri, May 2, 2014 at 3:17 PM, Jakub Wilk jw...@debian.org wrote:
 The package in question (google-mock) doesn't use ${python:Depends}. It has
 python:all hardcoded in debian/control.

 The :all qualifier makes absolutely no sense to me.

 And in fact, the package is uninstallable: #746659

Adjusting accordingly.

-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#746718: piuparts_slave_* scripts not on PATH (1)

[Dave Steele]

Package: piuparts-slave
thanks

I'm going to take an opportunity here to log a number of annoyances that I
ran into with my recent re-introduction to the packaged version of the
piuparts service. It's been long enough for me that this amounts to a set
of somewhat fresh eyes on the subject. Logged as bugs to add some
persistence this time.

First issue:

The piuparts_slave_run and piuparts_slave_join scripts are intended to run
as user piupartss. But, they are stored in /usr/sbin, which is not in the
PATH for the user, and the documentation is insufficient on how to actually
execute them.

Those scripts should be in the PATH for piupartss, either by expanding the
PATH, or moving the scripts.

Previous report:
http://lists.alioth.debian.org/pipermail/piuparts-devel/2013-June/004633.html

-- 
Le mieux est l'ennemi du bien - Voltaire

Bug#746721: piuparts-master/slave cron file syntax wrong

[Dave Steele]

Package: piuparts-master
Severity: serious
thanks

Cron files, installed in /etc/cron.d, are not in the right format. The
required 'user' field is omitted.

Because of this issue, slaves are not started at boot, and no normal
recovery or retest actions are taken. Reports are not automatically
generated. Documentation is insufficient for straightforward manual
work-arounds (see also #746718).

Setting to 'serious', because it makes the package in question unusable or
mostly so, or makes the package unsuitable for release.

https://release.debian.org/testing/rc_policy.txt

This is assigned to piuparts-master, to avoid a release-critical bug
against piuparts. The issue applies to piuparts-slave as well.

Previous mention:
http://lists.alioth.debian.org/pipermail/piuparts-devel/2012-June/003048.html

Also, more cron tasks than are necessary are commented out, with
insufficient guidance on what/when to enable.

-- 
Le mieux est l'ennemi du bien - Voltaire

Bug#746723: Support 'file://' access for piuparts-master report output

[Dave Steele]

Package: piuparts-master
Severity: wishlist
thanks

It would be nice to be able to review the HTML output of
piuparts-report without having to install and configure a web server.
Access via file:/// URLs would be viable if the reports were reworked
to use relative links throughout.

This would also require a rework of the doc_root mangling in
piuparts-report main().

-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#746722: Spurious log directory creation in piuparts-report

[Dave Steele]

Package: piuparts-master
thanks

Each run of piuparts-report results in either an exception crash, or a
fresh set of master section log file directories in the current
directory.

Per 740386, where the problem was discussed:

On Sat, Mar 1, 2014 at 4:16 PM, Andreas Beckmann a...@debian.org wrote:
 On 2014-03-01 16:44, Dave Steele wrote:
 On Sat, Mar 1, 2014 at 1:52 AM, Andreas Beckmann a...@debian.org wrote:
 On 2014-02-28 22:57, Dave Steele wrote:
 3057fb6 piuparts-report.py: Establish PackagesDB prefix

 NACK. Or why is this needed for sources_db? This doesn't have logfiles.

...
 line 345, in create_subdirs
 os.makedirs(sdir)
   File /usr/lib/python2.7/os.py, line 157, in makedirs
 mkdir(name, mode)
 OSError: [Errno 13] Permission denied: 'pass'

...
 So let's try to fix this properly, not work around it ...

 I'll look into this later next week.


 Andreas

I'd say that the 'proper' fix to packagesdb is more substantial than
any of the alternatives likely under consideration.

The proposed patch was:

diff --git a/piuparts-report.py b/piuparts-report.py
index 8a5e9b6..cf55c4c 100644
--- a/piuparts-report.py
+++ b/piuparts-report.py
@@ -731,7 +731,7 @@ class Section:
 self._load_package_database(section, master_directory)
 self._binary_db = self._package_databases[section]

-self._source_db = piupartslib.packagesdb.PackagesDB()
+self._source_db =
piupartslib.packagesdb.PackagesDB(prefix=self._section_directory)
 self._source_db.load_packages_urls(
 self._distro_config.get_sources_urls(
 self._config.get_distro(),


-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#746724: p.d.o spelling errors

[Dave Steele]

Package: piuparts-master
Severity: minor
thanks

The words licensed and ditto are spelled incorrectly in the footer
of all of the web pages created by piuparts-report.

-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#746722: [Piuparts-devel] Bug#746722: Bug#746722: Spurious log directory creation in piuparts-report

[Dave Steele]

On Fri, May 2, 2014 at 5:21 PM, Holger Levsen hol...@layer-acht.org wrote:
 do you still propose this patch or something else?

I would propose the patch, and eventual rework of packagesdb.


-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#746724: p.d.o spelling errors

[Dave Steele]

On Fri, May 2, 2014 at 5:24 PM, Cyril Brulebois k...@debian.org wrote:
 Both licensed and licenced are correct.

'licenced' is unambiguously wrong in American English. Google.co.uk top
links state it is incorrect for the Queen's English as well:

http://www.grammar-monster.com/easily_confused/licence_license.htm

http://dictionary.cambridge.org/us/spellcheck/british/?q=licenced

-- 
Le mieux est l'ennemi du bien - Voltaire

Bug#740386: [Piuparts-commits] [piuparts] 06/06: piuparts-report.py: Default summary dist support

[Dave Steele]

On Wed, Apr 30, 2014 at 6:24 AM, Holger Levsen
hol...@moszumanska.debian.org wrote:

 holger pushed a commit to branch develop
 in repository piuparts.

 commit b8096c51c66e7c97bf5aaed8014684522ffc8239
 Author: David Steele dste...@gmail.com
 Date:   Sun Mar 9 21:34:13 2014 -0400

 diff --git a/piuparts-report.py b/piuparts-report.py
 index 8b1b858..94e7142 100644
 --- a/piuparts-report.py
 +++ b/piuparts-report.py
 @@ -496,7 +496,7 @@ class Config(piupartslib.conf.Config):
  max-reserved: 1,
  doc-root: /,
  known-problem-directory: 
 @sharedir@/piuparts/known_problems,
 -reporting-sections: ,
 +reporting-sections: default,
  precedence: 1,
  master-host: piuparts.debian.org,
  },


The summary json file is being created on pejacevik now, and looks
shiny, except for the URLs. I used master-host to form the URLs. That
field is previously defined, for the slave to find the master. All of
the JSON source references are to http://pejacevik instead of
http://piuparts.

I'll submit a fix tonight, to define and use a web-host.

-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#740386: [Piuparts-devel] Summary.json web-host

[Dave Steele]

On Wed, Apr 30, 2014 at 11:19 AM, Holger Levsen hol...@layer-acht.org wrote:
 On Mittwoch, 30. April 2014, Dave Steele wrote:
 I'll submit a fix tonight, to define and use a web-host.

 cool. Please hurry up, else it might not be included in 0.58! Not that it
 matters much, but anyway... :)

Feast or famine...

five-holger(3)

974d80b piuparts-report.py: De-indent global summary func
4e75ffb piuparts-report.py: Refactor global summary
949c05f piuparts-report.py: Use web-host for summary URL

-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#740386: [Piuparts-devel] Bug#740386: Bug#740386: Summary.json web-host

[Dave Steele]

On Wed, Apr 30, 2014 at 5:29 PM, Holger Levsen hol...@layer-acht.org wrote:
 On Mittwoch, 30. April 2014, Dave Steele wrote:
 974d80b piuparts-report.py: De-indent global summary func

 unneeded (and/or rather unwanted atm...)

No functional changes, so OK.

 4e75ffb piuparts-report.py: Refactor global summary
 -if os.path.isfile(summary_path):
 -os.unlink(summary_path)

 did you really want that?

Yes. It isn't needed.

-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#745392: gnome-tweak-tool: enabling 'Icons on Desktop' greys out the background

[Dave Steele]

From Andreas Glaeser bugs.andreas.glae...@freenet.de

I wondered for some time, why the desktop-background is grey with my 
user-profile and the
normally set background is shown with a new user-profile. Now I found that 
this is because
of the option 'Icons on Desktop' in the tweak-tool under 'Desktop'.

I'd love to hear a definitive answer on what is going on here. Is this
considered a bug, which will be fixed at some point, or a feature?

I also have a problem with the background settings app persistently
crashing. Is this part of the same problem, or is it independent? Is
that a known problem to be fixed?

Google searches say the fix for one or both of these problems is to
set gnome-tweak-tool to use the file manager to manage the background.
I can't find that option. Is it gone, or am I just not looking hard
enough?

-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#740386: [Piuparts-devel] Five-holger - Support automated summary.json reporting-section definitions

[Dave Steele]

On Wed, Mar 19, 2014 at 6:36 AM, Holger Levsen hol...@layer-acht.org wrote:
  9a92575 test_pkgsummary.py: Initial pkgsummary tests

 includes a typo: ittp instead of http

Not a typo. That's an argument validation test.

 please dont disable that/those time sensitive test/s.

 good thing not to create a summary when no section is defined, but please
 log(ging.info) a hint saying so

Done. I took the opportunity to collapse some commits. There was also
a small Depends bug that is now fixed.

five-holger(6)

c984178 Close bug in changelog for JSON summary report
811e3cf Change pkgsummary 'summ' references to 'summary'
3112cfe Improve pkgsummary reliability and testability
2080210 test_pkgsummary.py: Initial pkgsummary tests
5552827 conf.py: Add get_std_distro()
8dbbc39 piuparts-report.py: Default summary dist support

 Dave, what/where's the bug / patch to make DDPO use this?

Not released at the moment. I was waiting for a published summary file
before proceeding on that side.

-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#740386: Five-holger - Support automated summary.json reporting-section definitions

[Dave Steele]

On Mon, Mar 10, 2014 at 12:27 AM, Dave Steele dste...@gmail.com wrote:
 On Sun, Mar 2, 2014 at 9:57 PM, Holger Levsen hol...@layer-acht.org wrote:

 I don't like this patch as it hardcodes info which is also in the distro-info
 packages. Plus: why is it untested?


 On Sonntag, 2. März 2014, Dave Steele wrote:
 How about this (interesting part Support default reporting-section 
 definition):


Updated, with more robust section mapping. The history is rewritten
due to a small changelog bug.

I've tested this against the full pejacevik configuration, with no issues.

 five-holger(8)

92d63d4 pkgsummary documentation cleanup
dcba555 Change pkgsummary 'summ' references to 'summary'
c4fb1d4 Improve pkgsummary reliability and testability
9a92575 test_pkgsummary.py: Initial pkgsummary tests
513680c conf.py: Add get_std_distro()
38b06eb piuparts-report.py: Support default reporting-section definition
1b976cb conf.py: _map_distro properly for '*-proposed'
7af5845 conf.py: Add _map_distro() support for all others

https://github.com/davesteele/piuparts/compare/develop...five-holger

-- 
Le mieux est l'ennemi du bien - Voltair


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

Bug#695188: Multiple Bug# references in subject

[Dave Steele]

I'd like to second the notion that this is a real bug, and that it
should be addressed - e.g.

http://lists.alioth.debian.org/pipermail/piuparts-devel/2014-March/thread.html#5197

I agree with #27 that the solution could be to check for the presence
of a Bug# in the subject before adding one.

I suggest that the 'unreproducible' and 'moreinfo' tags be removed
from this bug.

-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#740386: Five-holger - Support automated summary.json reporting-section definitions

[Dave Steele]

On Sun, Mar 2, 2014 at 9:57 PM, Holger Levsen hol...@layer-acht.org wrote:

 On Sonntag, 2. März 2014, Dave Steele wrote:
 5892fca piuparts.conf.pejacevic: Add reporting-sections

 I don't like this patch as it hardcodes info which is also in the distro-info
 packages. Plus: why is it untested?


How about this (interesting part in the last commit):

five-holger(6)

da5521f pkgsummary documentation cleanup
f347d85 Change pkgsummary 'summ' references to 'summary'
25fc7ab Improve pkgsummary reliability and testability
1d1c432 test_pkgsummary.py: Initial pkgsummary tests
9f03d00 conf.py: Add get_std_distro()
37d9c93 piuparts-report.py: Support default reporting-section definition

https://github.com/davesteele/piuparts/compare/develop...five-holger

This makes reporting-sections optional. I'd prefer not to discuss
particulars on the distribution selection algorithm. The configuration
variable is available as an override.

Tested on a handful of sections, including a new upgrade section. I
wouldn't mind hearing how it runs on a more robust instance.

-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#740386: [Piuparts-devel] Bug#740386: Bug#740386: Bug#740386: More robust piuparts results reporting format

[Dave Steele]

On Sun, Mar 2, 2014 at 9:57 PM, Holger Levsen hol...@layer-acht.org wrote:
 control: tags -1 + pending

 + ...The names
 + unstable, testing, stable, oldstable, and experimental
 + have special meaning.

 yet this text lacks an explaination what the special meaning is. can you
 explain and add that please?!?


The current precise definition is a bit obtuse in this context - DDPO
sorts these strings, for use in a tooltip, in a particular order
relative to each other, vs. alphabetical for all others. It's a bit
presumptuous to say that in the README now, since DDPO does no such
thing yet.

The purpose here was to give a hint on a scheme for entering values.
The summary doesn't enforce a model, except for the reserved
'overall'.

To work with my current DDPO code, I could add something like By
convention, the values [...] are expected here, though other values
can be used.

The real answer is that the special meaning is not yet defined. It
is dependent on how you want to use summaries. Last month, I would
have said that the 'special' values were required, at a minimum, to
populate the piuparts distribution table in DDPO. They dropped those
tables for other metrics in February, to reclaim space.

The current concept, defined by my DDPO patches, is that you have the
ability to control the distributions reported by the DDPO tool tip
from piuparts.conf, with the special sorting for the special
reporting-sections.

Another concept would be to limit DDPO to the special sections.This
would let you use other values to report other summary breakdowns to
other contexts. The 'overall' concept would need to be reworked a bit
here.

Which do you prefer?

 5892fca piuparts.conf.pejacevic: Add reporting-sections

 I don't like this patch as it hardcodes info which is also in the distro-info
 packages. Plus: why is it untested?

The point is that it is not hard coded. It's not necessarily
deterministic from distro-info. I can think of a couple of models for
assigning sections to distributions, and didn't want to hard code one,
or one mapping to distro-info. Do you map an upgrade test to the
newest dist in the list, or to more than one? Do you want all sections
to be summarized, per an algorithm, or just some, per a config? I
wouldn't be surprised to see the values here change.

Right now, if you don't define reporting-sections, you'll get an empty
global summary. Would you prefer a default? How would you see that
being calculated for the existing p.d.o sections?

It is untested because I don't have a cloned pejacevic environment.


 I've merged them all into develop now, except 5892fca. Plus I have pushed the
 branch but not yet deployed it.


Thanks

-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#740386: [Piuparts-devel] Bug#740386: More robust piuparts results reporting format

[Dave Steele]

Another tack. I've removed the PackagesDB prefix commit. There is no
linkage between the logdir traceback issue and summary-json.

summary-json (11)

247ac53 piuparts-report: Minor rework of main loop
54d116c README_server.txt: Add reporting-section
94e8539 pkgsummary.py: Initial checkin for pkg summaries
b00a6ea piuparts-report.py: Section-level summary support
d442180 pkgsummary.py: Add support for global merge
9bb8332 piuparts-report.py: generate_global_summary()
4fd7512 Add blocking count to the JSON summary format
6a1c8f1 pkgsummary.py: tooltip() routing for DDPO
e57fdcf changelog: Entry for summary.json
35f473b index.tpl: Placekeeper announce of summary.json
5892fca piuparts.conf.pejacevic: Add reporting-sections

-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#740386: More robust piuparts results reporting format

[Dave Steele]

On Sat, Mar 1, 2014 at 1:52 AM, Andreas Beckmann a...@debian.org wrote:
 On 2014-02-28 22:57, Dave Steele wrote:
 3057fb6 piuparts-report.py: Establish PackagesDB prefix

 NACK. Or why is this needed for sources_db? This doesn't have logfiles.


Because PackagesDB always cares about log files.

$ pwd
/home/otheruser/
$ whoami
piupartsm
$ /usr/share/piuparts/piuparts-report
09:56:10 ---
09:56:10 Running section sid
09:56:10 Loading and parsing Packages file
09:56:10 Opening http://127.0.0.1/debian/dists/sid/main/binary-amd64/Packages.*
09:56:10 Fetching
http://127.0.0.1/debian/dists/sid/main/binary-amd64/Packages.gz
Traceback (most recent call last):
  File /usr/share/piuparts/piuparts-report, line 1654, in module
main()
  File /usr/share/piuparts/piuparts-report, line 1625, in main
section = Section(section_name, master_directory, doc_root,
packagedb_cache=packagedb_cache)
  File /usr/share/piuparts/piuparts-report, line 734, in __init__
self._source_db = piupartslib.packagesdb.PackagesDB()
  File /usr/lib/python2.7/dist-packages/piupartslib/packagesdb.py,
line 313, in __init__
self.create_subdirs()
  File /usr/lib/python2.7/dist-packages/piupartslib/packagesdb.py,
line 345, in create_subdirs
os.makedirs(sdir)
  File /usr/lib/python2.7/os.py, line 157, in makedirs
mkdir(name, mode)
OSError: [Errno 13] Permission denied: 'pass'

This is why there are turd log directories in piupartsm home, or
wherever else report is run.

-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#740386: [Piuparts-devel] Bug#740386: More robust piuparts results reporting format

[Dave Steele]

On Sat, Mar 1, 2014 at 4:16 PM, Andreas Beckmann a...@debian.org wrote:
 On 2014-03-01 16:44, Dave Steele wrote:
 On Sat, Mar 1, 2014 at 1:52 AM, Andreas Beckmann a...@debian.org wrote:
 On 2014-02-28 22:57, Dave Steele wrote:
 3057fb6 piuparts-report.py: Establish PackagesDB prefix

 NACK. Or why is this needed for sources_db? This doesn't have logfiles.

 OSError: [Errno 13] Permission denied: 'pass'

 I'll look into this later next week.


In the meantime, I'd like to maintain progress on the submission. I'm
keeping the commit, in lieu of another current fix. Holger, you can
can keep it or drop it on merge, at your option, without affecting the
rest of the branch.

I've updated to the latest develop. Can we move forward?

-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#740386: More robust piuparts results reporting format

[Dave Steele]

Package: piuparts-master
Version: 0.57
Severity: wishlist
Tags: patch
User: debian...@lists.debian.org
thanks

Create a new JSON summary on the piuparts-master web site for
exporting richer information about piuparts test results. The content
is targeted for piuparts integration into DDPO.

summary-json(12):

3057fb6 piuparts-report.py: Establish PackagesDB prefix
b4681a4 piuparts-report: Minor rework of main loop
6692bf6 README_server.txt: Add reporting-section
55211a6 pkgsummary.py: Initial checkin for pkg summaries
fa72461 piuparts-report.py: Section-level summary support
b0ecc22 pkgsummary.py: Add support for global merge
fb0cee5 piuparts-report.py: generate_global_summary()
a3d3ce4 Add blocking count to the JSON summary format
e8ae2a9 pkgsummary.py: tooltip() routing for DDPO
c73a3ea changelog: Entry for summary.json
35a1a8e index.tpl: Placekeeper announce of summary.json
e467473 piuparts.conf.pejacevic: Add reporting-sections

https://github.com/davesteele/piuparts/compare/develop...summary-json

Compared to the existing yaml, the json adds:
- a means to define a mapping between piuparts sections and Debian
distributions, under control of piuparts.conf
- ability to report a condensed test result by source package at the
distribution and global levels
- more refined state information (blocked/waiting)
- a blocking count for failed tests
- an optimal URL for inspecting the reported result for each package,
managed by piuparts.conf
- all export information stored at a single URL

-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#625278: Prioritization of broken symlink issues

[Dave Steele]

On Fri, Feb 21, 2014 at 12:34 PM, Agustin Martin agmar...@debian.orgwrote:

 On Mon, Feb 17, 2014 at 12:29:49PM -0500, Dave Steele wrote:
  1) How does lintian know to issue this warning? Does it download
  piuparts results?

 I am afraid that by manual interaction. Both work differently, lintian
 works
 on unpacked packages while pipuarts works on installed (and configured,
 along
 with the dependencies) packages.


I didn't know about the lintian test when I wrote earlier. I was thinking
in terms of broken symlinks left after uninstall (which is a bigger problem
IMO).


 There is a difference between an email and an implicit suggestion about a
 flood of bug reports.


Based on history, that's not what happens. There's only one bug report,
plus the purely psychic pain of knowing that there are packages out there
that could be tested, if just...

See fontconfig-config as an example. A recent failure there has ballooned
the untestable count in sid to 10% of all packages

 https://piuparts.debian.org/sid/states.png

The only developer ramification - a note on the bug report:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730361#10

I meant to focus on the psychic part. Sorry if I suggested/threatened a
flood of complaints.

Somewhere next week I plan to upload 1.22.1 to deal with this
 #625278 bug report in a way based in attached patch.


I appreciate that you are addressing this. Thanks.

-- 
Le mieux est l'ennemi du bien - Voltaire

Bug#625278: Prioritization of broken symlink issues

[Dave Steele]

On Mon, Feb 17, 2014 at 7:14 AM, Agustin Martin agmar...@debian.org wrote:
 Anyway, I think this will be fixed before we reach that point. But something
 like

 stage a) lintian warning + piuparts warning
 stage b) lintian error   + piuparts error

 would have IMHO be a better approach, even if the time between a) and b) is
 not long.

1) How does lintian know to issue this warning? Does it download
piuparts results?
2) Replace 'lintian warning' with 'email warning' and you've gotten
exactly what you asked for.

-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#625278: Prioritization of broken symlink issues

[Dave Steele]

On Sun, Feb 16, 2014 at 11:14 AM, Agustin Martin
agustin6mar...@gmail.com wrote:
 2014-02-15 5:47 GMT+01:00 Dave Steele dste...@gmail.com:
 Hi Agustin,

 On the subject of TODO list priorities, note that the Piupart broken symlink
 test is likely to be elevated soon, returning an error result rather than a
 warning.

 Hi David,

 While I really appreciate your work on following the bug report, I
 really think this is nonsensic escalation.

OK. For my part, the issue is moot.

I came into  this as a developer of one of the over one-thousand
packages that has a message saying there is a (dictionaries-common)
broken symlink problem in the piuparts test. I had to do (a small
amount of) research to determine that, while it is a problem worth
addressing, it wasn't my problem. Multiplying that inconvenience by
one thousand - I found that worthy of attention, and a three-year-old
bug report on the subject worthy of a bump.

 Sorry again if I look unpolite, I am just after lunch and a bit
 overheated. Debian policy must be stated directly by Debian policy,
 not indirectly by whatever package requirements. pipuarts is not
 Debian policy, so I'd personally consider this a bug in piuparts
 itself.

I've come to the conclusion that the Policy is Debian's version of
Godwin's Law. It can be a driving principle, more of just a guideline,
or not important, dependent on the needs of the argument. Invoking it
diverts discussion. So, no more about that from me.

As you say, this is about a piuparts test result. My involvement in
piuparts has convinced me that the tests add value, and reflect errors
appropriately. I've seen that the issues found don't get fixed until
they are classified as errors. I've also come to understand that
addressing an issue like this as a piuparts error would cause more
problems than it solves.

If and when the test is elevated, the thousand packages will await
resolution of the bug owner.

-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#625278: Prioritization of broken symlink issues

[Dave Steele]

On Tue, 3 May 2011, Agustin Martin wrote:
On Tue, May 03, 2011 at 05:05:09AM +0200, J G Miller wrote:
 Package: dictionaries-common
 Version: 1.10.6
 Severity: normal

 The dictionaries-common package contains two dangling symbolic links
 in /usr/lib/ispell

 0 lrwxrwxrwx 1 root root   36 2011-03-28 16:16 default.aff - 
 /etc/dictionaries-common/default.aff
 0 lrwxrwxrwx 1 root root   37 2011-03-28 16:16 default.hash - 
 /etc/dictionaries-common/default.hash

 apt-file search indicates that no packages contains these files.

Thanks for the info.

That is a design choice, those symlinks will point to default ispell
dictionary if ispell dictionaries are installed. Same happens with
/etc/dictionaries-common/words.

Creating those symlinks when needed and removing them from postrm is
in my TODO list, but somewhere low. So, I am leaving this bug report open
until I can work on that.

Regards,

--
Agustin

Hi Agustin,

On the subject of TODO list priorities, note that the Piupart broken symlink
test is likely to be elevated soon, returning an error result rather than a
warning.

There are currently over one thousand packages which depend on
dictionaries-common. The logs for each contain warnings about the
symlinks left by the dependency. Once the change is made to the test,
those packages are subject to becoming untestable in piuparts.

https://piuparts.debian.org/sid/broken_symlinks_issue.html

The broken symlinks indicated by the log are as follows:

0m31.4s ERROR: WARN: Broken symlinks:
  /usr/share/dict/words - /etc/dictionaries-common/words
  /usr/lib/ispell/default.aff - /etc/dictionaries-common/default.aff
  /usr/lib/ispell/default.hash - /etc/dictionaries-common/default.hash

https://piuparts.debian.org/sid/pass/dictionaries-common_1.20.5.log

~

-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#715098: Broken library symlink detected in libostyle-dev

[Dave Steele]

On Mon, Oct 7, 2013 at 7:46 PM, Neil Roeth n...@debian.org wrote:

 On 07/06/2013 01:01 AM, David Steele wrote:


 ...
 The log contains the following broken symlinks:

/usr/lib/libostyle.so
  - libostyle.so.1.0.0
/usr/lib/libospgrove.so
  - libospgrove.so.1.0.0
/usr/lib/libogrove.so
  - libogrove.so.1.0.0

 The symlinks all point to a valid library.   What exactly is the issue?


Probably a missing dependency on the package providing the library.
Piuparts is testing only the -dev package - there is no explicit reference
to the other binary package(s) in the source package.

-- 
Le mieux est l'ennemi du bien - Voltaire

Bug#712440: Missing recently archived bugs

[Dave Steele]

On Sun, Sep 29, 2013 at 1:01 AM, Don Armstrong d...@debian.org wrote:
 On Sat, 28 Sep 2013, Dave Steele wrote:
 Should I expect to be able to use BTS to get a complete history of
 bugs for a project?

 Yes, all of them should be returned. I'm not sure why 717780 isn't being
 returned.


Thanks for the prompt reply.

I've worked around the problem by being more insistent about remembering RTSs.

Be aware that I captured on the order of 100 archived
sponsorship-requests RFSs that were not displayed by BTS (e.g. the RFS
open count for January went from 17 to 85 after the collection), by
going back through the debian-mentors list archive. I went back as far
as January. I believe that was the only month that did not reveal
missing bugs.

I'm attaching this to another bug with a similar report against BTS.
You may want to bump the priority.

-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#706904: Chinese Checkers RFS review

[Dave Steele]

On Sep 20, 2013 1:36 AM, Paul Gevers elb...@debian.org wrote:

 On 20-09-13 01:29, Dave Steele wrote:
  ... it would be simpler if the source format were '3.0
  (native)', not '3.0 (quilt)'.

 Please don't recommend native as format. Especially not for this reason.
 The native format is meant for software that only makes sense in Debian.


Do you have a source for that?  I was told otherwise before.

Bug#706904: Chinese Checkers RFS review

[Dave Steele]

On Fri, Sep 20, 2013 at 9:08 AM, Paul Tagliamonte paul...@debian.org wrote:
 On Fri, Sep 20, 2013 at 08:00:23AM -0400, Dave Steele wrote:
 Do you have a source for that?  I was told otherwise before.

 This is what defines a Debian native package.

 Here's why it's stupid for non-native packages:

...

 In addition, we use pristine (and hash-identical) tarballs with upstream
 releases. You can't do this with 3.0 (native), without being upstream.

 I'm all for allowing native packages, but newbies shouldn't be using
 them to package software with an upstream.


I'm not sure we are clear with terms here. The newbie is the upstream,
and he has chosen to include the debian directory in his main
repository. Should he choose to rev the packaging, upstream is
coordinated, by definition.

I'm good with the idea that using 'native' with non-native packages is
'stupid'. My question was about resolving the definition of 'native'.
Shouldn't it simply mean that upstream is the Debian maintainer, and
that the packaging is included? That is the guidance I was given
regarding one of my packages.

-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#706904: Chinese Checkers RFS review

[Dave Steele]

On Fri, Sep 20, 2013 at 10:19 AM, Paul Tagliamonte paul...@debian.org wrote:
 On Fri, Sep 20, 2013 at 10:18:18AM -0400, Dave Steele wrote:
 I'm not sure we are clear with terms here. The newbie is the upstream,
 and he has chosen to include the debian directory in his main
 repository. Should he choose to rev the packaging, upstream is
 coordinated, by definition.

 As such, a trivial debian package change would trigger a new upstream
 release. If this is the intent, that's fineish in my view, but remember,
 this screws up and chance of cross-distro work (since a change to RPM
 local stuff, as example, would trigger a new upstream, and a no change
 rebuild in Debian to match)

 I really discourage this usage a lot. Native packages must be for
 packages local to Debian only.


This raises an interesting question on this package. He is using
github tags to identify releases. Currently, the tags page is
providing native-friendly tars for each version.

So how does he tag packaging-only updates - by tagging at the debian
rev level, then adjusting watch to ignore the dash? I don't see how
this provides less screwage to other distributions.

In any case, it sounds like the guidance on this ticket is that either
solution is fineish.

-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#706904: Chinese Checkers RFS review

[Dave Steele]

On Fri, Sep 20, 2013 at 1:16 PM, Michael Shuler mich...@pbandjelly.org wrote:
 On 09/20/2013 10:06 AM, Dave Steele wrote:
 In any case, it sounds like the guidance on this ticket is that either
 solution is fineish.

 Not to my knowledge.  A native package should only be one that is solely
 internal to Debian and is not usable as an upstream software for
 anything else.  There are quite a few readings on this topic.

 https://wiki.debian.org/DebianMentorsFaq#What.27s_wrong_with_upstream_shipping_a_debian.2F_directory.3F
 https://wiki.debian.org/UpstreamGuide
 http://joeyh.name/blog/entry/on_debian_directories_in_upstream_tarballs/
 https://www.google.com/search?q=%22upstream+debian+directory%22 (quite a
 few mailing list posts, bug reports, etc.)

Ok. thanks for the references. That's what I was looking for.

-- 
Le mieux est l'ennemi du bien - Voltaire


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

Bug#706904: Chinese Checkers RFS review

[Dave Steele]

Sorry about the long delay for a response to your submission. Here are
some comments, based on a visual review of your package. I am not a
DD. I cannot upload it.

I get no response from the server hosting your distribution files.
Perhaps it was your personal machine at college? This will need to be
fixed. The site mentors.debian.net is recommended.

The rest is based on the software in your git repository.

Since you are maintaining the software and the Debian packaging in the
same repository, it would be simpler if the source format were '3.0
(native)', not '3.0 (quilt)'.

python-support is deprecated. Your sponsor will likely require that
you remove the python-support'isms in your package, such as in control
and debian/pyversions (see
https://wiki.debian.org/Python/TransitionToDHPython2).

I don't see any other obvious problems. mentors.d.o will do additional
source tests when you put it there. Good luck with your upload.

-- 
Le mieux est l'ennemi du bien - Voltaire


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