Timo Aaltonen pushed to branch debian-unstable at X Strike Force / lib / mesa
Commits: 7475d772 by Emil Velikov at 2019-01-31T21:08:36Z docs: add sha256 checksums for 18.3.3 Signed-off-by: Emil Velikov <[email protected]> - - - - - 434f19a8 by Rob Clark at 2019-02-12T12:52:32Z freedreno: stop frob'ing pipe_resource::nr_samples Previously we tried to normalize nr_samples to MAX2(1, nr_samples) to avoid having to deal with 0 vs 1 everywhere. But this causes problems in mesa/st, for example st_finalize_texture() will think there is a nr_samples mismatch and recreate the texture. Somehow this manifests as corrupt x11 font rendering on generations that do not support MSAA (but apparently works fine on a5xx and a6xx which do support MSAA.) Fixes: cf0c7258ee0 freedreno/a5xx: MSAA Signed-off-by: Rob Clark <[email protected]> (cherry picked from commit c3baa077bf6db9f9d46be62ed7cbbc3167e68c8f) [Emil Velikov: resolve trivial conflicts] Signed-off-by: Emil Velikov <[email protected]> Conflicts: src/gallium/drivers/freedreno/freedreno_batch_cache.c - - - - - 6beaa2d7 by Jason Ekstrand at 2019-02-12T12:53:06Z intel/fs: Handle IMAGE_SIZE in size_read() and is_send_from_grf() Like all the other sends, it's just mlen * REG_SIZE. Fixes: 3cbc02e4693 "intel: Use TXS for image_size when we have..." Reviewed-by: Iago Toral Quiroga <[email protected]> (cherry picked from commit cf42b0f9e2d2d612f92b24ec8a5a77ff107b92ab) - - - - - 1a2b227f by Ernestas Kulik at 2019-02-12T12:53:09Z vc4: Fix leak in HW queries error path Reported by Coverity: in the case where there exist hardware and non-hardware queries, the code does not jump to err_free_query and leaks the query. CID: 1430194 Signed-off-by: Ernestas Kulik <[email protected]> Fixes: 9ea90ffb98fb ("broadcom/vc4: Add support for HW perfmon") (cherry picked from commit f6e49d5ad0fde19a074644491475470d684dd721) - - - - - e0eba40a by Ernestas Kulik at 2019-02-12T12:53:12Z v3d: Fix leak in resource setup error path Reported by Coverity: in the case of unsupported modifier request, the code does not jump to the “fail” label to destroy the acquired resource. CID: 1435704 Signed-off-by: Ernestas Kulik <[email protected]> Fixes: 45bb8f295710 ("broadcom: Add V3D 3.3 gallium driver called "vc5", for BCM7268.") (cherry picked from commit 90458bef544ac46a912f06e73f71c3cb20fdaaf6) - - - - - 7bf9cf29 by Jason Ekstrand at 2019-02-12T12:53:14Z intel/fs: Do the grf127 hack on SIMD8 instructions in SIMD16 mode Previously, we only applied the fix to shaders with a dispatch mode of SIMD8 but the code it relies on for SIMD16 mode only applies to SIMD16 instructions. If you have a SIMD8 instruction in a SIMD16 shader, neither would trigger and the restriction could still be hit. Fixes: 232ed8980217dd "i965/fs: Register allocator shoudn't use grf127..." Reviewed-by: Jose Maria Casanova Crespo <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> (cherry picked from commit b4f0d062cd12b4f675bac900ac41d1085a79239a) - - - - - a19ddce9 by Marek Olšák at 2019-02-12T12:53:18Z meson: drop the xcb-xrandr version requirement autotools doesn't have any requirement. This fixes meson on Ubuntu 16.04. Cc: 18.3 19.0 <[email protected]> Reviewed-by: Erik Faye-Lund <[email protected]> (cherry picked from commit 1e85cfb91a08565f28f51cc19573324722765823) - - - - - e868c776 by Emil Velikov at 2019-02-14T12:28:28Z cherry-ignore: nv50,nvc0: add explicit settings for recent caps stable Explicit 19.0 only nomination. Signed-off-by: Emil Velikov <[email protected]> - - - - - fdb66dd1 by Bart Oldeman at 2019-02-14T12:28:47Z gallium-xlib: query MIT-SHM before using it. When Mesa is compiled for gallium-xlib using e.g. ./configure --enable-glx=gallium-xlib --disable-dri --disable-gbm -disable-egl and is used by an X server (usually remotely via SSH X11 forwarding) that does not support MIT-SHM such as XMing or MobaXterm, OpenGL clients report error messages such as Xlib: extension "MIT-SHM" missing on display "localhost:11.0". ad infinitum. The reason is that the code in src/gallium/winsys/sw/xlib uses MIT-SHM without checking for its existence, unlike the code in src/glx/drisw_glx.c and src/mesa/drivers/x11/xm_api.c. I copied the same check using XQueryExtension, and tested with glxgears on MobaXterm. This issue was reported before here: https://lists.freedesktop.org/archives/mesa-users/2016-July/001183.html Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Cc: <[email protected]> (cherry picked from commit a203eaa4f4fb672b95426289b8dad3a8998f92d7) - - - - - 2180aa1b by Eric Engestrom at 2019-02-14T12:28:47Z xvmc: fix string comparison Fixes: c7b65dcaffeb9d0760c8 "xvmc: Define some Xv attribs to allow users to specify color standard and procamp" Cc: Christian König <[email protected]> Signed-off-by: Eric Engestrom <[email protected]> (cherry picked from commit 110a6e1839bcf31e3592389ad55a7ba07b551965) - - - - - 45c3bf14 by Eric Engestrom at 2019-02-14T12:28:47Z xvmc: fix string comparison Fixes: 6fca18696d0e6a243f6f "g3dvl: Update XvMC unit tests." Cc: Younes Manton <[email protected]> Signed-off-by: Eric Engestrom <[email protected]> (cherry picked from commit 40b53a72033a601ab474c5f8e27eb5ca2c8bad6c) - - - - - f04d57ff by Bas Nieuwenhuizen at 2019-02-14T12:28:47Z radv: Only look at pImmutableSamples if the descriptor has a sampler. Equivalent of ANV patch c7f4a2867ce492d78c1f8e2870c0a593d280572d CC: <[email protected]> Reviewed-by: Samuel Pitoiset <[email protected]> (cherry picked from commit 39ab4e12f71a640b43403a110d3d85565b59d16c) - - - - - 08834a37 by Bas Nieuwenhuizen at 2019-02-14T12:28:47Z amd/common: Use correct writemask for shared memory stores. The check was for 1 bit being set, which is clearly not what we want. CC: <[email protected]> Reviewed-by: Samuel Pitoiset <[email protected]> (cherry picked from commit 3c24fc64c7a4e564d84843fab7db25963d574d99) - - - - - fb63b1b3 by Kristian H. Kristensen at 2019-02-14T12:28:47Z freedreno/a6xx: Emit blitter dst with OUT_RELOCW We're writing to the bo and the kernel needs to know for fd_bo_cpu_prep() to work. Fixes: f93e43127252679b ("freedreno/a6xx: Enable blitter") Reviewed-by: Rob Clark <[email protected]> Signed-off-by: Kristian H. Kristensen <[email protected]> (cherry picked from commit 357ea7da51a2392eb1b7f464ff99cbe8e98378e2) - - - - - 541eb984 by Emil Velikov at 2019-02-15T11:38:13Z cherry-ignore: add more 19.0 only nominations from Ilia Signed-off-by: Emil Velikov <[email protected]> - - - - - a9c0e146 by Ilia Mirkin at 2019-02-15T11:38:47Z nvc0: we have 16k-sized framebuffers, fix default scissors For some reason we don't use view volume clipping by default, and use scissors instead. These scissors were set to an 8k max fb size, while the driver advertises 16k-sized framebuffers. Signed-off-by: Ilia Mirkin <[email protected]> Cc: <[email protected]> (cherry picked from commit cc79a1483ffb7b91edc97c9870eadcab1e83b8f3) - - - - - 35459869 by Jason Ekstrand at 2019-02-15T11:38:47Z nir/deref: Rematerialize parents in rematerialize_derefs_in_use_blocks When nir_rematerialize_derefs_in_use_blocks_impl was first written, I attempted to optimize things a bit by not bothering to re-materialize the sources of deref instructions figuring that the final caller would take care of that. However, in the case of more complex deref chains where the first link or two lives in block A and then another link and the load/store_deref intrinsic live in block B it doesn't work. The code in rematerialize_deref_in_block looks at the tail of the chain, sees that it's already in block B and skips it, not realizing that part of the chain also lives in block A. The easy solution here is to just rematerialize deref sources of deref instructions as well. This may potentially lead to a few more deref instructions being created by the conditions required for that to actually happen are fairly unlikely and, thanks to the caching, it's all linear time regardless. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109603 Fixes: 7d1d1208c2b "nir: Add a small pass to rematerialize derefs per-block" Reviewed-by: Alejandro Piñeiro <[email protected]> (cherry picked from commit 9e6a6ef0d45a5bb61a541c495fe12e54e646ecfe) - - - - - b3b0a97f by Marek Olšák at 2019-02-15T11:38:47Z gallium/u_threaded: fix EXPLICIT_FLUSH for flush offsets > 0 Cc: 18.3 19.0 <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]> (cherry picked from commit 4522f01d4ef9e8a1bb945ca28fba7649aae2171b) - - - - - 945aa874 by Marek Olšák at 2019-02-15T11:38:47Z radeonsi: fix EXPLICIT_FLUSH for flush offsets > 0 Cc: 18.3 19.0 <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]> (cherry picked from commit 61c678d4bc91d2ff9ca8c9b183e08daf07d8d24c) - - - - - f1eccd09 by Marek Olšák at 2019-02-15T11:38:47Z winsys/amdgpu: don't drop manually added fence dependencies wow, it's hard to believe that fence and syncobjs dependencies were ignored. Cc: 18.3 19.0 <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]> (cherry picked from commit ddfe209a0d61917e7b08100eeac82f4c20ca59e8) - - - - - 36258308 by Leo Liu at 2019-02-15T11:38:47Z st/va: fix the incorrect max profiles report Add "PIPE_VIDEO_PROFILE_MAX" to enum, so it will make sure here will be correct when adding more profiles in the future. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109107 Signed-off-by: Leo Liu <[email protected]> Reviewed-by: Boyuan Zhang <[email protected]> Cc: 19.0 <[email protected]> (cherry picked from commit 21cdb828a3f4d1e2f140fc7c81a4bc305b2f6b04) - - - - - dafa02c9 by Leo Liu at 2019-02-15T11:39:21Z st/va/vp9: set max reference as default of VP9 reference number If there is no information about number of render targets Signed-off-by: Leo Liu <[email protected]> Reviewed-by: Boyuan Zhang <[email protected]> Cc: 19.0 <[email protected]> (cherry picked from commit a0a52a036708dbf5989778795fd67a79e3226289) - - - - - 75340edb by Kenneth Graunke at 2019-02-15T11:39:41Z st/mesa: Limit GL_MAX_[NATIVE_]PROGRAM_PARAMETERS_ARB to 2048 Piglit's vp-max-array test creates a vertex program containing a uniform array sized to the value of GL_MAX_NATIVE_PROGRAM_PARAMETERS_ARB. Mesa will then add additional state-var parameters for things like the MVP matrix. radeonsi currently exposes a value of 4096, derived from constant buffer upload size. This means the array will have 4096 elements, and the extra MVP state-vars would get a prog_src_register::Index of over 4096. Unfortunately, prog_src_register::Index is a signed 13-bit integer, so values beyond 4096 end up turning into negative numbers. Negative source indexes are only valid for relative addressing, so this ends up generating illegal IR. In prog_to_nir, this would cause an out of bounds array access. st_mesa_to_tgsi checks for a negative value, assumes it's bogus, and remaps it to parameter 0 in order to get something in-range. This isn't right - instead of reading the MVP matrix, it would read the first element of the vertex program's large array. But the test only checks that the program compiles, so we never noticed that it was broken. This patch limits the size of the program limits, with the understanding that we may need to generate additional state-vars internally. i965 has exposed 1024 for this limit for years, so I don't expect lowering it to 2048 will cause any practical problems for radeonsi or other drivers. Fixes vp-max-array with prog_to_nir.c. Cc: "19.0" <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Eric Anholt <[email protected]> (cherry picked from commit f45dd6d31b2ff46a082931386ccd0bf043cfad59) - - - - - 5694279c by Samuel Pitoiset at 2019-02-15T11:39:41Z radv: fix compiler issues with GCC 9 "The C standard says that compound literals which occur inside of the body of a function have automatic storage duration associated with the enclosing block. Older GCC releases were putting such compound literals into the scope of the whole function, so their lifetime actually ended at the end of containing function. This has been fixed in GCC 9. Code that relied on this extended lifetime needs to be fixed, move the compound literals to whatever scope they need to accessible in." Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109543 Cc: <[email protected]> Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Gustaw Smolarczyk <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]> (cherry picked from commit 129a9f4937b8f2adb4d37999677d748d816d611c) - - - - - f036a040 by Iago Toral Quiroga at 2019-02-15T11:39:41Z intel/compiler: do not copy-propagate strided regions to ddx/ddy arguments The implementation of these opcodes in the generator assumes that their arguments are packed, and it generates register regions based on that assumption. Reviewed-by: Jason Ekstrand <[email protected]> (cherry picked from commit 391894321161b37a3f8ae1cae4ece6c72ea38bc1) - - - - - ecad528a by Mario Kleiner at 2019-02-15T11:39:41Z egl/wayland: Allow client->server format conversion for PRIME offload. (v2) Support PRIME render offload between a Wayland server gpu and a Wayland client gpu with different channel ordering for their color formats, e.g., between Intel drivers which currently only support ARGB2101010 and XRGB2101010 import/display and nouveau which only supports ABGR2101010 rendering and display on nv-50 and later. In the wl_visuals table, we also store for each format an alternate sibling format which stores colors at the same precision, but with different channel ordering, e.g., ARGB2101010 <-> ABGR2101010. If a given client-gpu renderable format is not supported by the server for import, but the alternate format is supported by the server, expose the client-gpu renderable format as a valid EGLConfig to the client. At eglSwapBuffers time, during the blitImage() detiling blit from the client backbuffer to the linear buffer, the client format is converted to the server supported format. As we have to do a copy for PRIME anyway, this channel swizzling conversion comes essentially for free. Note that even if a server gpu in principle does support sampling from the clients native format, this conversion will be a performance advantage if it allows to convert to the servers preferred format for direct scanout, as the Wayland compositor may then be able to directly page-flip a fullscreen client wl_buffer onto the primary plane, or onto a hardware overlay plane, avoiding an extra data copy for desktop composition. Tested so far under Weston with: nouveau single-gpu, Intel single-gpu, AMD single-gpu, "Optimus" Intel server iGPU for display + NVidia client dGPU for rendering. v2: Implement minor review comments by Eric Engestrom: Add some comment and assert, and some style fixes for clarity. No functional change. Signed-off-by: Mario Kleiner <[email protected]> Reviewed-by: Adam Jackson <[email protected]> Reviewed-by: Daniel Stone <[email protected]> (cherry picked from commit a34b0d68bbf8571e4d858cf4e1176766a50364de) - - - - - d3f49ece by Mario Kleiner at 2019-02-15T11:39:41Z egl/wayland-drm: Only announce formats via wl_drm which the driver supports. Check if a pixel format is supported by the Wayland servers gpu driver before exposing it to the client via wl_drm, so we avoid reporting formats to the client which the server gpu can't handle. Restrict this reporting to the new color depth 30 formats for now, as the ARGB/XRGB8888 and RGB565 formats are probably supported by every gpu under the sun. Atm. this is mostly useful to allow proper PRIME renderoffload for depth 30 formats on the typical Intel iGPU + NVidia dGPU "NVidia Optimus" laptop combo. Tested on Intel, AMD, NVidia with single-gpu setup and on a Intel + NVidia Optimus setup. Signed-off-by: Mario Kleiner <[email protected]> Reviewed-by: Adam Jackson <[email protected]> Reviewed-by: Daniel Stone <[email protected]> (cherry picked from commit 820dfcea431e4f96f25e6b340edd9cd1e449158b) - - - - - 5b48a260 by Rodrigo Vivi at 2019-02-15T11:39:41Z intel: Add more PCI Device IDs for Coffee Lake and Ice Lake. Align with kernel commits: 5e0f5a58b167 ("drm/i915/cfl: Adding another PCI Device ID.") 03ca3cf8e9aa ("drm/i915/icl: Adding few more device IDs for Ice Lake") Cc: José Roberto de Souza <[email protected]> Cc: Kenneth Graunke <[email protected]> Cc: Anuj Phogat <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]> (cherry picked from commit 56c3b4971d44748ad8618efdf8833ec2f9af4078) - - - - - 6cea56e2 by Emil Velikov at 2019-02-15T11:40:09Z cherry-ignore: radv: fix using LOAD_CONTEXT_REG with old GFX ME firmwares on GFX8 stable The commit addresses functionality not present in branch. Signed-off-by: Emil Velikov <[email protected]> - - - - - 7662965c by Juan A. Suarez Romero at 2019-02-15T11:40:11Z anv/cmd_buffer: check for NULL framebuffer This can happen when we record a VkCmdDraw in a secondary buffer that was created inheriting from the primary buffer, but with the framebuffer set to NULL in the VkCommandBufferInheritanceInfo. Vulkan 1.1.81 spec says that "the application must ensure (using scissor if neccesary) that all rendering is contained in the render area [...] [which] must be contained within the framebuffer dimesions". While this should be done by the application, commit 465e5a86 added the clamp to the framebuffer size, in case of application does not do it. But this requires to know the framebuffer dimensions. If we do not have a framebuffer at that moment, the best compromise we can do is to just apply the scissor as it is, and let the application to ensure the rendering is contained in the render area. v2: do not clamp to framebuffer if there isn't a framebuffer v3 (Jason): - clamp earlier in the conditional - clamp to render area if command buffer is primary v4: clamp also x and y to render area (Jason) v5: rename used variables (Jason) Fixes: 465e5a86 ("anv: Clamp scissors to the framebuffer boundary") CC: Jason Ekstrand <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> (cherry picked from commit 1ad26f941792f07f226c054811be78b0c0ac9fce) - - - - - 4bb51927 by Oscar Blumberg at 2019-02-15T11:40:11Z radeonsi: Fix guardband computation for large render targets Stop using 12.12 quantization for viewports that are not contained in the lower 4k corner of the render target as the hardware needs to keep both absolute and relative coordinates representable. Signed-off-by: Marek Olšák <[email protected]> Cc: 18.3 19.0 <[email protected]> (cherry picked from commit 3c540e0a748844258e77254fc4f864f3b875fe18) - - - - - 08ab660b by Dylan Baker at 2019-02-15T11:40:11Z get-pick-list: Add --pretty=medium to the arguments for Cc patches Because none of them have been picked up for 19.0 due to this bug being reintroduced. v2: - Fix fixes tags Fixes: e6b3a3b2014413366110f6deeced8095e7262b1d ("bin/get-pick-list.sh: handle "typod" usecase.") Fixes: fac10169bbad2da918ef07a62c01e0b321508cfe ("bin/get-pick-list.sh: prefix output with "[stable] "") Reviewed-by: Andres Gomez <[email protected]> Reviewed-by: Emil Velikov <[email protected]> (cherry picked from commit aff52dd2c61eb8d1b03cebbcca7e070ffa48afdf) - - - - - 4aa92b54 by Samuel Pitoiset at 2019-02-15T11:40:11Z radv: always export gl_SampleMask when the fragment shader uses it For some reasons, this breaks trees rendering in Project Cars. Fixes: 85010585cde ("radv: only enable gl_SampleMask if MSAA is enabled too") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109401 Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]> (cherry picked from commit 334da034d8d91ca5a0a1bff8deaefd8ca762c42e) - - - - - d000488c by Dylan Baker at 2019-02-15T11:40:11Z meson: Add dependency on genxml to anvil Currently the Intel "anvil" driver races with the generation of genxml files, while i965 has an explicit dependency. This patch adds the same dependency to anvil. Fixes: d1992255bb29054fa51763376d125183a9f602f ("meson: Add build Intel "anv" vulkan driver") Acked-by: Jason Ekstrand <[email protected]> Acked-by: Lionel Landwerlin <[email protected]> Reviewed-by: Eric Engestrom <[email protected]> (cherry picked from commit 279060cd32dd673c6a5bf302ceac852f51a6c17c) - - - - - 55f3a4fa by Eric Anholt at 2019-02-16T13:46:37Z vc4: Fix copy-and-paste fail in backport of NEON asm fixes. One of the cpu pointers wasn't marked as read-write, causing gcc to complain: ../src/gallium/drivers/vc4/vc4_tiling_lt.c:181:17: error: output operand constraint lacks ‘=’ __asm__ volatile ( Cc: Emil Velikov <[email protected]> Fixes: 813f0a82960 ("vc4: Declare the cpu pointers as being modified in NEON asm.") - - - - - a41881fc by Emil Velikov at 2019-02-18T18:19:54Z Update version to 18.3.4 Signed-off-by: Emil Velikov <[email protected]> - - - - - b26488de by Emil Velikov at 2019-02-18T18:23:55Z docs: add release notes for 18.3.4 Signed-off-by: Emil Velikov <[email protected]> - - - - - fd9d7553 by Timo Aaltonen at 2019-02-19T08:29:11Z Merge branch 'upstream-unstable' into debian-unstable - - - - - 0e3a30d6 by Timo Aaltonen at 2019-02-19T08:33:16Z bump the version - - - - - 00b54f84 by Timo Aaltonen at 2019-02-19T09:02:54Z release to sid - - - - - 30 changed files: - VERSION - bin/.cherry-ignore - bin/get-pick-list.sh - debian/changelog - docs/relnotes/18.3.3.html - + docs/relnotes/18.3.4.html - include/pci_ids/i965_pci_ids.h - meson.build - src/amd/common/ac_nir_to_llvm.c - src/amd/vulkan/radv_descriptor_set.c - src/amd/vulkan/radv_meta_blit.c - src/amd/vulkan/radv_pipeline.c - src/compiler/nir/nir_deref.c - src/egl/drivers/dri2/egl_dri2.c - src/egl/drivers/dri2/egl_dri2.h - src/egl/drivers/dri2/platform_wayland.c - src/egl/wayland/wayland-drm/wayland-drm.c - src/egl/wayland/wayland-drm/wayland-drm.h - src/gallium/auxiliary/util/u_threaded_context.c - src/gallium/drivers/freedreno/a6xx/fd6_blitter.c - src/gallium/drivers/freedreno/freedreno_resource.c - src/gallium/drivers/freedreno/freedreno_resource.h - src/gallium/drivers/freedreno/freedreno_texture.c - src/gallium/drivers/nouveau/nvc0/nvc0_screen.c - src/gallium/drivers/radeonsi/si_buffer.c - src/gallium/drivers/radeonsi/si_state_viewport.c - src/gallium/drivers/v3d/v3d_resource.c - src/gallium/drivers/vc4/vc4_query.c - src/gallium/drivers/vc4/vc4_tiling_lt.c - src/gallium/include/pipe/p_video_enums.h The diff was not included because it is too large. View it on GitLab: https://salsa.debian.org/xorg-team/lib/mesa/compare/b1517248e1f11d6384f459dc95d9e368537751f1...00b54f84c7dfcc08c99a19325a3de00cdbea65a4 -- View it on GitLab: https://salsa.debian.org/xorg-team/lib/mesa/compare/b1517248e1f11d6384f459dc95d9e368537751f1...00b54f84c7dfcc08c99a19325a3de00cdbea65a4 You're receiving this email because of your account on salsa.debian.org.
