Bug#1070274: bibledit: The current version currently has partially broken javascript
Source: bibledit Version: 5.1.002-1 Severity: grave Tags: upstream Justification: renders package unusable X-Debbugs-Cc: teusbensc...@debian.org Dear Maintainer, The version of upstream code, included in this package, has broken javascript. This cripples some parts of the program, in particular the verse editor. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.7.12-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1070273: bibledit-cloud: The current version currently has partially broken javascript
Source: bibledit-cloud Version: 5.1.005-1 Severity: grave Tags: upstream Justification: renders package unusable X-Debbugs-Cc: teusbensc...@debian.org Dear Maintainer, The uptream version, included in this package, has partially broken javascript. This cripples some parts of the Bible editors. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.7.12-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1052445: Uploaded to sid
Thank you, Sebastian, for the go-ahead. The upload to sid was done, and things build well there. Cheers, Teus Benschop
Bug#1052445: Request for permission to upload to sid
Hello Release Team, For clarity, this is a request for me to upload libpqxx to sid to start the transition there. A binNMU is enough for each reverse dependency. With thanks, Teus Benschop teusbensc...@debian.org
Bug#1052445: Support for this transition
Dear Release Team, Version 7.8 was uploaded to experimental and builds well there. Maarten has checked the reverse dependencies listed in this report. Both the reverse dependencies in https://release.debian.org/transitions/html/auto-libpqxx.html wered tested by him to build with version 7.8 of libpqxx, and both packages require no changes. It's sufficient to do a binNMU for both packages. I am supporting Maarten in his contributions to Debian and am mentoring him. Teus Benschop teusbensc...@debian.org
Bug#1003724: Minor repo cleanup ready to push
Hello Marcin, There were nice updates ready in the repository at https://salsa.debian.org/debian/libpqxx, all created by you, and thank you for that. The changes were, among other things, related to an update to libpqxx version, upstream, 7.2.1. When I tried to build the package, it appeared that the branch "pristine-tar" did not have the tag related to that new upstream version. In an attempt to help a bit, I updated the branch "pristine-tar" in a local clone of this repository. So I am willing and ready to push this commit to the public repository at Salsa. Please let me know what you think, whether this is acceptable to you. I think I'll wait a while on any comments from you and other developers, and in case no objection is there, I would then feel free to push this. Guys, have a good Sunday! Teus Benschop, DD
Bug#1003724: Support for proposal
Hello fellow-developers, I would like to voice my support for the proposal from Stephan Lachnit, and also for the proposal from Maarten van Geijn. In Salsa, at https://salsa.debian.org/debian/libpqxx, I can see that Marcin has made lots of updates, improving the package greatly, and is ready for uploading to the Debian archives, so that helps a great lot. The last upload was made in 2019 according to https://tracker.debian.org/pkg/libpqxx. I just wonder if there's a problem in maintaining this package, or that perhaps I can help reviewing packaging and uploading to the Debian archives if need be? I'd gladly help with this, please let me know. With kind regards, Teus Benschop https://freesoftwareconsultants.nl https://bibledit.org
Bug#1037591: Why was the severity of this bug increased?
Hello, On 5 July the severity of this bug was changed from 'normal' to 'important'. Yet this bug is already fixed. It was marked as: Fixed in version bibledit-cloud/5.1.002-1 This version, bibledit-cloud/5.1.002-1, is already available in the testing and unstable archives. Question: Why was the severity of this bug raised? Note that although the bug was fixed, it was left open as per request in the bug report. Met vriendelijke groeten, With kind regards, Teus Benschop https://freesoftwareconsultants.nl https://bibledit.org
Bug#1037589: Why was the severity of this bug increased?
Hello, On 5 July the severity of this bug was changed from 'normal' to 'important'. Yet this bug is already fixed. It was marked as: Fixed in version bibledit/5.1.002-1 This version, bibledit/5.1.002-1, is already available in the testing and unstable archives. Question: Why was the severity of this bug raised? Note that although the bug was fixed, it was left open as per request in the bug report. Met vriendelijke groeten, With kind regards, Teus Benschop https://freesoftwareconsultants.nl https://bibledit.org
Bug#975407: Moved
Hi Bastian, The repository how now been moved to the new location. An upload was done that, hopefully, closes this bug. If you feel there’s still something to be done on this bug, please feel free to re-open it.
Bug#1023373: [pkg-crosswire-devel] Bug#1023373: Further bug discussion
[…] > Then it is not only a non-source file but a non-source file that does not > have a public source. Right, since this file does not have a public source, this is a valid reason to remove it. So here’s the proof how useful the discussion was we’ve just had on this topic. The usefulness is visible in that now there’s a valid reason to delete this file. I’ve just prepared a new Debian tarball for Bibledit Cloud and uploaded the new build to the Debian archives. It also includes also your recent fixes in Salsa - thank you for that contribution. Then the upload to Bibledit (non-Cloud) should finally fix this bug - coming soon.
Bug#1023373: Further bug discussion
Initially I thought that the file analytics.html is a non-source file.
Then I went to search the Quill source code at GitHub.
https://github.com/quilljs/quill
I expected to find some Typescript or other source that would generate the
supposedly non-source file “analytics.html”.
Here is search one:
% grep -R GoogleAnalyticsObject *
source/docs/_includes/analytics.html:
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
And here is search two:
% grep -R analytics.html *
source/docs/_layouts/v0.20.html: {% include analytics.html %}
source/docs/_layouts/default.html:{% include analytics.html %}
So from the results of the $ grep, it appears that there is not any source file
in the GitHub repository that has a more preferred form of modification than
analytics.html currently has.
So it seems like the Quill upstream developers use analytics.html as their
source file, even if it contains minified Javascript.
Therefore although I initially thought that analytics.html is a non-source file,
I now think that there is not better source file than that available.
It could have been that the upstream developers of Quill have grabbed some
minified Javascript code, and put that in analytics.html, and are now treating
that file as their source.
Any thoughts?
Bug#1023373: Further bug discussion
Hi Bastian,
Thank you for the extra clarification about what this bug is about, and for the
extra details.
> We can play a word game but "missing sources" is exactly about
> "non-source files". If a file is contained in a package that is not a
> source file then its sources are missing.
Okay, the clarification is clear, and rest assured I was not playing a game on
words.
[…]
> Please take a look at analytics.html and think about the question: "Is
> this a source file or not?”
Here is the file analytics.html:
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-19077541-2', 'auto');
ga('send', 'pageview');
window.heap=window.heap||[],heap.load=function(e,t){window.heap.appid=e,window.heap.config=t=t||{};var
r=t.forceSSL||"https:"===document.location.protocol,a=document.createElement("script");a.type="text/javascript",a.async=!0,a.src=(r?"https:":"http:")+"//cdn.heapanalytics.com/js/heap-"+e+".js";var
n=document.getElementsByTagName("script")[0];n.parentNode.insertBefore(a,n);for(var
o=function(e){return
function(){heap.push([e].concat(Array.prototype.slice.call(arguments,0)))}},p=["addEventProperties","addUserProperties","clearEventProperties","identify","removeEventProperty","setEventProperties","track","unsetEventProperty"],c=0;c I know about that bug report (I have already referenced it here). It was
> closed without actually fixing it. The quill files are still non-source
> files because they are not in their preferred form of modification.
Ah, okay, thanks for that clarification too.
When this bug report [1] titled "Some sources are not included in your
package” was closed by me,
I genuinely believed that the fix made was fixing the issue the bug was about.
But if you believe that the bug was not fixed, then feel free to re-open it.
We can then continue the discussion there.
I believe that this course of action is clearer since then the topic can be
discussed in the context of the bug.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017083
> So this bug is primarily about the missing source (Policy violation).
> When you have addressed that you can downgrade the severity to important
> to address the secondary issue of supposed privacy violations.
That is okay.
So what I suggest is to move the issue of the missing source back to that bug
where it belongs, to bug #1017083.
That now having been moved there, the current bug, titled "non-source Google
Analytics file” can then have its severity change to important.
I intend to change that severity soon after.
We may then continue the discussion on that google analytics file here at this
bug.
As is clear from all of this, my current main concern is that there’s a release
critical bug against bibledit, but yet it is not very clear why this bug is so
critical. So changing that severity address this concern.
Being free of that concern now, it’s possible to move on about the content of
the bug report.
Although I intend to change the severity of the bug titled non-source Google
Analytics file”
I am not intending to reopen bug #1017083 because currently I believe it is
fixed.
Please reopen this bug if you believe it’s not fixed yet.
Thanks for all the input on making the package better and better.
Teus.
Bug#1023373: Further bug discussion
Hi Bastian, Thank you for the further clarification. You wrote: > 1) For dealing with non-source files see §4.16. Paragraph 4.16 of the DPM [1] does not mention “non-source files”. It is about “missing sources”. There was a bug report on this issue [2]. The file "quill/source/docs/_includes/analytics.html” landed in the Bibledit source to fix that bug. [1] https://www.debian.org/doc/debian-policy/ch-source.html#missing-sources-debian-missing-sources [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017083 You wrote: > 2) The script calls https://www.google-analytics.com/analytics.js which is a > privacy breach. > I do not know the Policy section which applies to this but it is > certainly a violation of the social contract, > which says: "Our priorities are our users and free software”. You are correct that the file "quill/source/docs/_includes/analytics.html” makes a call to Google Analytics. But I also see that this call is never executed by Bibledit. The call to Google Analytics can even never be made by Bibledit, because this call is not found in the file “quill.min.js|. This is the final minified version from Quill that Bibledit uses. Therefore when referring to the social contract, where it says “Our priorities are our users and free software”, Bibledit does prioritise the users and free software in this context. Because Bibledit never calls Google Analytics. After thinking over all these things, it now becomes even more unclear to me what the exact bug is that this report is about. My questions are: 1. Since there’s no policy violation, and no violation of the social contract, and no functional error, what exactly is the bug? 2. Since there’s no violation of policy or social contract, and the package is not unfit for release, why has this bug been tagged release critical? A few suggestion are these: 1. To no longer make this bug release critical. 2. Perhaps make this bug a wishlist item instead. 3. Perhaps close this bug since there’s no bug found yet. You wrote: > You should really have a look at the lintian output. > There are more privacy-breach-generic tagged errors in the quill files. > Those should be addressed as well. I agree with you, and have had a look a couple of times, now and in the past. I agree that these should be addressed too. Anyway, these are a few of my thoughts about this bug, and thank you for your eagerness to make Bibledit a perfect Debian package. Teus.
Bug#1023373: Policy references
Hi Bastian, You wrote: > […], > quill/source/docs/_includes/analytics.html is clearly a non-source > file that applies Google Analytics, which is not acceptable. Could you please explain the reasons why the contents of analytics.html is not acceptable? I am specifically asking for references to the Debian Policy. https://www.debian.org/doc/debian-policy/ That way it may be clearer how exactly analytics.html violates the Debian Policy. It may also then be clearer how best to fix this bug.
Bug#1023373: Some findings
Hi,
The file “analytics.html” is used in other parts of the Quill source code tree.
% grep -R "analytics.html" *
docs/_layouts/v0.20.html: {% include analytics.html %}
docs/_layouts/default.html:{% include analytics.html %}
If this file were just deleted, then it could happen that this would affect
building this source tree.
A possible solution to this is not to entirely delete the “analytics.html”, but
rather to delete the contents of that file within the … tags.
Bug#1023373: ACK
Ah, okay, thank you for spotting this analytics.html. It had escaped me. I’ll create a new Debian source tarball without this file.
Bug#1010925: New upload Bibledit client
Here is some extra information I found related to removing the font file and the license files: The Debian tarball removes extra license files as a fix for the lintian warnings "extra-license-file". It removes the extra font files as a fix for the lintian warning "duplicate-font-file".
Bug#1010925: New upload Bibledit client
Hi Bastian, A new upload was done to Debian. It aims to address all of the issues you have raised in the bug report. Here's a couple of comments related to that. > In git, I have fixed the suspected source URL that is now available in the right version. Thank you for fixing the source URL, everything looks right with the updated URL. > The mbedtls repack can now be done automatically on importing the source. Yes, it did that well. Unfortunately upstream had provided an incorrect tarball at https://github.com/bibledit/debian/releases/ This has now been fixed, the correct tarball is now on the above URL. This correct tarball is intended to be a tarball that satisfies the Debian policy. The updated tarball no longer needs to be repacked. It's intended to be correct already as it is. So I updated the d/copyright file to reflect this. > There are some files that are deleted unnecessarily: > stamp-h1, fonts/SILEOTF.ttf, and several COPYING and LICENSE files. > They can be excluded from installation but shoud still be kept in the source imho. The upstream tarball does not have this font because it's already in the package fonts-sil-ezra. https://packages.debian.org/source/bullseye/fonts/fonts-sil-ezra If I remember well the upstream tarball removed the copying and license files because there were warnings about this from lintian. But it's long back that these were removed and I cannot remember full details now. If it's interesting one may try adding those back and see what lintian says about it. If there's still something to be included in the upstream tarball, please opan an issue upstream at https://github.com/bibledit/cloud/issues. This issue would contain the details about what to add and why. > Also, there are differences in pkgdata/files.txt, the Makefiles, and configure scripts > that are not documented in debian/README.source. > Please add documentation on how to reproduce these changes. > Preferably as patches or a script that can be run on importing the source. I agree such differences should not be there. The new upstream tarball is intended to fix all of this, so there's no differences left anymore. So thanks for the hints and improvements. Teus Benschop
Bug#1017083: [pkg-crosswire-devel] Bug#1017083: Path forward
On Sat, 27 Aug 2022 at 20:55, Roberto C. Sánchez wrote: > I agree with your approach. Including the source now to address the bug > and ensure that package is not removed is something that should be done > soon. The introduction of the new package could also be pursued in > parallel and once it is accepted into the archive, then bibledit could > be updated to depend on the package and remove the duplicate components. > > Thank you for the support for this approach Roberto. Upstream now has created a new tarball that includes the missing source code. This addresses the bug. It took quite a while to be able to get things work out well, upstream, but anyway, it's done now. That tarball was used to create a new package for Debian. Then the upload was done. Likely things will be moving fast now, and hopefully this fixes the issue completely. Teus.
Bug#1017083: Path forward
The bug report states this: > In order to solve this problem, you could: > 1. add the source files to "debian/missing-sources" directory. > 2. repack the origin tarball and add the missing source files to it. The intention just now is to go for something similar to the proposed solution number 2. That means in this case that upstream will provide a new tarball that includes the missing source files. Then once this is done, a new Bibledit package can be created based on this tarball. The intention is to do the above before the package will be automatically removed from the testing distro, and then let the new changelog close this bug in time. Thanks for all the input on this matter.
Bug#1017083: Path forward
If a package like libjs-quill was created, this package would have to go through the NEW queue before it would be accepted in the Debian archives. Earlier packages in this queue always took considerable time before they were reviewed and accepted. Based on earlier experience with new packages in Debian, I would expect that this Bibledit package will long have been removed automatically from testing. So although creating libjs-quill would be the right thing to do, I am inclined to take the quicker route this time around, and just satisfy the bug report, and that's it. Satisfying the bug report is, as the bug states, to include the source code that leads to the minified Javascript. That looks a reasonable approach just now, and something that can be done in time before Bibledit is removed from the testing distribution. At the same time it looks wise to me if someone files a bug that libjs-quill would need to be packaged. Then if libjs-quill is available, Bibledit could eventually switch to using this new package. But this is something for the longer term. It's not a short-term solution to this bug report.
Bug#1017083: [pkg-crosswire-devel] Bug#1017083: All sources are included, the bug report is invalid
On Fri, 26 Aug 2022 at 14:40, Bastian Germann wrote:
> Control: severity -1 serious
>
> Am 26.08.22 um 14:15 schrieb Teus Benschop:
> > Additionally the quill code was downloaded from the official quill
> releases in whatever form their official releases are.
> > "Webpack" does not come in here.
>
> The point is that the quill releases do not fit Debian's definition of
> source, so the bug IS valid at least for quill.
> Bastien pointed to the non-minifies quill files because they are readable
> ("full") source but not source that is defined
> by preferred form for modification.
>
> The right thing would be to create a libjs-quill package that builds the
> module from the source available at:
> https://github.com/quilljs/quill. Then depend on that package.
>
> Actually, this is a serious bug as filed by Bastien. If we as a team
> cannot afford the time to make this package abide
> by the DFSG, then it is justified that the autoremove automation kicks in.
>
Okay, the explanation you have given is clear, thanks for that.
We'll see what the team is able to do before the package is automatically
removed from the testing distribution.
It could happen that upstream generates the Quill source in Javascript
from, and includes that in the Bibledit upstream source. That's a possible
solution too.
Teus.
Bug#1017083: [pkg-crosswire-devel] Bug#1017083: All sources are included, the bug report is invalid
On Fri, 26 Aug 2022 at 13:12, Bastian Germann wrote: > At least the quill sources are not in the preferrable form for > modification but are in a "webpack" format. > > > The bug is about the minified versions that did not have their full forms included as well. The quill code included is both minified and full. That's why I thought that the bug report is invalid. Additionally the quill code was downloaded from the official quill releases in whatever form their official releases are. "Webpack" does not come in here.
Bug#1010925: [pkg-crosswire-devel] Bug#1010925: bibledit: d/copyright's Source is invalid
On Fri, 26 Aug 2022 at 13:12, Bastian Germann wrote: > On Thu, 18 Aug 2022 15:59:44 +0200 Bastian Germann > wrote: > > Teus, please make sure that you create the Debian package from a > publicly accessible file. > > Again, the upstream source is not available for 5.0.985. > > > Hi Bastian, Thank you for the update. Yes, the issue you mentioned is still there. The bug that will address this issue is still open upstream. Here is the link to the issue: https://github.com/bibledit/cloud/issues/822 In the meantime the tarball used to create the newest Bibledit for Debian was released here publicly: https://github.com/bibledit/debian/releases/ The bug on Debian about the packaging is not critical. The severity of this bug is set to "normal". There's a good number of outstanding issues on the Bibledit source that also have a normal severity. So the Debian bug just will have to wait till upstream has the time to attend to it. There's no need to put the Debian bug at the front of the queue. Addressing this Debian bug runs via the Bibledit issues list on GitHub. https://github.com/bibledit/cloud/issues Many issues were created before the Debian bug was opened. These will be resolved by upstream first, following the waiting queue. Anyway thanks for the heads up, and all your work on Debian. Teus
Bug#1017083: All sources are included, the bug report is invalid
Hello, Thank you for looking into and reporting this issue. The bug lists a couple of minified Javascript code that is included in the package, and the bug report asserts that the original source, the non-minified source, is not included in the source package. I have checked all of the reported minified sources to find out whether the source is reported correctly in the bug report, or whether the original source is already included in the source code of the package. Here is a list of all the reported files in the bug report, together with my remarks on them. [jquery/jquery-3.5.1.min.js] The source is already included in this file: jquery/jquery-3.5.1.js [jquery/jquery.touchSwipe.min.js] The source is already included in this file: jquery/jquery.touchSwipe.js [nicedit/nicedit.min.js] The source is already included in this file: nicedit/nicedit.js [notifit/notifit.min.js] The source is already included in this file: notifit/notifit.js [quill/1.1.5/quill.core.js] The above is full source, not minified. [quill/1.1.5/quill.js] The above is full source, not minified. [quill/1.1.5/quill.min.js] The source is already included in this file: quill/1.1.5/quill.js [quill/1.3.6/quill.core.js] The above is full source, not minified. [quill/1.3.6/quill.js] The above is full source, not minified. [quill/1.3.6/quill.min.js] The source is already included in this file: quill/1.3.6/quill.js [quill/quill.core.js] The above is full source, not minified. [quill/quill.js] The above is full source, not minified. [quill/quill.min.js] The source is already included in this file: quill/quill.js [rangy13/rangy-classapplier.min.js] The source is already included in this file: rangy13/rangy-classapplier.js [rangy13/rangy-core.min.js] The source is already included in this file: rangy13/rangy-core.js [rangy13/rangy-highlighter.min.js] The source is already included in this file: rangy13/rangy-highlighter.js [rangy13/rangy-selectionsaverestore.min.js] The source is already included in this file: rangy13/rangy-selectionsaverestore.js [rangy13/rangy-serializer.min.js] The source is already included in this file: rangy13/rangy-serializer.js [rangy13/rangy-textrange.min.js] The source is already included in this file: rangy13/rangy-textrange.js Therefore my current impression is that all the items reported in this bug were reported in error, and that the bug report seems to be invalid. Please correct me if I'm wrong. If the bug report is invalid, could it be closed? The bug report, if it remains open, will cause the package to be removed from the testing distribution. Something I'd like not to happen, in particular as there seems to be no reason for that. Met vriendelijke groeten, With kind regards, Teus Benschop https://freesoftwareconsultants.nl https://bibledit.org
Bug#1017616: Unicode
I would agree that this is a package bug. But I think that this is not related to "packaging" only. Upstream too would like to fix the licensing issue in a proper way. Feel free to remove the upstream reference though.
Bug#1017083: Forwarded upstream to https://github.com/bibledit/cloud/issues/820
forwarded 1017083 https://github.com/bibledit/cloud/issues/820 thanks
Bug#985477: [pkg-crosswire-devel] Bug#985477: Bug#985477: diatheke: Sticky titles
Hi Lasse, The bug tracker for upstream is at https://tracker.crosswire.org/secure/Dashboard.jspa. To discuss with the developers, their forum is at SWORD Developers' Collaboration Forum sword-de...@crosswire.org Met vriendelijke groeten, With kind regards, Teus Benschop https://freesoftwareconsultants.nl https://bibledit.org
Bug#984526: sword-text-kjv: Package is non-free
On Thu, 4 Mar 2021 at 20:56, Bastian Germann wrote: > This was discussed in #338077 and found to be okay (because it is a > Commonwealth problem only). This is not the problem here. It is the > editions by CrossWire that are non-free. > > > If an earlier version was okayed by Crosswire to be put in the public domain, and to be distributed in Debian, even if later on Crosswire removed that earlier version from their repository, it looks to me that Debian can continue to distribute that earlier version.
Bug#984526: [pkg-crosswire-devel] Bug#984526: sword-text-kjv: Package is non-free
Here is an article on the copyright issues with regard to the KJV. https://en.wikipedia.org/wiki/King_James_Version#Copyright_status It says, among many other things that "The Authorized Version is in the public domain in most of the world. However, in the United Kingdom, the right to print, publish and distribute it is a royal prerogative..." It's a bit messy, it looks. Reading over it, I am not sure that the KJV is free to be distributed in Debian. Earlier faults in history are continuing to harass us and limit the word of God somehow. Met vriendelijke groeten, With kind regards, Teus Benschop https://freesoftwareconsultants.nl https://bibledit.org On Thu, 4 Mar 2021 at 20:12, Roberto C. Sánchez wrote: > On Thu, Mar 04, 2021 at 06:04:13PM +0100, Bastian Germann wrote: > > Source: sword-text-kjv > > Severity: serious > > Version: 2.10-1 > > > > sword-text-kjv is non-free in all of its versions. The details are in > > https://gitlab.com/crosswire-bible-society/kjv/-/commit/0203c85010a9a > > > I read the thread (and looked at your changes). This seems to a bit of > a tangled mess. It will be a few days before I can take a closer look > and provide my thoughts. > > Regards, > > -Roberto > > -- > Roberto C. Sánchez > > ___ > pkg-crosswire-devel mailing list > pkg-crosswire-de...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-crosswire-devel >
Bug#976561: uploaded
Thanks for the fix. That is great. The package was built, reviewed and uploaded.
Bug#975982: Swift work
That was a swift transition, thank you for tracking it Sebastian. Met vriendelijke groeten, With kind regards, Teus Benschop https://freesoftwareconsultants.nl https://bibledit.org
Bug#975982: Will do
Thank you, Sebastian, for the go-ahead. We will do so soon. That helps a lot. Met vriendelijke groeten, With kind regards, Teus Benschop https://freesoftwareconsultants.nl https://bibledit.org
Bug#975982: transition: sword
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: teusbensc...@debian.org Upstream has released a new API version. That is the reason for this sword transiton. The affected packages are bibletime and xiphos. Someone from the packaging team will do a new upload of the affected packages, once the new sword packages is in unstable. Ben file: title = "sword"; is_affected = .depends ~ "libsword-1.8.1" | .depends ~ "libsword1.9.0"; is_good = .depends ~ "libsword1.9.0"; is_bad = .depends ~ "libsword-1.8.1"; -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.8.0-1-amd64 (SMP w/2 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#970471: Possible ways to resolve
The error message in this bug report is an unusual one. I managed to find one other similar report on Google, which was in Chinese. Possible solutions I could think of are these two. 1. If the error is temporary, to upload a new package that would trigger a rebuild. 2. To ask the FTP Masters to remove the previously build for this architecture, so the remaining architectures can move to testing. Perhaps there are more possible solutions others may think of? Met vriendelijke groeten, With kind regards, Teus Benschop https://freesoftwareconsultants.nl https://bibledit.org
Bug#955971: forwarded
forwarded 955971 https://github.com/crosswire/xiphos/issues/1049 thanks Met vriendelijke groeten, With kind regards, Teus Benschop
Bug#955971: [pkg-crosswire-devel] Processed: reopen
On Sun, 5 Jul 2020 at 08:57, Geert Stappers wrote: > On Sun, Jul 05, 2020 at 08:17:23AM +0200, Teus Benschop wrote: > > > Question to the Debian developers: > > Should we just disable the dbus functionality in Xiphos? > > > What Debian Developers do: > * Find a way to enable full functionality > * Avoid yes-no-questions > * Make the world a better place > > > Yes, you are correct mentioning these three things that DD's do. The question I have has to do with bug number https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955971 Xiphos depends on deprecated dbus-glib. And there's lots of other packages also depending on this deprecated library. My question is then, what are the options to handle this bug number 955971. We could be doing nothing just now and leave the bug number as it is. We also could, say, write patches, that either disable the dependency on dbus-glib. Or perhaps there's other ways to deal with it. What do you think?
Bug#955971: [pkg-crosswire-devel] Processed: reopen
It was closed because the changelog of the new upload had this bug number, whereas it should have been another bug number to close. So yes, it's correct to reopen this bug again. It was forwarded upstream. Question to the Debian developers: Should we just disable the dbus functionality in Xiphos?
Bug#913128: uncompress
This how2do it. If it's in debhelper, it must be the following override: dh_compress --exclude=.ogg https://manpages.debian.org/jessie/debhelper/dh_compress.1.en.html
Bug#964098: [pkg-crosswire-devel] Bug#964098: Bug#964098: xiphos: package new upstream release: 4.2.1
On Sat, 4 Jul 2020 at 15:09, Roberto C. Sánchez wrote: > >If only the upstream maintainers would complete their WebKit2 editor, > that > >would be so good :) > >It is WebKit (version 1) now. So Bastian had reworked on the patch to > work > >around it. Because WebKit (version 1) is not included in Debian > unstable. > > I am guessing that means that the package in Debian will be missing some > functionality, rather than this preventing it from being in Debian > entirely. > > > Yes, you are correct, that is what it means. And if bugs are going to be opened because of any missing functionality, we can always forward the bugs upstream :)
Bug#964098: [pkg-crosswire-devel] Bug#964098: Bug#964098: xiphos: package new upstream release: 4.2.1
On Wed, 1 Jul 2020 at 20:51, Teus Benschop wrote: > On Wed, 1 Jul 2020 at 20:39, Roberto C. Sánchez > wrote: > > > On Wed, Jul 01, 2020 at 08:34:39PM +0200, Teus Benschop wrote: > > >Yes, that would be good. > > >There's some patches and bugs too. > > >It would be good if the new release would fix those issues. > > >I was thinking of working on this after a week or so time > permitting. > > > > That would be excellent. Do you intend to start by reviewing Bastian's > > MR in Salsa? If you can't get to it by the end of next week, please let > > me know and I will take care of it. > > > > > > I wasn't sure yet where to start, but certainly Bastian's merge requests > are welcome and would be considered. > I can't tell for sure when I will get to working on those, also because > there's lots of work to do for me on a youtube channel for teens. > Please feel free to merge them if and when you like to do so. > Hi Roberto, The merge request of Bastian was now merged into the master branch. Thank you @Bastian, for contributing to Debian. I am now working on importing the newest upstream, and building the package, then to test the package. Everything is going well, so I am happy. If only the upstream maintainers would complete their WebKit2 editor, that would be so good :) It is WebKit (version 1) now. So Bastian had reworked on the patch to work around it. Because WebKit (version 1) is not included in Debian unstable. Teus.
Bug#964098: [pkg-crosswire-devel] Bug#964098: xiphos: package new upstream release: 4.2.1
On Wed, 1 Jul 2020 at 20:39, Roberto C. Sánchez wrote: > On Wed, Jul 01, 2020 at 08:34:39PM +0200, Teus Benschop wrote: > >Yes, that would be good. > >There's some patches and bugs too. > >It would be good if the new release would fix those issues. > >I was thinking of working on this after a week or so time permitting. > > That would be excellent. Do you intend to start by reviewing Bastian's > MR in Salsa? If you can't get to it by the end of next week, please let > me know and I will take care of it. > > > I wasn't sure yet where to start, but certainly Bastian's merge requests are welcome and would be considered. I can't tell for sure when I will get to working on those, also because there's lots of work to do for me on a youtube channel for teens. Please feel free to merge them if and when you like to do so.
Bug#964098: [pkg-crosswire-devel] Bug#964098: xiphos: package new upstream release: 4.2.1
Yes, that would be good. There's some patches and bugs too. It would be good if the new release would fix those issues. I was thinking of working on this after a week or so time permitting. Met vriendelijke groeten, With kind regards, Teus Benschop On Wed, 1 Jul 2020 at 20:15, Roberto C. Sanchez wrote: > Package: xiphos > Version: 4.1.0.1+dfsg1-1 > Severity: wishlist > > It would be good if we could package the new upstream release 4.2.1 > fairly soon. > > Regards, > > -Roberto > > ___ > pkg-crosswire-devel mailing list > pkg-crosswire-de...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-crosswire-devel >
Bug#961535: Getting the source files copyright notices right
The copyright notices in the Bibledit-Desktop source packages are not yet compatible with Debian. So some work remains to be done in the source package. Here's some more information about the copyright notices. https://github.com/postiffm/bibledit-desktop/issues/37 It also tracks progress upstream makes on this. Met vriendelijke groeten, With kind regards, Teus Benschop
Bug#961535: Repository
The repository for the current Debian packaging, not yet released, is on Salsa. https://salsa.debian.org/debian/bibledit-desktop Met vriendelijke groeten, With kind regards, Teus Benschop
Bug#961535: ITP: bibledit-desktop -- Bible editor
Package: wnpp Severity: wishlist Owner: Teus Benschop * Package name: bibledit-desktop Version : 4.17 Upstream Author : Matthew A. Postiff * URL : https://github.com/postiffm/bibledit-desktop/wiki * License : GPL Programming Lang: C++ Description : Bible editor Bibledit-Desktop (formerly bibledit-gtk) is a program that aims to help Bible translation be faster and more accurate. It is a full-featured application for doing Bible translation on the desktop (or laptop). It does not require a constant Internet connection to run properly.
Bug#950592: debhelper 10
Hi, The alternative option to fix this, setting the debhelper compat to 10 or more, I like this option because not only enables it parallel builds but it also updates the debhelper compatibility, giving the package bibledit-cloud all goodies that come with this update. Package is now being checked and updated. I am preparing a new package upload with this fix. Met vriendelijke groeten, With kind regards, Teus Benschop
Bug#950592: Will do
Thank you for noticing the issue of parallel builds. I will implement this soon and upload a new package. Currently I am waiting for the package to move into testing for the first time. Once the package is in testing, I can then proceed with this. Thank you for your contribution towards improving the package. Met vriendelijke groeten, With kind regards, Teus Benschop
Bug#863408: Progress
The package has been created and uploaded to the "new" queue. See also this bug report on GitHub: https://github.com/bibledit/cloud/issues/328
Bug#863408: ITP: bibledit-cloud -- Bible editor server
Package: wnpp Followup-For: Bug #863408 Owner: Teus Benschop I am intending to package the existing upstream tarball and create a proper Debian package from it. It already exists in Ubuntu and works well there. The plan is to base the Debian packaging on the existing Ubuntu packaging. This is expected to speed all up.
Bug#921869: libwebkit2gtk-4.0-37: Renders some Hebrew characters as square boxes
Awesome, thanks! On Tue, Feb 12, 2019, 4:41 PM Alberto Garcia Control: tags -1 patch > > On Sun, Feb 10, 2019 at 01:11:58PM +0100, Teus Benschop wrote: > > > Of course, the WebKit engine should display Hebrew in decomposed > > format, as well as in composed format. > > I have good news, there's now a patch available fixing this problem. > > I tested it and it does show all characters correctly, so I requested > it to be included in the next stable release. > > Regards, > > Berto >
Bug#921869: libwebkit2gtk-4.0-37: Renders some Hebrew characters as square boxes
Thank you for doing more tests on this issue, and for confirming the bug, and for going to discuss it with the webkit developers. I found that if those Hebrew characters are converted to the NFC format, that is, to the composed format, then they display well in the current WebKit. There won't be any square boxes with the characters in the composed format. Of course, the WebKit engine should display Hebrew in decomposed format, as well as in composed format. -- Teus Benschop teusjanne...@gmail.com 0318 712046
Bug#921869: original bug report
The original bug report is here: https://github.com/bibledit/cloud/issues/252 This bug report provides some additional context. -- Teus Benschop teusjanne...@gmail.com 0318 712046
Bug#921869: libwebkit2gtk-4.0-37: Renders some Hebrew characters as square boxes
Package: libwebkit2gtk-4.0-37 Version: 2.22.5-1 Severity: normal Dear Maintainer, The webkit engine renders some Hebrew characters as square boxes. I have created a minimal example that shows the problem. The link to the minimal example is here: http://bibleconsultants.nl/downloads/webkit2gtk/ Here are the steps to take for the problem to show up. * Download the files "run" and "main.c" to a local directory. * Install the dependencies as listed in file "run". * Compile and run the example: $ ./run The result of these steps is that certain Hebrew characters get rendered as in file "wrong-rendering.png" at the link above. The expected result would be that these Hebrew characters get rendered correctly as in file "right-rendering.png" at the link above. The correct rendering can also be seen by opening the link http://bibleconsultants.nl/downloads/webkit2gtk/resources.html in a browser. Running the link http://bibleconsultants.nl/downloads/webkit2gtk/resources.html through the validator at https://validator.w3.org shows warnings like "Text run is not in Unicode Normalization Form C." But it is not a requirement in html 5 that "form C" be used for Unicode characters. The webkit rendering engine should also render decomposed Unicode characters. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-3-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_CRAP Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libwebkit2gtk-4.0-37 depends on: ii libatk1.0-0 2.30.0-2 ii libc6 2.28-6 ii libcairo2 1.16.0-2 ii libegl1 1.1.0-1 ii libenchant1c2a 1.6.0-11.1+b1 ii libfontconfig1 2.13.1-2 ii libfreetype62.9.1-3 ii libgcc1 1:8.2.0-19 ii libgcrypt20 1.8.4-5 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-7 ii libgl1 1.1.0-1 ii libglib2.0-02.58.3-1 ii libgstreamer-gl1.0-01.14.4-1 ii libgstreamer-plugins-base1.0-0 1.14.4-1 ii libgstreamer1.0-0 1.14.4-1 ii libgtk-3-0 3.24.5-1 ii libharfbuzz-icu02.3.1-1 ii libharfbuzz0b 2.3.1-1 ii libhyphen0 2.8.8-7 ii libicu6363.1-6 ii libjavascriptcoregtk-4.0-18 2.22.5-1 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libnotify4 0.7.7-4 ii libpango-1.0-0 1.42.4-6 ii libpng16-16 1.6.36-5 ii libsecret-1-0 0.18.7-1 ii libsoup2.4-12.64.2-2 ii libsqlite3-03.26.0+fossilbc891ac6b-2 ii libstdc++6 8.2.0-19 ii libtasn1-6 4.13-3 ii libwayland-client0 1.16.0-1 ii libwayland-egl1 1.16.0-1 ii libwayland-server0 1.16.0-1 ii libwebp60.6.1-2 ii libwebpdemux2 0.6.1-2 ii libwoff11.0.2-1 ii libx11-62:1.6.7-1 ii libxcomposite1 1:0.4.4-2 ii libxdamage1 1:1.1.4-3 ii libxml2 2.9.4+dfsg1-7+b3 ii libxslt1.1 1.1.32-2 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages libwebkit2gtk-4.0-37 recommends: ii gstreamer1.0-gl1.14.4-1 ii gstreamer1.0-plugins-good 1.14.4-1 ii gstreamer1.0-pulseaudio1.14.4-1 ii libgl1-mesa-dri18.3.3-1 Versions of packages libwebkit2gtk-4.0-37 suggests: pn libwebkit2gtk-4.0-37-gtk2 -- no debconf information
Bug#913640: sword: apply upstream ICU 63 support
Source: sword Severity: wishlist Dear Maintainer, See this link: http://tracker.crosswire.org/browse/API-214 Upstream suggests that they've got a good way of letting libsword work with ICU 63. Suggestion is to follow their implementation, once a new upstream version is available. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#913128: xiphos-data: uncompress Xiphos.ogg
Package: xiphos-data Severity: normal Dear Maintainer, Xiphos.ogg is compressed when it is installed, and probably has been for a long time. Can it be stopped from being compressed? I'm opening this bug to keep track of this issue. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled xiphos-data depends on no packages. xiphos-data recommends no packages. Versions of packages xiphos-data suggests: pn xiphos
Bug#913076: [pkg-crosswire-devel] Bug#913076: Bug#913076: libsword-utils: no binaries installed for addld, emptyvss, only libtool wrappers
Sounds good, Thx! What upstream thinks should be packaged, will be the same, usually, as what upstream installs through the autotools. Once they modify the Makefile.am, then the Debian packaging will follow that. On Tue, 6 Nov 2018 at 19:04 Daniel Glassey wrote: > On Wed, Nov 7, 2018 at 12:42 AM Teus Benschop > wrote: > >> Recent there was a discussion on the bug tracker of crosswire, about an >> issue related to this. >> >> Here is the link to the discussion: >> >> http://tracker.crosswire.org/browse/API-213 >> > > Thanks, > I've added a request there for which utilties upstream thinks should be > installed. > > Regards, > Daniel > -- Teus Benschop teusjanne...@gmail.com 0318 712046
Bug#913076: [pkg-crosswire-devel] Bug#913076: reproducible issue too
There was a bug for the issue of the reproducible build: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912161 The patch was attached to the bug report. The patch was applied too. But alas this didn't lead to a reproducible build. On Tue, 6 Nov 2018 at 18:45 Daniel Glassey wrote: > Just realised this bug also means that sword doesn't have a reproducible > build. > > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/sword.html > > Regards, > Daniel > ___ > pkg-crosswire-devel mailing list > pkg-crosswire-de...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-crosswire-devel > -- Teus Benschop teusjanne...@gmail.com 0318 712046
Bug#913076: [pkg-crosswire-devel] Bug#913076: reproducible issue too
... but the bug got closed by the change log. And alas too, I forgot all about it :) On Tue, 6 Nov 2018 at 18:52 Teus Benschop wrote: > There was a bug for the issue of the reproducible build: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912161 > > The patch was attached to the bug report. > The patch was applied too. > But alas this didn't lead to a reproducible build. > > On Tue, 6 Nov 2018 at 18:45 Daniel Glassey wrote: > >> Just realised this bug also means that sword doesn't have a reproducible >> build. >> >> >> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/sword.html >> >> Regards, >> Daniel >> ___ >> pkg-crosswire-devel mailing list >> pkg-crosswire-de...@alioth-lists.debian.net >> >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-crosswire-devel >> > -- > Teus Benschop > teusjanne...@gmail.com > 0318 712046 <0318%20712%20046> > -- Teus Benschop teusjanne...@gmail.com 0318 712046
Bug#913076: [pkg-crosswire-devel] Bug#913076: libsword-utils: no binaries installed for addld, emptyvss, only libtool wrappers
Recent there was a discussion on the bug tracker of crosswire, about an issue related to this. Here is the link to the discussion: http://tracker.crosswire.org/browse/API-213 -- Teus Benschop teusjanne...@gmail.com 0318 712046
Bug#913057: RM: xiphos [ppc64el] -- ROM; missing build on ppc64el
Of course I am all in for taking the fast lane in particular if this is already common practice. So what I'll do is to discuss this with the Crosswire packaging team if they can give me the approval to go ahead in the way you describe. I really want to have the team's consent in this, just now, in the circumstances. Thanks, Jeremy! On Tue, 6 Nov 2018 at 15:52 Jeremy Bicha wrote: > On Tue, Nov 6, 2018 at 9:43 AM Teus Benschop > wrote: > > You are right that the way you say (upload to unstable / ask binNMUs) > would be the fast track to success. > > But within the Crosswire packaging team, I was asked to do this one > through an auto transition. > > https://wiki.debian.org/Teams/ReleaseTeam/Transitions > > And that route is a bit longer. > > But it plays by the book. And I already botched my DD application by not > following the rules. > > So while I agree with you about the faster way to do this, I can't > afford to not follow the book this time :) > > Since there are only 2 affected packages, both owned by the Crosswire > team, it's common practice to *not* need a transition bug and advance > approval from the Release Team. > > But I'm not a Release Team member, so why don't you just ask them? :) > > Jeremy > -- Teus Benschop teusjanne...@gmail.com 0318 712046
Bug#913057: RM: xiphos [ppc64el] -- ROM; missing build on ppc64el
You are right that the way you say (upload to unstable / ask binNMUs) would be the fast track to success. But within the Crosswire packaging team, I was asked to do this one through an auto transition. https://wiki.debian.org/Teams/ReleaseTeam/Transitions And that route is a bit longer. But it plays by the book. And I already botched my DD application by not following the rules. So while I agree with you about the faster way to do this, I can't afford to not follow the book this time :) On Tue, 6 Nov 2018 at 15:37 Jeremy Bicha wrote: > On Tue, Nov 6, 2018 at 9:22 AM Teus Benschop > wrote: > > Yes, this bug seems obsolete because once libsword is fixed it's a > matter of doing the uploads and rebuilds as you say. > > But libsword is going into auto transition due to a change in the soname. > > And I have now experience with how long such an automatic library > transition is going to take. > > In the mean time Xiphos is not yet running on the testing distribution > due to linking to an older libsword version. > > So I thought it more expedient and prudent to ensure Xiphos is right in > testing and works there. > > So yes, it's kind of two independent tracks that could lead to the same > solution. > > A slower one and a fast one. > > It doesn't have to be very slow. Just upload sword to unstable now and > then ask the Debian Release team to do the binNMUs. > > If you use the default urgency=medium, it might only take 5 days to > transition to testing, assuming that xiphos will build on ppc64el now. > > Thanks, > Jeremy Bicha > -- Teus Benschop teusjanne...@gmail.com 0318 712046
Bug#913057: RM: xiphos [ppc64el] -- ROM; missing build on ppc64el
Yes, this bug seems obsolete because once libsword is fixed it's a matter of doing the uploads and rebuilds as you say. But libsword is going into auto transition due to a change in the soname. And I have now experience with how long such an automatic library transition is going to take. In the mean time Xiphos is not yet running on the testing distribution due to linking to an older libsword version. So I thought it more expedient and prudent to ensure Xiphos is right in testing and works there. So yes, it's kind of two independent tracks that could lead to the same solution. A slower one and a fast one. On Tue, 6 Nov 2018 at 15:10 Jeremy Bicha wrote: > Is this bug obsolete now that sword has been accepted into > experimental? Can you just upload sword to unstable now and do the > rebuilds? > > Thanks, > Jeremy Bicha > -- Teus Benschop teusjanne...@gmail.com 0318 712046
Bug#912834: RM - ROM [architecture]
See the bug at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912834 for more information. -- Teus Benschop teusjanne...@gmail.com 0318 712046
Bug#913057: [pkg-crosswire-devel] Bug#913057: RM: xiphos [ppc64el] -- ROM; missing build on ppc64el
Correction of a typo: Instead of saying "will move from unstable to stable", it was supposed to mean "will move from unstable to testing". On Tue, 6 Nov 2018 at 14:21 Teus Benschop wrote: > Package: ftp.debian.org > Severity: normal > > The updated "xiphos" packages does not move from unstable to testing. > > See this page: > https://tracker.debian.org/pkg/xiphos > > The rationale is that when the package is removed from this one > architecture, > the remaining binaries will move from unstable to stable. > > Here is the bug report related to this issue: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912834 > > Thank you! > > Teus Benschop > > ___ > pkg-crosswire-devel mailing list > pkg-crosswire-de...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-crosswire-devel > -- Teus Benschop teusjanne...@gmail.com 0318 712046
Bug#913057: RM: xiphos [ppc64el] -- ROM; missing build on ppc64el
Package: ftp.debian.org Severity: normal The updated "xiphos" packages does not move from unstable to testing. See this page: https://tracker.debian.org/pkg/xiphos The rationale is that when the package is removed from this one architecture, the remaining binaries will move from unstable to stable. Here is the bug report related to this issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912834 Thank you! Teus Benschop
Bug#913043: wish: support architectures armel mips mips64el ppc64el s390x also
Package: qtwebengine5-dev Version: 5.11.2+dfsg-2 Severity: wishlist Dear Maintainer, Currently the package is available for the following architectures: Architecture: amd64 arm64 armhf i386 mipsel It would be so helpful if the packages were also available for the following architectures: armel mips mips64el ppc64el s390x This would help our reverse dependency bibletime, so it would build on all relevant architectures. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qtwebengine5-dev depends on: ii libc62.27-8 ii libqt5core5a 5.11.2+dfsg-4 ii libqt5gui5 5.11.2+dfsg-4 ii libqt5webchannel5-dev5.11.2-2 ii libqt5webengine5 5.11.2+dfsg-2 ii libqt5webenginecore5 5.11.2+dfsg-2 ii libqt5webenginewidgets5 5.11.2+dfsg-2 ii libqt5widgets5 5.11.2+dfsg-4 ii libstdc++6 8.2.0-9 ii qtbase5-dev 5.11.2+dfsg-4 ii qtdeclarative5-dev 5.11.2-2 ii qtpositioning5-dev 5.11.2+dfsg-2 Versions of packages qtwebengine5-dev recommends: ii qtwebengine5-doc 5.11.2+dfsg-2 qtwebengine5-dev suggests no packages. -- no debconf information
Bug#912834: Fix typo
There was a typo in my bug report. I feel it's good to fix this, so the bug report remains clear. The sentence "libsword is not going into auto-transition mode soon" should have been written with "now" rather than "not". So it was going to be meant to mean this: "libsword is now going into auto-transition mode soon" -- Teus Benschop teusjanne...@gmail.com 0318 712046
Bug#912834: xiphos: missing build on ppc64el: suggestion to remove it there
Source: xiphos Version: 4.0.7.1-4 Severity: serious Justification: fails to build from source (but built successfully in the past) Dear Maintainers, The package xiphos currently does not build on architecture ppc64el. There is a patch for it, and this patch is in libsword. But this libsword is not going into auto-transition mode soon. In the mean time package xiphos as is now in testing is not linked to the correct libsword version. So it won't run on testing right now. And this was due to me not following the proper route of the transition. A new build of xiphos was made. That new build links to the correct libsword. So Xiphos works with that new build. But now a missing build on ppc64el will prevent this correctly working xiphos package from being migrated to testing. See this link: https://qa.debian.org/excuses.php?package=xiphos My suggestion is to now request removal of xiphos version 4.0.7.1-4 from architecture ppc64el. So the remaining xiphos binaries will migrate to testing soon. Is there a problem with this approach? If there's no problem with this, I intend to move on with this. This bug is actually to keep track of this issue. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#866657: Source was patched
The source code was patched so it no longer has a hard dependency on libwebkitgtk. The patch removes the editor that was based on libwebkitgtk. Once upstream has updated their source code, the patches can be removed again, of course. But for just now these patches serve to keep Xiphos (with slightly reduced functionality) in Debian Sid and in the upcoming Ubuntu releases. So the patch is sacrificing a bit of functionality in order to keep the major functionality. -- Teus Benschop teusjanne...@gmail.com 0318 712046
Bug#893864: no longer depends on webkitgtk
Yes, it's a hard dependency. But even so, it no no longer officially depends on webkitgtk. Actually it has now changed to a FTBFS error. Can we close this bug now? The FTBFS will be dealt with soon, I am patching the source so it compiles in a clean environment. -- Teus Benschop teusjanne...@gmail.com 0318 712046
Bug#893864: dependency fixed
A new version of Xiphos was uploaded to Debian just now. It no longer depends on libwebkitgtk. If that works out well, then Xiphos can migrate to testing normally. It will required a couple of days from now on. -- Teus Benschop teusjanne...@gmail.com 0318 712046
Bug#866657: dependency fixed
A new version of Xiphos was uploaded just now. It no longer depends on libwebkitgtk. If it works out fine, then soon Xiphos can be migrated to testing again. -- Teus Benschop teusjanne...@gmail.com 0318 712046
Bug#856876: Steps to reproduce
I tried to reproduce this but failed to even write text into the personal commentary. Question: What are the exact steps to reproduce the issue? 1. Install BibleTime 2.11.2 on Debian. 2. Install Commentary Personal. 3. ? 4. ? Thank you for your contribution to Debian. -- Teus Benschop teusjanne...@gmail.com 0318 712046
Bug#655758: Steps to reproduce
I fail to even write text in the Personal commentary, in BibleTime 2.11.2 on Debian. My question is this: What are the steps to reproduce the whole issue: 1. Install BbileTime 2.11.2. 2. Install Personal Commentary 3. Enter text .. how? 4. Do something ... -- Teus Benschop teusjanne...@gmail.com 0318 712046
Bug#893489: [pkg-crosswire-devel] Bug#893489: Bug#893489: bibletime: package not migrating from sid to testing
On Wed, 10 Oct 2018 at 13:00 Christoph Berg wrote: > Re: Teus Benschop 2018-10-10 5dgx71+73dbjkb...@mail.gmail.com> > > Christoph Berg had suggested to follow the same strategy, to get this > fixed. > > > > I had the plan to limit the architectures of the package to those it > builds > > on, then hoping to trick the system into migrating the package from sid > to > > testing, hoping . But apparently this does not work. > > I thought I had told you that this trick doesn't work? > > Christoph > I now found it where you told that this trick does not work. It's here: Britney won't migrate 2.11.1-1 to testing because the builds are missing. ... -- Teus Benschop teusjanne...@gmail.com 0318 712046
Bug#893489: [pkg-crosswire-devel] Bug#893489: Bug#893489: bibletime: package not migrating from sid to testing
The file removal bug can be followed here: 910726: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910726. -- Teus Benschop teusjanne...@gmail.com 0318 712046
Bug#893489: [pkg-crosswire-devel] Bug#893489: Bug#893489: bibletime: package not migrating from sid to testing
Ah, oops, I think I had missed that, sorry! On Wed, 10 Oct 2018 at 13:00 Christoph Berg wrote: > Re: Teus Benschop 2018-10-10 5dgx71+73dbjkb...@mail.gmail.com> > > Christoph Berg had suggested to follow the same strategy, to get this > fixed. > > > > I had the plan to limit the architectures of the package to those it > builds > > on, then hoping to trick the system into migrating the package from sid > to > > testing, hoping . But apparently this does not work. > > I thought I had told you that this trick doesn't work? > > Christoph > -- Teus Benschop teusjanne...@gmail.com 0318 712046
Bug#893489: [pkg-crosswire-devel] Bug#893489: bibletime: package not migrating from sid to testing
I have filed the partial removal bug, asking the FTP Masters to remove the bibletime package for the relevant architectures. Christoph Berg had suggested to follow the same strategy, to get this fixed. I had the plan to limit the architectures of the package to those it builds on, then hoping to trick the system into migrating the package from sid to testing, hoping . But apparently this does not work. Thanks for the contribution. I expect that after some time, if the blocking architectures have been removed, that things will move from sid to testing smoothly. -- Teus Benschop teusjanne...@gmail.com 0318 712046
Bug#910726: RM: bibletime [armel mips mips64el ppc64el s390x] -- ROM; unsatisfiable Build-Depends on armel mips mips64el ppc64el s390x
Package: ftp.debian.org Severity: normal Package bibletime cannot be built on all architectures. See https://qa.debian.org/excuses.php?package=bibletime bibletime unsatisfiable Build-Depends(-Arch) on armel: qtwebengine5-dev bibletime unsatisfiable Build-Depends(-Arch) on mips: qtwebengine5-dev bibletime unsatisfiable Build-Depends(-Arch) on mips64el: qtwebengine5-dev bibletime unsatisfiable Build-Depends(-Arch) on ppc64el: qtwebengine5-dev bibletime unsatisfiable Build-Depends(-Arch) on s390x: qtwebengine5-dev This is a partial removal request to remove bibletime from the following architectures: armel mips mips64el ppc64el s390x See also this: missing build on armel: bibletime (from 2.10.1-3.1) missing build on mips: bibletime (from 2.10.1-3.1) missing build on mips64el: bibletime (from 2.10.1-3.1) missing build on ppc64el: bibletime (from 2.10.1-3.1) missing build on s390x: bibletime (from 2.10.1-3.1) The package bibletime no longer builds on these architectures, because of its changed build depends. See also bug number #893489 where this removal is being discussed. I am one of the maintainers of the bibletime package. The team is pkg-crosswire-de...@alioth-lists.debian.net See also: https://qa.debian.org/developer.php?email=pkg-crosswire-devel%40alioth-lists.debian.net Thanks! Teus Benschop
Bug#893784: Proceed with removal
No objections to this proposal were submitted or recorded. Therefore I am proceeding with this removal request. See bug #900465 for more information. -- Teus Benschop teusjanne...@gmail.com 0318 712046
Bug#893786: Deletion request submitted
No objections to this proposal have been recorded or submitted. I am proceeding with the removal request. A bug was opened for this purpose, see #900463 <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900463>. -- Teus Benschop teusjanne...@gmail.com 0318 712046
Bug#900465: RM: bibledit-bibletime -- ROM; depends on removed package bibledit-gtk
Package: ftp.debian.org Severity: normal Package bibledit-bibletime depends on package bibledit-gtk. Package bibledit-gtk has been removed a while ago. Package bibledit-bibletime standing on its own no longer works. Therefore I am requesting this package to be removed from the Debian archives. There is no reason for having this package while it serves no purposes. Bug number #893784 was filed a while ago, proposing deletion of bibledit-bibletime. No objection was filed against deletion. Therefore I am proceeding with this deletion request.
Bug#900463: RM: bibledit-xiphos -- ROM; ROM; depends on removed package bibledit-gtk
Package: ftp.debian.org Severity: normal Package bibledit-xiphos depends on package bibledit-gtk. Package bibledit-gtk has been removed a while ago. Package bibledit-xiphos standing on its own no longer works. Therefore I am requesting this package to be removed from the Debian archives. There is no reason for having this package while it serves no purposes. Bug number #893786 was filed a while ago, proposing deletion of bibledit-xiphos. No objection was filed against deletion. Therefore I am proceeding with this deletion request.
Bug#893489: Package updated
The updated package is in the Debian code repository, and is ready for review, and for upload.
Bug#893864: Reported upstream
Hi, The upstream developers know about the issue but have not yet addressed it. A bug with this information is available upstream: https://github.com/crosswire/xiphos/issues/834 As to the question you ask, whether it's OK for you to file a removal bug, I'd say that I am not the person to answer this question, but that the actions taken or not taken by Xiphos upstream, determine the answer to your question. That is, if you need to go ahead with removing the old webkitgtk from Debian, and you are blocked by others, and you have informed them several times, then I'd say, as my personal few cents worth of view, that nobody should prevent you from getting ahead with the intended removal. But I am just submitting my own view, perhaps others have other views.
Bug#575426: Confirmed to be fixed
The bug is no longer present in version 2.11.1-1 now in sid. I have installed that version, and checked the option to have a blank line between the verses. This options is called "Insert line break after each verse". I then opened two Bibles. Both Bibles have a blank line between the verses. I am in a mood of cleaning up older bugs. Can this bug be closed? :)
Bug#893786: bibledit-xiphos: propose for deletion
Package: bibledit-xiphos Severity: wishlist Dear Maintainer, The package bibledit-xiphos works together solely with the former package bibledit-gtk. Bibledit-Gtk has now been removed from the Debian archive. Therefore Bibledit-Xiphos no longer serves any purpose. My suggestion is to remove this package bibledit-xiphos from Debian too. I am opening this bug in order to get feedback on this proposal. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bibledit-xiphos depends on: pn curl ii libatk1.0-0 2.28.1-1 ii libc62.27-2 ii libcairo21.15.10-2 ii libdbus-1-3 1.12.6-2 ii libdbus-glib-1-2 0.110-2 ii libfontconfig1 2.12.6-0.1 ii libfreetype6 2.8.1-2 ii libgcc1 1:8-20180319-1 ii libgdk-pixbuf2.0-0 2.36.11-2 ii libglib2.0-0 2.56.0-2 pn libgtk2.0-0 ii libpango-1.0-0 1.40.14-1 ii libpangocairo-1.0-0 1.40.14-1 ii libpangoft2-1.0-01.40.14-1 ii libsoup2.4-1 2.62.0-1 ii libstdc++6 8-20180319-1 bibledit-xiphos recommends no packages. bibledit-xiphos suggests no packages.
Bug#893784: bibledit-bibletime: propose for deletion
Package: bibledit-bibletime Severity: wishlist Dear Maintainer, The package bibledit-bibletime works together solely with the former package bibledit-gtk. Bibledit-Gtk has now been removed from the Debian archive. Therefore Bibledit-Bibletime no longer server any purpose. My suggestion is to remove this package bibledit-bibletime from Debian too. I am opening this bug in order to get feedback on this proposal. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bibledit-bibletime depends on: pn curl ii libatk1.0-0 2.28.1-1 ii libc62.27-2 ii libcairo21.15.10-2 ii libdbus-1-3 1.12.6-2 ii libdbus-glib-1-2 0.110-2 ii libfontconfig1 2.12.6-0.1 ii libfreetype6 2.8.1-2 ii libgcc1 1:8-20180319-1 ii libgdk-pixbuf2.0-0 2.36.11-2 ii libglib2.0-0 2.56.0-2 pn libgtk2.0-0 ii libpango-1.0-0 1.40.14-1 ii libpangocairo-1.0-0 1.40.14-1 ii libpangoft2-1.0-01.40.14-1 ii libsoup2.4-1 2.62.0-1 ii libstdc++6 8-20180319-1 bibledit-bibletime recommends no packages. bibledit-bibletime suggests no packages.
Bug#893614: bibledit-data: set Multi-Arch: foreign
Package: bibledit-data Severity: wishlist Dear Maintainer, Pluparts makes this suggestion: https://wiki.debian.org/MultiArch/Hints#ma-foreign It says this: set Multi-Arch: foreign The package in question is Architecture: all, does not contain any maintainer scripts and does not have any dependencies on architecture-dependent packages. Thus there is no way for it to expose architecture-specific interfaces and marking it Multi-Arch: foreign usually is safe. The hint can be wrong when other metadata is wrong already (e.g. a dependency is wrongly marked Multi-Arch: foreign). Care must be taken when updating the package. When it is switched to Architecture: any or maintainer scripts or dependencies are added, the marking should be reevaluated. Note that even though Architecture: all and Multi-Arch: foreign may look like similar concepts, they are not. The former means that the same binary package can be installed on different architectures. Yet, after installation such packages are treated as if they were "native" architecture (by definition the architecture of the dpkg package) packages. Thus Architecture: all packages cannot satisfy dependencies from other architectures without being marked Multi-Arch foreign. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#893489: bibletime: package not migrating from sid to testing
Source: bibletime Severity: normal Dear Maintainer, The package BibleTime does not move from sid to testing. See further information in this email thread: http://lists.alioth.debian.org/pipermail/pkg-crosswire-devel/2018-March/002933.html -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#892821: bibledit-data: Extraneous content /usr/share/bibledit
Package: bibledit-data Severity: normal Upon reviewing the package, the following remark was made: - We need to stop shipping extraneous content under /usr/share/bibledit
Bug#892822: bibledit: audit debian directory
Source: bibledit Severity: normal Dear Maintainer, Upon reviewing the package, the following comment was made: We need to carefully audit the debian directory of the package and clean it up (e.g., the empty install and dirs files should be removed, update the Standards-Version, update to a newer debhelper compatibility level, clean up the rules file, etc.) -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#892820: bibledit: Fix postrm script
Source: bibledit Severity: normal Upon reviewing the package, the following remark was made: We need to completely remove the postrm script you added, figure out what things are not being properly purged, and then fix those things -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#889659: libwebkit2gtk: segmentation fault in strlen-avx2
Ok, thanks for the clarification! On Thu, 22 Feb 2018 at 13:39 Alberto Garcia <be...@igalia.com> wrote: > On Thu, Feb 22, 2018 at 07:58:36AM +0000, Teus Benschop wrote: > > Hello Teus, > > > There's just one thing that is different from before: After > > installing from experimental, when running bibledit, it now says > > this: > > > > *teus@debian-sid-gui*:*~*$ bibledit > > > > WaylandCompositor requires eglBindWaylandDisplayWL, > > eglUnbindWaylandDisplayWL and eglQueryWaylandBuffer. > > > > Nested Wayland compositor could not initialize EGL > > That's the expected message that you get when hardware rendering > cannot be initialized, so nothing to worry about! > > Regards, > > Berto >
Bug#889659: libwebkit2gtk: segmentation fault in strlen-avx2
Hello Berto, The updated webkit2gtk from the experimental branch fixes the segmentation fault. Thank you for making it available. There's just one thing that is different from before: After installing from experimental, when running bibledit, it now says this: *teus@debian-sid-gui*:*~*$ bibledit WaylandCompositor requires eglBindWaylandDisplayWL, eglUnbindWaylandDisplayWL and eglQueryWaylandBuffer. Nested Wayland compositor could not initialize EGL However, Bibledit itself runs perfectly normal, there's no segmentation fault anymore.
Bug#890865: No upgrade path
Hi, The packages bibledit-gtk and the package bibledit are different. There is no automatic upgrade path from bibledit-gtk to bibledit. The reason for this is that the file system layout is completely different between the two. If users have used bibledit-gtk, they keep their Bibles and consultation notes in a certain layout in their file system. If they then install bibledit, with its completely different file system and storage engine, there is really now way to automatically upgrade from one to the other. The users had Bibledit-Gtk with some Bibles in it, then Ubuntu and Debian suggest they can upgrade to Bibledit, once they do that upgrade, they end up with no Bibles in the new package. In view of the above information, I have this question: In what way will this transitional package assist the existing users on Debian 9 Stretch and Ubuntu 17.10?
Bug#890289: libmbedtls
Yes, you are right that embedding this library presents a security risk, in particular when the package plus its embedded library gets older and new security issues are found in mbedtls. The segmentation fault now caused by mbedtls was the reason this code was embedded, it didn't have a segmentation fault then. Upstream is looking into this how to solve this.
Bug#619118: Upstream comment
Hi, This issue was forwarded upstream. Upstream link: https://github.com/bibletime/bibletime/issues/122 The developer has responded to this issue, and explained how the personal commentary is writable. He describes the steps to take to write to the personal commentary. I have confirmed that the version now in Debian, that is version 2.11.1, behaves in the way the BibleTime developer says. That means that this bug report can be regarded as fixed. Thank you for contributing to the quality of Debian.
