[Git][archlinux/packaging/packages/xz][main] update upstream and source url
Christian Hesse pushed to branch main at Arch Linux / Packaging / Packages / xz
Commits:
f70de467 by Christian Hesse at 2024-06-04T13:01:23+02:00
update upstream and source url
https://github.com/tukaani-project/xz
Fixes: https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/issues/6
- - - - -
2 changed files:
- .SRCINFO
- PKGBUILD
Changes:
=
.SRCINFO
=
@@ -2,7 +2,7 @@ pkgbase = xz
pkgdesc = Library and command line tools for XZ and LZMA compressed
files
pkgver = 5.6.2
pkgrel = 1
- url = https://xz.tukaani.org/xz-utils/
+ url = https://tukaani.org/xz/
arch = x86_64
license = GPL
license = LGPL
@@ -12,7 +12,7 @@ pkgbase = xz
makedepends = doxygen
depends = sh
provides = liblzma.so
- source = git+https://git.tukaani.org/xz.git#tag=v5.6.2
+ source = git+https://github.com/tukaani-project/xz#tag=v5.6.2
validpgpkeys = 3690C240CE51B4670D30AD1C38EE757D69184620
sha256sums =
a71fcf56faa1f7d9e9708ca8d6a97906b929307d6a98d220018852eef37853c8
sha512sums =
f369f126dd3d538ef27ecce62e8ae01a2c9056eeb22c6b21d9a1d5e456f35330bc7f2bb0df525ad4a4f95ba84c0196c7c79ad768359786d3a73f876aa043f164
=
PKGBUILD
=
@@ -6,13 +6,13 @@ pkgver=5.6.2
pkgrel=1
pkgdesc='Library and command line tools for XZ and LZMA compressed files'
arch=('x86_64')
-url='https://xz.tukaani.org/xz-utils/'
+url='https://tukaani.org/xz/'
license=('GPL' 'LGPL' 'custom')
depends=('sh')
makedepends=('git' 'po4a' 'doxygen')
provides=('liblzma.so')
validpgpkeys=('3690C240CE51B4670D30AD1C38EE757D69184620') # Lasse Collin
-source=("git+https://git.tukaani.org/xz.git#tag=v${pkgver};)
+source=("git+https://github.com/tukaani-project/xz#tag=v${pkgver};)
sha256sums=('a71fcf56faa1f7d9e9708ca8d6a97906b929307d6a98d220018852eef37853c8')
sha512sums=('f369f126dd3d538ef27ecce62e8ae01a2c9056eeb22c6b21d9a1d5e456f35330bc7f2bb0df525ad4a4f95ba84c0196c7c79ad768359786d3a73f876aa043f164')
View it on GitLab:
https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/commit/f70de467701b94373fb79c8015416e354fb165cc
--
View it on GitLab:
https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/commit/f70de467701b94373fb79c8015416e354fb165cc
You're receiving this email because of your account on gitlab.archlinux.org.
translations.git: Changes to 'refs/tags/libreoffice-24.2.4.2'
Tag 'libreoffice-24.2.4.2' created by Christian Lohmaier at 2024-06-04 10:40 + Tag libreoffice-24.2.4.2 -BEGIN PGP SIGNATURE- iQIzBAABCAAdFiEEwoOeytlAj76VMcPp9DSh76/urqMFAmZe7zYACgkQ9DSh76/u rqOq3g//UrkYTpwqPh0Y70JPY688CQpVPAxODJGgEFd6dPOcdXKBV0ZFlmiqV0Sz Sk18GbYrH+GuNNdL6VUK35KAhZ7Kwky/C8T+vxcvFbsTit8outLuW23+fB6ocenF hMYeT1LuvMjlZ6lXPTtoM/CHAst03pXP9bla5XNybMgnSUyG0aNGRlW1MInM8cHA rXJVG5VwnW4gBf6rVRTf+7Fp85D2yZDiqirBxilQ9G1igjDvxQ8GT3DPMSp7Y17c bJCmo9bCR4m8yoDHkfwbxIdEpxUOudsp9zmLJaODo4v7PhMGtpLQpHrWhkCTmij/ paPHTs/afNN62y+YEKgab6tzF/OwU8ovcqWs9zfRc1XNRittu19NIfzM7friqXM3 rljLKuqadti1tFZqSgk4gBLIjpIuwHPbf3Y5luTUw4ajCoh5PeyStjaUHgP3640h HA3wfqS1q5N8pg4zf4DMFbqaA1fy4d08e1ajUAhy96Vn5Ug8UdHA8r73C1/Cygri a/Gk4JXJIgetXhZszHDjxgeTvb9sTd3M7Q0RZLGbjrqPXHEeL4m73uI7rUaARZ1q cwHGvrue7c1iEIvp+/yYaU5tgOkOeIP5c0UeH7hYs6316w3RUO+nNWeGf76SBhgV hLpzEjXDspcGdphCfdfhyThHOJWVuytxBDOe1/jngkRe61bEys8= =8+lw -END PGP SIGNATURE- Changes since cp-24.04.0-1-12: --- 0 files changed ---
help.git: Changes to 'refs/tags/libreoffice-24.2.4.2'
Tag 'libreoffice-24.2.4.2' created by Christian Lohmaier at 2024-06-04 10:40 + Tag libreoffice-24.2.4.2 -BEGIN PGP SIGNATURE- iQIzBAABCAAdFiEEwoOeytlAj76VMcPp9DSh76/urqMFAmZe7zYACgkQ9DSh76/u rqNDBA/9F9HD9AH7kGSFRH4qs0zyPv9jHcbhywxK906Cf21fZhwT8CfFpyDxzoic qBELuIvUiCh8ibidZDAw1slzHx2xK8DnsGvxJFT03gxbUVJe0sPSuIjsSAcVvk8i A3hqyHZaQhG9rXzHSxILCbnWwCRKl64jU7/pIMmmFvaEAg/SqI/G9bCsPvpCRmzn 4A2tZsTT7lW6XbZ3gN/e7IlXBp1njD0FqsR1hnFwMDcMFNMkqCs+sFBwbWtQTTfQ AZGZxNvzvB4ZaiqD2kVIxyvWMHi4NSIB8gBp98p6TFoQo71bQQGrxBst8S1jtahR XunZ/re04gmu5rz38qNxVg/hhYSpZr/nbj2J8TbTH+QAr234utU/1216I1nAqbtI crJ//pY0J6Rnqv9FKZ3TpSFVmEQvH2asVQ5bLbzlFvuRqvaJR/AMeQDiOjWsDsvd fkMEqOSeE0TeRzjNwR1VxreBCk8RUzbK4H5qeKfwf3ShSGmGsDEU7Gvf73UYbB44 /+G3oI7IcVCz/0N2x74udwjogXt82ECrmNThbTKTeXIiB9YM3sZsUDKiCIuX97Wy BS+WonEfax39e8JzPcZ4mcjFagSsNTE1f36/o104K0fuSYOYVTcnC+oWwtVqq6Qa Iq0jPJ590JV1zVZvJ5kNddDujWarIG/V2bAUIk7hESNCjwt9dqQ= =qs19 -END PGP SIGNATURE- Changes since co-24.04-branch-point-15: --- 0 files changed ---
dictionaries.git: Changes to 'refs/tags/libreoffice-24.2.4.2'
Tag 'libreoffice-24.2.4.2' created by Christian Lohmaier at 2024-06-04 10:40 + Tag libreoffice-24.2.4.2 -BEGIN PGP SIGNATURE- iQIzBAABCAAdFiEEwoOeytlAj76VMcPp9DSh76/urqMFAmZe7zMACgkQ9DSh76/u rqN60Q//QB3DyP4lED7ItUW87L+aeCT3Be7ApUvyLDjpNp0Fi24pz93LU/20Fmix SooSSO574yBR3XdWcWaPTHlf7ZXYtOrCxxhNV1cWyuYqw1qbxin3lMjNXeJiQdfS awYqPjLvbSSUgOohUPGq2y6jAFSlhk9bO6GUrJ0350aBaiVcGEfgAzNDcw+HG/rP ay+6d4iCLlBY4I/AIL7ETGQyHZYe24HjAPPt28EAbhfq7cF0TBLmgLBhCPW56y+4 uY1wVkNms6PScPuZPK8YBs0OWvh88g56D/h38mwRFvdbQn3r9TTLdIfxwCLXCrTd m04VGEoPDy0sD+sS/apSTXldLi2nZtdbqmzncLtShlATfe70JuA87VrFg53HWmMC CU/BzJ1PTeyiXeUrmruRsFB5lZkDuA4buYSCxzKgQ43TBQlkT333Mzl79D0Pf42p ho8xt2Azsj0GGEpEeNBzYP06W4648qsNnd5TNrkCuOP85HHAuBovWFzQNGFZiTKM rOTnc8juNY8K239RLVN+GPU0EQdKKGTPg19rRmlH+v3c+Z502+9YOm+dBcIUaY7c Ccyh/8BdTz+sWxZk4ystdHG/+xCs6Y2SmHanp9RBctqGecMG3E6iGYXe14VU/Wq6 GKdal4IVxRsUToj0XVC22/rO5WYtOPbzYPXjcaEdpxPAYkCCcDs= =IdJ+ -END PGP SIGNATURE- Changes since cp-24.04.1-2-5: --- 0 files changed ---
core.git: Branch 'libreoffice-24-2-4' - configure.ac
configure.ac |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) New commits: commit 7897b6c55f863411d5d0d3fa61f4da37618dd22f Author: Christian Lohmaier AuthorDate: Tue Jun 4 12:41:17 2024 +0200 Commit: Christian Lohmaier CommitDate: Tue Jun 4 12:41:17 2024 +0200 bump product version to 24.2.4.2.0+ Change-Id: I1fce883b881651cd72eaa7f252686dbfafabe1ad diff --git a/configure.ac b/configure.ac index 8fc5f88de3c1..76f11edfe2e3 100644 --- a/configure.ac +++ b/configure.ac @@ -9,7 +9,7 @@ dnl in order to create a configure script. # several non-alphanumeric characters, those are split off and used only for the # ABOUTBOXPRODUCTVERSIONSUFFIX in openoffice.lst. Why that is necessary, no idea. -AC_INIT([LibreOffice],[24.2.4.1.0+],[],[],[http://documentfoundation.org/]) +AC_INIT([LibreOffice],[24.2.4.2.0+],[],[],[http://documentfoundation.org/]) dnl libnumbertext needs autoconf 2.68, but that can pick up autoconf268 just fine if it is installed dnl whereas aclocal (as run by autogen.sh) insists on using autoconf and fails hard
core.git: Changes to 'refs/tags/libreoffice-24.2.4.2'
Tag 'libreoffice-24.2.4.2' created by Christian Lohmaier at 2024-06-04 10:40 + Tag libreoffice-24.2.4.2 -BEGIN PGP SIGNATURE- iQIzBAABCAAdFiEEwoOeytlAj76VMcPp9DSh76/urqMFAmZe7zYACgkQ9DSh76/u rqMt1Q/+IZnYlg56ii3Je7viKRCG0ikABi1eHCHKL4rYoL8++tnL5maJdQGO2dQx cNxTP84F9xBGeBbGunWz2tYGQOn6ZkCyxFkUtfK0EV44AMa+BPB4dy0ImFOxgdrB UvBAhfLw2BOUHoSPbgQGI5Lreqg/YsOCGgTz85AxexCrnDP1YpH4u76p7VW7sEeG oqe0o2eoEEJIEDSditJUtUAwDOb0OkBPTRuzyvcZNEWA3ZimF3OyW09YjghrlkDw DRG5cvmR69ySs3BBUEmXRoXcMvGblXgYi2uKY7R9qB0MFYriBxLJ+lKENX1SnoQA og4eAZUEBppk4k8yM030j2dg0dTUIHzOCcFnkKTmCHMMJ6RpYRYpITQgH+ijj+DS pHBKE6Lw7o8VDeNV65Bfuz+/ZNcXc2D2VduAh/KPPEtCe9mQ5xSeS7Anq6xchOIW 0R4++P9vhgC4na1ImhVtKhHtSL/uin7RRbhkn1W07FwG5SGJoAdOkkrMSxcDJ4Zg mfGnVC2/GUh79MeeS48b+YS42K+DL2wbptqLOgtzAiE4BWN5M+53AUZgpQ7tPKJM Ivku2LEQVI8FWfoL817NDL+vLminhvRDedY2g2XqYrwFkubdQlFb79uQHdG1+D+L Q8+WbhV7P+Fh76Er875txgPMnMyUcdauW1Xda6AF/r4/JUgV8Es= =xwfR -END PGP SIGNATURE- Changes since co-24.04-branch-point-587: --- 0 files changed ---
core.git: Branch 'libreoffice-24-2-4' - translations
translations |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) New commits: commit e3ce5d358dcf7cac002bee7b0c885a3d19859f57 Author: Christian Lohmaier AuthorDate: Tue Jun 4 12:45:55 2024 +0200 Commit: Gerrit Code Review CommitDate: Tue Jun 4 12:45:55 2024 +0200 Update git submodules * Update translations from branch 'libreoffice-24-2-4' to 3357c0b88c8b0d218ccc7c40558a9ee8cd4612ea - update translations for 24.2.4 rc2 and force-fix errors using pocheck Change-Id: Iecf863e23df6934c7fc9125f9eda4ec05c26739f (cherry picked from commit 8bde22939d49fb6cebb30841b269b1625c07eb5a) diff --git a/translations b/translations index f07002ad3f6f..3357c0b88c8b 16 --- a/translations +++ b/translations @@ -1 +1 @@ -Subproject commit f07002ad3f6f59f2808369beec84ace71b5af5fc +Subproject commit 3357c0b88c8b0d218ccc7c40558a9ee8cd4612ea
translations.git: Branch 'libreoffice-24-2-4' - source/ab source/ast source/ca source/da source/de source/es source/fa source/fi source/fr source/gug source/hsb source/ja source/ka source/ko source/nl
| 10 source/ka/cui/messages.po | 10 source/ka/officecfg/registry/data/org/openoffice/Office/UI.po |4 source/ko/cui/messages.po | 38 +- source/ko/extras/source/autocorr/emoji.po | 38 +- source/nl/cui/messages.po |6 source/nl/helpcontent2/source/text/sbasic/shared.po |8 source/nl/helpcontent2/source/text/scalc/01.po| 18 - source/nl/helpcontent2/source/text/scalc/guide.po | 24 - source/nl/helpcontent2/source/text/shared/00.po |8 source/nl/helpcontent2/source/text/shared/01.po |8 source/nl/helpcontent2/source/text/shared/optionen.po | 16 source/nl/sc/messages.po | 36 +- source/nl/scaddins/messages.po|4 source/nl/sfx2/messages.po|6 source/nl/svx/messages.po |6 source/pt-BR/cui/messages.po |6 source/pt-BR/helpcontent2/source/text/shared/guide.po |8 source/pt-BR/readlicense_oo/docs.po | 10 source/sv/helpcontent2/source/text/shared/00.po |8 source/th/sw/messages.po | 20 - 90 files changed, 781 insertions(+), 793 deletions(-) New commits: commit 3357c0b88c8b0d218ccc7c40558a9ee8cd4612ea Author: Christian Lohmaier AuthorDate: Tue Jun 4 12:32:38 2024 +0200 Commit: Christian Lohmaier CommitDate: Tue Jun 4 12:34:43 2024 +0200 update translations for 24.2.4 rc2 and force-fix errors using pocheck Change-Id: Iecf863e23df6934c7fc9125f9eda4ec05c26739f (cherry picked from commit 8bde22939d49fb6cebb30841b269b1625c07eb5a) diff --git a/source/ab/sc/messages.po b/source/ab/sc/messages.po index 99c63d9105a..cf25733b1cc 100644 --- a/source/ab/sc/messages.po +++ b/source/ab/sc/messages.po @@ -4,7 +4,7 @@ msgstr "" "Project-Id-Version: PACKAGE VERSION " "Report-Msgid-Bugs-To: https://bugs.libreoffice.org/enter_bug.cgi?product=LibreOffice_status=UNCONFIRMED=UI " "POT-Creation-Date: 2024-05-31 13:51+0200 " -"PO-Revision-Date: 2024-03-03 16:37+ " +"PO-Revision-Date: 2024-06-01 12:37+ " "Last-Translator: Андрей Абухба " "Language-Team: Abkhazian <https://translations.documentfoundation.org/projects/libo_ui-24-2/scmessages/ab/> " "Language: ab " @@ -13,7 +13,7 @@ msgstr "" "Content-Transfer-Encoding: 8bit " "Plural-Forms: nplurals=2; plural=n != 1; " "X-Accelerator-Marker: ~ " -"X-Generator: LibreOffice " +"X-Generator: Weblate 5.4.3 " "X-POOTLE-MTIME: 1542022333.00 " #. kBovX @@ -7946,7 +7946,7 @@ msgstr "Ахыԥхьаӡара" #: sc/inc/scfuncs.hrc:1456 msgctxt "SC_OPCODE_CEIL_ISO" msgid "The number to be rounded up." -msgstr "" +msgstr "Аҩадахьала ихыркәшахо ахыԥхьаӡара." #. gAmRk #: sc/inc/scfuncs.hrc:1457 @@ -8074,7 +8074,7 @@ msgstr "Аиашара" #: sc/inc/scfuncs.hrc:1492 msgctxt "SC_OPCODE_FLOOR" msgid "The number to whose multiple the value is to be rounded down." -msgstr "" +msgstr "Ахыԥхьаӡара ахьынӡахыркәшахо, ацифрақәа рхыԥхьаӡара." #. CAUCc #: sc/inc/scfuncs.hrc:1493 @@ -8107,7 +8107,7 @@ msgstr "Ахыԥхьаӡара" #: sc/inc/scfuncs.hrc:1502 msgctxt "SC_OPCODE_FLOOR_MS" msgid "The number to be rounded down." -msgstr "" +msgstr "Аладахьала ихыркәшахо ахыԥхьаӡара." #. w4Xsk #: sc/inc/scfuncs.hrc:1503 @@ -8149,7 +8149,7 @@ msgstr "Аиашқәшәара" #: sc/inc/scfuncs.hrc:1514 msgctxt "SC_OPCODE_FLOOR_MATH" msgid "The number to whose multiple the value is to be rounded down." -msgstr "" +msgstr "Ахыԥхьаӡара ахьынӡахыркәшахо, ацифрақәа рхыԥхьаӡара." #. yTCb8 #: sc/inc/scfuncs.hrc:1515 @@ -8210,7 +8210,7 @@ msgstr "" #: sc/inc/scfuncs.hrc:1534 msgctxt "SC_OPCODE_GCD" msgid "Integer 1; integer 2,... are integers for which the greatest common divisor is to be calculated." -msgstr "" +msgstr "Еибгоу ахыԥхаӡара 1; еибгоу ахыԥхаӡара 2,... еибгоу ахыԥхаӡарақәа, ззы азеиԥш шага ԥшаахо." #. 8Bp3W #: sc/inc/scfuncs.hrc:1540 @@ -8264,7 +8264,7 @@ msgstr "Амассив 1" #: sc/inc/scfuncs.hrc:1558 msgctxt "SC_OPCODE_MAT_MULT" msgid "The first array for the array product." -msgstr "" +msgstr "Аматрицақәа рышьҭыхлыҵ аԥшааразы актәи аматрица." #. Ebs87 #: sc/inc/scfuncs.hrc:1559 @@ -8276,13 +8276,13 @@ msgstr "Амассив 2" #: sc/inc/scfunc
core.git: Branch 'libreoffice-24-2' - translations
translations |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) New commits: commit f6e74a4e0f3c3008b0901bcadc4d6ae384b39e02 Author: Christian Lohmaier AuthorDate: Tue Jun 4 12:44:45 2024 +0200 Commit: Gerrit Code Review CommitDate: Tue Jun 4 12:44:45 2024 +0200 Update git submodules * Update translations from branch 'libreoffice-24-2' to 8bde22939d49fb6cebb30841b269b1625c07eb5a - update translations for 24.2.4 rc2 and force-fix errors using pocheck Change-Id: Iecf863e23df6934c7fc9125f9eda4ec05c26739f diff --git a/translations b/translations index 70127e22568e..8bde22939d49 16 --- a/translations +++ b/translations @@ -1 +1 @@ -Subproject commit 70127e22568ed8e3993d85ab681f8e23b2bf1e0b +Subproject commit 8bde22939d49fb6cebb30841b269b1625c07eb5a
translations.git: Branch 'libreoffice-24-2' - source/ab source/ast source/ca source/da source/de source/es source/fa source/fi source/fr source/gug source/hsb source/ja source/ka source/ko source/nl s
| 10 source/ka/cui/messages.po | 10 source/ka/officecfg/registry/data/org/openoffice/Office/UI.po |4 source/ko/cui/messages.po | 38 +- source/ko/extras/source/autocorr/emoji.po | 38 +- source/nl/cui/messages.po |6 source/nl/helpcontent2/source/text/sbasic/shared.po |8 source/nl/helpcontent2/source/text/scalc/01.po| 18 - source/nl/helpcontent2/source/text/scalc/guide.po | 24 - source/nl/helpcontent2/source/text/shared/00.po |8 source/nl/helpcontent2/source/text/shared/01.po |8 source/nl/helpcontent2/source/text/shared/optionen.po | 16 source/nl/sc/messages.po | 36 +- source/nl/scaddins/messages.po|4 source/nl/sfx2/messages.po|6 source/nl/svx/messages.po |6 source/pt-BR/cui/messages.po |6 source/pt-BR/helpcontent2/source/text/shared/guide.po |8 source/pt-BR/readlicense_oo/docs.po | 10 source/sv/helpcontent2/source/text/shared/00.po |8 source/th/sw/messages.po | 20 - 90 files changed, 781 insertions(+), 793 deletions(-) New commits: commit 8bde22939d49fb6cebb30841b269b1625c07eb5a Author: Christian Lohmaier AuthorDate: Tue Jun 4 12:32:38 2024 +0200 Commit: Christian Lohmaier CommitDate: Tue Jun 4 12:32:38 2024 +0200 update translations for 24.2.4 rc2 and force-fix errors using pocheck Change-Id: Iecf863e23df6934c7fc9125f9eda4ec05c26739f diff --git a/source/ab/sc/messages.po b/source/ab/sc/messages.po index 99c63d9105a..cf25733b1cc 100644 --- a/source/ab/sc/messages.po +++ b/source/ab/sc/messages.po @@ -4,7 +4,7 @@ msgstr "" "Project-Id-Version: PACKAGE VERSION " "Report-Msgid-Bugs-To: https://bugs.libreoffice.org/enter_bug.cgi?product=LibreOffice_status=UNCONFIRMED=UI " "POT-Creation-Date: 2024-05-31 13:51+0200 " -"PO-Revision-Date: 2024-03-03 16:37+ " +"PO-Revision-Date: 2024-06-01 12:37+ " "Last-Translator: Андрей Абухба " "Language-Team: Abkhazian <https://translations.documentfoundation.org/projects/libo_ui-24-2/scmessages/ab/> " "Language: ab " @@ -13,7 +13,7 @@ msgstr "" "Content-Transfer-Encoding: 8bit " "Plural-Forms: nplurals=2; plural=n != 1; " "X-Accelerator-Marker: ~ " -"X-Generator: LibreOffice " +"X-Generator: Weblate 5.4.3 " "X-POOTLE-MTIME: 1542022333.00 " #. kBovX @@ -7946,7 +7946,7 @@ msgstr "Ахыԥхьаӡара" #: sc/inc/scfuncs.hrc:1456 msgctxt "SC_OPCODE_CEIL_ISO" msgid "The number to be rounded up." -msgstr "" +msgstr "Аҩадахьала ихыркәшахо ахыԥхьаӡара." #. gAmRk #: sc/inc/scfuncs.hrc:1457 @@ -8074,7 +8074,7 @@ msgstr "Аиашара" #: sc/inc/scfuncs.hrc:1492 msgctxt "SC_OPCODE_FLOOR" msgid "The number to whose multiple the value is to be rounded down." -msgstr "" +msgstr "Ахыԥхьаӡара ахьынӡахыркәшахо, ацифрақәа рхыԥхьаӡара." #. CAUCc #: sc/inc/scfuncs.hrc:1493 @@ -8107,7 +8107,7 @@ msgstr "Ахыԥхьаӡара" #: sc/inc/scfuncs.hrc:1502 msgctxt "SC_OPCODE_FLOOR_MS" msgid "The number to be rounded down." -msgstr "" +msgstr "Аладахьала ихыркәшахо ахыԥхьаӡара." #. w4Xsk #: sc/inc/scfuncs.hrc:1503 @@ -8149,7 +8149,7 @@ msgstr "Аиашқәшәара" #: sc/inc/scfuncs.hrc:1514 msgctxt "SC_OPCODE_FLOOR_MATH" msgid "The number to whose multiple the value is to be rounded down." -msgstr "" +msgstr "Ахыԥхьаӡара ахьынӡахыркәшахо, ацифрақәа рхыԥхьаӡара." #. yTCb8 #: sc/inc/scfuncs.hrc:1515 @@ -8210,7 +8210,7 @@ msgstr "" #: sc/inc/scfuncs.hrc:1534 msgctxt "SC_OPCODE_GCD" msgid "Integer 1; integer 2,... are integers for which the greatest common divisor is to be calculated." -msgstr "" +msgstr "Еибгоу ахыԥхаӡара 1; еибгоу ахыԥхаӡара 2,... еибгоу ахыԥхаӡарақәа, ззы азеиԥш шага ԥшаахо." #. 8Bp3W #: sc/inc/scfuncs.hrc:1540 @@ -8264,7 +8264,7 @@ msgstr "Амассив 1" #: sc/inc/scfuncs.hrc:1558 msgctxt "SC_OPCODE_MAT_MULT" msgid "The first array for the array product." -msgstr "" +msgstr "Аматрицақәа рышьҭыхлыҵ аԥшааразы актәи аматрица." #. Ebs87 #: sc/inc/scfuncs.hrc:1559 @@ -8276,13 +8276,13 @@ msgstr "Амассив 2" #: sc/inc/scfuncs.hrc:1560 msgctxt "SC_OPCODE_MAT_MULT" msgid "T
Re: [PATCH] fix setting of current source file context
Hi, I tried the patch but get an error during compile: %%% cat chicken-defaults.h >>chicken-config.h gcc -fno-strict-aliasing -fwrapv -fno-common -DHAVE_CHICKEN_CONFIG_H -DC_ENABLE_PTABLES -c -Os -fomit-frame-pointer -DC_BUILDING_LIBCHICKEN library.c -o library-static.o -I. -I./ chicken eval.scm -optimize-level 2 -include-path . -include-path ./ -inline -ignore-repository -feature chicken-bootstrap -no-warnings -specialize -consult-types-file ./types.db -explicit-use -no-trace -output-file eval.c \ -emit-import-library chicken.eval \ -emit-import-library chicken.load Error: invalid argument type in specialization (or fixnum char boolean eof bwp null undefined) ((pair (or fixnum char boolean eof bwp null undefined)) (##sys#setislot #(1) (quote 0) #(2))) scheme#set-car! Call history: (##core#begin (##core#require modules)) (##core#require modules) (##core#callunit modules) <-- make: *** [eval.c] Error 70 %%% Christian > On 4. Jun 2024, at 12:15, felix.winkelm...@bevuta.com wrote: > > This patch addresses the problem reported by Christian Himpe weith > "include-relative". The patch also adds tests for the problem that > was addressed earlier with relative includes. > > > felix > > <0001-Ensure-current-source-filename-is-set-correctly.patch>
Re: What might ‘org-element-at-point’ be doing in *scratch*?
Ihor Radchenko writes: > Christian Moe writes: > >> After upgrading to 9.7.1 on Emacs 27.1, I get a curious warning on Emacs >> start-up: >> >> "Warning (org-element): ‘org-element-at-point’ cannot be used in non-Org >> buffer # (fundamental-mode)" >> >> It does not happen with 'emacs -Q', but it also did not happen before >> the upgrade, so I don't know what in my configuration now triggers it, >> or why anything would want to do this. > > Try M-x debug-on-entry org-element-at-point and you may then get clues > from the backtrace. Thanks! Nothing the matter with Org; pardon the noise. Culprit found: some old code of mine that called org-get-id on load for bad reasons, and which Emacs has so far suffered in silence. Yours, Christian
Re: [PATCH V2] drm/ttm: increase ttm pre-fault value to PMD size
Am 04.06.24 um 12:18 schrieb Huang Rui: On Tue, Jun 04, 2024 at 04:49:34PM +0800, Zhu, Lingshan wrote: ttm page fault handler ttm_bo_vm_fault_reserved() maps TTM_BO_VM_NUM_PREFAULT more pages beforehand due to the principle of locality. However, on some platform the page faults are more costly, this patch intends to increase the number of ttm pre-fault to relieve the number of page faults. When multiple levels of page table is supported, the new default value would be the PMD size, similar to huge page. Signed-off-by: Zhu Lingshan Reported-and-tested-by: Li Jingxiang Acked-by: Huang Rui Not sure if there really is an architecture with less than 3 page table levels, but the build robots should be able to tell us if everything is fine here. Reviewed-by: Christian König --- include/drm/ttm/ttm_bo.h | 4 1 file changed, 4 insertions(+) diff --git a/include/drm/ttm/ttm_bo.h b/include/drm/ttm/ttm_bo.h index 6ccf96c91f3a..ef0f52f56ebc 100644 --- a/include/drm/ttm/ttm_bo.h +++ b/include/drm/ttm/ttm_bo.h @@ -39,7 +39,11 @@ #include "ttm_device.h" /* Default number of pre-faulted pages in the TTM fault handler */ +#if CONFIG_PGTABLE_LEVELS > 2 +#define TTM_BO_VM_NUM_PREFAULT (1 << (PMD_SHIFT - PAGE_SHIFT)) +#else #define TTM_BO_VM_NUM_PREFAULT 16 +#endif struct iosys_map; -- 2.45.1
[Bug 2068014] [NEW] mandos-client fails to install gpg-agent into intiramfs
Public bug reported:
# lsb_release -rd
No LSB modules are available.
Description:Ubuntu 24.04 LTS
Release:24.04
# apt-cache policy mandos-client
mandos-client:
Installed: 1.8.16-1ubuntu4
Candidate: 1.8.16-1ubuntu4
Version table:
*** 1.8.16-1ubuntu4 500
500 http://mirror.hetzner.com/ubuntu/packages noble/universe amd64
Packages
500 http://archive.ubuntu.com/ubuntu noble/universe amd64 Packages
100 /var/lib/dpkg/status
mandos-client is able to fetch password from server in running system, but
fails in initrams with error
Mandos plugin mandos-client: bad gpgme_op_decrypt: GnuPG: No secret key
The reason why mandos-client is not working is that initramfs is missing the
gpg-agent binary.
The reason why gpg-agent binary is not copied to initramfs is that the
package libgpgme11 has been renamed to libgpgme11t64.
The fix is:
# diff /usr/share/initramfs-tools/hooks/mandos.orig
/usr/share/initramfs-tools/hooks/mandos
183c183
< libgpgme11_version="`dpkg-query --showformat='${Version}' --show libgpgme11`"
---
> libgpgme11_version="`dpkg-query --showformat='${Version}' --show
> libgpgme11t64`"
As I think creation of intiramfs is part of the distro I address this here.
Please let me know when I am wrong.
Kind regards
Christian Rusa
** Affects: mandos (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2068014
Title:
mandos-client fails to install gpg-agent into intiramfs
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mandos/+bug/2068014/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
What might ‘org-element-at-point’ be doing in *scratch*?
Hi, After upgrading to 9.7.1 on Emacs 27.1, I get a curious warning on Emacs start-up: "Warning (org-element): ‘org-element-at-point’ cannot be used in non-Org buffer # (fundamental-mode)" It does not happen with 'emacs -Q', but it also did not happen before the upgrade, so I don't know what in my configuration now triggers it, or why anything would want to do this. Anyone else seeing this? Yours, Christian
Re: [PATCH for-4.19? v5 00/10] x86: Make MAX_ALTP2M configurable
> On 2 Jun 2024, at 21:04, Petr Beneš wrote: > > tools/ocaml/libs/xc/xenctrl.ml | 2 + > tools/ocaml/libs/xc/xenctrl.mli | 2 + > tools/ocaml/libs/xc/xenctrl_stubs.c | 40 +++--- Acked-by: Christian Lindig
Re: [PATCH v2 03/10] drm/amdgpu: abort fence poll if reset is started
Hi Shaoyun, see inline. Am 03.06.24 um 20:28 schrieb Liu, Shaoyun: [AMD Official Use Only - AMD Internal Distribution Only] Thanks Christian for the detail explanation. I checked your patch , you try to use query_scheduler_status package to check the command completion . It may not work as expected since this API query the status is for MES itself , so mes can update the fence address with the expected seq value, but the command itself (ex .remove_queue for mes and then mes send the unmap_queue to kiq internally) still fails. And that is exactly the desired behavior. See the fence value is for ring buffer processing and getting feedback in the case of a reset for example if the MES has processed the commands. If that processing is successfully or not *must* be completely irrelevant for writing the fence value. For mes , driver always poll for the command completion No, exactly that's what we want to avoid as much as possible. Polling means that we throw away tons of CPU cycles and especially on fault handling and TLB flushing that is an absolutely in-acceptable performance loss. , do you think it's an acceptable solution that MES set a specific failure value(ex , -1) in the fence address to indicate the failure of the operation ? But that should be similar to let driver poll the completion till timeout . MES internally also need to wait for a timeout on some command that it sent to CP (ex. 2 seconds for unmap_queue command). No, what we should really do is to separate the fence and the result values. And then give an input dependency on each operation. I'm actually a little bit confused here , has driver use the lock to ensure there is only one submission into MES at any time ? No, exactly that's what we try to avoid. Othertwise we don't need a ring buffer in the first place. MES can also trigger the interrupt on the failure if driver side require us to do so , the payload will have the seq number to indicate which submission cause the failure , that might requires more code change from driver side .Please let me what's preferred from driver side. I can come up with a more detailed explanation of the driver requirements when I'm back from sick leave. Regards, Christian. Regards Shaoyun.liu -Original Message- From: Koenig, Christian Sent: Monday, June 3, 2024 6:59 AM To: Liu, Shaoyun ; Christian König ; Li, Yunxiang (Teddy) ; amd-gfx@lists.freedesktop.org; Deucher, Alexander ; Xiao, Hua Subject: Re: [PATCH v2 03/10] drm/amdgpu: abort fence poll if reset is started Hi Shaoyun, yes my thinking goes into the same direction. The basic problem here is that we are trying to stuff two different information into the same variable. The first information is if the commands haven been read by the MES from the ring buffer. This information is necessary for the normal ring buffer and reset handling, e.g. prevents ring buffer overflow, ordering of command, lockups during reset etc... The second information is if a certain operation was successfully or not. For example this is necessary to get signaled back if y queue map/unmap operation has been successfully or if the CP not responding or any other error has happened etc... Another issue is that while it is in general a good idea to have the firmware work in a way where errors are reported instead of completely stopping all processing, here we run into trouble because the driver usually assumes that work can be scheduled on the ring buffer and a subsequent work is processed only when everything previously submitted has completed successfully. So as initial fix for the issue we see I've send Alex a patch on Friday to partially revert his change to use an individual writeback for each submission. Instead we will submit an addition QUERY_STATUS command after the real command and let that one write fence value. This way the fence value is always written, independent of the result of the operation. Additional to that we need to insert something like a dependency between submissions, e.g. when you have commands A, B and C on the ring and C can only execute when A was successfully then we need to somehow tell that the MES. Only other alternative is to not scheduler commands behind each other on the ring and that in turn is a bad idea from the performance point of view. Regards, Christian. Am 31.05.24 um 16:44 schrieb Liu, Shaoyun: [AMD Official Use Only - AMD Internal Distribution Only] Hi, Christian I think we have a discussion about this before . Alex also have a change that allow driver to use different write back address for the fence for each submission for the original issue . From MES point of view , MES will update the fence when the API can be complete successfully, so if the API (ex . remove_queue) fails due to other component issue (ex , CP hang), the MES will not update the fence In this situation , but MES itself still works
Re: EnumerableTableScan array/multiset handling
Hi Julian, it seems to me that org.apache.calcite.rel.type.RelDataTypeFactoryImpl.JavaType, which is a subtype of RelDataType, would be the best place to model this. How about I add an Accessor contract and a field to JavaType to take care of producing expressions for the enumerable adapater? By default, this will use an implementation based on public fields or record accessors depending on class type. In addition, I would also add an implementation that works based on calling getter methods, since that is what I need for my purposes. Wdyt? Regards, Christian Am 31.05.2024 um 03:02 schrieb Julian Hyde: Thanks for doing these experiments, Christian, and documenting what you found. I think you’re running into the limitations of ReflectiveSchema. It works with POJOs (java classes with public fields) but hasn’t been tested for richer variations and therefore just doesn’t work. In many cases, it can be fixed (seehttps://issues.apache.org/jira/browse/CALCITE-6244 for example). I’m uneasy about extending RelDataType to return JavaRowFormat. That seems to be introducing a physical property into a logical data type; also, it is surfacing the details of one particular adapter (enumerable). Maybe there is a way to surface this information via annotations or the java.sql.Wrapper interface without extending RelDataType. Julian On May 24, 2024, at 11:33 AM, Christian Beikov wrote: Hello, in my recent experiments I ran into some issues when trying to unnest an array of struct. The query is roughly this: select t.id, e.value1 from MyTable t, unnest(t.structArray) e EnumerableTableScan#fieldExpression will then try to generate code that converts the value of the "structArray" column to a List, which is where the problems start to arise. This code does not seem to be tested at all, because currently generates a compile error, due to missing a cast to "Iterable". It also assumes the data is already available in the JavaRowFormat.CUSTOM representation, but AFAIU, it could be in any format. When using RelRecordType for structs, regular struct columns seem to expect JavaRowFormat.ARRAY, but struct arrays don't seem to behave the same way. What is the expected data format that an enumerator should return for struct arrays that are typed as RelRecordType? To support formats per type it might be nice to allow specifying the JavaRowFormat on RelDataType. Wdyt? Also, is there a way to allow working with custom Java types for table/struct rows? From looking at AbstractCursor#createAccessor, it seems the Aviatica code currently only works with classes that expose public fields. Regards, Christian
Commit: patch 9.1.0465: missing filecopy() function
patch 9.1.0465: missing filecopy() function
Commit:
https://github.com/vim/vim/commit/60c8743ab6c90e402e6ed49d27455ef7e5698abe
Author: Shougo Matsushita
Date: Mon Jun 3 22:59:27 2024 +0200
patch 9.1.0465: missing filecopy() function
Problem: missing filecopy() function
Solution: implement filecopy() Vim script function
(Shougo Matsushita)
closes: #12346
Co-authored-by: zeertzjq
Signed-off-by: Shougo Matsushita
Signed-off-by: Christian Brabandt
diff --git a/runtime/doc/builtin.txt b/runtime/doc/builtin.txt
index 751fbc215..782c42f74 100644
--- a/runtime/doc/builtin.txt
+++ b/runtime/doc/builtin.txt
@@ -1,4 +1,4 @@
-*builtin.txt* For Vim version 9.1. Last change: 2024 May 25
+*builtin.txt* For Vim version 9.1. Last change: 2024 Jun 03
VIM REFERENCE MANUALby Bram Moolenaar
@@ -178,6 +178,8 @@ extendnew({expr1}, {expr2} [, {expr3}])
List/Dict like |extend()| but creates a new
List or Dictionary
feedkeys({string} [, {mode}]) Number add key sequence to typeahead buffer
+filecopy({from}, {to}) Number |TRUE| if copying file {from} to {to}
+ worked
filereadable({file}) Number |TRUE| if {file} is a readable file
filewritable({file}) Number |TRUE| if {file} is a writable file
filter({expr1}, {expr2}) List/Dict/Blob/String
@@ -2757,6 +2759,18 @@ feedkeys({string} [, {mode}])
*feedkeys()*
Can also be used as a |method|: >
GetInput()->feedkeys()
+filecopy({from}, {to}) *filecopy()*
+ Copy the file pointed to by the name {from} to {to}. The
+ result is a Number, which is |TRUE| if the file was copied
+ successfully, and |FALSE| when it failed.
+ If a file with name {to} already exists, it will fail.
+ Note that it does not handle directories (yet).
+
+ This function is not available in the |sandbox|.
+
+ Can also be used as a |method|: >
+ GetOldName()->filecopy(newname)
+
filereadable({file}) *filereadable()*
The result is a Number, which is |TRUE| when a file with the
name {file} exists, and can be read. If {file} doesn't exist,
diff --git a/runtime/doc/tags b/runtime/doc/tags
index 73aefe1ce..75c27f928 100644
--- a/runtime/doc/tags
+++ b/runtime/doc/tags
@@ -7091,6 +7091,7 @@ file-searchingediting.txt /*file-searching*
file-type filetype.txt/*file-type*
file-types filetype.txt/*file-types*
file_readable()builtin.txt /*file_readable()*
+filecopy() builtin.txt /*filecopy()*
fileencoding-changed version6.txt/*fileencoding-changed*
filename-backslash cmdline.txt /*filename-backslash*
filename-modifiers cmdline.txt /*filename-modifiers*
diff --git a/runtime/doc/todo.txt b/runtime/doc/todo.txt
index 7491b06e0..c37a1d4bd 100644
--- a/runtime/doc/todo.txt
+++ b/runtime/doc/todo.txt
@@ -1,4 +1,4 @@
-*todo.txt* For Vim version 9.1. Last change: 2024 May 11
+*todo.txt* For Vim version 9.1. Last change: 2024 Jun 03
VIM REFERENCE MANUALby Bram Moolenaar
@@ -82,8 +82,6 @@ With 'smoothscroll' set and "lastline" in 'display', moving
the cursor to a
wrapping line that makes the display scroll up may scroll much more than
needed, thus jump-scrolling. (part of issue 12411)
-Add filecopy() ? #12346
-
Implement foreach() PR #12166
Errors when running tests with valgrind:
@@ -4242,7 +4240,6 @@ Vim script language:
base64enc() base 64 encoding
base64dec() base 64 decoding
attributes()return file protection flags "drwxrwxrwx"
- filecopy(from, to) Copy a file
shorten(fname) shorten a file name, like home_replace()
perl(cmd) call Perl and return string
inputrl() like input() but right-to-left
diff --git a/runtime/doc/usr_41.txt b/runtime/doc/usr_41.txt
index 26651ebb1..4225d1f62 100644
--- a/runtime/doc/usr_41.txt
+++ b/runtime/doc/usr_41.txt
@@ -1,4 +1,4 @@
-*usr_41.txt* For Vim version 9.1. Last change: 2024 May 07
+*usr_41.txt* For Vim version 9.1. Last change: 2024 Jun 03
VIM USER MANUAL - by Bram Moolenaar
@@ -993,6 +993,7 @@ System functions and manipulation of files:
readdir() get a List of file names in a directory
readdirex() get a List of file information in a directory
writefile() write a List of lines or Blob into a file
+ filecopy() copy a file {from} to {to}
Date and Time:
Commit: patch 9.1.0464: no whitespace padding in commentstring option in ftplugins
patch 9.1.0464: no whitespace padding in commentstring option in ftplugins
Commit:
https://github.com/vim/vim/commit/0a0830624a260660c7fa692ecb7e6e5de09114ba
Author: Riley Bruins
Date: Mon Jun 3 20:40:45 2024 +0200
patch 9.1.0464: no whitespace padding in commentstring option in ftplugins
Problem: no whitespace padding in commentstring option in ftplugins
Solution: Change default to include whitespace padding, update
existing filetype plugins with the new default value
(Riley Bruins)
closes: #14843
Signed-off-by: Riley Bruins
Signed-off-by: Christian Brabandt
diff --git a/.github/MAINTAINERS b/.github/MAINTAINERS
index dbc04868f..91c3284af 100644
--- a/.github/MAINTAINERS
+++ b/.github/MAINTAINERS
@@ -179,6 +179,7 @@ runtime/ftplugin/kotlin.vim @udalov
runtime/ftplugin/less.vim @genoma
runtime/ftplugin/liquid.vim@tpope
runtime/ftplugin/lua.vim @dkearns
+runtime/ftplugin/lc.vim@ribru17
runtime/ftplugin/lynx.vim @dkearns
runtime/ftplugin/m3build.vim @dkearns
runtime/ftplugin/m3quake.vim @dkearns
diff --git a/runtime/doc/options.txt b/runtime/doc/options.txt
index e28244f11..bc7f68713 100644
--- a/runtime/doc/options.txt
+++ b/runtime/doc/options.txt
@@ -1909,13 +1909,14 @@ A jump table for the options with a short description
can be found at |Q_op|.
insert a space.
*'commentstring'* *'cms'* *E537*
-'commentstring' 'cms' string (default "/*%s*/")
+'commentstring' 'cms' string (default "/* %s */")
local to buffer
{not available when compiled without the |+folding|
feature}
A template for a comment. The "%s" in the value is replaced with the
- comment text. Currently only used to add markers for folding, see
- |fold-marker|. Also used by comment plugins |comment-install|.
+ comment text, and should be padded with a space when possible.
+ Currently used to add markers for folding, see |fold-marker| also
+ commonly used by commenting plugins (e.g. |comment-install|).
*'compatible'* *'cp'* *'nocompatible'* *'nocp'*
'compatible' 'cp' boolean (default on, off when a |vimrc| or |gvimrc|
diff --git a/runtime/doc/version9.txt b/runtime/doc/version9.txt
index 3473d796f..3fe8b2dad 100644
--- a/runtime/doc/version9.txt
+++ b/runtime/doc/version9.txt
@@ -41565,6 +41565,8 @@ Changed~
---
- use 'smoothscroll' logic for CTRL-F and CTRL-B for pagewise scrolling
- use 'smoothscroll' logic for CTRL-D and CTRL-U for half-pagewise scrolling
+- the default for 'commentstring' contains whitespace padding to have
+ automatic comments look nicer |comment-install|
*added-9.2*
Added ~
diff --git a/runtime/ftplugin/abaqus.vim b/runtime/ftplugin/abaqus.vim
index c16e7b032..d4bb6fe77 100644
--- a/runtime/ftplugin/abaqus.vim
+++ b/runtime/ftplugin/abaqus.vim
@@ -3,6 +3,7 @@
" Maintainer: Carl Osterwisch
" Last Change: 2022 Oct 08
" 2024 Jan 14 by Vim Project (browsefilter)
+" 2024 May 23 by Riley Bruins
('commentstring')
" Only do this when not done yet for this buffer
if exists("b:did_ftplugin") | finish | endif
@@ -27,7 +28,7 @@ setlocal isfname-=,
" Define format of comment lines (see 'formatoptions' for uses)
setlocal comments=:**
-setlocal commentstring=**%s
+setlocal commentstring=**\ %s
" Definitions start with a * and assign a NAME, NSET, or ELSET
" Used in [d ^wd and other commands
diff --git a/runtime/ftplugin/arduino.vim b/runtime/ftplugin/arduino.vim
index dae3dd83d..60b11dab1 100644
--- a/runtime/ftplugin/arduino.vim
+++ b/runtime/ftplugin/arduino.vim
@@ -3,6 +3,7 @@
" Maintainer: The Vim Project <https://github.com/vim/vim>
" Ken Takata <https://github.com/k-takata>
" Last Change: 2024 Apr 12
+" 2024 Jun 02 by Riley Bruins
('commentstring')
"
" Most of the part was copied from c.vim.
@@ -32,7 +33,7 @@ setlocal fo-=t fo+=croql
" These options have the right value as default, but the user may have
" overruled that.
-setlocal commentstring& define& include&
+setlocal commentstring=/*\ %s\ */ define& include&
" Set completion with CTRL-X CTRL-O to autoloaded function.
if exists('')
diff --git a/runtime/ftplugin/asm.vim b/runtime/ftplugin/asm.vim
index 0ae161039..4482b90d0 100644
--- a/runtime/ftplugin/asm.vim
+++ b/runtime/ftplugin/asm.vim
@@ -4,13 +4,14 @@
" Last Change: 2020 May 23
" 2023 Aug 28 by Vim Project (undo_ftplugin)
" 2024 Apr 09 by Vim Project (add Matchit support)
+"
[plasmashell] [Bug 487987] New: Regression: (X11) Primary Selection no longer appears in history
https://bugs.kde.org/show_bug.cgi?id=487987 Bug ID: 487987 Summary: Regression: (X11) Primary Selection no longer appears in history Classification: Plasma Product: plasmashell Version: 6.0.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Clipboard Assignee: plasma-b...@kde.org Reporter: k...@fuchsnet.ch Target Milestone: 1.0 SUMMARY On my desktop I have plasma 5.27.11, on my notebook I upgraded to 6.0.5. The clipboard settings are (visually, in the GUI) the same, but the behaviour on 6.0.5 changed. Selecting text (X11 Primary Selection) appears in the history on 5.*, while it no longer does on 6.* unless I activate the option to keep the clipboard and selection in sync, which I do not want. There is an option, but it only becomes editable if the sync is enabled, and doesn't allow me to configure it the way 5.* behaves (or I didn't find out how) Please fix this regression, as managing both the selection and the clipboard content is an important usecase to me. I also don't see why this should not be possible option-wise, as in: why this specific combination can't be configured. STEPS TO REPRODUCE 1. Update to Plasma 6.* 2. Use X11 (potentially same in Wayland, didn't test, not sure about selection there in general) 3. Mark text with mouse OBSERVED RESULT Text doesn't appear in clipboard history EXPECTED RESULT Text does appear, as it did in 5.* If you think this is confusing for users, please at least offer an option (since the GUI seems somewhat prepared to that) to change that behaviour. -- You are receiving this mail because: You are watching all bug changes.
Re: [PATCH] drm/amdgpu: use local xcc write to flush tlb
Am 03.06.24 um 13:46 schrieb Yiqing Yao:
When flushing gpu tlb using kiq from gfxhub, kiq ring is always
local as xcc instance is selected for it. Thus using lower 18 bits
to access mmregs inside local xcc instead of full address used
when accessing regs outside of local xcc.
Remove redundent code.
Signed-off-by: Yiqing Yao
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index 350f6b6676f1..864fea31c354 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -853,8 +853,10 @@ static void gmc_v9_0_flush_gpu_tlb(struct amdgpu_device
*adev, uint32_t vmid,
*/
if (adev->gfx.kiq[inst].ring.sched.ready &&
(amdgpu_sriov_runtime(adev) || !amdgpu_sriov_vf(adev))) {
- uint32_t req = hub->vm_inv_eng0_req + hub->eng_distance * eng;
- uint32_t ack = hub->vm_inv_eng0_ack + hub->eng_distance * eng;
+
+ /* Select lower 18 bits to write in local xcc */
+ if (vmhub < AMDGPU_MMHUB0(0))
+ req = req & 0x3;
A bit more explanation would be good here, e.g. what you have in the
commit message.
Apart from that why do we need that in the first place? Isn't the KIQ
able to access the register anyway?
Regards,
Christian.
amdgpu_gmc_fw_reg_write_reg_wait(adev, req, ack, inv_req,
1 << vmid, inst);
Commit: patch 9.1.0463: no fuzzy-matching support for insert-completion
patch 9.1.0463: no fuzzy-matching support for insert-completion Commit: https://github.com/vim/vim/commit/a218cc6cdabae1113647b817c4eefc2b60a6902f Author: glepnir Date: Mon Jun 3 19:32:39 2024 +0200 patch 9.1.0463: no fuzzy-matching support for insert-completion Problem: no fuzzy-matching support for insert-completion Solution: enable insert-mode completion with fuzzy-matching using :set completopt+=fuzzy (glepnir). closes: #14878 Signed-off-by: glepnir Signed-off-by: Christian Brabandt diff --git a/runtime/doc/options.txt b/runtime/doc/options.txt index cae3e5433..e28244f11 100644 --- a/runtime/doc/options.txt +++ b/runtime/doc/options.txt @@ -1,4 +1,4 @@ -*options.txt* For Vim version 9.1. Last change: 2024 Jun 01 +*options.txt* For Vim version 9.1. Last change: 2024 Jun 03 VIM REFERENCE MANUALby Bram Moolenaar @@ -2143,6 +2143,11 @@ A jump table for the options with a short description can be found at |Q_op|. select one from the menu. Only works in combination with "menu" or "menuone". + fuzzyEnable |fuzzy-matching| for completion candidates. This + allows for more flexible and intuitive matching, where + characters can be skipped and matches can be found even + if the exact sequence is not typed. + *'completepopup'* *'cpp'* 'completepopup' 'cpp' string (default empty) global diff --git a/runtime/doc/pattern.txt b/runtime/doc/pattern.txt index f16e7d2d6..183806a96 100644 --- a/runtime/doc/pattern.txt +++ b/runtime/doc/pattern.txt @@ -1,4 +1,4 @@ -*pattern.txt* For Vim version 9.1. Last change: 2024 Apr 26 +*pattern.txt* For Vim version 9.1. Last change: 2024 Jun 03 VIM REFERENCE MANUALby Bram Moolenaar @@ -1513,5 +1513,7 @@ the matching positions and the fuzzy match scores. The "f" flag of `:vimgrep` enables fuzzy matching. +To enable fuzzy matching for |ins-completion|, add the "fuzzy" value to the +'completeopt' option. vim:tw=78:ts=8:noet:ft=help:norl: diff --git a/runtime/doc/version9.txt b/runtime/doc/version9.txt index 1c5a29f20..3473d796f 100644 --- a/runtime/doc/version9.txt +++ b/runtime/doc/version9.txt @@ -1,4 +1,4 @@ -*version9.txt* For Vim version 9.1. Last change: 2024 May 17 +*version9.txt* For Vim version 9.1. Last change: 2024 Jun 03 VIM REFERENCE MANUALby Bram Moolenaar @@ -31711,12 +31711,12 @@ in |vim9-class|. The following features are supported: Support for creating a type alias for an existing type is added. -Virtual text +Virtual text ~ Support for adding |virtual-text| to a buffer is added. This is useful for language server features (e.g. inlay hints) -Smooth Scroll +Smooth Scroll ~ - Support for scrolling text using screen lines instead of file lines is added. Refer to the 'smoothscroll' option. @@ -31726,7 +31726,8 @@ The EditorConfig (|editorconfig-install|) and the JSON formatting OpenVMS x86_64 platform port: http://www.polarhome.com/vim/ -Other improvements *new-other-9.1* + *new-other-9.1* +Other improvements ~ -- - Support for undercurl (|t_Ce|), double underline (|t_Us|), dotted underline (|t_ds|) and dashed underline (|t_Ds|) termcap entries and @@ -31783,7 +31784,8 @@ Other improvements *new-other-9.1* - xxd: reversing a bit dump (xxd -r). - xxd: customize the variable name used in the C include output (xxd -n). -Changed*changed-9.1* + *changed-9.1* +Changed ~ --- - The features |++builtin_terms|, |+cmdline_info|, |+cmdwin|, |+file_in_path|, |+float|, |+path_extra|, |+textobjects|, |+wildignore| and |+wildmenu| are @@ -31815,7 +31817,8 @@ Changed *changed-9.1* - Migrate to autoconf 2.71. - Start using C99 feature (declare variable in for loops). -Added *added-9.1* + *added-9.1* +Added ~ - Various syntax, indent and other plugins were added. @@ -41541,30 +41544,31 @@ VERSION 9.2 *version-9.2* *version9.2* *vim-9.2* This section is about improvements made between version 9.1 and 9.2 and is a work in progress. -Support for Wayland UI. - -Support for the XDG Desktop Specification |xdg-base-dir| - -Vim9 script +Vim9 script ~ --- Add support for internal builtin functions with vim9 objects, see |builtin-object-methods| Enum support for Vim9 script |:enum| -Other improvements
Commit: patch 9.1.0462: eval5() and eval7 are too complex
patch 9.1.0462: eval5() and eval7 are too complex
Commit:
https://github.com/vim/vim/commit/734286e4c626f80ace27eeb252a5e384e798aebf
Author: Yegappan Lakshmanan
Date: Mon Jun 3 18:52:22 2024 +0200
patch 9.1.0462: eval5() and eval7 are too complex
Problem: eval5() and eval7 are too complex
Solution: Refactor eval5() and eval7() in eval.c
(Yegappan Lakshmanan)
closes: #14900
Signed-off-by: Yegappan Lakshmanan
Signed-off-by: Christian Brabandt
diff --git a/src/eval.c b/src/eval.c
index 4a039792c..7848feaa8 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -3946,6 +3946,40 @@ eval_addlist(typval_T *tv1, typval_T *tv2)
return OK;
}
+/*
+ * Left or right shift the number "tv1" by the number "tv2" and store the
+ * result in "tv1".
+ *
+ * Return OK or FAIL.
+ */
+static int
+eval_shift_number(typval_T *tv1, typval_T *tv2, int shift_type)
+{
+if (tv2->v_type != VAR_NUMBER || tv2->vval.v_number < 0)
+{
+ // right operand should be a positive number
+ if (tv2->v_type != VAR_NUMBER)
+ emsg(_(e_bitshift_ops_must_be_number));
+ else
+ emsg(_(e_bitshift_ops_must_be_positive));
+ clear_tv(tv1);
+ clear_tv(tv2);
+ return FAIL;
+}
+
+if (tv2->vval.v_number > MAX_LSHIFT_BITS)
+ // shifting more bits than we have always results in zero
+ tv1->vval.v_number = 0;
+else if (shift_type == EXPR_LSHIFT)
+ tv1->vval.v_number =
+ (uvarnumber_T)tv1->vval.v_number << tv2->vval.v_number;
+else
+ tv1->vval.v_number =
+ (uvarnumber_T)tv1->vval.v_number >> tv2->vval.v_number;
+
+return OK;
+}
+
/*
* Handle the bitwise left/right shift operator expression:
* var1 << var2
@@ -3972,16 +4006,16 @@ eval5(char_u **arg, typval_T *rettv, evalarg_T *evalarg)
{
char_u *p;
int getnext;
- exprtype_T type;
+ exprtype_T exprtype;
int evaluate;
typval_Tvar2;
int vim9script;
p = eval_next_non_blank(*arg, evalarg, );
if (p[0] == '<' && p[1] == '<')
- type = EXPR_LSHIFT;
+ exprtype = EXPR_LSHIFT;
else if (p[0] == '>' && p[1] == '>')
- type = EXPR_RSHIFT;
+ exprtype = EXPR_RSHIFT;
else
return OK;
@@ -4026,27 +4060,8 @@ eval5(char_u **arg, typval_T *rettv, evalarg_T *evalarg)
if (evaluate)
{
- if (var2.v_type != VAR_NUMBER || var2.vval.v_number < 0)
- {
- // right operand should be a positive number
- if (var2.v_type != VAR_NUMBER)
- emsg(_(e_bitshift_ops_must_be_number));
- else
- emsg(_(e_bitshift_ops_must_be_positive));
- clear_tv(rettv);
- clear_tv();
+ if (eval_shift_number(rettv, , exprtype) == FAIL)
return FAIL;
- }
-
- if (var2.vval.v_number > MAX_LSHIFT_BITS)
- // shifting more bits than we have always results in zero
- rettv->vval.v_number = 0;
- else if (type == EXPR_LSHIFT)
- rettv->vval.v_number =
- (uvarnumber_T)rettv->vval.v_number << var2.vval.v_number;
- else
- rettv->vval.v_number =
- (uvarnumber_T)rettv->vval.v_number >> var2.vval.v_number;
}
clear_tv();
@@ -4100,7 +4115,7 @@ eval_concat_str(typval_T *tv1, typval_T *tv2)
* The numbers can be whole numbers or floats.
*/
static int
-eval_addsub_num(typval_T *tv1, typval_T *tv2, int op)
+eval_addsub_number(typval_T *tv1, typval_T *tv2, int op)
{
interror = FALSE;
varnumber_Tn1, n2;
@@ -4290,7 +4305,7 @@ eval6(char_u **arg, typval_T *rettv, evalarg_T *evalarg)
}
else
{
- if (eval_addsub_num(rettv, , op) == FAIL)
+ if (eval_addsub_number(rettv, , op) == FAIL)
return FAIL;
}
clear_tv();
@@ -4299,6 +4314,113 @@ eval6(char_u **arg, typval_T *rettv, evalarg_T *evalarg)
return OK;
}
+/*
+ * Multiply or divide or compute the modulo of numbers "tv1" and "tv2" and
+ * store the result in "tv1". The numbers can be whole numbers or floats.
+ */
+static int
+eval_multdiv_number(typval_T *tv1, typval_T *tv2, int op)
+{
+varnumber_Tn1, n2;
+float_Tf1, f2;
+interror;
+intuse_float = FALSE;
+
+f1 = 0;
+f2 = 0;
+error = FALSE;
+if (tv1->v_type == VAR_FLOAT)
+{
+ f1 = tv1->vval.v_float;
+ use_float = TRUE;
+ n1 = 0;
+
core.git: Branch 'distro/collabora/co-24.04' - translations
translations |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) New commits: commit ea5fdd799fdcbe20d218873e44b8dc95ab6d305a Author: Christian Lohmaier AuthorDate: Mon Jun 3 17:31:44 2024 +0200 Commit: Gerrit Code Review CommitDate: Mon Jun 3 17:31:44 2024 +0200 Update git submodules * Update translations from branch 'distro/collabora/co-24.04' to eb9a6b26a36adfac6235cbd2852e5e7abeda54a3 - update translations for 24.2.4 rc2 and force-fix errors using pocheck Change-Id: I72d7d0cfe6d2cf73e9d77b235e568607dc2e64ac - update translations for 24.2.4 rc1 and force-fix errors using pocheck Change-Id: I33b8c9512615cb5d058159e40785d20255b645df - update translations for 24.2.3 rc2 and force-fix errors using pocheck Change-Id: Ia1b6ca2a6abad23632aafb021c8bba19a20e1a7b diff --git a/translations b/translations index d835b3bec673..eb9a6b26a36a 16 --- a/translations +++ b/translations @@ -1 +1 @@ -Subproject commit d835b3bec673fcb88a3e9c4aed8067ec0e838773 +Subproject commit eb9a6b26a36adfac6235cbd2852e5e7abeda54a3
Bug#1072515: general: Repeating cracking sound in headphones when nothing is playing.
On Mon, 3 Jun 2024 12:42:17 +0200 Andrius Merkys wrote: > Hi Christian, > > On 2024-06-03 11:38, Christian Böck wrote: > > when using headphones with my laptop (Thinkpad W550s) I get a repeating > > cracking (~1sec intervalls) when nothing is playing. > > I have a similar issue on a workstation with Ubuntu 22.04. What is your > operating system version? I believe the issue started manifesting once I > installed Jack. Do you have Jack on your machine? > > Andrius > > Hi Andrius! I'm running an up-to-date Debian 12 64Bit (bookworm) and I don't have Jack installed. After some messing with duckduckgo the problem seems to be, that the system puts the audio-chip to sleep, but not the headphone-amplifier. I hope someone from Debian can fix it.
Bug#1072515: general: Repeating cracking sound in headphones when nothing is playing.
On Mon, 3 Jun 2024 12:42:17 +0200 Andrius Merkys wrote: > Hi Christian, > > On 2024-06-03 11:38, Christian Böck wrote: > > when using headphones with my laptop (Thinkpad W550s) I get a repeating > > cracking (~1sec intervalls) when nothing is playing. > > I have a similar issue on a workstation with Ubuntu 22.04. What is your > operating system version? I believe the issue started manifesting once I > installed Jack. Do you have Jack on your machine? > > Andrius > > Hi Andrius! I'm running an up-to-date Debian 12 64Bit (bookworm) and I don't have Jack installed. After some messing with duckduckgo the problem seems to be, that the system puts the audio-chip to sleep, but not the headphone-amplifier. I hope someone from Debian can fix it.
Re: [PATCH v2] hostfs: convert hostfs to use the new mount API
On Thu, 30 May 2024 20:01:11 +0800, Hongbo Li wrote: > Convert the hostfs filesystem to the new internal mount API as the old > one will be obsoleted and removed. This allows greater flexibility in > communication of mount parameters between userspace, the VFS and the > filesystem. > > See Documentation/filesystems/mount_api.txt for more information. > > [...] Applied to the vfs.mount.api branch of the vfs/vfs.git tree. Patches in the vfs.mount.api branch should appear in linux-next soon. Please report any outstanding bugs that were missed during review in a new review to the original patch series allowing us to drop it. It's encouraged to provide Acked-bys and Reviewed-bys even though the patch has now been applied. If possible patch trailers will be updated. Note that commit hashes shown below are subject to change due to rebase, trailer updates or similar. If in doubt, please check the listed branch. tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git branch: vfs.mount.api [1/1] hostfs: convert hostfs to use the new mount API https://git.kernel.org/vfs/vfs/c/cd140ce9f611
Re: [PATCH 1/2] amdgpu: add the amdgpu_vm ptr in the vm_bo_map/unmap events
Am 03.06.24 um 13:52 schrieb Pierre-Eric Pelloux-Prayer:
Hi Christia,
Le 03/06/2024 à 11:58, Christian König a écrit :
Am 03.06.24 um 10:46 schrieb Pierre-Eric Pelloux-Prayer:
These 2 traces events are tied to a specific VM so in order for them
to be useful for a tool we need to trace the amdgpu_vm as well.
The bo_va already contains the VM pointer the map/unmap operation
belongs to.
Indeed, I've missed that. I'll fix that in v2.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 20
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8
2 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
index f539b1d00234..c84050d318d6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -243,10 +243,11 @@ TRACE_EVENT(amdgpu_vm_grab_id,
);
TRACE_EVENT(amdgpu_vm_bo_map,
- TP_PROTO(struct amdgpu_bo_va *bo_va,
+ TP_PROTO(struct amdgpu_vm *vm, struct amdgpu_bo_va *bo_va,
struct amdgpu_bo_va_mapping *mapping),
- TP_ARGS(bo_va, mapping),
+ TP_ARGS(vm, bo_va, mapping),
TP_STRUCT__entry(
+ __field(struct amdgpu_vm *, vm)
__field(struct amdgpu_bo *, bo)
__field(long, start)
__field(long, last)
@@ -255,22 +256,24 @@ TRACE_EVENT(amdgpu_vm_bo_map,
),
TP_fast_assign(
+ __entry->vm = vm;
__entry->bo = bo_va ? bo_va->base.bo : NULL;
__entry->start = mapping->start;
__entry->last = mapping->last;
__entry->offset = mapping->offset;
__entry->flags = mapping->flags;
),
- TP_printk("bo=%p, start=%lx, last=%lx, offset=%010llx,
flags=%llx",
- __entry->bo, __entry->start, __entry->last,
+ TP_printk("vm=%p bo=%p, start=%lx, last=%lx,
offset=%010llx, flags=%llx",
+ __entry->vm, __entry->bo, __entry->start, __entry->last,
__entry->offset, __entry->flags)
);
TRACE_EVENT(amdgpu_vm_bo_unmap,
- TP_PROTO(struct amdgpu_bo_va *bo_va,
+ TP_PROTO(struct amdgpu_vm *vm, struct amdgpu_bo_va *bo_va,
struct amdgpu_bo_va_mapping *mapping),
- TP_ARGS(bo_va, mapping),
+ TP_ARGS(vm, bo_va, mapping),
TP_STRUCT__entry(
+ __field(struct amdgpu_vm *, vm)
__field(struct amdgpu_bo *, bo)
__field(long, start)
__field(long, last)
@@ -279,14 +282,15 @@ TRACE_EVENT(amdgpu_vm_bo_unmap,
),
TP_fast_assign(
+ __entry->vm = vm;
__entry->bo = bo_va ? bo_va->base.bo : NULL;
__entry->start = mapping->start;
__entry->last = mapping->last;
__entry->offset = mapping->offset;
__entry->flags = mapping->flags;
),
- TP_printk("bo=%p, start=%lx, last=%lx, offset=%010llx,
flags=%llx",
- __entry->bo, __entry->start, __entry->last,
+ TP_printk("vm=%p bo=%p, start=%lx, last=%lx,
offset=%010llx, flags=%llx",
+ __entry->vm, __entry->bo, __entry->start, __entry->last,
__entry->offset, __entry->flags)
);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 3abfa66d72a2..e04928d2e26a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1642,7 +1642,7 @@ static void amdgpu_vm_bo_insert_map(struct
amdgpu_device *adev,
if (amdgpu_vm_is_bo_always_valid(vm, bo) && !bo_va->base.moved)
amdgpu_vm_bo_moved(_va->base);
- trace_amdgpu_vm_bo_map(bo_va, mapping);
+ trace_amdgpu_vm_bo_map(vm, bo_va, mapping);
}
/* Validate operation parameters to prevent potential abuse */
@@ -1834,7 +1834,7 @@ int amdgpu_vm_bo_unmap(struct amdgpu_device
*adev,
list_del(>list);
amdgpu_vm_it_remove(mapping, >va);
mapping->bo_va = NULL;
- trace_amdgpu_vm_bo_unmap(bo_va, mapping);
+ trace_amdgpu_vm_bo_unmap(vm, bo_va, mapping);
if (valid)
list_add(>list, >freed);
@@ -1929,7 +1929,7 @@ int amdgpu_vm_bo_clear_mappings(struct
amdgpu_device *adev,
tmp->bo_va = NULL;
list_add(>list, >freed);
- trace_amdgpu_vm_bo_unmap(NULL, tmp);
+ trace_amdgpu_vm_bo_unmap(vm, NULL, tmp);
That bo_va is NULL here is probably a bug and should be fixed.
Would something like this work?
trace_amdgpu_vm_bo_unmap(tmp->bo_va, tmp);
tmp->bo_va = NULL;
Re: [SOGo] infinite loop upon SAML login with Keycloak
Hello You have to change this: Am 03.05.24 um 09:17 schrieb "jpchev" (giam...@gmail.com): SOGoXSRFValidationEnabled = YES; Set it to NO and try again. Kind regards, Christian Mack -- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung, Lehre, Infrastruktur 78457 Konstanz +49 7531 88-4416 smime.p7s Description: Kryptografische S/MIME-Signatur
[Bug 2067889] Re: DPDK 23.11.1 / OVS 3.3.0 cause test failures
Directly running just the failing test (of the 6 I picked the MTU upper bound that I analyzed above) works like this: # WIP apt install ubuntu-dev-tools conntrack curl devscripts dpdk-dev ethtool equivs net-tools ncat python3-pyftpdlib tcpdump wget apt-get remove --yes --purge netcat-openbsd ln -sf /usr/bin/ncat /usr/bin/nc pull-lp-source openvswitch cd openvswitch-3.3.0/ mk-build-deps --install --tool "apt-get -o Debug::pkgProblemResolver=yes --no-install-recommends --yes" --remove debian/control ./debian/rules build systemctl stop openvswitch-ipsec ovs-vswitchd ovsdb-server ./tests/system-dpdk-testsuite -C _debian/tests -j1 AUTOTEST_PATH="$(pwd)/tests:$(pwd)/_debian/tests" 20 # Warning While it seems to mostly work these steps are yet incomplete, it fails even with the good version unable to start the vhost-user client successfully. I'll update it once I find more, maybe Fnordahl knows more about OVS tests. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2067889 Title: DPDK 23.11.1 / OVS 3.3.0 cause test failures To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/2067889/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[clang-tools-extra] [clangd] Allow "move function body out-of-line" in non-header files (PR #69704)
https://github.com/ckandeler closed https://github.com/llvm/llvm-project/pull/69704 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] [clangd] Allow "move function body out-of-line" in non-header files (PR #69704)
ckandeler wrote: I'm going to merge this without explicit format approval based on the following: - There was a general LGTM. - I addressed the remaining issues. - There was no further feedback for more than half a year. https://github.com/llvm/llvm-project/pull/69704 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [Rtk-users] Reconstruction geometry
Hello Simon, I realize that a 90° scan only allows for a partial reconstruction of the volume. This approach seems to be quite common in industrial applications due to space and time constraints, but I have not found much information about it in the literature. The Astra toolbox's FDK implementation seems to cope with this quite well, at least in the center of the volume. The rescaled pixel size should be 6 * 0.099 mm = 0.594 mm. Best regards, Christian Von: Simon Rit Gesendet: Sonntag, 2. Juni 2024 08:00 An: Christian Riesch Cc: rtk-us...@openrtk.org Betreff: Re: [Rtk-users] Reconstruction geometry Hi Christian, Thanks for the share. It was not clear to me that you had a 90° scan sorry. FDK is not appropriate for such a 90° scan, it's meant for a full 360° scan. rtkfdk tries to apply a short scan but Parker weighting is for 180°+fan-angle. So I'm not sure what to expect from FDK with such a scan. The projections that you shared are 512x511, can you please clarify the pixel size? I would try iterative reconstruction with such a scan. Cheers, Simon On Fri, May 31, 2024 at 12:25 PM Christian Riesch mailto:christian.rie...@live.com>> wrote: Hello Simon, Thanks for the quick response. So I have tried rtksimulatedgeometry with --arc 273 together with adding --neworigin=-153.5985,-153.2025,0 to rtkfdk. The result is different than before, but still looks very wrong (two ribbons and some vertical lines). I may be able to share some data later. Best regards, Christian Von: Simon Rit mailto:simon@creatis.insa-lyon.fr>> Gesendet: Donnerstag, 30. Mai 2024 08:48 An: Christian Riesch mailto:christian.rie...@live.com>> Cc: rtk-us...@openrtk.org<mailto:rtk-us...@openrtk.org> mailto:rtk-us...@openrtk.org>> Betreff: Re: [Rtk-users] Reconstruction geometry Hi, I can see two problems: - you need to indicate the short scan to rtksimulatedgeometry, e.g. --arc 273 or, if the angle convention is opposite in your system, --arc -273. You may have to tune the --first_angle option to position the volume as you wish but that should not prevent accurate reconstruction. - you need to center your projections, i.e., add the option --neworigin=-153.5985,-153.2025,0 to rtkfdk, computed with -0.5*(3104-1)*0.099 and -0.5*(3096-1)*0.099. Don't hesitate to share a dataset if that does not help. Good luck! Simon On Thu, May 30, 2024 at 6:58 AM Christian Riesch mailto:christian.rie...@live.com>> wrote: Hello, I'm currently trying to use RTK for a reconstruction from a stack of images that resulted from a 90° scan, but struggling to get the parameters right. On the other hand, I was able to get what looks like a faithful reconstruction using the Astra toolbox and the script from https://tomroelandts.com/articles/astra-toolbox-tutorial-reconstruction-from-projection-images-part-1 I have these parameters from the X-ray device that captured the images (size 3104x3096): "fod_mm": 75.46, (focus to object distance) "odd_mm": 407.07, (object to detector distance) "pixel_size_mm": 0.099, "start_arc_deg": 45.0, "stop_arc_deg": -45.0 (There is also "detector_offset_mm": 9.8, which I have ignored so far with both Astra and RTK.) So I have tried to create a geometry using .\rtksimulatedgeometry.exe -o"geo.xml" -n91 -f45 -a90 --sdd=482.53 --sid=75.46 where sdd = fod_mm + odd_mm and sid = fod_mm, and a reconstruction with .\rtkfdk.exe -p"images" -r".*tif" -g"geo.xml" -o"out.tif" --dimension=512,512,200 --newspacing=0.099 However, out.tif contains mostly zeros and a weird ribbon-like shape in the center. So I think my geometry is wrong, but I don't know how to fix it. For comparison, here are the input parameters for the Astra script: distance_source_origin = 75.46 # [mm] distance_origin_detector = 407.07 # [mm] detector_pixel_size = 0.099 # [mm] num_projections = 91 start_angle_deg = 45 stop_angle_deg = 135 Any pointers would be appreciated. Best regards, Christian Riesch ___ Rtk-users mailing list rtk-us...@openrtk.org<mailto:rtk-us...@openrtk.org> https://www.creatis.insa-lyon.fr/mailman/listinfo/rtk-users ___ Rtk-users mailing list rtk-us...@openrtk.org https://www.creatis.insa-lyon.fr/mailman/listinfo/rtk-users
Re: obscure microsd detection issue between U-Boot and kernel
On 5/31/24 21:47, Tim Harvey wrote: > Greetings, > > I'm seeing an issue on an imx8mm board (imx8mm-venice-gw73xx) where > for a specific set of microsd cards if I have accessed the microsd in > U-Boot with UHS/1.8V the kernel will not recognize that microsd when > scanning. > > The issue does not occur with all microsd cards but seems to appear > with a large sample size of a specific card/model (Kingston SDC32 32GB > SDR104 card). I do not see a signal integrity issue on the scope. > > Instrumenting the kernel the issue is that the host reports a CRC > error as soon as the first mmc_send_if_cond call which occurs in > mmc_rescan_try_freq. > > I can avoid the issue by either not accessing the microsd in U-Boot or > by disabling UHS/1.8V mode in U-Boot therefore what I think is > happening is that U-Boot leaves the card in UHS/1.8V signalling mode > and when the kernel scans it sets the voltage back to 3.3V > standard/default and default timings then issues its clock cycles to > 'reset' the card and the card does not recognize the reset. I'm > wondering if this is because the reset is done via clock cycles after > the kernel has set the I/O voltage back to 3.3V when perhaps the card > is still in 1.8V mode (although I don't see how that would cause an > issue)? It will cause an issue for many cards and might break some cards. > > Is there some sort of MMC 'reset' I can/should do in U-Boot before > booting the kernel? Has anyone encountered anything like this before? There is no 'switching back' to 3.3V signalling from UHS 1.8V. The only way this can be done is therefore a full power-off. Is that done correctly for your system? AFAIR spec dictates 500ms of <0.5V on VCC. Note that driving CLK/signal lines can also sustain the card somewhat, as leakage is only limited within operating voltage.
core.git: translations
translations |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) New commits: commit 0fc56575b69e0083d66149adeeb90662e29cdac7 Author: Christian Lohmaier AuthorDate: Mon Jun 3 13:51:56 2024 +0200 Commit: Gerrit Code Review CommitDate: Mon Jun 3 13:51:56 2024 +0200 Update git submodules * Update translations from branch 'master' to fbbd7b927a869cfe63dfbf0542b967da94eef28e - update translations for master and force-fix errors using pocheck Change-Id: I49098e6b67b2b13457c5f911910aac85b0d70b5d diff --git a/translations b/translations index 113c6c3c2498..fbbd7b927a86 16 --- a/translations +++ b/translations @@ -1 +1 @@ -Subproject commit 113c6c3c2498ffc2f99f20c088367bca1fecc50b +Subproject commit fbbd7b927a869cfe63dfbf0542b967da94eef28e
Re: [PATCH] drm/amdgpu: replace int with unsigned int for imu_v12_0.c
Am 03.06.24 um 10:53 schrieb Zhou, Bob:
[AMD Official Use Only - AMD Internal Distribution Only]
Hi Christian,
It fixes a potential Overflowed constant (INTEGER_OVERFLOW) warning reported by
Coverity.
You need to mention that in the commit message.
And I haven't checked the hardware docs, but it can be that this isn't
the right solution for the warning. Instead you should probably use the
RREG32_SOC15() macro with a mask which only leaves the valid bits around.
Only when the register is really 32bit wide you need an unsigned
datatype and if that is the case I suggest to use either uint32_t or u32
instead.
Regards,
Christian.
Regards,
Bob
-Original Message-
From: Koenig, Christian
Sent: 2024年6月3日 15:56
To: Zhou, Bob ; amd-gfx@lists.freedesktop.org; Huang, Tim
; Zhang, Jesse(Jie)
Cc: Deucher, Alexander
Subject: Re: [PATCH] drm/amdgpu: replace int with unsigned int for imu_v12_0.c
Am 03.06.24 um 07:59 schrieb Bob Zhou:
The return value of RREG32_SOC15 is unsigned int, so modify variable to
unsigned.
And why is that an improvement?
Regards,
Christian.
Signed-off-by: Bob Zhou
---
drivers/gpu/drm/amd/amdgpu/imu_v12_0.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/imu_v12_0.c
b/drivers/gpu/drm/amd/amdgpu/imu_v12_0.c
index 0c8ef908d112..2d6f7549c2af 100644
--- a/drivers/gpu/drm/amd/amdgpu/imu_v12_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/imu_v12_0.c
@@ -119,7 +119,7 @@ static int imu_v12_0_load_microcode(struct
amdgpu_device *adev)
static int imu_v12_0_wait_for_reset_status(struct amdgpu_device *adev)
{
- int i, imu_reg_val = 0;
+ unsigned int i, imu_reg_val = 0;
for (i = 0; i < adev->usec_timeout; i++) {
imu_reg_val = RREG32_SOC15(GC, 0, regGFX_IMU_GFX_RESET_CTRL); @@
-138,7 +138,7 @@ static int imu_v12_0_wait_for_reset_status(struct
amdgpu_device *adev)
static void imu_v12_0_setup(struct amdgpu_device *adev)
{
- int imu_reg_val;
+ unsigned int imu_reg_val;
WREG32_SOC15(GC, 0, regGFX_IMU_C2PMSG_ACCESS_CTRL0, 0xff);
WREG32_SOC15(GC, 0, regGFX_IMU_C2PMSG_ACCESS_CTRL1, 0x); @@
-157,7 +157,7 @@ static void imu_v12_0_setup(struct amdgpu_device
*adev)
static int imu_v12_0_start(struct amdgpu_device *adev)
{
- int imu_reg_val;
+ unsigned int imu_reg_val;
imu_reg_val = RREG32_SOC15(GC, 0, regGFX_IMU_CORE_CTRL);
imu_reg_val &= 0xfffe;
core.git: solenv/gbuild
solenv/gbuild/platform/com_MSC_defs.mk |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) New commits: commit c2f9689cd489f44122b50d7c0d7841c47381df99 Author: Christian Lohmaier AuthorDate: Mon Jun 3 11:55:14 2024 +0200 Commit: Christian Lohmaier CommitDate: Mon Jun 3 13:08:43 2024 +0200 disable MSVC -analyse when run in CI - build time penalty is too much times went from 55min to 88min when doing a single build Change-Id: I9304eae9f2326c206bd571e7b8a3ef861206282f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168362 Tested-by: Jenkins Reviewed-by: Christian Lohmaier Reviewed-by: Noel Grandin diff --git a/solenv/gbuild/platform/com_MSC_defs.mk b/solenv/gbuild/platform/com_MSC_defs.mk index 506cfbe7d30a..67aa47320c6c 100644 --- a/solenv/gbuild/platform/com_MSC_defs.mk +++ b/solenv/gbuild/platform/com_MSC_defs.mk @@ -104,7 +104,8 @@ gb_AFLAGS := $(AFLAGS) # C4706: assignment within conditional expression -MSVC_ANALYZE_FLAGS := -analyze:ruleset$(SRCDIR)/solenv/vs/LibreOffice.ruleset +# build-time penalty is to high for ci use/disable when JENKINS_HOME is set +MSVC_ANALYZE_FLAGS := $(if $(JENKINS_HOME),,-analyze:ruleset$(SRCDIR)/solenv/vs/LibreOffice.ruleset) gb_FilterOutClangCFLAGS += $(MSVC_ANALYZE_FLAGS)
[Bug 2067889] Re: DPDK 23.11.1 / OVS 3.3.0 cause test failures
The log message I have seen might be a red herring as well [1] added that but unless something insists on "non-ERR" that should not be the reason as it is not changing behavior. But then, what else am I looking for, Frode confirmed that he will do some triage and debug from the OVS POV which might help to find where things actually break. [1]: https://github.com/DPDK/dpdk- stable/commit/cbd1c165bb1ea86efc31c8ac309ee5e7c5f555cb -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2067889 Title: DPDK 23.11.1 / OVS 3.3.0 cause test failures To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/2067889/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [PATCH 01/18] drm/amdgpu: enhance amdgpu_ucode_request() function flexibility
Am 31.05.24 um 08:52 schrieb Yang Wang:
Adding formatting string feature to improve function flexibility.
Signed-off-by: Yang Wang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 30 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h | 3 ++-
2 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
index a9de78bb96e2..a452d9b6afdb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
@@ -28,6 +28,8 @@
#include "amdgpu.h"
#include "amdgpu_ucode.h"
+#define AMDGPU_MAX_FW_NAME_LEN (128)
Please drop that define and use NAME_MAX instead.
+
static void amdgpu_ucode_print_common_hdr(const struct common_firmware_header
*hdr)
{
DRM_DEBUG("size_bytes: %u\n", le32_to_cpu(hdr->size_bytes));
@@ -1432,28 +1434,40 @@ void amdgpu_ucode_ip_version_decode(struct
amdgpu_device *adev, int block_type,
*
* @adev: amdgpu device
* @fw: pointer to load firmware to
- * @fw_name: firmware to load
+ * @fmt: firmware name format string
+ * @...: variable arguments
*
* This is a helper that will use request_firmware and amdgpu_ucode_validate
* to load and run basic validation on firmware. If the load fails, remap
* the error code to -ENODEV, so that early_init functions will fail to load.
*/
int amdgpu_ucode_request(struct amdgpu_device *adev, const struct firmware
**fw,
-const char *fw_name)
+const char *fmt, ...)
{
- int err = request_firmware(fw, fw_name, adev->dev);
+ char fname[AMDGPU_MAX_FW_NAME_LEN];
+ va_list ap;
+ int r;
+
+ va_start(ap, fmt);
+ r = vsnprintf(fname, sizeof(fname), fmt, ap);
+ va_end(ap);
+ if (r == sizeof(fname)) {
+ dev_warn(adev->dev, "amdgpu firmware name buffer overflow\n");
+ return -EOVERFLOW;
+ }
- if (err)
+ r = request_firmware(fw, fname, adev->dev);
+ if (r)
return -ENODEV;
- err = amdgpu_ucode_validate(*fw);
- if (err) {
- dev_dbg(adev->dev, "\"%s\" failed to validate\n", fw_name);
+ r = amdgpu_ucode_validate(*fw);
+ if (r) {
+ dev_dbg(adev->dev, "\"%s\" failed to validate\n", fname);
release_firmware(*fw);
*fw = NULL;
}
- return err;
+ return r;
}
/*
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h
index db745ab7b0c8..5bc37acd3981 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h
@@ -594,8 +594,9 @@ void amdgpu_ucode_print_rlc_hdr(const struct
common_firmware_header *hdr);
void amdgpu_ucode_print_sdma_hdr(const struct common_firmware_header *hdr);
void amdgpu_ucode_print_psp_hdr(const struct common_firmware_header *hdr);
void amdgpu_ucode_print_gpu_info_hdr(const struct common_firmware_header
*hdr);
+__printf(3, 4)
int amdgpu_ucode_request(struct amdgpu_device *adev, const struct firmware
**fw,
-const char *fw_name);
+const char *fmt, ...);
That should probably have __printf() annotation so that the compiler can
check the format and arguments.
See here
https://elixir.free-electrons.com/linux/v6.10-rc2/source/include/linux/compiler_attributes.h#L171
Regards,
Christian.
void amdgpu_ucode_release(const struct firmware **fw);
bool amdgpu_ucode_hdr_version(union amdgpu_firmware_header *hdr,
uint16_t hdr_major, uint16_t hdr_minor);
Re: [PATCH v2 03/10] drm/amdgpu: abort fence poll if reset is started
Hi Shaoyun, yes my thinking goes into the same direction. The basic problem here is that we are trying to stuff two different information into the same variable. The first information is if the commands haven been read by the MES from the ring buffer. This information is necessary for the normal ring buffer and reset handling, e.g. prevents ring buffer overflow, ordering of command, lockups during reset etc... The second information is if a certain operation was successfully or not. For example this is necessary to get signaled back if y queue map/unmap operation has been successfully or if the CP not responding or any other error has happened etc... Another issue is that while it is in general a good idea to have the firmware work in a way where errors are reported instead of completely stopping all processing, here we run into trouble because the driver usually assumes that work can be scheduled on the ring buffer and a subsequent work is processed only when everything previously submitted has completed successfully. So as initial fix for the issue we see I've send Alex a patch on Friday to partially revert his change to use an individual writeback for each submission. Instead we will submit an addition QUERY_STATUS command after the real command and let that one write fence value. This way the fence value is always written, independent of the result of the operation. Additional to that we need to insert something like a dependency between submissions, e.g. when you have commands A, B and C on the ring and C can only execute when A was successfully then we need to somehow tell that the MES. Only other alternative is to not scheduler commands behind each other on the ring and that in turn is a bad idea from the performance point of view. Regards, Christian. Am 31.05.24 um 16:44 schrieb Liu, Shaoyun: [AMD Official Use Only - AMD Internal Distribution Only] Hi, Christian I think we have a discussion about this before . Alex also have a change that allow driver to use different write back address for the fence for each submission for the original issue . From MES point of view , MES will update the fence when the API can be complete successfully, so if the API (ex . remove_queue) fails due to other component issue (ex , CP hang), the MES will not update the fence In this situation , but MES itself still works and can respond to other commands (ex ,,read_reg) . Alex's change allow driver to check the fence for each API without mess around them . If you expect MES to stop responding to further commands after one API fails , that will introduce combability issue since this design already exist on products for customer and MES also need to works for windows . Also MES always need to respond to some commands like RESET etc that might make things worse if we need to change the logic . One possible solution is MES can trigger an Interrupt to indicate which submission has failed with the seq number . In this case driver can get the failure of the submission to MES in time and make its own decision for what to do next , What do you think about this ? Regards Shaoyun.liu -Original Message- From: amd-gfx On Behalf Of Christian König Sent: Wednesday, May 29, 2024 11:19 AM To: Li, Yunxiang (Teddy) ; Koenig, Christian ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH v2 03/10] drm/amdgpu: abort fence poll if reset is started Am 29.05.24 um 16:48 schrieb Li, Yunxiang (Teddy): [AMD Official Use Only - AMD Internal Distribution Only] Yeah, I know. That's one of the reason I've pointed out on the patch adding that that this behavior is actually completely broken. If you run into issues with the MES because of this then please suggest a revert of that patch. I think it just need to be improved to allow this force-signal behavior. The current behavior is slow/inconvenient, but the old behavior is wrong. Since MES will continue process submissions even when one submission failed. So with just one fence location there's no way to tell if a command failed or not. No the MES behavior is broken. When a submission failed it should stop processing or signal that the operation didn't completed through some other mechanism. Just not writing the fence and continuing results in tons of problems, from the TLB fence all the way to the ring buffer and reset handling. This is a hard requirement and really can't be changed. Regards, Christian.
[Bug 2067889] Re: DPDK 23.11.1 / OVS 3.3.0 cause test failures
Frode mentioned that OVS 3.3.1 might get some bonus love in regard to DPDK 23.11.1 [1]. In the past that was only ever needed for new features, which the stable update does not have, but there is a chance that this is just a test bug I do not yet understand fully - so yeah, giving this a look with OVS 3.3.1 might be worth a try. Worst case there is a chance that DPDK 23.11.1 only works with OVS >=3.3.1 which we need to express in dependencies than (which is odd as DPDK does not depend on OVS, but vice versa) Also adding a tag to show up in excuses, as this is what makes those stuck in proposed migration. ** Tags added: update-excuse -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2067889 Title: DPDK 23.11.1 / OVS 3.3.0 cause test failures To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/2067889/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[jira] [Created] (SLING-12345) Log import duration of each package
Christian Schneider created SLING-12345: --- Summary: Log import duration of each package Key: SLING-12345 URL: https://issues.apache.org/jira/browse/SLING-12345 Project: Sling Issue Type: Improvement Components: Content Distribution Reporter: Christian Schneider Assignee: Christian Schneider Fix For: Content Distribution Journal Core 0.4.0 We have a metric for import duration already but there it is not easy to connect the slow import to a specific package id. So we should also log the duration to get the connection explicitly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PATCH 1/2] amdgpu: add the amdgpu_vm ptr in the vm_bo_map/unmap events
Am 03.06.24 um 10:46 schrieb Pierre-Eric Pelloux-Prayer:
These 2 traces events are tied to a specific VM so in order for them
to be useful for a tool we need to trace the amdgpu_vm as well.
The bo_va already contains the VM pointer the map/unmap operation
belongs to.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 20
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 8
2 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
index f539b1d00234..c84050d318d6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -243,10 +243,11 @@ TRACE_EVENT(amdgpu_vm_grab_id,
);
TRACE_EVENT(amdgpu_vm_bo_map,
- TP_PROTO(struct amdgpu_bo_va *bo_va,
+ TP_PROTO(struct amdgpu_vm *vm, struct amdgpu_bo_va *bo_va,
struct amdgpu_bo_va_mapping *mapping),
- TP_ARGS(bo_va, mapping),
+ TP_ARGS(vm, bo_va, mapping),
TP_STRUCT__entry(
+__field(struct amdgpu_vm *, vm)
__field(struct amdgpu_bo *, bo)
__field(long, start)
__field(long, last)
@@ -255,22 +256,24 @@ TRACE_EVENT(amdgpu_vm_bo_map,
),
TP_fast_assign(
+ __entry->vm = vm;
__entry->bo = bo_va ? bo_va->base.bo : NULL;
__entry->start = mapping->start;
__entry->last = mapping->last;
__entry->offset = mapping->offset;
__entry->flags = mapping->flags;
),
- TP_printk("bo=%p, start=%lx, last=%lx, offset=%010llx, flags=%llx",
- __entry->bo, __entry->start, __entry->last,
+ TP_printk("vm=%p bo=%p, start=%lx, last=%lx, offset=%010llx,
flags=%llx",
+ __entry->vm, __entry->bo, __entry->start, __entry->last,
__entry->offset, __entry->flags)
);
TRACE_EVENT(amdgpu_vm_bo_unmap,
- TP_PROTO(struct amdgpu_bo_va *bo_va,
+ TP_PROTO(struct amdgpu_vm *vm, struct amdgpu_bo_va *bo_va,
struct amdgpu_bo_va_mapping *mapping),
- TP_ARGS(bo_va, mapping),
+ TP_ARGS(vm, bo_va, mapping),
TP_STRUCT__entry(
+__field(struct amdgpu_vm *, vm)
__field(struct amdgpu_bo *, bo)
__field(long, start)
__field(long, last)
@@ -279,14 +282,15 @@ TRACE_EVENT(amdgpu_vm_bo_unmap,
),
TP_fast_assign(
+ __entry->vm = vm;
__entry->bo = bo_va ? bo_va->base.bo : NULL;
__entry->start = mapping->start;
__entry->last = mapping->last;
__entry->offset = mapping->offset;
__entry->flags = mapping->flags;
),
- TP_printk("bo=%p, start=%lx, last=%lx, offset=%010llx, flags=%llx",
- __entry->bo, __entry->start, __entry->last,
+ TP_printk("vm=%p bo=%p, start=%lx, last=%lx, offset=%010llx,
flags=%llx",
+ __entry->vm, __entry->bo, __entry->start, __entry->last,
__entry->offset, __entry->flags)
);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 3abfa66d72a2..e04928d2e26a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1642,7 +1642,7 @@ static void amdgpu_vm_bo_insert_map(struct amdgpu_device
*adev,
if (amdgpu_vm_is_bo_always_valid(vm, bo) && !bo_va->base.moved)
amdgpu_vm_bo_moved(_va->base);
- trace_amdgpu_vm_bo_map(bo_va, mapping);
+ trace_amdgpu_vm_bo_map(vm, bo_va, mapping);
}
/* Validate operation parameters to prevent potential abuse */
@@ -1834,7 +1834,7 @@ int amdgpu_vm_bo_unmap(struct amdgpu_device *adev,
list_del(>list);
amdgpu_vm_it_remove(mapping, >va);
mapping->bo_va = NULL;
- trace_amdgpu_vm_bo_unmap(bo_va, mapping);
+ trace_amdgpu_vm_bo_unmap(vm, bo_va, mapping);
if (valid)
list_add(>list, >freed);
@@ -1929,7 +1929,7 @@ int amdgpu_vm_bo_clear_mappings(struct amdgpu_device
*adev,
tmp->bo_va = NULL;
list_add(>list, >freed);
- trace_amdgpu_vm_bo_unmap(NULL, tmp);
+ trac
Bug#1072515: general: Repeating cracking sound in headphones when nothing is playing.
Package: general Severity: normal X-Debbugs-Cc: deb...@funtech.org Dear Maintainer, when using headphones with my laptop (Thinkpad W550s) I get a repeating cracking (~1sec intervalls) when nothing is playing. *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I used headphones for the first time with Debian. * What exactly did you do (or not do) that was effective (or ineffective)? I can't find a fitting setting, so I did nothing. * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines ***
Bug#1072515: general: Repeating cracking sound in headphones when nothing is playing.
Package: general Severity: normal X-Debbugs-Cc: deb...@funtech.org Dear Maintainer, when using headphones with my laptop (Thinkpad W550s) I get a repeating cracking (~1sec intervalls) when nothing is playing. *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I used headphones for the first time with Debian. * What exactly did you do (or not do) that was effective (or ineffective)? I can't find a fitting setting, so I did nothing. * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines ***
[Bug 2067889] Re: DPDK 23.11.1 / OVS 3.3.0 cause test failures
** Attachment added: "ovs-vswitchd-bad-23.11.1-1.log" https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/2067889/+attachment/5785493/+files/ovs-vswitchd-bad-23.11.1-1.log -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2067889 Title: DPDK 23.11.1 / OVS 3.3.0 cause test failures To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/2067889/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2067889] Re: DPDK 23.11.1 / OVS 3.3.0 cause test failures
** Attachment added: "ovs-vswitchd-good-23.11-1.log" https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/2067889/+attachment/5785494/+files/ovs-vswitchd-good-23.11-1.log -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2067889 Title: DPDK 23.11.1 / OVS 3.3.0 cause test failures To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/2067889/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2067889] Re: DPDK 23.11.1 / OVS 3.3.0 cause test failures
** Attachment added: "just the log section of the failures" https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/2067889/+attachment/5785468/+files/dpdk-ovs-test-fail-log.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2067889 Title: DPDK 23.11.1 / OVS 3.3.0 cause test failures To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/2067889/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2067889] Re: DPDK 23.11.1 / OVS 3.3.0 cause test failures
The only very unique entry I got here in those logs of the dpdk enabled openvswitch in the bad case was: 1|dpdk|ERR|TELEMETRY: Socket write base info to client failed Not sure where to go with that, is that from the switch or the client even? I might need to reach out if there are any known issues where, now that I have some pointers, this rings a bell. ** Also affects: openvswitch (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2067889 Title: DPDK 23.11.1 / OVS 3.3.0 cause test failures To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/2067889/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2067889] Re: DPDK 23.11.1 / OVS 3.3.0 cause test failures
23.11.1-1 console output
root@o-dpdk-ovs:~# systemctl stop openvswitch-switch ovs-vswitchd
root@o-dpdk-ovs:~# rm /var/log/openvswitch/ovs-vswitchd.log
root@o-dpdk-ovs:~# systemctl start openvswitch-switch ovs-vswitchd
root@o-dpdk-ovs:~# ovs-vsctl show
9a966e25-a911-45d1-a5ad-1beeb7c142a1
ovs_version: "3.3.0"
root@o-dpdk-ovs:~# ovs-vsctl add-br br10 -- set bridge br10 datapath_type=netdev
root@o-dpdk-ovs:~#
OVS_RUNDIR="/tmpdir/_debian/tests/system-dpdk-testsuite.dir/020"
root@o-dpdk-ovs:~# rm -rf $OVS_RUNDIR
root@o-dpdk-ovs:~# mkdir -p $OVS_RUNDIR
root@o-dpdk-ovs:~# ovs-vsctl add-port br10 dpdkvhostuserclient0 -- set
Interface dpdkvhostuserclient0 type=dpdkvhostuserclient
options:vhost-server-path=$OVS_RUNDIR/dpdkvhostclient0
root@o-dpdk-ovs:~# ovs-vsctl show
9a966e25-a911-45d1-a5ad-1beeb7c142a1
Bridge br10
datapath_type: netdev
Port dpdkvhostuserclient0
Interface dpdkvhostuserclient0
type: dpdkvhostuserclient
options:
{vhost-server-path="/tmpdir/_debian/tests/system-dpdk-testsuite.dir/020/dpdkvhostclient0"}
Port br10
Interface br10
type: internal
ovs_version: "3.3.0"
root@o-dpdk-ovs:~# ovs-vsctl get Interface dpdkvhostuserclient0 link_state
up
root@o-dpdk-ovs:~# ovs-vsctl set Interface dpdkvhostuserclient0 mtu_request=9702
root@o-dpdk-ovs:~# ovs-vsctl get Interface dpdkvhostuserclient0 mtu
9702
root@o-dpdk-ovs:~# ovs-vsctl set Interface dpdkvhostuserclient0 mtu_request=9711
root@o-dpdk-ovs:~# ovs-vsctl get Interface dpdkvhostuserclient0 mtu
9702
root@o-dpdk-ovs:~# ovs-vsctl del-port br10 dpdkvhostuserclient0
root@o-dpdk-ovs:~# ovs-vsctl del-br br10
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2067889
Title:
DPDK 23.11.1 / OVS 3.3.0 cause test failures
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/2067889/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2067889] Re: DPDK 23.11.1 / OVS 3.3.0 cause test failures
From here I was capturing full logs of this with DPDK 23.11-1 and
23.11.1-1
23.11-1 console output:
root@o-dpdk-ovs:~# systemctl stop openvswitch-switch ovs-vswitchd
root@o-dpdk-ovs:~# rm /var/log/openvswitch/ovs-vswitchd.log
root@o-dpdk-ovs:~# systemctl start openvswitch-switch ovs-vswitchd
root@o-dpdk-ovs:~# ovs-vsctl show
9a966e25-a911-45d1-a5ad-1beeb7c142a1
ovs_version: "3.3.0"
root@o-dpdk-ovs:~# ovs-vsctl add-br br10 -- set bridge br10 datapath_type=netdev
root@o-dpdk-ovs:~#
OVS_RUNDIR="/tmpdir/_debian/tests/system-dpdk-testsuite.dir/020"
root@o-dpdk-ovs:~# rm -rf $OVS_RUNDIR
root@o-dpdk-ovs:~# mkdir -p $OVS_RUNDIR
root@o-dpdk-ovs:~# ovs-vsctl add-port br10 dpdkvhostuserclient0 -- set
Interface dpdkvhostuserclient0 type=dpdkvhostuserclient
options:vhost-server-path=$OVS_RUNDIR/dpdkvhostclient0
root@o-dpdk-ovs:~# ovs-vsctl show
9a966e25-a911-45d1-a5ad-1beeb7c142a1
Bridge br10
datapath_type: netdev
Port dpdkvhostuserclient0
Interface dpdkvhostuserclient0
type: dpdkvhostuserclient
options:
{vhost-server-path="/tmpdir/_debian/tests/system-dpdk-testsuite.dir/020/dpdkvhostclient0"}
Port br10
Interface br10
type: internal
ovs_version: "3.3.0"
root@o-dpdk-ovs:~# ovs-vsctl get Interface dpdkvhostuserclient0 link_state
up
root@o-dpdk-ovs:~# ovs-vsctl set Interface dpdkvhostuserclient0 mtu_request=9702
root@o-dpdk-ovs:~# ovs-vsctl get Interface dpdkvhostuserclient0 mtu
9702
root@o-dpdk-ovs:~# ovs-vsctl set Interface dpdkvhostuserclient0 mtu_request=9711
root@o-dpdk-ovs:~# ovs-vsctl get Interface dpdkvhostuserclient0 mtu
9702
root@o-dpdk-ovs:~# ovs-vsctl del-port br10 dpdkvhostuserclient0
root@o-dpdk-ovs:~# ovs-vsctl del-br br10
root@o-dpdk-ovs:~# ovs-vsctl show
9a966e25-a911-45d1-a5ad-1beeb7c142a1
ovs_version: "3.3.0"
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2067889
Title:
DPDK 23.11.1 / OVS 3.3.0 cause test failures
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/2067889/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2067889] Re: DPDK 23.11.1 / OVS 3.3.0 cause test failures
Trying to isolate the commands used in the failing test (works in a not too small Oracular VM): 0. Prep install and config apt install openvswitch-switch-dpdk dpdk-dev echo "NR_2M_PAGES=784" >> /etc/dpdk/dpdk.conf systemctl restart dpdk update-alternatives --set ovs-vswitchd /usr/lib/openvswitch-switch-dpdk/ovs-vswitchd-dpdk ovs-vsctl --no-wait init ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-extra="--log-level=pmd.*:error --no-pci" 1. start OVS with DPDK support (this is the point where you'd restart new test iterations) systemctl stop openvswitch-switch ovs-vswitchd rm /var/log/openvswitch/ovs-vswitchd.log systemctl start openvswitch-switch ovs-vswitchd ovs-vsctl show 2. create an internal DPDK bridge with a vhostuserclient port with defined MTU ovs-vsctl add-br br10 -- set bridge br10 datapath_type=netdev OVS_RUNDIR="/tmpdir/_debian/tests/system-dpdk-testsuite.dir/020" rm -rf $OVS_RUNDIR mkdir -p $OVS_RUNDIR ovs-vsctl add-port br10 dpdkvhostuserclient0 -- set Interface dpdkvhostuserclient0 type=dpdkvhostuserclient options:vhost-server-path=$OVS_RUNDIR/dpdkvhostclient0 ovs-vsctl show 3. connect a vhostuserclient server # Do this in a shell of its own, it will stay up dpdk-testpmd --in-memory --socket-mem=512 --single-file-segments --no-pci --vdev="net_virtio_user,path=$OVS_RUNDIR/dpdkvhostclient0,server=1 --vdev=net_tap0,iface=tap0 -- -a --stats-period 2 --nb-cores 2 --rxq 2 --txq 2 4. check if it is truly ready ovs-vsctl show grep "virtio is now ready for processing" /var/log/openvswitch/ovs-vswitchd.log # should have a happy dpdkvhostuserclient0 ovs-vsctl get Interface dpdkvhostuserclient0 link_state # should say "up" 5. set happy MTU ovs-vsctl set Interface dpdkvhostuserclient0 mtu_request=9702 ovs-vsctl get Interface dpdkvhostuserclient0 mtu # should deliver 9702 6. set the bigger MTU ovs-vsctl set Interface dpdkvhostuserclient0 mtu_request=9711 # the ovs-vswitchd.log will say (expected) dpdkvhostuserclient0: unsupported MTU 9711 failed to set MTU for network device dpdkvhostuserclient0: Invalid argument ovs-vsctl get Interface dpdkvhostuserclient0 mtu # will still deliver 9702 7. cleanup the port ovs-vsctl del-port br10 dpdkvhostuserclient0 # Should work without bad RC, log in ovs-vswitchd.log will say: bridge|INFO|bridge br10: deleted interface dpdkvhostuserclient0 on port 1 dpif_netdev|INFO|PMD thread on numa_id: 0, core id: 1 destroyed. dpdk(pmd-c01/id:8)|INFO|PMD thread released DPDK lcore 1. dpdk|INFO|VHOST_CONFIG: (/tmpdir/_debian/tests/system-dpdk-testsuite.dir/020/dpdkvhostclient0) free connfd 50 netdev_dpdk|INFO|vHost Device '/tmpdir/_debian/tests/system-dpdk-testsuite.dir/020/dpdkvhostclient0' not found ovs-vsctl del-br br10 ovs-vsctl show # should show an empty switch ^^ Here I expected the issue with the new code (OVS + DPDK being new). But sadly I have proven that the "not found" on the path was a red herring as well. It comes up in the good path as well. The good case just does not push the log output to the test-output. Hence it seemed to be an issue "only in the bad case" but that was a fluke. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2067889 Title: DPDK 23.11.1 / OVS 3.3.0 cause test failures To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/2067889/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2067889] Re: DPDK 23.11.1 / OVS 3.3.0 cause test failures
Again, is that the root cause or a symptom of a former failure? Not all tests are very clear in that regard, but one I liked. As it fails BEFORE this cleanup phase. The "MTU upper bound vport port" test is like this: > 2024-05-31T10:08:28.364Z|00117|netdev_dpdk|WARN|dpdkvhostuserclient0: > unsupported MTU 9711 > 2024-05-31T10:08:28.364Z|00118|netdev|WARN|failed to set MTU for network > device dpdkvhostuserclient0: Invalid argument > 2024-05-31T10:08:28.374Z|00119|bridge|INFO|bridge br10: deleted interface > dpdkvhostuserclient0 on port 1 > 2024-05-31T10:08:28.374Z|00120|dpif_netdev|INFO|PMD thread on numa_id: 0, > core id: 3 destroyed. > 2024-05-31T10:08:28.374Z|2|dpdk(pmd-c03/id:10)|INFO|PMD thread released > DPDK lcore 1. > 2024-05-31T10:08:28.375Z|00121|dpdk|INFO|VHOST_CONFIG: > (/tmpdir/_debian/tests/system-dpdk-testsuite.dir/020/dpdkvhostclient0) free > connfd 52 > 2024-05-31T10:08:28.375Z|00122|netdev_dpdk|INFO|vHost Device > '/tmpdir/_debian/tests/system-dpdk-testsuite.dir/020/dpdkvhostclient0' not > found tests/system-dpdk-testsuite: line 1754: 275858 Killed dpdk-testpmd $eal_options -- $testpmd_options > testpmd.log 2>&1 20. system-dpdk.at:736: 20. OVS-DPDK - MTU upper bound vport port (system-dpdk.at:736): FAILED (system-dpdk.at:767) But this is a red-herring, as the setting of this is meant to fail. The test says: "Set MTU value above upper bound and check for error" So it might indeed be the cleanup that fails? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2067889 Title: DPDK 23.11.1 / OVS 3.3.0 cause test failures To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/2067889/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2067889] Re: DPDK 23.11.1 / OVS 3.3.0 cause test failures
After that one knows which sub-log to check, for ease of consumption I've attached the subsection here that talks about the actually failing tests. Fail #1 /tmpdir/_debian/tests/system-dpdk-testsuite.dir/004/cleanup: line 1: kill: (275003) - No such process 4. system-dpdk.at:102: 4. OVS-DPDK - ping vhost-user ports (system-dpdk.at:102): FAILED (system-dpdk.at:148) Fail #2 > 2024-05-31T10:08:11.896Z|00087|dpdk|INFO|VHOST_CONFIG: > (/tmpdir/_debian/tests/system-dpdk-testsuite.dir/005/dpdkvhostclient0) free > connfd 52 > 2024-05-31T10:08:11.896Z|00088|netdev_dpdk|INFO|vHost Device > '/tmpdir/_debian/tests/system-dpdk-testsuite.dir/005/dpdkvhostclient0' not > found tests/system-dpdk-testsuite: line 1754: 275274 Killed dpdk-testpmd $eal_options -- $testpmd_options > testpmd.log 2>&1 5. system-dpdk.at:158: 5. OVS-DPDK - ping vhost-user-client ports (system-dpdk.at:158): FAILED (system-dpdk.at:224) Fail #3 > 2024-05-31T10:08:17.179Z|00120|dpdk|INFO|VHOST_CONFIG: > (/tmpdir/_debian/tests/system-dpdk-testsuite.dir/016/dpdkvhostclient0) free > connfd 52 > 2024-05-31T10:08:17.179Z|00121|netdev_dpdk|INFO|vHost Device > '/tmpdir/_debian/tests/system-dpdk-testsuite.dir/016/dpdkvhostclient0' not > found tests/system-dpdk-testsuite: line 1754: 275495 Killed dpdk-testpmd $eal_options -- $testpmd_options > testpmd.log 2>&1 16. system-dpdk.at:577: 16. OVS-DPDK - MTU increase vport port (system-dpdk.at:577): FAILED (system-dpdk.at:609) Fail #4 > 2024-05-31T10:08:22.436Z|00079|dpdk|INFO|VHOST_CONFIG: > (/tmpdir/_debian/tests/system-dpdk-testsuite.dir/017/dpdkvhostclient0) free > connfd 52 > 2024-05-31T10:08:22.436Z|00080|netdev_dpdk|INFO|vHost Device > '/tmpdir/_debian/tests/system-dpdk-testsuite.dir/017/dpdkvhostclient0' not > found tests/system-dpdk-testsuite: line 1767: 275658 Killed dpdk-testpmd $eal_options -- $testpmd_options > testpmd.log 2>&1 17. system-dpdk.at:618: 17. OVS-DPDK - MTU decrease vport port (system-dpdk.at:618): FAILED (system-dpdk.at:651) Fail #5 > 2024-05-31T10:08:28.375Z|00121|dpdk|INFO|VHOST_CONFIG: > (/tmpdir/_debian/tests/system-dpdk-testsuite.dir/020/dpdkvhostclient0) free > connfd 52 > 2024-05-31T10:08:28.375Z|00122|netdev_dpdk|INFO|vHost Device > '/tmpdir/_debian/tests/system-dpdk-testsuite.dir/020/dpdkvhostclient0' not > found tests/system-dpdk-testsuite: line 1754: 275858 Killed dpdk-testpmd $eal_options -- $testpmd_options > testpmd.log 2>&1 20. system-dpdk.at:736: 20. OVS-DPDK - MTU upper bound vport port (system-dpdk.at:736): FAILED (system-dpdk.at:767) Fail #6 > 2024-05-31T10:08:32.113Z|00079|dpdk|INFO|VHOST_CONFIG: > (/tmpdir/_debian/tests/system-dpdk-testsuite.dir/021/dpdkvhostclient0) free > connfd 52 > 2024-05-31T10:08:32.113Z|00080|netdev_dpdk|INFO|vHost Device > '/tmpdir/_debian/tests/system-dpdk-testsuite.dir/021/dpdkvhostclient0' not > found tests/system-dpdk-testsuite: line 1767: 276061 Killed dpdk-testpmd $eal_options -- $testpmd_options > testpmd.log 2>&1 21. system-dpdk.at:778: 21. OVS-DPDK - MTU lower bound vport port (system-dpdk.at:778): FAILED (system-dpdk.at:809) They seem to all stumble over some cleanup. The question now is if that is a symptom (something before goes wrong, and then we see the cleanup path go nuts). Or if it is the root cause (it always cleaned up, but now it no more works). It seems the sequence here is always to the end of the actual tests. There it deletes interfaces, but then breaks on the associated file not existing. But is that really the issue that changed? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2067889 Title: DPDK 23.11.1 / OVS 3.3.0 cause test failures To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/2067889/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2067889] Re: DPDK 23.11.1 / OVS 3.3.0 cause test failures
One has to realize, even the good path hits the cleanup function, but entered with rc=0. It then cleans up and exits with the RC it got. The bad case OTOH seems to do parts of the cleanup function, but not all of it. It ends the tests, with more successful tests (151) but then enters cleanup with a bad RC. Note: There is also an autopkgtest/nova issue in the bad log: 5063s /home/ubuntu/autopkgtest/ssh-setup/nova: 234: [: x86_64: unexpected operator 5063s /home/ubuntu/autopkgtest/ssh-setup/nova: 237: [: x86_64: unexpected operator But myself and bryce think this is an orthogonal issue. Diving into the log a bit deeper made me find: 4: OVS-DPDK - ping vhost-user portsFAILED (system-dpdk.at:148) 5: OVS-DPDK - ping vhost-user-client ports FAILED (system-dpdk.at:224) 16: OVS-DPDK - MTU increase vport port FAILED (system-dpdk.at:609) 17: OVS-DPDK - MTU decrease vport port FAILED (system-dpdk.at:651) 20: OVS-DPDK - MTU upper bound vport port FAILED (system-dpdk.at:767) 21: OVS-DPDK - MTU lower bound vport port FAILED (system-dpdk.at:809) The partial confusion is from the test running multiple suites: => openvswitch-afxdp-testsuite Good 136 skip 39 => system-dpdk-testsuite Good 142 skip 49 Fail 6 => system-userspace-testsuite Good 151 skip 36 => system-offloads-testsuite Good 152 skip 33 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2067889 Title: DPDK 23.11.1 / OVS 3.3.0 cause test failures To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/2067889/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2067889] Re: DPDK 23.11.1 / OVS 3.3.0 cause test failures
Oracular OVS bad test with DPDK 23.11.1-1 https://autopkgtest.ubuntu.com/results/autopkgtest-oracular/oracular/amd64/o/openvswitch/20240531_100906_6f957@/log.gz 5047s 151 tests were successful. 5047s 36 tests were skipped. 5047s + update-alternatives --set ovs-vswitchd /usr/lib/openvswitch-switch/ovs-vswitchd 5047s update-alternatives: using /usr/lib/openvswitch-switch/ovs-vswitchd to provide /usr/sbin/ovs-vswitchd (ovs-vswitchd) in manual mode 5047s /tmp/autopkgtest.62SGkT/build.KmH/src 5047s + dirs +1 5047s + popd 5047s + umount /UZ4 5047s + rmdir /UZ4 5047s + exit 1 Oracular OVS good test with DPDK 23.11-1 https://autopkgtest.ubuntu.com/results/autopkgtest-oracular/oracular/amd64/o/openvswitch/20240529_111623_6f8db@/log.gz 4957s 148 tests were successful. 4957s 49 tests were skipped. 4957s + cleanup 4957s + rc=0 4957s + set +e 4957s + '[' 0 -ne 0 ']' 4957s + '[' -L /usr/bin/nc ']' 4957s + rm -f /usr/bin/nc 4957s + '[' dpdk = dpdk ']' 4957s + mv /etc/dpdk/dpdk.conf.bak /etc/dpdk/dpdk.conf 4957s + systemctl restart dpdk 4957s + update-alternatives --set ovs-vswitchd /usr/lib/openvswitch-switch/ovs-vswitchd 4957s update-alternatives: using /usr/lib/openvswitch-switch/ovs-vswitchd to provide /usr/sbin/ovs-vswitchd (ovs-vswitchd) in manual mode 4957s /tmp/autopkgtest.vQL7uJ/build.4Ev/src 4957s + dirs +1 4957s + popd 4957s + umount /S31 4957s + rmdir /S31 4957s + exit 0 The arches that worked are no counter to that: dpdk SKIP exit status 77 and marked as skippable Theory, legit issue with the new DPDK breaking the OVS testcase -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2067889 Title: DPDK 23.11.1 / OVS 3.3.0 cause test failures To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/2067889/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2067889] [NEW] DPDK 23.11.1 / OVS 3.3.0 cause test failures
Public bug reported: https://autopkgtest.ubuntu.com/packages/o/openvswitch/oracular/amd64 Bad Oracular OVS test with DPDK 23.11.1-1 https://autopkgtest.ubuntu.com/results/autopkgtest-oracular/oracular/amd64/o/openvswitch/20240531_100906_6f957@/log.gz Good Oracular OVS test with DPDK 23.11-1 https://autopkgtest.ubuntu.com/results/autopkgtest-oracular/oracular/amd64/o/openvswitch/20240529_111623_6f8db@/log.gz The logs are messy to read if not used to it, this is a try at debugging what is going wrong. So far it seems other people have retried 14 times, and 14714 fail at the same tests - I think there is a real issue. As shown below, one can find always these fail: 4: OVS-DPDK - ping vhost-user portsFAILED (system-dpdk.at:148) 5: OVS-DPDK - ping vhost-user-client ports FAILED (system-dpdk.at:224) 16: OVS-DPDK - MTU increase vport port FAILED (system-dpdk.at:609) 17: OVS-DPDK - MTU decrease vport port FAILED (system-dpdk.at:651) 20: OVS-DPDK - MTU upper bound vport port FAILED (system-dpdk.at:767) 21: OVS-DPDK - MTU lower bound vport port FAILED (system-dpdk.at:809) ** Affects: dpdk (Ubuntu) Importance: Undecided Status: New ** Affects: openvswitch (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2067889 Title: DPDK 23.11.1 / OVS 3.3.0 cause test failures To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/2067889/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [SOGo] Missing SOGoTemplatesFolderName in sogo.conf
Hello Am 31.05.24 um 11:44 schrieb Ing. Zdeněk Havránek, HAF (h...@hafici.eu): I'm from the Czech Republic and I need to set SOGoTemplatesFolderName similarly to other folder names (SOGoSentFolderName, SOGoDraftsFolderName, ...) This parameter is missing in chapter 5.13. IMAP Server Configuration. This option already works, it is only missing in the documentation. You could create a bug report for this at https://sogo.nu/bugs Kind regards, Christian Mack -- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung, Lehre, Infrastruktur 78457 Konstanz +49 7531 88-4416 smime.p7s Description: Kryptografische S/MIME-Signatur
Re: [SOGo] Laggy and slow web interface when replying to large emails
Hello Am 01.06.24 um 07:48 schrieb Kenren Taisho (toushin.tai...@gmail.com): Hi. We are experiencing a very laggy and slow web interface when replying to emails involving many message exchanges between them. It does not show the same behavior for new messages or messages with few replies. I am running my SOGo server in a physical server with adequate CPU/RAM and IO so I don't think it's a resource issue. My hardware is as follows: CPU: Intel(R) Xeon(R) Silver 4214 CPU @ 2.20GHz (24 core) RAM: 64G Storage: Raid10 (HW Controller H730P) SOGo is running on AlmaLinux v8.10 I am running SOGo 5.10.0 (production stable release) Hoping for your support and guidance regarding the matter. I assume, you are hit by the following bug in the HTML editor. See https://bugs.sogo.nu/view.php?id=5944 You (and we) have to wait for the next release for this fix. Kind regards, Christian Mack -- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung, Lehre, Infrastruktur 78457 Konstanz +49 7531 88-4416 smime.p7s Description: Kryptografische S/MIME-Signatur
Re: [SOGo] [SPAM] Is it possible to backup and restore SOGo calendar and contact information with MySQL database backup?
Hello Am 02.06.24 um 22:47 schrieb Paul Leiber (p...@onlineschubla.de): Dear SOGo users, Due to some unknown circumstance, I seem to have lost all my personal contact and calendar information in SOGo. I have been using MySQL backup functionality (mariadb-backup) to regularly back up the complete MySQL database, including the SOGo database. Now, when trying to restore the database, the calendar and contact information stays empty, independent from the specific backup I am restoring. I also noticed that the file sizes of the database files created by mariadb-backup are more or less identical and do not change over time. To narrow down the error, I would like to know if it is possible in principle to backup SOGo calendar and contact information by backing up the MySQL database, like I did (or better tried to do). If this is possible, then I seem to have made an error while backing up or restoring the database. If this is not possible, then I don't need to work on the MySQL part. Any other help is of course also appreciated. And a +1 for always testing restoration when implementing a backup strategy to avoid situations like mine... MariaDB Backup should contain all data for calendars, address books and settings. Did you backup the data too, or only the table structure? (You can see the data inside "INSERT" statements.) Kind regards, Christian Mack -- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung, Lehre, Infrastruktur 78457 Konstanz +49 7531 88-4416 smime.p7s Description: Kryptografische S/MIME-Signatur
Re: [SOGo] SOGo nightly on debian: SOGo Restart causes error "listening socket: attempt n failed"
Hello Am 02.06.24 um 22:32 schrieb Paul Leiber (p...@onlineschubla.de): Am 29.05.2024 um 21:52 schrieb Paul Leiber: [...] For finding the cause of the above behavior, I am often changing configuration, which requires me to restart SOGo. However, when restarting SOGo with "systemctl restart sogo", sogo is not functional anymore and the following log entries come up: May 29 21:41:02 sogod [2058]: [WARN] <0x0x557824d99d10[WOWatchDog]> listening socket: attempt 1 failed May 29 21:41:03 sogod [2058]: [WARN] <0x0x557824d99d10[WOWatchDog]> listening socket: attempt 2 failed May 29 21:41:04 sogod [2058]: [WARN] <0x0x557824d99d10[WOWatchDog]> listening socket: attempt 3 failed May 29 21:41:05 sogod [2058]: [WARN] <0x0x557824d99d10[WOWatchDog]> listening socket: attempt 4 failed May 29 21:41:06 sogod [2058]: [WARN] <0x0x557824d99d10[WOWatchDog]> listening socket: attempt 5 failed May 29 21:41:07 sogod [2058]: [ERROR] <0x0x557824d99d10[WOWatchDog]> unable to listen on specified port, check that no other process is already using it A reboot leads to a functional sogo system (besides the issues mentioned above), but takes quite some time. In the past, I didn't observe this behavior. FYI: With the current nightly, restarting sogo with systemd is working again. I do not think that this has to do with the nightly build. I only get those error messages, if stopping sogo didn't stop all workers, before it starts sogo again. Then the sockets are still in use by an outdated worker. This especially happens with long running workers, used for e.g. ActiveSync. Therefore I stop sogo, then test with ps command if all workers are really stopped, before starting it again. Kind regards, Christian Mack -- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung, Lehre, Infrastruktur 78457 Konstanz +49 7531 88-4416 smime.p7s Description: Kryptografische S/MIME-Signatur
[MBS] [ANN] 14.3pr1
Hi, Let's start a new round for MBS Plugin development: * Added Python functions. * Added Plugin.LockedFunctions function. * Enhanced execute button for calculation dialog to allow pressing option key to only evaluate the selected text. * Updated for future FileMaker version. * Improved variable auto completion to better handle custom functions starting with underscore. * Updated to newer plugin SDK for FileMaker 21. * Fixed problem with JSON returning negative floating point numbers without leading 0. * Updated to Xcode 15.4. * Updated SQLAPI to version 5.3.2. * Fixed the WordFile.ReplaceTag function, which broke in 14.2. * Improved the formatting code for calculations to handle special words like or and and better. * Update LibXL libraries for macOS and Windows to version 4.3. * Fixed a bug in WebLink() function in DynaPDFMBS class returning negative number. * Changed XL.Book.Version to have the book parameter optional. * Added EmailParser.ReleaseAll function. * Renamed EmailParser.Free to EmailParser.Release, but old name will stay valid. * Fixed a memory leak in loading Excel file from disk with XL.LoadBook function. * Fixed a problem with XL functions where license key was not recognized properly. * Fixed a problem with copying script text would duplicate field names or calculations. * Changed trace function to not log the password for a Files.Mount call. * Added check to XL.Initialize and DynaPDF.Initialize to return an error if the license key includes invalid characters like a space character. * Added Mutex.ReleaseAll function. * Renamed Mutex.Free to Mutex.Release, but old name will stay valid. * Updated SQLite to version 3.46.0. * Updated our ICU integration for SQLite to the new SQLite version. * Updated DynaPDF to version 4.0.87.251. * Enhanced format button for calculation dialog to allow pressing shift key to only format the selected text. * Updated curl to version 8.8.0 * Enhanced check syntax button for calculation dialog to allow pressing shift key to only check the selected text. Download at https://www.monkeybreadsoftware.com/filemaker/files/Prerelease/ or ask for being added to the DropBox shared folder. Please also go to the FM Soup forum and setup "Watching First Post" for the MBS category, so you get an email when I start my pre-release topic. Then once you see that, please put the topic on watching, so you get an email for every new posting from me. https://the.fmsoup.org/c/plugins/mbs-plugins/58 Best regards, Christian -- Read our blog about news on our plugins: http://www.mbsplugins.de/ ___ MBS FM Plugin mailing list -- mbsfmplugin@lists.monkeybreadsoftware.com To unsubscribe send an email to mbsfmplugin-le...@lists.monkeybreadsoftware.com
Re: Free(opensource) Ticketing solutions
The google incantation you're looking for is "task management software" or "task management software for teams". Commercial solutions are things like Monday.com or asana. There are lots of alternatives here as well depending on your workflow and needed feature set, and both open source and commercial solutions are available. On Sun, Jun 2, 2024, 11:45 PM Saku Ytti wrote: > This threat is interesting to me, but I'm surprised how no > requirements or use-cases are mentioned. > > Like what is OP trying to do? > > Looking at some of the proposals, it's obvious some of them are > intended for use cases where one side is an external party with email, > and one side is an internal party with application. And this system > would be obviously terribly for internal use, where teams ask each > other to do things via the system. > > I find the customer facing ticketing system a far easier problem, than > the internal one. > > For the internal one, my MVP requirements would be > - Everyone has their own ticket view, and see just tickets that > are actionable to them, right now > - Tickets can have dependencies, maybe I've been assigned a > ticket, and I figure out what I need to do, and what I need from > others to do it, so I can create new tickets and have my ticket depend > on them. This way I can get my ticket out of my view, until > dependencies are solved, in which case I get it back > - Tickets could have parent and child, where parent automatically > tracks progress through children, perhaps my parent ticket is 'enabled > ISIS' and I have child ticket for each device. > - API for users, not just developers - I strongly believe the > market has understood UX wrong, I believe WebUX is great for problems > where users use the UX rarely, but CliUX actually is desirable by > users and management for problems where users use the UX every day > hours on end. The Cli/Curses UX is blazing fast and predictable > layout, so after onboarding, users don't even look at the screen and > are exceedingly efficient. When I check-in to a hotel, buy a SIM or > rent a car, I often have to wait silently when the clerk spends > literally 10min clicking and typing, on the most common use case they > have. I don't expect market to ever agree, but at least if it has API, > I can write my own CliUX to be fast on the couple things I need to do > > > The commercial solutions I've used, Remedy and ServiceNow are > absolutely horrible, and it shocks me this is the state of the art. > Companies where those are used, you have to force employees to use > them, and if you are senior enough that rules don't apply, you don't > use it, because it's so bad UX. Both would basically require an > internal team to develop them actively, at which point you might > wonder, why didn't we just NIH this? But usually this internal team > doesn't exist due to cost reasons, and the outcome is really poor and > expensive. > Someone is going to do what Slack did to chat, and make a ticketing > system that people actually want to use rather than email, because > they think it makes their work easier. > > > -- > ++ytti >
Re: [PATCH] drm/amdgpu: replace int with unsigned int for imu_v12_0.c
Am 03.06.24 um 07:59 schrieb Bob Zhou:
The return value of RREG32_SOC15 is unsigned int, so modify variable to
unsigned.
And why is that an improvement?
Regards,
Christian.
Signed-off-by: Bob Zhou
---
drivers/gpu/drm/amd/amdgpu/imu_v12_0.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/imu_v12_0.c
b/drivers/gpu/drm/amd/amdgpu/imu_v12_0.c
index 0c8ef908d112..2d6f7549c2af 100644
--- a/drivers/gpu/drm/amd/amdgpu/imu_v12_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/imu_v12_0.c
@@ -119,7 +119,7 @@ static int imu_v12_0_load_microcode(struct amdgpu_device
*adev)
static int imu_v12_0_wait_for_reset_status(struct amdgpu_device *adev)
{
- int i, imu_reg_val = 0;
+ unsigned int i, imu_reg_val = 0;
for (i = 0; i < adev->usec_timeout; i++) {
imu_reg_val = RREG32_SOC15(GC, 0, regGFX_IMU_GFX_RESET_CTRL);
@@ -138,7 +138,7 @@ static int imu_v12_0_wait_for_reset_status(struct
amdgpu_device *adev)
static void imu_v12_0_setup(struct amdgpu_device *adev)
{
- int imu_reg_val;
+ unsigned int imu_reg_val;
WREG32_SOC15(GC, 0, regGFX_IMU_C2PMSG_ACCESS_CTRL0, 0xff);
WREG32_SOC15(GC, 0, regGFX_IMU_C2PMSG_ACCESS_CTRL1, 0x);
@@ -157,7 +157,7 @@ static void imu_v12_0_setup(struct amdgpu_device *adev)
static int imu_v12_0_start(struct amdgpu_device *adev)
{
- int imu_reg_val;
+ unsigned int imu_reg_val;
imu_reg_val = RREG32_SOC15(GC, 0, regGFX_IMU_CORE_CTRL);
imu_reg_val &= 0xfffe;
Re: [PATCH] drm/amdgpu: Skip coredump during resets for debug
Am 31.05.24 um 14:34 schrieb Lijo Lazar: Skip scheduling coredump when gpu reset is intentionally triggered through debugfs. Signed-off-by: Lijo Lazar Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c index 10832b470448..1a9fda1d20fb 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c @@ -981,6 +981,7 @@ static void amdgpu_debugfs_reset_work(struct work_struct *work) reset_context.method = AMD_RESET_METHOD_NONE; reset_context.reset_req_dev = adev; set_bit(AMDGPU_NEED_FULL_RESET, _context.flags); + set_bit(AMDGPU_SKIP_COREDUMP, _context.flags); amdgpu_device_gpu_recover(adev, NULL, _context); }
Re: [Chicken-announce] [ANN] CHICKEN 5.4.0 release candidate available
Hi, here are my 5.4rc1 results: HW: MacBook Air M2 (arm64) OS: macos Montery 12.7.5 CC: clang 14.0.0 Installation works?: yes Tests work?: no (see attachment) Installation of "pastiche" egg works?: yes Installation of “arcadedb" egg works?: yes Installation of "matrico" egg works?: no (see attachment, it works with brew-installed chicken-5.3) Best Christian check.log Description: Binary data matrico.log Description: Binary data > On 31. May 2024, at 10:08, Peter Bex wrote: > > Hello everyone, > > We are happy to announce the first release candidate of the upcoming > CHICKEN 5.4.0. > > CHICKEN 5.4.0rc1 is now available at this location: > https://code.call-cc.org/dev-snapshots/2024/05/31/chicken-5.4.0rc1.tar.gz > > The SHA256 sum of that tarball is > 61d59cb4f3ca226995d7dca3510c7a646c2cf1e28ebc771bf6c5177e28d14c81 > > This is mostly a bugfix and maintenance release, preparing for the > upcoming CHICKEN 6 release (hopefully later this year). > > It contains some security hardening regarding option parsing and a > fix for CVE-2022-45145 handling of escape characters in egg metadata. > > Notable new features are new thread-safe APIs for POSIX signals and > finalizers, support for weak pairs and having line numbers available > on error traces in the interpreter. > > The complete list of changes since version 5.3.0 is available here: > https://code.call-cc.org/dev-snapshots/2024/05/31/NEWS > > Please give it a test and report your findings to the mailing list. > > Here's a suggested test procedure: > > $ make PREFIX= install check > $ /bin/chicken-install pastiche > > If you want to build CHICKEN with a compiler other than the default one, > just use C_COMPILER= (e.g., C_COMPILER=clang) on the make > invocation. > > Of course, feel free to explore other supported build options (see the > README file for more information) and actually use CHICKEN 5.3.0rc1 for > your software. > > If you can, please let us know the following information about the > environment you tested the RC tarball on: > > Operating system: (e.g., FreeBSD 14.0, Debian 12, Windows 11 mingw-msys under > mingw32) > Hardware platform: (e.g., x86, x86-64, PPC) > C Compiler: (e.g., GCC 11.3.0, clang 16.0.6) > Installation works?: yes or no > Tests work?: yes or no > Installation of eggs works?: yes or no > > Thanks in advance! > > The CHICKEN Team >
Commit: patch 9.1.0461: too many strlen() calls in drawline.c
patch 9.1.0461: too many strlen() calls in drawline.c
Commit:
https://github.com/vim/vim/commit/f51ff96532ab8f97f779b44d17dccdda9d8ce566
Author: John Marriott
Date: Sun Jun 2 19:44:11 2024 +0200
patch 9.1.0461: too many strlen() calls in drawline.c
Problem: too many strlen() calls in drawline.c
Solution: Refactor code to avoid strlen()
(John Marriott)
closes: #14890
Signed-off-by: John Marriott
Signed-off-by: Christian Brabandt
diff --git a/src/drawline.c b/src/drawline.c
index 9502fc53a..e388bdbee 100644
--- a/src/drawline.c
+++ b/src/drawline.c
@@ -296,10 +296,9 @@ get_sign_display_info(
if (nrcol)
{
wlv->c_extra = NUL;
- sprintf((char *)wlv->extra, "%-*c ",
- number_width(wp), SIGN_BYTE);
+ wlv->n_extra = vim_snprintf((char *)wlv->extra,
sizeof(wlv->extra),
+ "%-*c ", number_width(wp),
SIGN_BYTE);
wlv->p_extra = wlv->extra;
- wlv->n_extra = (int)STRLEN(wlv->p_extra);
}
else
wlv->c_extra = SIGN_BYTE;
@@ -310,10 +309,9 @@ get_sign_display_info(
if (nrcol)
{
wlv->c_extra = NUL;
- sprintf((char *)wlv->extra, "%-*c ", number_width(wp),
- MULTISIGN_BYTE);
+ wlv->n_extra = vim_snprintf((char *)wlv->extra,
sizeof(wlv->extra),
+ "%-*c ", number_width(wp),
MULTISIGN_BYTE);
wlv->p_extra = wlv->extra;
- wlv->n_extra = (int)STRLEN(wlv->p_extra);
}
else
wlv->c_extra = MULTISIGN_BYTE;
@@ -332,17 +330,18 @@ get_sign_display_info(
if (nrcol)
{
int width = number_width(wp) - 2;
- int n;
- for (n = 0; n < width; n++)
- wlv->extra[n] = ' ';
- vim_snprintf((char *)wlv->extra + n,
- sizeof(wlv->extra) - n, "%s ", wlv->p_extra);
+ vim_memset(wlv->extra, ' ', width);
+ wlv->n_extra = width;
+ wlv->n_extra += vim_snprintf((char *)wlv->extra + width,
+ sizeof(wlv->extra) - width, "%s ",
wlv->p_extra);
wlv->p_extra = wlv->extra;
}
+ else
+ wlv->n_extra = (int)STRLEN(wlv->p_extra);
+
wlv->c_extra = NUL;
wlv->c_final = NUL;
- wlv->n_extra = (int)STRLEN(wlv->p_extra);
}
if (use_cursor_line_highlight(wp, wlv->lnum)
@@ -417,7 +416,7 @@ handle_lnum_col(
}
}
- sprintf((char *)wlv->extra, fmt, number_width(wp), num);
+ vim_snprintf((char *)wlv->extra, sizeof(wlv->extra), fmt,
number_width(wp), num);
if (wp->w_skipcol > 0 && wlv->startrow == 0)
for (wlv->p_extra = wlv->extra; *wlv->p_extra == ' ';
++wlv->p_extra)
@@ -621,25 +620,26 @@ textprop_size_after_trunc(
{
intspace = (flags & (TP_FLAG_ALIGN_BELOW | TP_FLAG_ALIGN_ABOVE))
? wp->w_width - win_col_off(wp) : added;
-int len = (int)STRLEN(text);
int strsize = 0;
-int n_used;
+char_u *p;
-// if the remaining size is to small and 'wrap' is set we wrap anyway and
+// if the remaining size is too small and 'wrap' is set we wrap anyway and
// use the next line
if (space < PROP_TEXT_MIN_CELLS && wp->w_p_wrap)
space += wp->w_width;
if (flags & (TP_FLAG_ALIGN_BELOW | TP_FLAG_ALIGN_ABOVE))
space -= padding;
-for (n_used = 0; n_used < len; n_used += (*mb_ptr2len)(text + n_used))
+
+for (p = text; *p != NUL; p += (*mb_ptr2len)(p))
{
- int clen = ptr2cells(text + n_used);
+ int clen = ptr2cells(p);
if (strsize + clen > space)
break;
strsize += clen;
}
-*n_used_ptr = n_used;
+*n_used_ptr = (int)(p - text);
+
return strsize;
}
@@ -1807,7 +1807,7 @@ win_line(
line = ml_get_buf(wp->w_buffer, lnum, FALSE);
ptr = line + linecol;
- if (len == 0 || (int)wp->w_cursor.col > ptr - line)
+ if (len == 0 || (int)wp->w_cursor.col > linecol)
{
// no bad
core.git: configure.ac l10ntools/source scp2/source solenv/inc
configure.ac | 16 l10ntools/source/ulfconv/msi-encodinglist.txt |1 + scp2/source/ooo/module_langpack.ulf |6 ++ solenv/inc/langlist.mk|9 + 4 files changed, 24 insertions(+), 8 deletions(-) New commits: commit e8392bc1c984da1f09674055b1bac95e12de59a6 Author: Christian Lohmaier AuthorDate: Sat Jun 1 17:45:55 2024 +0200 Commit: Christian Lohmaier CommitDate: Sun Jun 2 19:26:46 2024 +0200 allow low-translation-completion-langs for dev-builds (e.g.: Sundanese) will be included when using --with-lang=ALL in non-release configuration (i.e. tinderbox provided daily builds), but not when using --enable-release-build. Change the way how configure fetches the list of all supported languages from a fancy sed call to running make with a dummy-recipe. Change-Id: I8bbea5fd95d37eac5bbce2e55ae34830b0ab4ebb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168334 Reviewed-by: Christian Lohmaier Tested-by: Jenkins diff --git a/configure.ac b/configure.ac index 2cccb004e8dd..172417596a84 100644 --- a/configure.ac +++ b/configure.ac @@ -14457,14 +14457,14 @@ dnl === AC_MSG_CHECKING([which languages to be built]) # get list of all languages # generate shell variable from completelangiso= from solenv/inc/langlist.mk -# the sed command does the following: -# + if a line ends with a backslash, append the next line to it -# + adds " on the beginning of the value (after =) -# + adds " at the end of the value -# + removes en-US; we want to put it on the beginning -# + prints just the section starting with 'completelangiso=' and ending with the " at the end of line -[eval $(sed -e :a -e '/\$/N; s/\ //; ta' -n -e 's/=/="/;s/\([^\]\)$/"/;s/en-US//;/^completelangiso/p' $SRC_ROOT/solenv/inc/langlist.mk)] -ALL_LANGS="en-US $completelangiso" +# we want en-US at the beginning +ALL_LANGS=$($GNUMAKE SRC_ROOT=$SRC_ROOT WITH_LANG="$with_lang" ENABLE_RELEASE_BUILD="$ENABLE_RELEASE_BUILD" -sr -f - <<'EOF' | tr -d ' ' +include $(SRC_ROOT)/solenv/inc/langlist.mk +all: + $(info en-US $(filter-out en-US,$(sort $(completelangiso +EOF +) + # check the configured localizations WITH_LANG="$with_lang" diff --git a/l10ntools/source/ulfconv/msi-encodinglist.txt b/l10ntools/source/ulfconv/msi-encodinglist.txt index eaa1754cf538..453d1330dd39 100644 --- a/l10ntools/source/ulfconv/msi-encodinglist.txt +++ b/l10ntools/source/ulfconv/msi-encodinglist.txt @@ -147,6 +147,7 @@ sr-Latn 0 2074 # Serbian Latin sr-SP0 3098 # Serbian Cyrillic ss 0 1579 # Swazi st 0 1072 # Southern Sotho, Sutu +sun 0 1690 # Sundanese, fake LCID sv 0 1053 sw 0 1089 # Swahili sw-TZ0 1089 # Swahili diff --git a/scp2/source/ooo/module_langpack.ulf b/scp2/source/ooo/module_langpack.ulf index 5b51e7fa9f64..e9274207734c 100644 --- a/scp2/source/ooo/module_langpack.ulf +++ b/scp2/source/ooo/module_langpack.ulf @@ -70,6 +70,12 @@ en-US = "Spanish" [STR_DESC_MODULE_LANGPACK_ES] en-US = "Installs the Spanish user interface" +[STR_NAME_MODULE_LANGPACK_SUN] +en-US = "Sundanese" + +[STR_DESC_MODULE_LANGPACK_SUN] +en-US = "Installs the Sundanese user interface" + [STR_NAME_MODULE_LANGPACK_SV] en-US = "Swedish" diff --git a/solenv/inc/langlist.mk b/solenv/inc/langlist.mk index 0de00dff99a7..95a295c10738 100644 --- a/solenv/inc/langlist.mk +++ b/solenv/inc/langlist.mk @@ -138,6 +138,15 @@ zh-CN \ zh-TW \ zu +# languages with low translation percentage, but still wish to have daily builds +lowcompletion_langs = sun +ifneq ($(ENABLE_RELEASE_BUILD),TRUE) +completelangiso += $(lowcompletion_langs) +else +# allow to manually specify even in release config +completelangiso += $(foreach lang,$(WITH_LANG),$(filter $(lang),$(lowcompletion_langs))) +endif + ifneq ($(WITH_LANG),ALL) gb_WITH_LANG=$(WITH_LANG) else
Commit: patch 9.1.0460: filetype: lintstagedrc files are not recognized
patch 9.1.0460: filetype: lintstagedrc files are not recognized
Commit:
https://github.com/vim/vim/commit/7577afd5efd0f7ebf0dbbca09713185024263ed7
Author: İlyas Akın
Date: Sun Jun 2 16:57:00 2024 +0200
patch 9.1.0460: filetype: lintstagedrc files are not recognized
Problem: filetype: lintstagedrc files are not recognized
Solution: recognize '.lintstagedrc' files as json filetype
(İlyas Akın)
see: https://github.com/lint-staged/lint-staged
closes: #14897
Signed-off-by: İlyas Akın
Signed-off-by: Christian Brabandt
diff --git a/runtime/filetype.vim b/runtime/filetype.vim
index 27879d497..801a8f346 100644
--- a/runtime/filetype.vim
+++ b/runtime/filetype.vim
@@ -1177,7 +1177,7 @@ au BufNewFile,BufRead *.ipynb,*.jupyterlab-settings
setf json
au BufNewFile,BufRead *.sublime-project,*.sublime-settings,*.sublime-workspace
setf json
" Other files that look like json
-au BufNewFile,BufRead .prettierrc,.firebaserc,.stylelintrc,flake.lock setf
json
+au BufNewFile,BufRead
.prettierrc,.firebaserc,.stylelintrc,.lintstagedrc,flake.locksetf json
" JSONC (JSON with comments)
au BufNewFile,BufRead *.jsonc,.babelrc,.eslintrc,.jsfmtrc setf jsonc
diff --git a/src/testdir/test_filetype.vim b/src/testdir/test_filetype.vim
index 322c873ee..284a55fe6 100644
--- a/src/testdir/test_filetype.vim
+++ b/src/testdir/test_filetype.vim
@@ -364,7 +364,7 @@ def s:GetFilenameChecks(): dict>
jq: ['file.jq'],
jovial: ['file.jov', 'file.j73', 'file.jovial'],
jproperties: ['file.properties', 'file.properties_xx',
'file.properties_xx_xx', 'some.properties_xx_xx_file', 'org.eclipse.xyz.prefs'],
-json: ['file.json', 'file.jsonp', 'file.json-patch', 'file.geojson',
'file.webmanifest', 'Pipfile.lock', 'file.ipynb', 'file.jupyterlab-settings',
'.prettierrc', '.firebaserc', '.stylelintrc', 'file.slnf',
'file.sublime-project', 'file.sublime-settings', 'file.sublime-workspace',
'file.bd', 'file.bda', 'file.xci', 'flake.lock'],
+json: ['file.json', 'file.jsonp', 'file.json-patch', 'file.geojson',
'file.webmanifest', 'Pipfile.lock', 'file.ipynb', 'file.jupyterlab-settings',
'.prettierrc', '.firebaserc', '.stylelintrc', '.lintstagedrc', 'file.slnf',
'file.sublime-project', 'file.sublime-settings', 'file.sublime-workspace',
'file.bd', 'file.bda', 'file.xci', 'flake.lock'],
json5: ['file.json5'],
jsonc: ['file.jsonc', '.babelrc', '.eslintrc', '.jsfmtrc', '.jshintrc',
'.jscsrc', '.vsconfig', '.hintrc', '.swrc', 'jsconfig.json', 'tsconfig.json',
'tsconfig.test.json', 'tsconfig-test.json', '.luaurc'],
jsonl: ['file.jsonl'],
diff --git a/src/version.c b/src/version.c
index 8b1282bd4..f8951af06 100644
--- a/src/version.c
+++ b/src/version.c
@@ -704,6 +704,8 @@ static char *(features[]) =
static int included_patches[] =
{ /* Add new patch number below this line */
+/**/
+460,
/**/
459,
/**/
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/E1sDmvH-005eh4-D4%40256bit.org.
Re: Calls to ch_log() left in released code
On Sa, 01 Jun 2024, Gary Johnson wrote: > I would like to request that developers not leave calls to ch_log() > enabled in released code, that is, in code that has been committed > to the GitHub repo. > > I just tried debugging some Vim code by sprinkling calls to ch_log() > in it. When I ran tail on the log file, I was inundated with log > messages from other sources, making it hard to find mine. To quiet > the log, I put #if 0/#endif around several calls in > > channel.c > evalfunc.c > main.c > ops.c > os_unix.c > ui.c > > It would be nice if the responsible developers would fix those in > the manner they prefer, since the project doesn't seem to have > a uniform solution for this, such as the one used in term.c. > > Perhaps a note about not leaving calls to ch_log() enabled when > you're done debugging should be added to src/README.md. I thought the idea was that you can use `--log file` and have a log with all kind of information that can be used even with released versions of Vim. So I have used it e.g. to debug what keys are received by Vim when a user complains certain keys don't work in alacritty or kitty terminal. If we disable the calls to ch_log() we wouldn't be able to debug those, no? Thanks, Christian -- I believe that the moment is near when by a procedure of active paranoiac thought, it will be possible to systematize confusion and contribute to the total discrediting of the world of reality. -- Salvador Dali -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/ZlyH0/L2OxNrc/Uo%40256bit.org.
Bug#1072474: backintime-common: "sshfs" should be "dep" instead of "sug"
Package: backintime-common Version: 1.3.3-4 Severity: important Upstream maintainer here. I migrated from Debian 11 to 12 with fresh installing the whole system including Back In Time (BIT). I realized that "sshfs" is not installed when installing BIT. I would say that "sshfs" should be a "depending" package instead of just a "suggestion". With "sshfs" remote backups using SSH are not possible. BIT gives error messages about a missing "sshfs" but don't handle the situation in an elegant way. Users will get lost. SSH using backup profiles are not disabled in this case. I would ease up a lot for us maintainers and users if "sshfs" would be a hard dependecy. Not sure how the Debian Policy is about it but I would suggest to also fix the current stable (Debian 12) version. Best, Christian Buhtz -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages backintime-common depends on: ii cron [cron-daemon] 3.0pl1-162 ii openssh-client 1:9.2p1-2+deb12u2 ii python3 3.11.2-1+b1 ii python3-dbus1.3.2-4+b1 ii python3-keyring 23.9.3-2 ii python3-packaging 23.0-1 ii rsync 3.2.7-1 Versions of packages backintime-common recommends: ii backintime-qt 1.3.3-4 Versions of packages backintime-common suggests: pn encfs pn powermgmt-base pn sshfs -- no debconf information
Commit: patch 9.1.0459: Vim9: import autoload does not work with symlink
patch 9.1.0459: Vim9: import autoload does not work with symlink
Commit:
https://github.com/vim/vim/commit/36b66767195f1e39e6cc997f825bedc6c823183b
Author: nwounkn
Date: Sun Jun 2 16:10:07 2024 +0200
patch 9.1.0459: Vim9: import autoload does not work with symlink
Problem: Vim9: import autoload does not work with symlink
(Olivier Dormond)
Solution: set sn_autoload_prefix in check_script_symlink
(nwounkn)
fixes: #14775
closes: #14885
Signed-off-by: nwounkn
Signed-off-by: Christian Brabandt
diff --git a/src/scriptfile.c b/src/scriptfile.c
index b6c66b7a4..6a6a037e3 100644
--- a/src/scriptfile.c
+++ b/src/scriptfile.c
@@ -435,8 +435,13 @@ check_script_symlink(int sid)
si = SCRIPT_ITEM(sid);
si->sn_sourced_sid = real_sid;
if (new_sid)
+ {
SCRIPT_ITEM(real_sid)->sn_import_autoload
= si->sn_import_autoload;
+ if (si->sn_autoload_prefix != NULL)
+ SCRIPT_ITEM(real_sid)->sn_autoload_prefix =
+ vim_strsave(si->sn_autoload_prefix);
+ }
}
}
vim_free(real_fname);
diff --git a/src/testdir/test_vim9_import.vim b/src/testdir/test_vim9_import.vim
index 3067ef6c9..fb309cb3b 100644
--- a/src/testdir/test_vim9_import.vim
+++ b/src/testdir/test_vim9_import.vim
@@ -3068,7 +3068,10 @@ def Test_vim9_import_symlink()
var lines =<< trim END
vim9script
import autoload 'bar.vim'
-g:resultFunc = bar.Func()
+def FooFunc(): string
+ return bar.Func()
+enddef
+g:resultFunc = FooFunc()
g:resultValue = bar.value
END
writefile(lines, 'Xto/plugin/foo.vim')
diff --git a/src/version.c b/src/version.c
index 068c0793c..8b1282bd4 100644
--- a/src/version.c
+++ b/src/version.c
@@ -704,6 +704,8 @@ static char *(features[]) =
static int included_patches[] =
{ /* Add new patch number below this line */
+/**/
+459,
/**/
458,
/**/
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/E1sDmDj-005aUE-CQ%40256bit.org.
Commit: patch 9.1.0458: Coverity complains about division by zero
patch 9.1.0458: Coverity complains about division by zero
Commit:
https://github.com/vim/vim/commit/7737ce519b9cba8ef135154d76b69f715b1a0b4d
Author: Christian Brabandt
Date: Sun Jun 2 16:04:43 2024 +0200
patch 9.1.0458: Coverity complains about division by zero
Problem: Coverity complains about division by zero
Solution: Check explicitly for sw_val being zero
Shouldn't happen, since tabstop value should always be larger than zero.
So just add this as a safety measure.
Signed-off-by: Christian Brabandt
diff --git a/src/ops.c b/src/ops.c
index fea021b93..b9569571e 100644
--- a/src/ops.c
+++ b/src/ops.c
@@ -233,6 +233,9 @@ shift_line(
inti, j;
intsw_val = trim_to_int(get_sw_value_indent(curbuf, left));
+if (sw_val == 0)
+ sw_val = 1; // shouldn't happen, just in case
+
count = get_indent(); // get current indent
if (round) // round off indent
diff --git a/src/version.c b/src/version.c
index 221fcf8c7..068c0793c 100644
--- a/src/version.c
+++ b/src/version.c
@@ -704,6 +704,8 @@ static char *(features[]) =
static int included_patches[] =
{ /* Add new patch number below this line */
+/**/
+458,
/**/
457,
/**/
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/E1sDlzE-005Z1U-TO%40256bit.org.
Re: [PATCH gnunet-handbook] add evans thesis to users docs
Applied, thanks! -christian On 6/2/24 11:06, Nikolaos Chatzikonstantinou wrote: Hello, This patch is for gnunet-handbook First time small contribution here, see attachment. Regards, Nikolaos Chatzikonstantinou
[ptxdist] [PATCH] wayland: Version bump. 1.22.0 -> 1.23.0
Minor enhancements. https://lists.freedesktop.org/archives/wayland-devel/2024-May/043636.html Signed-off-by: Christian Melki --- rules/wayland.make | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rules/wayland.make b/rules/wayland.make index 3e192f427..b9b132e97 100644 --- a/rules/wayland.make +++ b/rules/wayland.make @@ -14,8 +14,8 @@ PACKAGES-$(PTXCONF_WAYLAND) += wayland # # Paths and names # -WAYLAND_VERSION:= 1.22.0 -WAYLAND_MD5:= 7410ab549e3928fce9381455b17b0803 +WAYLAND_VERSION:= 1.23.0 +WAYLAND_MD5:= 23ad991e776ec8cf7e58b34cbd2efa75 WAYLAND:= wayland-$(WAYLAND_VERSION) WAYLAND_SUFFIX := tar.xz WAYLAND_URL:= https://gitlab.freedesktop.org/wayland/wayland/-/releases/$(WAYLAND_VERSION)/downloads/$(WAYLAND).$(WAYLAND_SUFFIX) -- 2.34.1
[ptxdist] [PATCH] hwdata: Version bump. 0.382 -> 0.383
Update pci and vendor ids. Signed-off-by: Christian Melki --- rules/hwdata.make | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rules/hwdata.make b/rules/hwdata.make index 9c15cf790..99bb4815f 100644 --- a/rules/hwdata.make +++ b/rules/hwdata.make @@ -14,8 +14,8 @@ PACKAGES-$(PTXCONF_HWDATA) += hwdata # # Paths and names # -HWDATA_VERSION := 0.382 -HWDATA_MD5 := 17cffcd26a627070332422c65b55eaab +HWDATA_VERSION := 0.383 +HWDATA_MD5 := 6067227e71284f56a375a746ecec7d71 HWDATA := hwdata-$(HWDATA_VERSION) HWDATA_SUFFIX := tar.gz HWDATA_URL := https://github.com/vcrhonek/hwdata/archive/refs/tags/v$(HWDATA_VERSION).$(HWDATA_SUFFIX) -- 2.34.1
[ptxdist] [PATCH] hwdata: Version bump. 0.382 -> 0.383
Update pci and vendor ids. Signed-off-by: Christian Melki --- rules/hwdata.make | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rules/hwdata.make b/rules/hwdata.make index 9c15cf790..99bb4815f 100644 --- a/rules/hwdata.make +++ b/rules/hwdata.make @@ -14,8 +14,8 @@ PACKAGES-$(PTXCONF_HWDATA) += hwdata # # Paths and names # -HWDATA_VERSION := 0.382 -HWDATA_MD5 := 17cffcd26a627070332422c65b55eaab +HWDATA_VERSION := 0.383 +HWDATA_MD5 := 6067227e71284f56a375a746ecec7d71 HWDATA := hwdata-$(HWDATA_VERSION) HWDATA_SUFFIX := tar.gz HWDATA_URL := https://github.com/vcrhonek/hwdata/archive/refs/tags/v$(HWDATA_VERSION).$(HWDATA_SUFFIX) -- 2.34.1
[ptxdist] [PATCH] libevdev: Version bump. 1.13.1 -> 1.13.2
Minor changes, mostly build and a kernel event sync to 6.9. https://gitlab.freedesktop.org/libevdev/libevdev/-/commits/libevdev-1.13.2 Signed-off-by: Christian Melki --- rules/libevdev.make | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rules/libevdev.make b/rules/libevdev.make index 192e11439..22fd717fc 100644 --- a/rules/libevdev.make +++ b/rules/libevdev.make @@ -14,8 +14,8 @@ PACKAGES-$(PTXCONF_LIBEVDEV) += libevdev # # Paths and names # -LIBEVDEV_VERSION := 1.13.1 -LIBEVDEV_MD5 := 58fe71aa6fd5e80d0928e9b691761311 +LIBEVDEV_VERSION := 1.13.2 +LIBEVDEV_MD5 := ddb1d798e0f2b4d0bd17c892b7d4aed3 LIBEVDEV := libevdev-$(LIBEVDEV_VERSION) LIBEVDEV_SUFFIX:= tar.xz LIBEVDEV_URL := http://www.freedesktop.org/software/libevdev/$(LIBEVDEV).$(LIBEVDEV_SUFFIX) -- 2.34.1
[ptxdist] [PATCH] pciutils: Version bump. 3.12.0 -> 3.13.0
Minor changes and fixes. https://github.com/pciutils/pciutils/blob/v3.13.0/ChangeLog Signed-off-by: Christian Melki --- rules/pciutils.make | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rules/pciutils.make b/rules/pciutils.make index 20e2b7f7e..46c15b8ab 100644 --- a/rules/pciutils.make +++ b/rules/pciutils.make @@ -15,8 +15,8 @@ PACKAGES-$(PTXCONF_PCIUTILS) += pciutils # # Paths and names # -PCIUTILS_VERSION := 3.12.0 -PCIUTILS_MD5 := f6607d41eb8ce0f676368a1012b5fe5c +PCIUTILS_VERSION := 3.13.0 +PCIUTILS_MD5 := 03cf42b53406618b35782a1fb729e330 PCIUTILS := pciutils-$(PCIUTILS_VERSION) PCIUTILS_SUFFIX:= tar.gz PCIUTILS_URL := https://github.com/pciutils/pciutils/archive/refs/tags/v$(PCIUTILS_VERSION).$(PCIUTILS_SUFFIX) -- 2.34.1
Re: [de-discuss] Übersetzung von Makros?
Hallo, Robert! Am 12.04.24 um 08:35 schrieb Robert Großkopf: kann es sein, dass sich unsere Übersetzercrew auch an Makros wagt? Aus der Hilfe von LO 24.2 Aus der uns angezeigten Zeichenfolge ist nicht immer ersichtlich, welchen Kontext sie hat. Dann passieren solche Fehler (zumal, wenn man kein Programmierer ist). Daher solche Fehlübersetzungen immer gerne melden, dann werden sie korrigiert. Sub ExampleWeekDay Dim sDay As String ' Wochentag ermitteln und ausgeben Select Case WeekDay( Now ) 1. Fall: sDay="Sonntag" 2. Fall: sDay="Montag" 3. Fall: sDay="Dienstag" 4. Fall: sDay="Mittwoch" 5. Fall: sDay="Donnerstag" 6. Fall: sDay="Freitag" 7. Fall: sDay="Samstag" End Select MsgBox "" + sDay,64,"Heute ist" End Sub Muss natürlich heißen … Case 1: sDay="Sonntag" Case 2: sDay="Montag" Ich habe es korrigiert. Natürlich ist hier etwas zu übersetzen gewesen, nämlich die Namensbezeichnungen. Aber: Vielleicht sollten wir doch überlegen, Makrocode grundsätzlich von der Übersetzung aus zu schließen. Wie gesagt, es ist nicht immer ersichtlich, wozu die Zeichenfolge gerade gehört. Meistens wird sogar nur der zugehöriger Kommentar zur Übersetzung angezeigt (da nichts zu übersetzen ist), dann wäre der Code später auch wieder eine Mischung aus teilweise übersetztem und teilweise nicht übersetztem Inhalt. Gruß Christian -- Liste abmelden mit E-Mail an: discuss+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/discuss/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: Package Maintainer application - Giovanni Harting
On 24/05/20 11:46AM, Giovanni Harting wrote: > Hey everyone. Hey Giovanni > I'm hereby applying as a package maintainer, > which is kindly sponsored by David (dvzrv) and Jelle (jelly) and formally by > Levente (anthraxx), for whom Jelle has taken over the sponsorship. Thanks for applying and good luck in the process! Sorry for replying last minute, but I didn't find the time / got sidetracked with other things in the last week! > ## Who > > I'm Giovanni, also known as anonfunc or idlegandalf. I've been using Arch > Linux as my day-to-day driver since 2013 and Linux in general since probably > 2008 (mostly server-side until 2011-12, last Windows I actually used was 7). > As for notable contributions, you might have heard of ALHP, which I started > in 2020. > > ALHP developed from the idea of utilising modern CPU extensions all the way > back in Q4 2019 (after I had a quick Gentoo detour on one of my laptops). At > the time, no x86_64 levels were defined, so the first rough outlines still > considered building for specific gcc CPU-baselines, like Haswell for example > (which seems crazy in hindsight). When the x86_64 levels were announced in > 2020, I started developing a buildbot capable of doing the heavy lifting, at > the time in Python. After ditching Python in 2021 (after I got annoyed of > multi-process) and rewriting the buildbot in Go, the project launched in > July 2021. At the time, ALHP only provided x86_64-v3, shortly after launch > x86_64-v2 followed. In December 2023 the x86_64-v4 repo launched, after I > got my hands on a machine capable of building v4. > Not sure how many users it actually has, since I do not do any tracking, but > as far as requests on the tier 0 mirror go (ALHP has 7 mirrors in total, one > operated by myself), it seems to see some usage. > The buildbot is completely FOSS, you can have a look down in the links > section. That sounds cool and like a very useful addition to the team! In which way did these endeavours make you contribute back to the Arch Linux ecosystem so far? Because your name only rings a bell for me regarding the ALHP project but not i.e. via bug reports, merge requests or similar 樂 Then again I'm not part of the team for too long > ## Goals & Packages > > I want to help with package maintenance and advance infrastructure topics > with the overall goal of bringing x86_64-v3 and build automation to life, as > well as helping with potential problems that may come with v3, since ALHP > had plenty of those already. Sounds good, especially since this is already ratified from the RFC side (RFC002) and can (in theory) just be started with! > As for packages, I have a few that I think would benefit the general Arch > Linux audience by being promoted to official packages, mostly QoL stuff: > > - batsignal Is this an AUR package already? If yes I think I couldn't find it. > - wljoywake > - jellyfin-mpv-shim (+ deps) > - prismlauncher > - victoriametrics > - asus-numpad > - mmdbinspect With regard to votes & popularity some of these seem a bit low (with prismlauncher being the obvious outlier), so even though the related rules[0] are not enforced strictly some of these might need some extra consideration 樂 > I'm also open to co-maintainer roles if there are any packages in need. > Candidates could include DevOps related packages like Grafana or packages > from the Go ecosystem in general, since I use that language extensively. > > Besides the mentioned categories, I'm also interested to co-maintain: > > - home-assistant > - jellyfin > > ## Links > > AUR packages: https://aur.archlinux.org/packages?SeB=m=anonfunc > AUR source repo: https://somegit.dev/anonfunc/aur-packages I had a quick look at your AUR packages and didn't find many extra comments to those of Antiz. Some things are weirdly indented, but well thats just nitpicking > ALHP: https://somegit.dev/ALHP/ALHP.GO > ALHP Status: https://status.alhp.dev/ > > Feel free to criticise PKGBUILDs to your heart's content :) Improvement is a > continuous thing, so keep them coming. > > Giovanni Again, thanks for applying and I already got some ideas/questions looking at the repositories so I'm looking forward to having you on the team and discussing/implementing these things! Cheers, chris [0]: https://wiki.archlinux.org/title/Package_Maintainer_guidelines#Rules_for_packages_entering_the_extra_repository signature.asc Description: PGP signature
[PATCH 1/1] git: update to v2.45.2
From: Christian Hesse Update to git version v2.45.2, no additional changes required. Signed-off-by: Christian Hesse --- Makefile | 2 +- git | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index ecfebaf..1eb64ea 100644 --- a/Makefile +++ b/Makefile @@ -14,7 +14,7 @@ htmldir = $(docdir) pdfdir = $(docdir) mandir = $(prefix)/share/man SHA1_HEADER = -GIT_VER = 2.45.1 +GIT_VER = 2.45.2 GIT_URL = https://www.kernel.org/pub/software/scm/git/git-$(GIT_VER).tar.xz INSTALL = install COPYTREE = cp -r diff --git a/git b/git index 2c7b491..bea9ecd 16 --- a/git +++ b/git @@ -1 +1 @@ -Subproject commit 2c7b491c1d3107be35c375f59e040b0f13d0cc0c +Subproject commit bea9ecd24b0c3bf06cab4a851694fe09e7e51408 -- 2.45.1
[Git][archlinux/packaging/packages/open-iscsi][main] upgpkg: 2.1.10-1: new upstream release
Christian Hesse pushed to branch main at Arch Linux / Packaging / Packages /
open-iscsi
Commits:
a5062657 by Christian Hesse at 2024-06-01T23:16:55+02:00
upgpkg: 2.1.10-1: new upstream release
- - - - -
2 changed files:
- .SRCINFO
- PKGBUILD
Changes:
=
.SRCINFO
=
@@ -1,7 +1,7 @@
pkgbase = open-iscsi
pkgdesc = iSCSI userland tools
- pkgver = 2.1.9
- pkgrel = 2
+ pkgver = 2.1.10
+ pkgrel = 1
url = https://www.open-iscsi.com/
install = open-iscsi.install
arch = x86_64
@@ -16,7 +16,7 @@ pkgbase = open-iscsi
options = docs
backup = etc/iscsi/iscsid.conf
backup = etc/iscsi/initiatorname.iscsi
- source =
open-iscsi-2.1.9.tar.gz::https://github.com/open-iscsi/open-iscsi/archive/2.1.9.tar.gz
- sha256sums =
60e2a1e3058a8af7f702e86a5a0511b05b8754d29d3d2df4e0e301399b5cf70a
+ source =
open-iscsi-2.1.10.tar.gz::https://github.com/open-iscsi/open-iscsi/archive/2.1.10.tar.gz
+ sha256sums =
12c19f65f9136b87ac11bf5bbe5eb3e23de4e7f1ee07eecda830da53a2316113
pkgname = open-iscsi
=
PKGBUILD
=
@@ -2,8 +2,8 @@
# Maintainer: Stefan Kirrmann
pkgname=open-iscsi
-pkgver=2.1.9
-pkgrel=2
+pkgver=2.1.10
+pkgrel=1
pkgdesc='iSCSI userland tools'
arch=('x86_64')
url='https://www.open-iscsi.com/'
@@ -15,7 +15,7 @@ backup=('etc/iscsi/iscsid.conf'
'etc/iscsi/initiatorname.iscsi')
options=('docs')
source=("$pkgname-$pkgver.tar.gz::https://github.com/open-iscsi/open-iscsi/archive/$pkgver.tar.gz;)
-sha256sums=('60e2a1e3058a8af7f702e86a5a0511b05b8754d29d3d2df4e0e301399b5cf70a')
+sha256sums=('12c19f65f9136b87ac11bf5bbe5eb3e23de4e7f1ee07eecda830da53a2316113')
build() {
local _meson_options=(
View it on GitLab:
https://gitlab.archlinux.org/archlinux/packaging/packages/open-iscsi/-/commit/a5062657088049f344d22d83537178eb551d176c
--
View it on GitLab:
https://gitlab.archlinux.org/archlinux/packaging/packages/open-iscsi/-/commit/a5062657088049f344d22d83537178eb551d176c
You're receiving this email because of your account on gitlab.archlinux.org.
[Git][archlinux/packaging/packages/open-iscsi] Pushed new tag 2.1.10-1
Christian Hesse pushed new tag 2.1.10-1 at Arch Linux / Packaging / Packages / open-iscsi -- View it on GitLab: https://gitlab.archlinux.org/archlinux/packaging/packages/open-iscsi/-/tree/2.1.10-1 You're receiving this email because of your account on gitlab.archlinux.org.
[Git][archlinux/packaging/packages/git] Pushed new tag 2.45.2-1
Christian Hesse pushed new tag 2.45.2-1 at Arch Linux / Packaging / Packages / git -- View it on GitLab: https://gitlab.archlinux.org/archlinux/packaging/packages/git/-/tree/2.45.2-1 You're receiving this email because of your account on gitlab.archlinux.org.
[Git][archlinux/packaging/packages/git][main] upgpkg: 2.45.2-1: new upstream release
Christian Hesse pushed to branch main at Arch Linux / Packaging / Packages / git
Commits:
1dc8ae31 by Christian Hesse at 2024-06-01T23:12:30+02:00
upgpkg: 2.45.2-1: new upstream release
- - - - -
2 changed files:
- .SRCINFO
- PKGBUILD
Changes:
=
.SRCINFO
=
@@ -1,6 +1,6 @@
pkgbase = git
pkgdesc = the fast distributed version control system
- pkgver = 2.45.1
+ pkgver = 2.45.2
pkgrel = 1
url = https://git-scm.com/
install = git.install
@@ -34,13 +34,13 @@ pkgbase = git
optdepends = subversion: git svn
optdepends = org.freedesktop.secrets: keyring credential helper
optdepends = libsecret: libsecret credential helper
- source = https://www.kernel.org/pub/software/scm/git/git-2.45.1.tar.xz
- source = https://www.kernel.org/pub/software/scm/git/git-2.45.1.tar.sign
+ source = https://www.kernel.org/pub/software/scm/git/git-2.45.2.tar.xz
+ source = https://www.kernel.org/pub/software/scm/git/git-2.45.2.tar.sign
source = git-daemon@.service
source = git-daemon.socket
source = git-sysusers.conf
validpgpkeys = 96E07AF25771955980DAD10020D04E5A713660A7
- sha256sums =
e64d340a8e627ae22cfb8bcc651cca0b497cf1e9fdf523735544ff4a732f12bf
+ sha256sums =
51bfe87eb1c02fed1484051875365eeab229831d30d0cec5d89a14f9e40e9adb
sha256sums = SKIP
sha256sums =
14c0b67cfe116b430645c19d8c4759419657e6809dfa28f438c33a005245ad91
sha256sums =
ac4c90d62c44926e6d30d18d97767efc901076d4e0283ed812a349aece72f203
=
PKGBUILD
=
@@ -2,7 +2,7 @@
# Maintainer: Dan McGee
pkgname=git
-pkgver=2.45.1
+pkgver=2.45.2
pkgrel=1
pkgdesc='the fast distributed version control system'
arch=('x86_64')
@@ -32,7 +32,7 @@
source=("https://www.kernel.org/pub/software/scm/git/git-$pkgver.tar."{xz,sign}
'git-daemon@.service'
'git-daemon.socket'
'git-sysusers.conf')
-sha256sums=('e64d340a8e627ae22cfb8bcc651cca0b497cf1e9fdf523735544ff4a732f12bf'
+sha256sums=('51bfe87eb1c02fed1484051875365eeab229831d30d0cec5d89a14f9e40e9adb'
'SKIP'
'14c0b67cfe116b430645c19d8c4759419657e6809dfa28f438c33a005245ad91'
'ac4c90d62c44926e6d30d18d97767efc901076d4e0283ed812a349aece72f203'
View it on GitLab:
https://gitlab.archlinux.org/archlinux/packaging/packages/git/-/commit/1dc8ae31a5b277e3f65af8fa452d3c026225fa00
--
View it on GitLab:
https://gitlab.archlinux.org/archlinux/packaging/packages/git/-/commit/1dc8ae31a5b277e3f65af8fa452d3c026225fa00
You're receiving this email because of your account on gitlab.archlinux.org.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2024/06/01 14:59:01 Modified files: archivers/xz : Makefile distinfo archivers/xz/pkg: PLIST Added files: archivers/xz/patches: patch-src_liblzma_check_crc32_arm64_h patch-src_liblzma_check_crc_common_h Removed files: archivers/xz/patches: patch-config_h_in patch-src_xzdec_xzdec_c Log message: archivers/xz: update to 5.6.2 * Multithreaded mode is now the default. * New command line options to set filter chains using the liblzma filter string syntax. * Significant speed optimizations to the LZMA decoder. * Omit the Doxygen-generated liblzma API documentation.
Commit: patch 9.1.0457: tests: test_gui fails on Wayland
patch 9.1.0457: tests: test_gui fails on Wayland
Commit:
https://github.com/vim/vim/commit/e5bc2e4bc9e7456daef480dd422252dbf444c58c
Author: Christian Brabandt
Date: Sat Jun 1 20:55:09 2024 +0200
patch 9.1.0457: tests: test_gui fails on Wayland
v:windowid is set in GUI buils with Wayland
Problem: tests: test_gui fails on Wayland
(after: 9.1.0064, Gary Johnson)
Solution: drop the "empty($WAYLAND_DISPLAY)" condition in the test
fixes: #14886
Signed-off-by: Christian Brabandt
diff --git a/runtime/doc/eval.txt b/runtime/doc/eval.txt
index ae93b35b3..18cd2c123 100644
--- a/runtime/doc/eval.txt
+++ b/runtime/doc/eval.txt
@@ -1,4 +1,4 @@
-*eval.txt* For Vim version 9.1. Last change: 2024 May 05
+*eval.txt* For Vim version 9.1. Last change: 2024 Jun 01
VIM REFERENCE MANUALby Bram Moolenaar
@@ -2727,7 +2727,7 @@ v:vim_did_enter Zero until most of startup is done. It
is set to one just
v:warningmsg Last given warning message. It's allowed to set this variable.
*v:windowid* *windowid-variable*
-v:windowid When any X11 based GUI is running or when running in a
+v:windowid When any X11/Wayland based GUI is running or when running in a
terminal and Vim connects to the X server (|-X|) this will be
set to the window ID.
When an MS-Windows GUI is running this will be set to the
diff --git a/src/testdir/test_gui.vim b/src/testdir/test_gui.vim
index 2ff8d3400..d53750f19 100644
--- a/src/testdir/test_gui.vim
+++ b/src/testdir/test_gui.vim
@@ -899,7 +899,7 @@ func Test_set_term()
endfunc
func Test_windowid_variable()
- if (g:x11_based_gui && empty($WAYLAND_DISPLAY)) || has('win32')
+ if g:x11_based_gui || has('win32')
call assert_true(v:windowid > 0)
else
call assert_equal(0, v:windowid)
diff --git a/src/version.c b/src/version.c
index 6e02c3e58..221fcf8c7 100644
--- a/src/version.c
+++ b/src/version.c
@@ -704,6 +704,8 @@ static char *(features[]) =
static int included_patches[] =
{ /* Add new patch number below this line */
+/**/
+457,
/**/
456,
/**/
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/E1sDUBz-003ipS-Fo%40256bit.org.
Commit: patch 9.1.0456: Left shift is incorrect with vartabstop and shiftwidth=0
patch 9.1.0456: Left shift is incorrect with vartabstop and shiftwidth=0
Commit:
https://github.com/vim/vim/commit/88d4f255b7b7a19bb4f6489e0ad0956e47d51fed
Author: Gary Johnson
Date: Sat Jun 1 20:51:33 2024 +0200
patch 9.1.0456: Left shift is incorrect with vartabstop and shiftwidth=0
Problem: Left shift is incorrect with vartabstop and shiftwidth=0
Solution: make tabstop_at() function aware of shift direction
(Gary Johnson)
The problem was that with 'vartabstop' set and 'shiftwidth' equal 0,
left shifts using << were shifting the line to the wrong column. The
tabstop to the right of the first character in the line was being used
as the shift amount instead of the tabstop to the left of that first
character.
The reason was that the tabstop_at() function always returned the value
of the tabstop to the right of the given column and was not accounting
for the direction of the shift.
The solution was to make tabstop_at() aware of the direction of the
shift and to choose the tabtop accordingly.
A test was added to check this behavior and make sure it doesn't
regress.
While at it, also fix a few indentation/alignment issues.
fixes: #14864
closes: #14887
Signed-off-by: Gary Johnson
Signed-off-by: Christian Brabandt
diff --git a/src/edit.c b/src/edit.c
index 075b39bff..e75a1cf11 100644
--- a/src/edit.c
+++ b/src/edit.c
@@ -519,9 +519,10 @@ edit(
if (
#ifdef FEAT_VARTABS
- curwin->w_wcol < mincol - tabstop_at(
- get_nolist_virtcol(), curbuf->b_p_ts,
-curbuf->b_p_vts_array)
+ curwin->w_wcol < mincol - tabstop_at(get_nolist_virtcol(),
+curbuf->b_p_ts,
+curbuf->b_p_vts_array,
+FALSE)
#else
(int)curwin->w_wcol < mincol - curbuf->b_p_ts
#endif
@@ -1310,7 +1311,7 @@ docomplete:
c = ins_ctrl_ey(c);
break;
- default:
+ default:
#ifdef UNIX
if (c == intr_char) // special interrupt char
goto do_intr;
@@ -1842,7 +1843,7 @@ backspace_until_column(int col)
* Only matters when there are composing characters.
* Return TRUE when something was deleted.
*/
- static int
+static int
del_char_after_col(int limit_col UNUSED)
{
if (enc_utf8 && limit_col >= 0)
diff --git a/src/evalfunc.c b/src/evalfunc.c
index 6e1eb037e..3028cf975 100644
--- a/src/evalfunc.c
+++ b/src/evalfunc.c
@@ -5464,7 +5464,7 @@ f_getpos(typval_T *argvars, typval_T *rettv)
/*
* Convert from block_def to string
*/
- static char_u *
+static char_u *
block_def2str(struct block_def *bd)
{
char_u *p, *ret;
@@ -10948,7 +10948,7 @@ f_shiftwidth(typval_T *argvars UNUSED, typval_T *rettv)
if (col < 0)
return; // type error; errmsg already given
#ifdef FEAT_VARTABS
- rettv->vval.v_number = get_sw_value_col(curbuf, col);
+ rettv->vval.v_number = get_sw_value_col(curbuf, col, FALSE);
return;
#endif
}
diff --git a/src/indent.c b/src/indent.c
index 1dfde7ddd..777db244a 100644
--- a/src/indent.c
+++ b/src/indent.c
@@ -123,14 +123,22 @@ tabstop_padding(colnr_T col, int ts_arg, int *vts)
/*
* Find the size of the tab that covers a particular column.
+ *
+ * If this is being called as part of a shift operation, col is not the cursor
+ * column but is the column number to the left of the first non-whitespace
+ * character in the line. If the shift is to the left (left = TRUE), then
+ * return the size of the tab interval to the left of the column.
*/
int
-tabstop_at(colnr_T col, int ts, int *vts)
+tabstop_at(colnr_T col, int ts, int *vts, int left)
{
-inttabcount;
-colnr_Ttabcol = 0;
-intt;
-inttab_size = 0;
+inttabcount; // Number of tab stops in the list of
variable
+ // tab stops.
+colnr_Ttabcol = 0; // Column of the tab stop under consideration.
+intt; // Tabstop index in the list of
variable tab
+ // stops.
+inttab_size = 0; // Size of the tab stop interval to the
right
+ // or left of the col.
if (vts == 0 || vts[0] == 0)
return ts;
@@ -141,11 +149,22 @@ tabstop_at(colnr_T col, int ts, int *vts)
tabcol += vts[t];
if (tabcol > col)
{
- tab_size = vts[t];
+ // If shifting left (left != 0), and if the column to the left of
+ // the first first non-blank character (col) in the l
Commit: runtime(doc): clarify 'shortmess' flag "S"
runtime(doc): clarify 'shortmess' flag "S" Commit: https://github.com/vim/vim/commit/e299591498a20c5c587364e4df57f947dfc02897 Author: Christian Brabandt Date: Sat Jun 1 20:40:25 2024 +0200 runtime(doc): clarify 'shortmess' flag "S" fixes: https://github.com/vim/vim/issues/14893 Signed-off-by: Christian Brabandt diff --git a/runtime/doc/options.txt b/runtime/doc/options.txt index a6f156ada..cae3e5433 100644 --- a/runtime/doc/options.txt +++ b/runtime/doc/options.txt @@ -1,4 +1,4 @@ -*options.txt* For Vim version 9.1. Last change: 2024 May 19 +*options.txt* For Vim version 9.1. Last change: 2024 Jun 01 VIM REFERENCE MANUALby Bram Moolenaar @@ -7238,8 +7238,8 @@ A jump table for the options with a short description can be found at |Q_op|. message; also for quickfix message (e.g., ":cn") s don't give "search hit BOTTOM, continuing at TOP" or*shm-s* "search hit TOP, continuing at BOTTOM" messages; when using - the search count do not show "W" after the count message (see - S below) + the search count do not show "W" before the count message + (see |shm-S| below) t truncate file message at the start if it is too long*shm-t* to fit on the command-line, "<" will appear in the left most column; ignored in Ex mode @@ -7261,7 +7261,11 @@ A jump table for the options with a short description can be found at |Q_op|. `:silent` was used for the command; note that this also affects messages from autocommands and 'autoread' reloading S do not show search count message when searching, e.g. *shm-S* - "[1/5]" + "[1/5]". When the "S" flag is not present (e.g. search count + is shown), the "search hit BOTTOM, continuing at TOP" and + "search hit TOP, continuing at BOTTOM" messages are only + indicated by a "W" (Mnemonic: Wrapped) letter before the + search count statistics. This gives you the opportunity to avoid that a change between buffers requires you to hit , but still gives as useful a message as -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/E1sDTiz-003g8S-0T%40256bit.org.
core.git: translations
translations |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) New commits: commit 9265dd87222763453784938553f9be41277acd6a Author: Christian Lohmaier AuthorDate: Sat Jun 1 18:23:09 2024 +0200 Commit: Gerrit Code Review CommitDate: Sat Jun 1 18:23:09 2024 +0200 Update git submodules * Update translations from branch 'master' to 113c6c3c2498ffc2f99f20c088367bca1fecc50b - add files for Sundanese (sun) Change-Id: Ic64f8f20a409024e8e0bf8d07aa644d7caa38bda - update translations for master and force-fix errors using pocheck Change-Id: I9e8399ac390552903a010f54802d722a2acf36f4 diff --git a/translations b/translations index 833ed440d8ca..113c6c3c2498 16 --- a/translations +++ b/translations @@ -1 +1 @@ -Subproject commit 833ed440d8cae32801d2e6a4b6e45d8210e99251 +Subproject commit 113c6c3c2498ffc2f99f20c088367bca1fecc50b
Commit: patch 9.1.0455: MS-Windows: compiler warning for size_t to int conversion
patch 9.1.0455: MS-Windows: compiler warning for size_t to int conversion
Commit:
https://github.com/vim/vim/commit/16b63bd002d48fa0b04f27cf3ccca894e14db378
Author: Mike Williams
Date: Sat Jun 1 11:33:40 2024 +0200
patch 9.1.0455: MS-Windows: compiler warning for size_t to int conversion
Problem: MS-Windows: compiler warning for size_t to int conversion
Solution: Add a few type casts to resolve warning on Windows
(Mike Williams)
closes: #14884
Signed-off-by: Mike Williams
Signed-off-by: Christian Brabandt
diff --git a/src/insexpand.c b/src/insexpand.c
index c1374d3e9..897c3b587 100644
--- a/src/insexpand.c
+++ b/src/insexpand.c
@@ -3383,7 +3383,7 @@ done:
get_next_include_file_completion(int compl_type)
{
find_pattern_in_path(compl_pattern, compl_direction,
- compl_patternlen, FALSE, FALSE,
+ (int)compl_patternlen, FALSE, FALSE,
(compl_type == CTRL_X_PATH_DEFINES
&& !(compl_cont_status & CONT_SOL))
? FIND_DEFINE : FIND_ANY, 1L, ACTION_EXPAND,
@@ -3487,7 +3487,7 @@ get_next_cmdline_completion(void)
intnum_matches;
if (expand_cmdline(_xp, compl_pattern,
- compl_patternlen, _matches, ) == EXPAND_OK)
+ (int)compl_patternlen, _matches, ) == EXPAND_OK)
ins_compl_add_matches(num_matches, matches, FALSE);
}
@@ -4593,7 +4593,7 @@ get_cmdline_compl_info(char_u *line, colnr_T curs_col)
}
compl_patternlen = curs_col;
set_cmd_context(_xp, compl_pattern,
- compl_patternlen, curs_col, FALSE);
+ (int)compl_patternlen, curs_col, FALSE);
if (compl_xp.xp_context == EXPAND_UNSUCCESSFUL
|| compl_xp.xp_context == EXPAND_NOTHING)
// No completion possible, use an empty pattern to get a
diff --git a/src/ops.c b/src/ops.c
index 1dd36ab28..8706a015d 100644
--- a/src/ops.c
+++ b/src/ops.c
@@ -580,7 +580,7 @@ block_insert(
// copy the new text
mch_memmove(newp + startcol, s, slen);
- offset += slen;
+ offset += (int)slen;
if (spaces > 0 && !bdp->is_short)
{
@@ -607,7 +607,7 @@ block_insert(
if (b_insert)
// correct any text properties
- inserted_bytes(lnum, startcol, slen);
+ inserted_bytes(lnum, startcol, (int)slen);
if (lnum == oap->end.lnum)
{
@@ -1722,7 +1722,7 @@ op_insert(oparg_T *oap, long count1)
add = len; // short line, point to the NUL
firstline += add;
len -= add;
- if (pre_textlen >= 0 && (ins_len = len - pre_textlen - offset) > 0)
+ if (pre_textlen >= 0 && (ins_len = (int)len - pre_textlen - offset) > 0)
{
ins_text = vim_strnsave(firstline, ins_len);
if (ins_text != NULL)
@@ -1866,7 +1866,7 @@ op_change(oparg_T *oap)
// Shift the properties for linenr as edit() would do.
if (curbuf->b_has_textprop)
adjust_prop_columns(linenr, bd.textcol,
-vpos.coladd + ins_len, 0);
+vpos.coladd +
(int)ins_len, 0);
#endif
}
}
diff --git a/src/version.c b/src/version.c
index d0bbf3e04..c0d660177 100644
--- a/src/version.c
+++ b/src/version.c
@@ -704,6 +704,8 @@ static char *(features[]) =
static int included_patches[] =
{ /* Add new patch number below this line */
+/**/
+455,
/**/
454,
/**/
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/E1sDLIP-002vVQ-JJ%40256bit.org.
[Git][archlinux/packaging/packages/imlib2][main] Prevent libtool overlinking
Christian Heusel pushed to branch main at Arch Linux / Packaging / Packages /
imlib2
Commits:
a1ace6f6 by loqs at 2024-04-21T12:16:48+00:00
Prevent libtool overlinking
- - - - -
1 changed file:
- PKGBUILD
Changes:
=
PKGBUILD
=
@@ -33,6 +33,7 @@ build() {
--sysconfdir=/etc/imlib2 \
--x-libraries=/usr/lib \
--enable-amd64
+ sed -i -e 's/ -shared / -Wl,-O1,--as-needed\0/g' libtool
make
}
View it on GitLab:
https://gitlab.archlinux.org/archlinux/packaging/packages/imlib2/-/commit/a1ace6f66c274f777eed8377089e1f636a486fdf
--
View it on GitLab:
https://gitlab.archlinux.org/archlinux/packaging/packages/imlib2/-/commit/a1ace6f66c274f777eed8377089e1f636a486fdf
You're receiving this email because of your account on gitlab.archlinux.org.
[Git][archlinux/packaging/packages/python-pyarrow][main] 8 commits: Change to SPDX license identifier
Christian Heusel pushed to branch main at Arch Linux / Packaging / Packages /
python-pyarrow
Commits:
228cf4b4 by loqs at 2024-05-31T21:23:39+00:00
Change to SPDX license identifier
https://github.com/apache/arrow/blob/apache-arrow-16.1.0/LICENSE.txt
- - - - -
4f5571f4 by loqs at 2024-05-31T21:24:49+00:00
Change build time SIMD level to None use runtime detection for all SIMD
features.
Fixes
https://gitlab.archlinux.org/archlinux/packaging/packages/python-pyarrow/-/issues/4.
- - - - -
0abb7f53 by loqs at 2024-05-31T21:24:51+00:00
Add substrait module.
Fixes
https://gitlab.archlinux.org/archlinux/packaging/packages/python-pyarrow/issues/1
- - - - -
bf0f646e by loqs at 2024-05-31T21:24:52+00:00
Harmonize PYARROW_WITH_PARQUET_ENCRYPTION with PARQUET_REQUIRE_ENCRYPTION in
arrow.
- - - - -
1b4d7b5a by loqs at 2024-05-31T21:24:52+00:00
Update environment variables based on upstream documentation [1].
[1]:
https://github.com/apache/arrow/blob/main/docs/source/developers/python.rst#relevant-components-and-environment-variables
- - - - -
fb79c717 by loqs at 2024-05-31T21:24:53+00:00
Install pyarrow header files.
Fixes
https://gitlab.archlinux.org/archlinux/packaging/packages/python-pyarrow/issues/2
- - - - -
49d7c014 by loqs at 2024-05-31T21:24:54+00:00
Use a local install for testing.
This removes the need to skip some tests.
- - - - -
75e239e0 by Christian Heusel at 2024-05-31T23:55:56+02:00
upgpkg: 16.1.0-2: various improvements
See
https://gitlab.archlinux.org/archlinux/packaging/packages/python-pyarrow/-/merge_requests/1
for details
- - - - -
2 changed files:
- .SRCINFO
- PKGBUILD
Changes:
=
.SRCINFO
=
@@ -1,10 +1,10 @@
pkgbase = python-pyarrow
pkgdesc = Columnar in-memory analytics layer for big data — Python
module.
pkgver = 16.1.0
- pkgrel = 1
+ pkgrel = 2
url = https://arrow.apache.org
arch = x86_64
- license = Apache
+ license = Apache-2.0
checkdepends = python-brotli
checkdepends = python-hypothesis
checkdepends = python-pandas
=
PKGBUILD
=
@@ -6,11 +6,11 @@ _pkg=arrow
_pkgname=pyarrow
pkgname=python-${_pkgname}
pkgver=16.1.0
-pkgrel=1
+pkgrel=2
pkgdesc="Columnar in-memory analytics layer for big data — Python module."
arch=(x86_64)
url="https://arrow.apache.org;
-license=(Apache)
+license=(Apache-2.0)
depends=(arrow gcc-libs glibc python python-numpy python-setuptools-scm)
optdepends=('python-cffi: interact with C code'
'python-pandas: Pandas integration'
@@ -37,49 +37,37 @@ prepare() {
build() {
cd apache-${_pkg}-${pkgver}/python
- ARROW_HOME=/usr \
- PARQUET_HOME=/usr \
- PYARROW_BUNDLE_ARROW_CPP_HEADERS=0 \
- PYARROW_BUNDLE_PLASMA_EXECUTABLE=0 \
- PYARROW_WITH_HDFS=1 \
- PYARROW_WITH_FLIGHT=1 \
+ #
https://github.com/apache/arrow/blob/main/docs/source/developers/python.rst#relevant-components-and-environment-variables
+ PYARROW_CMAKE_OPTIONS="-DARROW_SIMD_LEVEL=NONE
-DARROW_RUNTIME_SIMD_LEVEL=MAX" \
PYARROW_WITH_DATASET=1 \
+ PYARROW_WITH_FLIGHT=1 \
+ PYARROW_WITH_HDFS=1 \
+ PYARROW_WITH_ORC=1 \
PYARROW_WITH_PARQUET=1 \
- PYARROW_WITH_PLASMA=1 \
+ PYARROW_WITH_PARQUET_ENCRYPTION=1 \
+ PYARROW_WITH_SUBSTRAIT=1 \
PYARROW_WITH_TENSORFLOW=1 \
- PYARROW_WITH_ORC=1 \
python -m build --wheel --no-isolation
}
check() {
- cd apache-${_pkg}-${pkgver}/python
- local python_version=$(python -c 'import sys; print("".join(map(str,
sys.version_info[:2])))')
- # rename source to avoid name clash
- mv pyarrow _nopyarrow
- PYTHONPATH="${PWD}/build/lib.linux-${CARCH}-cpython-${python_version/./}" \
+ python -m venv --system-site-packages local-env
+ local-env/bin/python -m installer apache-${_pkg}-${pkgver}/python/dist/*.whl
ARROW_TEST_DATA="${srcdir}"/arrow-testing/data \
- ARROW_HOME=/usr \
- PARQUET_HOME=/usr \
- pytest -vv --color=yes -k 'not test_cython_api and not test_visit_strings
and not test_env_var and not test_get_include and not test_pyarrow_include'
- mv _nopyarrow pyarrow
+ local-env/bin/python -m pytest -vv --color=yes --pyargs pyarrow
}
package(){
cd apache-${_pkg}-${pkgver}/python
- ARROW_HOME=/usr \
- PARQUET_HOME=/usr \
- PYARROW_BUNDLE_ARROW_CPP_HEADERS=0 \
- PYARROW_BUNDLE_PLASMA_EXECUTABLE=0 \
- PYARROW_WITH_HDFS=1 \
- PYARROW_WITH_FLIGHT=1 \
- PYARROW_WITH_DATASET=1 \
- PYARROW_WITH_PARQUET=1 \
- PYARROW_WITH_PLASMA=1 \
- PYARROW_WITH_TENSORFLOW=1 \
- PYARROW_WITH_ORC=1 \
python -m installer --destdir="${pkgdir}" dist/*.whl
# drop tests from install
local site_packages=$(python -c "import site;
print(site.getsitepackages()[0])")
rm -rf "${pkgdir}${site_packages}"/${_pkgname}/{conftest.py,tests}
+
+ # move python include files
+ install -d "
[Git][archlinux/packaging/packages/python-pyarrow] Pushed new tag 16.1.0-2
Christian Heusel pushed new tag 16.1.0-2 at Arch Linux / Packaging / Packages / python-pyarrow -- View it on GitLab: https://gitlab.archlinux.org/archlinux/packaging/packages/python-pyarrow/-/tree/16.1.0-2 You're receiving this email because of your account on gitlab.archlinux.org.
[ptxdist] [PATCH v2] ntp: Version bump. 4.2.8p17 -> 4.2.8p18
Mostly bugfixes. https://www.ntp.org/support/securitynotice/4_2_8-series-changelog/#428p18 * Remove obsoleted options. * Correct a pthread build detection issue with gcc-14. Assume existing func. Unfortunately, a patch didn't make it into p18. Probably nobody bothered with the new compiler before releasing p18. * License file had date changes. Signed-off-by: Christian Melki --- rules/ntp.make | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/rules/ntp.make b/rules/ntp.make index b813df9db..21bae26a1 100644 --- a/rules/ntp.make +++ b/rules/ntp.make @@ -15,15 +15,15 @@ PACKAGES-$(PTXCONF_NTP) += ntp # # Paths and names # -NTP_VERSION:= 4.2.8p17 -NTP_MD5:= a15558df580bd1b955a105a8b91c078f +NTP_VERSION:= 4.2.8p18 +NTP_MD5:= 516bdabd94ab7c824e9771390761a46c NTP:= ntp-$(NTP_VERSION) NTP_SUFFIX := tar.gz NTP_URL:= http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/$(NTP).$(NTP_SUFFIX) NTP_SOURCE := $(SRCDIR)/$(NTP).$(NTP_SUFFIX) NTP_DIR:= $(BUILDDIR)/$(NTP) NTP_LICENSE:= ntp -NTP_LICENSE_FILES := file://COPYRIGHT;md5=3a8ffebbcad335abf2c39fec38671eec +NTP_LICENSE_FILES := file://COPYRIGHT;md5=2311915f6d5142b06395231b0ffeaf29 # # Prepare @@ -32,6 +32,7 @@ NTP_LICENSE_FILES := file://COPYRIGHT;md5=3a8ffebbcad335abf2c39fec38671eec NTP_CONF_ENV := \ $(CROSS_ENV) \ ac_cv_search_MD5Init=no \ + ol_cv_func_pthread_detach=yes \ libopts_cv_test_dev_zero=yes \ ntp_cv_vsnprintf_percent_m=yes @@ -60,7 +61,6 @@ NTP_CONF_OPT := \ --enable-linuxcaps \ --disable-solarisprivs \ --disable-trustedbsd-mac \ - --without-arlib \ --without-net-snmp-config \ --disable-libseccomp \ --disable-debug-timing \ @@ -121,7 +121,6 @@ NTP_CONF_OPT:= \ --$(call ptx/endis, PTXCONF_NTP_VARITEXT)-VARITEXT \ --$(call ptx/endis, PTXCONF_NTP_SEL240X)-SEL240X \ --$(call ptx/wwo, PTXCONF_NTP_CRYPTO)-crypto \ - --without-rpath \ --$(call ptx/endis, PTXCONF_NTP_CRYPTO)-openssl-random \ --$(call ptx/endis, PTXCONF_NTP_CRYPTO)-autokey \ --disable-kmem \ -- 2.34.1
Integrated: 8314480: Memory ordering spec updates in java.lang.ref
On Mon, 13 Nov 2023 22:31:16 GMT, Brent Christian wrote: > Classes in the `java.lang.ref` package would benefit from an update to bring > the spec in line with how the VM already behaves. The changes would focus on > _happens-before_ edges at some key points during reference processing. > > A couple key things we want to be able to say are: > - `Reference.reachabilityFence(x)` _happens-before_ reference processing > occurs for 'x'. > - `Cleaner.register()` _happens-before_ the Cleaner thread runs the > registered cleaning action. > > This will bring Cleaner in line (or close) with the memory visibility > guarantees made for finalizers in [JLS > 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5): > _"There is a happens-before edge from the end of a constructor of an object > to the start of a finalizer (§12.6) for that object."_ This pull request has now been integrated. Changeset: 2cae9a03 Author:Brent Christian URL: https://git.openjdk.org/jdk/commit/2cae9a0397f4e46c6faec0a998ecad1c7015564d Stats: 229 lines in 4 files changed: 132 ins; 19 del; 78 mod 8314480: Memory ordering spec updates in java.lang.ref Reviewed-by: dholmes, alanb, darcy - PR: https://git.openjdk.org/jdk/pull/16644
[Git][archlinux/packaging/packages/exim] Pushed new tag 4.97.1-2
Christian Heusel pushed new tag 4.97.1-2 at Arch Linux / Packaging / Packages / exim -- View it on GitLab: https://gitlab.archlinux.org/archlinux/packaging/packages/exim/-/tree/4.97.1-2 You're receiving this email because of your account on gitlab.archlinux.org.
[Git][archlinux/packaging/packages/exim][main] upgpkg: 4.97.1-2: rebuild for openssl 3.3
Christian Heusel pushed to branch main at Arch Linux / Packaging / Packages /
exim
Commits:
328b5af8 by Christian Heusel at 2024-05-31T22:54:36+02:00
upgpkg: 4.97.1-2: rebuild for openssl 3.3
fixes https://gitlab.archlinux.org/archlinux/packaging/packages/exim/-/issues/6
- - - - -
2 changed files:
- .SRCINFO
- PKGBUILD
Changes:
=
.SRCINFO
=
@@ -1,7 +1,7 @@
pkgbase = exim
pkgdesc = Message Transfer Agent
pkgver = 4.97.1
- pkgrel = 1
+ pkgrel = 2
url = https://www.exim.org/
arch = x86_64
license = GPL
=
PKGBUILD
=
@@ -7,7 +7,7 @@
pkgname=exim
pkgver=4.97.1
-pkgrel=1
+pkgrel=2
pkgdesc='Message Transfer Agent'
arch=('x86_64')
url='https://www.exim.org/'
View it on GitLab:
https://gitlab.archlinux.org/archlinux/packaging/packages/exim/-/commit/328b5af8335c4139d1c82ff3d76ff747352ed7ec
--
View it on GitLab:
https://gitlab.archlinux.org/archlinux/packaging/packages/exim/-/commit/328b5af8335c4139d1c82ff3d76ff747352ed7ec
You're receiving this email because of your account on gitlab.archlinux.org.
