Package: libqt6gui6
Version: 6.4.2+dfsg-18
Severity: important
Tags: patch
Dear Maintainer,
When running:
https://github.com/ankitects/anki/releases/download/2.1.66/anki-2.1.66-linux-qt6.tar.zst
I get the following error:
| anki-2.1.66-linux-qt6$ QT_DEBUG_PLUGINS=1 DISABLE_QT5_COMPAT=1 ./anki
Source: ktexteditor
Version: 5.70.1-1
Severity: important
Tags: upstream
Dear Maintainer,
libgit2 1.0 is now available in experimental. Please make sure your
package is ready for this version by the time we upload this package to
unstable in one to two weeks. The severity of this report will be
Lisandro Damián Nicanor Pérez Meyer:
> By the way: is there a macro or combination of macros which *default* value
> can be replaced in the use of __FILE__ without caussing regressions?
>
> Because if that's the case it's easier to convince upstream people that
> changing the usage goes in favor
Lisandro Damián Nicanor Pérez Meyer:
> [..]
>
> Yes, we do understand that your workaround solves the issue, but we do also
> understand that we should not be using this workaround in the first place.
>
> Guillem: the thread is long, but be sure that we Qt/KDE maintainers consider
> that this c
Lisandro Damián Nicanor Pérez Meyer:
> On miércoles, 15 de noviembre de 2017 20:35:00 -03 Ximin Luo wrote:
>> Lisandro Damián Nicanor Pérez Meyer:
>>> I was wanting to write this on a keyboard, but let me try on the phone and
>>> see if we can all agree in one
Lisandro Damián Nicanor Pérez Meyer:
> I was wanting to write this on a keyboard, but let me try on the phone and
> see if we can all agree in one point.
>
> There is one *excellent* method to settle this once and forever: submit the
> __FILE__ patch to GCC devs. If it gets accepted then Qt and wh
Pino Toscano:
> Loose meanings do not imply neither the other way around, that you are
> free to break because people cannot do anything with it. Also,
> considering the very same behaviour (short of the different wording in
> documentations) that is established for decades, this is a "de facto"
>
Pino Toscano:
> [..]
>
>> In summary: in no document or standard, does it guarantee or imply
>> that __FILE__ can be taken to represent a real filesystem path.
>> Applications relying on this behaviour are broken and should not be
>> upset when things don't work. As documented in multiple places,
Lisandro Damián Nicanor Pérez Meyer:
> [..]
>
> Xi: you also mentioned that having to file hundreds of patchs seems
> impossible. Well, it seems so, but it is actually not that necessary. Please
> allow me to explain the idea.
>
Thanks for being less inflammatory than Pino.
I agree that event
Pino Toscano:
> In data martedì 14 novembre 2017 11:14:00 CET, Ximin Luo ha scritto:
>> You're using __FILE__ inappropriately, none of the documentation
>> guarantees or implies that you can access __FILE__ as a real
>> filesystem path. "Surely for relative paths&quo
Lisandro Damián Nicanor Pérez Meyer:
> [..]
>
> Sorry, it is not realistic to force us to have a delta from upstream for no
> direct gain.
>
None of the solutions I suggested involve patching upstream, they would be done
in d/rules.
X
--
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5F
Pino Toscano:
> [..]
>
>> Well let's take a look at the standards:
>> [...]
>
> Even with different wordings, both describe basically the same
> behaviour. And yes, none of them says that __FILE__ is a full path,
> but surely for relative paths the combination of $srcdir + __FILE__
> will give m
Pino Toscano:
> [..]
>
> This is not an annoyance, it is the crux of the problem! __FILE__ is
> something standard, with a very well defined behaviour, upon which
> people rely on: you cannot trash it from one day to another like this,
> saying "too bad" to all its users, even those using it appr
Pino Toscano:
> [..]
>
> A better approach here is to work on removing the invalid & abusing
> usages of __FILE__ from packages, just like it was done for __DATE__.
>
We in fact did not do the latter because it was easier to implement
SOURCE_DATE_EPOCH to fix the expansion of __DATE__, rather t
Pino Toscano:
> [..]
>
> No, the solution is:
> a) *not* break what __FILE__ means
> b) remove the misuses of __FILE__ in packages (not the case of
>QFINDTESTDATA)
>
>> I am not "blaming the user", but pointing to the fact that __FILE__
>> is being used in a surprising way here, which is not
Ximin Luo:
> Ximin Luo:
>> [..]
>>
>> (maybe there are other options)
>>
>
> If all the test files reside underneath the same directory, like tests/, you
> could:
>
> 4. export BUILD_PATH_PREFIX_MAP="$BUILD_PATH_PREFIX_MAP=tests=$BASEDIR
Ximin Luo:
> [..]
>
> (maybe there are other options)
>
If all the test files reside underneath the same directory, like tests/, you
could:
4. export BUILD_PATH_PREFIX_MAP="$BUILD_PATH_PREFIX_MAP=tests=$BASEDIR/tests".
This should make the tests pass, whilst keeping
Adrian Bunk:
> Control: reassign -1 qtbase5-dev
> Control: reassign 876917 qtbase5-dev
> Control: reassign 876933 qtbase5-dev
> Control: forcemerge -1 876917 876933
> Control: retitle -1 QFINDTESTDATA uses __FILE__
> Control: severity -1 normal
> Control: affects -1 src:karchive src:ki18n src:kcode
Control: notfound -1 4:16.08.2-1
Control: close -1
Hi,
Actually the package does build fine, you just need to rebuild ktexteditor
against libgit2 0.26 first, then use this rebuilt version when building kate.
Sorry I missed this earlier, closing the bug now.
Ximin
On Mon, 21 Aug 2017 22:42:08
Ximin Luo:
> Ximin Luo:
>> Antonio Rojas:
>>> El lunes, 22 de mayo de 2017 23:59:00 (CEST) Ximin Luo escribió:
>>>
>>>> Thanks for the info. I had a play around, unfortunately --simple-prompt
>>>> won't be sufficient.
>>>>&g
Ximin Luo:
> Antonio Rojas:
>> El lunes, 22 de mayo de 2017 23:59:00 (CEST) Ximin Luo escribió:
>>
>>> Thanks for the info. I had a play around, unfortunately --simple-prompt
>>> won't be sufficient.
>>>>
>>> REPLs generally support m
Ximin Luo:
> Antonio Rojas:
>> El lunes, 22 de mayo de 2017 23:59:00 (CEST) Ximin Luo escribió:
>>
>>> Thanks for the info. I had a play around, unfortunately --simple-prompt
>>> won't be sufficient.
>>>>
>>> REPLs generally support m
Antonio Rojas:
> El lunes, 22 de mayo de 2017 23:59:00 (CEST) Ximin Luo escribió:
>
>> Thanks for the info. I had a play around, unfortunately --simple-prompt
>> won't be sufficient.
>>>
>> REPLs generally support multiline input (e.g. Python itself) so un
(+CC the debian bug)
Antonio Rojas:
> El lunes, 22 de mayo de 2017 18:56:00 (CEST) Ximin Luo escribió:
>> Has anyone had any success in making this work? In Debian we're suffering
>> from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852780 at the moment.
>>
>
Ximin Luo:
> Package: cantor-backend-sage
> Version: 4:16.08.3-1
> Severity: normal
>
> Dear Maintainer,
>
> SageMath has been in Debian for about a month now:
> https://packages.qa.debian.org/s/sagemath.html
>
> I just did a quick test and it seems not to wor
Package: cantor-backend-sage
Version: 4:16.08.3-1
Severity: normal
Dear Maintainer,
SageMath has been in Debian for about a month now:
https://packages.qa.debian.org/s/sagemath.html
I just did a quick test and it seems not to work however, it detects the Sage
version incorrectly and has troubl
Package: gtk3-engines-breeze
Version: 5.5.4-1
Severity: normal
Tags: upstream
Dear Maintainer,
GTK 3.20 has updated their themes as described in this blog post
https://blogs.gnome.org/mclasen/2015/11/20/a-gtk-update/
Unfortunately this breaks the themes contained in this package, and it should
Package: marble
Version: 4:15.12.1-1.1
Severity: wishlist
Tags: patch
Dear Maintainer,
As of a few months ago Marble contains experimental support for vector tiles.
This is functional but rudimentary, but I think to help the general FOSS effort
it would be good to deploy this to users already. It
Package: marble
Version: 4:15.08.1+dfsg-2
Severity: normal
Tags: upstream patch
Dear Maintainer,
The open file dialog (Ctrl-O) doesn't work; the following patch fixes this:
diff -Nru marble-15.08.1+dfsg/debian/patches/fix-openurl.patch
marble-15.08.1+dfsg0/debian/patches/fix-openurl.patch
--- m
Package: marble
Version: 4:15.08.1+dfsg-2
Severity: normal
Tags: patch
Dear Maintainer,
The current package doesn't detect quazip properly, even though it's listed in
Build-Depends; this breaks KMZ support.
The following patch fixes this:
diff -Nru marble-15.08.1+dfsg/debian/rules marble-15.08.
On 23/09/15 13:20, intrigeri wrote:
> intrigeri wrote (23 Sep 2015 11:08:16 GMT) :
>> maps/earth/{openstreetmap/openstreetmap,temp-july/temp-july}.dgml,
>
> I wonder if the license info in those map description files applies to
> the map data (that we don't ship in Debian anyway) and/or to the
> m
Package: marble
Version: 4:15.08.1+dfsg-2
Severity: normal
Dear Maintainer,
marble now seems to ignore ".config/kde.org/marble.conf" and instead
reads/writes
from ".config/Unknown Organisation/marble.conf"
"~/.config/marblerc" is unaffected, this is still used.
X
-- System Information:
Debian
Package: marble
Version: 4:15.08.0+dfsg-1
Severity: important
Dear Maintainer,
The normal OSM map seems to have disappeared. There is still the
- OpenCycleMap
- OpenSeaMap
- Public Transport
but not the old default OpenStreetMap.
We still have "MapQuest OSM" which uses the same data, but this
33 matches
Mail list logo
