Bug#1011748: onionshare-nautilus.py is not compatible with Python3
Package: onionshare
Version: 2.2-3
Severity: important
Tags: patch upstream
X-Debbugs-Cc: boy...@riseup.net
Dear Maintainer,
* What led up to the situation?
In Tails 5.0, onionshare 2.2-3 is installed, Python2 is not.
>From Nautilus, I want to right-click a file and share it via OnionShare.
* What was the outcome of this action?
Nothing happens. See
https://gitlab.tails.boum.org/tails/tails/-/issues/18990 for details.
The reason is that onionshare is using urllib.url2pathname. This has
been renamed to urllib.request.url2pathname in python3.
Here is a fix that keeps compatibility with python2:
https://github.com/boyska/onionshare/commit/fd6269a7f3e54389543fd3559c8e4d39dfe02b09
I'm also attaching a patch that *drops* compatibility with python2.
Choose the one you like the most :)
--- /usr/share/nautilus-python/extensions/onionshare-nautilus.py 2019-10-13 18:35:40.0 +
+++ /usr/share/nautilus-python/extensions/onionshare-nautilus.py 2022-05-26 08:35:15.74400 +
@@ -3,7 +3,7 @@
import json
import locale
import subprocess
-import urllib
+import urllib.request
import gi
gi.require_version("Nautilus", "3.0")
@@ -67,7 +67,7 @@
def url2path(self, url):
file_uri = url.get_activation_uri()
arg_uri = file_uri[7:]
-path = urllib.url2pathname(arg_uri)
+path = urllib.request.url2pathname(arg_uri)
return path
def exec_onionshare(self, filenames):
Bug#990852: nicotine-plus appears to be maintained again: upgrade to latest version
Package: nicotine Severity: normal Dear Maintainer, I see that updates to the nicotine package are pretty low, and it has even been removed from unstable. However, I see activity on https://github.com/nicotine-plus/nicotine-plus and it seems to me that nicotine should now support gtk3 So I think that removing the package from the repositories is not the only choice; upgrading to new version with modern dependencies should be possible. It would be fantastic if you could do that!
Bug#821356: emoslib: Package is not reproducible changing shell
Package: emoslib
Version: 4.3.9-1
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Hi,
While working on the “reproducible builds” effort [1], we have noticed that
emoslib is not reproducible changing shell: debian/rules assume the behaviour
of dash's echo, which is not compatible with bash.
The attached patch (thanks, deki) fixes this behavior.
[1] https://wiki.debian.org/ReproducibleBuilds
-- System Information:
Architecture: amd64 (x86_64)
Kernel: Linux 4.1.11-1-lts-apparmor (SMP w/8 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
diff -Nur emoslib-4.3.9/debian/changelog emoslib-4.3.9-repr/debian/changelog
--- emoslib-4.3.9/debian/changelog 2016-03-22 19:28:00.0 -0400
+++ emoslib-4.3.9-repr/debian/changelog 2016-04-17 10:42:19.868582724 -0400
@@ -1,3 +1,9 @@
+emoslib (2:4.3.9-1.0~reproducible1) UNRELEASED; urgency=medium
+
+ * Solve reproducibility issues with different shells
+
+ -- boyska <piutto...@logorroici.org> Sun, 17 Apr 2016 10:41:40 -0400
+
emoslib (2:4.3.9-1) unstable; urgency=medium
* New upstream release.
diff -Nur emoslib-4.3.9/debian/rules emoslib-4.3.9-repr/debian/rules
--- emoslib-4.3.9/debian/rules 2016-03-22 19:28:00.0 -0400
+++ emoslib-4.3.9-repr/debian/rules 2016-04-17 10:41:02.746387904 -0400
@@ -96,4 +96,5 @@
# Change default from emos to emos_shared to link against shared libs in metview, etc.
grep -v LIBEMOS_SELF_LIBRARIES ${CMAKE_DIR}/libemos-config.cmake > ${CMAKE_DIR}/tmp
mv ${CMAKE_DIR}/tmp ${CMAKE_DIR}/libemos-config.cmake
- echo "\nset( LIBEMOS_SELF_LIBRARIES"emos_shared" )" >> ${CMAKE_DIR}/libemos-config.cmake
+ echo >> ${CMAKE_DIR}/libemos-config.cmake
+ echo "set( LIBEMOS_SELF_LIBRARIES"emos_shared" )" >> ${CMAKE_DIR}/libemos-config.cmake
Bug#820169: python-reportlab: please honour SOURCE_DATE_EPOCH
Package: python-reportlab Version: 3.3.0-1 Severity: normal Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: toolchain timestamps Hi, While working on the “reproducible builds” effort [1], we have noticed that reportlab embeds current timestamp in the generated PDF. This behavior make packages whose documentation is generated with reportlab unreproducible. The attached patch fixes this behavior honoring the SOURCE_DATE_EPOCH [2] environment variable. [1] https://wiki.debian.org/ReproducibleBuilds [2] https://reproducible-builds.org/specs/source-date-epoch/ Description: Honour SOURCE_DATE_EPOCH environment variable If the SOURCE_DATE_EPOCH environment variable is set, reportlab will use it instead of the current timestamp. See https://reproducible-builds.org/specs/source-date-epoch/ . python-reportlab (3.3.0-1.0~reproducible1) UNRELEASED; urgency=medium . * Honour SOURCE_DATE_EPOCH, to generate PDFs reproducibly Author: boyska <piutto...@logorroici.org> --- The information above should follow the Patch Tagging Guidelines, please checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here are templates for supplementary fields that you might want to add: Origin: <vendor|upstream|other>, Bug: Bug-Debian: https://bugs.debian.org/ Bug-Ubuntu: https://launchpad.net/bugs/ Forwarded: <no|not-needed|url proving that it has been forwarded> Reviewed-By: Last-Update: --- python-reportlab-3.3.0.orig/src/reportlab/pdfbase/pdfdoc.py +++ python-reportlab-3.3.0/src/reportlab/pdfbase/pdfdoc.py @@ -1730,8 +1730,12 @@ _NOWT=None def _getTimeStamp(): global _NOWT if not _NOWT: -import time -_NOWT = time.time() +import os +if 'SOURCE_DATE_EPOCH' in os.environ: +_NOWT = float(os.environ['SOURCE_DATE_EPOCH']) +else: +import time +_NOWT = time.time() return _NOWT class PDFDate(PDFObject):
Bug#819726: ckbuilder: please use SOURCE_DATE_EPOCH for copyright notices and build timestamp
Package: ckbuilder
Version: 2.3.0+dfsg-2
Severity: normal
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain timestamps
Hi,
While working on the “reproducible builds” effort [1], we have noticed
that ckbuilder embeds the build time in two places: copyrigh headers on the
built javascript files, and a ".options.timestamp" field in the generated code
itself. This behaviour make packages generated by ckbuilder (ie: ckeditor)
unreproducible.
The attached patch fixes this behaviour honoring the SOURCE_DATE_EPOCH [2]
environment variable.
[1] https://wiki.debian.org/ReproducibleBuilds
[2] https://reproducible-builds.org/specs/source-date-epoch/
diff --git debian/changelog debian/changelog
index 98e47d0..4f53bb9 100644
--- debian/changelog
+++ debian/changelog
@@ -1,3 +1,9 @@
+ckbuilder (2.3.0+dfsg-2.0~reproducible1) UNRELEASED; urgency=medium
+
+ * FIX timestamps in copyright notices
+
+ -- boyska <piutto...@logorroici.org> Mon, 28 Mar 2016 21:23:15 -0400
+
ckbuilder (2.3.0+dfsg-2) unstable; urgency=medium
* Depends += "libprotobuf-java".
diff --git debian/patches/now-respects-source-date-epoch.patch debian/patches/now-respects-source-date-epoch.patch
new file mode 100644
index 000..6a84658
--- /dev/null
+++ debian/patches/now-respects-source-date-epoch.patch
@@ -0,0 +1,63 @@
+Description: respect SOURCE_DATE_EPOCH spec
+ ckbuilder puts a buildtime timestamp both in comments and in other part of
+ generated js. This patch make it observe SOURCE_DATE_EPOCH, so to allow for
+ reproducible builds
+ See https://reproducible-builds.org/specs/source-date-epoch/
+ .
+ ckbuilder (2.3.0+dfsg-2.0~reproducible1) UNRELEASED; urgency=medium
+ .
+ * FIX timestamps in copyright notices
+Author: boyska <piutto...@logorroici.org>
+
+---
+The information above should follow the Patch Tagging Guidelines, please
+checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
+are templates for supplementary fields that you might want to add:
+
+Origin: <vendor|upstream|other>,
+Bug:
+Bug-Debian: https://bugs.debian.org/
+Bug-Ubuntu: https://launchpad.net/bugs/
+Forwarded: <no|not-needed|url proving that it has been forwarded>
+Reviewed-By:
+Last-Update:
+
+--- a/src/ckbuilder.js
b/src/ckbuilder.js
+@@ -35,7 +35,11 @@
+ } catch ( e ) {
+ isMinified = false;
+ }
+- var now = new Date();
++ if(System.env.get('SOURCE_DATE_EPOCH') !== null) {
++ var now = new Date(parseInt(System.getenv("SOURCE_DATE_EPOCH"), 10) * 1000);
++ } else {
++ var now = new Date();
++ }
+ var timestamp = Integer.toString( now.getUTCFullYear() % 1000, 36 ) + Integer.toString( now.getUTCMonth(), 36 ) + Integer.toString( now.getUTCDate(), 36 ) + Integer.toString( now.getUTCHours(), 36 );
+ timestamp = timestamp.toUpperCase();
+
+--- a/src/lib/utils.js
b/src/lib/utils.js
+@@ -30,8 +30,12 @@
+ * @static
+ */
+ copyright: function( eol ) {
+- var copyright,
+-date = new Date();
++ var copyright;
++ if(System.env.get('SOURCE_DATE_EPOCH') !== null) {
++var date = new Date(parseInt(System.getenv("SOURCE_DATE_EPOCH"), 10) * 1000);
++ } else {
++var date = new Date();
++ }
+
+ if ( CKBuilder.options.commercial )
+ copyright = "/*" + eol + "This software is covered by CKEditor Commercial License. Usage without proper license is prohibited." + eol + "Copyright (c) 2003-" + date.getFullYear() + ", CKSource - Frederico Knabben. All rights reserved." + eol + "*/" + eol;
+@@ -221,4 +225,4 @@
+ return result;
+ }
+ };
+-}() );
+\ No newline at end of file
++}() );
diff --git debian/patches/series debian/patches/series
index 11053e4..549e272 100644
--- debian/patches/series
+++ debian/patches/series
@@ -1,3 +1,4 @@
make.patch
notar.patch
unmerge.patch
+now-respects-source-date-epoch.patch
Bug#817958: RFP: python-flask-bootstrap -- python-flask extension to make the Bootstrap framework available to flask templates
Package: wnpp Severity: wishlist * Package name: python-flask-bootstrap Version : 3.3.5.7 Upstream Author : Marc Brinkmann <g...@marcbrinkmann.de> * URL : https://pythonhosted.org/Flask-Bootstrap/ * License : Apache License Programming Lang: Python Description : python-flask extension to make the Bootstrap framework available to flask templates Flask-Bootstrap packages Bootstrap into an extension that mostly consists of a blueprint named 'bootstrap'. It can also create links to serve Bootstrap from a CDN and works with no boilerplate code in your application. This package is important for me because I am one of the developer (and maintainer) of libreant<http://github.com/insomnia-lab/libreant>, which depends on it. My medium-term wish is to have all of libreant dependencies into debian, and I guess that this is a good start because it is simple to package and quite popular. I have already done debian packaging for it <http://git.lattuga.net/boyska/deb-flask-bootstrap>, but I have little experience with debian packaging and zero experience with teams, uploading, maintenance. So I would be willing to engage in its maintenance but definitely can't do that alone.
