Bug#1064881: ITP: golang-github-soniakeys-quant -- An interface for image color quantizers.

2024-02-27 Thread Robin Jarry
Package: wnpp
Severity: wishlist
Owner: Robin Jarry 

* Package name: golang-github-soniakeys-quant
  Version : 1.0.0-1
  Upstream Author : Sonia Keys
* URL : https://github.com/soniakeys/quant
* License : Expat
  Programming Lang: Go
  Description : An interface for image color quantizers.

 Quant
 .
 Experiments with color quantizers
 .
 Implemented here are two rather simple quantizers and an (also simple)
 ditherer. The quantizers satisfy the draw.Quantizer interface of the
 standard library. The ditherer satisfies the draw.Drawer interface of
 the standard library.

We need this as an indirect dependency for golang-sourcehut-rockorager-vaxis.



Bug#1064880: ITP: golang-github-mattn-go-sixel -- DRCS/Sixel Encoder/Decoder

2024-02-27 Thread Robin Jarry
Package: wnpp
Severity: wishlist
Owner: Robin Jarry 

* Package name: golang-github-mattn-go-sixel
  Version : 0.0.5-1
  Upstream Author : mattn
* URL : https://github.com/mattn/go-sixel
* License : Expat
  Programming Lang: Go
  Description : DRCS/Sixel Encoder/Decoder

 go-sixel
 .
 DRCS Sixel Encoder/Decoder
 .
 (http://go-gyazo.appspot.com/75ec3ce96dfc573e.png)
 .
 Installation
 .
   $ go get github.com/mattn/go-sixel
 .
 You can install gosr (go sixel renderer), gosd (go sixel decoder) with
 following installation instruction.
 .
   $ go get github.com/mattn/go-sixel/cmd/gosr
   $ go get github.com/mattn/go-sixel/cmd/gosd
 .
   COMMAND | DESCRIPTION
 --+---
   gosr| Image renderer
   gosd| Decoder to png
   goscat  | Render cats
   gosgif  | Render animation GIF
   gosl| Run SL
 .
 Usage
 .
 Encode
 .
   $ cat foo.png | gosr -
 .
 Decode
 .
   $ cat foo.drcs | gosd > foo.png
 .
 Use as library
 .
   img, _, _ := image.Decode(filename)
   sixel.NewEncoder(os.Stdout).Encode(img)
 .
 License
 .
 MIT
 .
 Author
 .
 Yasuhiro Matsumoto (a.k.a mattn)

We need this as a dependency for vaxis.



Bug#1064818: ITP: golang-sourcehut-rockorager-vaxis -- A modern TUI library for go

2024-02-26 Thread Robin Jarry
Package: wnpp
Severity: wishlist
Owner: Robin Jarry 

* Package name: golang-sourcehut-rockorager-vaxis
  Version : 0.8.2-1
  Upstream Author : Tim Culverhouse <>
* URL : https://git.sr.ht/~rockorager/vaxis
* License : Apache-2.0
  Programming Lang: Go
  Description : A modern TUI library for go

Vaxis is a Terminal User Interface (TUI) library for go. Vaxis supports modern
terminal features, such as styled underlines and graphics. A widgets package is
provided with some useful widgets.

Vaxis is blazingly fast at rendering. It might not be as fast or efficient as
notcurses, but significant profiling has been done to reduce all render
bottlenecks while still maintaining the feature-set.

All input parsing is done using a real terminal parser, based on the excellent
state machine by Paul Flo Williams. Some modifications have been made to allow
for proper SGR parsing (':' separated sub-parameters)

Vaxis does not use terminfo. Support for features is detected through terminal
queries. Vaxis assumes xterm-style escape codes everywhere else.

This will be a new dependency for aerc 0.18 and onwards.



Bug#1061857: Recommends: is too strong for dante-client

2024-02-01 Thread Robin Jarry

Nilesh Patra, Feb 01, 2024 at 10:07:

From what I gather, filters/html still uses socksify from dante package.
This looks OK as recommends - given that in 2024, people do get a bunch of HTML 
mails.

I want to close this bug if you agree.


We *could* drop it and change the default html filter to only use w3m 
without socksify.


Actually, aerc already ships an html-unsafe filter that does exactly 
that:


https://git.sr.ht/~rjarry/aerc/tree/master/item/filters/html-unsafe

The name may be frightening, I guess we could remove the hard dependency 
to socksify. People with high concerns for privacy can always tweak it 
to their needs.


Thoughts?



Bug#1053244: ITP: golang-sourcehut-rockorager-go-jmap -- A JMAP client library

2023-09-29 Thread Robin Jarry
Package: wnpp
Severity: wishlist
Owner: Robin Jarry 

* Package name: golang-sourcehut-rockorager-go-jmap
  Version : 0.3.0-1
  Upstream Author : Tim Culverhouse
* URL : https://git.sr.ht/~rockorager/go-jmap
* License : Expat
  Programming Lang: Go
  Description : A JMAP client library

A JMAP client library. Includes support for all core functionality (including
PushSubscription and EventSource event streams), mail, smime-verify, and MDN
specifications.

This is a new build dependency of aerc.



Bug#1049256: python-bonsai: Fails to build source after successful build

2023-09-05 Thread Robin Jarry
Lucas Nussbaum, Aug 14, 2023 at 03:54:
> If you fail to reproduce this, please provide a build log and diff it with 
> mine
> so that we can identify if something relevant changed in the meantime.

Hi Lucas,

I didn't manage to reproduce this. Here are both build logs binary and
source. I generated them with:

dpkg-buildpackage -us -uc; dpkg-buildpackage -S -us -uc

I don't use sbuild so I don't have the same logs than you have. Making
the diff a bit complex.
dpkg-buildpackage: info: source package python-bonsai
dpkg-buildpackage: info: source version 1.5.0+ds-3
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Jelmer Vernooij 
dpkg-buildpackage: info: host architecture amd64
 dpkg-source --before-build .
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying docs-disable-furo-theme.patch
dpkg-source: info: applying setup-do-not-use-distutils.patch
 debian/rules clean
dh clean --with python3,sphinxdoc --buildsystem=pybuild
   dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:291: python3.11 setup.py clean 
running clean
removing '/<>/.pybuild/cpython3_3.11/build' (and everything under it)
'build/bdist.linux-x86_64' does not exist -- can't clean it
'build/scripts-3.11' does not exist -- can't clean it
I: pybuild pybuild:340: rm -rf /<>/docs/_build
   dh_autoreconf_clean -O--buildsystem=pybuild
   dh_clean -O--buildsystem=pybuild
 dpkg-source -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building python-bonsai using existing ./python-bonsai_1.5.0+ds.orig.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: building python-bonsai in python-bonsai_1.5.0+ds-3.debian.tar.xz
dpkg-source: info: building python-bonsai in python-bonsai_1.5.0+ds-3.dsc
 debian/rules binary
dh binary --with python3,sphinxdoc --buildsystem=pybuild
   dh_update_autotools_config -O--buildsystem=pybuild
   dh_autoreconf -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
I: pybuild base:291: python3.11 setup.py config 
running config
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
blhc: ignore-line-regexp: .*test_krb5\.o .*test_krb5
dh_auto_build -O--buildsystem=pybuild
I: pybuild base:291: /usr/bin/python3 setup.py build 
running build
running build_py
creating /<>/.pybuild/cpython3_3.11/build/bonsai
copying src/bonsai/__init__.py -> /<>/.pybuild/cpython3_3.11/build/bonsai
copying src/bonsai/errors.py -> /<>/.pybuild/cpython3_3.11/build/bonsai
copying src/bonsai/ldapclient.py -> /<>/.pybuild/cpython3_3.11/build/bonsai
copying src/bonsai/ldapconnection.py -> /<>/.pybuild/cpython3_3.11/build/bonsai
copying src/bonsai/ldapdn.py -> /<>/.pybuild/cpython3_3.11/build/bonsai
copying src/bonsai/ldapentry.py -> /<>/.pybuild/cpython3_3.11/build/bonsai
copying src/bonsai/ldapreference.py -> /<>/.pybuild/cpython3_3.11/build/bonsai
copying src/bonsai/ldapurl.py -> /<>/.pybuild/cpython3_3.11/build/bonsai
copying src/bonsai/ldapvaluelist.py -> /<>/.pybuild/cpython3_3.11/build/bonsai
copying src/bonsai/ldif.py -> /<>/.pybuild/cpython3_3.11/build/bonsai
copying src/bonsai/pool.py -> /<>/.pybuild/cpython3_3.11/build/bonsai
copying src/bonsai/utils.py -> /<>/.pybuild/cpython3_3.11/build/bonsai
creating /<>/.pybuild/cpython3_3.11/build/bonsai/active_directory
copying src/bonsai/active_directory/__init__.py -> /<>/.pybuild/cpython3_3.11/build/bonsai/active_directory
copying src/bonsai/active_directory/acl.py -> /<>/.pybuild/cpython3_3.11/build/bonsai/active_directory
copying src/bonsai/active_directory/sid.py -> /<>/.pybuild/cpython3_3.11/build/bonsai/active_directory
creating /<>/.pybuild/cpython3_3.11/build/bonsai/asyncio
copying src/bonsai/asyncio/__init__.py -> /<>/.pybuild/cpython3_3.11/build/bonsai/asyncio
copying src/bonsai/asyncio/aioconnection.py -> /<>/.pybuild/cpython3_3.11/build/bonsai/asyncio
copying src/bonsai/asyncio/aiopool.py -> /<>/.pybuild/cpython3_3.11/build/bonsai/asyncio
creating /<>/.pybuild/cpython3_3.11/build/bonsai/gevent
copying src/bonsai/gevent/__init__.py -> /<>/.pybuild/cpython3_3.11/build/bonsai/gevent
copying src/bonsai/gevent/geventconnection.py -> /<>/.pybuild/cpython3_3.11/build/bonsai/gevent
creating /<>/.pybuild/cpython3_3.11/build/bonsai/tornado
copying src/bonsai/tornado/__init__.py -> /<>/.pybuild/cpython3_3.11/build/bonsai/tornado
copying src/bonsai/tornado/tornadoconnection.py -> /<>/.pybuild/cpython3_3.11/build/bonsai/tornado
creating /<>/.pybuild/cpython3_3.11/build/bonsai/trio
copying src/bonsai/trio/__init__.py -> /<>/.pybuild/cpython3_3.11/build/bonsai/trio
copying src/bonsai/trio/trioconnection.py -> /<>/.pybuild/cpython3_3.11/build/bonsai/trio
running egg_info
creating bonsai.egg-info
writing bonsai.egg-info/PKG-INFO
writing dependency_links to bonsai.egg-info/dependency_links.txt
writing requirements to bonsai.egg-info/requires.txt
writing top-level names to bonsai.egg-info/top_level.txt
writing manifest file 

Bug#1042578: aerc: No Reply-To completion

2023-08-24 Thread Robin Jarry
On Sun, 30 Jul 2023 17:48:07 +0200 Pelle  wrote:
> I think it would make sense if address book completion was enabled for
> the reply-to header field like it is for other fields for entering
> email addresses (From, To, CC, BCC).

Hi Pelle,

this is not supported at the moment. The list of headers for which there
is address completion is hard coded.

https://git.sr.ht/~rjarry/aerc/tree/0.15.2/item/completer/completer.go#L66-74

Feel free to submit a patch to add "reply-to" to that list. It should be
trivial ;)



Bug#1040907: aerc: Freeze when pasting to body on email compose

2023-07-14 Thread Robin Jarry
Nilesh Patra, Jul 14, 2023 at 20:35:
> On Fri, Jul 14, 2023 at 08:13:16PM +0200, Robin Jarry wrote:
> > Nilesh Patra, Jul 14, 2023 at 19:59:
> > > There you go
> > >
> > > https://pb.envs.net/?816fb8c61575e2ba#4kD2xS4wJMGrsCd8tBhPfqHDJZ7qeM6qERaobgoYj46F
> > 
> > Thanks a lot that helps. It looks like there is a deadlock due to two
> > goroutines trying to interact with the terminal:
>
> I'm going ahead with an upload in debian with this patch backported.
> From a distro pov I consider this a major breakeage. Given that aerc is
> designed to facilitate patch workflow as a goal, it makes it useless if
> I can't paste more than 4-5 lines in one go.
>
> If you disagree, feel free to revert the upload. You have the rights.

Sure thing. It is certainly less risky than tagging a release in a rush.



Bug#1040907: aerc: Freeze when pasting to body on email compose

2023-07-14 Thread Robin Jarry
Nilesh Patra, Jul 14, 2023 at 19:59:
> There you go
>
> https://pb.envs.net/?816fb8c61575e2ba#4kD2xS4wJMGrsCd8tBhPfqHDJZ7qeM6qERaobgoYj46F

Thanks a lot that helps. It looks like there is a deadlock due to two
goroutines trying to interact with the terminal:

goroutine 1 [sync.Mutex.Lock]:

sync.(*Mutex).Lock(...)
sync/mutex.go:90
git.sr.ht/~rockorager/tcell-term.(*VT).HandleEvent(0xc000158c80, {0xc5ce80?, 
0xc0007fff60?})
git.sr.ht/~rockorager/tcell-term@v0.7.1/vt.go:452 +0x6d fp=0xc000a2db40 
sp=0xc000a2dad8 pc=0x9a72cd
git.sr.ht/~rjarry/aerc/widgets.(*Terminal).Event(0xc000b26280?, {0xc5ce80?, 
0xc0007fff60?})
git.sr.ht/~rjarry/aerc/widgets/terminal.go:189 +0x72 fp=0xc000a2db68 
sp=0xc000a2db40 pc=0x9e72d2
git.sr.ht/~rjarry/aerc/widgets.(*Composer).Event(0xc000a2dc48?, {0xc5ce80?, 
0xc0007fff60?})
git.sr.ht/~rjarry/aerc/widgets/compose.go:669 +0xcf fp=0xc000a2dbb8 
sp=0xc000a2db68 pc=0x9c43af
git.sr.ht/~rjarry/aerc/widgets.(*Aerc).Event(0xc062e8?, {0xc5ce80?, 
0xc0007fff60?})
git.sr.ht/~rjarry/aerc/widgets/aerc.go:316 +0xc3 fp=0xc000a2dc30 
sp=0xc000a2dbb8 pc=0x9ba1a3
git.sr.ht/~rjarry/aerc/lib/ui.(*UI).HandleEvent(0xc4a040, {0xc5ce80?, 
0xc0007fff60})
git.sr.ht/~rjarry/aerc/lib/ui/ui.go:150 +0x162 fp=0xc000a2dc80 
sp=0xc000a2dc30 pc=0x6a79c2
main.main()
git.sr.ht/~rjarry/aerc/main.go:266 +0xb45 fp=0xc000a2df80 
sp=0xc000a2dc80 pc=0xa32fe5

goroutine 102 [chan send]:

git.sr.ht/~rjarry/aerc/lib/ui.QueueRedraw(...)
git.sr.ht/~rjarry/aerc/lib/ui/ui.go:30
git.sr.ht/~rjarry/aerc/widgets.(*Terminal).HandleEvent(0x8?, {0xc5c140?, 
0xc00094e850?})
git.sr.ht/~rjarry/aerc/widgets/terminal.go:168 +0x9c fp=0xc000435e38 
sp=0xc000435e10 pc=0x9e71bc
git.sr.ht/~rjarry/aerc/widgets.(*Terminal).HandleEvent-fm({0xc5c140?, 
0xc00094e850?})
:1 +0x39 fp=0xc000435e60 sp=0xc000435e38 pc=0x9e9fb9
git.sr.ht/~rockorager/tcell-term.(*VT).postEvent(...)
git.sr.ht/~rockorager/tcell-term@v0.7.1/vt.go:414
git.sr.ht/~rockorager/tcell-term.(*VT).update(0xc000158c80, {0xb119c0?, 
0xc000b24940?})
git.sr.ht/~rockorager/tcell-term@v0.7.1/vt.go:195 +0x489 
fp=0xc000435f80 sp=0xc000435e60 pc=0x9a50e9
git.sr.ht/~rockorager/tcell-term.(*VT).Start.func1()
git.sr.ht/~rockorager/tcell-term@v0.7.1/vt.go:165 +0x2d fp=0xc000435fe0 
sp=0xc000435f80 pc=0x9a4b2d
runtime.goexit()
runtime/asm_amd64.s:1598 +0x1 fp=0xc000435fe8 sp=0xc000435fe0 
pc=0x469781
created by git.sr.ht/~rockorager/tcell-term.(*VT).Start
git.sr.ht/~rockorager/tcell-term@v0.7.1/vt.go:155 +0x33c

It looks like a known issue that has been fixed by this commit:

https://git.sr.ht/~rjarry/aerc/commit/916bca33ea6cf2530117071fdd9b7b15e00e2f29

Not released yet.



Bug#1040907: aerc: Freeze when pasting to body on email compose

2023-07-14 Thread Robin Jarry
If you manage to reproduce this easily, could you try the following:

1) aerc >trace.log 2>&1
2) Compose a message reproduce the freeze.
3) From another terminal, kill aerc with SIGQUIT.

After aerc has died, share the trace.log file contents. Ideally via
paste service, lists.sr.ht bounce emails that have attachments.

Thanks



Bug#1040907: aerc: Freeze when pasting to body on email compose

2023-07-14 Thread Robin Jarry
Nilesh Patra, Jul 14, 2023 at 19:14:
> Are you using debian though?

No, I am on Fedora 38.

Linux ringo 6.3.11-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Jul  2 13:17:31 
UTC 2023 x86_64 GNU/Linux
go version go1.20.5 linux/amd64
sway version 1.8.1
foot version: 1.14.0 -pgo +ime +graphemes -assertions
aerc 0.15.2-96-gae07f640371e +notmuch (go1.20.5 amd64 linux)
NVIM v0.9.1
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/gcc -O2 -g -Og -g -Wall -Wextra -pedantic 
-Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion 
-Wvla -Wdouble-promotion -Wmissing-noreturn -Wmissing-format-attribute 
-Wmissing-prototypes -fno-common -Wno-unused-result -Wimplicit-fallthrough 
-fdiagnostics-color=auto -fstack-protector-strong -DUNIT_TESTING 
-DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -I/usr/include/luajit-2.1 
-I/usr/include -I/usr/include/luv 
-I/builddir/build/BUILD/neovim-0.9.1/redhat-linux-build/src/nvim/auto 
-I/builddir/build/BUILD/neovim-0.9.1/redhat-linux-build/include 
-I/builddir/build/BUILD/neovim-0.9.1/redhat-linux-build/cmake.config 
-I/builddir/build/BUILD/neovim-0.9.1/src -I/usr/include -I/usr/include 
-I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include



Bug#1040907: aerc: Freeze when pasting to body on email compose

2023-07-14 Thread Robin Jarry
pelle, Jul 14, 2023 at 18:23:
> > Robin and I are both on wayland...I'm guessing with xclip you are on
> > X? I wonder if that comes into play at all?
>
> I'm having the issue in Sway. I've noticed that the freeze happens in
> vim when pasting with `CTRL+V` or `SHIFT+INSERT` while pasting works
> fine with `p`.

I assume that you enter insert mode before pasting with `CTRL+V` or
`SHIFT+INSERT`. Tim, could it be a race with tcell term?



Bug#1040907: aerc: Freeze when pasting to body on email compose

2023-07-14 Thread Robin Jarry
Nilesh Patra, Jul 13, 2023 at 19:27:
> Hi,
>
> On Wed, 12 Jul 2023 11:09:03 +0200 Pelle  wrote:
> > Package: aerc
> > Version: 0.15.2-1
> > Severity: normal
> > 
> > I find that aerc almost always freezes when pasting into the compose area.
> > 
> > It can easily be reproduced here:
> >* Open aerc.
> >* Compose an email.
> >* Move cursor from headers onto the email body compose area.
> >* In another window, open a text editor, enter "hello world" 100 times 
> > and copy it.
> >* Back in aerc, paste into the compose area by `SHIFT+INSERT`
> >* Some of the text will be pasted, but then aerc will get stuck, 
> > sometimes like "hell|"
> >* Aerc stops responding to any input, including `CTRL+C`
> > 
> > I have tested an confirmed this is an issue whether using vim or nvim text 
> > editor, and whether using kitty, alacritty or foot terminal emulator.
>
> Thanks for reporting this, and I can confirm the behavior. @Robin, is
> this an issue known to you as upstream?
> Could you please take a look at this?

Hi Nilesh,

I cannot reproduce this but maybe Tim can have a look.

What editor is this?



Bug#1028779: buildbot: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.11 --system=custom "--test-args=PYTHONPATH=pkg:{destdir}/{install_dir} PATH=\$PATH:{destdir}/usr/bin trial3 --

2023-02-06 Thread Robin Jarry

Nilesh Patra, Feb 05, 2023 at 12:12:

Hi Robin,

buildbot is marked for removal on Feb 16. Do you intend to make an
upload?


Hi Nilesh,

sorry I had forgotten about that. It looks like Bastien has uploaded 
3.7.0-1 with a fix.




Bug#1019152: python-bonsai: flaky autopkgtest on armhf and armel: timeout too short?

2022-09-19 Thread Robin Jarry
Paul Gevers, Sep 19, 2022 at 21:52:
> Architecture: !armel !armhf
> is supported.

Awesome. I'll upload a new version with that fix then.

Thanks!



Bug#1019152: python-bonsai: flaky autopkgtest on armhf and armel: timeout too short?

2022-09-19 Thread Robin Jarry
Paul Gevers, Sep 19, 2022 at 21:13:
> I consider tests marked flaky as not so useful. Obviously if you'll
> look at it from time to time it's OK, but if no human is going to
> inspect it, it's smarter to just skip those architectures. Doing the
> latter is also easier than the former as we have the "Architecture"
> field for that, while flaky per arch you'd need to implement yourself.

I can live with disabling these tests on armel and armhf. If
I understood correctly, the Architecture field in d/t/control does not
support exclusions and it requires to set what arch is supported. I did
not found any explicit docs on that matter. Is there a way to list
multiple architectures?



Bug#1019152: python-bonsai: flaky autopkgtest on armhf and armel: timeout too short?

2022-09-19 Thread Robin Jarry
Hi Paul,

sorry for the delay. I am getting to work on this issue.

I am not sure how to increase the timeouts for these tests.

Would it be acceptable to mark these tests as flaky only on armel and
armhf?



Bug#1019894: ITP: golang-sourcehut-rockorager-tcell-term -- TODO

2022-09-15 Thread Robin Jarry
Package: wnpp
Severity: wishlist
Owner: Robin Jarry 

* Package name: golang-sourcehut-rockorager-tcell-term
  Version : 0.1.0-1
  Upstream Author : Tim Culverhouse 
* URL : https://git.sr.ht/~rockorager/tcell-term
* License : expat
  Programming Lang: Go
  Description : A virtual terminal widget for tcell

tcell-term implements the native tcell Widget interface.

This is a new dependency for aerc.



Bug#1017247: golang-github-gatherstars-com-jwz: FTBFS: dh_auto_test: error: cd _build && go test -vet=off -v -p 8 github.com/gatherstars-com/jwz github.com/gatherstars-com/jwz/examples/visualize retur

2022-08-25 Thread Robin Jarry
Hey Nilesh,

Nilesh Patra, Aug 25, 2022 at 14:20:
> This bug is causing an autoremoval warning for aerc. There does not seem to 
> be a fix
> upstream about this. I am not sure what exactly is triggering this, but my 
> hunch
> is it might be related to change in sort function with golang 1.19.
> (This works fine with go-1.18)
>
> Can I ask you to take a look at it?

I pushed a fix on salsa:

https://salsa.debian.org/go-team/packages/golang-github-gatherstars-com-jwz/-/commit/842c69125282bdfb2725325d91d8002ce8f86891

This patch was submitted upstream:

https://github.com/gatherstars-com/jwz/pull/2

If you want I can upload but you'll need to give me permission for
golang-github-gatherstars-com-jwz :-)

Cheers,



Bug#1016453: python-tornado breaks python-bonsai autopkgtest: 'TornadoLDAPConnectionTest' object has no attribute 'should_close_asyncio_loop'

2022-08-01 Thread Robin Jarry
Hi Paul,

I have checked in bonsai code base, and there is no reference to
should_close_asyncio_loop. It looks like a tornado thing.

However, looking at the full error trace, I can see that:

> ldapwhoami: unrecognized option -�
> Issue LDAP Who am I? operation to request user's authzid
>
> usage: ldapwhoami [options]
> Common options:
>   -d level   set LDAP debugging level to `level'
>   -D binddn  bind DN
> [...]

Which may cause the tests to be aborted early and cause
should_close_asyncio_loop to be accessed[1] before it is defined[2] in
tornado.

[1]: 
https://salsa.debian.org/python-team/packages/python-tornado/-/blob/master/tornado/testing.py#L282
[2]: 
https://salsa.debian.org/python-team/packages/python-tornado/-/blob/master/tornado/testing.py#L204-230

There were a few unreleased patches from bonsai[3], I'll make a new
release.

[3]: 
https://salsa.debian.org/python-team/packages/python-bonsai/-/commit/22d2533ab8094a299d1816a46917070e2b251265

In the meantime, I think that the should_close_asyncio_loop attribute
should be defined in tornado.testing.AsyncTestCase.__init__() instead of
in tornado.testing.AsyncTestCase.setUp().



Bug#1014313: ITP: golang-github-emersion-go-mbox -- Package mbox parses the mbox file format into messages and formats messages into mbox files

2022-07-03 Thread Robin Jarry
Package: wnpp
Severity: wishlist
Owner: Robin Jarry 

* Package name: golang-github-emersion-go-mbox
  Version : 1.0.3-1
  Upstream Author : Simon Ser
* URL : https://github.com/emersion/go-mbox
* License : Expat
  Programming Lang: Go
  Description : Package mbox parses the mbox file format into messages and 
formats messages into mbox files

New dependency for aerc.



Bug#1013966: ITP: golang-github-emersion-go-milter -- Go library to write mail filters

2022-06-28 Thread Robin Jarry
Package: wnpp
Severity: wishlist
Owner: Robin Jarry 

* Package name: golang-github-emersion-go-milter
  Version : 0.3.3-1
  Upstream Author : Simon Ser
* URL : https://github.com/emersion/go-milter
* License : BSD-2-clause
  Programming Lang: Go
  Description : Go library to write mail filters

 go-milter
 .
 GoDoc (https://godoc.org/github.com/emersion/go-milter) builds.sr.ht
 status (https://builds.sr.ht/~emersion/go-milter/commits?)
 .
 A Go library to write mail filters.
 .
 License
 .
 BSD 2-Clause

Dependency of golang-github-emersion-go-msgauth, indirect dependency of aerc.



Bug#1013928: ITP: golang-github-emersion-go-msgauth -- A Go library and tools for DKIM, DMARC and Authentication-Results

2022-06-27 Thread Robin Jarry
Package: wnpp
Severity: wishlist
Owner: Robin Jarry 

* Package name: golang-github-emersion-go-msgauth
  Version : 0.6.6-1
  Upstream Author : Simon Ser
* URL : https://github.com/emersion/go-msgauth
* License : Expat
  Programming Lang: Go
  Description : A Go library and tools for DKIM, DMARC and 
Authentication-Results

 go-msgauth
 .
 godocs.io (https://godocs.io/github.com/emersion/go-msgauth) builds.sr.ht
 status (https://builds.sr.ht/~emersion/go-msgauth/commits/master)
 .
 A Go library and tools to authenticate e-mails:
 .
  * Create and verify DKIM signatures
(https://tools.ietf.org/html/rfc6376)
  * Create and parse Authentication-Results header fields
(https://tools.ietf.org/html/rfc7601)
  * Fetch DMARC (http://tools.ietf.org/html/rfc7489) records
 .
 DKIM godocs.io (https://godocs.io/github.com/emersion/go-msgauth/dkim)
 .
 Sign
 .
   r := strings.NewReader(mailString)
 .
   options := {
Domain: "example.org",
Selector: "brisbane",
Signer: privateKey,
   }
 .
   var b bytes.Buffer
   if err := dkim.Sign(, r, options); err != nil {
log.Fatal(err)
   }
 .
 Verify
 .
   r := strings.NewReader(mailString)
 .
   verifications, err := dkim.Verify(r)
   if err != nil {
log.Fatal(err)
   }
 .
   for _, v := range verifications {
if v.Err == nil {
log.Println("Valid signature for:", v.Domain)
} else {
log.Println("Invalid signature for:", v.Domain, v.Err)
}
   }
 .
 FAQ
 .
 **Why can't I verify a mail.Message directly?** A mail.Message header is
 already parsed, and whitespace characters (especially continuation
 lines) are removed. Thus, the signature computed from the parsed header
 is not the same as the one computed from the raw header.
 .
 **How can I publish my public key?** You have to add a TXT record to
 your DNS zone. See RFC 6376 appendix C
 (https://tools.ietf.org/html/rfc6376#appendix-C). You can use the dkim-
 keygen tool included in go-msgauth to generate the key and the TXT
 record.
 .
 Authentication-Results godocs.io
 (https://godocs.io/github.com/emersion/go-msgauth/authres)
 .
   // Format
   results := []authres.Result{
{Value: authres.ResultPass, From: "example.net"},
{Value: authres.ResultPass, Auth:
 "sen...@example.com"},
   }
   s := authres.Format("example.com", results)
   log.Println(s)
 .
   // Parse
   identifier, results, err := authres.Parse(s)
   if err != nil {
log.Fatal(err)
   }
 .
   log.Println(identifier, results)
 .
 DMARC godocs.io (https://godocs.io/github.com/emersion/go-msgauth/dmarc)
 .
 See the GoDoc page.
 .
 Tools
 .
 A few tools are included in go-msgauth:
 .
  * dkim-keygen: generate a DKIM key
  * dkim-milter: a mail filter to sign and verify DKIM signatures
  * dkim-verify: verify a DKIM-signed email
  * dmarc-lookup: lookup the DMARC policy of a domain
 .
 License
 .
 MIT


This is a new build dependency for aerc.



Bug#1013927: ITP: golang-github-arran4-golang-ical -- A ICS / ICal parser and serialiser for Golang.

2022-06-27 Thread Robin Jarry
Package: wnpp
Severity: wishlist
Owner: Robin Jarry 

* Package name: golang-github-arran4-golang-ical
  Version : 0.0~git20220517.fd89fefb0182-1
  Upstream Author : Arran Ubels
* URL : https://github.com/arran4/golang-ical
* License : Apache-2.0
  Programming Lang: Go
  Description : A  ICS / ICal parser and serialiser for Golang.

 golang-ical
 .
 A  ICS / ICal parser and serialiser for Golang.
 .
 Because the other libraries didn't quite do what I needed.
 .
 Usage, parsing:
 .
   cal, err := ParseCalendar(strings.NewReader(input))
 .
 .
 Creating:
 .
 cal := ics.NewCalendar()
 cal.SetMethod(ics.MethodRequest)
 event := cal.AddEvent(fmt.Sprintf("id@domain",
 p.SessionKey.IntID()))
 event.SetCreatedTime(time.Now())
 event.SetDtStampTime(time.Now())
 event.SetModifiedAt(time.Now())
 event.SetStartAt(time.Now())
 event.SetEndAt(time.Now())
 event.SetSummary("Summary")
 event.SetLocation("Address")
 event.SetDescription("Description")
 event.SetURL("https://URL/;)
 event.AddRrule(fmt.Sprintf("FREQ=YEARLY;BYMONTH=%d;BYMONTHDAY=%d",
 time.Now().Month(), time.Now().Day()))
 event.SetOrganizer("sender@domain", ics.WithCN("This Machine"))
 event.AddAttendee("reciever or participant",
 ics.CalendarUserTypeIndividual, ics.ParticipationStatusNeedsAction,
 ics.ParticipationRoleReqParticipant, ics.WithRSVP(true))
 return cal.Serialize()
 .
 Helper methods created as needed feel free to send a P.R. with more.

This is a new build dependency for aerc.



Bug#1004344: how to generate list of JS deps to package

2022-06-20 Thread Robin Jarry
Martin, Jun 20, 2022 at 15:49:
> See https://wiki.debian.org/Javascript/Nodejs/Tasks/
>
> The tool generates the source code for a wiki page, e.g. like this one:

Hi,

I ran the script on buildbot-build-common which is not a real
installable package, only a toolkit used by www plugins (it took more
than 2 hours).

https://paste.sr.ht/~rjarry/2197906bc7f706e726dddfe3071a27b0a82c5f80

I cannot subscribe to the wiki to create a new page: "Automatic account
creation disabled to stop spammers signing up."

In any case, there seem to be a lot of missing packages. This does not
look like a trivial task :)

Cheers,
Robin



Bug#1006955: ITP: python-txrequests -- Asynchronous Python HTTP Requests for Humans using twisted

2022-03-08 Thread Robin Jarry
Package: wnpp
Severity: wishlist
Owner: Robin Jarry 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-txrequests
  Version : 0.9.6
  Upstream Author : Pierre Tardy 
* URL : https://github.com/tardyp/txrequests
* License : Apache-2.0
  Programming Lang: Python
  Description : Asynchronous Python HTTP Requests for Humans using twisted

Small add-on for the python requests http library. Makes use twisted's
ThreadPool, so that the requests'API returns deferred objects.

This is a dependency of buildbot. Required to update to 3.4.1 and later.

I intend on maintaining this package in the context of the Debian Python
Team. I will need a sponsor for uploads after pushing on Salsa.

Thanks!



Bug#1004344: buildbot: Fails to load the web interface

2022-01-25 Thread Robin Jarry
Hi,

this is a known issue. The buildbot-www package cannot be integrated in
Debian due to tons of missing JS dependencies. See buildbot(7) and bug
#883529 for more details.

Since then, buildbot has changed from coffeescript+gulp to plain
JS+webpack. This should make it easier to package the missing
dependencies and support packaging the www plugins. Still far from
a trivial task unfortunately... I am not even sure how to proceed.
I would really appreciate some help on the matter.

In the meantime, you may install buildbot-www via pip (although this is
not a very nice workaround).

Thanks.



Bug#1001417: ITP: bonsai -- Python3 asyncio-compatible LDAP library

2021-12-09 Thread Robin Jarry
Package: wnpp
Severity: wishlist
Owner: Robin Jarry 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: bonsai
  Version : 1.3.0
  Upstream Author : noirello 
* URL : https://github.com/noirello/bonsai
* License : MIT
  Programming Lang: Python 3
  Description : Python3 asyncio-compatible LDAP library

Bonsai is library for handling LDAP operations in Python. Uses libldap2
on UNIX platforms and WinLDAP on Microsoft Windows. LDAP entries are
mapped to a special Python case-insensitive dictionary, tracking the
changes of the dictionary to modify the entry on the server easily.

* Supports only Python 3.6 or newer, and LDAPv3.

* Uses LDAP libraries (OpenLDAP and WinLDAP) written in C for faster
  processing.

* Simple pythonic design.

* Implements an own dictionary-like object for mapping LDAP entries that
  makes easier to add and modify them.

* Works with various asynchronous libraries (like asyncio, gevent).

I intend on maintaining this package in the context of the Debian Python 
Team. I will need a sponsor for uploads after pushing on Salsa.

This package is not yet in Debian but I like the design and I think it
would be a great addition in the archive. Also, it is the only asyncio
compatible LDAP library that I know of.

Thanks!



Bug#993522: buildbot-worker: Setting WORKER_OPTIONS to any non-empty value doesn't work

2021-09-02 Thread Robin Jarry
Hi Vadim,

2021-09-02, Vadim Zeitlin:
> Package: buildbot-worker
> Version: 2.10.1-1
> Severity: normal
> 
> Dear Maintainer,
> 
> Setting WORKER_OPTIONS in /etc/default/buildbot-worker to e.g. "--verbose"
> doesn't work because its value is used in a wrong place in the init.d
> script: it does
> 
> "$WORKER_RUNNER $op ${WORKER_OPTIONS[$mi]} ${WORKER_BASEDIR[$mi]}
> 
> when the correct syntax would be
> 
> "$WORKER_RUNNER ${WORKER_OPTIONS[$mi]} $op ${WORKER_BASEDIR[$mi]}
> 
> i.e. the options must come _before_ the operation for buildbot-worker, not
> after it.

Actually, this is only true for the --verbose option. Other options must
be passed after $op.

> -- System Information:
> Debian Release: 11.0
>   APT prefers stable-security
>   APT policy: (500, 'stable-security'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
> to C.UTF-8), LANGUAGE=en_US:en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)

I see that you are using systemd. You should not use the init.d script
but the systemd unit template which is provided with the package. There
are examples in the man page to tweak the unit parameters:

https://manpages.debian.org/bullseye/buildbot-worker/buildbot-worker.7.en.html#systemd

In your case, you should override ExecStart= in a drop-in file.

Also, it looks like this is a duplicate of bug #993521. Should I close
the first one?

-- 
Robin



Bug#984970: buildbot 2.10.2 in Debian/bullseye

2021-03-11 Thread Robin Jarry
Unfortunately, I don't know if 3.0.0 is stable. It deprecates a lot of
things and only has been out for a couple of days.

I'll submit 2.10.2 first and then I'll check with the python team what
they think.



Bug#984970: buildbot 2.10.2 in Debian/bullseye

2021-03-11 Thread Robin Jarry
Hi Hans,

I was considering uploading 3.0.0 now that has been released.

https://github.com/buildbot/buildbot/releases/tag/v3.0.0

Would that be ok?



Bug#953966: buildbot: autopkgtest failure with Python 3.8 as default

2020-03-26 Thread Robin Jarry
Control: severity -1 important

The autopkgtests seem to work now:

https://ci.debian.net/user/britney/jobs?package=buildbot[]=testing[]=amd64

The bug may have been fixed by: python3-defaults 3.8.2-2

Lets leave it open for a while to see if the tests are stable now.

-- 
Robin



Bug#872864: gbp-buildpackage: orig signature file not exported with pristine-tar

2019-07-09 Thread Robin Jarry
Hi,

This problem causes a lintian warning:

W: buildbot source: orig-tarball-missing-upstream-signature 
buildbot_2.3.1.orig.tar.gz
N: 
N:The packaging includes an upstream signing key but the corresponding
N:.asc signature for one or more source tarballs are not included in your
N:.changes file.
N:
N:Please ensure a _.orig.tar..asc file exists in
N:the same directory as your _.orig.tar. tarball
N:prior to dpkg-source --build being called.
N:
N:If you are repackaging your source tarballs for Debian Free Software
N:Guidelines compliance reasons, ensure that your package version includes
N:dfsg or similar.
N:
N:Support for signatures was added to pristine-tar in version 1.41 and
N:support in git-buildpackage is being tracked in #872864.
N:
N:Severity: normal, Certainty: certain
N:
N:Check: control-file, Type: source
N: 

I attached an inline patch that "fixes" the problem at the end of this
message but I am not entirely sure if this is the correct approach.

Please tell me if you need more info.

Thanks

--- /usr/lib/python3/dist-packages/gbp/deb/git.py.old   2019-07-09 
13:01:18.913389409 +0200
+++ /usr/lib/python3/dist-packages/gbp/deb/git.py   2019-07-09 
12:59:34.854238866 +0200
@@ -320,7 +320,7 @@ class DebianGitRepository(PkgGitReposito
 output = source.upstream_tarball_name(comp.type, component=component)
 try:
 self.pristine_tar.checkout(source.name, source.upstream_version, 
comp.type, output_dir,
-   component=component, quiet=True)
+   component=component, quiet=True, 
signature=True)
 except Exception as e:
 raise GitRepositoryError("Error creating %s: %s" % (output, e))
 return True

-- 
Robin



Bug#929965: unblock: buildbot/2.0.1-2

2019-06-04 Thread Robin Jarry
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Tags: security
Control: affects -1 src:buildbot

Please unblock package buildbot.

Version 2.0.1-2 resolves a grave security bug in buildbot (#929849).

A source debdiff against 2.0.1-1 follows.

Thank you!

Robin

diff -Nru buildbot-2.0.1/debian/changelog buildbot-2.0.1/debian/changelog
--- buildbot-2.0.1/debian/changelog 2019-02-11 21:26:20.0 +0100
+++ buildbot-2.0.1/debian/changelog 2019-06-03 14:47:25.0 +0200
@@ -1,3 +1,9 @@
+buildbot (2.0.1-2) unstable; urgency=high
+
+  * Fix OAuth module security bypass [CVE-2019-12300] (Closes: #929849)
+
+ -- Robin Jarry   Mon, 03 Jun 2019 14:47:25 +0200
+
 buildbot (2.0.1-1) unstable; urgency=medium
 
   * Use scdoc for man pages
diff -Nru 
buildbot-2.0.1/debian/patches/0005-Revert-master-Accept-GitHub-access_token-directly-fr.patch
 
buildbot-2.0.1/debian/patches/0005-Revert-master-Accept-GitHub-access_token-directly-fr.patch
--- 
buildbot-2.0.1/debian/patches/0005-Revert-master-Accept-GitHub-access_token-directly-fr.patch
   1970-01-01 01:00:00.0 +0100
+++ 
buildbot-2.0.1/debian/patches/0005-Revert-master-Accept-GitHub-access_token-directly-fr.patch
   2019-06-03 14:47:25.0 +0200
@@ -0,0 +1,153 @@
+From: Robin Jarry 
+Date: Mon, 3 Jun 2019 14:43:12 +0200
+Subject: Revert "master: Accept GitHub `access_token` directly from user"
+
+This is a backport of upstream commit e1dcfce4388bfb: ("Revert "master:
+Accept GitHub `access_token` directly from user"").
+
+Fixes: CVE-2019-12300
+Signed-off-by: Pierre Tardy 
+Signed-off-by: Robin Jarry 
+---
+ master/buildbot/test/unit/test_www_oauth.py | 37 +-
+ master/buildbot/www/oauth2.py   | 41 +++--
+ 2 files changed, 21 insertions(+), 57 deletions(-)
+
+diff --git a/master/buildbot/test/unit/test_www_oauth.py 
b/master/buildbot/test/unit/test_www_oauth.py
+index 551f221..fd3b0de 100644
+--- a/master/buildbot/test/unit/test_www_oauth.py
 b/master/buildbot/test/unit/test_www_oauth.py
+@@ -191,30 +191,7 @@ class OAuth2Auth(www.WwwTestMixin, ConfigErrorsMixin, 
unittest.TestCase):
+   'full_name': 'foo bar'}, res)
+ 
+ @defer.inlineCallbacks
+-def test_GithubAcceptToken(self):
+-requests.get.side_effect = []
+-requests.post.side_effect = [
+-FakeResponse(dict(access_token="TOK3N"))]
+-self.githubAuth.get = mock.Mock(side_effect=[
+-dict(  # /user
+-login="bar",
+-name="foo bar",
+-email="buzz@bar"),
+-[  # /user/emails
+-{'email': 'buzz@bar', 'verified': True, 'primary': False},
+-{'email': 'bar@foo', 'verified': True, 'primary': True}],
+-[  # /user/orgs
+-dict(login="hello"),
+-dict(login="grp"),
+-]])
+-res = yield self.githubAuth.acceptToken("TOK3N")
+-self.assertEqual({'email': 'bar@foo',
+-  'username': 'bar',
+-  'groups': ["hello", "grp"],
+-  'full_name': 'foo bar'}, res)
+-
+-@defer.inlineCallbacks
+-def test_GithubAcceptToken_v4(self):
++def test_GithubVerifyCode_v4(self):
+ requests.get.side_effect = []
+ requests.post.side_effect = [
+ FakeResponse(dict(access_token="TOK3N"))]
+@@ -243,14 +220,14 @@ class OAuth2Auth(www.WwwTestMixin, ConfigErrorsMixin, 
unittest.TestCase):
+ }
+ }
+ ])
+-res = yield self.githubAuth_v4.acceptToken("TOK3N")
++res = yield self.githubAuth_v4.verifyCode("code!")
+ self.assertEqual({'email': 'bar@foo',
+   'username': 'bar',
+   'groups': ["hello", "grp"],
+   'full_name': 'foo bar'}, res)
+ 
+ @defer.inlineCallbacks
+-def test_GithubAcceptToken_v4_teams(self):
++def test_GithubVerifyCode_v4_teams(self):
+ requests.get.side_effect = []
+ requests.post.side_effect = [
+ FakeResponse(dict(access_token="TOK3N"))]
+@@ -331,7 +308,7 @@ class OAuth2Auth(www.WwwTestMixin, ConfigErrorsMixin, 
unittest.TestCase):
+ }
+ }
+ ])
+-res = yield self.githubAuth_v4_teams.acceptToken("TOK3N")
++res = yield self.githubAuth_v4_teams.verifyCode("code!")
+ self.assertEqual({'email': 'bar@foo',
+   'username': 'bar',
+   'groups': [
+@@ -434,11 +411,9 @@ class OAuth2Auth(www.WwwTestMixin, ConfigErrorsMixin, 
unittest.TestCase):
+ rsrc.auth.verifyCode.assert_cal

Bug#917489: duplicate of #916922 in src:migrate

2018-12-28 Thread Robin Jarry
Control: reassign -1 src:migrate 0.11.0-4
Control: affects -1 src:buildbot


Bug#916922: buildbot: FTBFS: test failures

2018-12-20 Thread Robin Jarry
Control: reassign -1 migrate 0.11.0-4

2018-12-20, Mattia Rizzolo:
> All of them seems to always boil down to:
> builtins.NameError: name 'sqlite3' is not defined

The error actually pops into migrate code.

  File "/usr/lib/python3/dist-packages/migrate/changeset/databases/sqlite.py", 
line 99, in recreate_table
tup = sqlite3.sqlite_version_info
builtins.NameError: name 'sqlite3' is not defined

I've done some digging, and it looks like it is caused by the latest
version of migrate. Indeed, it applies a patch from ubuntu:

https://salsa.debian.org/openstack-team/libs/migrate/commit/6de8f506fd9265f52a2086ec1e3cde35802f73fb

Which references the sqlite3 symbol which is not imported in the
migrate/changeset/databases/sqlite.py file.

I would suggest modifying this patch and add the missing import.

Thanks.

-- 
Robin



Bug#901769: sphinx: crash with numbered toctrees

2018-06-18 Thread Robin Jarry
Control: severity -1 serious

By the way, this bug breaks the build of buildbot 1.1.1-3 (which is
already in the archive).

-- 
Robin



Bug#901769: sphinx: crash with numbered toctrees

2018-06-18 Thread Robin Jarry
Package: python3-sphinx
Source: sphinx
Version: 1.7.5-2
Severity: important
Tags: upstream fixed-upstream

Hi,

With python{,3}-sphinx 1.7.5-*, using numbered toctrees cause a crash.
Take the following rst source:

 .. toctree::
:numbered:

doc1
doc2
doc3

When building (whatever format), we get this error:

  Exception occurred:
File 
"/usr/lib/python3/dist-packages/sphinx/environment/collectors/toctree.py", line 
172, in _walk_toc
  subnode[0]['secnumber'] = list(number)
  TypeError: 'NoneType' object is not iterable

This bug has already been reported:
https://github.com/sphinx-doc/sphinx/issues/5048

and fixed upstream:
https://github.com/sphinx-doc/sphinx/commit/96b9b9a127646c51e4bb8db980d528802a6ba652.patch

But this fix is not yet included in a release, it will be in sphinx
1.7.6. Could you apply the patch in a debian 1.7.5-3 version?

Thanks.

-- 
Robin



Bug#895289: RM: buildbot-slave -- RoM; now merged with buildbot

2018-04-09 Thread Robin Jarry
Package: ftp.debian.org

Please remove the buildbot-slave source package from the archive. All
buildbot packages are now built from the buildbot source package.

Thanks.

-- 
Robin



Bug#883529: Buildbot maintenance by PAPT

2018-03-27 Thread Robin Jarry
2018-03-26, Piotr Ożarowski:
> great, just let me know if you accept our policy and I'll hit the button

Yes, I accept the Debian Python Policy:
https://www.debian.org/doc/packaging-manuals/python-policy/

> (BTW, dh-python should be ready for builbot now, let me know if you need
> more changes)

Awesome, I'll check it ASAP.

Thanks!

-- 
Robin



Bug#883529: Buildbot maintenance by PAPT

2018-02-27 Thread Robin Jarry
Hi all,

after some discussions on https://bugs.debian.org/883529, Martin Borgert
suggested that buildbot becomes maintained by the Python Applications
Packaging Team.

That sounds like a good thing to have more than one person able to work
on this package.

I am currently working on buildbot (both upstream dev and Debian
packaging), I have read the Debian Python Policy and I'm not sure how to
proceed for joining the PAPT.

Thanks for your guidance.

-- 
Robin



Bug#883529: ITA: buildbot,buildbot-slave -- Build automation system

2018-02-15 Thread Robin Jarry
2018-02-14, W. Martin Borgert:
> Robin, many thanks for working on buildbot!
> Very much appreciated!

Don't mention it. It is a good thing to have it in Debian, it gives a
lot of visibility and good reputation to the project. I'm glad to help!

> At least for Node I reject the term ecosystem. Toxic waste dump?
> 
> Sorry, just kidding.

Hehe, so that is not only for java :)

> Very good! If server and web ui are separated cleanly, it should
> be possible to write alternative UIs, right? Like a console one
> for us terminal aficionados.

Yes absolutely. The web ui itself makes use of the rest api:

  https://docs.buildbot.net/latest/developer/rest.html

I personally use this api extensively from command line tools at work.
It should be completely possible to have an official console client.

> If there are Python depends, that are not in Debian or too old,
> do not hesitate to ask me, maybe I can burn some time.

So far, the missing depends are projects that have not seen much
activity since a long time. I am in the process of making them optional
for building docs and running tests.

> Btw. maybe you want to maintain buildbot (at least the parts mainly
> written in Python) within the Python Applications Packaging Team
> ? It is also at salsa:
> https://salsa.debian.org/python-team/applications, but the packages
> have not yet been migrated.

I had not thought about that. Why not, but I don't know how this works.
Do I need to join this team first?

For now, the source for buildbot Debian packaging is hosted on github:

  https://github.com/buildbot/debian-buildbot/
  https://github.com/buildbot/debian-buildbot-worker/

And I have a fork with my work-in-progress:

  https://github.com/rjarry/debian-buildbot/



Bug#883529: ITA: buildbot,buildbot-slave -- Build automation system

2018-02-14 Thread Robin Jarry
Hi Martin,

2018-02-14, W. Martin Borgert:
> did the discussion about coffeescript vs ECMA6 already lead to something?

We mentioned it a few times during the weekly meetings we have on
tuesdays. We have been busy lately with the 1.0.0 release!

https://medium.com/buildbot/buildbot-1-0-0-38c6208ac7d7

This is hard for me to estimate the repercussions as I lack good
knowledge of the JS ecosystem. It does not look like a trivial task in
any case :)

I'll try to bring this up next tuesday to see when/if this can be
considered.

> In any case, I suggest mass-file RFPs/ITPs for all needed node packages.
> Then package as many as you feel like. Maybe others will help, let's see.
> I cannot promise any help, because I'm already busy with other tasks.
> 
> I recommend to package all node libraries under the umbrella of the
> Debian Javascript Maintainers 
> They have their git repo here: https://salsa.debian.org/js-team

That's very nice to know. Thanks! I was afraid I might need to do all
that myself :D

For now, I am focusing in having only the server and worker packages
(without any web ui) updated in debian with the latest upstream release.
There is a small limitation in pybuild regarding building multiple
binary packages from the same source package (each located in
subdirectories). I talked with p1otr on #debian-python and he told me he
may have a fix uploaded soon(tm).

In the meantime, I am struggling to make the tests run and docs build
with only debian dependencies.

Once this is done, I will work on web ui packages. Hopefully,
buildbot-www* packages will have gotten rid of some dependencies which
would make debian integration easier. I'll surely shime in #debian-js to
ask for guidance.

Cheers,

-- 
Robin



Bug#883529: ITA: buildbot,buildbot-slave -- Build automation system

2017-12-15 Thread Robin Jarry
Hi,

I had a look at the current state of the buildbot and buildbot-slave
source packages. It looks like the choice was made to have one source
package per binary package.

https://tracker.debian.org/pkg/buildbot
https://tracker.debian.org/pkg/buildbot-slave

All buildbot related code is under source control in a single git
repository. If I understand correctly the way Debian packaging works,
there can be multiple bin packages produced from a single source
package.

This would make sense for buildbot. Even more now that there are
multiple web ui plugins that can be installed separately. No need to
maintain multiple packages would be simpler.

There is one major problem: all www plugins require building
coffeescript and jade templates into pure javascript. This requires
nodejs and a ton of dependencies (managed by gulp). Simevo created a
page on debian wiki to track these:

https://wiki.debian.org/Javascript/Nodejs/Tasks/guanlecoja

Also, there is an on-going discussion to replace coffeescript by native
ECMA6 javascript and switching from gulp to webpack which would remove a
lot of these dependencies. Unfortunately, this will take some time to
land as this almost means rewriting the whole frontend plugins.

In the meantime, I feel that we should drop the buildbot-slave source
package and build both buildbot and buildbot-worker binary packages from
the buildbot source package.

The www plugins can be added later when building them is actually
feasible with debian dependencies.

Martin, Matthias, what do you think? I'd like your opinion before
proceeding in any direction.

-- 
Robin



Bug#884353: --no-wheel option causes pip install errors

2017-12-14 Thread Robin Jarry
Package: python-virtualenv
Version: 15.1.0+ds-1
Source: python-virtualenv

When creating a venv with the --no-wheel option, the wheel package is
not installed in /lib/pythonX.Y/site-packages. However, due to a
Debian patch [1], all *.whl files in /usr/share/python-wheels are copied
into /share/python-wheels. Amongst them is
/usr/share/python-wheels/wheel-0.29.0-py2.py3-none-any.whl.

[1] 
https://sources.debian.org/src/python-virtualenv/15.1.0+ds-1/debian/patches/use-wheels.patch/

This causes pip install errors because of the interaction with another
Debian patch [2]. This includes all /share/python-wheels/*.whl
files into sys.path.

[2] 
https://sources.debian.org/src/python-pip/9.0.1-2/debian/patches/debundle.patch/

The result is that "import wheel" works in pip's context (from
/share/python-wheels) but it does not in other python program or
lib that does not include /share/python-wheels/*.whl in its
sys.path.

Here is how to reproduce the problem:

$ virtualenv --no-wheel ./venv
Running virtualenv with interpreter /usr/bin/python2
New python executable in ./venv/bin/python2
Also creating executable in ./venv/bin/python
Installing setuptools, pkg_resources, pip...done.
$ rm -rf ~/.cache/pip
$ ./venv/bin/pip install future
Collecting future
  Downloading future-0.16.0.tar.gz (824kB)
100% || 829kB 1.6MB/s
Building wheels for collected packages: future
  Running setup.py bdist_wheel for future ... error
  Complete output from command ./venv/bin/python2 -u -c "import setuptools, 
tokenize;__file__='/tmp/pip-build-OCcj3b/future/setup.py';f=getattr(tokenize, 
'open', open)(__file__);code=f.read().replace('\r\n', 
'\n');f.close();exec(compile(code, __file__, 'exec'))" bdist_wheel -d 
/tmp/tmpTT25xXpip-wheel- --python-tag cp27:
  usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
 or: -c --help [cmd1 cmd2 ...]
 or: -c --help-commands
 or: -c cmd --help

  error: invalid command 'bdist_wheel'

  
  Failed building wheel for future
  Running setup.py clean for future
Failed to build future
Installing collected packages: future
  Running setup.py install for future ... done
Successfully installed future-0.16.0

A thorough analysis reveals that when "import wheel" works here [3],
this code [4] is executed which in turn executes `./setup.py
bdist_wheel` in a subprocess [5]. Since sys.path is not preserved with
fork+exec, wheel is not available for the setup.py command which fails.

[3] https://github.com/pypa/pip/blob/9.0.1/pip/commands/install.py#L10
[4] https://github.com/pypa/pip/blob/9.0.1/pip/commands/install.py#L335
[5] https://github.com/pypa/pip/blob/9.0.1/pip/wheel.py#L710

Surprisingly, pip does not crash. It ignores the error and installs
directly from source instead. Still, this should be fixed.

I suggest that when virtualenv is executed with --no-wheel, the
wheel-*.whl file should *not* be copied into /share/python-wheels.

Here is an example patch:

---
 virtualenv.py | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/virtualenv.py b/virtualenv.py
index 61fe5448682e..ab9d9b1c2b37 100755
--- a/virtualenv.py
+++ b/virtualenv.py
@@ -961,6 +961,12 @@ def create_environment(home_dir, site_packages=False, 
clear=False,
 if error.errno != errno.EEXIST:
 raise
 for project in DEBIAN_WHEEL_DEPS:
+if no_wheel and project == 'wheel':
+continue
 wheel_names = glob.glob(
 '/usr/share/python-wheels/{0}-*.whl'.format(project))
 if len(wheel_names) == 0:

-- 
Robin



Bug#883529: ITA: buildbot,buildbot-slave -- Build automation system

2017-12-13 Thread Robin Jarry
retitle 883529 ITA: buildbot,buildbot-slave -- Build automation system
owner 883529 !
thanks

Hi,

I am willing to adopt both buildbot and buildbot-slave (which should maybe
be renamed to buildbot-worker).

Cheers,

-- 
Robin