I have created a merge request to update the documentation to reflect the
changes in
the Qt packaging that have entered unstable with qt6-webengine
6.4.2-final+dfsg-1.
https://salsa.debian.org/debian/dictionaries-common/-/merge_requests/6[1]
https://tracker.debian.org/pkg/qt6-webengine[2]
Am 16.02.23 um 21:37 schrieb Soren Stoutner:
It would be fine with me if Chromium provided the virtual package and symlink
used to build the .bdic files. My only concern is that it is important that
these always exist in Stable and Old Stable going forward.
Yes. Not only for backporting but
It would be fine with me if Chromium provided the virtual package and symlink
used to build the .bdic files. My only concern is that it is important that
these always exist in Stable and Old Stable going forward. Otherwise, it
makes backporting Hunspell language packages more difficult (not
Related to this - we got approval for chromium to ship in bookworm
(#1004441). That doesn't necessarily mean it'll be in future releases
(trixie or whatever), of course, but if it's easier for the dependency
chain; I'm open to discussing having chromium provide it.
I haven't followed all of
Honestly, the impact on maintaining the Qt WebEngine packages is negligible.
The Debian packages have been shipping the binary dictionary conversion tool
for a long time, which is the biggest piece of the puzzle and has already been
solved. Upstream (both Qt and Chromium) have not modified
El jueves, 16 de febrero de 2023 13:42:42 -03 Soren Stoutner escribió:
> Seeing as this is how Qt WebEngine is designed upstream, I think it is
> important to support it in Debian. From my personal perspective, the
> program I am developing (Privacy Browser) depends on Qt WebEngine and needs
>
Seeing as this is how Qt WebEngine is designed upstream, I think it is
important to support it in Debian. From my personal perspective, the program
I am developing (Privacy Browser) depends on Qt WebEngine and needs spell
checking functionality to be viable in Debian.
I have been working with
By the way: I **do** understand that what you all are proposing is an easy way
out and sounds like it makes sense.
Now I have been around Qt for 10+ years already, and suffered each and every
web engine of the day source code during all this time. I know how problematic
it can be and how, at
On jueves, 16 de febrero de 2023 02:40:21 -03 Rene Engelhard wrote:
> Hi,
>
> Am 16.02.23 um 02:24 schrieb Lisandro Damian Nicanor Perez Meyer:
> > - Hunspell dictionaries should be handled by... hunspell. Yes, I know
> > this was
> > considered and it's still not possible. But the fact that
Hi,
Am 16.02.23 um 06:40 schrieb Rene Engelhard:
root@frodo:/# apt-cache showsrc igerman98
Package: igerman98
root@frodo:/# grep-dctrl -FBuild-Depends-Indep qt6-web
/var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources
-sPackage
Package: eo-spell
Package: espa-nol
Hi,
Am 16.02.23 um 02:24 schrieb Lisandro Damian Nicanor Perez Meyer:
- Hunspell dictionaries should be handled by... hunspell. Yes, I know
this was
considered and it's still not possible. But the fact that webengine ships them
is not enough a reason to expose them to the world instead of
On martes, 14 de febrero de 2023 19:28:53 -03 Soren Stoutner wrote:
> Which part do you not understand about not being needed on both Qt 5 and Qt
> 6? The part about building the .bdic files or the part about Qt WebEngine
> using the .bdic files at runtime?
Sorry, wrong question on my side.
I
Which part do you not understand about not being needed on both Qt 5 and Qt 6?
The part about building the .bdic files or the part about Qt WebEngine using
the .bdic files at runtime?
On Tuesday, February 14, 2023 12:25:20 PM MST Lisandro Damián Nicanor Pérez
Meyer wrote:
> One thing I do not
One thing I do not understand is why is this needed on both Qt 5 and Qt 6?
What I understand from the thread is that currently any of them can provide
the dictionaries, so why not keeping this under just one source package?
signature.asc
Description: This is a digitally signed message part.
Yes, the packages will continue to ship the conversion tools under their
current names in
perpetuity. Because Qt goes through version transitions, there are often two
version of Qt
available in Debian (currently Qt 5 and Qt 6), both of which will ship this
tool under a
versioned path. The
El sáb, 4 feb 2023 a las 20:20, Rene Engelhard () escribió:
>
> Hi,
>
> Am 04.02.23 um 19:14 schrieb Soren Stoutner:
> > Seeing as how .bdic files are not exclusive to Qt, qt-convert-dict is
> > probably
> > not the most accurate name, but bdic-convert-dict would make sense. Another
> > option
Hi,
Am 04.02.23 um 19:14 schrieb Soren Stoutner:
Seeing as how .bdic files are not exclusive to Qt, qt-convert-dict is probably
not the most accurate name, but bdic-convert-dict would make sense. Another
option would be to name it convert-bdic. The Chromium upstream names the tool
Seeing as how .bdic files are not exclusive to Qt, qt-convert-dict is probably
not the most accurate name, but bdic-convert-dict would make sense. Another
option would be to name it convert-bdic. The Chromium upstream names the tool
convert_dict, but we aren’t beholden to follow their lead.
Hi,
Am 04.02.23 um 18:30 schrieb Soren Stoutner:
I have submitted a merge request to the qt6webengine package that
implements what has been discussed.
https://salsa.debian.org/qt-kde-team/qt6/qt6-webengine/-/merge_requests/4
Once it is merged, I will prepare a merge request for the
I have submitted a merge request to the qt6webengine package that implements
what has
been discussed.
https://salsa.debian.org/qt-kde-team/qt6/qt6-webengine/-/merge_requests/4[1]
Once it is merged, I will prepare a merge request for the documentation in this
package
that reflects these
In discussion with the Qt 5 maintainer, we have found a solution that does not
use a
symlink, which will be included in the upcoming 5.15.12+dfsg-3 release.
More information can be found at:
https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/merge_requests/12[1]
On Monday, January 9, 2023
For sake of completeness, it was previously discussed that it would be
possible to patch the Qt WebEngine source to directly look for the
dictionaries in /usr/share/hunspell-bdic instead of the default upstream
location. It is unclear how much ongoing maintenance effort that would entail,
but
Although I can think of some circumstances where a dangling symlink can pose a
security risk (depending on where it is located, where it points to, if there
are different permissions on who can write to each location, and what type of
information programs read or write to the link), but I
Hi!
On Fri, 6 Jan 2023 at 12:22, Dmitry Shachnev wrote:
>
> On Thu, Jan 05, 2023 at 03:18:14PM -0700, Soren Stoutner wrote:
> > What is the Debian policy on this? If a user does not have any Hunspell
> > dictionaries installed it will result in a dangling symlink. We could have
> > some
On Thu, Jan 05, 2023 at 03:18:14PM -0700, Soren Stoutner wrote:
> What is the Debian policy on this? If a user does not have any Hunspell
> dictionaries installed it will result in a dangling symlink. We could have
> some essential package create the /usr/share/hunspell-bdic directory, but in
What is the Debian policy on this? If a user does not have any Hunspell
dictionaries installed it will result in a dangling symlink. We could have
some essential package create the /usr/share/hunspell-bdic directory, but in
that case /usr/share/huspell-bdic will exist on systems that don’t
Hi Soren!
On Wed, Jan 04, 2023 at 02:28:45PM -0700, Soren Stoutner wrote:
> Dmitry,
>
> I wanted to followup on the topic of symlinks from /usr/share/qt5/
> qtwebengine_dictionaries and /usr/share/qt6/qtwebengine_dictionaries to /usr/
> share/hunspell-bdic.
>
> Now that some of the languages are
Dmitry,
I wanted to followup on the topic of symlinks from /usr/share/qt5/
qtwebengine_dictionaries and /usr/share/qt6/qtwebengine_dictionaries to /usr/
share/hunspell-bdic.
Now that some of the languages are shipping .bdic files, anyone can test how
this works with programs that use Qt
ne Engelhard"
> , "Mattia Rizzolo" , "Debian Chromium
> Team" ,
> "Timothy Pearson"
> Sent: Monday, December 26, 2022 2:33:52 PM
> Subject: Re: Bug#1020387: dictionaries-common: Consensus regarding the
> packaging of the Qt WebEngine hunspell b
Hi Andres!
On Mon, Dec 26, 2022 at 03:33:52PM -0500, Andres Salomon wrote:
> It's definitely feasible*. However, there's the question of whether we want
> other important packages depending on chromium.
> https://bugs.debian.org/1004441 shows that it's still an outstanding
> question whether
On Mon, Dec 26 2022 at 10:32:20 AM -0700, Soren Stoutner
wrote:
Dmitry
It hasn’t been discussed, but I think it would make sense for
Chromium to ship the convert_dict tool as it is the upstream for the
project. I suppose the reason why the discussion was around how it
is shipped in the
El vie, 23 dic 2022 a las 17:21, Roland Rosenfeld
() escribió:
>
> Hi Agustin!
>
> > By the way, I have been playing with an old helper
> > (installdeb-myspell) shipped with dictionaries-common-dev to help with
> > these bdic files. First cut committed to salsa. Currently
> > installdeb-myspell
Dmitry
It hasn’t been discussed, but I think it would make sense for Chromium to ship
the
convert_dict tool as it is the upstream for the project. I suppose the reason
why the
discussion was around how it is shipped in the Qt packages was because that is
the only
place it is currently
Hi all!
(And sorry for the late response. debian-qt-...@lists.debian.org is a
list for bots, so I didn't get it in my inbox. It's better to use
pkg-kde-t...@alioth-lists.debian.net or @packages.debian.org.)
On Tue, Dec 13, 2022 at 10:43:06AM -0700, Soren Stoutner wrote:
> Can one of the Debian
Hi Agustin!
On Fri, 09 Dec 2022, Agustin Martin wrote:
> By the way, I have been playing with an old helper
> (installdeb-myspell) shipped with dictionaries-common-dev to help with
> these bdic files. First cut committed to salsa. Currently
> installdeb-myspell will fail if no conversion tool is
Agustin,
On Tuesday, December 13, 2022 11:14:22 AM MST Agustin Martin wrote:
> I modified installdeb-myspell to look for both, with qt6 version
> preferred. In policy document, I commented about qt5 version
> existence, but discouraging its use as it will disappear sooner. In
> theory it could be
El mar, 13 dic 2022 a las 18:43, Soren Stoutner () escribió:
>
> Can one of the Debian Qt/KDE maintainers weigh in on the feasibility of
> either creating a meta package that depends on the most recent package that
> includes qwebengine_convert_dict or creating an unversioned package that
>
Agustin,
You are correct that there are currently two copies in Debian, one that comes
with the Qt 5
packages and the other that comes with the Qt 6 packages.
Can one of the Debian Qt/KDE maintainers weigh in on the feasibility of either
creating a
meta package that depends on the most
That’s really cool. Thank you for doing that.
On Friday, December 9, 2022 11:09:00 AM MST Agustin Martin wrote:
> By the way, I have been playing with an old helper
> (installdeb-myspell) shipped with dictionaries-common-dev to help with
> these bdic files. First cut committed to salsa.
El mar, 6 dic 2022 a las 23:34, Agustin Martin
() escribió:
>
> El dom, 4 dic 2022 a las 4:54, Soren Stoutner () escribió:
> >
> > I created an MR:
> >
> > https://salsa.debian.org/debian/dictionaries-common/-/merge_requests/5
> >
> > Please review and make sure I haven’t missed anything or
El dom, 4 dic 2022 a las 4:54, Soren Stoutner () escribió:
>
> I created an MR:
>
> https://salsa.debian.org/debian/dictionaries-common/-/merge_requests/5
>
> Please review and make sure I haven’t missed anything or misrepresented the
> consensus.
Merged.
Will wait some days for possible new
I created an MR:
https://salsa.debian.org/debian/dictionaries-common/-/merge_requests/5[1]
Please review and make sure I haven’t missed anything or misrepresented the
consensus.
On Thursday, November 17, 2022 2:25:17 PM MST Soren Stoutner wrote:
> At this point, the only question left is where
No current changes are needed to QT WebEngine as it currently exists in
Debian. It works just fine as long as the dictionaries are in the canonical
location (or that canonical location is a symlink to the actual location).
I have written some descriptions of my testing of this in earlier posts
Hi,
On Wed, 9 Nov 2022 at 15:13, Soren Stoutner wrote:
[snip]
> This would also require the the Debain Qt/KDE Maintainers add a symlink from /
> usr/share/qt5/qtwebengine_dictionaries and /usr/share/qt6/
> qtwebengine_dictionaries to /usr/share/hunspell-bdic. They can do this in
> whatever
On Thursday, November 17, 2022 3:18:17 PM MST Mattia Rizzolo wrote:>
> What I do want to see *before* we actually release a lo-dicts with these
> is something that actually reads and make use of them *first*.
Privacy Browser PC uses them.
https://www.stoutner.com/privacy-browser-pc/[1]
I would
On Thu, Nov 17, 2022 at 02:25:17PM -0700, Soren Stoutner wrote:
> Based on the lack of opposition, it seems that the following is the consensus
> for packaging .bdic files.
thanks for driving this silent resolution ahah :D
> 1. The .bdic files should be compiled at package creation time.
> 2.
Based on the lack of opposition, it seems that the following is the consensus
for packaging .bdic files.
1. The .bdic files should be compiled at package creation time.
2. The .bdic files should be included in the existing Hunspell language binary
packages.
3. The .bdic files should be
On Sunday, November 13, 2022 3:13:55 PM MST Agustin Martin wrote:
> It is to note that even that 10 years code apparently has support for
> the IGNORE flag, unsupported by the .bdic dicts. Fortunately, seems
> that there are not many dicts using that flag in
> libreoffice-dictionaries.
>
>
El jue, 3 nov 2022 a las 23:33, Soren Stoutner () escribió:
>
> On Friday, October 28, 2022 4:09:45 AM MST Agustin Martin wrote:
> > I am not particularly happy about this (see details below), but seems
> > we will have to package all these .bdic files because qtwebengine and
> > chromium use
I would take the lack of response to indicate that nobody has any strong
objections to packaging the .bdic files inside the existing Hunspell binary
packages.
This means that there is a consensus on the following two items:
1. The .bdic files should be compiled at package creation time
On Friday, October 28, 2022 4:09:45 AM MST Agustin Martin wrote:
> I am not particularly happy about this (see details below), but seems
> we will have to package all these .bdic files because qtwebengine and
> chromium use them. Since some .bdic may fail to build I would rather
> prefer them to
El mar, 25 oct 2022 a las 20:43, Soren Stoutner () escribió:
>
> While we wait for answers as to whether these dictionaries can be used by the
> Chromium package and how they might possibly be integrated with upstream
> Hunspell, I would recommend that we move forward with packaging them in /usr/
While we wait for answers as to whether these dictionaries can be used by the
Chromium package and how they might possibly be integrated with upstream
Hunspell, I would recommend that we move forward with packaging them in /usr/
share/hunspell-bdic. This location provides flexibility for
On Friday, October 14, 2022 11:58:17 AM MST Andres Salomon wrote:
> That would allow chromium and other hunspell users to link against a
> system hunspell when desired, dropping all the bdict versioning stuff
> and the custom paths. I'm pretty sure I could get a patch to link
> against system
On Fri, Oct 14, 2022 at 02:58:17PM -0400, Andres Salomon wrote:
> In my opinion, chromium's (, or QT's, or whoever's) bdic support should be
> merged upstream into hunspell, and hunspell should be shipping bdic files in
> /usr/share/hunspell alongside the .aff and .dic files. I don't know how
>
On Fri, Oct 14 2022 at 12:54:53 PM +0200, Roland Rosenfeld
wrote:
Hi,
let me try to summarize where we stand and what options and open
questions we have.
I see the following options to package the bdic-Files (seems not all
of them were already mentioned before):
a) Bundle the bdic files
FYI:
Chromium includes an embedded copy of the hunspell library, which
they've forked to ignore dic/aff files and instead use bdic files. The
patch and google additions can be found here:
https://sources.debian.org/src/chromium/106.0.5249.119-1/third_party/hunspell/google.patch/
> It doesn’t directly address the topic of endianess, but it does say
> the following:
>
> "The .bdic files are always UTF-8 internally, and the convert_dict
> tool converts things appropriately when it runs.”
>
> I must admit that the topic of endianess goes a bit beyond my
> expertise, but my
This is Google’s page describing the .bdic format:
https://sites.google.com/a/chromium.org/dev/developers/how-tos/editing-the-spell-checking-dictionaries[1]
It doesn’t directly address the topic of endianess, but it does say the
following:
"The .bdic files are always UTF-8 internally, and the
On Friday, October 14, 2022 3:54:53 AM MST Roland Rosenfeld wrote:
> - Where should the bdic files be placed?
> 1) /usr/share/hunspell-bdic
I like this option because it would eliminate the need to wait to find out if
Chromium can use the files before deciding where to put them.
On a separate
Hi,
let me try to summarize where we stand and what options and open
questions we have.
I see the following options to package the bdic-Files (seems not all
of them were already mentioned before):
a) Bundle the bdic files in the existing hunspell- files.
- Pro: no new packages needed
-
I submitted three upstream bugs.
https://bugreports.qt.io/browse/QTBUG-107599[1]
https://bugreports.qt.io/browse/QTBUG-107600[2]
https://bugreports.qt.io/browse/QTBUG-107601[3]
--
Soren Stoutner
so...@stoutner.com
[1] https://bugreports.qt.io/browse/QTBUG-107599
[2]
On Wednesday, October 5, 2022 9:38:09 AM MST Soren Stoutner wrote:
> > ++ processing gl_ES.aff
> > gl_ES.dic_delta not found.
> > Reading gl_ES.aff
> > Reading gl_ES.dic
> > Serializing...
> > Verifying...
> > Word does not match!
> >
> > Index:2126
> > Expected: Abū po:antropónimo
> >
>
On Wednesday, October 5, 2022 5:07:50 AM MST Agustin Martin wrote:
> El jue, 22 sept 2022 a las 21:30, Soren Stoutner
> One noticeable thing is that bdic generation failed for some hunspell
> dicts I have installed
That’s concerning.
> ++ processing an_ES.aff
>
El jue, 22 sept 2022 a las 21:30, Soren Stoutner
() escribió:
>
> On Thursday, September 22, 2022 9:20:46 AM MST Agustin Martin wrote:
>
> > First of all, I am curious about the reasons behind this new format,
> > the problems it deals with and its advantages. I assume they are valid
> > enough,
On Tuesday, September 27, 2022 8:29:30 PM MST Andres Salomon wrote:
> The "team" would just be me (wanna join? :),
Currently my interests lie elsewhere, but I may reconsider that in the future.
> and I had to do some
> security uploads today and haven't had the chance to look further into
>
The "team" would just be me (wanna join? :), and I had to do some
security uploads today and haven't had the chance to look further into
this. Unfortunately, there's a few other high-priority things I need to
deal with before I can take a look.
On Tue, Sep 27, 2022 at 20:27, Soren Stoutner
Does anyone from the Chromium team have any insights
into the feasibility of Chromium using a system-wide
directory for .bdic files?
--
Soren Stoutner
so...@stoutner.com
signature.asc
Description: This is a digitally signed message part.
On Thursday, September 22, 2022 9:20:46 AM MST Agustin Martin wrote:
> First of all, I am curious about the reasons behind this new format,
> the problems it deals with and its advantages. I assume they are valid
> enough, but they imply yet another spellchecking engine/format. We
> currently have
El mar, 20 sept 2022 a las 22:33, Soren Stoutner
() escribió:
>
> Package: dictionaries-common
> Version: 1.28.18
> Severity: wishlist
> Tags: l10n
>
> Qt WebEngine has the ability to use Hunspell dictionaries for spell checking
> with the WebEngine, but for some reason they require that the
On Wed, Sep 21, 2022 at 06:39:16AM +0200, Rene Engelhard wrote:
> Am Tue, Sep 20, 2022 at 01:31:14PM -0700 schrieb Soren Stoutner:
> > Another option would be to create a separate binary package (for example,
> > qtwebengine-dict-en-us).
>
> Name makes sense to me, yes.
>
> > The argument for
Hi,
[ your HTML mails make quoting hard... ]
Thanks for filing the report.
Am Tue, Sep 20, 2022 at 01:31:14PM -0700 schrieb Soren Stoutner:
> Another option would be to create a separate binary package (for example,
> qtwebengine-dict-en-us).
Name makes sense to me, yes.
> The argument for
Package: dictionaries-common
Version: 1.28.18
Severity: wishlist
Tags: l10n
Qt WebEngine has the ability to use Hunspell dictionaries for spell checking
with the WebEngine, but for some reason they require that the dictionary files
be converted to a special binary format (.bdic). This
73 matches
Mail list logo
