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

[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

[arch-dev-public] I will be away this week
by Filipe Laíns 08 Aug '19

08 Aug '19

Hi, I will be away this week. I understand some of you have questions specifically about the new discord packages. Feel free to take any action that you feel necessary, delete, modify, etc..., just document that (email, irc or etc). Thabk you, Filipe Laíns 3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2

2 1

[arch-dev-public] New ideas for notifying users about (minor) changes
by Christian Rebischke 30 Jul '19

30 Jul '19

Hello everybody, I got assigned to this issue here: https://bugs.archlinux.org/task/62823 The users would like to have a notice in pre/post install/upgrade notifications via pacman .install files. I am not a fan of spamming such news via pacman and I think the installation/upgrade process should be clean of such messages, but I don't have access to the news tool on our website as well. So what can we do here? I am a big fan of Gentoos Newsletter feature[1]. It would be super awesome if we would have a tool such like `archnews <packagename>` to retrieve NEWS about a certain package from an endpoint. This endpoint should be controllable by every maintainer (devs and TUs included). I discussed this with coderobe a bit and we came to different solutions: Solution 1: a NEWS file inside of the package repository: -------------------------------------------------------- A maintainer could upload a `NEWS` file into the package repository and then a client could grab this information directly via downloading the file from: https://git.archlinux.org/svntogit/community.git/plain/trunk/NEWS?h=package… Pro: + every maintainer could control this NEWS file easily via our current tools. + It's easy to download the NEWS files (we can expect new tools from the community) Con: - We bloat our repository Solution 2: commit messages as NEWS ------------------------------------ The maintainer could/should put such news into the latest commit message. Pro: + no extra file + using existing infrastructure + one workflow Con: - I need an actual change in the repository to create a new NEWS object (If we have a look on my example with strongswan, I would need to add something in the PKGBUILD to make a new commit to make a new NEWS object) - It's more difficult to get with tools. The user needs to checkout the repository (in solution 1 it can be just a curl call) Solution 3: A webapp on news.archlinux.org with a fancy UI ----------------------------------------------------------- This solution would be the most work. We could have a new webapp (such like our security tracker) just for NEWS objects. Every maintainer should have access to their assigned packages. Pro: + Fancy + Easy to use + API endpoints Con: - A lot of work ------------------------------------------------------------- I would go for solution 1. What would be interesting to know for me: 1. Do you think that we actually *need* such a tool? 2. Would you use such a tool/workflow? 3. Do you have other/better ideas? I hope for an interesting constructive discussion. Best regards chris [1] https://wiki.gentoo.org/wiki/Gentoo_Cheat_Sheet#Gentoo_Monthly_Newsletter_.…

6 10

[arch-dev-public] Database maintenance affecting AUR & BBS
by Jelle van der Waa 27 Jul '19

27 Jul '19

Hi all, Luna requires some database maintenance to improve the stability of MySQL. This will affect the AUR and the BBS (forums) which will be down for some time to dump and import the aur and bbs database. It is expected that this will take an hour at max. Maintenance will shall start today at 12:00 UTC. -- Jelle van der Waa

1 0

[arch-dev-public] Dropping dingo from [community]
by Felix Yan 27 Jun '19

27 Jun '19

Hi All, I have removed dingo the Google DNS-over-HTTPS client from [community]. The upstream is inactive for years and supports Google only. I would recommend dns-over-https [1] instead which has support for multiple protocols and is still actively maintained. Note that Google announced [2] yesterday that they recommend to use the newer IETF protocol (at a new endpoint), which is also the protocol of all other major DoH providers (CloudFlare, Quad9, etc). [1] https://www.archlinux.org/packages/community/x86_64/dns-over-https/ [2] https://security.googleblog.com/2019/06/google-public-dns-over-https-doh.ht… -- Regards, Felix Yan

2 1

[arch-dev-public] HEADS UP: Qt 5.13 in [testing]
by Antonio Rojas 22 Jun '19

22 Jun '19

The usual warning: anything built against 5.13 will automatically get a runtime dependency on it, so it will need to wait in testing until Qt itself moves.

1 0

[arch-dev-public] Drop ekiga?
by jan＠jgc.homeip.net 10 Jun '19

10 Jun '19

Hello, I would like to drop Ekiga. The software hasn't seen a release in years, the git master branch has some active development now and then, but a release for Ekiga5 is not near (though upstream stated the software itself is ready enough to release v5 a year ago). Alternative is to bump Ekiga to git master and hope it doesn't have too much bugs. Issue that gets fixed: one package less that depends on gconf Issue that remains: Ekiga still depends on deprecated and unmaintained versions of Opal/ptlib Regards, Jan de Groot

3 3