Bug#1053483: hash-slinger: diff for NMU version 3.1-1.2
Control: tags 1053483 + pending Dear maintainer, I've prepared an NMU for hash-slinger (versioned as 3.1-1.2) and uploaded it to DELAYED/10. Please feel free to tell me if I should delay it longer. I didn't find a recent copy of the source code on Salsa as well, otherwise I would have submitted this as a MR there as well. I also plan on issuing a stable release update for this once the NMU lands in testing. Let me know if I should delay this as well. My work on this issue is tracked in this bug report and our internal tracker here as well: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41350 Regards. -- diff -Nru hash-slinger-3.1/debian/changelog hash-slinger-3.1/debian/changelog --- hash-slinger-3.1/debian/changelog 2022-02-10 01:03:46.0 -0500 +++ hash-slinger-3.1/debian/changelog 2023-10-05 10:37:58.0 -0400 @@ -1,3 +1,10 @@ +hash-slinger (3.1-1.2) unstable; urgency=medium + + * Non-maintainer upload. + * Bug fix: "tlsa can produce invalid records" (Closes: #1053483) + + -- Antoine Beaupré Thu, 05 Oct 2023 10:37:58 -0400 + hash-slinger (3.1-1.1) unstable; urgency=low * Non-maintainer upload. diff -Nru hash-slinger-3.1/debian/patches/0001-fix-generic-TLSA-record-generation.patch hash-slinger-3.1/debian/patches/0001-fix-generic-TLSA-record-generation.patch --- hash-slinger-3.1/debian/patches/0001-fix-generic-TLSA-record-generation.patch 1969-12-31 19:00:00.0 -0500 +++ hash-slinger-3.1/debian/patches/0001-fix-generic-TLSA-record-generation.patch 2023-10-05 10:36:07.0 -0400 @@ -0,0 +1,34 @@ +From e3bec6e2a6b1bda7c52b4c585474fd7cc23ab643 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Charaoui?= +Date: Wed, 4 Oct 2023 22:05:26 -0400 +Subject: [PATCH] fix generic TLSA record generation +Applied-Upstream: https://github.com/letoams/hash-slinger/commit/0bb0dba91c51d367d9a37297f13e07f33c01bfdc + +It seems like the calculation for the TLSA record never really worked, +as we're doing float division here on the `len()` field. In our case, +that field returned `35.0` which is not valid in our environment. + +Doing an integer division gives the correct result in most cases, I +believe. + +Closes: #45 +--- + tlsa | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/tlsa b/tlsa +index cea7230..ec97150 100755 +--- a/tlsa b/tlsa +@@ -513,7 +513,7 @@ class TLSARecord: + def getRecord(self, generic=False): + """Returns the RR string of this TLSARecord, either in rfc (default) or generic format""" + if generic: +- return '%s IN TYPE52 \# %s %s%s%s%s' % (self.name, (len(self.cert)/2)+3 , self._toHex(self.usage), self._toHex(self.selector), self._toHex(self.mtype), self.cert) ++ return '%s IN TYPE52 \# %s %s%s%s%s' % (self.name, (len(self.cert)//2)+3 , self._toHex(self.usage), self._toHex(self.selector), self._toHex(self.mtype), self.cert) + return '%s IN TLSA %s %s %s %s' % (self.name, self.usage, self.selector, self.mtype, self.cert) + + def _toHex(self, val): +-- +2.39.2 + diff -Nru hash-slinger-3.1/debian/patches/series hash-slinger-3.1/debian/patches/series --- hash-slinger-3.1/debian/patches/series 2021-02-14 11:40:02.0 -0500 +++ hash-slinger-3.1/debian/patches/series 2023-10-05 10:36:07.0 -0400 @@ -1 +1,2 @@ 0001-Debian-default-root.key-resides-in-usr-share-dns-roo.patch +0001-fix-generic-TLSA-record-generation.patch signature.asc Description: PGP signature
Bug#1032287: python-qrencode: diff for NMU version 1.2-5.1
Control: tags 1032287 + pending Dear maintainer, I've prepared an NMU for python-qrencode (versioned as 1.2-5.1) and uploaded it to DELAYED/10. Please feel free to tell me if I should delay it longer. Regards. -- diff -Nru python-qrencode-1.2/debian/changelog python-qrencode-1.2/debian/changelog --- python-qrencode-1.2/debian/changelog 2019-08-30 08:31:57.0 -0400 +++ python-qrencode-1.2/debian/changelog 2023-03-02 22:19:32.0 -0500 @@ -1,3 +1,10 @@ +python-qrencode (1.2-5.1) unstable; urgency=medium + + * Non-maintainer upload. + * fix crash in Python 3.10 (Closes: #1032287) + + -- Antoine Beaupré Thu, 02 Mar 2023 22:19:32 -0500 + python-qrencode (1.2-5) unstable; urgency=medium * Drop Python 2 support (Closes: #938112). diff -Nru python-qrencode-1.2/debian/patches/python3-10-port.patch python-qrencode-1.2/debian/patches/python3-10-port.patch --- python-qrencode-1.2/debian/patches/python3-10-port.patch 1969-12-31 19:00:00.0 -0500 +++ python-qrencode-1.2/debian/patches/python3-10-port.patch 2023-03-02 22:19:28.0 -0500 @@ -0,0 +1,13 @@ +Description: adapt to changes in Python 3.10 +Author: anar...@debian.org +Origin: Debian +Forwarded: no +Last-Update: 2023-03-03 + +--- python-qrencode-1.2.orig/qr_encode.c python-qrencode-1.2/qr_encode.c +@@ -1,3 +1,4 @@ ++#define PY_SSIZE_T_CLEAN + #include + #include + #include diff -Nru python-qrencode-1.2/debian/patches/series python-qrencode-1.2/debian/patches/series --- python-qrencode-1.2/debian/patches/series 1969-12-31 19:00:00.0 -0500 +++ python-qrencode-1.2/debian/patches/series 2023-03-02 22:18:59.0 -0500 @@ -0,0 +1 @@ +python3-10-port.patch signature.asc Description: PGP signature
Bug#987008: grub2: diff for NMU version 2.06-8.1
Control: tags 987008 + pending Dear maintainer, I've prepared an NMU for grub2 (versioned as 2.06-8.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Note that the package was uploaded to *experimental*, not unstable, as an extra precaution. Let me know if you will followup with an unstable update or I should. A copy of the package is also available at: https://people.debian.org/~anarcat/debian/sid/grub2_2.06-8.1_amd64.changes (and yes, I am aware this makes it possible to bypass the DELAYED queue, which is partly why it's targeting experimental.) Regards. a. diff -Nru grub2-2.06/debian/changelog grub2-2.06/debian/changelog --- grub2-2.06/debian/changelog 2023-02-08 20:09:00.0 -0500 +++ grub2-2.06/debian/changelog 2023-02-25 15:16:55.0 -0500 @@ -1,3 +1,11 @@ +grub2 (2.06-8.1) experimental; urgency=medium + + * Non-maintainer upload. + * Fix an issue where a logical volume rename would lead grub to fail to +boot (Closes: #987008) + + -- Antoine Beaupré Sat, 25 Feb 2023 15:16:55 -0500 + grub2 (2.06-8) unstable; urgency=medium [ Steve McIntyre ] diff -Nru grub2-2.06/debian/patches/987008-lvrename-boot-fail.patch grub2-2.06/debian/patches/987008-lvrename-boot-fail.patch --- grub2-2.06/debian/patches/987008-lvrename-boot-fail.patch 1969-12-31 19:00:00.0 -0500 +++ grub2-2.06/debian/patches/987008-lvrename-boot-fail.patch 2023-02-25 15:16:55.0 -0500 @@ -0,0 +1,35 @@ +Description: fix renamed LV detection + It looks like the detection of the LVM logical volumes fails in + certain edge conditions. In particular, it was reported that + renaming an LV will make grub fail to boot from the system as it + cannot properly detect it anymore. + . + I have looked at the code surrounding the patch and cannot claim to + understand the entire function here, as it is huge and quite + cryptic. But it seems sane: the `ptr` we're inspecting here starts + at the `rlocn->offset`, but we were adding `mda_size` to the + (somewhat) unrelated metadatabuf instead. Now we're marking the + `mda_end` correctly, based on the rlocn->offsite and ->size. + . + I have not tested this myself as the test setup is quite involved, + but it seems others (e.g. "Hoyer, David" ) + have tested the patch and confirmed it worked. +Author: Rogier +Origin: other +Bug: https://savannah.gnu.org/bugs/index.php?61620 +Bug-Debian: https://bugs.debian.org/987008 +Forwarded: https://savannah.gnu.org/bugs/index.php?61620 +Reviewed-By: Antoine Beaupré +Last-Update: 2023-02-25 + +--- grub2-2.06.orig/grub-core/disk/lvm.c grub2-2.06/grub-core/disk/lvm.c +@@ -290,7 +290,7 @@ grub_lvm_detect (grub_disk_t disk, + + p = q = (char *)ptr; + +- if (grub_add ((grub_size_t)metadatabuf, (grub_size_t)mda_size, &ptr)) ++ if (grub_add (ptr, (grub_size_t)grub_le_to_cpu64 (rlocn->size), &ptr)) + goto error_parsing_metadata; + + mda_end = (char *)ptr; diff -Nru grub2-2.06/debian/patches/series grub2-2.06/debian/patches/series --- grub2-2.06/debian/patches/series 2023-02-08 20:09:00.0 -0500 +++ grub2-2.06/debian/patches/series 2023-02-25 15:09:36.0 -0500 @@ -114,3 +114,4 @@ grub_mkconfig_restore_umask.patch ignore_checksum_seed_incompat_feature.patch ignore_the_large_dir_incompat_feature.patch +987008-lvrename-boot-fail.patch signature.asc Description: PGP signature
Bug#988074: trocla: diff for NMU version 0.3.0-0.1
Package: trocla
Version: 0.2.3-1
Severity: normal
Tags: patch pending
Dear maintainer,
I've prepared an NMU for trocla (versioned as 0.3.0-0.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.
I also uploaded it to experimental, given that we're in a freeze, as a
precaution, in case you want to just cherry-pick the two patches to just
fix the RC bugs. But considering that 0.2.3 is pretty broken, I suspect
that wouldn't be a good idea anyways.
Note that this diff includes a pile of changes that had accumulated in
the git repository on salsa and are therefore not only my changes. My
work may be more easily reviewed here:
https://salsa.debian.org/anarcat/trocla/-/commits/debian/experimental/
You can also see the pipeline has been fixed by those commits here:
https://salsa.debian.org/anarcat/trocla/-/pipelines/251950
Regards.
diff -Nru trocla-0.2.3/bin/trocla trocla-0.3.0/bin/trocla
--- trocla-0.2.3/bin/trocla 2016-03-01 15:40:25.0 -0500
+++ trocla-0.3.0/bin/trocla 2021-05-04 15:31:47.0 -0400
@@ -47,18 +47,20 @@
end.parse!
def create(options)
- Trocla.new(options.delete(:config_file)).password(
+ [ Trocla.new(options.delete(:config_file)).password(
options.delete(:trocla_key),
options.delete(:trocla_format),
options.merge(YAML.load(options.delete(:other_options).shift.to_s)||{})
- )
+ ) , 0 ]
end
def get(options)
- Trocla.new(options.delete(:config_file)).get_password(
+ res = Trocla.new(options.delete(:config_file)).get_password(
options.delete(:trocla_key),
-options.delete(:trocla_format)
+options.delete(:trocla_format),
+options.merge(YAML.load(options.delete(:other_options).shift.to_s)||{})
)
+ [ res, res.nil? ? 1 : 0 ]
end
def set(options)
if options.delete(:ask_password)
@@ -67,7 +69,7 @@
pwd2 = ask('Repeat password: ') { |q| q.echo = 'x' }.to_s
unless password == pwd2
STDERR.puts 'Passwords did not match, exiting!'
- exit 1
+ return [ nil, 1 ]
end
else
password = options.delete(:password) || STDIN.read.chomp
@@ -78,29 +80,29 @@
value = if no_format
password
else
-trocla.formats(format).format(password, options.delete(:other_options).shift.to_s)
+trocla.formats(format).format(password, (YAML.load(options.delete(:other_options).shift.to_s)||{}))
end
trocla.set_password(
options.delete(:trocla_key),
format,
value
)
- ''
+ [ '', 0 ]
end
def reset(options)
- Trocla.new(options.delete(:config_file)).reset_password(
+ [ Trocla.new(options.delete(:config_file)).reset_password(
options.delete(:trocla_key),
options.delete(:trocla_format),
options.merge(YAML.load(options.delete(:other_options).shift.to_s)||{})
- )
+ ), 0 ]
end
def delete(options)
- Trocla.new(options.delete(:config_file)).delete_password(
+ [ Trocla.new(options.delete(:config_file)).delete_password(
options.delete(:trocla_key),
options.delete(:trocla_format)
- )
+ ), 0 ]
end
def formats(options)
@@ -125,7 +127,8 @@
options[:other_options] = ARGV
check_format(options[:trocla_format]) unless ['delete','formats'].include?(action)
begin
- if result = send(action,options)
+ result, excode = send(action,options)
+ if result
puts result.is_a?(String) ? result : result.inspect
end
rescue Exception => e
@@ -136,6 +139,7 @@
raise e if options[:trace]
exit 1
end
+exit excode.nil? ? 0 : excode
else
STDERR.puts "Please supply one of the following actions: #{actions.join(', ')}"
STDERR.puts "Use #{$0} --help to get a list of options for these actions"
diff -Nru trocla-0.2.3/CHANGELOG.md trocla-0.3.0/CHANGELOG.md
--- trocla-0.2.3/CHANGELOG.md 2016-03-01 15:40:25.0 -0500
+++ trocla-0.3.0/CHANGELOG.md 2021-05-04 15:31:47.0 -0400
@@ -1,5 +1,14 @@
# Changelog
+## to 0.3.0
+
+* Add open method to be able to immediately close a trocla store after using it - thanks martinpfeiffer
+* Add typesafe charset - thanks hggh
+* Support cost option for bcrypt
+* address concurrency corner cases, when 2 concurrent threads or even processes
+ are currently calculating the same (expensive) format.
+* parse additional options on cli (#39 & #46) - thanks fe80
+
## to 0.2.3
1. Add extended CA validity profiles
diff -Nru trocla-0.2.3/debian/changelog trocla-0.3.0/debian/changelog
--- trocla-0.2.3/debian/changelog 2016-03-01 16:05:19.0 -0500
+++ trocla-0.3.0/debian/changelog 2021-05-04 15:32:32.0 -0400
@@ -1,3 +1,39 @@
+trocla (0.3.0-0.1) experimental; urgency=medium
+
+ [ Antoine Beaupré ]
+ * Non-maintainer upload.
+ * New upstream release (Closes: #974697)
+ * Remove no-pending_for patch: dependency packaged in Debian and added
+to Build-Depends.
+ * remove fix_version.patch: just s
Bug#826675: rapid-photo-downloader: Wrong sort order
Control: tag -1 moreinfo On Tue, Jun 07, 2016 at 09:40:07PM +0200, Christian von Kietzell wrote: > Package: rapid-photo-downloader > Version: 0.4.11-1 > Severity: normal > > Dear Maintainer, > > rpd sorts the files to import incorrectly, resulting in file numbering that > isn't chronological (with respect to the files to import). Its internally used > modification time, which files are sorted by, is only accurate to full > seconds. I checked this by printing the filename and modification time in > scan.py. > "touch"-ing all files in (filename) order and sleeping at least one second in > between calls makes rpd sort them correctly. > > Usually, this isn't really a problem when photos are downloaded from a memory > card directly. If you bulk-copy them to a different directory first, it's > easily triggered, though. On the other hand I can see how the same behaviour > might come about with cameras with high framerates and photos shot in burst > mode. Hi! This bug report is pretty old, could you try again with the latest release in testing? A lot of changes went in RPD since then, and I wonder if this is still a problem. Otherwise, I would also argue that if you copy files before RPD processes them, you're kind of doing it wrong. :) RPD is the thing that's designed to copy them... a. signature.asc Description: PGP signature
Bug#807990: oath-toolkit: diff for NMU version 2.6.1-1.4
[this is a resend: the prevous version had the wrong date in
debian/changelog]
Dear maintainer,
I've prepared an NMU for oath-toolkit (versioned as 2.6.1-1.4) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.
Regards.
--
diff -Nru oath-toolkit-2.6.1/debian/changelog oath-toolkit-2.6.1/debian/changelog
--- oath-toolkit-2.6.1/debian/changelog 2019-02-09 10:39:41.0 -0500
+++ oath-toolkit-2.6.1/debian/changelog 2016-08-20 09:51:41.0 -0400
@@ -1,3 +1,11 @@
+oath-toolkit (2.6.1-1.4) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * patch: fail gracefully for missing users (Closes: #807990)
+ * push to salsa
+
+ -- Antoine Beaupré Sat, 20 Aug 2016 09:51:41 -0400
+
oath-toolkit (2.6.1-1.3) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru oath-toolkit-2.6.1/debian/control oath-toolkit-2.6.1/debian/control
--- oath-toolkit-2.6.1/debian/control 2018-06-22 13:48:52.0 -0400
+++ oath-toolkit-2.6.1/debian/control 2016-08-20 09:51:41.0 -0400
@@ -6,8 +6,8 @@
Build-Depends: cdbs, debhelper (>= 7.0.0), libpam0g-dev, datefudge, gtk-doc-tools, dblatex, libxml2-utils, libxmlsec1-dev, dh-autoreconf
Standards-Version: 3.9.6
Homepage: http://www.nongnu.org/oath-toolkit/
-Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/oath-toolkit.git
-Vcs-Git: git://anonscm.debian.org/collab-maint/oath-toolkit.git
+Vcs-Browser: https://salsa.debian.org/debian/oath-toolkit
+Vcs-Git: https://salsa.debian.org/debian/oath-toolkit.git
Package: liboath-dev
Section: libdevel
diff -Nru oath-toolkit-2.6.1/debian/patches/0001-fail-gracefully-for-missing-users.patch oath-toolkit-2.6.1/debian/patches/0001-fail-gracefully-for-missing-users.patch
--- oath-toolkit-2.6.1/debian/patches/0001-fail-gracefully-for-missing-users.patch 1969-12-31 19:00:00.0 -0500
+++ oath-toolkit-2.6.1/debian/patches/0001-fail-gracefully-for-missing-users.patch 2016-08-20 09:51:41.0 -0400
@@ -0,0 +1,83 @@
+From 509c4cda7e08384d7cd16dfdb3917b4373f1e36e Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?=
+Date: Mon, 1 Aug 2016 12:25:10 -0400
+Subject: [PATCH] fail gracefully for missing users
+
+when the pam module is enabled, it forces *all* users to immediately
+start using OATH, or they can't login at all.
+
+a more progressive approach would seem more reasonable to me,
+especially since each user need to get an admin user to update the
+central file for them.
+
+this patch adds an early check to the users file and makes sure the
+user exists before prompting for a password.
+
+if the user is missing, it exits early with a standard error code
+(PAM_USER_UNKNOWN) which can then be ignored in the PAM configuration
+(as shown in the README file). this leaves the policy decision up to
+the admin (and defaults to "fail closed").
+
+if the user is present, the code path remains the same except the
+usersfile is scanned twice, which may be a performance penalty on very
+slow filesystems or very large files. the only workaround I can think
+of for this would be to load the whole file into memory, but this
+could have significant memory impact on large files.
+
+the function used (`oath_authenticate_usersfile`) is a little overkill
+as it actually goes and tries to authenticate the user with an empty
+password. this is harmless because the file isn't updated if the OTP
+is incorrect and because no warning is sent to syslog.
+
+a possible improvement on this would be to have a warning shown to the
+user inciting them to configure OATH or to warn them about a possible
+typo in their username before they enter their regular passphrase
+---
+ pam_oath/README | 2 +-
+ pam_oath/pam_oath.c | 17 +
+ 2 files changed, 18 insertions(+), 1 deletion(-)
+
+diff --git a/pam_oath/README b/pam_oath/README
+index bef4265..24b9f8b 100644
+--- a/pam_oath/README
b/pam_oath/README
+@@ -23,7 +23,7 @@ window open before making any changes!
+
+ -
+ # head -1 /etc/pam.d/su
+-auth requisite pam_oath.so debug usersfile=/etc/users.oath window=20
++auth [user_unknown=ignore success=ok] pam_oath.so debug usersfile=/etc/users.oath window=20
+ #
+ -
+
+diff --git a/pam_oath/pam_oath.c b/pam_oath/pam_oath.c
+index 2820318..25a3452 100644
+--- a/pam_oath/pam_oath.c
b/pam_oath/pam_oath.c
+@@ -162,6 +162,23 @@ pam_sm_authenticate (pam_handle_t * pamh,
+ }
+ DBG (("get user returned: %s", user));
+
++ // quick check to skip unconfigured users before prompting for password
++ {
++time_t last_otp;
++otp[0] = '\0';
++rc = oath_authenticate_usersfile (cfg.usersfile,
++ user,
++ otp, cfg.window, onlypasswd, &last_otp);
++
++DBG (("authenticate first pass rc %d (%s: %s) last otp %s", rc,
++ oath_strerror_name (rc) ? oath_strerror_name (rc) : "UNKNOWN",
++ oath_strerror (rc), ctime (&last_otp)));
++if (rc == OATH_
Bug#807990: oath-toolkit: diff for NMU version 2.6.1-1.4
Control: tags 807990 + pending
Dear maintainer,
I've prepared an NMU for oath-toolkit (versioned as 2.6.1-1.4) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.
Regards.
diff -Nru oath-toolkit-2.6.1/debian/changelog oath-toolkit-2.6.1/debian/changelog
--- oath-toolkit-2.6.1/debian/changelog 2019-02-09 10:39:41.0 -0500
+++ oath-toolkit-2.6.1/debian/changelog 2016-08-20 09:51:41.0 -0400
@@ -1,3 +1,11 @@
+oath-toolkit (2.6.1-1.4) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * patch: fail gracefully for missing users (Closes: #807990)
+ * push to salsa
+
+ -- Antoine Beaupré Sat, 20 Aug 2016 09:51:41 -0400
+
oath-toolkit (2.6.1-1.3) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru oath-toolkit-2.6.1/debian/control oath-toolkit-2.6.1/debian/control
--- oath-toolkit-2.6.1/debian/control 2018-06-22 13:48:52.0 -0400
+++ oath-toolkit-2.6.1/debian/control 2016-08-20 09:51:41.0 -0400
@@ -6,8 +6,8 @@
Build-Depends: cdbs, debhelper (>= 7.0.0), libpam0g-dev, datefudge, gtk-doc-tools, dblatex, libxml2-utils, libxmlsec1-dev, dh-autoreconf
Standards-Version: 3.9.6
Homepage: http://www.nongnu.org/oath-toolkit/
-Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/oath-toolkit.git
-Vcs-Git: git://anonscm.debian.org/collab-maint/oath-toolkit.git
+Vcs-Browser: https://salsa.debian.org/debian/oath-toolkit
+Vcs-Git: https://salsa.debian.org/debian/oath-toolkit.git
Package: liboath-dev
Section: libdevel
diff -Nru oath-toolkit-2.6.1/debian/patches/0001-fail-gracefully-for-missing-users.patch oath-toolkit-2.6.1/debian/patches/0001-fail-gracefully-for-missing-users.patch
--- oath-toolkit-2.6.1/debian/patches/0001-fail-gracefully-for-missing-users.patch 1969-12-31 19:00:00.0 -0500
+++ oath-toolkit-2.6.1/debian/patches/0001-fail-gracefully-for-missing-users.patch 2016-08-20 09:51:41.0 -0400
@@ -0,0 +1,83 @@
+From 509c4cda7e08384d7cd16dfdb3917b4373f1e36e Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?=
+Date: Mon, 1 Aug 2016 12:25:10 -0400
+Subject: [PATCH] fail gracefully for missing users
+
+when the pam module is enabled, it forces *all* users to immediately
+start using OATH, or they can't login at all.
+
+a more progressive approach would seem more reasonable to me,
+especially since each user need to get an admin user to update the
+central file for them.
+
+this patch adds an early check to the users file and makes sure the
+user exists before prompting for a password.
+
+if the user is missing, it exits early with a standard error code
+(PAM_USER_UNKNOWN) which can then be ignored in the PAM configuration
+(as shown in the README file). this leaves the policy decision up to
+the admin (and defaults to "fail closed").
+
+if the user is present, the code path remains the same except the
+usersfile is scanned twice, which may be a performance penalty on very
+slow filesystems or very large files. the only workaround I can think
+of for this would be to load the whole file into memory, but this
+could have significant memory impact on large files.
+
+the function used (`oath_authenticate_usersfile`) is a little overkill
+as it actually goes and tries to authenticate the user with an empty
+password. this is harmless because the file isn't updated if the OTP
+is incorrect and because no warning is sent to syslog.
+
+a possible improvement on this would be to have a warning shown to the
+user inciting them to configure OATH or to warn them about a possible
+typo in their username before they enter their regular passphrase
+---
+ pam_oath/README | 2 +-
+ pam_oath/pam_oath.c | 17 +
+ 2 files changed, 18 insertions(+), 1 deletion(-)
+
+diff --git a/pam_oath/README b/pam_oath/README
+index bef4265..24b9f8b 100644
+--- a/pam_oath/README
b/pam_oath/README
+@@ -23,7 +23,7 @@ window open before making any changes!
+
+ -
+ # head -1 /etc/pam.d/su
+-auth requisite pam_oath.so debug usersfile=/etc/users.oath window=20
++auth [user_unknown=ignore success=ok] pam_oath.so debug usersfile=/etc/users.oath window=20
+ #
+ -
+
+diff --git a/pam_oath/pam_oath.c b/pam_oath/pam_oath.c
+index 2820318..25a3452 100644
+--- a/pam_oath/pam_oath.c
b/pam_oath/pam_oath.c
+@@ -162,6 +162,23 @@ pam_sm_authenticate (pam_handle_t * pamh,
+ }
+ DBG (("get user returned: %s", user));
+
++ // quick check to skip unconfigured users before prompting for password
++ {
++time_t last_otp;
++otp[0] = '\0';
++rc = oath_authenticate_usersfile (cfg.usersfile,
++ user,
++ otp, cfg.window, onlypasswd, &last_otp);
++
++DBG (("authenticate first pass rc %d (%s: %s) last otp %s", rc,
++ oath_strerror_name (rc) ? oath_strerror_name (rc) : "UNKNOWN",
++ oath_strerror (rc), ctime (&last_otp)));
++if (rc == OATH_UNKNOWN_USER)
++ {
++return PAM_USER_UNKN
Bug#930440: RFP: podman -- Library and tool for running OCI-based containers in Pods
Control: tags -1 +pending On Wed, Jun 12, 2019 at 08:26:22PM +0200, Varac wrote: > * Package name: podman I just want to mention that it seems podman has entered NEW: https://ftp-master.debian.org/new/libpod_1.6.4+dfsg-1.html The last dependency that was missing (#948113) is also waiting there: https://ftp-master.debian.org/new/golang-github-checkpoint-restore-go-criu_3.11-1.html This is great news! Can't wait to see this awesome project available in Debian... Congratulations to everyone on all their hard work. Let's hope this can converge on a good, standard set of packages that will satisfy everyone involved! I, for one, will look at replacing Docker with podman in the near future on my infrastructure. :) A. signature.asc Description: PGP signature
Bug#944986: ITP: emacs-wgrep -- edit multiple files simultaneously in Emacs using grep buffers--pattern editing
On Sun, Nov 17, 2019 at 07:39:49PM -0500, Nicholas D Steeves wrote: > Package: wnpp > Severity: wishlist > Owner: Nicholas D Steeves > Control: tag + moreinfo > > Package name: emacs-wgrep > Version : 2.3.0 > Upstream Author : Masahiro Hayashi > URL : https://github.com/mhayashi1120/Emacs-wgrep > License : GPL-3+ > Programming Lang: Emacs LISP > Description : edit multiple files simultaneously in Emacs using grep > buffers--pattern editing I heard through the grapevine (#debian-til, specifically) that there's a similar project for the silver searcher (ag): https://github.com/syohex/emacs-helm-ag a. -- The individual has always had to struggle to keep from being overwhelmed by the tribe. If you try it, you will be lonely often, and sometimes frightened. But no price is too high to pay for the privilege of owning yourself.- Friedrich Nietzsche
Bug#936043: ITP: gitbatch -- Manage git repositories in one place
On Thu, Aug 29, 2019 at 01:28:57PM +0200, Dawid Dziurla wrote: > Managing multiple git repositories is easier than ever. Often one would end > up working on many directories and manually pulling updates etc. To make > this routine faster, gitbatch was created, a simple tool to handle this job. > Although the focus is batch jobs, one can still do de facto micro management > of > git repositories (e.g add/reset, stash, commit etc.) > > Useful tool for managing multiple git repositiories at once. > Does not need additional dependencies, only those already in archive. Oh. My. God. This looks gorgeous. Do you need any help? On Thu, Aug 29, 2019 at 03:23:23PM +, Dmitry Bogatov wrote: > Sounds like `myrepos'. What `gitbatch' does that is not possible with > `myrepos'? On Thu, Aug 29, 2019 at 09:36:01AM -0700, Don Armstrong wrote: > It would be interesting to know how gitbatch compares to myrepos, as > they seem to be operating in the same or similar spaces. On Fri, Aug 30, 2019 at 12:54:43AM +0100, Ben Hutchings wrote: > We already have "mr", which can do this for git and several other > version control systems. Does gitbatch offer anything new? Did you look at the website? Did you look at the demo? Just look at it! https://asciinema.org/a/lxoZT6Z8fSliIEebWSPVIY8ct This thing looks AWESOME! Don't get me wrong: I've been using myrepos for years now and I'm a fan. But gitbatch just blew my mind: it does all that mr does, but interactively, and with a new TUI! Can't wait to see that land. A. -- Ou bien Dieu voudrait supprimer le mal, mais il ne le peut pas Ou bien Dieu pourrait supprimer le mal, mais il ne le veut pas. - Sébastien Faure signature.asc Description: PGP signature
Bug#942114: ganeti-instance-debootstrap: diff for NMU version 0.16-6.1
Control: tags 942114 + pending
Dear maintainer,
I've prepared an NMU for ganeti-instance-debootstrap (versioned as 0.16-6.1) and
uploaded it to DELAYED/02. Please feel free to tell me if I
should delay it longer.
Regards.
diff -Nru ganeti-instance-debootstrap-0.16/debian/changelog ganeti-instance-debootstrap-0.16/debian/changelog
--- ganeti-instance-debootstrap-0.16/debian/changelog 2018-06-20 06:57:18.0 -0400
+++ ganeti-instance-debootstrap-0.16/debian/changelog 2019-11-01 19:01:50.0 -0400
@@ -1,3 +1,10 @@
+ganeti-instance-debootstrap (0.16-6.1) unstable; urgency=medium
+
+ * Non-maintainer upload
+ * add patch to respect linux caps (Closes: #942114)
+
+ -- Antoine Beaupré Fri, 01 Nov 2019 19:01:50 -0400
+
ganeti-instance-debootstrap (0.16-6) unstable; urgency=medium
* Bump Standards-Version to 4.1.4; no changes needed
diff -Nru ganeti-instance-debootstrap-0.16/debian/patches/respect-Linux-capabilities-7-in-cache.patch ganeti-instance-debootstrap-0.16/debian/patches/respect-Linux-capabilities-7-in-cache.patch
--- ganeti-instance-debootstrap-0.16/debian/patches/respect-Linux-capabilities-7-in-cache.patch 1969-12-31 19:00:00.0 -0500
+++ ganeti-instance-debootstrap-0.16/debian/patches/respect-Linux-capabilities-7-in-cache.patch 2019-11-01 19:01:50.0 -0400
@@ -0,0 +1,48 @@
+From cd34bcc48a2af92f484535b81fba2d46dad1dbb6 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?=
+Date: Thu, 10 Oct 2019 11:07:51 -0400
+Subject: [PATCH] respect Linux capabilities(7) in cache
+
+The default GNU tar configuration does not carry fancy extended
+attributes and that is where, among other things, stuff like Linux
+capabilities(7) are stored. This is kind of important because that's
+how ping(8) works for regular users.
+
+We shove --selinux and --acls in there while we're at it, because why
+not. We never know what the future might bring, and it seems
+silly *not* to create a complete archive.
+
+Note that --xattrs-include='*' is important because, by default, GNU
+tar will not include capabilities /even/ if --xattrs is specified on
+the commandline, see this bug report for details:
+
+https://bugzilla.redhat.com/show_bug.cgi?id=771927
+---
+ create | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/create b/create
+index 607bab2..7526e71 100755
+--- a/create
b/create
+@@ -83,7 +83,7 @@ if [ "$CLEAN_CACHE" -a -d "$CACHE_DIR" ]; then
+ fi
+
+ if [ -f "$CACHE_FILE" ]; then
+- tar xf "$CACHE_FILE" -C $TMPDIR
++ tar --acls --selinux --xattrs --xattrs-include='*' -x -f "$CACHE_FILE" -C $TMPDIR
+ else
+ if [ "$PROXY" ]; then
+ export http_proxy="$PROXY"
+@@ -109,7 +109,7 @@ else
+
+ if [ "$GENERATE_CACHE" = "yes" ]; then
+ TMP_CACHE=`mktemp "${CACHE_FILE}.XX"`
+-tar cf "$TMP_CACHE" -C $TMPDIR .
++tar --acls --selinux --xattrs --xattrs-include='*' -c -f "$TMP_CACHE" -C $TMPDIR .
+ mv -f "$TMP_CACHE" "$CACHE_FILE"
+ fi
+ fi
+--
+2.20.1
+
diff -Nru ganeti-instance-debootstrap-0.16/debian/patches/series ganeti-instance-debootstrap-0.16/debian/patches/series
--- ganeti-instance-debootstrap-0.16/debian/patches/series 2018-06-20 06:57:18.0 -0400
+++ ganeti-instance-debootstrap-0.16/debian/patches/series 2019-11-01 19:01:50.0 -0400
@@ -1 +1,2 @@
+respect-Linux-capabilities-7-in-cache.patch
fix-sfdisk-BLKRRPART.patch
signature.asc
Description: PGP signature
Bug#941638: docopt: diff for NMU version 0.6.2-2.1
Control: tags 941638 + pending
Dear maintainer,
I've prepared an NMU for docopt (versioned as 0.6.2-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
Regards.
diff -Nru docopt-0.6.2/debian/changelog docopt-0.6.2/debian/changelog
--- docopt-0.6.2/debian/changelog 2018-08-17 10:16:51.0 -0400
+++ docopt-0.6.2/debian/changelog 2019-10-11 00:57:20.0 -0400
@@ -1,3 +1,16 @@
+docopt (0.6.2-2.1) unstable; urgency=medium
+
+ [ Matthias Klose ]
+ * Don't run the Python2 autopkg tests. python-schema is gone.
+
+ [ Ondřej Nový ]
+ * d/copyright: Use https protocol in Format field
+
+ [ Antoine Beaupré ]
+ * Non-maintainer upload to ship Klose's patch (Closes: #941638)
+
+ -- Antoine Beaupré Fri, 11 Oct 2019 00:57:20 -0400
+
docopt (0.6.2-2) unstable; urgency=medium
* [d/control] Remove obsolete X-Python-Version
diff -Nru docopt-0.6.2/debian/copyright docopt-0.6.2/debian/copyright
--- docopt-0.6.2/debian/copyright 2018-08-17 10:16:51.0 -0400
+++ docopt-0.6.2/debian/copyright 2019-10-11 00:57:20.0 -0400
@@ -1,4 +1,4 @@
-Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: docopt
Upstream-Contact: Vladimir Keleshev
Source: https://github.com/docopt/docopt
diff -Nru docopt-0.6.2/debian/gitlab-ci.yml docopt-0.6.2/debian/gitlab-ci.yml
--- docopt-0.6.2/debian/gitlab-ci.yml 2018-08-17 10:16:51.0 -0400
+++ docopt-0.6.2/debian/gitlab-ci.yml 2019-10-11 00:57:20.0 -0400
@@ -1,71 +1,16 @@
-# Warning! This file is autogenerated by salsa pipeline bot. Any change made
-# over this document will be lost. Customization and changes must be made over
-# the template yaml.
-variables:
- DEBFULLNAME: "Salsa Pipeline"
- DEBEMAIL: ""
- DEBIAN_FRONTEND: noninteractive
- WORKING_DIR: ./debian/output
+include: https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
-stages:
- - build
- - test
+build:
+extends: .build-unstable
-image: debian:unstable
+reprotest:
+extends: .test-reprotest
-build package:
- stage: build
- image: registry.salsa.debian.org/salsa-ci-team/images/gbp
- artifacts:
-expire_in: 180 day
-name: "$CI_BUILD_NAME"
-paths:
-- ${WORKING_DIR}/
- script:
-- apt-get update
-- eatmydata apt-get build-dep -y .
-- gbp pull --ignore-branch
-- gbp buildpackage --git-ignore-branch --git-export-dir=${WORKING_DIR} -us -uc
+lintian:
+extends: .test-lintian
-run autopkgtest:
- stage: test
- image: registry.salsa.debian.org/salsa-ci-team/images/autopkgtest
- script:
-- eatmydata autopkgtest -U ${WORKING_DIR}/*.deb -- null
+autopkgtest:
+extends: .test-autopkgtest
-run lintian:
- stage: test
- image: registry.salsa.debian.org/salsa-ci-team/images/lintian
- script:
-- lintian -iI ${WORKING_DIR}/*.changes
-
-run reprotest:
- stage: test
- image: registry.salsa.debian.org/salsa-ci-team/images/reprotest
- artifacts:
-name: "$CI_BUILD_NAME"
-expire_in: 180 day
-paths:
- - ./reprotest.log
-when: always
- script:
-- apt-get update
-- eatmydata apt-get build-dep -y .
-- export DEB_BUILD_OPTIONS=nocheck
-- eatmydata reprotest . -- null &> reprotest.log
-
-run piuparts:
- stage: test
- image: registry.salsa.debian.org/salsa-ci-team/images/piuparts
- services:
-- docker:dind
- script:
-- CHROOT_PATH=/tmp/debian-unstable
-- CONTAINER_ID=$(docker run --rm -d debian:unstable sleep infinity)
-- docker exec ${CONTAINER_ID} bash -c "apt-get update && apt-get install eatmydata -y"
-- mkdir -p ${CHROOT_PATH}
-- docker export ${CONTAINER_ID} | tar -C ${CHROOT_PATH} -xf -
-- mknod -m 666 ${CHROOT_PATH}/dev/urandom c 1 9
-- piuparts --hard-link -e ${CHROOT_PATH} ${WORKING_DIR}/*.deb
-# End of include
- Below starts the local customization ###
+piuparts:
+extends: .test-piuparts
diff -Nru docopt-0.6.2/debian/gitlab-ci.yml.tpl docopt-0.6.2/debian/gitlab-ci.yml.tpl
--- docopt-0.6.2/debian/gitlab-ci.yml.tpl 2018-08-17 10:16:51.0 -0400
+++ docopt-0.6.2/debian/gitlab-ci.yml.tpl 1969-12-31 19:00:00.0 -0500
@@ -1,3 +0,0 @@
-include: https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
-
-# end of salsa pipeline bot parser
diff -Nru docopt-0.6.2/debian/tests/control docopt-0.6.2/debian/tests/control
--- docopt-0.6.2/debian/tests/control 2018-08-17 10:16:51.0 -0400
+++ docopt-0.6.2/debian/tests/control 2019-10-11 00:57:20.0 -0400
@@ -2,5 +2,3 @@
Depends: @,
python3-pytest,
python3-schema,
- python-pytest,
- python-schema,
diff -Nru docopt-0.6.2/debian/tests/run_examples docopt-0.6.2/debian/tests/run_examples
--- docopt-0.6.2/debian/tests/run_examples 2018-08-17 10:16:51.0 -0400
+++ docopt-0.6.2/debian/tests/run_examples 2019-10-11 00:57:20.
Bug#930080: solarized-emacs: diff for NMU version 1.3.0-0.1~exp0
Package: solarized-emacs Version: 1.2.2-4 Severity: normal Tags: patch pending Dear maintainer, I've prepared an NMU for solarized-emacs (versioned as 1.3.0-0.1~exp0) and uploaded it to DELAYED/10. Please feel free to tell me if I should delay it longer. Regards. -- diff -Nru solarized-emacs-1.2.2/child-theme-example/themes/my-solarized-dark-theme.el solarized-emacs-1.3.0/child-theme-example/themes/my-solarized-dark-theme.el --- solarized-emacs-1.2.2/child-theme-example/themes/my-solarized-dark-theme.el 2015-07-06 13:28:07.0 -0400 +++ solarized-emacs-1.3.0/child-theme-example/themes/my-solarized-dark-theme.el 2019-06-06 11:20:58.0 -0400 @@ -3,7 +3,7 @@ ;; This files needs to be places iside the custom-theme-load-path list -(deftheme my-solarized-dark "The light variant of the Solarized colour theme") +(deftheme my-solarized-dark "The dark variant of the Solarized colour theme") (create-solarized-theme 'dark 'my-solarized-dark 'my-solarized-theme) (provide-theme 'my-solarized-dark) diff -Nru solarized-emacs-1.2.2/debian/changelog solarized-emacs-1.3.0/debian/changelog --- solarized-emacs-1.2.2/debian/changelog 2019-02-02 04:46:04.0 -0500 +++ solarized-emacs-1.3.0/debian/changelog 2019-06-06 11:21:07.0 -0400 @@ -1,3 +1,10 @@ +solarized-emacs (1.3.0-0.1~exp0) experimental; urgency=medium + + * Non-maintainer upload. + * New upstream release. + + -- Antoine Beaupré Thu, 06 Jun 2019 11:21:07 -0400 + solarized-emacs (1.2.2-4) unstable; urgency=medium * Migrate to dh 12 diff -Nru solarized-emacs-1.2.2/debian/patches/0001-remove-badges.diff solarized-emacs-1.3.0/debian/patches/0001-remove-badges.diff --- solarized-emacs-1.2.2/debian/patches/0001-remove-badges.diff 2019-02-02 04:46:04.0 -0500 +++ solarized-emacs-1.3.0/debian/patches/0001-remove-badges.diff 2019-06-06 11:21:07.0 -0400 @@ -4,14 +4,16 @@ This patch removes badges icons from README files. These icons are intended rather for developers and are loaded from several external web sites. a/README.md -+++ b/README.md +Index: b/README.md +=== +--- a/README.md 2019-06-06 11:22:15.534788629 -0400 b/README.md 2019-06-06 11:22:29.978725995 -0400 @@ -1,8 +1,3 @@ -[![License GPL 3][badge-license]](http://www.gnu.org/licenses/gpl-3.0.txt) -[](http://melpa.org/#/solarized-theme) -[](http://stable.melpa.org/#/solarized-theme) -[](https://gitter.im/bbatsov/solarized-emacs?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge) - - ## Solarized for Emacs + # Solarized for Emacs Solarized for Emacs is an Emacs port of the [Solarized theme for vim](http://ethanschoonover.com/solarized), diff -Nru solarized-emacs-1.2.2/debian/patches/0002-remove-dependency-on-dash-elpa-package.diff solarized-emacs-1.3.0/debian/patches/0002-remove-dependency-on-dash-elpa-package.diff --- solarized-emacs-1.2.2/debian/patches/0002-remove-dependency-on-dash-elpa-package.diff 2019-02-02 04:46:04.0 -0500 +++ solarized-emacs-1.3.0/debian/patches/0002-remove-dependency-on-dash-elpa-package.diff 1969-12-31 19:00:00.0 -0500 @@ -1,14 +0,0 @@ -From: Lev Lamberov -Subject: Remove dependency on dash.el - -This patch removes dependency on dash.el, since that package is not yet known -to elpa. - a/solarized-theme-pkg.el -+++ b/solarized-theme-pkg.el -@@ -2,4 +2,4 @@ - "solarized-theme" - "1.2.2" - "The Solarized color theme, ported to Emacs." -- '((dash "2.6.0"))) -+ '()) diff -Nru solarized-emacs-1.2.2/debian/patches/series solarized-emacs-1.3.0/debian/patches/series --- solarized-emacs-1.2.2/debian/patches/series 2019-02-02 04:46:04.0 -0500 +++ solarized-emacs-1.3.0/debian/patches/series 2019-06-06 11:21:07.0 -0400 @@ -1,2 +1 @@ 0001-remove-badges.diff -0002-remove-dependency-on-dash-elpa-package.diff diff -Nru solarized-emacs-1.2.2/.gitignore solarized-emacs-1.3.0/.gitignore --- solarized-emacs-1.2.2/.gitignore 1969-12-31 19:00:00.0 -0500 +++ solarized-emacs-1.3.0/.gitignore 2019-06-06 11:20:58.0 -0400 @@ -0,0 +1 @@ +*.elc diff -Nru solarized-emacs-1.2.2/README.md solarized-emacs-1.3.0/README.md --- solarized-emacs-1.2.2/README.md 2015-07-06 13:28:07.0 -0400 +++ solarized-emacs-1.3.0/README.md 2019-06-06 11:20:58.0 -0400 @@ -3,11 +3,13 @@ [](http://stable.melpa.org/#/solarized-theme) [](https://gitter.im/bbatsov/solarized-emacs?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge) -## Solarized for Emacs +# Solari
Bug#887750: pam-python: diff for NMU version 1.0.6-1.1
Dear maintainer,
I've prepared an NMU for pam-python (versioned as 1.0.6-1.1) and
uploaded it to DELAYED/0. Please feel free to tell me if I
should delay it longer.
Regards.
--
diff -Nru pam-python-1.0.6/debian/changelog pam-python-1.0.6/debian/changelog
--- pam-python-1.0.6/debian/changelog 2016-08-27 07:37:03.0 -0400
+++ pam-python-1.0.6/debian/changelog 2019-01-19 15:14:26.0 -0500
@@ -1,3 +1,11 @@
+pam-python (1.0.6-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix build with glibc 2.26, thanks to Adrian Bunk (Closes: #887750).
+ * Fix build with GCC 8
+
+ -- Antoine Beaupré Sat, 19 Jan 2019 15:14:26 -0500
+
pam-python (1.0.6-1) unstable; urgency=low
* New upstream.
diff -Nru pam-python-1.0.6/debian/patches/fix-function-types.patch pam-python-1.0.6/debian/patches/fix-function-types.patch
--- pam-python-1.0.6/debian/patches/fix-function-types.patch 1969-12-31 19:00:00.0 -0500
+++ pam-python-1.0.6/debian/patches/fix-function-types.patch 2019-01-19 15:14:26.0 -0500
@@ -0,0 +1,96 @@
+From 12869142411f7a85d438971792cd75095f140f28 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?=
+Date: Sat, 19 Jan 2019 16:00:52 -0500
+Subject: [PATCH] fix build with -Wcast-function-type -Werror on gcc8
+
+New versions of gcc8 will fail to build from source on Python
+declarations because of the hairy cast we're doing there, example:
+
+pam_python.c:1355:19: error: cast between incompatible function types from 'PyObject * (*)(PyObject *, PyObject *, PyObject *)' {aka 'struct _object * (*)(struct _object *, struct _object *, struct _object *)'} to 'PyObject * (*)(PyObject *, PyObject *)' {aka 'struct _object * (*)(struct _object *, struct _object *)'} [-Werror=cast-function-type]
+
+This fix comes form the upstream cpython implementation:
+
+https://github.com/python/cpython/commit/62be74290aca26d16f3f55ece7ff6dad14e60e8d#diff-c3cf251f16d5a03a9e7d4639f2d6f998
+---
+ src/pam_python.c | 30 +++---
+ 1 file changed, 15 insertions(+), 15 deletions(-)
+
+diff --git a/src/pam_python.c b/src/pam_python.c
+index e01ee68..654f0aa 100644
+--- a/src/pam_python.c
b/src/pam_python.c
+@@ -317,7 +317,7 @@ static PyMethodDef SyslogFile_Methods[] =
+ {
+ {
+ "write",
+-(PyCFunction)SyslogFile_write,
++(PyCFunction)(void(*)(void))SyslogFile_write,
+ METH_VARARGS|METH_KEYWORDS,
+ 0
+ },
+@@ -1349,16 +1349,16 @@ static PyObject* PamEnv_values(
+
+ static PyMethodDef PamEnv_Methods[] =
+ {
+- {"__contains__", (PyCFunction)PamEnv_has_key,METH_VARARGS|METH_KEYWORDS, 0},
+- {"__getitem__", (PyCFunction)PamEnv_getitem,METH_VARARGS|METH_KEYWORDS, 0},
+- {"get", (PyCFunction)PamEnv_get, METH_VARARGS|METH_KEYWORDS, 0},
+- {"has_key", (PyCFunction)PamEnv_has_key,METH_VARARGS|METH_KEYWORDS, 0},
+- {"items", (PyCFunction)PamEnv_items, METH_VARARGS|METH_KEYWORDS, 0},
+- {"iteritems", (PyCFunction)PamEnv_iteritems,METH_VARARGS|METH_KEYWORDS, 0},
+- {"iterkeys", (PyCFunction)PamEnv_iterkeys,METH_VARARGS|METH_KEYWORDS, 0},
+- {"itervalues",(PyCFunction)PamEnv_itervalues,METH_VARARGS|METH_KEYWORDS, 0},
+- {"keys", (PyCFunction)PamEnv_keys, METH_VARARGS|METH_KEYWORDS, 0},
+- {"values", (PyCFunction)PamEnv_values, METH_VARARGS|METH_KEYWORDS, 0},
++ {"__contains__", (PyCFunction)(void(*)(void))PamEnv_has_key,METH_VARARGS|METH_KEYWORDS, 0},
++ {"__getitem__", (PyCFunction)(void(*)(void))PamEnv_getitem,METH_VARARGS|METH_KEYWORDS, 0},
++ {"get", (PyCFunction)(void(*)(void))PamEnv_get, METH_VARARGS|METH_KEYWORDS, 0},
++ {"has_key", (PyCFunction)(void(*)(void))PamEnv_has_key,METH_VARARGS|METH_KEYWORDS, 0},
++ {"items", (PyCFunction)(void(*)(void))PamEnv_items, METH_VARARGS|METH_KEYWORDS, 0},
++ {"iteritems", (PyCFunction)(void(*)(void))PamEnv_iteritems,METH_VARARGS|METH_KEYWORDS, 0},
++ {"iterkeys", (PyCFunction)(void(*)(void))PamEnv_iterkeys,METH_VARARGS|METH_KEYWORDS, 0},
++ {"itervalues",(PyCFunction)(void(*)(void))PamEnv_itervalues,METH_VARARGS|METH_KEYWORDS, 0},
++ {"keys", (PyCFunction)(void(*)(void))PamEnv_keys, METH_VARARGS|METH_KEYWORDS, 0},
++ {"values", (PyCFunction)(void(*)(void))PamEnv_values, METH_VARARGS|METH_KEYWORDS, 0},
+ {0,0,0,0} /* Sentinel */
+ };
+
+@@ -2029,7 +2029,7 @@ static PyMethodDef PamHandle_Methods[] =
+ {
+ {
+ "conversation",
+-(PyCFunction)PamHandle_conversation,
++(PyCFunction)(void(*)(void))PamHandle_conversation,
+ METH_VARARGS|METH_KEYWORDS,
+ MODULE_NAME "." PAMHANDLE_NAME "." "conversation(prompts)\n"
+ " Ask the application to issue the prompts to the user and return the\n"
+@@ -2039,7 +2039,7 @@ static PyMethodDef PamHandle_Methods[] =
+ },
+ {
+ "fail_delay",
+-(PyCFunction)PamHandle_fail_delay,
++(PyCFunction)(void(*)(void))PamHandle_fail_delay,
+ METH_VARARGS|METH_KEYWORDS,
+ MODULE_NAME "." PAMHANDLE_NAME "." "fail_delay(micro_sec)\n"
+
Bug#917492: fam: diff for NMU version 2.7.0-17.3
Control: tags 917492 + pending
Dear maintainer,
I've prepared an NMU for fam (versioned as 2.7.0-17.3) and
uploaded it to DELAYED/0. Please feel free to tell me if I
should delay it longer.
Regards.
--
diff -u fam-2.7.0/debian/changelog fam-2.7.0/debian/changelog
--- fam-2.7.0/debian/changelog
+++ fam-2.7.0/debian/changelog
@@ -1,3 +1,11 @@
+fam (2.7.0-17.3) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * Fix build failure with recent glibc ('minor' was not declared in this
+scope), thanks to Logan Rosen (Closes: #917492).
+
+ -- Antoine Beaupré Sat, 19 Jan 2019 13:58:08 -0500
+
fam (2.7.0-17.2) unstable; urgency=medium
* Non-maintainer upload.
only in patch2:
unchanged:
--- fam-2.7.0.orig/.pc/.quilt_patches
+++ fam-2.7.0/.pc/.quilt_patches
@@ -0,0 +1 @@
+debian/patches
only in patch2:
unchanged:
--- fam-2.7.0.orig/.pc/.quilt_series
+++ fam-2.7.0/.pc/.quilt_series
@@ -0,0 +1 @@
+series
only in patch2:
unchanged:
--- fam-2.7.0.orig/.pc/.version
+++ fam-2.7.0/.pc/.version
@@ -0,0 +1 @@
+2
only in patch2:
unchanged:
--- fam-2.7.0.orig/debian/patches/19_glibc_2.28.patch
+++ fam-2.7.0/debian/patches/19_glibc_2.28.patch
@@ -0,0 +1,17 @@
+## Description: Fix FTBFS against glibc 2.28
+## Origin/Author: Logan Rosen
+## Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917492
+diff -Nur -x '*.orig' -x '*~' fam-2.7.0/build-tree/fam-2.7.0/src/DNotify.c++ fam-2.7.0.new/build-tree/fam-2.7.0/src/DNotify.c++
+--- fam-2.7.0/src/DNotify.c++ 2019-01-08 23:35:20.513574095 -0500
fam-2.7.0/src/DNotify.c++ 2019-01-08 23:36:37.568605429 -0500
+@@ -36,6 +36,10 @@
+ #include
+ #include
+
++#ifdef __GNU_LIBRARY__
++#include
++#endif
++
+ #include "DNotify.h"
+
+ #include "Interest.h"
signature.asc
Description: PGP signature
Bug#919217: Acknowledgement (Missing dependency on devscripts)
tags 919217 +pendingo user debian-rele...@lists.debian.org usertag 919217 + bsp-2019-01-ca-montreal thanks On Mon, Jan 14, 2019 at 09:27:08PM +0100, Jeroen Dekkers wrote: > Control: tag -1 +patch > > https://salsa.debian.org/jelmer/lintian-brush/merge_requests/1 That MR was accepted and jelmer will upload the package this weekend. A.
Bug#903698: sphinxbase: build appears broken for multiple python3 versions
user debian-rele...@lists.debian.org usertag nn + bsp-2019-01-ca-montreal tags -1 -patch +moreinfo thank you On Thu, Jan 03, 2019 at 10:16:13AM +0100, Samuel Thibault wrote: > Oops, this bug was erroneously closed because its mention was remaining > in the sphinxbase changelog. So after reviewing this bug during the montreal BSP, I'm a little confused - it shows up in the "sponsor" UDD dashboard because it's marked as affecting buster and sid but with a patch. Yet, I don't see a recent patch that will fix the issue in dh-python. I'm not even sure there *is* an issue in dh-python at all anymore... Could someone summarize the current state of this bug report? Thanks! -- Be yourself. Everyone else is already taken! - Oscar Wilde signature.asc Description: PGP signature
Bug#915307: magic-wormhole FTBFS with Python 3.7
Control: fixed 915307 0.11.2-1 I believe the latest upstream release fixes that, or at least it compiles here in a sid schroot with py 3.7. I meant to fix this in the changelog but forgot about it before doing the upload... :/ Thanks for the heads up though! signature.asc Description: PGP signature
Bug#880220: Fixed in upload
Control: found 880220 2017.11.24~bpo9+1 I have version 2017.11.24~bpo9+1 installed here, and the global trust anchor is still installed. # dpkg -L leap-archive-keyring | grep trusted.gpg.d/ /etc/apt/trusted.gpg.d/leap-archive.gpg /etc/apt/trusted.gpg.d/leap-experimental-archive.gpg So this bug has not correctly been fixed, or a regression was introduced. A. On Wed, Nov 08, 2017 at 09:16:20AM -0500, micah anderson wrote: > Version: 2007.11.08 > thanks > > This issue was resolved in the most recent upload, > micah -- Either you're with us or you're with the terrorist state. signature.asc Description: PGP signature
Bug#807866: RFP: github-hub -- hub helps you win at git
Control: unblock 807866 by 819936 On Mon, Aug 22, 2016 at 11:13:05AM +1200, Olly Betts wrote: > So it looks like it's just github.com/octokit/go-octokit/octokit that is > needed now (ITP is https://bugs.debian.org/819936 so marking that bug as > blocking this, and Cc-ing the owner of that ITP so they're aware). And that dependency was now removed. So what's blocking packaging now? It would be pretty awesome to have this in Debian! I use this every day... a. signature.asc Description: PGP signature
Bug#889281: dokuwiki: CVE-2017-18123: reflected file download vulnerability
Hi,
I have tested an update of the jessie package and things seem to work
fine after merging the patch from upstream during a smoketest of a clean
jessie VM.
Attached is the debdiff to complete the update.
A.
diff -Nru dokuwiki-0.0.20140505.a+dfsg/debian/changelog
dokuwiki-0.0.20140505.a+dfsg/debian/changelog
--- dokuwiki-0.0.20140505.a+dfsg/debian/changelog 2015-03-22
13:50:07.0 -0400
+++ dokuwiki-0.0.20140505.a+dfsg/debian/changelog 2018-06-07
15:25:55.0 -0400
@@ -1,3 +1,11 @@
+dokuwiki (0.0.20140505.a+dfsg-4+deb8u1) jessie-security; urgency=high
+
+ * Non-maintainer upload by the Security Team.
+ * CVE-2017-18123: fix remote code execution through reflected file
+download
+
+ -- Antoine Beaupré Thu, 07 Jun 2018 15:25:55 -0400
+
dokuwiki (0.0.20140505.a+dfsg-4) testing-proposed-updates; urgency=high
* debian/patches: security fix, from upstream hotfix release
diff -Nru
dokuwiki-0.0.20140505.a+dfsg/debian/patches/CVE-2017-18123-2f65d86.patch
dokuwiki-0.0.20140505.a+dfsg/debian/patches/CVE-2017-18123-2f65d86.patch
--- dokuwiki-0.0.20140505.a+dfsg/debian/patches/CVE-2017-18123-2f65d86.patch
1969-12-31 19:00:00.0 -0500
+++ dokuwiki-0.0.20140505.a+dfsg/debian/patches/CVE-2017-18123-2f65d86.patch
2018-06-07 15:25:35.0 -0400
@@ -0,0 +1,25 @@
+From 238b8e878ad48f370903465192b57c2072f65d86 Mon Sep 17 00:00:00 2001
+From: Andreas Gohr
+Date: Tue, 27 Jun 2017 15:04:23 +0200
+Subject: [PATCH] filter special chars from ajax call parameter. fixes #2019
+
+---
+ lib/exe/ajax.php | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/lib/exe/ajax.php b/lib/exe/ajax.php
+index b3e9a618f5..9f9db5391a 100644
+--- a/lib/exe/ajax.php
b/lib/exe/ajax.php
+@@ -15,9 +15,9 @@
+
+ //call the requested function
+ if($INPUT->post->has('call')){
+-$call = $INPUT->post->str('call');
++$call = $INPUT->post->filter('utf8_stripspecials')->str('call');
+ }else if($INPUT->get->has('call')){
+-$call = $INPUT->get->str('call');
++$call = $INPUT->get->filter('utf8_stripspecials')->str('call');
+ }else{
+ exit;
+ }
diff -Nru dokuwiki-0.0.20140505.a+dfsg/debian/patches/series
dokuwiki-0.0.20140505.a+dfsg/debian/patches/series
--- dokuwiki-0.0.20140505.a+dfsg/debian/patches/series 2015-03-22
13:48:40.0 -0400
+++ dokuwiki-0.0.20140505.a+dfsg/debian/patches/series 2018-06-07
15:25:35.0 -0400
@@ -5,3 +5,4 @@
soften_email_validator.diff
use_packaged_jquery.diff
cve-2015-2172_check_permissions_in_rpc.patch
+CVE-2017-18123-2f65d86.patch
signature.asc
Description: PGP signature
Bug#885699: smokeping: symbolic link to smokeping.cgi missing
Control: tags -1 +pending Control: severity -1 normal On Fri, Dec 29, 2017 at 10:48:43AM +0100, Sigbjorn Kjetland wrote: > Dear Maintainer, > >* What led up to the situation? > I am installing smokeping on a new server to replace old smokeping server > I have configured and restarted smokeping like in previous server > but web GUI did not work. Error was 403 forbidden. > fcgi not working and I have limited knowledge so i didn't go that route. >* What exactly did you do (or not do) that was effective (or > ineffective)? > I added these 3 lines to apache config file: > /etc/apache2/conf-enabled/smokeping.conf > Options Indexes FollowSymLinks ExecCGI > AddHandler cgi-script .cgi > DirectoryIndex index.html smokeping.cgi > > There was no working fcgi file and no cgi file so I linked the cgi as > below > > ln -s /usr/lib/cgi-bin/smokeping.cgi > /usr/share/smokeping/www/smokeping.cgi Hi! Sorry for the delays. This problem actually happens in earlier releases as well - it is expected you visit /smokeping/smokeping.cgi and not /smokeping/... Furthermore, this hardly is a release-critical bug, in my opinion, so I will downgrade this to normal. Still, it seems reasonable to have a DirectoryIndex. In our tests here (Debian stretch), it seems that just adding that line was sufficient to resolve the issue completely. This will be resolved in the next upload. Thanks for the bug report! A. signature.asc Description: PGP signature
Bug#705369: gnutls support broken in charybdis
GnuTLS support is still broken in charybdis. On irc.indymedia.org, we couldn't link servers with gnutls - we'd get all sorts of errors like "Read error: Error in the pull function". Our experience was documented here: https://we.riseup.net/ircd/outage-20170202 So I reopened this issue and marked unstable as affected. An upcoming upload should fix the issue by switching to the mbedtls backend, which behaved better (so far) in our tests. There's code in the debian/rules file to switch backends, as documented in debian/README.source. A.
Bug#860287: libosip2: CVE-2016-10324 CVE-2016-10325 CVE-2016-10326 CVE-2017-7853
Control: fixed -1 4.1.0-2.1 Control: tags -1 +pending I have made a NMU (diff in #860345) to fix this in sid/stretch, the patches apply fairly cleanly, and since it's the same version in jessie, it should be trivial to backport there... I forgot to mention the bug # in the NMU, unfortunately... A.
Bug#860345: libosip2: diff for NMU version 4.1.0-2.1
Package: libosip2
Version: 4.1.0-2
Severity: normal
Tags: patch pending
Dear maintainer,
I've prepared an NMU for libosip2 (versioned as 4.1.0-2.1) and
uploaded it to DELAYED/3. Please feel free to tell me if I
should delay it longer.
Regards.
--
diff -Nru libosip2-4.1.0/debian/changelog libosip2-4.1.0/debian/changelog
--- libosip2-4.1.0/debian/changelog 2014-06-25 07:55:15.0 -0400
+++ libosip2-4.1.0/debian/changelog 2017-04-14 16:23:31.0 -0400
@@ -1,3 +1,23 @@
+libosip2 (4.1.0-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * CVE-2016-10324: In libosip2 in GNU oSIP 4.1.0, a malformed SIP message
+can lead to a heap buffer overflow in the osip_clrncpy() function
+defined in osipparser2/osip_port.c.
+ * CVE-2016-10325: In libosip2 in GNU oSIP 4.1.0, a malformed SIP message
+can lead to a heap buffer overflow in the _osip_message_to_str()
+function defined in osipparser2/osip_message_to_str.c, resulting in a
+remote DoS.
+ * CVE-2016-10326: In libosip2 in GNU oSIP 4.1.0, a malformed SIP message
+can lead to a heap buffer overflow in the osip_body_to_str() function
+defined in osipparser2/osip_body.c, resulting in a remote DoS.
+ * CVE-2017-7853: In libosip2 in GNU oSIP 5.0.0, a malformed SIP message
+can lead to a heap buffer overflow in the msg_osip_body_parse()
+function defined in osipparser2/osip_message_parse.c, resulting in a
+remote DoS.
+
+ -- Antoine Beaupré Fri, 14 Apr 2017 16:21:21 -0400
+
libosip2 (4.1.0-2) unstable; urgency=low
* Upload to unstable - coordinated through debian-release
diff -Nru libosip2-4.1.0/debian/patches/CVE-2016-10324.patch libosip2-4.1.0/debian/patches/CVE-2016-10324.patch
--- libosip2-4.1.0/debian/patches/CVE-2016-10324.patch 1969-12-31 19:00:00.0 -0500
+++ libosip2-4.1.0/debian/patches/CVE-2016-10324.patch 2017-04-14 16:26:51.0 -0400
@@ -0,0 +1,24 @@
+From 7e0793e15e21f68337e130c67b031ca38edf055f Mon Sep 17 00:00:00 2001
+From: Aymeric Moizard
+Date: Mon, 5 Sep 2016 15:01:53 +0200
+Subject: * fix bug report: sr #109133: Heap buffer overflow in utility
+ function *osip_clrncpy*https://savannah.gnu.org/support/?109133
+
+---
+ src/osipparser2/osip_port.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/src/osipparser2/osip_port.c
b/src/osipparser2/osip_port.c
+@@ -1462,8 +1462,10 @@ osip_clrncpy (char *dst, const char *src
+ char *p;
+ size_t spaceless_length;
+
+- if (src == NULL)
++ if (src == NULL || len == 0) {
++*dst = '\0';
+ return NULL;
++ }
+
+ /* find the start of relevant text */
+ pbeg = src;
diff -Nru libosip2-4.1.0/debian/patches/CVE-2016-10325.patch libosip2-4.1.0/debian/patches/CVE-2016-10325.patch
--- libosip2-4.1.0/debian/patches/CVE-2016-10325.patch 1969-12-31 19:00:00.0 -0500
+++ libosip2-4.1.0/debian/patches/CVE-2016-10325.patch 2017-04-14 16:26:54.0 -0400
@@ -0,0 +1,26 @@
+From 1d9fb1d3a71cc85ef95352e549b140c706cf8696 Mon Sep 17 00:00:00 2001
+From: Aymeric Moizard
+Date: Sat, 3 Sep 2016 15:29:34 +0200
+Subject: * fix bug report: sr #109131: Heap buffer overflow in
+ `_osip_message_to_str` https://savannah.gnu.org/support/?109131
+
+---
+ src/osipparser2/osip_message_to_str.c | 7 +++
+ 1 file changed, 7 insertions(+)
+
+--- a/src/osipparser2/osip_message_to_str.c
b/src/osipparser2/osip_message_to_str.c
+@@ -378,6 +378,13 @@ _osip_message_to_str (osip_message_t * s
+ /* A start-line isn't required for message/sipfrag parts. */
+ }
+ else {
++size_t message_len = strlen(tmp);
++if (_osip_message_realloc (&message, dest, message_len + 3, &malloc_size) < 0) {
++ osip_free (tmp);
++ *dest = NULL;
++ return OSIP_NOMEM;
++}
++
+ message = osip_str_append (message, tmp);
+ osip_free (tmp);
+ message = osip_strn_append (message, CRLF, 2);
diff -Nru libosip2-4.1.0/debian/patches/CVE-2016-10326.patch libosip2-4.1.0/debian/patches/CVE-2016-10326.patch
--- libosip2-4.1.0/debian/patches/CVE-2016-10326.patch 1969-12-31 19:00:00.0 -0500
+++ libosip2-4.1.0/debian/patches/CVE-2016-10326.patch 2017-04-14 16:26:56.0 -0400
@@ -0,0 +1,27 @@
+From b9dd097b5b24f5ee54b0a8739e59641cd51b6ead Mon Sep 17 00:00:00 2001
+From: Aymeric Moizard
+Date: Sat, 3 Sep 2016 15:58:06 +0200
+Subject: * fix bug report: sr #109132: Heap buffer overflow in
+ *osip_body_to_str*https://savannah.gnu.org/support/index.php?109132
+
+---
+ src/osipparser2/osip_body.c | 8
+ 1 file changed, 8 insertions(+)
+
+--- a/src/osipparser2/osip_body.c
b/src/osipparser2/osip_body.c
+@@ -417,6 +417,14 @@ osip_body_to_str (const osip_body_t * bo
+ }
+
+ if ((osip_list_size (body->headers) > 0) || (body->content_type != NULL)) {
++if (length < tmp_body - ptr + 3) {
++ size_t len;
++
++ len = tmp_body - ptr;
++ length = length + 3 + body->length; /* add body->length, to avoid calling realloc often */
++ ptr = osip_realloc (ptr
Bug#857992: openjdk-8-jre-headless: please add Breaks: tzdata-java
user debian-rele...@lists.debian.org
usertags 857992 bsp-2017-04-ca-montreal
thanks
On Mon, Apr 10, 2017 at 12:28:07PM +0200, Andreas Beckmann wrote:
> Control: severity -1 serious
>
> On 2017-03-17 00:33, Andreas Beckmann wrote:
> > I haven't rebuilt openjdk-8 to test whether this actually works (and
> > don't have the tiem to so now).
>
> I just rebuilt openjdk-8 with that Breaks added and it fixed this
> previously failing upgrade path.
I have tried to do a NMU for this and failed to build OpenJDK through
pdebuild:
-> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team
Description: Dummy package to satisfy dependencies with aptitude - created by
pbuilder
This package was created automatically by pbuilder to satisfy the
build-dependencies of the package being currently built.
Depends: debhelper (>= 9), quilt, m4, lsb-release, zip, unzip, sharutils, gawk,
cpio, pkg-config, procps, wdiff, fastjar (>= 2:0.96-0ubuntu2), autoconf (>=
2.69), automake, autotools-dev, ant, ant-optional, g++-6, openjdk-8-jdk |
openjdk-7-jdk, libxtst-dev, libxi-dev, libxt-dev, libxaw7-dev, libxrender-dev,
libcups2-dev, libasound2-dev, liblcms2-dev, libfreetype6-dev (>= 2.2.1),
libgtk2.0-dev, libxinerama-dev, libkrb5-dev, xsltproc, libpcsclite-dev,
libffi-dev, zlib1g-dev, libattr1-dev, libpng-dev, libjpeg-dev, libgif-dev,
libpulse-dev (>= 0.9.12), systemtap-sdt-dev, libnss3-dev (>= 2:3.17.1), tzdata,
mauve, jtreg, xvfb, xauth, xfonts-base, libgl1-mesa-dri, twm | metacity, twm |
dbus-x11, x11-xkb-utils, time, openjdk-8-jdk-headless , dpkg-dev (>=
1.17.14)
dpkg-deb: error: parsing file
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy/DEBIAN/control'
near line 8 package 'pbuilder-satisfydepends-dummy':
'Depends' field, syntax error after reference to package
'openjdk-8-jdk-headless'
E: pbuilder-satisfydepends failed.
I couldn't even build a source-only package there..
So I'm giving up on this - but I'll not that there is a
${tzdata:Depends} in the headless package that may be the cause of the
problems here...
I also wonder if that affects other binary packages in openjdk, but
considering tzdata is present only in the headless version, that
shouldn't be an issue...
A.
Bug#859655: golang-go.crypto: CVE-2017-3204
Control: user -1 debian-rele...@lists.debian.org Control: usertags -1 bsp-2017-04-ca-montreal Control: tags -1 +patch I looked into this during the Montreal BSP, and it's unclear what we should do here, considering there has been multiple new uploads since the stretch freeze. The patch is pretty long: https://github.com/golang/crypto/commit/e4e2799dd7aab89f583e1d898300d96367750991 ... and there's no way to just backport it into stretch at this point (IIRC). So I'm wondering if the next step here would not just be to ask for an exception to unblock this for stretch, or just tell the release team to just ignore this and drop the package from stretch. Let me know, A. -- Celui qui ne connaît pas l'histoire est condamné à la revivre. - Karl Marx
Bug#850168: lintian should have checks for manual pages to see if they have an EXAMPlES section
Control: severity -1 wishlist I agree! I often find myself frustrated by more obscure bits of software where I would love to see some EXAMPLES sections to help me get started. Maybe this could be a "Informative" or "Pedantic" level instead of "Warning"? It certainly shouldn't be at the "Error" level, or at least not worse than the current "manpage missing" message. Thanks! -- If it's important for you, you'll find a way. If it's not, you'll find an excuse. - Unknown signature.asc Description: Digital signature
Bug#848508: LANG=C wormhole :/
On Tue, Jan 03, 2017 at 02:03:44PM -0500, Daniel Kahn Gillmor wrote:
> Control: forwarded 848508 https://github.com/warner/magic-wormhole/issues/127
>
> It'd be really nice for wormhole to stay on python 3 -- i would like to
> be able to run a system free of python2 in the near future, and i'd also
> like to be able to have wormhole available.
I'd like to have Debian free of Python2 as well, but it is not going to
happen in stretch, not by a long shot.
> I've forwarded the debian bug report upstream to see whether Brian has
> any suggested resolution.
Great, thanks!
> but I note that once we're talking about wormhole using non-ASCII
> wordlists (see https://github.com/warner/magic-wormhole/issues/26),
> "LANG=C wormhole receive" is going to be a buggy invocation no matter
> what anyway.
I'm happy to follow whatever upstream decides, but I'd like to point out
that this is not just a feature request ("non-ASCII wordlist", which can
be supported fine even if we go back to py2 btw), but an actual bug
("fails to work").
> I'm inclined to just say "don't do that" on debian systems, where we
> expect C.UTF-8 to be available anyway.
C.UTF-8 is necessarily available on all Debian systems, let alone the
default. In fact, I believe the default locale, on Debian systems, is
still C. Having our package fail to work in that locale breaks the
Principle Of Least Astonishment.
I still believe the simplest fix, in the short term, is to revert back
packaging to Python2. We could (and should, anyways) provide both
python2 and python3 bindings for the magic-wormhole *libraries* and make
the binary use the python2 libraries until the click bug is fixed or
Debian defaults to a UTF-8 locale.
Until then, we are, by default, not working at all unless the user
does an extra configuration. I think this is an unacceptable situation
and a bug that should be fixed.
Failing that, someone should mark this bug as unfixed and just close
this issue. I certainly wouldn't do that myself as I believe this is a
bug that we should work around until Click does the right thing.
Not everyone is a unicode geek like we are. ;)
A.
--
I worry about my child and the Internet all the time, even though
she's too young to have logged on yet. Here's what I worry about. I
worry that 10 or 15 years from now, she will come to me and say
'Daddy, where were you when they took freedom of the press away from
the Internet?' - Mike Godwin, Electronic Frontier Foundation
signature.asc
Description: Digital signature
Bug#810506: Upload of linux-grsec to jessie-backports?
On Mon, Apr 25, 2016 at 08:19:42AM +0200, Yves-Alexis Perez wrote: > On lun., 2016-04-25 at 05:45 +, Amarildo Júnior wrote: > > Any news? > > Stay tuned? As already said I was waiting on the kernel to become eligible for > migration. This happened two days ago, so I'll prepare a jessie-backport > upload. But you're not forced to stop breathing in the meantime. It's been a few months and the package is still not in stretch, partly because of this bug (but also because of #835949). It is also considered bad practice to upload a package to backports if it is not in testing yet, especially if it's destined to be packaged there... It would be great to settle this before the stretch freeze, which is coming real soon now (soft freeze on jan 5th would block this, iirc): https://release.debian.org/ A. -- I've got to design so you can put it together out of garbage cans. In part because that's what I started from, but mostly because I don’t trust the industrial structure—they might decide to suppress us weirdos and try to deny us the parts we need. - Lee Felsenstein signature.asc Description: Digital signature
Bug#845196: closed by Bastien Roucariès (Bug#845196: fixed in imagemagick 8:6.8.9.9-5+deb8u6)
I believe the fix for Bug#845196 is incomplete, at least in stable. It does ship with this patch: https://github.com/ImageMagick/ImageMagick/commit/1be809ae06f2fcb094836960edb707f81422e964 but not this one: https://github.com/ImageMagick/ImageMagick/commit/933e96f01a8c889c7bf5ffd30020e86a02a046e7 so it is missing one fputc check in convert. a. signature.asc Description: Digital signature
Bug#848139: CVE-2016-8707 ImageMagick Convert Tiff Adobe Deflate Code Execution Vulnerability
Here's a patch for wheezy, which may be useful for jessie if, like
wheezy, it lacks the ReadYCCKMethod case.
From e5fd9ab1b70b2edd06de8efb606e04482cb9a2f0 Mon Sep 17 00:00:00 2001
From: Cristy
Date: Thu, 1 Dec 2016 20:06:50 -0500
Subject: [PATCH] Fix possible buffer overflow when writing compressed TIFFS
---
ChangeLog | 2 ++
coders/tiff.c | 34 +++---
2 files changed, 21 insertions(+), 15 deletions(-)
Patch was modified to remove ReadYCCKMethod case because absent from wheezy.
--- a/ChangeLog
+++ b/ChangeLog
@@ -3,6 +3,8 @@
2012-06-26 6.7.7-10 Glenn Randers-Pehrson
* Don't attempt to use Z_RLE compression strategy with old zlib (prior to
+ * Fix possible buffer overflow when writing compressed TIFFS (vulnerability
+report from Cisco Talos, CVE-2016-8707).
zlib-1.2.0) that does not support it.
* Increase PLTE chunk length to accommodate background color in indexed PNG
(reference www.imagemagick.org/discourse-server/viewtopic.php?f=1&t=21288).
--- a/coders/tiff.c
+++ b/coders/tiff.c
@@ -866,7 +866,7 @@ static Image *ReadTIFFImage(const ImageI
width;
unsigned char
-*pixels;
+*tiff_pixels;
/*
Open image.
@@ -1223,7 +1223,13 @@ static Image *ReadTIFFImage(const ImageI
method=ReadTileMethod;
quantum_info->endian=LSBEndian;
quantum_type=RGBQuantum;
-pixels=GetQuantumPixels(quantum_info);
+tiff_pixels=(unsigned char *) AcquireMagickMemory(TIFFScanlineSize(tiff)+
+ sizeof(uint32));
+if (tiff_pixels == (unsigned char *) NULL)
+ {
+TIFFClose(tiff);
+ThrowReaderException(ResourceLimitError,"MemoryAllocationFailed");
+ }
switch (method)
{
case ReadSingleSampleMethod:
@@ -1294,7 +1300,6 @@ static Image *ReadTIFFImage(const ImageI
TIFFClose(tiff);
ThrowReaderException(ResourceLimitError,"MemoryAllocationFailed");
}
-pixels=GetQuantumPixels(quantum_info);
for (y=0; y < (ssize_t) image->rows; y++)
{
int
@@ -1303,14 +1308,14 @@ static Image *ReadTIFFImage(const ImageI
register PixelPacket
*restrict q;
- status=TIFFReadPixels(tiff,bits_per_sample,0,y,(char *) pixels);
+ status=TIFFReadPixels(tiff,bits_per_sample,0,y,(char *) tiff_pixels);
if (status == -1)
break;
q=QueueAuthenticPixels(image,0,y,image->columns,1,exception);
if (q == (PixelPacket *) NULL)
break;
length=ImportQuantumPixels(image,(CacheView *) NULL,quantum_info,
-quantum_type,pixels,exception);
+quantum_type,tiff_pixels,exception);
(void) length;
if (SyncAuthenticPixels(image,exception) == MagickFalse)
break;
@@ -1352,7 +1357,6 @@ static Image *ReadTIFFImage(const ImageI
TIFFClose(tiff);
ThrowReaderException(ResourceLimitError,"MemoryAllocationFailed");
}
-pixels=GetQuantumPixels(quantum_info);
for (y=0; y < (ssize_t) image->rows; y++)
{
int
@@ -1361,14 +1365,14 @@ static Image *ReadTIFFImage(const ImageI
register PixelPacket
*restrict q;
- status=TIFFReadPixels(tiff,bits_per_sample,0,y,(char *) pixels);
+ status=TIFFReadPixels(tiff,bits_per_sample,0,y,(char *) tiff_pixels);
if (status == -1)
break;
q=QueueAuthenticPixels(image,0,y,image->columns,1,exception);
if (q == (PixelPacket *) NULL)
break;
length=ImportQuantumPixels(image,(CacheView *) NULL,quantum_info,
-quantum_type,pixels,exception);
+quantum_type,tiff_pixels,exception);
if (SyncAuthenticPixels(image,exception) == MagickFalse)
break;
if (image->previous == (Image *) NULL)
@@ -1397,7 +1401,7 @@ static Image *ReadTIFFImage(const ImageI
status;
status=TIFFReadPixels(tiff,bits_per_sample,(tsample_t) i,y,(char *)
- pixels);
+ tiff_pixels);
if (status == -1)
break;
q=GetAuthenticPixels(image,0,y,image->columns,1,exception);
@@ -1423,7 +1427,7 @@ static Image *ReadTIFFImage(const ImageI
default: quantum_type=UndefinedQuantum; break;
}
length=ImportQuantumPixels(image,(CacheView *) NULL,quantum_info,
- quantum_type,pixels,exception);
+ quantum_type,tiff_pixels,exception);
if (SyncAuthenticPixels(image,exception) == MagickFalse)
break;
}
@@ -1460,13 +1464,13 @@ static Image *ReadTIFFImage(const ImageI
break;
if (i == 0)
{
- if (TIFFReadRGBAStrip(tiff,(tstrip_t) y,(uint32 *) pixels) == 0)
+ if (TIFFReadRGBAStrip(tiff,(tstrip_t) y,(uint32 *) tiff_pixels) == 0)
break;
Bug#842388: RFP: zcash -- an implementation of the "Zerocash" protocol
There are packages here it seems: https://github.com/zcash/zcash/wiki/Debian-binary-packages It seems their apt repo is down, however... signature.asc Description: Digital signature
Bug#824670: ITP: dnsdiag -- DNS Diagnostics and Performance Measurement Tools
Glad to see some progress on this. It seems that the patches for dnspython have all been merged upstream and that dnsdiag now uses dnspython cleanly: https://github.com/farrokhi/dnsdiag/issues/17#issuecomment-254445188 I believe this removes the last blocker you have documented for packaging this. Good luck with the packaging, let me know if you need help! a. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan signature.asc Description: Digital signature
Bug#837591:
On Wed, Sep 14, 2016 at 10:27:06PM +0200, Tobias Frost wrote: > Actually, whether deleting a user on purge or not is disputed. > https://wiki.debian.org/AccountHandlingInMaintainerScripts > > (I wouldn't say this is RC, but I let the maintainer decide if it > should be downgraded) Understood. On Wed, Sep 14, 2016 at 11:21:07PM +0200, Neil Muller wrote: > Removing support for user deletion was specifically asked for when the > package was adopted into PAPT. I also don't see any compelling reason > to re-add it from policy, so I'm downgrading this bug. Right. > If there are files being left after the package is purged, please > provide details. Well, that's the thing. I wasn't very clear in my original report, but I can't think of files that irker could leave behind that we don't also want to remove. Logfiles, maybe, but those are not created by default anyways, AFAIK. So removing the user is harmless, and would make the package cleaner. Thanks. A. signature.asc Description: Digital signature
Bug#774992: O: linkchecker -- check websites and HTML documents for broken links
I may be interested in collaboratively maintaining this, if we can get upstream development to resume. Otherwise I'm tempted to just give up and point people towards w3c-checker. A. -- C'est avec les pierres de la loi qu'on a bâti les prisons, et avec les briques de la religion, les bordels. - William Blake signature.asc Description: Digital signature
Bug#773970: Monkeyscan fails at launch
Control: tags 773970 +fixed-upstream Control: fixed 773970 2.1.0 I overlooked that bug report when creating the changelog. This was fixed in the recent 2.1.0 release. A. signature.asc Description: Digital signature
Bug#784602: [PATCH] make monkeysign build reproducibly
Control: fixed 784602 2.1.0 Control: tags 784602 fixed-upstream Thanks Daniel and intri for the patch and feedback. This was fixed in the 2.1.0 release, I just overlooked that bug in the release process... What I actually did was that I just ripped out the timestamp code from the manpage generation process, which was rebuilt based on the new argparse code. Unfortunately, that means loss of functionality and the manpage is not as great as it was before. We are considering other ways of maintaining the manpage, maybe through Sphinx directly: https://0xacab.org/monkeysphere/monkeysign/issues/47 ... which would hopefully *not* trigger this issue again. :) Cheers, A. -- You Are What You Is - Frank Zappa signature.asc Description: Digital signature
Bug#647883: lists ${distro_codename}-updates but needs stable-updates
Control: fixed 647883 0.83.3.1
On Tue, Nov 08, 2011 at 12:00:26PM +0100, Michael Vogt wrote:
> On Mon, Nov 07, 2011 at 10:53:12AM +0100, Philipp Kern wrote:
> > The commented-out example for squeeze-updates (${distro_codename}-updates)
> > provided by unattended-upgrades does not work. You actually need to specify
> > stable-updates to get automatic upgrades.
>
> Thanks for your bugreport.
>
> I pushed this fix to
> http://anonscm.debian.org/bzr/apt/unattended-upgrades/debian-squeeze/
> and it will need a proposed-updates upload.
It looks like you forgot to close this bug report. I believe this was
actually fixed in 0.83.3.1:
https://github.com/mvo5/unattended-upgrades/commit/9a2afa59502b34a5941ee6d1f72294f4494d129a
On Tue, Dec 20, 2011 at 11:47:52AM +0200, Teodor MICU wrote:
> This bug look very much like #618336.
... which has been marked as resolved.
> If it doesn't worth the trouble for a backport to 'stable' maybe close it?
We are now 5 years later. I would assume it is too late for a backport
and we can just close this bug report.
Sorry for the delays everyone, it looks like the BTS needs a lot of
triage for unattended-upgrades... volunteers? :)
A.
--
Tu connaîtras la vérité de ton chemin à ce qui te rend heureux.
- Aristote
signature.asc
Description: Digital signature
Bug#832758: irkerd.service runs irkerd as root (should run as user "irker")
Control: tags -1 +pending Control: forwarded https://gitlab.com/esr/irker/merge_requests/15 The following patch should fix that problem: commit 1980b7cb4239463b581579cc39480774d3e2d2fe Author: Antoine Beaupré Date: Mon Sep 12 12:01:44 2016 -0400 run daemon as the irker user (Close: #832758) this is an improvement upon the default .service file. it requires a irker user to be created, something which is automatically handled by the debian package, but should be handled by other distributions when deploying the .service file. there are obvious dangers in running irkerd as root: a compromise would be catastrophic, and since it runs on public servers that are traditionnally pretty hostile (IRC), it seems critical that rights of the daemon be limited. diff --git a/irkerd.service b/irkerd.service index d19378b..82f39b0 100644 --- a/irkerd.service +++ b/irkerd.service @@ -7,6 +7,7 @@ Requires=network.target [Service] ExecStart=/usr/bin/irkerd +User=irker [Install] WantedBy=multi-user.target I have forwarded it upstream as well. A. signature.asc Description: Digital signature
Bug#837589: irker: diff for NMU version 2.18+dfsg-1.1
Package: irker Version: 2.18+dfsg-1 Severity: normal Tags: patch pending [Replace XX with correct value] Dear maintainer, I've prepared an NMU for irker (versioned as 2.18+dfsg-1.1) and uploaded it to DELAYED/10. Please feel free to tell me if I should delay it longer. Regards. diff -Nru irker-2.18+dfsg/debian/changelog irker-2.18+dfsg/debian/changelog --- irker-2.18+dfsg/debian/changelog 2016-06-18 04:54:48.0 -0400 +++ irker-2.18+dfsg/debian/changelog 2016-09-12 12:09:50.0 -0400 @@ -1,3 +1,12 @@ +irker (2.18+dfsg-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * new patches to the .service file: +* run daemon as the irker used (Closes: #832758) +* properly import environment from /etc/defaults (Closes: #832322) + + -- Antoine Beaupré Mon, 12 Sep 2016 11:59:26 -0400 + irker (2.18+dfsg-1) unstable; urgency=low * Update to latest upstream release. diff -Nru irker-2.18+dfsg/debian/patches/0008-user-service.patch irker-2.18+dfsg/debian/patches/0008-user-service.patch --- irker-2.18+dfsg/debian/patches/0008-user-service.patch 1969-12-31 19:00:00.0 -0500 +++ irker-2.18+dfsg/debian/patches/0008-user-service.patch 2016-09-12 12:04:51.0 -0400 @@ -0,0 +1,28 @@ +commit 1980b7cb4239463b581579cc39480774d3e2d2fe +Author: Antoine Beaupré +Date: Mon Sep 12 12:01:44 2016 -0400 + +run daemon as the irker user (Close: #832758) + +this is an improvement upon the default .service file. it requires a +irker user to be created, something which is automatically handled by +the debian package, but should be handled by other distributions when +deploying the .service file. + +there are obvious dangers in running irkerd as root: a compromise +would be catastrophic, and since it runs on public servers that are +traditionnally pretty hostile (IRC), it seems critical that rights of +the daemon be limited. + +diff --git a/irkerd.service b/irkerd.service +index d19378b..82f39b0 100644 +--- a/irkerd.service b/irkerd.service +@@ -7,6 +7,7 @@ Requires=network.target + + [Service] + ExecStart=/usr/bin/irkerd ++User=irker + + [Install] + WantedBy=multi-user.target diff -Nru irker-2.18+dfsg/debian/patches/0009-env-service.patch irker-2.18+dfsg/debian/patches/0009-env-service.patch --- irker-2.18+dfsg/debian/patches/0009-env-service.patch 1969-12-31 19:00:00.0 -0500 +++ irker-2.18+dfsg/debian/patches/0009-env-service.patch 2016-09-12 12:08:44.0 -0400 @@ -0,0 +1,14 @@ +diff --git a/irkerd.service b/irkerd.service +index 82f39b0..f4cd45b 100644 +--- a/irkerd.service b/irkerd.service +@@ -6,7 +6,8 @@ Description=irker daemon + Requires=network.target + + [Service] +-ExecStart=/usr/bin/irkerd ++EnvironmentFile=-/etc/default/irker ++ExecStart=/usr/bin/irkerd $IRKER_OPTIONS + User=irker + + [Install] diff -Nru irker-2.18+dfsg/debian/patches/series irker-2.18+dfsg/debian/patches/series --- irker-2.18+dfsg/debian/patches/series 2016-03-17 18:42:26.0 -0400 +++ irker-2.18+dfsg/debian/patches/series 2016-09-12 12:08:55.0 -0400 @@ -2,3 +2,5 @@ 0005-author-name.patch 0006-alias-service.patch 0007-irkerhook-git.patch +0008-user-service.patch +0009-env-service.patch signature.asc Description: Digital signature
Bug#832322: irker: Irker is ignoring startup options defined in /etc/default/irker.
Control: tags -1 +patch +pending The following patch should fix that problem: diff --git a/irkerd.service b/irkerd.service index 82f39b0..f4cd45b 100644 --- a/irkerd.service +++ b/irkerd.service @@ -6,7 +6,8 @@ Description=irker daemon Requires=network.target [Service] -ExecStart=/usr/bin/irkerd +EnvironmentFile=-/etc/default/irker +ExecStart=/usr/bin/irkerd $IRKER_OPTIONS User=irker [Install] Note that this is rolled on top of the patch for #832758. signature.asc Description: Digital signature
Bug#736548: monkeysign: Reports "key is expired, cannot sign" on non-expired key
Control: tags -1 +confirmed -help +pending On Fri, Jan 24, 2014 at 09:24:42PM +0100, Emilien Klein wrote: > When trying to sign this particular key (2BEF0A33), I get the error message > that the key is expired. > This key is not expired > I've been in contact with the key owner, who acknoledged that one ID had > indeed been revoqued, but that the main key is still active. On Sat, Jan 25, 2014 at 06:08:20PM +0100, Andreas Rütten wrote: > I can confirm this behaviour with this two keys: > > pub 4096R/29299233 2011-11-11 >Fingerprint=4B84 4C8F B6EB 4194 29F5 EBEC 5764 07A6 2929 9233 Thanks. I have added that key to our test rig and wrote a unit test that confirms the problem: https://0xacab.org/monkeysphere/monkeysign/commit/03fc176fe804fe96b3c4ccd9ffcafaf0350b0c10 On Sat, Jul 16, 2016 at 05:31:15PM -0400, Jerome Charaoui wrote: > tag patch > thanks > > This ugly little patch appears to fix the problem for me. ... and I have merged jerome's patch which fixes the failed unit test here: https://0xacab.org/monkeysphere/monkeysign/commit/65a986bf66b9c81cc13ab3cd51fda5a84121b01f This will be fixed in the next upload. Thank you for your patience and detailed reports. A. signature.asc Description: Digital signature
Bug#725061: RFE: monkeysign should provide a --from option
Control: tags -1 +wontfix +moreinfo On Tue, Oct 01, 2013 at 01:33:45AM +0200, Kristian Fiskerstrand wrote: > In order to specify the sending address a --from option should be added, > alternatively, if a UID containing an email address exists in the > signing key this could be used as the sending address for emails. Hmm... how does that differ from the --user option exactly? Here is how the "From" logic is determined right now: https://0xacab.org/monkeysphere/monkeysign/blob/2.x/monkeysign/ui.py#L343 Ie. either we take it straight from --user, or we use the first UID of the chosen key. This ensures we send an email with a From that matches the signing key. That assumes we do *explicitely* not want to send email with a From that matches the signing key. That assumption may be incorrect. I'd love to hear the reasoning behind it in that case. Thanks, and sorry for the delay. A. -- A genius is someone who discovers that the stone that falls and the moon that doesn't fall represent one and the same phenomenon. - Ernesto Sabato signature.asc Description: Digital signature
Bug#760139: expiry date in epoch time is not human readable
Control: tags -1 +patch +pending A patch was provided for this (yaay!) here: https://lists.riseup.net/www/arc/monkeysphere/2016-06/msg2.html It has been applied to the 2.x branch. Thanks for the report! signature.asc Description: Digital signature
Bug#766129: monkeysign tells me that it's going to sign with a key I revoked in 2009
Control: retitle -1 monkeysign should not use revoked keys to make signatures Control: tags -1 +confirmed +patch Control: severity -1 important Actually, I just realized there's a patch for this here: https://lists.riseup.net/www/arc/monkeysphere/2015-02/msg9.html I kept on being confused because there's a bunch of similar issues here: * monkeysign *signs* revoked keys (#723763) * monkeysign signs *with* revoked keys (this issue) * monkeysign signs *expired* keys (#736548) * *monkeyscan* offers to sign with revoked keys (#773896) ... and so on. -- The history of any one part of the earth, like the life of a soldier, consists of long periods of boredom and short periods of terror. - British geologist Derek V. Ager signature.asc Description: Digital signature
Bug#723763: monkeysign should not sign revoked uids
On Thu, Sep 01, 2016 at 11:11:57AM -0400, Antoine Beaupré wrote: > On 2016-08-01 17:53:11, Antoine Beaupré wrote: > > Control: tags -1 +moreinfo > > > > Could you provide unit tests coverage for this and verify that the tests > > pass after the patch is applied? > > Also, after discussing with the Geysigning people, it seems that I > missed another patch that was already made here: > > https://lists.riseup.net/www/arc/monkeysphere/2015-02/msg9.html > > It seems that his patchset is a little more complete, although it still > doesn't feature unit tests, which I would prefer to have before merging > this in. > > Please consider reviewing his work before going forward - it seems that > running --list-keys twice is necessary, unless we're running GPG 2.1 > (which I am starting to think we should depend on :/). Sigh... disregard that - the above patches make sure that we don't sign *with* revoked keys - a different issue (which I'll track in #766129). a. -- L'homme construit des maisons parce qu'il est vivant, mais il écrit des livres parce qu'il se sait mortel. - Daniel Pennac, Comme un roman signature.asc Description: Digital signature
Bug#780393: Monkeyscan shows wrong fingerprint
Control: tags -1 +moreinfo +unreproducible On Fri, Mar 13, 2015 at 10:26:25AM +0100, Dimitri Dhuyvetter wrote: > Package: monkeysign > > When I scan a QR code I made outside of Monkeysig, which contains the > string "openpgp4fpr:6FC84DA08920932D34DDCBCD188E3F108C693450" Monkeysign > shows me this message: > > Signing the following key > > > > pub [unknown] 4096R/D4E5573D 1412669072 [expiry: 1475741072] > > Fingerprint = 7699 3358 A023 D4C7 460E CD23 E690 607D D4E5 573D > > uid 1 [unknown] Dimitri Dhuyvetter > > uid 2 [unknown] Dimitri Dhuyvetter > > uid 3 [unknown] Dimitri Dhuyvetter > > sub 4096R/D4E5573D 1412669072 [expiry: 1475741072] > > > > > > Sign all identities? [y/N] > > This should be > > sec 4096R/0x188E3F108C693450 2014-10-07 [expires: 2016-10-06] > > Key fingerprint = 6FC8 4DA0 8920 932D 34DD CBCD 188E 3F10 8C69 3450 > > uidDimitri Dhuyvetter > > uidDimitri Dhuyvetter > > uidDimitri Dhuyvetter > > uidDimitri Dhuyvetter > > ssb 4096R/0xE690607DD4E5573D 2014-10-07 > > Or short ID 0x8C693450 That is really strange. I cannot reproduce this here, obviously: $ monkeysign --local 6FC84DA08920932D34DDCBCD188E3F108C693450 Préparation à la signature de cette clé: pub [unknown] 4096R/7B75921E 1243621534 [expiry: 1496357973] Fingerprint = 8DC9 01CE 6414 6C04 8AD5 0FBB 7921 5252 7B75 921E uid 1 [unknown] Antoine Beaupré (home address) uid 2 [unknown] Antoine Beaupré (work) sub 2048R/EE02855A 1342743455 sub 4096R/9C5A5581 1243622183 La clé suivante sera certifiée pub [unknown] 4096R/8C693450 1412669072 [expiry: 1475741072] Fingerprint = 6FC8 4DA0 8920 932D 34DD CBCD 188E 3F10 8C69 3450 uid 1 [unknown] Dimitri Dhuyvetter uid 2 [unknown] Dimitri Dhuyvetter uid 3 [unknown] Dimitri Dhuyvetter uid 4 [unknown] Dimitri Dhuyvetter uid 5 [unknown] Dimitri Dhuyvetter sub 4096R/D4E5573D 1412669072 [expiry: 1475741072] What is interesting is that if I try the other fingerprint that you originally found, I get this: $ monkeysign --local 7699 3358 A023 D4C7 460E CD23 E690 607D D4E5 573D Préparation à la signature de cette clé: pub [unknown] 4096R/7B75921E 1243621534 [expiry: 1496357973] Fingerprint = 8DC9 01CE 6414 6C04 8AD5 0FBB 7921 5252 7B75 921E uid 1 [unknown] Antoine Beaupré (home address) uid 2 [unknown] Antoine Beaupré (work) sub 2048R/EE02855A 1342743455 sub 4096R/9C5A5581 1243622183 La clé suivante sera certifiée pub [unknown] 4096R/8C693450 1412669072 [expiry: 1475741072] Fingerprint = 6FC8 4DA0 8920 932D 34DD CBCD 188E 3F10 8C69 3450 uid 1 [unknown] Dimitri Dhuyvetter uid 2 [unknown] Dimitri Dhuyvetter uid 3 [unknown] Dimitri Dhuyvetter uid 4 [unknown] Dimitri Dhuyvetter uid 5 [unknown] Dimitri Dhuyvetter sub 4096R/D4E5573D 1412669072 [expiry: 1475741072] ie. it signs the same key! When I import your key from the keyservers, I find can export your key using that other fingerprint: $ gpg --export -a '76993358A023D4C7460ECD23E690607DD4E5573D' | gpg pub 4096R/188E3F108C693450 2014-10-07 Dimitri Dhuyvetter uidDimitri Dhuyvetter uidDimitri Dhuyvetter uidDimitri Dhuyvetter uidDimitri Dhuyvetter sub 4096R/E690607DD4E5573D 2014-10-07 [expire : 2016-10-06] I cannot find key 76993358A023D4C7460ECD23E690607DD4E5573D anywhere on the keyservers. > I've attached the QR in question, so you can test it out yourself. I do not see the qrcode in attachment, nor in the URL you mentionned in that other post, could you send it again? > I'm not sure which version of Monkeysign or Monkeyscan I have, I > installed it today from Ubuntu repos. > I am running Ubuntu 14.03 LTS You are likely running 1.1, according to this: http://packages.ubuntu.com/monkeysign You may want to try a newer version. A. -- One has a moral responsibility to disobey unjust laws. - Martin Luther King, Jr. signature.asc Description: Digital signature
Bug#773896: monkeyscan: identity menu has no indicator for expired keys
Control: tags -1 confirmed Control: retitle -1 monkeyscan: do not offer to sign with revoked keys On Tue, Jan 20, 2015 at 12:29:36PM -0800, Vagrant Cascadian wrote: > On 2014-12-24, Paul Wise wrote: > > I have an expired key in my local keyring but monkeyscan doesn't > > indicate that it is expired in the menu. I would expect the menu item to > > be either greyed or crossed out or not be visible in the Identity menu > > at all. I don't have any revoked keys but I would expect those to have > > an indicator too, probably a different one to expired keys. Probably > > greyed out for expired keys and crossed out for revoked keys. > > I can confirm it also shows revoked keys. To add insult to injury, it > defaults to using a revoked key for me... This is because we can't tell if secret keys are revoked, blame GPG <2.1 and see #723763. But yeah, even if we could tell, the UI doesn't deal with that at all - we should just not show those keys at all. Regarding the default that is wrong, that is also documented, in #766129. A. -- The history of any one part of the earth, like the life of a soldier, consists of long periods of boredom and short periods of terror. - British geologist Derek V. Ager signature.asc Description: Digital signature
Bug#760717: monkeysign chokes when gpg wants user to run with --check-trustdb
Control: severity -1 wishlist Control: tags -1 +confirmed +help Control: retitle -1 monkeysign should deal with --no-auto-check-trustdb configurations On Sun, Sep 07, 2014 at 03:53:18AM -0400, Gabriel Filion wrote: > with current master (commit 5a8d12914a8d4388c6543056098276f6e756e483) > when I try to sign a key, gpg emits an error message about needing to > run with --check-trustdb, and apparently monkeysign is choking on this > output with the following debug info: it seems that you have --no-auto-check-trustdb in your gpg.conf, is that correct? i am tempted to just ignore this as an unsupported configuration for now. but it certainly doesn't warrant the current severity at least. ;) i would welcome patches that would ignore that piece of dialog. unit tests to reproduce this issue would also be appreciated! thanks for the bug report! a. -- The destiny of Earthseed is to take root among the stars. - Octavia Butler signature.asc Description: Digital signature
Bug#823104: monkeysign: Twice confused by package description
Control: tags -1 moreinfo Control: severity -1 wishlist On Sat, Apr 30, 2016 at 09:50:01PM +0200, Holger Levsen wrote: > Package: monkeysign > Version: 2.0.2 > Severity: normal > > Hi, > > I've read the package description and while I like the funny tone, I > also find it confusing for two reasons: > > 1.) > > monkeysign is a tool to overhaul the OpenPGP keysigning experience > and bring it closer to something that most primates can understand. > [...] > Monkeysign is the commandline signing software. > > -> most primates can't understand commandline software?! That is correct. What do you find find confusing here? > 2.) > > The project makes use of cheap digital cameras and the type of bar > code known as a QRcode to provide a human-friendly yet still-secure > keysigning experience. > [...] > Monkeysign is the commandline signing software, a caff > replacement. > > -> is it a caff replacement or does it rely on QRcodes? It's funny that you quote only the first sentence of that paragraph, the full paragraph is: Monkeysign is the commandline signing software, a caff replacement. Monkeyscan is the graphical user interface that scans qrcodes. So Monkeysign is the caff replacement, and monkeyscan is the GUI. > Please clarify the package description to make these things > clear(er). I would appreciate a suggestion on how to phrase this better. With the above, I am not sure I can find a proper formulation that would be satisfactory. > Also it might be appropriate to explain that monkeysign is a > commandline tool, just like caff or pius… (and that only monkeyscan > does all the monkey QR stuff and therefore has a gui…) Again, I felt that the last paragraph did exactly that. > Also, I'm kinda surprised that I have recommends enabled and get this > after installing monkeysign: > > $ monkeyscan some modules missing for scanning functionality: No > module named zbar That seems like a completely different issue... python-zbar and python-zbarpygtk and both in Recommends - are they installed on your computer? A. -- Il est sage de nous réconcilier avec notre adolescence ; haїr, mépriser, nier ou simplement oublier l’adolescent que nous fûmes est en soi une attitude adolescente. - Daniel Pennac, Comme un roman signature.asc Description: Digital signature
Bug#736629: UnicodeDecodeError: 'utf8' codec can't decode byte 0xf6
Control: severity -1 minor Control: found -1 2.0.2 It looks like Dennis' key has an invalid encoding, even in gpg: $ gpg --search-keys allsp...@planetcyborg.de gpg: recherche de « allsp...@planetcyborg.de » sur le serveur hkp pool.sks-keyservers.net (1) Dennis Boerm 2048 bit RSA key 287992D55C7E48CE, créé : 2014-06-16 (révoquée) (2) Dennis Börm Dennis Börm Dennis Börm Dennis Börm Dennis Börm 4096 bit RSA key DF87C73A6F432148, créé : 2014-04-25 (3) Dennis Boerm Dennis Boerm Dennis B\xf6\x72m Dennis Börm Dennis Boerm Dennis Boerm Dennis Boerm Dennis Börm Dennis Boerm 2048 bit RSA key ECAA37C45C7E48CE, créé : 2009-09-15 Keys 1-3 of 3 for "allsp...@planetcyborg.de". Entrez le ou les nombres, (S)uivant, ou (Q)uitter > I am not sure what we should do with this - an exception certainly isn't great, but how do you certify corrupt data anyways? A. signature.asc Description: Digital signature
Bug#736120: Update on bug#736120
Control: tags -1 -moreinfo +unreproducible
On Sat, Dec 13, 2014 at 05:39:13PM +0100, Emilien Klein wrote:
> Hi,
>
> Using version 2.0.2 on a sid box, with the same key that I used in
> post#2, I do get a different traceback, which seems unrelated:
>
>
> Really sign key? [y/N] y
> command: ['gpg', '--command-fd', '0', '--with-fingerprint',
> '--list-options',
> 'show-sig-subpackets,show-uid-validity,show-unusable-uids,show-unusable-subkeys,show-keyring,show-sig-expire',
> '--status-fd', '2', '--quiet', '--batch', '--fixed-list-mode',
> '--no-tty', '--with-colons', '--use-agent', '--secret-keyring',
> '/home/emilien/.gnupg/secring.gpg', '--homedir', '/tmp/pygpg-s5Sx9O',
> '--sign-key', 'Stefano Zacchiroli ']
> SKIPPED: [GNUPG:] KEYEXPIRED 1417438220
> Traceback (most recent call last):
> File "/usr/bin/monkeysign", line 41, in
> u.main()
> File "/usr/lib/python2.7/dist-packages/monkeysign/cli.py", line 70, in
> main
> self.sign_key()
> File "/usr/lib/python2.7/dist-packages/monkeysign/ui.py", line 305, in
> sign_key
> if not self.tmpkeyring.sign_key(pattern, alluids):
> File "/usr/lib/python2.7/dist-packages/monkeysign/gpg.py", line 482,
> in sign_key
> raise GpgRuntimeError(self.context.returncode, _('cannot select uid
> for signing: %s') % e.found().decode('utf-8'))
> monkeysign.gpg.GpgRuntimeError: [Errno 0] cannot select uid for signing:
> [GNUPG:] KEYEXPIRED 1417438220
>
>
> The weird thing is that neither my key (I just signed 3 other keys
> without issues) nor the key that I'm signing have expired.
This definitely look like #736548:
monkeysign: Reports "key is expired, cannot sign" on non-expired key
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736548
> As I don't know if this traceback occurs before or after the place where
> the original issue occurred, I can't really confirm if the issue is fixed.
Right. You could try the patch available above to see if it fixes the
problem for you.
> Let me know if I can provide extra information for you to reproduce.
I am tempted to just close this bug report at this point - I have Zack's
key in the test suite and it passes. If you can reproduce, remove the
tag and send me another backtrace.
Sorry for the delays, BTW... and thanks for following up!
--
signature.asc
Description: Digital signature
Bug#834524: init-system-helpers: does not own /etc/rc?.d
On Wed, Aug 17, 2016 at 12:08:05AM +0200, Michael Biebl wrote: > Am 16.08.2016 um 19:12 schrieb Ferenc Wágner: > > Package: init-system-helpers > > Version: 1.25 > > Severity: normal > > > > Hi, > > > > Recently both my daemon packages started to exhibit this piuparts error: > > > > ERROR: FAIL: Package purging left files on system: > > /etc/rc2.d/not owned > > /etc/rc3.d/not owned > > /etc/rc4.d/not owned > > /etc/rc5.d/not owned > > > > I think this is the result of sysv-rc losing its Essential flag, which means > > it isn't present in minimal chroots (like those used by piuparts) anymore. > > On the other hand, init-system-helpers imported update-rc.d in version 1.25, > > and I think /etc/rc?.d is created by update-rc.d (but never removed). All > > this results in piuparts failures in recently tested daemon packages. > > > > If the above analysis is correct, please fix this. > > Fix what exactly? I am not sure what the fix is either, but it breaks Piuparts (#834766) for a *lot* of packages: https://piuparts.debian.org/sid/unowned_files_after_purge_error.html arguably, not all those matches are due to this specific bug, but at this point, any package that ships a daemon with dh_installinit (and that's a lot of packages!) are now yielding piuparts errors all over the place (e.g. postfix, openssh-server, apache2 all now fail piuparts). This bug is marked as "pending", with a patch. Would that fix piuparts? If so, I would highly recommend uploading the new version ASAP to keep people like me from looking all over the place to figure out what broke in their packages. If not, it would be great to have some way forward. Punting the issue in Piuparts' backyard may work, but I think it would be nice to get rid of those old directories on systems that do not have init.d files anymore... Thanks! A. signature.asc Description: Digital signature
Bug#833854: sks: no longer logs to /var/log/sks/
On Tue, Aug 09, 2016 at 09:23:51PM +0200, Christoph Anton Mitterer wrote: > On Tue, 2016-08-09 at 12:06 -0400, Daniel Kahn Gillmor wrote: > > it'd also likely fix this piuparts failure for sks itself at least: > > > > https://piuparts.debian.org/sid/fail/sks_1.1.6-1.log > > > > 0m26.6s ERROR: FAIL: Package purging left files on system: > > /etc/rc1.d/ not owned > > /etc/rc2.d/ not owned > > /etc/rc3.d/ not owned > > /etc/rc4.d/ not owned > > /etc/rc5.d/ not owned > > > > 0m26.7s ERROR: FAIL: Installation and purging test. > > Kinda strange... here these packages are sysv-rc owned... if they're > left over, than somewhere is a bug (dpkg-helper scripts? init-helper- > scripts?) Did you have any other ideas on how to fix this? I'm seeing similar problems with charybdis, and i'm starting to believe this is a larger problem than just our two packages: https://piuparts.debian.org/sid/unowned_files_after_purge_error.html Charybdis's log is here: https://piuparts.debian.org/sid/fail/charybdis_3.5.2p1-2.log Actually, I got pointed towards this bug which seems to be common, in piuparts: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834766 So this doesn't seem to be sks at all. (I found this bug googling for the piuparts error message so i figured i would mention it here for future seekers of truth.) A. -- L'ennui avec la grande famille humaine, c'est que tout le monde veut en être le père. - Mafalda signature.asc Description: Digital signature
Bug#834766: piuparts: unowned rcX.d
On Thu, Aug 18, 2016 at 07:38:37PM +, Holger Levsen wrote: > package: piuparts > severity: important > version: 0.72 > x-debbugs-cc: Antonio Radici > > On Wed, Aug 17, 2016 at 06:59:16AM +, Antonio Radici wrote: > > Hi there, > > I recently uploaded a new version of cfengine3 and I got an error from > > piuparts, > > the log is here: > > https://piuparts.debian.org/sid/fail/cfengine3_3.7.4-2.log > > > > From what I can see it seems that /etc/rcX.d directories are unowned after > > the > > purge, the new version did not introduce a change to the init script so I > > was > > wondering if something has changed in the way init scripts are handled or > > there > > is something in particular that I'm missing > > > > Thanks a lot in advance! > > thanks for your report, Antonio! > > I'm quite busy right now and will try to look into this next week. Help & > patches much welcome! This seems to be a bug with the init-system-helpers package, which ships update-rc.d but doesn't cleanup those directories on removal, see #834524. Not sure it's a problem with Piuparts... A. signature.asc Description: Digital signature
Bug#806034: gmpc: FTBFS when built with dpkg-buildpackage -A (No such file or directory)
On Wed, Aug 03, 2016 at 07:55:10AM +0100, Simon McVittie wrote: > On Sun, 29 May 2016 at 15:12:12 +0200, Etienne Millon wrote: > > Here's a patch that fixes the issue. > > Please prepare a proposed upload, I'd be happy to sponsor it. > > Alternatively, if you intend for pkg-mpd team members to be able to upload > this package without it being an NMU, please set the team as the Maintainer > with yourself in Uploaders, or add the team to Uploaders if you want to be > considered the primary maintainer. The canonical spelling seems to be > "mpd maintainers ". Hi! Thanks for the offer Simon, I have made an upload to mark me and etienne as uploaders and MPD as the maintainer team. I hope everything is in order! a. -- I know where I am going, and I know the truth, and I do not have to be what you want me to be. I am free to be what I want. - Muhammad Ali signature.asc Description: Digital signature
Bug#781180: Please add new youtube-dl in jessie-updates
Control: severity -1 grave Control: fixed -1 2016.02.22-1~bpo8+1 On Mon, Apr 27, 2015 at 10:16:25PM -0300, Rogério Brito wrote: > Hi. > > On Apr 27 2015, transylvania wrote: > > Thanks for maintaining youtube-dl. > > You're welcome. +1 :) > > Since youtube-dl is one of those programs like clamav that needs to be > > kept up to date with upstream quite frequently in order to be consistently > > useful, > > Yes, I agree. > > > please could you arrange for the version you've added to unstable to be > > added to jessie-updates? > > Yes, I can do that, but I would first need to know the procedure to perform > such updates. Since I am a bit short on time, can you contact the stable > release team and let them know about the user's needs? Is this still a thing? The procedure for stable updates is here: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable Basically, we need to file a bug to release.debian.org including the patch we want to apply to the package to fix the bug. Considering there are fairly large changes between stable and testing, I am not sure the change would be accepted. But then again, this bug makes the youtube package basically useless in stable so it should either be removed from stable, or updated to the testing version. I have bumped the bug severity accordingly. I am using the backports version, which works well, but the point of backports is not to provide such critical bugfixes, but backport special functionalities that do not warrant a full stable update. I will file a bug against release.debian.org to start that conversation. A. -- Voter, c'est abdiquer - Élisée Reclus signature.asc Description: Digital signature
Bug#760787: Please try these
On Sun, Apr 24, 2016 at 09:13:09PM +0200, Richard Hartmann wrote: > Hi, > > feel free to use > dediserver.eu/misc/git-annex_6.20160418-1~bpo8+1_amd64.deb until its > "real" package migrated into testing. The package did migrate to testing now, can the backport be updated? Thanks! -- Les plus beaux chants sont les chants de revendications Le vers doit faire l'amour dans la tête des populations. À l'école de la poésie, on n'apprend pas: on se bat! - Léo Ferré, "Préface" signature.asc Description: Digital signature
Bug#833090: ITP: magic-wormhole -- Securely and simply transfer data between computers
On Tue, Aug 02, 2016 at 06:52:03PM -0700, Jameson Graef Rollins wrote: > On Tue, Aug 02 2016, Fredrik Alströmer wrote: > > I would object slightly to calling it "securely", from what I can tell by a > > quick glance at the code, the data is relayed through the authors private > > server. The pass phrases seem to be fairly limited (chosen from a 512-entry > > dictionary iiuc), simply spamming the the public endpoint with passwords > > should net you something cool sooner or later. > > Hi, Fredrik. Thanks for the comments. > > The fact that data is relayed through the author's private server should > not compromise integrity of the data, since the data is actually > encrypted end-to-end. The package also includes the server program > itself so users can set up their own server rather than use the one > provided by the author. > > The upstream author has attempted to explain the compromises involved in > using relatively low-entropy password for the initial key exchange: > > http://www.lothar.com/%7Ewarner/MagicWormhole-PyCon2016.pdf > https://youtu.be/dgnikoiau68 > > > Also, as a comment in the code suggests, the server might disappear at any > > time so it's not intended for wide adoption. > > My intention is to put the package in experimental, so that we can gain > deployment experience. > > I don't think that any of the concerns that you express should preclude > us putting the package into experimental. I'd go even further and say this should be shipped as part of regular Debian releases, ie. just push it to unstable. We still ship FTP daemons that serve files without passwords and use cleartext by default. Jamie, I'd be happy to co-maintain this! A. -- Semantics is the gravity of abstraction. signature.asc Description: Digital signature
Bug#818977: removing or updating libmowgli?
On Tue, Jul 05, 2016 at 04:33:15PM +0200, Andrew Shadura wrote: > On 03/05/16 20:22, Antoine Beaupré wrote: > > This issue is now fixed. > > Yes, and I have uploaded 2.1.0 to Debian. Cool, thanks! > > However, to fix this in sid, we'll need to setup a transition for > > libmowgli. This seems overkill, to say the least, since atheme is, as > > far as I know, the only package depending on libmowgli. > > At the moment yes. libmowgli should probably go away. Okay, do you want to orphan the package, should I file for removal, or how do we proceed? > > Why are we keeping those two separate anyways? It's not as if there's a > > lot of things that use libmowgli out there. In the whole existence of > > the package, *nothing* came up that reused the library. > > In the past, libguess and audacious used libmowgli, but both then > stopped doing so. Oooh... i was wondering which packages that might have been. :) I have now uploaded atheme 7.2.6, which links against debian's libmowgli. let me know if you take measures to remove it from sid so i can upload a new package... thanks for following up! PS: btw, i missed your message because I wasn't cc'd in your reply... -- A riot is the language of the unheard. - Martin Luther King, Jr. signature.asc Description: Digital signature
Bug#754972: ITP: percol -- adds flavor of interactive filtering to the traditional pipe concept of UNIX shell
On Fri, Aug 28, 2015 at 10:29:02AM +0900, Kozo Nishida wrote: > Hi Antoine, > > Sorry for the late reply, and thank you for your kindness. > > I first submit percol debian package on https://mentors.debian.net/ Hello, I am not sure if you uploaded the said package to mentors.debian.net, but it doesn't show up there right now. Packages do expire after a while, so it's possible you uploaded it and I just missed it. Considering how long it took for me to reply here, maybe it would be better if you put the package somewhere else where I have time to review it before it gets removed... Please do keep me in CC when replying so that I see your reply! thanks, a. -- Every time I see an adult on a bicycle I no longer despair for the future of the human race. - H. G. Wells signature.asc Description: Digital signature
Bug#825301: More details
On Fri, May 27, 2016 at 10:17:45AM +, S y s C o / lz wrote: > Hi, > > the problem shows up when the user clicks on the link 'Search' for a database > (not a table). > > http:///phpmyadmin/db_search.php?db=apecchampi&server=1&token=x I have built new packages that should fix this bug available here: https://people.debian.org/~anarcat/debian/wheezy-lts/ Will test and upload myself by the end of the day. Sorry for the trouble. A. signature.asc Description: Digital signature
Bug#804384: smokeping: README.Debian quite outdated
On Sat, Nov 07, 2015 at 10:28:55PM +, Jonathan Dowland wrote: > Package: smokeping > Version: 2.6.11-1 > Severity: normal > > hi, > > /usr/share/doc/smokeping/README.Debian is quite outdated now: Yes, it is. > > After installing the package you have to edit the file > > /etc/smokeping/config to set your preferences. You can follow > > the example provided. > > the config file now is just a list of includes of other files, > there is no longer really an example to follow. Hmm... well, what's wrong with following those include files? > > ln -s /etc/smokeping/apache2.conf /etc/apache2/conf.d/smokeping > > invoke-rc.d apache2 restart > > I see #760474 already reported complains that the above is not right because > conf.d no longer exists; however, now /etc/smokeping/apache2.conf is gone > too. I simply removed that reference from the README and reshuffled it a bit. > Finally it would be quite nice to include lighttpd/fastcgi auto-configuration. Please file this as a seperate wishlist. Patches are, obviously, welcome. :) I need help maintaining this package... A. -- Advertisers, not governments, are the primary censors of media content in the United States today. - C. Edwin Baker signature.asc Description: Digital signature
Bug#730674: ITP: piwik -- web analytics software
On Fri, Jul 25, 2014 at 09:08:42PM +0200, Daniel Baumann wrote: > i'm not going to do it after all. On Wed, Mar 12, 2014 at 05:11:39PM +0100, Daniel Baumann wrote: > after having worked on #609521 already a couple of years ago, i'll > finally got to it now and am finishing up the last remaining things. > > the preliminary packaging is available at > http://daniel-baumann.ch/gitweb/?p=debian/packages/piwik.git So obviously this repo is gone. Did anyone get the chance to clone a copy of it? It's not on the internet archive or anywhere i can see. It seems that upstream has its own debian package now: https://github.com/piwik/piwik-package Maybe that could be of interest here? A. -- Les écrivains qui ont recours à leurs doigts pour savoir s'ils ont leur compte de pieds ne sont pas des poètes, ce sont des dactylographes. - Léo Ferré, "Préface" signature.asc Description: Digital signature
Bug#813313: [planet-venus] fails on SNI enabled websites
Control: forwarded -1 https://github.com/jcgregorio/httplib2/issues/233 On Wed, Feb 10, 2016 at 01:05:59AM +0100, Jakub Wilk wrote: > * anarcat , 2016-02-09, 09:33: > >This is typical of Python apps that depend only on urllib and so on. > > Not really. Python's stdlib supports SNI since 2.7.9, which was the first > version that enabled certificate verification by default, and what's in > jessie. > > Here the culrprit is httplib2: [...] You're right of course. Here's the upstream bug: https://github.com/jcgregorio/httplib2/issues/233 httplib2 folks say that the problem doesn't appear in Python3, so maybe Venus could run in Py3k? I actually doubt it, considering that software hasn't been updated since well, 2010 or so... The number of failed hosts keeps on growing in the meantime: $ grep -c 'Server presented certificate that does not match host' planet.log.0 22 Note that those are not all let's encrypt certs, but they are probably mostly SNI. Those wishing to reproduce the issue can follow the instructions on the wiki page here: https://wiki.debian.org/PlanetDebian#test Or simply run the bootstrap script: http://anonscm.debian.org/viewvc/planet-debian/trunk/planet-bootstrap.sh?view=co&content-type=text%2Fplain The faulty code in planet venus itself is in planet/spider.py, around line 300, in the httpThread function. It *looks* like it could be fairly easy to convert it to requests, as the API usage is fairly superficial. A. signature.asc Description: Digital signature
Bug#798500: drush will be removed from Debian
Hi,
In #823767, I have requested from the FTP-masters that Drush be removed
from Debian. In the ~9 months since it was orphaned, no one stepped up
to start maintaining the Drush package, let alone update it to a current
version. There was some movement on the Ubuntu side of things (also in
CC), but it seems it didn't end up going anywhere.
It seems clear to me no one is available to do that task and having an
outdated version of Drush in Debian is hurting both projects for no good
reason. At least that is the constant feedback I receive, both privately
and through the above bug reports.
So unless someone steps up *now* to tell the FTP-masters to stop, it
will be removed as soon as they take a look at bug #823767.
Thanks for your attention, and sorry for the wide {B,}CC.
A.
--
Le pouvoir n'est pas à conquérir, il est à détruire
- Jean-François Brient, de la servitude moderne
signature.asc
Description: Digital signature
Bug#685734: dpkg should manage system users and groups
On Fri, Aug 24, 2012 at 07:23:57AM +0200, Harald Dunkel wrote: > It would be very nice if dpkg could manage system users and groups > created for each package. > > At the moment I've got GID 105 for dbus on host A, while 105 is > used for saned on host B (just as an example). This is a severe > problem when A's root partition is visible somehow on B, e.g. > on a central backup server, or on an LXC server managing the > client rootfs in its own name space. > > I would like to tell dpkg to use GID 105 for the dbus package on > all systems. If there is a conflict with an existing entry in > /etc/passwd or /etc/group, then it should refuse to install. I have another use case for this: root-less .deb installs. While *in general* one needs root to run `dpkg -i`, most packages (75%) don't *actually* need arbitrary code to be ran as root to be installed[1]. By making user creation declarative, we could lower that number quite a bit, I believe. So my use case here is to reduce the attack surface for intrusions through untrusted .debs. I have documented various attack vectors here: https://wiki.debian.org/UntrustedDebs ... and this is clearly one of them. :) A. [1]: https://nthykier.wordpress.com/2016/04/26/putting-debian-packages-in-labelled-boxes/ signature.asc Description: Digital signature
Bug#817286: Simplify testing access for packages on security-master
On Wed, Mar 09, 2016 at 07:41:57PM +0100, Moritz Muehlenhoff wrote: > Package: ftp.debian.org > Severity: wishlist > > This was discussed at one of the past security team meetings, but > there was never a bug for that: > > (This is a first high level view, the exact requirements can be hashed > out later.) > > It would be great to have a simple (single command) method to simplify > testing security updates. Right now these need to copied manually to > the respective test hosts. If it's not available via apt, this is a > problem for many people since they are unable to find out which binary > packages are installed and how to update them via dpkg. > > There should be a method to allow > - publishing a public security issue to a permanent staging repository > ala jessie-security-staging, which people can keep in their apt source > > - publishing an non-public security issue to a protected apt > repository to simplify testing for members of the security team I am not very familiar with the internals of DAK, but to me this should be setup similarly to how the stable-proposed-updates currently are setup. Couldn't there be a suite before "security" in dak? For those, like me, who are struggling to keep in RAM all those suites, I've updated the flow diagram that madduck made a while back, so now it looks like this: https://wiki.debian.org/DebianReleases#Workflow There's probably a bunch of mistakes there, it's in the wrong place (moinmoin wiki that doesn't keep revisions instead of real docs somewhere) but i had to stop shaving yaks at *some* point. A. -- It is a miracle that curiosity survives formal education - Albert Einstein signature.asc Description: Digital signature
Bug#760787: Please provide a backport of latest release
Control: found -1 5.20151208-1~bpo8+1 Control: found -1 5.20141125 This is still an issue for me. I'm looking at a workaround for this bug: https://git-annex.branchable.com/bugs/git_annex_get_fails_from_read-only_repository/ .. and it seems it needs at least a 2016 version to get this fix. Can we get a new backport uploaded? Thanks! -- The history of any one part of the earth, like the life of a soldier, consists of long periods of boredom and short periods of terror. - British geologist Derek V. Ager signature.asc Description: Digital signature
Bug#807735: gmpc-plugins: FTBFS: libmpd-internal.h:210:10: error: expected identifier or '(' before '__extension__'
Control: tags -1 +patch So how about just disabling jamendo as a quick fix? --- debian/rules.orig 2016-04-13 11:29:24.570556456 -0400 +++ debian/rules2016-04-13 11:29:26.214556530 -0400 @@ -9,7 +9,7 @@ dh $@ --with autoreconf override_dh_auto_configure: - dh_auto_configure -- --disable-lyricwiki + dh_auto_configure -- --disable-lyricwiki --disable-jamendo override_dh_strip: dh_strip $(DEB_DH_STRIP_ARGS) -- Choose a job you love and you will never have to work a day in your life. - Confucius signature.asc Description: Digital signature
Bug#820378: Ensure users report bugs in BTS and not to upstream directly
I think this patch is a great idea! Unfortunately, there is no obvious way to file a bug from the URL used: https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=xscreensaver;dist=unstable (that is the target of the redirection.) We are doing a poor job at helping people file bugs, generally. I usually point people to: https://www.debian.org/Bugs/Reporting but that's a little horrible as well... Not sure what the best fix is here, but pointing people to bugs.d.o/xscreensaver will certainly not help our users. :) A. PS: great job on that other bug report btw, Tormod. :) -- If builders built houses the way programmers built programs, The first woodpecker to come along would destroy civilization. - Gerald Weinberg signature.asc Description: Digital signature
Bug#507682: Adjustable averaging window for rate display
Control: fixed -1 1.2.0-1 Hi, You may like to know this is now a feature in pv 1.2.0. Sorry for the (very) delayed response - I actually had a confirmation of this from upstream in 2014 but forgot to document it here. A. On Wed, Dec 03, 2008 at 10:40:33AM -0500, Anthony DeRobertis wrote: > Package: pv > Version: 1.1.4-1 > Severity: wishlist > File: /usr/bin/pv > > It appears that pv always averages the transfer rate over the display > interval. It'd be nice if that could be controlled seperately. Right > now, if you have very bursty data (for example, lzcat receiving > compressed data from the network, writing uncompressed to disk), you > have to use a very long update interval, on the order of a minute, to > get a reasonable rate estimate. It'd be nice to keep the 1s update > interval, but take the average over a longer period. > > It'd be awesome if pv recognized bursty data and adjusted the averaging > itself, but that's way more than I expect. > > -- System Information: > Debian Release: lenny/sid > APT prefers testing > APT policy: (500, 'testing'), (100, 'unstable') > Architecture: i386 (i686) > > Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/bash > > Versions of packages pv depends on: > ii libc6 2.7-16 GNU C Library: Shared libraries > > pv recommends no packages. > > Versions of packages pv suggests: > ii doc-base 0.8.16 utilities to manage online > documen > > -- no debconf information > > -- Education is the most powerful weapon which we can use to change the world. - Nelson Mandela signature.asc Description: Digital signature
Bug#470995: where is the source??
4 years later, still no debian package... a little embarrassing! It looks like the source is here now: https://vote.debian.org/~secretary/devotee.git/ A. signature.asc Description: Digital signature
Bug#799292: ITP: mailman3 -- Mailman3 mailing list manager suite
Any progress here? signature.asc Description: Digital signature
Bug#818510: upgrade-reports: excellent upgrade experience on Lenovo E431
Package: upgrade-reports Severity: minor I just upgraded my friend's laptop from the latest Wheezy to the latest Jessie without a hitch! Things went really smoothly. I changed the sources.list by hand, ran apt-get upgrade; apt-get dist-upgrade and everything went almost perfectly. For some reason, db5.1-util and unoconv were not correctly upgraded on dist-upgrade. Running dist-upgrade fixed the latter, but not the former. I eneded up just purging db5.1-util. autoremove didn't catch everything: a bunch of packages were "obsolete" according to aptitude and I had to remove those by hand. it would be nice if the upgrade process would cover those as well. this includes python 2.6, the older kernel, openjdk 6, gcc 4.6 and a bunch more random libs that clutter the system. otherwise everything seems to be going well so far. the user's only complaint so far is that the minimize button is gone from gnome, but she figured out she can click on the window in the window list to achieve the same result. mission accomplished! although ideally, *she* would have been able to do the upgrade herself. maybe next time! a. PS: this is not really a bug report, more of a "good job" to whoever is receiving those messages. :) of course if you think some bug reports should be open for specific issues, I'll be glad to follow any pointer! -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#749887: Status update
Ping! Any progress here? When can we hope to see this in NEW or mentors? Should we be reviewing the package? Can't wait! :) -- Every one of us is, in the cosmic perspective, precious. If a human disagrees with you, let him live. In a hundred billion galaxies, you will not find another. - Carl Sagan signature.asc Description: Digital signature
Bug#814543: ITP: asset-collector -- collect information about the used hardware/software
On 2016-02-12 14:02:53, Benjamin Drung wrote: > I started writing the asset-collector, because I found no other tool for > this purpose (correct me if I am wrong). I invite everyone who is > interested in this topic to join the project. Hmm... it seems to me there are already a bunch of tools that do similar stuff. Of course there's dmidecode, but that's only part of what you are trying to do. Yet I can't help but think this could be part of one of those projects instead: http://glpi-project.org/ http://www.ocsinventory-ng.org/ http://machdb.org/ http://www.onecmdb.org/ Anything specific your tool plans to do that is not covered above? And is the source code available yet? -- That's the kind of society I want to build. I want a guarantee - with physics and mathematics, not with laws - that we can give ourselves real privacy of personal communications. - John Gilmore
Bug#792916: RFP: keybase-client a client to access keybase services
FWIW, keybase is now written in go and the main client is here: https://github.com/keybase/client there's a debian package available upstream: https://keybase.io/download https://keybase.io/docs/the_app/install_linux ... and the source for that seems to be partly here: https://github.com/keybase/client/tree/master/packaging/linux/deb I am not sure keybase itself is such a good thing: they have weird practices like encouraging people to store the private key on the server and so on. But it's an interesting project and certainly has its place in Debian. a. signature.asc Description: Digital signature
Bug#816788: borgbackup-doc: api.html build embeds datetime and i/o charset, thus making package unreproducible
https://github.com/borgbackup/borg/issues/399 It would be useful to contribute / share information with upstream regarding this here. A. -- Dr. King’s major assumption was that if you are nonviolent, if you suffer, your opponent will see your suffering and will be moved to change his heart. He only made one fallacious assumption: In order for nonviolence to work, your opponent must have a conscience. The United States has none. - Stokely Carmichael signature.asc Description: Digital signature
Bug#813313: raising severity to important
On Tue, Feb 09, 2016 at 03:24:03PM +0100, Holger Levsen wrote: > control: severity -1 important This is typical of Python apps that depend only on urllib and so on. I have had the same problem in the sopel IRC bot and solved it by switching to using the Requests library: https://github.com/sopel-irc/sopel/pull/988 requests is so simple to use that the change makes the code actually easier to read and shorter, not to mention faster.. a. signature.asc Description: Digital signature
Bug#804698: RFP: muchsync -- synchronize maildirs and notmuch databases
On Tue, Nov 10, 2015 at 11:24:27AM -0500, Antoine Beaupré wrote: > * it works! or at least i think it does: i'm testing it right now Actually, it doesn't work: I sent an email to the upstream author about this and to the notmuch mailing list, but basically, here it eats up all memory before being killed by the OOM-killer. (~11GB of mail). A. -- It will be a great day when our schools get all the money they need and the air force has to hold a bake sale to buy a bomber. - Unknown
Bug#812401: cpio: CVE-2016-2037: out-of-bounds write
I can't actually reproduce with the test case provided on oss-security: (gdb) run -i < ../overflow.cpio Starting program: /bin/cpio -i < ../overflow.cpio [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". /bin/cpio: Malformed number000 /bin/cpio: warning: skipped 8 bytes of junk /bin/cpio: Substituting `.' for empty member name /bin/cpio: . not created: newer or same age version exists /bin/cpio: premature end of file [Inferior 1 (process 191) exited with code 02] Did i miss anything? signature.asc Description: Digital signature
Bug#809136: borgbackup: Mention API incompatibilities in README
On Mon, Jan 11, 2016 at 01:46:48PM +0100, Danny Edel wrote: [...] > Please state whether you think this (write README and hope user actually > reads it) is an appropriate solution to the compatibility problem, > meaning we could close the bug this way. [...] > [2]: > https://anonscm.debian.org/cgit/collab-maint/borgbackup.git/tree/debian/README.Debian The readme is not quite accurate: *some* borg versions are actually compatible across the network. It's only on the 0.29 boundary that there is a problem. It also refers to a non-existent backport, but i guess we can trust this will come to fruitition soon. :) Otherwise i do think this bug can be closed now. a. -- Si les triangles avaient un Dieu, ils lui donneraient trois côtés. - Montesquieu, Lettres persanes signature.asc Description: Digital signature
Bug#807826: redmine: CVE-2015-8537: Data disclosure in atom feed
And of course I forgot the patch: diff --git a/app/views/journals/index.builder b/app/views/journals/index.builder index a81ff98..7d90346 100644 --- a/app/views/journals/index.builder +++ b/app/views/journals/index.builder @@ -19,7 +19,7 @@ xml.feed "xmlns" => "http://www.w3.org/2005/Atom"; do end xml.content "type" => "html" do xml.text! '' -details_to_strings(change.details, false).each do |string| +details_to_strings(change.visible_details, false).each do |string| xml.text! '' + string + '' end xml.text! '' Fairly trivial, and should be portable to all current versions. This is basically 7e423fb4538247d59e01958c48b491f196a1de56 but stripping the tests to ease backporting. Not tested. signature.asc Description: Digital signature
Bug#807826: redmine: CVE-2015-8537: Data disclosure in atom feed
Control: notfound -1 1.0.1-2 Control: notfound -1 1.0.1-2+deb6u11 Control: found -1 1.1.2-2~bpo60+1 I have review the Redmine code for CVE-2015-8537 and it turns out the vulnerable code is not present in 1.0.1, but is present in 1.1 and 1.4 which makes everything from squeeze-backports and up vulnerable. A. -- Thousands of candles can be lit from a single candle And the life of the candle will not be shortened. Happiness never decreases by being shared. - Buddha signature.asc Description: Digital signature
Bug#638422: url changed
The project is now at: https://github.com/rfrail3/tuptime I have tried to run this from the source, and it's pretty cool: $ tuptime System startups:3 since 15:49:13 2015-08-07 System shutdowns: 1 ok - 1 bad System uptime: 100.0 % - 107 days, 7 hours, 27 minutes and 26 seconds System downtime:0.0 % - 1 minute and 47 seconds System life:107 days, 7 hours, 29 minutes and 14 seconds Largest uptime: 94 days, 6 hours, 15 minutes and 48 seconds from 15:49:13 2015-08-07 Shortest uptime:2 days, 12 hours, 59 minutes and 15 seconds from 21:05:49 2015-11-09 Average uptime: 35 days, 18 hours, 29 minutes and 9 seconds Largest downtime: 58 seconds from 10:05:04 2015-11-12 Shortest downtime: 48 seconds from 21:05:01 2015-11-09 Average downtime: 36 seconds Current uptime: 10 days, 12 hours, 12 minutes and 24 seconds since 10:06:03 2015-11-12 The source tree is prtty weird however. Instead of having the usual `debian/` directory, there's a `deb-package` one, with the `.deb` *in the git repo!* I have reported that issue here: https://github.com/rfrail3/tuptime/issues/11 Hopefully, this may enlighten us on how the .deb was created and maybe we could reuse that... -- The problem is not a lack of highly educated workers, the problem is a lack of highly educated workers willing to work for the minimum wage or lower in the U.S. Costs are driving outsourcing, not the quality of American schools. - Scott Kirwin, IT Professionals Association
Bug#753648: [Pkg-utopia-maintainers] Bug#753648: Bug#753648: network-manager: Connecting to an encrypted WLAN fails with `received an invalid or unencryptable secret`
I can confirm this behaviour here. I am running only nm-applet (on top of course of the system-wide NetworkManager daemon). Sometimes, out of the blue, some networks won't work. For example here, i have an internal *and* external wifi card. NM can connect to network "foo" fine with the internal card, but the external card yields this error: nov 08 21:37:18 angela NetworkManager[921]: Activation (wlan1) starting connection 'foo' nov 08 21:37:18 angela NetworkManager[921]: Activation (wlan1) Stage 1 of 5 (Device Prepare) scheduled... nov 08 21:37:18 angela NetworkManager[921]: Activation (wlan1) Stage 1 of 5 (Device Prepare) started... nov 08 21:37:18 angela NetworkManager[921]: (wlan1): device state change: disconnected -> prepare (reason 'none') [30 40 0] nov 08 21:37:19 angela NetworkManager[921]: Activation (wlan1) Stage 2 of 5 (Device Configure) scheduled... nov 08 21:37:19 angela NetworkManager[921]: Activation (wlan1) Stage 1 of 5 (Device Prepare) complete. nov 08 21:37:19 angela NetworkManager[921]: Activation (wlan1) Stage 2 of 5 (Device Configure) starting... nov 08 21:37:19 angela NetworkManager[921]: (wlan1): device state change: prepare -> config (reason 'none') [40 50 0] nov 08 21:37:19 angela NetworkManager[921]: Activation (wlan1/wireless): access point 'foo' has security, but secrets are required. nov 08 21:37:19 angela NetworkManager[921]: (wlan1): device state change: config -> need-auth (reason 'none') [50 60 0] nov 08 21:37:19 angela NetworkManager[921]: Activation (wlan1) Stage 2 of 5 (Device Configure) complete. nov 08 21:37:19 angela NetworkManager[921]: No agents were available for this request. nov 08 21:37:19 angela NetworkManager[921]: (wlan1): device state change: need-auth -> failed (reason 'no-secrets') [60 120 7] nov 08 21:37:19 angela NetworkManager[921]: Activation (wlan1) failed for connection 'foo' nov 08 21:37:19 angela NetworkManager[921]: (wlan1): device state change: failed -> disconnected (reason 'none') [120 30 0] nov 08 21:37:19 angela NetworkManager[921]: (wlan1): deactivating device (reason 'none') [0] What's odd is that it works with the internal card fine. I tried removing items from the config, they are recreated when using the internal card (which is also odd). This bug looks like those as well: https://bbs.archlinux.org/viewtopic.php?id=203374 http://forum.xfce.org/viewtopic.php?id=7458 http://ubuntuforums.org/showthread.php?t=1973863 so it is probably not debian specific, but seems common with non-Gnome setup (e.g. XFCE above). Oddly enough here, restarting `nm-applet` fixes the problem. It prompts me for my gnome-keyring passphrase (which i never setup, i believe), i dismiss that dialog and then things work fine. really odd. A.
Bug#792096: borg packaging
Hi folks, So what's holding up the package now? I understand Mark's position, and I don't think the team's efforts should be distracted at this stage. :) Please keep going! The msgpack package was updated, so I am not sure why this is not pushed ahead now! Cheers, A. signature.asc Description: Digital signature
Bug#762385: ITP: mailpile -- a modern fast web-mail client with user-friendly encryption and privacy features.
On Sun, Sep 21, 2014 at 06:21:58PM +, u wrote: > Package: wnpp > Severity: wishlist > Owner: Ulrike Uhlig > > * Package name: wnpp > Version: 0.4.0 > Upstream Author: Mailpile Team > * URL: https://mailpile.is > * License: AGPL v3 > Programming Lang: Python > > Mailpile is a modern, fast web-mail client with user-friendly encryption > and privacy features. > Mailpile's primary user interface is web-based, but it also has a basic > command-line interface and an API for developers. Using web technology > for the interface allows Mailpile to function both as a local desktop > application (accessed by visiting localhost in the browser) or a remote > web-mail on a personal server or VPS. What's the status on this ITP? Relevant upstream docs i found were: https://github.com/mailpile/Mailpile/wiki/Getting-started-on-linux https://www.mailpile.is/download/ a. -- The problem is not a lack of highly educated workers, the problem is a lack of highly educated workers willing to work for the minimum wage or lower in the U.S. Costs are driving outsourcing, not the quality of American schools. - Scott Kirwin, IT Professionals Association signature.asc Description: Digital signature
Bug#739860: ITP: tox -- easy to use all-in-one communication platform
Hi all, First off, sorry for the large CC list, but it seems in order to try to collect all the efforts here into one and put this into shape. This ITP is blocking the entry of toxcore in Debian, and I think that's a shame... We should already have this in Debian now! Here are the different efforts that has been reported here: On Sun, Feb 23, 2014 at 12:19:24PM +0100, Bartosz Feński wrote: > Package: wnpp Bartosz, do you have anything published here? On Fri, Jul 04, 2014 at 05:28:11PM -0500, Mike Dupont wrote: > I started on packaging today > https://github.com/h4ck3rm1k3/toxcore Mike, did you look at the work Gaffa did? On Mon, Oct 20, 2014 at 11:19:31AM -0400, Alexandre Viau wrote: > I intend to create a repository on collab-maint. It will be using the > gbp recommended layout. Was that repository created? On Tue, Nov 25, 2014 at 03:56:21PM +0100, gaffa wrote: > The packages are available on mentors.debian.net[1]. > > https://mentors.debian.net/packages/uploader/gaffa%40folkemagt.dk That package is gone (understandably), is there another copy somewhere? It seems to me, at this point, that someone should take the work Mike did, merge this with gaffa's, and push this on collab-maint, or *somewhere*! Also you should consider examining the work that was done upstream already; a Debian package archive is available here: https://pkg.tox.chat once that is all merged, then gaffa or anyone can find a mentor to upload this, i'm happy to volunteer for that part. On Thu, Jun 11, 2015 at 05:27:36PM +0200, Tzafrir Cohen wrote: > Right now it seems that the software is changing too fast and should not > go to Unstable (though may go into Experimental). > > However Upstream's policy regarding ABI/API stability (or lack thereof) > is not promising: > > https://github.com/irungentoo/toxcore/issues/1353#issuecomment-104950787 as for this well, we'll just have to deal with this if we want it in debian. i'd suggest a version number like "0~YYYMMDD.gitXXX" for now, until upstream figures out that release engineering thing (which, yes, is scary). but that shouldn't keep this from hitting unstable. at worse, file an RC bug to keep it from migrating to testing, with the reasons (e.g. "upstream doesn't want to", "changes to fast", or whatever). that way it's clear why it's not in a stable release, yet people can try it out. thanks! a. signature.asc Description: Digital signature
Bug#749664: horst: Conflicting declarations of function main_input to cause undefined behaviour
Control: fixed -1 4.0-1 On Thu, May 29, 2014 at 12:55:30AM +0100, Michael Tautschnig wrote: [...] > The wrong declaration here > > http://sources.debian.net/src/horst/3.0-2/display.c?hl=46#L46 > > will cause arbitrary truncation for values larger than 127 or any negative > values; yet even for values that fit this range big endian systems will end up > with an arbitrary argument value as the byte location is wrong. Hi. I believe this was fixed in version 4.0. A. -- C'est trop facile quand les guerres sont finies D'aller gueuler que c'était la dernière Amis bourgeois vous me faites envie Ne voyez vous pas donc point vos cimetières? - Jaques Brel signature.asc Description: Digital signature
Bug#717834: Fwd: Kill DEHS
On Thu, Jul 25, 2013 at 05:01:46PM +0300, anatoly techtonik wrote: > Package: qa.debian.org > > DEHS service at http://dehs.alioth.debian.org/ looks alive, but in > fact it is dead and its database is offline for almost two years, > which is shown by multiple reports in ML over that time > http://lists.alioth.debian.org/pipermail/dehs-devel/ > > It's time to kill it so that it won't confuse people anymore, and > redirect people from http://wiki.debian.org/DEHS to something like: > > 1. ROSA Upstream Tracker - see it in action - > http://upstream-tracker.org/updates/rosa/2012/ - it is GPL'ed, so it > should be easy to port it to Debian. This now says it is unmaintained: http://upstream.rosalinux.ru/ "Unfortunately, we cannot support the service anymore. Sorry for inconvenience. The suitable replacement for this tool will be available at github.com/lvc soon. ROSA Laboratory, 21 July 2015. " The database itself says "has been generated on 2014-09-04"... so is probably not a good way forward. > 2. http://people.ubuntuwire.org/~lucas/merges.html I am not sure how that helps. > 3. http://duck.debian.net Maybe? > 4. Anything else? So what's the solution here? Should we bug duck people to implement this? UDD seems to help here, but it does much more than this... I am using the latter now, in combination with feed2imap: - name: Debian todo url: https://udd.debian.org/dmd/?email1=anarcat%40debian.org&email2=&email3=&packages=&ignpackages=&format=rss#todo target: [ *target, debian-udd-todo ] A. -- Every one of us is, in the cosmic perspective, precious. If a human disagrees with you, let him live. In a hundred billion galaxies, you will not find another. - Carl Sagan signature.asc Description: Digital signature
Bug#794678: msgpack-python: please update to the latest upstream version
On Wed, Aug 12, 2015 at 11:17:21PM +0200, Marc Haber wrote: > On Wed, Aug 05, 2015 at 04:10:56PM +, Gianfranco Costamagna wrote: > > Hi, in order to have the latest w3af in Debian, a new msgpack-python >= > > 0.4.4 > > is needed, can you please update it? > > Current version is 0.4.6, which is needed by borgbackup. Please update > ;-) I would encourage a NMU at this stage, since there seems to be no response from the maintainer team... Oh, and it seems the watch file isn't working, because this hasn't detected the new package: https://tracker.debian.org/pkg/msgpack-python https://qa.debian.org/cgi-bin/watchfile-error.cgi?package=msgpack-python There's a redirector available that you should be using: https://wiki.debian.org/debian/watch#PyPI https://pypi.debian.net/msgpack-python/watch https://wiki.debian.org/Python/LibraryStyleGuide#debian.2Fwatch Cheers, A. -- I would defend the liberty of consenting adult creationists to practice whatever intellectual perversions they like in the privacy of their own homes; but it is also necessary to protect the young and innocent. - Arthur C. Clarke signature.asc Description: Digital signature
Bug#792096: borg packaging
On Thu, Aug 13, 2015 at 12:04:02PM +, Gianfranco Costamagna wrote: > Am I in? Sure you can join! Do you have access to collab-maint? https://wiki.debian.org/Alioth/PackagingProject Do you need a sponsor to upload a package? Marc, do you want to setup a more detailed packaging team? Others proposed joining the python app packaging team: https://wiki.debian.org/Teams/PythonAppsPackagingTeam or a new team can be made: https://wiki.debian.org/Teams Or just multiple Uploaders can be specified in the control file: https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer > On Wed, Aug 05, 2015 at 04:10:56PM +, Gianfranco Costamagna wrote: > > > Hi, in order to have the latest w3af in Debian, a new msgpack-python >= > > 0.4.4 > > is needed, can you please update it? > > Current version is 0.4.6, which is needed by borgbackup. Please update > ;-) ... indeed... a. -- Men often become what they believe themselves to be. If I believe I cannot do something, it makes me incapable of doing it. But when I believe I can, then I acquire the ability to do it even if I didn't have it in the beginning. - Mahatma Gandhi signature.asc Description: Digital signature
Bug#695878: new mutt-kz package
On Wed, Jun 17, 2015 at 10:52:16AM +0200, Alberto Garcia wrote: > On Wed, Jun 17, 2015 at 10:45:28AM +0200, Víctor M. Jáquez L. wrote: > > > > Other than that, the package looks much better now. I still > > > haven't checked all little details, though, but I think this is > > > almost ready for uploading. > > > > > > Do we have an ITP bug for mutt-kz? I haven't found it. > > > > I haven't posted a ITP bug. I'll do it. > > I've seen that Clint sponsored the current package. > > Clint, doesn't this need an ITP first? Is it enough with the RFP > (#698672)? I believe the RFP is sufficient, and that the package's changelog should close the RFP. Can't wait to start using mutt again. :) A. -- Un éducateur dans l'âme ne prend rien au sérieux que par rapport à ses disciples -- soi-même non excepté. - Nietzsche, "Par delà le bien et le mal" signature.asc Description: Digital signature
Bug#448638: RFP: i2p -- I2P is an anonymizing network
On Wed, Nov 26, 2014 at 02:56:58AM +, kytv wrote: > > Control: retitle -1 ITP: i2p -- I2P is an anonymizing network > Control: owner -1 killyou...@i2pmail.org > > > intrigeri wrote: > > kytv wrote (20 Nov 2014 03:08:58 GMT) : > >> On Mon, 17 Nov 2014 12:01:12 + (UTC) > >> intrigeri wrote: > > > >>> Now that you've started contributing to Debian, maybe you would be > >>> interested in maintaining I2P directly in there? This would make the > >>> Tails release process and source tree a bit simpler :) > > > >> Yes, I would certainly be willing to do so. > > > > \o/ > > > > I think the next formal step is to retitle this bug to ITP and set > > yourself as the owner, then :) > > Let's see if I did it correctly... Looks like you did! :) Now, the next step is to actually upload the package, is this something that's coming soon? Thanks! a. -- I'm sorry if any of you are catholic. I'm not sorry if you're offended, I'm actually just sorry by the fact that you're catholic - Bill Hicks signature.asc Description: Digital signature
Bug#695878: new mutt-kz package
On Sun, Sep 07, 2014 at 10:43:26PM +0200, Stefano Zacchiroli wrote: > Heya, +1 as well on the desire of having mutt-kz in Debian. +1 as well... > Has anyone verified with the security team if either approach would be > acceptable for them? > > What's the opinion of the Mutt maintainer on the two approaches? No idea about either, but either upload should probably close #698672 (the RFP for mutt-kz I opened without knowing about this bug) when done. I'd be curious to hear if there is any progress here as well now... Cheers! -- A man is none the less a slave because he is allowed to choose a new master once in a term of years. - Lysander Spooner signature.asc Description: Digital signature
Bug#698672: RFP: mutt-kz -- text-based mailreader supporting MIME, GPG, PGP and threading, with notmuch support
Here, note that there's a discussion about integrating this directly into the mutt package, here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695878 a. -- La mer, cette grande unificatrice, est l'unique espoir de l'homme. Aujourd'hui plus que jamais auparavant, ce vieux dicton dit littéralement ceci: nous sommes tous dans le même bateau. - Jacques Yves Cousteau - Océanographe signature.asc Description: Digital signature
Bug#538067: status of the opencpn PPA for inclusion in Debian
On Wed, Jan 07, 2015 at 08:52:55PM -0600, Pavel Kalian wrote: > Hi... Hi Pavel, > I'm an upstream developer and managing the PPA on Launchpad. Thanks for chiming in! It's certainly a good way to try to resolve this in the long run. :) (and sorry for the delay, i wasn't in cc to the bug report so i didn't see you reply until today.) > It certainly is more messy than needs to be, but it serves it's purpose, > which is to get the packages to the user in a way he can digest... Yeah, and I can certainly appreciate that! I certainly appreciate instructions on how to use this in jessie, for example. :) For the record, on Jessie, i am able to install the package from the Trusty PPA here: deb http://ppa.launchpad.net/opencpn/opencpn/ubuntu trusty main I do need to install wxwidgets from sid however, as mentionned in the upstream instructions. I would have been able to install the wxwidgets packages from wheezy (which seems like a better option than sid IMHO) if the dependencies were a little more relaxed (>= 2.8.12.1 instead of >= 2.8.12.1+dfsg). Unless of course that's an actual hard dependency requirement. > With the upcoming 4.0 release I have modularized the packages to certain > extent, separating the docs, tide data and GSHHS shorelines as they are > logical components. That's great news. I haven't reviewed the result but that seems like a huge improvement already. > I currently do no effort to clean the .orig sources off stuff not needed > on Linux, but it is on my list past the release. Frankly, I don't think it's that critical. The most important point right now is to ensure there are sources for all the binaries provided with the package. Code deduplication is a "should", not a "must" in Debian, IIRC, especially if there are actually no other copies! > We've put some effort into clarifying the license info etc. over time to > make packaging for Debian possible, but without further feedback from > you, finishing it in an acceptable way will keep having low priority - > we simply lack manpower to study the requirements in-depth. Understood. That seems perfectly reasonable. From what I understand, most of the actual licensing issues are gone. According to a quick review I did in october, all that was necessary was to remove copies of wxwidgets, the .git directory, zlib, bzip and tinyxml. I believe those were probably all "convenience copies of code" (ch. 4.13 in the debian policy): http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles So creating a tarball without those *should* be done, but it's not absolutely necessary, unless there are still (for example) DLLs without source. What is necessary however is the built package should *not* use the convenience copies but link to the existing libraries, to make security upgrades easy and (basically) possible. Another nice thing would be to build against wxwidgets 3.0: is that possible at all? A quick search led me to believe it is how opencpn is compiled in Windows and OSX... Since jessie doesn't ship with 2.8 anymore (for reasons I cannot fathom), compiling against 3.0 means it would be possible to backport to jessie and even, in fact, all the way back to wheezy and squeeze, since those also have wxwidget 3.0 backports! > Thanks for trying to clean up our mess Well, to be fair, it's an amazing work you guys are doing. I'm just sitting on the sidelines ranting that my computer isn't working the way it should be. Sorry about that. :) I hope my feedback here still has some use, and certainly hope to see opencpn land in Debian at some point. And to be real clear, I would be happy to sponsor your package once it: 1. doesn't compile against convenience copies 2. doesn't ship binaries without source 3. builds against 3.x (optional) 4. doesn't ship convenience copies of code (optional) Do you think the current package fits those requirements? In fact, I will need this package running in production fairly soon, so it would make sense for me to push again in that direction. :) Sorry we missed jessie. We can still make it to backports though. ;) Hold fast, A. signature.asc Description: Digital signature
