- Arch-dev-public - lists.archlinux.org

[arch-dev-public] A contrib repository
by Morten Linderud 12 Sep '19

12 Sep '19

There is a *lot* of small tools people have written over the years that resides in bin/ directories which could be useful for more people. We also have several such tools on soyuz, where sogrep was added to devtools this week. I have been thinking it could be great to have a simple `contrib` repository where every team member has commit access. This could work as a staging area for tools we would like to promote to `devtools` later on. We could maybe sort this into directories for its purpose: * packaging * security * devops * testing * bugwrangler * misc Tools that can be added here is the `ch` scripts from Bluewind, and the pkg-* tools eli has created. I also have some tools to look for pkgname in archweb, check them out from svn and check them against a nvchecker file. This would hopefully give us a space where we can experiment with new maintainer tools in a collaborative manner. I'd love to hear some feedback or thoughs on this! -- Morten Linderud PGP: 9C02FF419FECBE16

8 14

[arch-dev-public] new archweb release
by Jelle van der Waa 11 Sep '19

11 Sep '19

Hi all, A new archweb release has been deployed on our server, with a couple of notable changes: - Signoff status has been moved up in the Developer Dashboard for more attention - When enough signoffs are reached, archweb automatically sends a mail to the packager that the package has reached the target signoffs! If this is too spammy we can consider a "daily" report. In the future release, I aim to improve onboarding of testers and further investigate where the lack of signoffs comes from. So far it seems we have around ~ 18 "active" testers.

3 2

[arch-dev-public] Semi-away till 2019
by Bartłomiej Piotrowski 06 Sep '19

06 Sep '19

Hi all, As I have free time shortage lately, I think it's fair to officially say I will be in semi-away mode till 2019. I will try my best to keep up with uncomplicated pkgver bumps for packages I maintain on my own and make sure all keys are properly signed, but that's all I can promise. It also means I'm unable to give toolchain attention it deserves. Please poke me somewhere if you happen to be interested in co-maintaining it. My responses on IRC or via e-mail may be also delayed so take that into account before kicking me out. Bartłomiej

4 4

[arch-dev-public] packaging hunspell dictionaries converted for qt5-webengine
by Eli Schwartz 04 Sep '19

04 Sep '19

QtWebEngine supports spellchecking: https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker However, they have helpfully decided (steered by upstream chromium) to *not* use hunspell dictionaries, and instead to use... hunspell dictionaries stored in /usr/share/qt/qtwebengine_dictionaries/ as ".bdic" files, because this is supposedly "more efficiently read by chromium". (Actually QtWebEngine's spell-checking infrastructure is entirely willing to read dictionaries in /usr/bin/qtwebengine_dictionaries before looking in /usr/share because clearly they've put great thought into how this is all supposed to work on a conceptual design level especially for distro packaging.) So I have a program -- pageedit -- which just added spellchecking support via qtwebengine in the latest release, and I would like to support that. And I don't want to see people being personally responsible for installing their own stuff in /usr/share. While I'm at it, Morten (Foxboron) pointed out to me that qutebrowser also supports spellchecking, and it currently provides a user script which downloads preconverted dictionaries from chromium's git repository into $HOME/.local/share/qutebrowser/ ... because there's apparently no guidance or precedent for actually distributing these dictionaries. (In fact, currently only Fedora seems to make these dictionaries available to users.) It's possible to convert them yourself, using the qwebengine_convert_dict tool shipped in the qt5-webengine package. I think it would be nice if users were able to obtain these dictionaries properly, but I'm not positive what the best way would be. Ideas: - Ship a pacman hook to convert whatever the user has installed, implemented via the following libalpm script and hooks: https://paste.xinu.at/m-ydTjU/ - make every hunspell-* package makedepend on qt5-webengine and produce those dictionaries - same thing but also make split packages for basically a tiny data file - force users to install an out of date AUR package not kept in sync with hunspell-* (this one is just a joke) The advantage of a hook is that users with webengine installed automatically get magic google-approved dictionaries corresponding to the hunspell dictionaries they have installed. The advantage of modifying each hunspell-* package is saving about 0.38 seconds per file at installation time, plus users don't have weird untracked files in some cloistered dir in /usr/ The advantage of doing anything other than possibility #3 is "avoid adding another 34 packages to the repositories, which users need to manually install in addition to the other dictionaries they explicitly installed". ... Prior art: Fedora uses rpm post-install filetriggers: https://src.fedoraproject.org/rpms/qt5-qtwebengine/blob/master/f/qt5-qtwebe… Gentoo has a proposal for a package that runs the conversion tool on each file the user has installed in /usr/share/hunspell/ and packages the results. ... Thoughts on the best way forward to make these dictionaries available on Arch Linux? -- Eli Schwartz Bug Wrangler and Trusted User

5 8

[arch-dev-public] deepin-kwin removed from [community-testing]
by Felix Yan 03 Sep '19

03 Sep '19

There are multiple major issues with the new version 5.0.0, and upstream doesn't yet have figured them out after a month. Currently it would be better to stick with 0.1.0. -- Regards, Felix Yan

1 0

[arch-dev-public] Wiki Update in progress
by Pierre Schmitz 01 Sep '19

01 Sep '19

Hi there, I triggered a Wiki update. Unfortunately the update script is running longer than expected. So pages appear to be empty. Greetings, Pierre

2 4

[arch-dev-public] Speaking of OCaml: willing to orphan merlin + deps
by Bruno Pagani 20 Aug '19

20 Aug '19

Hi there, I’m riding on the train of OCaml e-mails to announce that I’m going to orphan merlin (OCaml smart auto-completion for emacs/vim) and its dependency tree as I’m no longer using any of those and don’t expect to use them again: – cppo – dune – menhir – merlin – ocaml-biniou – ocaml-easy-format – ocaml-yojson Note that merlin was recently upgraded to 3.3.2 by Jürgen (thanks for that), but rather than using Opam the new dependency should be added to the repo if someone is willing to maintain this stack. I had started with menhir, but some other were required IIRC. Please let me know if you are interested, adopt them and I’ll disown right after. Else, I’ll drop all of them to the AUR in ~1 week. Regards, Bruno/Archange

2 2

[arch-dev-public] [arch-dev] State of OCaml-Update (stuck by deprecation of camlp4)
by Jürgen Hötzel 16 Aug '19

16 Aug '19

Hi, Unfortunately it is not possible to compile camlp4 with OCaml >= 4.08. But some well known packages depend on this preprocessor. E.g. :Haxe, lablgtk2 (therefore also: Unison and Coq). I don't see that these projects will be migrated to camlp5 or ppx in the near future. Therefore there are only 2 options from my point of view: 1. OCaml-4.07 and Ocaml >= 4.08 in [EXTRA]. 2. removal of Haxe, lablgtk2, Unison and Coq. I prefer 1. What do you think? Same issue discussed on Debian Bug Tracker: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933722

3 3

Re: [arch-dev-public] packaging hunspell dictionaries converted for qt5-webengine
by Eli Schwartz 13 Aug '19

13 Aug '19

On August 13, 2019 5:17:27 AM EDT, Florian Bruhin <me(a)the-compiler.org> wrote: > Hey, > > My $0.02 as qutebrowser maintainer (off-list because I can't send to > arch-dev-public): Forwarded back to a-d-p with inline comments. :) > On Mon, Aug 12, 2019 at 07:50:44PM -0400, Eli Schwartz via > arch-dev-public wrote: > > QtWebEngine supports spellchecking: > > https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker > > > > However, they have helpfully decided (steered by upstream chromium) > to > > *not* use hunspell dictionaries, and instead to use... hunspell > > dictionaries stored in /usr/share/qt/qtwebengine_dictionaries/ as > > ".bdic" files, because this is supposedly "more efficiently read by > > chromium". > > The actual spell checking is implemented inside Chromium, all > QtWebEngine does > with the dictionaries is passing them to Chromium. I don't think > they're happy > with bdic files either, but the alternatives aren't really an option > (completely reimplementing spell checking support by patching their > copy of > Chromium, with a lot of added friction each time they want to update > their > Chromium snapshot). > > So it pretty much boils down to "blame Google/Chromium" ;) Yeah, but I still wanna blame them for npt patching it for the purpose of integrating well. :p > > (Actually QtWebEngine's spell-checking infrastructure is entirely > > willing to read dictionaries in /usr/bin/qtwebengine_dictionaries > before > > looking in /usr/share because clearly they've put great thought into > how > > this is all supposed to work on a conceptual design level especially > for > > distro packaging.) > > Agreed this doesn't make much sense for Linux distributions. It > happens because > it looks next to the executable, which probably *does* make a lot of > sense for > Windows, macOS, embedded scenarios, bundled apps, etc. It doesn't help > much for > distributions, but it also doesn't hurt. > > > So I have a program -- pageedit -- which just added spellchecking > > support via qtwebengine in the latest release, and I would like to > > support that. And I don't want to see people being personally > > responsible for installing their own stuff in /usr/share. While I'm > at > > it, Morten (Foxboron) pointed out to me that qutebrowser also > supports > > spellchecking, and it currently provides a user script which > downloads > > preconverted dictionaries from chromium's git repository into > > $HOME/.local/share/qutebrowser/ ... because there's apparently no > > guidance or precedent for actually distributing these dictionaries. > (In > > fact, currently only Fedora seems to make these dictionaries > available > > to users.) > > Oh, I didn't know Fedora packages them! I opened a qutebrowser issue > too: > https://github.com/qutebrowser/qutebrowser/issues/4966 > > > It's possible to convert them yourself, using the > > qwebengine_convert_dict tool shipped in the qt5-webengine package. I > > think it would be nice if users were able to obtain these > dictionaries > > properly, but I'm not positive what the best way would be. Ideas: > > > > - Ship a pacman hook to convert whatever the user has installed, > > implemented via the following libalpm script and hooks: > > https://paste.xinu.at/m-ydTjU/ > > - make every hunspell-* package makedepend on qt5-webengine and > produce > > those dictionaries > > - same thing but also make split packages for basically a tiny data > file > > - force users to install an out of date AUR package not kept in sync > > with hunspell-* (this one is just a joke) > > > > The advantage of a hook is that users with webengine installed > > automatically get magic google-approved dictionaries corresponding > to > > the hunspell dictionaries they have installed. > > > > The advantage of modifying each hunspell-* package is saving about > 0.38 > > seconds per file at installation time, plus users don't have weird > > untracked files in some cloistered dir in /usr/ > > > > The advantage of doing anything other than possibility #3 is "avoid > > adding another 34 packages to the repositories, which users need to > > manually install in addition to the other dictionaries they > explicitly > > installed". > > Depending on how big those dictionaries are, they all could be in a > single > qt5-webengine-dicts package? Though I guess they aren't much smaller > than the > hunspell ones, and there probably was a reason those were split. Well, they are different source code with different versions, so I see no gain or practical way to implement a combined hunspell package. A combined webengine dicts package would need to makedepend on all hunspell dict packages, then get updated for any hunspell dict update. > On Tue, Aug 13, 2019 at 09:22:39AM +0200, Jan Alexander Steffens via > arch-dev-public wrote: > > On Tue, Aug 13, 2019 at 9:04 AM Bartłomiej Piotrowski via > arch-dev-public < > > arch-dev-public(a)archlinux.org> wrote: > > > I'd go with updating all packages to ship the converted files. > > > Cluttering /usr with untracked files doesn't sound good. > > > > Yeah, I agree. I think we should package convert_dict from the > Chromium > > sources as a new package to makedepend on. > > I'm assuming those are compatible to each other? It does seem like it > from the > sources: > > https://github.com/qt/qtwebengine/blob/v5.13.0/src/tools/qwebengine_convert… > https://github.com/qt/qtwebengine-chromium/blob/75-based/chromium/chrome/to… > > > Assuming that WebEngine will not be the only consumer of .bdic > > dictionaries, how about putting them in /usr/share/bdic, and then > either > > patching sources to use that dir or linking whatever engine-specific > > dictionaries there? > > > > We could also put them with the other dictionaries into > > /usr/share/hunspell, assuming that won't cause problems. > > I guess Qt wouldn't be opposed to a change (for Qt 5.14 I guess) > adding one of > those paths. > > Maybe the Chromium package could load them as well from there? > > Florian I have no idea at all what chromium does do right now! -- Eli Schwartz Bug Wrangler and Trusted User

1 0

[arch-dev-public] [arch-dev] State of OCaml-Update (stuck by deprecation of camlp4)
by Jürgen Hötzel 13 Aug '19

13 Aug '19

Hi, Unfortunately it is not possible to compile camlp4 with OCaml >= 4.08. But some well known packages depend on this preprocessor. E.g. :Haxe, lablgtk2 (therefore also: Unison and Coq). I don't see that these projects will be migrated to camlp5 or ppx in the near future. Therefore there are only 2 options from my point of view: 1. OCaml-4.07 and Ocaml >= 4.08 in [EXTRA]. 2. removal of Haxe, lablgtk2, Unison and Coq. I prefer 1. What do you think? Same issue discussed on Debian Bug Tracker: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933722

2 2