Bug#640647: git feature branch pushed

I pushed this change to git repo on branch feature/640647 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#640648: [Piuparts-devel] Bug#640648: Bug#640648: TODO item “PackagesDB: get rid of 50% of unique() ”

On 09/26/2011 03:18 PM, Holger Levsen wrote: tags 640648 + pending thanks Hi Scott, On Dienstag, 6. September 2011, Scott Schaefer wrote: Attached patch addresses TODO item in sbuject. applied to feature/640648 branch, will merge into develop once I find time to test it. Please

Bug#504606: THREE manpages

Attached are manpages for: 1) pam_cap.8 2) capability.conf.5 And, per lintian error: 3) getpcaps.1 '\" t .\" Title: capability.conf .\"Author: [see the "AUTHOR" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 .\" Date: 09/23/2011 .\"Manual: Li

Bug#504606: Two manpages ...

Hm if I don't have any other priority items, I will try to tackle this in the next few days. Note that in addition to pam_cap(8) man page, there should also be one for capability.conf(5). If anyone else has already started on this (or finds one in another distro), please email this bug

Bug#633075: Upstream improved error

Indeed, you are correct -- it is "failing" with this confusing message when attempting to remove >=1 capability from a file on which no capabilities are set. In newest version (upstream 1:2.22), the message now reads: Failed to set capabilities on file `t' (No data available) Are you removing

Bug#610636: [PATCH] Manpages not in bin packages

1) Only the section 8 manpages are installed by the libcap2-bin package ... $ cat libcap2-bin.manpages debian/tmp/usr/share/man/man8/* 2) Both getcap.8 and setcap.8 both refer to section 3 manpages $ grep -E "^[\.][BI]R " doc/*8 | grep -E "\([0-9]\)" doc/getcap.8:.BR cap_get_file (3), doc

Bug#633991: Bitten by Bug 591410 ....

You are running version1:2-19.3 of libcap2-bin. I believe your problem is fixed by installing a version of libcap2-bin >= 1:2.21-1 (which may require you to configure and enable 'testing' in /etc/apt/sources.list). From changelog libcap2 (1:2.21-1) unstable; urgency=low * New upstr

Bug#640824: Debian Bug 640824 -- piuparts does not start

I had responded to your bug report on 09/09, but had messed up the "nnn-submitter" CC :-(( Text below. Basically, I was unable to reproduce here (on i386), and was wondering if you could either provide more detail, or perhaps rebuild your "base.tgz" chroot and retry. I am unable to reproduc

Bug#607375: manpage Updated

Upstream has decided that the current behavior is correct, and has modified the man page as follows: Remove text: "1" is equivalent to "1.0". Replaced with text: "1" is equivalent to "1.2" (the commonly preferred 1.x format). Marking this as fixed-upstream, to be included in next update.

Bug#641886: Fixed upstream

package mdadm tag 641886 +fixed-upstream thanks Upstream commit 3f555346fb26b7ee7447b004ecb2c2d57f243867 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#637068: Proper patch

package mdadm tag 637068  +patch thanks Proper patch attached diff --git a/debian/FAQ b/debian/FAQ index 189f0e7..6ec1c11 100644 --- a/debian/FAQ +++ b/debian/FAQ @@ -140,7 +140,7 @@ The latest version of this FAQ is available here: In two thirds of the cases, yes[0], and it does not mat

Bug#607375: Revised patch

-19 Origin: vendor, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607375 Bug-Debian: http://bugs.debian.org/607375 Author: Scott Schaefer Last-Update: 2011-09-19 diff --git a/super1.c b/super1.c index 0cd4124..f66e8e5 100644 --- a/super1.c +++ b/super1.c @@ -1398,7 +1398,8 @@ static struct

Bug#601198: Reclassifying ...

tag 601998 -wontfix tag 601998 +fixed-upstream thanks Based on Neil's response, I am moving this from "Won't Fix" to "Fixed Upstream". -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#640824: Unable to duplicate

I am unable to reproduce this problem; i.e. I have successfully run v0.41 against multiple .changes files here. Can you: 1) Execute the following: mkdir /sw/tmp/test_1 tar -C /sw/tmp/test_1 zxf /var/cache/pbuilder/ base-sid-amd64.tgz chroot /sw/tmp/test_1 apt-get update (report what is output

Bug#640647: Above Activity Unrelated

Quick summary ... all the above activity was mistakenly assigned to this bug, when it should have been to 640467 (slight dyslexia). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#640649: TODO item “fix scripts for dash as default shell”

Package: piuparts Version: 0.41 Severity: wishlist Tags: patch Attached patch addresses TODO item in subject It is somewhat difficult for me to test these changes thoroughly. Also, note that checkbashisms still reports the use of $HOSTNAME as "potential"bash-ism; I am nearly certain this is fine

Bug#640648: TODO item “PackagesDB: get rid of 50% of unique()”

Package: piuparts Version: 0.41 Severity: wishlist Tags: patch Attached patch addresses TODO item in sbuject. I chose to implement this by using the set type in place of a list and unique(), and then using set.pop() method in place of random.shuffle(). I also modified the class to no longer p

Bug#640647: TODO item: "Kill children after a timeout to make sure the,test doesn't run forever"

Package: piuparts Version: 0.41 Severity: wishlist Tags: patch Attached patch addresses TODO item in subject Note the max time is controlled by a hard-coded value in piuparts-slave (MAX_WAIT_TEST_RUN), which I set to 45 minutes. Please adjust based on your better judgement. This may/will(?) req

Bug#640646: TODO item: "Replace deprecated os.popen2 with subprocess.Popen(),in piuparts-slave"

Package: piuparts Version: 0.41 Severity: wishlist Tags: patch Attached patch addresses TODO item in subject diff --git a/piuparts-slave.py b/piuparts-slave.py --- a/piuparts-slave.py +++ b/piuparts-slave.py @@ -28,6 +28,7 @@ import stat import time import logging +import subprocess import Co

Bug#522918: [Piuparts-devel] Bug#522918: Bug#522918: Patch

> Was this part really needed or "clean up noise"? > diff --git a/piuparts.py b/piuparts.py > --- a/piuparts.py > +++ b/piuparts.py > @@ -37,11 +37,9 @@ > import logging > import optparse > import sys > -import commands > import tempfile > import shutil > import os > -import tarfile > impor

Bug#522918: Patch

Attached is patch that will kill (via SIGTERM, then if that fails, via SIGKILL), these leftover processes. diff --git a/piuparts.py b/piuparts.py --- a/piuparts.py +++ b/piuparts.py @@ -37,11 +37,9 @@ import logging import optparse import sys -import commands import tempfile import shutil

Bug#487792: User Error ???

In reviewing this bug, it appears to be user error Reasoning as follows: 1) pkcs12 in the absence of -export PARSES a PKCS12 input file. The commandline noted in the report implies the user is trying to CREATE a PKCS12 file (-out cert.p12); i.e. the user's intent was to run the

Bug#601198: mdadm: Does all that can be expected ...

I am glad that you phrased your request "It would better if it managed to say it failed doing the requested operation.". Because it indeed did successfully perform the operation, exactly as the output indicated. That is, it DID indeed set the MD_DISK_FAULTY attribute on the /dev/sdb2 device of t

Bug#628667: Verified: Patch for Upstream

Verified exists in 3.1.4 and 3.2.2. Attached patch is against 3.2.2 code. Description: --add incorrectly sets writemostly Forwarded: TBD Origin: vendor, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628667 Bug-Debian: http://bugs.debian.org/628667 Author: Scott Schaefer Last-Update: 2011-07

Bug#607375: Verified: Patch for Upstream

Verified exists in 3.1.4 and 3.2.2. Attached patch is against 3.2.2 code. Description: mdadm -e 1 incorrectly treated as 1.2 ("default") Forwarded: TBD Origin: vendor, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607375 Bug-Debian: http://bugs.debian.org/607375 Author: Scott Schae

Bug#619265: Clarification

Martin: The submitter wants the mdadm manpage to list the options for each mdadm mode in alphabetical order. The current manpage has non-alphabetically-ordered options in nearly every section. Single example should suffice ... Current manpage has section "For create, build, or grow", where the

Bug#627077: Misunderstanding ?

I believe you are misunderstanding ... It seems you are interpreting the second word of "If this is not specified (as it normally is not) ...", to mean the (required) VALUE of the --size option (documented as 'Amount (in Kibibytes) of space to use from each drive in RAID levels 1/4/5/6'). In

Bug#635449: Will troubleshoot ...

I am fairly certain the problem is actually in openjdk-6-jre-headless (6b18-1.8.7-5) package ... Warning: last time I tried to troubleshoot piuparts problem, I was "wrong in several ways". So, consider analysis below accordingly. From eclipse-cdt log: Setting up openjdk-6-jre-headless (6b1

Bug#633054: Transitioning /dev/.mdadm

Updating the mdadm sources to use /run/mdadm APPEARS to require only updating the following lines in Makefile: MAP_DIR=/dev/.mdadm MDMON_DIR = /dev/.mdadm FAILED_SLOTS_DIR = /dev/.mdadm/failed-slots -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsub

Bug#625392: Verified fix in 3.2.2

I have verified upstream release 3.2.2 build under gcc 4.6.1 without errors with gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debia

Bug#632041: [Piuparts-devel] Bug#632041: Bug#632041: piuparts: Provide state of running master

On 07/10/2011 09:55 AM, Holger Levsen wrote: Hi, On Mittwoch, 29. Juni 2011, Scott Schaefer wrote: Primarily as debugging aid, but hopefully also useful in production environment, the attached patch causes piuparts-master to produce a "dump" of package states upon receipt

Bug#632924: [Piuparts-devel] Bug#632924: Bug#632924: Bug#632924: piuparts-slave to recreate tarball(s) beyond certain age

On 07/10/2011 09:17 AM, Holger Levsen wrote: tags 632924 + pending thanks On Sonntag, 10. Juli 2011, Holger Levsen wrote: are you subscribed to the PTS, so I can stop cc:ing you? doing so now ;) Sorry. I thought I had answered this before. Yes -- I subscribed piuparts-devel

Bug#618463: RFC: Change Severity

I am reviewing current mdadm bugs. Since the latest input from upstream is that they view this as a "wishlist issue", I would like to change the severity to either important or even normal. Obviously, if we could supply upstream a patch ... OTOH, I have neither requisite skills nor needed fa

Bug#621786: One Thought/Thing to Try

I have spent some time attempting to duplicate this problem w/o much success. I have duplicated your setup as closely as I can, which, unfortunately is not real close: 1) I am running under QEMU, and 2) I have smaller drive; unfortunately, I don't have a spare TB drive lying around :-(( I

Bug#632924: [Piuparts-devel] Bug#632924: piuparts-slave to recreate tarball(s) beyond certain age

On 07/09/2011 07:10 PM, Holger Levsen wrote: another minor point: on successful recreation, the tgz.bak should be removed. tgz.old, not .bak :-) And I considered that. Tried to weigh the waste of disk space vs. retaining the .old file as means of "easily" determining when (and even wh

Bug#632924: [Piuparts-devel] Bug#632924: piuparts-slave to recreate tarball(s) beyond certain age

On 07/09/2011 07:08 PM, Holger Levsen wrote: Hi Scott, On Donnerstag, 7. Juli 2011, Scott Schaefer wrote: Attached patch resolves two items: please dont do this. always fix seperate issues in seperate patches. OK. That's one of those issues that, at least in my exper

Bug#633033: piuparts: libeatmydata alternative

Package: piuparts Version: 0.40 Severity: wishlist Tags: patch Attached patch addresses TODO item re libeatmydata .. "- use libeatmydata - either install it in all chroots or find a better way to use it." With Squeeze release, the version of dpkg in stable has had an option "--force-unsafe-io"

Bug#632924: piuparts-slave to recreate tarball(s) beyond certain age

Package: piuparts Version: 0.40 Severity: wishlist Tags: patch Attached patch resolves two items: 1) From TODO ... piuparts-slave: if chroot.tgz is older than N days, regenerate it - currently this is done via ~piupartss/crontab, but that's a hack - only throw away tarballs (and recreate them)

Bug#632046: [Piuparts-devel] Bug#632046: Bug#632046: Bug#632046: piuparts: Use HTTP_PROXY

On 07/05/2011 08:12 PM, Scott Schaefer wrote: On 07/05/2011 05:49 AM, Holger Levsen wrote: Hi Scott, On Montag, 4. Juli 2011, Scott Schaefer wrote: awesome than you already are, you could include debian/changelog entries in your patches too :-) Um ... OK. I will have to learn how to do

Bug#632046: [Piuparts-devel] Bug#632046: Bug#632046: Bug#632046: piuparts: Use HTTP_PROXY

On 07/05/2011 05:49 AM, Holger Levsen wrote: Hi Scott, On Montag, 4. Juli 2011, Scott Schaefer wrote: awesome than you already are, you could include debian/changelog entries in your patches too :-) Um ... OK. I will have to learn how to do that. I will add to my "Learn

Bug#545670: Modifying wording

Thanks for reporting this. And I concede the wording is slightly ambiguous. The code in question is in file apps/speed.c. The patch is "trivial". See below. However, changing it in Debian only seems to me to be a decision that is up to the official maintainer(s). Since I expect they will

Bug#487152: Patch Addendum

Re Rr. Martin's question of 6/23/2008 ... "... is it also in the code when you don't use the conf entry": Yes (and No). The code uses default value of 512 (as per documentation). Attached are two files: defbits-2048b.patch changes #define DEFAULT_KEY_LENGTH in code to 2048 openssl-defau

Bug#632046: [Piuparts-devel] Bug#632046: piuparts: Use HTTP_PROXY

"Learn About ..." list :-) On Mittwoch, 29. Juni 2011, Scott Schaefer wrote: Attached patch causes piuparts to add appropriate line to apt.conf in chroot to cause apt to use current HTTP_PROXY variable from OS environment. it also seems to contain unwanted noise about for

Bug#554157: OpenSSL x509 Cert with UTF-8 Email Address

AFAICT, this is correct. IETF RFC 5280 declares the EMailAddress attrribute to be of type IA5TRING EmailAddress ::= IA5String (SIZE (1..ub-emailaddress-length)) It further notes ... The attribute value for emailAddress is of type IA5String to permit inclusion of the character '@', which is

Bug#588041: Ready to tackle .. Feedback Solicited

I have been thinking about this bug ("installing/removing the debs with dpkg does not do dependency reordering" to refresh direct recipient's minds) for some time, and am about ready to tackle it. However, I would really appreciate some feedback from either Andreas or Holger, or anyone who cares

Bug#632046: Patch Application

This patch should apply to current SVN codebase, but it will apply with 'fuzz' ... my patch stack is now eight deep, and I didn't realize I added this one on top of the one for 588313 (detect diversions). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of

Bug#632046: piuparts: Use HTTP_PROXY

Package: piuparts Version: 0.40 Severity: wishlist Tags: patch Attached patch causes piuparts to add appropriate line to apt.conf in chroot to cause apt to use current HTTP_PROXY variable from OS environment. It PROBABLY should also read current apt config and duplicate any Acquire::http::prox

Bug#632041: piuparts: Provide state of running master

Package: piuparts Version: 0.40 Severity: wishlist Tags: patch Primarily as debugging aid, but hopefully also useful in production environment, the attached patch causes piuparts-master to produce a "dump" of package states upon receipt of SIGUSR1 (tempfile name written to configured 'master-dir

Bug#526045: [Piuparts-devel] Bug#526045: Patch

On 06/25/2011 06:01 PM, Holger Levsen wrote: welcome back! :-) On Freitag, 24. Juni 2011, Scott Schaefer wrote: Ping (I'm back). I should be able to respond relatively quickly to any questions/issues over next 8-10 days. I've applied your patch now to trunk and am run

Bug#526045: [Piuparts-devel] Bug#526045: Patch

On 06/26/2011 10:00 AM, Holger Levsen wrote: Hi Scott, On Sonntag, 26. Juni 2011, Scott Schaefer wrote: Um ... This is probably (?) due to addition of new states in packagesdb module. I think so too, I assume its a little fix in piuparts-report.py I will try to setup and test

Bug#526045: [Piuparts-devel] Bug#526045: Patch

On 06/26/2011 04:17 AM, Holger Levsen wrote: Hi Scott, I've applied your latest patch to trunk now and have been running it the last 12h or so on piatti.debian.org, with mixed results: a.) it's been testing packages now which have not been tested before, so yay. b.) it broke piuparts-reports,

Bug#303145: [Pkg-openssl-devel] Bug#303145: Patch

On 06/13/2011 10:08 PM, Scott Schaefer wrote: On 06/13/2011 06:10 AM, Kurt Roeckx wrote: On Fri, May 06, 2011 at 08:35:57AM -0400, Scott Schaefer wrote: See attached. Prints "completion" message only on successful return. Also fixes bug which prevents executing -newreq-nodes o

Bug#533365: Workaround; Forwarded Upstream

I filed report upstream (http://rt.openssl.org/Ticket/Display.html?id=2534&user=guest&pass=guest) describing your report and my analysis. In the meantime, can you verify that you can remove the passphrase (or use the key for other operations) by using either/both of the alternate means of spe

Bug#303145: [Pkg-openssl-devel] Bug#303145: Patch

On 06/13/2011 06:10 AM, Kurt Roeckx wrote: On Fri, May 06, 2011 at 08:35:57AM -0400, Scott Schaefer wrote: See attached. Prints "completion" message only on successful return. Also fixes bug which prevents executing -newreq-nodes option, and includes newer options in usa

Bug#523950: [Piuparts-devel] Bug#523950: Revised Patch

On 06/12/2011 06:44 AM, Holger Levsen wrote: tags 523950 + pending thanks Hi Scott, On Samstag, 11. Juni 2011, Scott Schaefer wrote: Attached is revised patch. Differs from previous by: 1) single patch file rather than multiple, and Thanks, I've applied this one now to svn

Bug#526045: Patch

Attached is patch as described in my posting of 02 Jun 2011 23:23:39. It needs some additional testing [ongoing here, but not the fastest equipment around ...]. I am on vacation for a couple of weeks, so if anyone has an opportunity to review and potentially test... Notes: 1) The mods to

Bug#523950: Revised Patch

Attached is revised patch. Differs from previous by: 1) single patch file rather than multiple, and 2) fixes one typo found during further testing of piuparts-master and piuparts-slave. diff --git a/piuparts-report.py b/piuparts-report.py --- a/piuparts-report.py +++ b/piuparts-report.py @@ -

Bug#526045: Preliminary Patch: Input Welcome

Thanks, Holger ... your input '... dependency resolver, which doesnt take alternative depends into consideration.' led me to directly what I hope is the solution. I have a patch for this issue on which I have run some preliminary tests. I am busy tomorrow (Friday, Jun 3) and Saturday, so I do

Bug#595119: piuparts: modular way to add new tests?

On 06/01/2011 03:16 AM, Timo Juhani Lindfors wrote: Scott Schaefer writes: Until then, the only alternatives I see are to revise/include your patch and/or to provide some way to provide for "package-specific" scriptdir. Hmm, package specific? This test should be run a

Bug#595119: piuparts: modular way to add new tests?

On 05/31/2011 03:31 AM, Timo Juhani Lindfors wrote: Hi, Scott Schaefer writes: From reading your report and your patch, I believe you can achieve this with the "custom scripting" interface (/usr/share/doc/piuparts/README.html or http://piuparts.debian.org/doc/R

Bug#584125: RFH: piuparts.d.o is maintainance hungry

On 05/30/2011 05:26 PM, Holger Levsen wrote: Hi Scott, please keep bugs cc:ed! :) My bad ... On Montag, 30. Mai 2011, Scott Schaefer wrote: I can explain both tasks in more detail should you be interested. Yes. I am interested. Please provide greater detail when you are

Bug#603873: Updated Patch

package piuparts tag 603873 + patch thanks Attached is both my original patch updated after reviewing Mr. Anderson's previous, and a short patch including only those items which I pulled from his effort: Two occurrences where pbuilder args were missing -- minimized was misspelled custom scrip

Bug#612408: Proposal for Comment

From http://piuparts.debian.org/sid/command_not_found_issue.html ... The commandline to find these logs is: COMMAND=`rgrep "command not found" pass | cut -d " " -f1 | sed -e "s#\.log:.*#.log#" | sort -u 2>/dev/null` piuparts already logs at different "levels" -- DEBUG, INFO, and DUMP. Un

Bug#588313: piuparts: needs to detect changes in diversions

Attached is patch that implements what you are doing with scripts "internally". It defines a new option --no-diversions, which defaults to False; i.e. DO check for differences between dpkg-divert --list executions after chroot setup and after package purge. Any differences are logged with on

Bug#462489: Documentation Error

This is another documentation issue ... apps/pkcs12.c accepts -password as an argument. The document author almost certainly meant to write "-password, -passin". However, that is not correct, either. Actually the code treats -password as equivalent to -passin, EXCEPT when -export is also s

Bug#628077: piuparts: piuparts does not execute post_install script when testing package by name (-a switch)

Package: piuparts Version: 0.38 ( from reportbug, but actual executing code is from SVN r889) Severity: normal A. Compare using -a to install package by name ... $ sudo python piuparts.py -b TARBALL.tgz --scriptsdir=... -a openssl > openssl.log 2>&1 $ grep "Running scripts" openssl.log 0m36.

Bug#595119: piuparts: modular way to add new tests?

From reading your report and your patch, I believe you can achieve this with the "custom scripting" interface (/usr/share/doc/piuparts/README.html or http://piuparts.debian.org/doc/README.html#_custom_scripts_with_piuparts). While perhaps not ideal, this interface provides a 'modular way to ad

Bug#526045: RFH - Current Status, Troubleshooting, Test Case

I have been looking into this; that is, I think I have gone down two blind alleys :-) Unfortunately, given that the latest data on this is now over two years old, and the URLs are stale, I am nearly certain I cannot duplicate the exact problem. So, I am left to find a current test case. Look

Bug#603873: New Patch

Attached please find patch which addresses long lines issue only. HTML output is indistinguishable in browser, though diff is quite large. l will take a look at Mr. Andersson's patch, and see about his other suggested changes before tagging + patch diff --git a/README.txt b/README.txt --- a/R

Bug#584125: RFH: piuparts.d.o is maintainance hungry

I am interested in helping. In addition, automated testing is one of my interests. I have done my share of QA over the years, though in different environments. I have begun helping out the OpenSSL project to a small degree (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332498), but I do n

Bug#534892: False positive ?

I am a bit confused... I am certainly no Helgrind expert, and I will concede that it may know more about C than I do. However, this certainly appears to me to be a false positive. The variable err_fns is declared as: static const ERR_FNS *err_fns = NULL; Your subject line states "err_fns_che

Bug#395424: [Patch]

Patches attached --- a/doc/apps/ec.pod +++ b/doc/apps/ec.pod @@ -41,7 +41,7 @@ This specifies the input format. The B option with a private key uses an ASN.1 DER encoded SEC1 private key. When used with a public key it -uses the SubjectPublicKeyInfo structur as specified in RFC 3280. +uses the

Bug#605561: Patch

Requires MODIFYING current debian/patch/rehash_pod.patch: --- a/debian/patches/rehash_pod.patch +++ b/debian/patches/rehash_pod.patch @@ -47,12 +47,12 @@ + +Colon separated list of directories to operate on. Ignored if directories are listed on the command line. + ++=back ++ +=head1 SEE ALS

Bug#404700: Patch submitted upstream

Submitted to upstream request tracker: http://rt.openssl.org/Ticket/Display.html?id=2516 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#397730: Confirmed Fixed

I am unable to determine w/o significant effort when/how this was fixed [or even if it was perhaps a problem in sudo]. However, I have verified that the following works in both stable (0.9.8o-4squeeze1), and testing (1.0.0d-2) $ sudo openssl genrsa -aes192 -out /tmp/host.example.edu.key 1024

Bug#613490: Update/Apology

I emailed original submitter with last two responses, and asked for input. I apologize for my ignorance -- I had (naively) assumed that the original submitter automatically received email whenever a followup was posted. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org

Bug#397507: Wait for original submitter, then close

I emailed original submitter, and asked if he would read/respond to my comments above. I am moving this bug to WillNotFix status and, should no further responses be posted in 30 days, will close. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsub

Bug#168201: Wait for original submitter, then close

I emailed original submitter, and asked if he would read/respond to my comments above. I am moving this bug to WillNotFix status, and should no further responses be posted in 30 days, will close. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsub

Bug#303145: Patch

See attached. Prints "completion" message only on successful return. Also fixes bug which prevents executing -newreq-nodes option, and includes newer options in usage message. Index: openssl-1.0.0d/apps/CA.pl === --- openssl-1.0.0d

Bug#622820: Patches

Attached are three patches to address POD errors and lintian misspellings. No file is touched in more than one patch, so they can be applied in any order. --- a/doc/crypto/ASN1_generate_nconf.pod +++ b/doc/crypto/ASN1_generate_nconf.pod @@ -61,7 +61,7 @@ =item B, B Encodes an ASN1 B type. Th

Bug#533365: Reviewed: Needs upstream fix

I recommend this bug be passed upstream. The problem described is due to hardcoded "MIN_LEN=4" in source file crypto/pem/pem_lib.c Fixing this almost certainly raises series of issues, and requires mods in # of places. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.o

Bug#613490: Troubleshooting: Verification/Help Requested

Hm now this is very (??) .. um ... "interesting" (note this is stable 0,9.8-4squeeze1) Assuming no silly user error, the code execution time has quite high variability. High-level math and/or statistics is not my area of expertise. However, given these results, do you agree it is plaus

Bug#613490: Attempting to Troubleshoot: More Info Requested

I am starting to look into this, and have two questions: 1) Can you tell me the precise commansd you are using ? i.e. Does "Generating small DHs" mean: openssl dhparam -outform DER -5 -out parameters.dh # for =256,512,1024,2048,4096 2) You reference an 8-minute difference to "for

Bug#168201: Bug Not Found -- Incorrect Cause or More Info Required

Based on my reading of the code, your SSL_xmit() routine never calls into the SSL library code if size==0. While I appreciate your report that adding the lines ... if (size == 0) // PTB fight new openssl bug return 0; ... "cured the problem", I believe you/someone will need to demonstr

Bug#449553: Bug Not Found - Fixed Upstream

Linux 2.6.32-5-686 #1 SMP Tue Mar 8 21:36:00 UTC 2011 i686 GNU/Linux Confirmed bug: With 0.9.8o-4squeeze1 # openssl ca -days 136500 -infiles newreq.pem -keyfile ca-key.pem Certificate Details: Serial Number: a3:34:04:d7:f6:40:89:4e Validity Not Before:

Bug#404700: Confirmed -- Proposed Patch

Confirmed bug in apps/req.c. When executed w/-batch argument, cannot retry input from user which fails min/max length check. Must instead fail. Proposed patch --- a/apps/req.c +++ b/apps/req.c @@ -1477,7 +1477,13 @@ #ifdef CHARSET_EBCDIC ebcdic2ascii(buf, buf, i); #endif -if(!req_

Bug#544763: Bug Not Found - Fixed Upstream

The enc manpage has been modified to properly reflect that -salt is the default in testing (1.0.0d-2). (Indeed, there are two new warnings on that page re ONLY using -nosalt for compability with older OpenSSL) I recommend this bug be closed. -- To UNSUBSCRIBE, email to debian-bugs-dist-req

Bug#561973: Not Found in 561973

As addendum to above, this was after successfully duplicating with 0.9.8o-4squeeze1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#561973: Not Found in 561973

Attempting to duplicate this in testing (1.0.0d-2) indicates that this was resolevd via change to file in upstream sources (file apps/dgst.c). $ openssl dgst -hmac mykey -sha1 -verify mykey.pub -signature outfile foo MAC and Signing key canno

Bug#88728: Likely Won't Fix -- Workaround

This is something you'd want to override in the application or maybe some environment variable. Agreed. However, I believe there is a solid argument that the current implementation satisfies that ... First, let me say that what I present here may be ... um ... inaccurate; i.e. 'dead wrong'

Bug#622820: Preliminary Patches

As you have noted, there are numerous POD errors in the documentation. Most, but not all of them, are due to the pod2man translator enforcing the rule that, if the first "item" value is numeric, then all subsequent item values in the same "over/back" set be the next integer. There are others,

Bug#481944: Bug Not Found -- Fixed Upstream

Both of these have been added to the man page in the upstream release... - hash now states it is an alias for -subject-hash HISTORY section now contains note re old/new has algorithms Before OpenSSL 0.9.8, the default digest for RSA keys was MD5. The hash algorithm used in the -subject

Bug#397507: Bug not Found -- User Configuration Required

The defaults are based on the values in the active configuration file. The active configuration file for “most” openssl subcommands is either: 1) Filename specified on command line with the –config option (man req in your case), or 2) Filename specified in OPENSSL_CONF env variable, or 3) /etc

Bug#332498: Offer of Help

I am interested in “dipping my toe in the water” and learning/evaluating whether I might one day want/earn the official role and responsibilities of a DM. It appears this project is still in need of help -- only two co-maintainers for a package of this size/complexity/important. I am therefor