Bug#1064881: ITP: golang-github-soniakeys-quant -- An interface for image color quantizers.
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
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
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
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
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
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
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
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
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
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
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
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
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 --
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?
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?
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?
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
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
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'
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
Control: reassign -1 src:migrate 0.11.0-4 Control: affects -1 src:buildbot
Bug#916922: buildbot: FTBFS: test failures
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
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
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
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-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
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-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
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
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
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
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