Bug#1019696: GitHub watch file workaround

[David Steele]

Another workaround is to us the 'downloadurlmangle' option to map a
discovered 'tags' url to the expected 'releases' link.

>From the sirikali package:

version=4

opts=downloadurlmangle=s/archive\/refs\/tags\/(.*)\.tar\.gz/releases\/download\/$1\/@PACKAGE@-$1\.tar\.xz/,\
pgpsigurlmangle=s/$/.asc/,\
dversionmangle=s/\+dfsg1//,repacksuffix=+dfsg1 \
https://github.com/mhogomchungu/@PACKAGE@/tags \
/mhogomchungu/@PACKAGE@/archive/refs/tags/(.*)\.tar\.gz

Note that this watch file is looking for a '.xz' release file and
.xz.asc signature file.

The pre-existing pgpsigurlmangle continued to work after the change.

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE

Bug#1009618: Firmware "beige-goby*", for Radeon RX6500XT, missing from package

[David Steele]

Package: firmware-amd-graphics

Version: 20210818-1

Severity: Normal

thanks


The RX6500XT was released in January. It requires the "beige-goby" line 
of firmware files, which were added upstream September of last year [1].


A refresh of the package is needed.


[1]: 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=62fd279be67cd6e46aa33a342579f6356ea60634

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

[David Steele]

On 1/27/22 5:11 PM, Sean Whitton wrote:

Hello David,


...


Reviewing this bug, it is still not clear to me that a virtual package
is wanted as opposed to just making /usr/bin/todo a path managed by the
alternatives system.

I'm closing the bug, but if development that has taken place in the
todo.txt world since our previous dicsussion has changed matters such
that there are concrete usecases for the virtual packages that you can
explain, then please consider opening a new bug with that explanation.



We have a significant disconnect here. The todo.txt-base (and gtd) 
packages place more requirements on an alternative implementations other 
than just owning the name. The proposed virtual package would codify 
that contract. That represents a concrete set of use cases, laid out 
previously in this thread, in Dec 2020 (the stuff about autodiscovery of 
the datafile, and support of hooks - both allow todo.txt-gtd to properly 
interact).


The packages that interact with todo.txt are released:

https://tracker.debian.org/pkg/todo.txt-base
https://github.com/davesteele/todo.txt-base
https://packages.debian.org/sid/todo.txt-gtd

Also, aesthetically, I believe that Debian should have a package named 
todo.txt that installs todo.txt-cli by default.


OTOH, I undertook this process only because Ondrej required it before 
supporting integration of todo.txt-cli with todo.txt-base. I'd be happy 
to support the majority consensus between the three of us on how to proceed.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004260: pybuild-plugin-pyproject: Uninstallable

[David Steele]

Package: pybuild-plugin-pyproject
Version: 5.20220119
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: ste...@debian.org


Dear Maintainer,

The dh-python-pep517 meta package, required for poetry builds, and 
satisfied solely by this package, fails to install.


$ sudo apt-get install dh-python dh-python-pep517
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
dh-python is already the newest version (5.20220119).
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 dh-python-pep517 : Depends: dh-python (= 5.20211225) but 5.20220119 is 
to be installed

E: Unable to correct problems, you have held broken packages.

Corroborated by the current debcheck report - 
https://qa.debian.org/debcheck.php?dist=unstable=dh-python


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (700, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.14.0-2-amd64 (SMP w/6 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
LC_ALL set to en_US.UTF-8), LANGUAGE not set

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pybuild-plugin-pyproject depends on:
ii  dh-python  5.20220119
ii  python3-build  0.7.0-2
ii  python3-installer  0.4.0+dfsg1-2
ii  python3-tomli  1.2.2-2

pybuild-plugin-pyproject recommends no packages.

pybuild-plugin-pyproject suggests no packages.

-- no debconf information



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003496: ITP: python-keyboard -- Python module for interacting with the keyboard

[David Steele]

Package: wnpp
Severity: wishlist
Owner: 'David Steele' 
thanks

* Package name: python-keyboard
  Version : 0.13.5
  Upstream Author : Lucas Bopphre 
* URL : https://github.com/boppreh/keyboard
* License : Expat
  Programming Lang: Python
  Description : Python module for interacting with the keyboard

Take full control of your keyboard with this small Python library. Hook 
global events, register hotkeys, simulate key presses and much more.


This packages the PyPi "keyboard" package, creating the 
"python3-keyboard" deb.


This should be a useful library for Python-based programs that need to 
interact with the keyboard at a low level. That's what I need it for.


I will be the sole maintainer for the time being, and intend to transfer 
it to the appropriate Python team as it matures.


The GitHub project has >300 forks and >2k stars.

PyPi: https://pypi.org/project/keyboard/
Documentation: https://github.com/boppreh/keyboard#api



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001316: gnome-gmail: 2.8 to stable-updates

[David Steele]

On Tue, Dec 14, 2021 at 7:03 AM Martin-Éric Racine
 wrote:
>
> ma 13. jouluk. 2021 klo 19.18 David Steele (ste...@debian.org) kirjoitti:
> >
> > Control: severity -1 normal
> > Control: tags -1 moreinfo unreproducible
> > thanks
> >
> > On Wed, Dec 8, 2021 at 4:48 AM Martin-Éric Racine
> >  wrote:
> > >
...
> >
> > I spun up a new and created a new draft with gnome-gmail with no API
> > errors. Can you provide more information on how you came across this
> > issue?
> >
> > Note that the API requires a fully-qualified email address
> > ("gnome-gmail j...@example.com" vs. "gnome-gmail joe").
>
> I click on a mailto link. I get the dialog box asking which e-mail
> should be used. Web browser opens asking for authorization to access
> the account using Viagee. I agree. I select the account to use. I get
> an error 403 notification in gnome-shell.
>
> Martin-Éric

I am unable to reproduce the issue.

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE

Bug#988390: gnome-gmail: test_body2html fails with Python 3.9.5

[David Steele]

Note that the released v2.8 has code to address this issue, but it has
not been tested against Python 3.9.5.

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE

Bug#1001316: gnome-gmail: 2.8 to stable-updates

[David Steele]

Control: severity -1 normal
Control: tags -1 moreinfo unreproducible
thanks

On Wed, Dec 8, 2021 at 4:48 AM Martin-Éric Racine
 wrote:
>
> Package: gnome-gmail
> Version: 2.8-1
> Severity: important
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> The version of gnome-mail currently in Stable fails to connect to GMail with 
> an API error.
>

I spun up a new and created a new draft with gnome-gmail with no API
errors. Can you provide more information on how you came across this
issue?

Note that the API requires a fully-qualified email address
("gnome-gmail j...@example.com" vs. "gnome-gmail joe").

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE

Bug#995135: CryFS Conan build requirement

[David Steele]

Thanks, I'll check it out.

On Sun, Sep 26, 2021 at 7:27 PM Sebastian Messmer  wrote:
>
> This may help: https://github.com/cryfs/cryfs#using-local-dependencies
> It should, in theory, allow building by getting the dependencies from the 
> local system instead of from Conan.
>
> On September 26, 2021 2:39:10 PM David Steele  wrote:
>
>> Package: cryfs
>> severity: important
>> thanks
>>
>>
>> CryFS 0.11.0 is asking for conan to be present for the build. Conan is
>> not available in Debian, and provides a service that should not be
>> necessary in any case.
>>
>> Resolve the CryFS build for 0.11.0-1.
>
>


-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE

Bug#995135: CryFS Conan build requirement

[David Steele]

Package: cryfs
severity: important
thanks


CryFS 0.11.0 is asking for conan to be present for the build. Conan is 
not available in Debian, and provides a service that should not be 
necessary in any case.


Resolve the CryFS build for 0.11.0-1.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#995079: Can't upgrade to upstream - no pybuild poetry support

[David Steele]

Package: aiofiles
Severity: important
Block: -1 by 984824
thanks

Upstream has replaced setup.{py|cfg} with a pyproject.toml 
configuration, using poetry. This is not yet supported by dh-python - 
pybuild does not recognize poetry, and cannot complete the build.


pybuild does support a toml build via flit. Looking at plugin_flit.py, 
it looks very much like a full PEP517 implementation, except that it 
looks explicitly for "flit" in the toml "build-system".


Why can't pybuild work with the same API that pip uses?

The workaround appears to be adding a patch to create a setup.py file. 
That seems like more than should be necessary.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#994932: python3-aiofiles: doesn't support type hints

[David Steele]

On 9/24/21 1:24 PM, Jonas Smedegaard wrote:

Quoting David Steele (2021-09-24 18:17:41)

Packaging is currently stymied by an upstream transition to using
poetry for the build. That is not currently supported by pybuild.


It might be possible to avoid poetry with a patch - see e.g.
https://salsa.debian.org/cryptocoin-team/python-duniterpy/-/blob/debian/latest/debian/patches/2001_non-poetry.patch



That's a bit extreme. I'm looking into a patch for flit.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#994932: python3-aiofiles: doesn't support type hints

[David Steele]

control: severity -1 normal

There are a number of means to address this:

- set ignore_missing_imports for aiofiles in mypy.ini

 [mypy-aiofiles]
 ignore_missing_imports = true

- add [stubs] to the offended project, and reference in mypy.ini:

 [mypy]
 mypy_path: stubs

- add stubs to [typeshed]


Packaging is currently stymied by an upstream transition to using poetry 
for the build. That is not currently supported by pybuild.



[stubs]: https://mypy.readthedocs.io/en/stable/stubs.html
[typeshed]: https://github.com/python/typeshed



OpenPGP_signature
Description: OpenPGP digital signature

Bug#989275: unblock: todo.txt-base/2.4

[David Steele]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package todo.txt-base

The todo.txt-base package is missing a dependency for
ConfigArgParse/python3-configargparse. This causes failure of the
backuptodo command, and can add an error message to all topydo actions.

[ Reason ]
Add a missing dependency to the todo.txt-base package.

[ Impact ]
Failure of the todo.txt-base package functionality, and an error message
with every action taken in topydo.

[ Tests ]
An autopkgtest has been added which has verified the failure, and 
verifies the fix.


[ Risks ]
Minimal risk to the deb itself - it's just an added dependency.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
No

unblock todo.txt-base/2.4
diff -Nru todo.txt-base-2.3/debian/changelog todo.txt-base-2.4/debian/changelog
--- todo.txt-base-2.3/debian/changelog  2021-02-19 21:58:40.0 -0500
+++ todo.txt-base-2.4/debian/changelog  2021-05-29 16:56:23.0 -0400
@@ -1,3 +1,9 @@
+todo.txt-base (2.4) unstable; urgency=medium
+
+  * Add dependency to configargparse (Closes: #989156).
+
+ -- David Steele   Sat, 29 May 2021 16:56:23 -0400
+
 todo.txt-base (2.3) unstable; urgency=medium
 
   * Speed-up application launch.
diff -Nru todo.txt-base-2.3/debian/tests/control 
todo.txt-base-2.4/debian/tests/control
--- todo.txt-base-2.3/debian/tests/control  2021-02-19 21:58:40.0 
-0500
+++ todo.txt-base-2.4/debian/tests/control  2021-05-29 16:56:23.0 
-0400
@@ -1,3 +1,3 @@
 
-Tests: test-helper.py, test-todo.py
+Tests: test-helper.py, test-todo.py, test-backup.py
 Depends: @, topydo
diff -Nru todo.txt-base-2.3/debian/tests/test-backup.py 
todo.txt-base-2.4/debian/tests/test-backup.py
--- todo.txt-base-2.3/debian/tests/test-backup.py   1969-12-31 
19:00:00.0 -0500
+++ todo.txt-base-2.4/debian/tests/test-backup.py   2021-05-29 
16:56:23.0 -0400
@@ -0,0 +1,25 @@
+#!/bin/sh
+
+set -e
+
+if [ -z "$AUTOPKGTEST_ARTIFACTS" ] ; then
+  BASEDIR=/tmp
+else
+  BASEDIR=$AUTOPKGTEST_ARTIFACTS
+fi
+
+TESTDIR="$BASEDIR"/backuptest
+rm -rf "$TESTDIR"
+mkdir "$TESTDIR"
+
+TODO="$TESTDIR"/todo.txt
+echo "Foo" > "$TODO"
+
+BACKUPDIR="$TESTDIR/backup"
+mkdir "$BACKUPDIR"
+
+backuptodo -f "$TODO" -b "$BACKUPDIR"
+
+cat "$BACKUPDIR"/* | grep -q "Foo"
+
+echo "Test complete"
diff -Nru todo.txt-base-2.3/setup.py todo.txt-base-2.4/setup.py
--- todo.txt-base-2.3/setup.py  2021-02-19 21:58:40.0 -0500
+++ todo.txt-base-2.4/setup.py  2021-05-29 16:56:23.0 -0400
@@ -7,7 +7,7 @@
 
 setup(
 name="todo_txt_base",
-version="1.0",
+version="2.4",
 description="foo",
 url="https://example.com;,
 author="David Steele",
@@ -26,7 +26,7 @@
 ],
 },
 setup_requires=["pytest-runner"],
-install_requires=["relatorio"],
+install_requires=["relatorio", "ConfigArgParse"],
 tests_require=["pytest"],
 classifiers=[
 "Environment :: Console",


OpenPGP_signature
Description: OpenPGP digital signature

Bug#989156: todo.txt-base is missing a python module dependency

[David Steele]

retitle 989156 The todo.txt-base package is missing a dependency
severity 989156 serious
thanks

The setup.py script is missing a required dependency on ConfigArgParse.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#989156: topydo: Prints "module not found" errors on every nontrivial invokation

[David Steele]

reassign -1 todo.txt-base 2.3

thanks





OpenPGP_signature
Description: OpenPGP digital signature

Bug#988390: gnome-gmail: test_body2html fails with Python 3.9.5

[David Steele]

On Tue, May 11, 2021 at 1:57 PM Dmitry Shachnev > wrote:


   Source: gnome-gmail
   Version: 2.7-2
   Severity: important



Thank you for that complete, concise, and early report.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#981145: todo.txt-gtd: missing Breaks+Replaces: turnin-ng

[David Steele]

control: severity -1 normal


On Tue, Jan 26, 2021 at 5:51 PM Andreas Beckmann  wrote:

> Package: todo.txt-gtd
> Version: 0.5
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package fails to upgrade from
> 'stable'.
> It installed fine in 'stable', then the upgrade to 'sid' fails
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.
>

This text is not correct.

What section is this? That should be part of the report.


> See policy 7.6 at
>
> https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces


I'd accept this as an RC rationale if both packages existed in the same
distribution. You should tune your severity logic.

I'm willing to address it, but not as an RC bug.

joy.

Dave

Bug#979842: ITP: todo.txt-gtd -- add GTD project features to todo.txt

[David Steele]

Package: wnpp
Severity: wishlist
Owner: 'David Steele' 
thanks

* Package name: todo.txt-gtd
  Version : 0.4
  Upstream Author : 'David Steele' 
* URL : https://github.com/davesteele/todo.txt-gtd
* License : GPL-2+
  Description : GTD project features for todo.txt


This package extends packages providing the virtual package
[todo.txt] - adding features to enhance project-level documentation 
within the todo.txt tasking file.


Utilities include:

tdtcleanup - re-sort all tasks by project within a todo.txt file
project - edit just one or several projects in a todo.txt file

The utilities integrate with the current todo.txt provider, running
cleanup automatically and discovering the correct todo.txt path.

The project features are inspired by the Getting Things Done ([GTD])
methodology.

[todo.txt]: http://todotxt.org/
[GTD]: https://gettingthingsdone.com/




OpenPGP_signature
Description: OpenPGP digital signature

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

[David Steele]

On Sun, Jan 10, 2021 at 11:53 AM Novy, Ondrej 
wrote:

> On Sat, 2 Jan 2021 14:20:57 +0100 Bill Allombert 
> wrote:
> > What Sean meant is that, at this stage, this proposal needs to be
> > seconded by people impacted by this virtual package before being
> > accepted.
>
> as maintainer of todotxt-cli I second this.
>
> --
> Best regards
>  Ondřej Nový
>
>
I'm not aware of anyone else directly affected by this.

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

[David Steele]

control: tag -1 - moreinfo

On Mon, Dec 21, 2020 at 11:32 AM David Steele  wrote:

>
>
> On Mon, Dec 14, 2020 at 5:29 PM David Steele  wrote:
>
>> On Mon, Dec 14, 2020 at 3:42 PM Sean Whitton 
>> wrote:
>>
>>>
>>> Could you provide an actual patch against policy.git, please, for
>>> seconding?  See README.md in policy.git for more info.
>>>
>>> --
>>> Sean Whitton
>>>
>>
>>
>> https://salsa.debian.org/steele/policy/-/tree/bug976402-steele
>>
>> diff --git a/virtual-package-names-list.yaml
>> b/virtual-package-names-list.yaml
>> index 2a9857a..11afe1e 100644
>> --- a/virtual-package-names-list.yaml
>> +++ b/virtual-package-names-list.yaml
>> @@ -65,6 +65,9 @@ virtualPackages:
>>  - name: tclsh
>>description: a /usr/bin/tclsh
>>alternatives: [/usr/bin/tclsh]
>>  {+- name: todo.txt+}
>> {+   description: a command-line task management utility compatible with
>> todo.txt CLI (http://todotxt.org)+}
>> {+   alternatives: [/usr/bin/todo.txt]+}
>>  - name: wish
>>description: a /usr/bin/wish
>>alternatives: [/usr/bin/wish]
>>
>
> Second seconds request.
>
>
I'm not aware of any other inputs expected of me.

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

[David Steele]

On Mon, Dec 14, 2020 at 5:29 PM David Steele  wrote:

> On Mon, Dec 14, 2020 at 3:42 PM Sean Whitton 
> wrote:
>
>>
>> Could you provide an actual patch against policy.git, please, for
>> seconding?  See README.md in policy.git for more info.
>>
>> --
>> Sean Whitton
>>
>
>
> https://salsa.debian.org/steele/policy/-/tree/bug976402-steele
>
> diff --git a/virtual-package-names-list.yaml
> b/virtual-package-names-list.yaml
> index 2a9857a..11afe1e 100644
> --- a/virtual-package-names-list.yaml
> +++ b/virtual-package-names-list.yaml
> @@ -65,6 +65,9 @@ virtualPackages:
>  - name: tclsh
>description: a /usr/bin/tclsh
>alternatives: [/usr/bin/tclsh]
>  {+- name: todo.txt+}
> {+   description: a command-line task management utility compatible with
> todo.txt CLI (http://todotxt.org)+}
> {+   alternatives: [/usr/bin/todo.txt]+}
>  - name: wish
>description: a /usr/bin/wish
>alternatives: [/usr/bin/wish]
>

Second seconds request.

Bug#977644: RM: cloudprint -- ROM; Web service is deprecated

[David Steele]

Package: ftp.debian.org
Severity: normal
Control: affects -1 cloudprint
thanks

Please remove the source package "cloudprint" from sid. it supports the 
Google Cloud Print service, which is going offline at the end of 2020 [1].


Cloudprint sources the binary packages "cloudprint" and 
"cloudprint-service".


[1]: https://support.google.com/chrome/answer/1069693



OpenPGP_signature
Description: OpenPGP digital signature

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

[David Steele]

On Wed, Dec 16, 2020 at 2:34 PM David Steele  wrote:

>
>
> On Wed, Dec 16, 2020 at 2:14 PM Sean Whitton 
> wrote:
>
>>
>> Okay, and you expect every implementation of todo.txt to have
>> tdtcleanup?  I think we probably want to specify that as one of the (or
>> the only?)  requirements of the virtual package.
>>
>
> No, no.
>
> The gtd stuff is an optional add-on to todo.txt. The requirements on
> todo.txt to support these types of add-ons I listed earlier in the thread.
>

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

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

[David Steele]

On Wed, Dec 16, 2020 at 2:14 PM Sean Whitton 
wrote:

>
> Okay, and you expect every implementation of todo.txt to have
> tdtcleanup?  I think we probably want to specify that as one of the (or
> the only?)  requirements of the virtual package.
>

No, no.

The gtd stuff is an optional add-on to todo.txt. The requirements on
todo.txt to support these types of add-ons I listed earlier in the thread.

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

[David Steele]

On Mon, Dec 14, 2020 at 5:29 PM David Steele  wrote:

>
> On Mon, Dec 14, 2020 at 3:48 PM Sean Whitton 
> wrote:
>
>>
>>
>> Putting aside the use of the alternatives system, why is a virtual
>> package wanted?  When would it be useful to be able to declare a
>> dependency and have it satisfied by one of these implementations?
>>
>>
> As an example, a future rev of an integrated todo.txt-gtd[1] would depend
> on that virtual package.
>
> [1]:  https://github.com/davesteele/todo.txt-gtd
>
>
Somehow I don't have a copy or your reply.

Imagine that tdtcleanup is a pre/post hook in todo.txt-base. An
implementation of todo.txt is needed
to make use of it.

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

[David Steele]

control: tag -1 + patch



On Mon, Dec 14, 2020 at 3:42 PM Sean Whitton 
wrote:

>
> Could you provide an actual patch against policy.git, please, for
> seconding?  See README.md in policy.git for more info.
>
> --
> Sean Whitton
>


https://salsa.debian.org/steele/policy/-/tree/bug976402-steele

diff --git a/virtual-package-names-list.yaml
b/virtual-package-names-list.yaml
index 2a9857a..11afe1e 100644
--- a/virtual-package-names-list.yaml
+++ b/virtual-package-names-list.yaml
@@ -65,6 +65,9 @@ virtualPackages:
 - name: tclsh
   description: a /usr/bin/tclsh
   alternatives: [/usr/bin/tclsh]
 {+- name: todo.txt+}
{+   description: a command-line task management utility compatible with
todo.txt CLI (http://todotxt.org)+}
{+   alternatives: [/usr/bin/todo.txt]+}
 - name: wish
   description: a /usr/bin/wish
   alternatives: [/usr/bin/wish]

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

[David Steele]

On Mon, Dec 14, 2020 at 3:48 PM Sean Whitton 
wrote:

>
>
> Putting aside the use of the alternatives system, why is a virtual
> package wanted?  When would it be useful to be able to declare a
> dependency and have it satisfied by one of these implementations?
>
>
As an example, a future rev of an integrated todo.txt-gtd[1] would depend
on that virtual package.

[1]:  https://github.com/davesteele/todo.txt-gtd

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

[David Steele]

On Wed, Dec 9, 2020 at 2:44 PM David Steele  wrote:

>
>
> On Wed, Dec 9, 2020 at 3:21 AM Ansgar  wrote:
>
>>
>>
>> Should emacs provide a "todo" script to open ~/TODO (with say org-mode)?
>>
>
In regards to org mode. I'd add a third criteria - the expectation that the
underlying
file complies with the todo.txt format, though there is no requirement that
the provider
enforce that.

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

[David Steele]

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

>
> Given topydo just provides/conflicts with devtodo to provide the "todo"
> binary, this seems to violate Policy 10.1 "Binaries" unless they provide
> the same functionality.
>

Note that there is a Conflicts because the current devtodo
does not support alternatives.

As I've said elsewhere, I claim they do provide the same functionality, and
are
not in violation of 10.1. I say "topydo and devtodo provide the same
functionality - the ability to add, delete, modify, and display discrete
tasking information". That is not a false statement. The question is, does
it reflect the intent of the Policy?

>From where I stand, I would expect the Policy to use a different word to
indicate something along the lines of greater API compatibility. I have no
additional background information, though. Are you aware of any expansions
on this text, or of any precedents that could help with a consensus process?


> Different "todo" managers should be coinstallable as different users
> might want to use different ones.
>

The scheme I propose allows that.


> From the messages I thought todo.txt is a standard *text* format, but
> now you say it is a standard command-line interface?  What can they do
> if they depend on todo.txt?
>

Todo.txt is an ecosystem of tools built around a file format. There is a
canonical
CLI implementation. Topydo was built as an alternative to that. I'm sorry,
but I'm
not sure I understand your question beyond that.

For the most part, todo.txt is an end user tool. As for a theoretical
package
that depends on todo.txt, I believe that the core capabilities it requires
of
todo.txt are:
  - a mechanism for discovering the location of the active tasking file
  - an optional mechanism for adding pre and post processing hooks to
task modification activities

These capabilities are present in topydo, with the help of todo.txt-base.


> This seems to imply I can manage tasks from the command-line like "todo
> new-task eat breakfast"?  What interface to do so is provided?  Can I
> call "todo ", "todo", "todo new-task ", ...?
>

It depends. Topydo can run one-off commands (arg[1] is the command, with a
default of "ls" - the same as devtodo). It also has an interpreter mode and
a
GUI mode, which I do not believe are pertinent to the discussion.. Devtodo
has one-off commands as well, along with other end point to support specific
commands.


> Should emacs provide a "todo" script to open ~/TODO (with say org-mode)?
>

Again, not sure I understand. To be sure, emacs could be used to edit the
file,
if it knows where it is. Note that part of the virtual packages work-up
involves
automatic discovery of the file location across providers (see
todo.txt-base -
https://manpages.debian.org/unstable/todo.txt-base/index.html).

I'm adding a common "--info" argument to all todo.txt providers. An emacs
todo script could use that to identify a todo file to open. But, the core
 "todo{.txt}" command does not open the file for editing. See the vitodo
and edittodo commands in todo.txt-base for something similar to what
you are talking about.

All of this is in preparation for another layer of capabilities for todo.txt
providers which is not submitted yet.

If your theoretical emacs script met the criterion I listed above ("--info"
and hooks), I'd say it is worth discussing if that could be a
todo.txt provider.

It appears that a virtual package, or at least these virtual packages in
particular,
need a distinct spec separate from their implementations. Where would
you expect to find that documentation? Should that spec be part of this
list application process?


> If it is just to have "todo" open a user-chosen program they like to
> manage their todo lists with, why not just have the user add a "todo"
> alias to their shell or $HOME/bin?
>

This standardizes that process. Part of the challenge with these tool sets
is the variety of things you have to do to get them to a common working
level. My goal in packaging them is to simplify that as much as
possible


> >   - name: todo.txt
> > description: task management based on a standard free-form text
> format
>
> This description seem to vague to me: it doesn't even mention what file
> format.  Does a package providing todo.txt provide any specific user
> interface?  Emacs can edit todo.txt files: would it qualify (even
> without a "todo" executable in $PATH)?
>
> Ansgar
>

Ok ... does anyone have guidance on the line length limit in that yaml file?
Could you take a stab at a replacement?

BTW - https://salsa.debian.org/debian/todotxt-cli/-/merge_requests/2

I'll just say here that your stance feels unnecessarily aggressive from the
viewpoint of my inbox. I'm just trying to add value here.

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE

Bug#976783: Update watch to point to the git repo

[David Steele]

Source: aioprocessing
Severity: normal
thanks

The watch file is currently pointing to PyPi. Since upstream is using tags
in the git repository now, update this to point to the repository with the
next
upstream release.

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

[David Steele]

On Fri, Dec 4, 2020 at 6:39 PM Bill Allombert  wrote:

> On Fri, Dec 04, 2020 at 06:23:44PM -0500, David Steele wrote:
> > On Fri, Dec 4, 2020 at 6:21 PM David Steele  wrote:
> >
> > >
> > > On Fri, Dec 4, 2020 at 5:54 PM Bill Allombert 
> wrote:
> > >
> > >>
> > >> Are people using /usr/bin/todo in script or Makefile ?
> > >> Are they likely to still work with the alternatives ?
> > >>
> > >
> > > I'd say no. It is an interactive end-user command.
> > >
> > > This gives flexibility in what they are interacting with.
> > >
> >
> > This is no more of a stretch than "vi" implementing "editor".
>
> Note that even in this case there is a minimal common interface required
> so that programms can call '/usr/bin/editor file' to let the user edit
> 'file'.
>

With devtodo added to the providers, the core "todo" capability will always
give you a
list of current tasks. Devtodo uses different endpoints to go beyond that
capability.

https://www.mankier.com/1/devtodo

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

[David Steele]

On Fri, Dec 4, 2020 at 6:21 PM David Steele  wrote:

>
> On Fri, Dec 4, 2020 at 5:54 PM Bill Allombert  wrote:
>
>>
>> Are people using /usr/bin/todo in script or Makefile ?
>> Are they likely to still work with the alternatives ?
>>
>
> I'd say no. It is an interactive end-user command.
>
> This gives flexibility in what they are interacting with.
>

This is no more of a stretch than "vi" implementing "editor".

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE

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

[David Steele]

On Fri, Dec 4, 2020 at 5:54 PM Bill Allombert  wrote:

>
> Are people using /usr/bin/todo in script or Makefile ?
> Are they likely to still work with the alternatives ?
>

I'd say no. It is an interactive end-user command.

This gives flexibility in what they are interacting with.

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

[David Steele]

On Fri, Dec 4, 2020 at 4:42 PM Bill Allombert  wrote:

> On Fri, Dec 04, 2020 at 01:34:44PM -0500, David Steele wrote:
> > On Fri, Dec 4, 2020 at 1:15 PM Bill Allombert 
> wrote:
> >
> > > Do you envision to have packages depending on todo and then use the
> > > todo binary ?
> > >
> >
> > No. This is a means to allow topydo and todotxt-cli to use "todo" without
> > crowding devtodo. I believe this meets the definition of a virtual
> package
> > in the Policy.
>
> I am not use I understand. Do you plan for /usr/bin/todo to be managed by
> update-alternatives ? That would require all alternatives to share a common
> interface.
>

The guidance in the Policy is that alternatives "offer more-or-less the same
functionality". I believe this standard is met.

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

[David Steele]

On Fri, Dec 4, 2020 at 1:15 PM Bill Allombert  wrote:

> What about devtodo ?
>
> Reading your summary, it seems that the todo.txt virtual package
> is well specified, but the todo one is not.
>
> Do you envision to have packages depending on todo and then use the
> todo binary ?
>

No. This is a means to allow topydo and todotxt-cli to use "todo" without
crowding devtodo. I believe this meets the definition of a virtual package
in the Policy.

I do see the desirability for packages to be able to Depend on todo.txt,
with
an expectation of the command line format beneath (e.g. support for a
todo.txt schema).

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

[David Steele]

On Fri, Dec 4, 2020 at 12:30 PM Bill Allombert  wrote:

>
> Does all theses tools provide an compatible interface ?
> In other word, are there interoperable ?
>


Yes, topydo and todotxt-cli support common commands, which make them
interoperable for most uses. However, the command sets are not identical.

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

[David Steele]

Package: debian-policy
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org, charlesmel...@outlook.com,
  on...@debian.org
thanks


I'd like to propose adding the virtual packages "todo" and "todo.txt" to
the authoritative list of virtual package names. I'm submitting this per
Policy section 3.6 and the preamble to the [authoritative list].

[Todo.txt] describes an ecosystem of task management tools that revolve
around a standard for a freeform-text tasking file.

The reference cli has been packaged for some time, as "todotxt-cli". It
provides the executable "todo-txt".

An alternative cli provider, "topydo", has been recently added, adding
an executable by the same name.

I propose uniting this packages using the name "todo" - the common name
for the utility. Since not all todo list packages that may want to share
that name conform to the todo.txt standards, I also propose "todo.txt",
a strict subset of "todo", for packages which conform.

Note that topydo already implements these virtual packages, and that
there now exists a todo.txt-base packages that extends cli todo.txt
capabilities. There is also a todo.txt-cli package in Sid. This is
redundant, and has a pending RM request.

I did a screen scrape of p.d.o to find any possible collisions for these
names. There is a single package, devtodo (popcon 74, recently ITA'd),
that installs a "todo" executable. Currently, topydo Conflicts with this
package. I'd propose adding it to the "todo" virtual package.

This is a request for comment per the procedure in the list.

Please copy replies to this bug report.


[authoritative list]:
https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.yaml
[Todo.txt]: http://todotxt.org/



signature.asc
Description: OpenPGP digital signature

Bug#976220: RM: todo.txt-cli -- ROM; Duplicate package

[David Steele]

Package: ftp.debian.org
Severity: normal
Control: affects -1 todo.txt-cli
thanks

Please remove the package "todo.txt-cli" from "unstable". I am the
maintainer.

It turns out that the package is a duplicate of the existing "todotxt-cli".

I will work with the other maintainer to have todotxt-cli provide the
virtual todo.txt.



signature.asc
Description: OpenPGP digital signature

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

[David Steele]

On Sun, Nov 29, 2020 at 3:51 PM Paul Gevers  wrote:

> Source: topydo
> Version: 0.13-3
> Severity: serious
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: issue
>
> Dear David,
>
> I have no idea what's happening, but currently we have multiple workers
> (on different architectures) off-line on the ci.debian.net
> infrastructure. In the current (short) list of pending tests,
> todo.txt-base sticks out as being triggered (by topydo) some time ago
> and waiting on all architectures. armhf finished (tmpfail) while I was
> writing this message so I noticed it already ran multiple times but the
> test on armhf times out after 2:55 hours (previous tests were under 1
> minute) with an error in autopkgtest so is treated as tmpfail (and
> retried).
>
> Can you help us investigate what's going on? What is topydo doing?


Topydo is a package implementing a todo.txt client.

Todo.txt-base is a helper program adding features to todo.txt clients.

Both are new, and I am new to the alternatives environment. I started by
having todo.txt-base serve as the application installed as the todo/todo.txt
application. Packages using this model were accepted, but turned out
to be unworkable as I attempted to expand the ecosystem.

So there are new versions of topydo and todo.txt-base in sid which use
the todo.txt provider (topydo) as the home for the "todo" and "todo.txt"
applications. It calls todo.txt-base features as necessary for the added
features. Autopkgtests pass in sid.

All works well, until you test the new version of one package along with
the old version of the other. In one scenario there is a recursion, where
topydo ends up calling itself via the alternatives hook.

I didn't worry too much about this when I submitted the new packages,
because the issue was transient, and the common popcon is like 5. I
failed to consider that ci would evaluate the packages independently,
and would choke.

I'm reworking the packages so that they can manage this upgrade
without complaint. That process will take at least days. I'd be willing to
consider more drastic means to resolve this, either by overriding the
failures this one time, or by deleting the packages from the distribution
and starting fresh.

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE

Bug#972945: They're a set

[David Steele]

todo.txt-base (#973903), todo.txt-cli (#971288), and topydo (#972945)
are being submitted as a set.
>



signature.asc
Description: OpenPGP digital signature

Bug#971288: They're a set

[David Steele]

todo.txt-base (#973903), todo.txt-cli (#971288), and topydo (#972945)
are being submitted as a set.




signature.asc
Description: OpenPGP digital signature

Bug#972945: ITP: topydo -- a todo.txt utility written in Python

[David Steele]

Package: wnpp
Severity: wishlist
Owner: 'David Steele' 
thanks

* Package name    : topydo
  Version : 0.13
  Upstream Author : Bram Schoenmakers 
* URL : https://github.com/topydo/topydo
* License : GPL-3
  Description : A powerful todo list application using the todo.txt
format
<https://github.com/ginatrapani/todo.txt-cli/wiki/The-Todo.txt-Format>.


This is a Python implementation of the todo.txt simple textual task
management utility. It supports more advanced task format capabilities
relative to todo.txt, and features a graphical mode.

I intend for this package to provide the virtual package (and
executable) "todo", as the todo.txt-cli package will.

There is an existing package ("devtodo", popcon 74, maintained by the
Debian QA Group) which provides an executable "todo" on the default
search path. The listed homepage flags the software as unmaintained, and
the last non-QA upload was in 2016. There will be an explicit
"Conflicts" clause for that package.






signature.asc
Description: OpenPGP digital signature

Bug#971288: ITP: todo.txt-cli -- a CLI text-based task manager

[David Steele]

Package: wnpp
Severity: wishlist
Owner: 'David Steele' 
thanks

* Package name    : todo.txt-cli
  Version : 2.12.0
  Upstream Author : The todo.txt Team <http://todotxt.org/>
* URL : https://github.com/todotxt/todo.txt-cli
* License : GPL-3
  Description : A CLI, text-file-based tasking manager


This is the first of a suite of cross-platform tools that can manage
tasks based on a common, simple text file format.


I intend for this package to provide the virtual package (and
executable) "todo", facilitating alternatives support for other
todo.txt-compatible utilities (e.g. topydo).


There is an existing package ("devtodo", popcon 74, maintained by the
Debian QA Group) which provides an executable "todo" on the default
search path. The listed homepage flags the software as unmaintained, and
the last non-QA upload was in 2016. There will be an explicit
"Conflicts" clause for that package.




signature.asc
Description: OpenPGP digital signature

Bug#949118: RM: goopg -- ROM; RC-Buggy, Python 2 only, Dead upstream

[David Steele]

Package: ftp.debian.org
Severity: normal
Control: affects -1 goopg
thanks

Please remove "goopg" from "unstable".

The goopg package is currently non-functional, as documented in two RC
bugs. It requires Python 2, with no indication that a Python 3 version
will become available.

Goopg is a Chromium Native Messaging Host utility for GMail. It allows
one to verify and sign emails in GMail web page, using GnuPG. The Chrome
'goopg' Extension is also required.

Goopg has no reverse dependencies.

https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=no=pending-fixed=fixed=done=critical=grave=serious=no=goopg

Upstream
https://github.com/LeoIannacone/goopg/issues/34
https://github.com/LeoIannacone/goopg/issues/33

David Steele



signature.asc
Description: OpenPGP digital signature

Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required

[David Steele]

On Sun, Oct 6, 2019, 8:17 PM Sean Whitton  wrote:

> Hello,
>
> On Sat 05 Oct 2019 at 07:30PM -04, David Steele wrote:
>
> > I'm going to drop my objection, and assume that this is saying I don't
> need to
> > write init scripts for my special case.
>
> Okay -- perhaps you'd like to second Dmitry's patch, then, if you think
> it reflects project consensus?
>

I'm abstaining.

>

Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required

[David Steele]

On Sat, Oct 5, 2019 at 1:06 PM Sean Whitton  wrote:
>
> Hello David,
>
> On Sun 29 Sep 2019 at 10:35AM -04, David Steele wrote:
>
> > On Sat, Sep 28, 2019 at 1:05 PM Sean Whitton  
> > wrote:
> >>
> >> Hello,
> >>
> >> On Sat 28 Sep 2019 at 04:18PM +00, Dmitry Bogatov wrote:
> >>
> >> > Reasonable. Then let's drop part about Depends:
> >> >
> >> >   [ ... All packages with daemons must provide init.d scripts ...],
> >> >   unless software is only usable, by upstream's design, when
> >> >   pid1 is provided by some other init system.
> >>
> >> I think this would work.  What do you think, David?
> >
> > I don't know. It provides more clarity the original Policy question, but 
> > raises
> > a technical one I don't know the answer to. For my special case, is it
> > practical to use systemd (via D-Bus) to manage system daemon
> > start/stop when it is
> > not pid1? If yes, things may have gotten worse (I'm responsible for getting 
> > this
> > all to work correctly?).
>
> Unfortunately, there isn't quite enough context in your reply for me to
> understand exactly how you think this makes things worse for you.  Could
> you expand, please?

I'm going to drop my objection, and assume that this is saying I don't need to
write init scripts for my special case.

Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required

[David Steele]

On Sat, Sep 28, 2019 at 1:05 PM Sean Whitton  wrote:
>
> Hello,
>
> On Sat 28 Sep 2019 at 04:18PM +00, Dmitry Bogatov wrote:
>
> > Reasonable. Then let's drop part about Depends:
> >
> >   [ ... All packages with daemons must provide init.d scripts ...],
> >   unless software is only usable, by upstream's design, when
> >   pid1 is provided by some other init system.
>
> I think this would work.  What do you think, David?

I don't know. It provides more clarity the original Policy question, but raises
a technical one I don't know the answer to. For my special case, is it
practical to use systemd (via D-Bus) to manage system daemon
start/stop when it is
not pid1? If yes, things may have gotten worse (I'm responsible for getting this
all to work correctly?). In that case I would prefer a statement discouraging
systemd-specific features.

Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required

[David Steele]

On Wed, Sep 25, 2019 at 2:00 PM Ansgar  wrote:
>
> Well, the Policy Editors currently see no consensus; so to change it one
> would need to convince them, involve the tech-ctte or a GR.
>

The Policy needs to either explicitly discourage the use of
systemd-specific features, or recognize the sysv-init incompatibility of
packages that use them,

For my part, I have no interest in participating in the init wars. I just
want clear guidance on how to avoid an AUTORM-level bug report.
Right now the Policy is pretty much telling me to add an init script
with calls to systemctl. I'd like a different answer.

Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required

[David Steele]

On Wed, Sep 25, 2019 at 12:18 PM Ansgar  wrote:
>
> Hi,
>
> On Sun, 2019-09-22 at 16:13 -0400, David Steele wrote:
> > On Tue, Jul 23, 2019 at 2:10 PM Sean Whitton  
> > wrote:
> > > The Policy Editors have decided that dropping the requirement to ship
> > > init scripts is not something that can be decided by means of the Policy
> > > Changes Process, at least for the time being.
> > >
> > > In proposing and reviewing wording to resolve this bug, then, we should
> > > be careful not to weaken the requirement to ship init scripts.
> > > Otherwise, in resolving this bug we would be changing the requirements
> > > to ship init scripts by means of the Policy Changes Process.
> > >
> > > I'm suggesting this be kept in mind.  It need not result in a wordier
> > > change, and I certainly agree with you that we should assume good faith
> > > on the part of package maintainers.
> > >
> >
> > Candidate language attached. It adds "Also excepted are packages which 
> > require a
> > feature of an alternate init system which is not available in SysV-Style
> > init systems.". Thoughts?
>
> I don't think there is a way to get such changes through the policy
> process as Sean said (I tried to document what I see as current
> practice in #911165).  Practically the project seems to have already
> decided that this is fine, even for packages that don't require
> systemd:
>
> +---
> | There are 1033 non-overridden instances of lintian detecting a
> | service unit without an init.d script [7].
> +---[ https://lists.debian.org/debian-devel-announce/2019/09/msg1.html ]
>
> Ansgar
>

Regardless of the practicality, I'd like clarity on the policy.

After reading #911165, I'd say I prefer it to this proposal. But something
needs to be done about the current alternate init system support
language.

Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required

[David Steele]

On Wed, Sep 25, 2019 at 11:43 AM Dmitry Bogatov  wrote:
>
>
> [2019-09-22 16:13] David Steele 
> > Candidate language attached. It adds "Also excepted are packages which 
> > require a
> > feature of an alternate init system which is not available in SysV-Style
> > init systems.". Thoughts?
>
> Imho, it opens loophole. Sysvinit does not provide equivalent of
> sd_notify("SD_READY=1"), so any service that links to libsystemd for
> that exactly call can be argued as "requiring feature [...] which is not
> available [...]".
>
> As real life example I recall Avahi-related bug (can't find number right
> now, sorry). Two inter-dependent services, where second fails to start
> unless first is already ready to listen.
>
> I'd argue this is bug in design, but if we consider design is written in
> stone, this is a bug in init.d script that must be worked around
> somehow.
>
> With your change in place, avahi maintainers would be able to drop
> sysvinit support instead of fixing init.d script.
>
> Very strong -1.

I'm just looking to avoid the scenario where I add systemctl calls to
an init script, for a package that uses the systemd D-Bus interface.
Alternate language is solicited.

Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required

[David Steele]

On Tue, Jul 23, 2019 at 2:10 PM Sean Whitton  wrote:
>
> The Policy Editors have decided that dropping the requirement to ship
> init scripts is not something that can be decided by means of the Policy
> Changes Process, at least for the time being.
>
> In proposing and reviewing wording to resolve this bug, then, we should
> be careful not to weaken the requirement to ship init scripts.
> Otherwise, in resolving this bug we would be changing the requirements
> to ship init scripts by means of the Policy Changes Process.
>
> I'm suggesting this be kept in mind.  It need not result in a wordier
> change, and I certainly agree with you that we should assume good faith
> on the part of package maintainers.
>

Candidate language attached. It adds "Also excepted are packages which require a
feature of an alternate init system which is not available in SysV-Style
init systems.". Thoughts?

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE
From 5b99099d370b6304cadaedc99d5f8d8cd3063c71 Mon Sep 17 00:00:00 2001
From: David Steele 
Date: Sun, 22 Sep 2019 15:53:12 -0400
Subject: [PATCH] Clarify exception to sysv init script requirement

---
 policy/ch-opersys.rst | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
index 3e685cf..41f06fa 100644
--- a/policy/ch-opersys.rst
+++ b/policy/ch-opersys.rst
@@ -1006,7 +1006,9 @@ supported by all init implementations. An exception to this rule is
 scripts or jobs provided by the init implementation itself; such jobs
 may be required for an implementation-specific equivalent of the
 ``/etc/rcS.d/`` scripts and may not have a one-to-one correspondence
-with the init scripts.
+with the init scripts. Also excepted are packages which require a
+feature of an alternate init system which is not available in SysV-Style
+init systems.
 
 .. _s-upstart:
 
-- 
2.23.0

Bug#935731: comitup: port to python 3

[David Steele]

 Severity: normal
thanks

There is an erroneous "Suggests" control file listing for the Python 2
package. This has no effect on the usability of the package. The issue
doesn't rate autoremoval 18 months before the next stable release.

The fix is in git, and will be released in due course.

https://github.com/davesteele/comitup/commit/43459f9

Bug#934484: python-pytest-asyncio: "Cannot import name 'transfer_markers'" with current pytest

[David Steele]

Source: python-pytest-asyncio
Version: 0.9.0-1
Severity: serious
Tags: upstream

Dear Maintainer,

Since the recent upgrade of pytest, tests involving pytest-asyncio[1]
are failing with:

ImportError: cannot import name 'transfer_markers' from
'_pytest.python' (/usr/lib/python3/dist-packages/_pytest/python.py)

A quick search suggests the problem is a compatibility issue with
pytest-asyncio[2], which
has been resolved upstream[3].

The package needs to be upgraded to 0.10.0.

[1] 
https://ci.debian.net/data/autopkgtest/unstable/amd64/a/aiofiles/2707314/log.gz
[2] https://github.com/pytest-dev/pytest-asyncio/issues/104
[3] https://github.com/pytest-dev/pytest-asyncio/pull/105


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (700, 'unstable')
Architecture: amd64 (x86_64)

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

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE

Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required

[David Steele]

On Tue, Jul 23, 2019 at 11:15 AM Sean Whitton  wrote:
>
> I think that the wording for this change should reflect the above
> (unless I've misunderstood David), such that the new wording cannot be
> misinterpreted to mean that the sysvinit requirement does not apply to
> any package using any systemd component.

That would resolve my issue, though I am not sold on the value of the
additional specificity. I'll say no more than this - If I am operating in good
faith, the additional language is not necessary. If I am not, it won't stop
me.

Dave

Bug#932704: Fwd: Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required

[David Steele]

Re-sending to the bug thread.

-- Forwarded message -
From: David Steele 
Date: Mon, Jul 22, 2019 at 9:15 AM
Subject: Re: Bug#932704: debian-policy: Don't force sysvinit
compatibility if e.g. alternate init required
To: Sean Whitton 


On Mon, Jul 22, 2019 at 7:02 AM Sean Whitton  wrote:
>
> We would want to be careful to word this requirement such that it did
> not license maintainers to do things which block the work of those who
> don't like systemd.
>
> --
> Sean Whitton

The use of the systemd API blocks the work of those who don't like
systemd. Is that something that should that be addressed by Policy? I
don't think so.

Under the scenario where the systemd api is used by a package, the
current Policy leads down a logical path resulting in vestigial init
scripts with calls to systemctl. Is that a preferred result, relative
to the proposed exception?

I don't see how that ultimately meets anyone's goals for alternate init support.

--
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE

Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required

[David Steele]

Source: debian-policy
Version: 4.4.0.1
Severity: normal

In section 9.11 (The Operating System/Alternate init systems), it is
stated that "...any package integrating with other init systems must
also be backwards-compatible with sysvinit by providing a SysV-style
init script...". There is a single exception for the alternate init
system implementation itself.

There are other exception conditions that we may want to consider
here. For instance, if a package has an explicit dependency on a
particular "alternate" init system, to, say, access the systemd D-Bus
interface, there is likely little value in providing sysv init
scripts.

I suggest that something like the following line be added to the end
of the second paragraph in that section:

"Also, SysV-style init scripts may be omitted for packages which have
an explicit dependency on an alternate init system."

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE

Bug#926495: unblock: gnome-gmail/2.6-1

[David Steele]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package gnome-gmail

This version contains a minimal change that resolves the serious bug against
Buster - #926487.

A recent Gmail update is unable to properly process upload MIME-encoded
messages that do not include a message body.The latest gnome-gmail
resolves the
issue by taking more effort for messages to be well formed - to always
include
a message body, and to drop the "To:" header if otherwise blank.

Debdiff attached.


unblock gnome-gmail/2.6-1

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/6 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

diff -Nru gnome-gmail-2.5.6/debian/changelog gnome-gmail-2.6/debian/changelog
--- gnome-gmail-2.5.6/debian/changelog  2018-10-09 13:38:04.0 -0400
+++ gnome-gmail-2.6/debian/changelog2019-04-05 21:18:19.0 -0400
@@ -1,3 +1,9 @@
+gnome-gmail (2.6-1) unstable; urgency=medium
+
+  * Fix Gmail bug - bad message if no body (Closes: 926487).
+
+ -- David Steele   Fri, 05 Apr 2019 21:18:19 -0400
+
 gnome-gmail (2.5.6-1) unstable; urgency=medium
 
   * Fix bug in setup.py distutils.
diff -Nru gnome-gmail-2.5.6/gnome-gmail.appdata.xml.in 
gnome-gmail-2.6/gnome-gmail.appdata.xml.in
--- gnome-gmail-2.5.6/gnome-gmail.appdata.xml.in2018-10-09 
11:22:57.0 -0400
+++ gnome-gmail-2.6/gnome-gmail.appdata.xml.in  2019-04-05 21:22:56.0 
-0400
@@ -51,6 +51,7 @@
 
 
 
+
 
 
 
diff -Nru gnome-gmail-2.5.6/gnomegmail.py gnome-gmail-2.6/gnomegmail.py
--- gnome-gmail-2.5.6/gnomegmail.py 2018-10-09 11:22:57.0 -0400
+++ gnome-gmail-2.6/gnomegmail.py   2019-04-05 21:22:56.0 -0400
@@ -569,7 +569,8 @@
 
 qsdict = urllib.parse.parse_qs(query_string)
 
-qsdict['to'] = [address]
+if address:
+qsdict['to'] = [address]
 
 if 'attachment' in qsdict:
 qsdict['attach'] = qsdict['attachment']
@@ -587,6 +588,9 @@
 if 'su' in qsdict:
 outdict["subject"] = outdict["su"]
 
+if "body" not in qsdict:
+outdict["body"] = " "
+
 return(outdict)
 
 def simple_gmail_url(self):
diff -Nru gnome-gmail-2.5.6/setup.py gnome-gmail-2.6/setup.py
--- gnome-gmail-2.5.6/setup.py  2018-10-09 11:22:57.0 -0400
+++ gnome-gmail-2.6/setup.py2019-04-05 21:22:56.0 -0400
@@ -129,7 +129,7 @@
 
 setup(
 name='gnome-gmail',
-version='2.5.6',
+version='2.6',
 description='support for Gmail as the preferred GNOME email application',
 author='David Steele',
 author_email='dste...@gmail.com',
diff -Nru gnome-gmail-2.5.6/test/test_body.py gnome-gmail-2.6/test/test_body.py
--- gnome-gmail-2.5.6/test/test_body.py 2018-10-09 11:22:57.0 -0400
+++ gnome-gmail-2.6/test/test_body.py   2019-04-05 21:22:56.0 -0400
@@ -107,8 +107,8 @@
 
 
 @pytest.mark.parametrize("mailto, needs_api", (
-("mailto:joe;, False),
-("mailto:joe?subject=hi;, False),
+("mailto:joe;, True),
+("mailto:joe?subject=hi;, True),
 ("mailto:joe?body=%20;, True),
 ("mailto:joe?attach=file;, True),
 ("mailto:joe?attachment=file;, True),

Bug#926487: GNOME Gmail incompatibilty with Gmail

[David Steele]

Package: gnome-gmail
Version: 2.5.6-1
Severity: Serious

If GNOME Gmail is used to "Send To..." on a file via Nautilus, the
resulting uploaded message is not rendered properly - not showing the
Subject or attached file. It is not possible to send the message that
is opened.

This happens because the service does not properly handle mime message
with no body. The fix would be to always add a body to the message.

As a result of this issue, a core capability of the package is broken.
Setting to Serious.

--
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE

Bug#695188: Ping

[David Steele]

Today is the sixth anniversary of this bug. The submitted patch is one year
old.

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE

Bug#902383: reproducible-builds.org: test host-specific FTBFS failures on i386

[David Steele]

Package: jenkins.debian.org
Severity: Serious

For some jobs, it appears that profitbricks-build2-i386.debian.net
repeatedly returns FTBFS, while profitbricks-build6-i386.debian.net always
succeeds. This situation has been in place for 2 months.

There is a FTBFS failure currently reported for Sirikali in Buster and Sid.
The failure is persistent across re-runs.

I can't reproduce the failure locally. The formal build succeeded.

Looking closer, success and failure is tied to the worker hardware. build2
always fails, whether running the first run or the second. build6 always
passes, when used for the first run.

I'm not able to see what the difference may be.

Note that i386 has the highest current FTBFS count across architectures.


-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE

Bug#888289: ITP: dbussy -- A Python asyncio-compatible D-Bus access library

[David Steele]

Package: wnpp
Severity: wishlist

* Package name: dbussy
  Version : 1.0
  Upstream Author : Lawrence D'Oliveiro
* URL : https://github.com/ldo/dbussy
* License : GNU Lesser General Public License v2.1
  Programming Lang: Python
  Description : A Python asyncio-compatible D-Bus access library

Dbussy is a Python binding module for accessing D-Bus. It is
compatible with Python
asyncio, so that D-Bus activities may be combined with other
asyncio-compatible actions
in a single event loop. Note that this more or less duplicates the
functionality of
python3-dbus, while adding asyncio compatibility.

Two modules are included. The dbussy module provides lower-level
access routines, while
the ravel module implements class-level access.

The sole binary package will be named python3-dbussy.

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE

Bug#777516: I need python3-networkmanager (patch)

[David Steele]

severity -1 important
thanks


The comitup package has a dependency on python-networkmanager. It is
blocked from migrating to Python3 by the lack of a Py3 NetworkManager
module. It's my last Python2 package.

I've updated the patch from the original 2015 bug submission with a small fix.

Comitup uses NetworkManager to manage wifi connections. I've tested it with
the Python3 version generated with the patch, with no issues.

Set to 'important' due to the migration blocker.

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE
From e2763cd95a32eb24a2b9c63338a4684126814b2a Mon Sep 17 00:00:00 2001
From: David Steele <dste...@gmail.com>
Date: Mon, 11 Dec 2017 16:01:35 -0500
Subject: [PATCH] Create a python3 version of the package

---
 debian/control | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/debian/control b/debian/control
index cbfb6ee..a8a29b1 100644
--- a/debian/control
+++ b/debian/control
@@ -27,3 +27,17 @@ Description: Python interface to the NetworkManager D-Bus interface
  .
  See docs/index.rst for the documentation. An HTML version can be found on
  http://packages.python.org/python-networkmanager/
+
+Package: python3-networkmanager
+Architecture: all
+Depends: network-manager (>= 0.9.0~),
+ ${misc:Depends},
+ ${python3:Depends}
+Description: Python interface to the NetworkManager D-Bus interface
+ python-networkmanager wraps NetworkManager's D-Bus interface so you can be
+ less verbose when talking to NetworkManager from python. All interfaces have
+ been wrapped in classes, properties are exposed as python properties and
+ function calls are forwarded to the correct interface.
+ .
+ See docs/index.rst for the documentation. An HTML version can be found on
+ http://packages.python.org/python-networkmanager/
-- 
2.14.1

Bug#875433: The packages "list of files" data has not been updated for at least TWO YEARS

[David Steele]

severity -1 important

On the packages.d.o binary packages pages, a "list of files" link is offered 
for every supported
architecture. For (at least many) packages that have been introduced in the 
last two years, that link points to a page that says "No such package in this 
suite on this architecture".

https://packages.debian.org/sid/net/comitup
https://packages.debian.org/sid/all/comitup/filelist

https://packages.debian.org/sid/gocryptfs
https://packages.debian.org/sid/arm64/gocryptfs/filelist

https://packages.debian.org/sid/golang-github-rfjakob-eme-dev
https://packages.debian.org/sid/all/golang-github-rfjakob-eme-dev/filelist

For older packages, the information is way stale. The gnome-gmail package 
introduced the file gnomegmail.py in 2015, but it is not represented in the 
displayed list of files.

https://packages.debian.org/sid/gnome/gnome-gmail
https://packages.debian.org/sid/all/gnome-gmail/filelist

This feature should be fixed or removed in the short term.

Bumping severity because two years.

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE


signature.asc
Description: GooPG digital signature

Bug#883131: DDPO: Popcon data not updating

[David Steele]

Package: qa.debian.org
Severity: normal
User: qa.debian@packages.debian.org
Usertags: ddpo

As a reminder...

It appears that the cron job at https://qa.debian.org/data/cronjobs/popcon has 
not run successfully since October.
This script downloads popcon data from popcon.d.o to 
https://qa.debian.org/data/popcon/, and updates popcon.db
in that directory. The db file is used to populate the popcon column in DDPO

As another symptom, the popcon.php pages on qa.d.o show up-to-date charts, but 
the tables on the same page use
months old data. See, for instance, 
https://qa.debian.org/popcon.php?package=aiofiles.



signature.asc
Description: GooPG digital signature

Bug#873916: ITP: shoogle -- Access the Google API from the command line

[David Steele]

retitle 873916 ITP: shoogle -- Access the Google API from the command line
owner 873916 !
thanks

Packaging at https://github.com/davesteele/shoogle/tree/debian/debian

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE


signature.asc
Description: GooPG digital signature

Bug#819589: RFP: python3-aioxmpp -- pure-python XMPP library using the asyncio standard library module

[David Steele]

I've taken a look at this, For others, note:
  - Packaging this would require also packaging aiosasl and aioopenssl
  - The source needs some copyright work
  - slixmpp, already packaged, appears to provide similar functionality

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE

Bug#880440: ITP: python3-aioprocessing -- Multiprocessing support for Python asyncio

[David Steele]

Package: wnpp
Severity: wishlist
Owner: David Steele <dste...@gmail.com>

* Package name: python3-aioprocessing
  Version : 1.0.0
  Upstream Author : Dan O'Reilly <oreil...@gmail.com>
* URL : https://pypi.python.org/pypi/aioprocessing/1.0.0
* License : BSD-2
  Programming Lang: Python
  Description : Asynchronous multiprocessing support for Python asyncio

This module includes support for the multiprocessing module to work
with the Python asyncio module.

Packaging is at https://github.com/davesteele/aioprocessing/tree/debian/debian

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE

Bug#880030: ITP: python3-aiofiles -- Asynchronous file I/O support for Python asyncio

[David Steele]

Package: wnpp
Severity: wishlist
Owner: David Steele <dste...@gmail.com>

* Package name: python3-aiofiles
  Version : 0.3.2
  Upstream Author : Tin Tvrtković <tinches...@gmail.com>
* URL : https://github.com/Tinche/aiofiles
* License : Apache 2.0
  Programming Lang: Python
  Description : Asynchronous file I/O support for Python asyncio

This module includes support for asynchronous file
 operations using the Python asyncio module.

Packaging is at https://github.com/davesteele/aiofiles/tree/debian/debian


-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE


signature.asc
Description: GooPG digital signature

Bug#857042: thonny packaging status

[David Steele]

On Sat, Oct 21, 2017 at 2:53 AM, Aivar Annamaa 
wrote:

> Dominik George from Debian Edu team agreed to sponsor my package once I
> get accepted to Edu team and fix the package problems.
>
> Should I update the RFS somehow to reflect this?
>
>
>
We just did :-)

Good luck. I'm looking forward to using it.

Bug#857042: thonny packaging status

[David Steele]

On Mon, Oct 16, 2017 at 7:14 AM, Aivar Annamaa 
wrote:

> I think I managed to complete the package.
>
> Here is the debian folder: https://bitbucket.org/plas/
> thonny-debian/src/master/debian/?at=master
>
> Here are the resulting files: https://bitbucket.org/plas/
> thonny-debian/downloads/
>
> I uploaded the package to https://mentors.debian.net. The output from
> dput indicated everything went fine, but I can't see the package under "My
> packages". Does it take some time?
>

I can see the package on mentors. It looks pretty good.

The watch file has some problems. Take a look at a recent uscan man page
for an example of a pypi watch file, and run 'uscan --force-download
--verbose' to test.

I'm a big fan of watch files and of get-orig-source (
https://wiki.debian.org/onlyjob/get-orig-source). The PGP signature
checking capability of uscan is also a good thing, if you are feeling
adventurous.

You still have a lintian issue to deal with Run 'lintian' in the project
directory after a build to review. Debian standards changes are summarized
in https://www.debian.org/doc/packaging-manuals/upgrading-checklist.txt.

I see that the tip of master builds much more cleanly - it needs a commit
tag to match in the changelog.

I built from your repository. There are generally two models for
maintaining packaging git repositories. One way has a branch containing
only a debian directory. The other includes the upstream data, both in a
pristine state, and also included with the debian directory for building.
You've gone the source included route, but the files don't match the tar
downloaded from pypi. Make sure you can build without error.  (Yes, I know
the tar probably doesn't match the upstream repository, but the watch file
defines the tar as the canonical source. Maintain the differences in the
debian branch, and review them).

Remember that, at some point, the UNRELEASED reference in the changelog
needs to change to unstable.

I haven't installed the package yet.

--
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE


signature.asc
Description: GooPG digital signature

Bug#869256: Upgrade from python-gobject-2

[David Steele]

Package: comitup
Version: 0.7
Severity: minor

Comitup uses python-gobject-2, which is marked as 'old':

https://qa.debian.org/debcheck.php?dist=unstable=comitup

Need to port to python-gi

https://packages.debian.org/sid/python-gobject

Bug#857042: thonny packaging status

[David Steele]

I learned about thonny from the Raspberry Pi announcement. I see that
development is quite active. Where do you stand on the packaging?

--
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE


signature.asc
Description: GooPG digital signature

Bug#788045: reportbug: patch - use the default desktop mua

[David Steele]

On Wed, Jun 28, 2017 at 10:19 PM, Paul Wise <p...@debian.org> wrote:
> On Wed, 2017-06-28 at 10:41 -0400, David Steele wrote:
>
> > The attached patch adds a "desktop-default" option
>
> I might be wrong but I think individual options for choosing an MUA are
> deprecated and you should instead use a parameter to the --mua option.

I followed the convention for the other options in the code, supported by the
current documentation. The --mua option feels pretty useless to me
(532150, 865792).

> I also think you should call it xdg-email not desktop-default for
> precision about what it does, there is no /usr/bin/desktop-default

reportbug has a mode called NOVICE. This felt like a better description -
xdg comes later. But, I could be persuaded.
 
> > via xdg-open and a "mailto" URI.
>
> I'd strongly suggest using xdg-email *not* xdg-open, the latter might
> not work for mailto but the former is more likely to work.

I've worked quite a bit with xdg-open with the mailto scheme, and know
how it will interpret the URI. I'm not so sure with xdg-email, and had
problems controlling text quoting for the individual arguments. I suspect
that the two are equivalent for mailto's, but this way I didn't have to check.

> In addition, xdg-email allows you to specify attachments, which IIRC
> reportbug can sometimes use. xdg-open cannot add attachments.

Actually, it can. There is broad support for an attachment keyword in
the mailto URI scheme, though at one point there was disagreement
on the name of the tag. That may or may not be fixed (Evolution was
the holdout, IIRC).

In any case, there's a 4+-year old comment in the reportbug source
stating that attachments are not (yet) supported for mua's. If that
changes, I would be willing to revisit it.

> > Note that this drops headers that are not
>
> I don't think that is acceptable since reportbug sets a number of other
> headers. mailto URLs can contain arbitrary headers anyway.

I just reread rfc2368. You shouldn't expect a mailto interface to respect
very many headers. Mine doesn't (gmail api, via gnome-gmail). I didn't
encounter any issues beyond X-Debbugs-CC, and I would worry about
side effects from feeding them all to all mailers. This way I am controlling
the issue at the source.

> > "X-Debbugs-Cc" would need to be moved to a pseudo-header.
>
> I think this should happen anyway, so that people receiving XCCs
> understand why they are getting a bug they did not expect.

I also think this is an issue that's independent of mailto support.

> PS: I think use of ui.system breaks this under the GTK+ UI.
>
> PPS: I note that the emacsclient MUA and viewing in a pager use it too.
>
> PPPS: *never* run external commands from python via os.system or
> equivalent (such as ui.system) unless you are using a hard-coded string
> for the command. Using dynamically calculated or user-provided data is
> likely to create issues when there are shell meta-characters present.

I'm trying not to break new ground beyond supporting the standard mailer.
The Mua class uses ui.system(). Note that all externally collected mailto
data is url-quoted before the call.

> S: if you are interested in expanding the MUA support of reportbug,
> I would suggest looking at reportbug-ng, which even supports webmail
> like gmail.com (in commented-out code that actually works).

You really should take a look at gnome-gmail.

> Personally,
> I think the MUA handling code of both reportbug and reportbug-ng needs
> to be factored out into a Python library that both tools can use.

Fair enough. Let's see how much friction there is in the process.

My immediate goal is modest - to make reportbug useful to me, and
make moot the question "Where did the message file go?".

Thanks for the prompt feedback.

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE


signature.asc
Description: GooPG digital signature

Bug#788045: reportbug: patch - use the default desktop mua

[David Steele]

Control: tags -1 + patch

Paul Wise wrote:

> When it is available, please use the xdg-email program to send bugs via
> the users preferred MUA. It supports setting To, CC, BCC, Subject, body
> text and adding attachments.

Good idea.

The attached patch adds a "desktop-default" option, which causes reportbug
to send using the default desktop mailer, via xdg-open and a "mailto" URI.

--
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE


0001-Add-a-desktop-default-mua-option.patch
Description: Binary data


signature.asc
Description: GooPG digital signature

Bug#840750: Availability for picocoin RFS

[David Steele]

First, I want to apologize for the latest delay in responding. I remember being 
on the waiting side of things, and am sorry I'm contributing to the problem.

Second, I want to let you know that I won't be able to get to this, for at 
least till the end of summer. If someone else picks up sponsorship, that would 
be great. Otherwise, I'll check in after August.

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE


signature.asc
Description: GooPG digital signature

Bug#532150: [Reportbug-maint] Bug#532150: reportbug: [regression] no longer supports custom mua commands

[David Steele]

chaica wrote:

> Allowing custom muas outside supported muas exclude the possibility to give
> feedback to the user about what happened *after* reportbug gave the bug
> report to the mua. How can reportbug know if your script/custom software is
> available on your system and efficiently working ? What error code should
> reportbug wait to inform the user the bug report failed to be sent ? We
> chose to only support some muas in order to provide a better efficienty
> using reportbug. And we did it because some users reported bugs *because*
> reportbug was not alerting them when the mua failed and finally was not
> doing its job.
> I think the main idea is to guarantee the user that the bug report will
> efficiently be sent through every options offered by reportbug.


My apologies - I submitted the patch in 865792 before spotting this entry.

The patch supports the mua_exists() call, and has error handling/detection
in the custom case that is equivalent to the supported muas.

Personally, I'd expect a decent mua (vs. an mta) to show the user what it is
going to send/has sent. In any case, you could make it clear that custom mua's
are the buyer's responsibility.

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE


signature.asc
Description: GooPG digital signature

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

[David Steele]

Package: reportbug
Version: 7.1.7
Severity: normal
Tags: patch

Dear Maintainer,

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.

This does not introduce any test failures.


-- Package-specific info:
** Environment settings:
DEBEMAIL="dste...@gmail.com"
DEBFULLNAME="David Steele"
INTERFACE="gtk2"

** /home/daves/.reportbugrc:
reportbug_version "6.6.6"
mode standard
ui gtk2
email "ste...@debian.org"
smtphost "smtp.gmail.com"

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages reportbug depends on:
ii  apt1.4.6
ii  python33.5.3-1
ii  python3-reportbug  7.1.7

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
ii  debsums2.2.2
pn  dlocate
pn  emacs24-bin-common | emacs25-bin-common
ii  exim4  4.89-3
ii  exim4-daemon-light [mail-transport-agent]  4.89-3
ii  file   1:5.30-1
ii  gir1.2-gtk-3.0 3.22.16-1
ii  gir1.2-vte-2.910.46.1-1
ii  gnupg  2.1.18-8
ii  python3-gi 3.22.0-2
ii  python3-gi-cairo   3.22.0-2
pn  python3-gtkspellcheck  
ii  python3-urwid  1.3.1-2+b1
ii  xdg-utils  1.1.1-1

Versions of packages python3-reportbug depends on:
ii  apt1.4.6
ii  file   1:5.30-1
ii  python33.5.3-1
ii  python3-debian 0.1.30
ii  python3-debianbts  2.6.1
ii  python3-requests   2.12.4-1

python3-reportbug suggests no packages.

-- Configuration Files:
/etc/reportbug.conf changed [not included]

-- no debconf information
From df360fb1796706f1f96f0af4113419bf50d9010a Mon Sep 17 00:00:00 2001
From: David Steele <ste...@debian.org>
Date: Wed, 21 Jun 2017 12:14:35 -0500
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   | 107 ---
 test/test_utils.py   |  29 --
 6 files changed, 93 insertions(+), 87 deletions(-)

diff --git a/bin/reportbug b/bin/reportbug
index 7eda598..71282c5 100755
--- a/bin/reportbug
+++ b/bin/reportbug
@@ -793,7 +793,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
@@ -861,6 +862,8 @@ def main():
   dest='bugnumber', help='specify a bug number to loo

Bug#864007: "Page Size" panic on many archs

[David Steele]

Package: golang-github-hanwen-go-fuse-dev
Version: 0.0~git20161210.0.6c2b7d8-2
Severity: important
block 849662 by -1
thanks

The function init(), in misc.go, checks the return of syscall.Getpagesize()
against 4096, and panics if they do not match. This breaks on the following
supported architectures.

arm64
ppc64el

See #849662 for an example.

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE

Bug#863671: Commit fix?

[David Steele]

Note that the CVE references 1ebc60b, which removes a "/bin/sh"
call, addressing the vulnerability.

Your patch incorporates the relevant code added by that commit
(though it replaces a system() call, instead).


https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-9059

https://github.com/npat-efault/picocom/commit/1ebc60b

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE

Bug#862876: Obsolete watch file for libcrypto++

[David Steele]

Source: libcrypto++
Version: 5.6.4-6
Tags: patch
Severity: normal
thanks

The watch file for libcrypto++ points to SourceForge. Per the upstream homepage
(https://www.cryptopp.com/), this source is deprecated.

Perhaps because of this problem, version 5.6.5, released last October, is not
represented on the QA page.

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.

A suggested patch is attached.

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

Shirky
From 7280dc14747d24e683518a6a96eb13961f275090 Mon Sep 17 00:00:00 2001
From: David Steele <ste...@debian.org>
Date: Wed, 17 May 2017 21:29:30 -0400
Subject: [PATCH] watch: update from SourceForge to the home page

---
 debian/watch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/watch b/debian/watch
index d3d0321..403bbaa 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,3 +1,3 @@
 version=3 
 opts=uversionmangle=s/^(\d)(\d)(\d)$/$1.$2.$3/;s/^(\d)(\d)$/$1.$2/ \
-http://sf.net/cryptopp/cryptopp(\d+)\.zip
+https://www.cryptopp.com/downloads.html cryptopp(\d+)\.zip
-- 
2.11.0



signature.asc
Description: GooPG digital signature

Bug#855920: Can't reproduce either

[David Steele]

On Tue, Apr 11, 2017 at 12:31 PM, Ivo De Decker <iv...@debian.org> wrote:
> Hi,
>
> On Mon, Mar 27, 2017 at 10:32:20PM -0400, David Steele wrote:
>> I've built 0.9.6-1 amd64 sid and stretch, desktop and pdebuild, with
>> and without networking, and have not seen the failure. Stretch build
>> attached.
>
> Same here. I tried in a sid pbuilder chroot on a jessie machine, and the build
> succeeds.
>

Note this failure in the original fail log:

==
FAIL: testGetTime (fail2ban.tests.datedetectortestcase.DateDetectorTest)
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/pythonX.Y_3.5/build/fail2ban/tests/datedetectortestcase.py",
line 75, in testGetTime
self.assertEqual(datelog, dateUnix)
AssertionError: 1106517599.0 != 1106513999.0



They differ by 3600 seconds.

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE

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

[David Steele]

On Sun, Apr 9, 2017 at 9:13 PM, Joel DeJesus
 wrote:
> I have uploaded a new source package to fix some of the smaller issues
> with the control files, copyrights, etc.  However, I seem to be stuck at
> what to do with the library name, libccoin.
>
> I was planning on just have libccoin as the package name and just
> managing the soname with the proper Makefile.am files.  However,
> according to the "package-name-doesnt-match-sonames", I will need to
> rename the package to libccoin0.
>
> Is it better for me to just change the name to libccoin0?

Take a look at what the policy says.

https://www.debian.org/doc/debian-policy/ch-sharedlibs.html

>
> As for the dependencies, I will have to learn how to use pbuilder under
> git-buildpackage and try to submit another source package.

git-buildpackage is useful, but complicated first time out, and not
necessary for this.

https://pbuilder.alioth.debian.org/

If you are using gbp, put the config file in the debian folder.See
"builder=git-pbuilder".

Bug#858458: ITP: lbry -- A fully decentralized network for distributing data

[David Steele]

Package: wnpp
Severity: wishlist

* Package name: lbry
  Upstream Author : LBRY Inc
* URL : https://github.com/lbryio/lbry
* License : Expat
  Programming Lang: Python
  Description :  LBRY is a blockchain/swarm-based content sharing
and publishing platform that is decentralized and owned by its users.
It is in the news for preserving the ADA-deficient lecture archive being
taken down by UC Berkeley.

Bug#843126: Man pages

[David Steele]

As I've been playing with freight, I am noticing that the man pages
are in need of updating.

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE

Bug#853916: encfs '-S' vulnerability

[David Steele]

Package: encfs
Version: 1.9.1-3
Severity: serious
thanks


Recently, a change in Encfs was found to have broken cryptkeeper, causing it
to use the password 'p' for all operations, regardless of user input 
(#852751)[3].
The bug was closed by removing cryptkeeper from Debian.

The issue, however, remains. Sirikali, which manages multiple userspace
filesystems including Encfs, suffers from the same failure (#853874).
An upstream Encfs representative has indicated that the problem will be fixed
there [1], though no change has been pushed to date [2].

The overall issue should be RC critical for Stretch. I've marked this as 
'serious',
indicating that the problem will be fixed in Encfs for the Stretch release. If 
this
is not the case, close or demote, and I'll elevate in Sirikali.

[1] https://github.com/tomm/cryptkeeper/issues/23#issuecomment-276304206
[2] https://github.com/vgough/encfs
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852751

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE


signature.asc
Description: GooPG digital signature

Bug#843126: RFS: freight/0.3.9-2 [ITP] -- easy-to-understand shell scripts to handle APT repositories

[David Steele]

First off, thanks for doing the work of preparing this package for Debian. I'd 
also like to apologize
for the long wait you've endured, and the lost opportunity for Stretch 
inclusion.

Your packaging is in pretty good shape. I have some comments based on a review, 
detailing the
changes I would like to see before uploading.

First, a couple of things which are not your fault - debhelper/compat should be 
10 now, and there
is a newer upstream version released. When you add the new version, set the 
older changelog
entry to UNRELEASED.

The source tar you uploaded does not match upstream. I did not investigate why.

One thing I very much like to see is a get-orig-source target in rules. It is a 
good way to ensure that
the correct source tar is always included, and is close to plug-and-chug with 
the instructions on the
wiki page:

https://wiki.debian.org/onlyjob/get-orig-source

I'd also like to see an /etc/freight.conf installed, defining the defaults and 
providing an obvious location
to modify them.

As an aside, when I first looked at freight, I was intrigued by the prospect of 
managing repos with
no config file (-c /dev/null). Params are defined as shell variables, and there 
are only about three that I
care about. Life would be simpler if I could just define the variables and call 
the freight commands
from the same script. Alas, it is not coded to support that right now.

The package needs to work properly out of the box. That means ensuring that the 
default VARLIB and
VARCACHE default directories are established and created as a part of the 
install. I'm not going to put
my secret key under root - there needs to be a standard way to run as a normal 
user, perhaps
by establishing a group with the necessary default permissions, and a clear 
message from freight-add
telling the user how to get the proper access. So, create a freight user and 
group, make the group
able to work in the default directories, and prompt the user with the proper 
usermod command if write
access fails on those directories. Note that users are established using 
installation scripts,
and that any user created in an installation script is never deleted by same.

Both your deb and the deb from the upstream homepage failed for me in chmod 
pubring.gpg. The
work directory did not exist. I commented out all actions on pubring to 
continue.

I don't recall if freight-cache announces the repo directory on completion. It 
should.

The FTP Masters are sticklers for the copyright file. Yours captures everything 
from the source, but
also includes "The Freight Team", with no indication of how it is claimed 
upstream. I don't know if that
will cause problems or not.

Minor stuff

This is minor (i.e. not required by me), but the lib scripts should be in 
/usr/share/freight.


http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA


Bash completion installation?


I promise a shorter wait next time.

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE


signature.asc
Description: GooPG digital signature

Bug#853874: Encfs '-S' vulnerability

[David Steele]

Package: sirikali
Version: 1.2.3-1
Severity: Important
thanks

Recently, a change in Encfs was found to have broken cryptkeeper, causing it
to use the password 'p' for all operations, regardless of user intput (#852751).
The bug was closed by removing cryptkeeper from Debian.

The issue, however, remains. Sirikali suffers from the same failure. Upstream
encfs has indicated that the problem will be fixed there [1]. If not,
disable encfs
in sirikali.


diff --git a/src/sirikali.cpp b/src/sirikali.cpp
index 388267e..44d32e4 100644
--- a/src/sirikali.cpp
+++ b/src/sirikali.cpp
@@ -148,6 +148,11 @@ void sirikali::setUpApp( const QString& volume )
  }else{
  ac->setText( tr( "%1 Is Not Installed" ).arg( exe ) ) ;
  }
+
+ }
+ else if( exe == "Encfs" ) {
+ ac->setEnabled( false ) ;
+ ac->setText( tr( "%1 Is Disabled" ).arg( exe ) ) ;
  }
  } ;

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

[David Steele]

Expanding on the previous feedback (from a quick review):

You should clear all of the non-green issues on the [mentors page]. Note that 
debuild includes a lintian run.

changelog:
  - The NMU complaint is there because your names in control and changelog 
don't match.

control
  - You should also populate the Vcs fields in control. This references your 
Debian repository.

rules
  - There are many who would require you to clear out the comments in that file.

copyright
  - The ftp masters pay particularly close attention to the copyright file of 
packages in the NEW queue. Yours has an error in it (missing License line in 
the claim paragraph). It also is missing references to third party Copyright 
claims in the source tree, and to your files in the debian directory. Do a 
careful search of copyright claims, and make sure all are documented.
  - "The MIT License (MIT)" (exact text) is not on the 'official' list. See the 
[license list], referenced from the [copyright file spec]. The one you are 
looking for is probably 'Expat', though you should verify the text carefully.

[mentors page]: https://mentors.debian.net/package/picocoin
[license list]: https://spdx.org/licenses/
[copyright files spec]: 
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/


You can upload again to mentors when complete. Update the revision, and mark 
previous revisions as "UNRELEASED" (that may just be my personal preference).

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


signature.asc
Description: GooPG digital signature

Bug#840235: Lintian dir-or-file-in-etc-opt should not be 'fatal'

[David Steele]

Package: ftp.debian.org
thanks

Debian Policy does not support blanket rejects based on the Lintian
dir-or-file-in-etc-opt tag.
The tag should be removed from the "fatal" list at
https://ftp-master.debian.org/static/lintian.tags.

Rationale

The Debian Policy has little to say about opt, except that the FHS
must be followed. There
is a stated ban concerning /usr/local, but nothing specific about opt.

The FHS explicitly states that distributions MAY place files under
/opt (with narrow exceptions
outside of the /etc/opt tree), and that /etc/opt is there to support
such files, as long as the
local admin is given an option to bail.

If circumstances dictate, the Policy does not preclude the use of
files installed under /etc/opt.

Reference - #825820

Bug#825820: ITP: goopg -- GPG for Gmail in Chrome and Chromium

[David Steele]

retitle 825820 ITP: goopg -- GPG for Gmail in Chrome and Chromium
owner 825820 !
Thanks

The most recent stable release is now 0.3.1.

The packages make use of the Chromium "native messaging hosts" capability to 
use the locally-installed gpg and gpg-agent to perform signing and 
verification. The key material and passphrase are never held by the browser or 
server.

This source creates three binary packages; goopg-common, goopg-chromium, and 
goopg-chrome. The chrome package is flagged for 'contrib'.

The upstream author prepared the bulk of the debian packaging information, and 
wishes to remain Maintainer. I intend to assist him. 


Regarding a lintian complaint for this package:

The Chrome version of this package installs a config file in a Google-required 
location under /etc/opt/chrome. That matches the convention of the 3rd-party 
Chrome package itself, installed in /opt/google/chrome.

The "dir-or-file-in-etc-opt" lintian test flags this as a 'serious' condition, 
saying "Debian packages should not install into /etc/opt, because it is 
reserved for add-on software". Lintian-overrides is not respected for this flag.

Debian Policy Section 9.1.1 states that packages must follow FHS v2.3. There 
are additional words strictly prohibiting installing files under /usr/local in 
9.1.2. There is no specific detail on /opt in Chapter 9.

The FHS is more precise, saying that "The directories /opt/bin, /opt/doc, 
/opt/include, /opt/info, /opt/lib, and /opt/man are reserved for local system 
administrator use", "No structure is imposed on the internal arrangement of 
/etc/opt/" and "Distributions may install software in /opt, but must 
not modify or delete software installed by the local system administrator 
without the assent of the local system administrator".

In short, the Policy does not support the level of concern shown by lintian. 
Also, the package does not violate the Policy.


signature.asc
Description: GooPG digital signature

Bug#839279: ITP: gocryptfs -- Encrypted overlay filesystem written in Go

[David Steele]

On Sat, Oct 1, 2016 at 3:09 PM, Ben Hutchings <b...@decadent.org.uk> wrote:
> On Sat, 2016-10-01 at 09:03 -0400, David Steele wrote:
>> On Sat, Oct 1, 2016 at 7:58 AM, Ben Hutchings <b...@decadent.org.uk>
>> wrote:
>> >
>> > On Sat, 2016-10-01 at 02:35 +, David Steele wrote:
>> > >
>> > > Package: wnpp
>> > > Severity: wishlist
>> > > >
>> > > > Owner: David Steele <ste...@debian.org>
>> > >
>> > > * Package name: gocryptfs
>> >
>> > What benefits does it provide over ecryptfs, which is already
>> > supported
>> > in Debian?
>> >
>>
>> https://nuetzlich.net/gocryptfs/comparison/
>
> OK, but it would be helpful to summarise the main advantages, like:
>
> - Includes integrity checking
> - Doesn't leak information about names of encrypted files
>

In the vs. ecryptfs case, the differences are more basic. I'd list kernel/root
vs FUSE/user, cloud sync support[1], and the availability of a user
management gui[2].

[1] https://www.cryfs.org/comparison#ecryptfs
[2] https://mhogomchungu.github.io/sirikali/

Bug#839402: ITP: golang-github-rfjakob-eme -- EME wide-block encryption for Go

[David Steele]

Package: wnpp
Severity: wishlist
Owner: David Steele <ste...@debian.org>

* Package name: golang-github-rfjakob-eme
  Version : 1.0
  Upstream Author : Jakob Unterwurzacher <jakob...@gmail.com>
* URL : https://github.com/rfjakob/eme
* License : Expat
  Programming Lang: Go
  Description : EME wide-block encryption for Go

EME for Go Build Status (https://drone.io/github.com/rfjakob/eme/latest)
GoDoc (https://godoc.org/github.com/rfjakob/eme) MIT License EME
(ECB-Mix-ECB) is a wide-block encryption mode developed by Halevi and
Rogaway in 2003 [eme]. (see references below)

EME uses multiple invocations of a block cipher to construct a new cipher
of bigger block size (in multiples of 16 bytes, up to 2048 bytes).


This library is required by gocryptfs (#839279).

The Debian Go Packaging Team is listed as the Maintainer. I intend to
provide ongoing support.

Bug#839279: ITP: gocryptfs -- Encrypted overlay filesystem written in Go

[David Steele]

On Sat, Oct 1, 2016 at 7:58 AM, Ben Hutchings <b...@decadent.org.uk> wrote:
> On Sat, 2016-10-01 at 02:35 +0000, David Steele wrote:
>> Package: wnpp
>> Severity: wishlist
>> > Owner: David Steele <ste...@debian.org>
>>
>> * Package name: gocryptfs
>
> What benefits does it provide over ecryptfs, which is already supported
> in Debian?
>

https://nuetzlich.net/gocryptfs/comparison/

Bug#839395: ITP: golang-github-jacobsa-crypto -- Some additional Go cryptography routines

[David Steele]

Package: wnpp
Severity: wishlist
Owner: David Steele <ste...@debian.org>

* Package name: golang-github-jacobsa-crypto
  Version : 0.0~git20160410.0.42daa9d-1
  Upstream Author : Aaron Jacobs
* URL : https://github.com/jacobsa/crypto
* License : Apache
  Programming Lang: Go
  Description : Some additional Go cryptography routines

This repository contains Go packages related to cryptographic standards
that are not included in the Go standard library. These include:

• SIV mode (http://go.pkgdoc.org/github.com/jacobsa/crypto/siv),
which provides deterministic encryption with authentication.

• CMAC (http://go.pkgdoc.org/github.com/jacobsa/crypto/cmac), a message
authentication system used by SIV mode.


This library is required by gocryptfs (#839279).

The Debian Go Packaging Team is listed as the Maintainer. I intend to
provide ongoing support.

Bug#839279: ITP: gocryptfs -- Encrypted overlay filesystem written in Go

[David Steele]

Package: wnpp
Severity: wishlist
Owner: David Steele <ste...@debian.org>

* Package name: gocryptfs
  Version : 1.0
  Upstream Author : Jakob Unterwurzacher <jakob...@gmail.com>
* URL : https://nuetzlich.net/gocryptfs/
* License : Expat
  Programming Lang: Go
  Description : Encrypted overlay filesystem written in Go

gocryptfs is built on top the excellent go-fuse
(https://github.com/hanwen/go-fuse) FUSE library and its
LoopbackFileSystem API.

This project was inspired by EncFS and strives to fix its
security issues while providing good performance (benchmarks
(https://nuetzlich.net/gocryptfs/comparison/#performance)).

For details on the security of gocryptfs see the Security
(https://nuetzlich.net/gocryptfs/security/) design document.


gocryptfs is one of several packages that implement FUSE encrypted
mounts. EncFS is already in Debian. CryFS is currently in NEW.
Relative to those, gocryptfs is generally faster and more space-
efficient, and exposes features of the underlying file system
(hard links, sparse files, ...). It was created to fix security
deficiencies in EncFS, but it still exposes features of the
protected filesystem to a greater degree than CryFS.

Two additional packages need to be introduced to support installation,
golang-github-jacobsa-crypto, and golang-github-rfjakob-eme.

The sirikali gui currently in NEW supports gocryptfs (#838426).

The Debian Go Packaging Team is listed as the Maintainer. I intend to
provide ongoing support.

Bug#838426: ITP: sirikali -- manage user encrypted volumes

[David Steele]

Package: wnpp
Severity: wishlist
Owner: David Steele <ste...@debian.org>

* Package name: sirikali
  Version : 1.1.0-1
  Upstream Author : Mhogo Mchungu <mhogomchu...@gmail.com>
* URL : https://mhogomchungu.github.io/sirikali/
* License : GPL
  Programming Lang: C++
  Description : manage user encrypted volumes

 Sirikali provides a Qt/C++ GUI front end for managing FUSE-based
 encrypted file systems, allowing the user to create, mount, and
 unmount encrypted volumes. The services cryfs (ITP[1]), encfs[2]
 gocryptfs, and securefs are supported. It also supports a number of
 key management mechanisms.

 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837127
 [2] https://packages.debian.org/sid/encfs

Bug#837127: ITP: cryfs -- encrypt your files and store them in the cloud

[David Steele]

Package: wnpp
Severity: wishlist
Owner: David Steele <ste...@debian.org>

* Package name: cryfs
  Version : 0.9.5
  Upstream Author : Sebastian Messmer
* URL : https://www.cryfs.org/
* License : LGPL
  Programming Lang: C++
  Description : encrypt your files and store them in the cloud

CryFS encrypts your files, so you can safely store them anywhere. It
works well together with cloud services like Dropbox, iCloud, OneDrive
and others.

It uses FUSE to establish a relationship between two directories. One
contains normal files. That directory is backed by another containing
an encrypted representation of the files.

It is roughly equivalent to the already-packaged EncFS, but is said to be
more secure (https://www.cryfs.org/comparison).

The most recent release prints a disclaimer that it should not yet be
used in production. Releasing to experimental.

Bug#821151: RFS: comitup/0.1-1 [ITP]

[David Steele]

Package: sponsorship-requests
Severity: wishlist
thanks

Dear mentors,

I am looking for a sponsor for my new package "comitup"

   Package name: comitup
   Version: 0.1
   Upstream Author: David Steele
   URL: https://github.com/davesteele/comitup
   License: GPL2+
   Section: net

It builds a single binary package:

comitup - bootstrap Wifi using Wifi

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

  http://mentors.debian.net/package/comitup

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

dget -x
http://mentors.debian.net/debian/pool/main/c/comitup/comitup_0.1-1.dsc

or, using git:

git clone https://github.com/davesteele/comitup.git -b debian
./comitup/debian/rules get-orig-source

More information about comitup can be obtained from

https://github.com/davesteele/comitup/tree/debian

ITP is at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821145

changelog:

comitup (0.1-1) unstable; urgency=low

  * Initial release (Closes: #821145)

 -- David Steele <dste...@gmail.com>  Wed, 23 Mar 2016 23:07:38 -0400



Regards,
   Dave Steele




signature.asc
Description: OpenPGP digital signature

Bug#821145: ITP: comitup -- Bootstrap Wifi using Wifi

[David Steele]

Package: wnpp
Severity: wishlist
thanks

* Package name: comitup
  Version : 0.1
  Upstream Author : David Steele <dste...@gmail.com>
* URL : https://github.com/davesteele/comitup
* License : GPL-2+
  Description : Bootstrap Wifi using Wifi

comitup is a service that provides a means for connecting a headless
Linux system (NUC, Raspberry Pi, etc.) to a wifi access point, using
wifi.

If the computer cannot automatically connect to a local access
point,comitup will create a custom hotspot, and establish a web service
on that network, published via Zeroconf. The web service can be used to
remotely select and authenticate a connection. The web service
communicates with comitup via a D-Bus API.

The Debian packaging is prepared, and can be seen at

  https://github.com/davesteele/comitup/tree/debian





signature.asc
Description: OpenPGP digital signature