Interestingly this appears to be a long-standing issue as I can't find any
version since Stretch that shows libesmtp-dev depending on libssl-dev.
Versions prior to 1.1.0 did not use pkg-config or Meson/Ninja build
system for that matter. This was the first iteration of the new build
system
I've taken a look at the diff of your fork. I'm about to be out of town
and away from my development box for the next two weeks in about 8 hours
so I can't do anything at this time... I'll let the NMU go through and
then pull your commit hash 96eb8e628c8e87200a208281e569523c8fb77bf8 in
and prepare
Haven't reached out to confirm with upstream but as the website states
"Swift Mailer integrates into any web app written in PHP 5, ..." I'm not
exactly certain PHP 7 is a concern. I have attempted to build latest
version 5.4.2 under Sid following the suggestions in the ticket and the
package
I believe I may have it fixed... I'm doing some final testing in my
build environment but I suspect I'll have the 1.16.0 package ready to go
shortly.
On 04/08/2016 05:18 PM, Barry Warsaw wrote:
> Okay, so I think the locale changes are enough to fix the FTBFS. I retried
> building in an Ubuntu
Yes, I'd taken a slightly different approach but got to the same results
that you are currently getting. I have included your approach as it is
much cleaner than what I'd hacked together.
Still trying to get to the bottom of those remaining failures causing
the test to fail and the build to
Package: gdm3
Version: 3.12.2-2.1
Severity: grave
Justification: renders package unusable
Performed routine aptitude upgrade and had new version of gdm installed.
Shutdown laptop and upon restart was no longer presented with the login
greeter. Gnome environment would work by getting to shell and
On 31.07.2014 17:43, Michael Biebl wrote:
Am 31.07.2014 17:38, schrieb Jeremy T. Bouse:
version. I'm therefore tagging as wontfix and will be closing it
unless you want to re-assign it to python-bzrlib.
Is that a threat?
Seriously, I don't mind where and how this is fixed. If you
tag +755910 wontfix
thanks
This bug report is useless to paramiko as the Conflict/Build-Conflict
is in python-bzrlib which I have absolutely no control of and if the
maintainer has decided this route than even when I upload a new version
of paramiko that addresses the underlying issue which
On 06/29/2014 01:05 AM, Salvatore Bonaccorso wrote:
Hi Jeremy,
With the conversion to Debhelper compat level 9, multiarch directories
are passed when running dh_auto_configure for --libdir and
--libexecdir, so the paths used to install the files needs some
adjustment.
Attached is
On 05/11/2014 09:16 PM, d...@debian.org wrote:
On Fri, May 09, 2014 at 02:54:57PM -0400, Jeremy T. Bouse wrote:
If this work was not done through the very public, very accessible Git repo
that is used to manage the package then it has wasted your time and made
mine harder as I've already been
On 05/11/2014 10:33 PM, d...@debian.org wrote:
On Sun, May 11, 2014 at 09:37:21PM -0400, Jeremy T. Bouse wrote:
https://github.com/jbouse-debian/paramiko/commits/master
i saw http://anonscm.debian.org/gitweb/?p=collab-maint/paramiko.git
from p.q.d.o information. i did not know you worked
On 09.05.2014 09:48, d...@debian.org wrote:
tags 718004 + patch
tags 718004 + pending
thanks
Dear maintainer,
I've prepared an NMU for paramiko (versioned as 1.10.1-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.
If this work was not done through
:50 PM, Jeremy T. Bouse wrote:
Not my problem... You put the burden on me, I'm giving you the
burden since
you obviously took the time failing to contact me to ask and
ascertain
whether the maintainer might actually be in the process of doing
anything
with the package.
I read the bug traffic
Typically one would contact the maintainer before doing an NMU which
you failed to do. If you had you would have been informed that I'm
waiting on the new upstream maintainer to make the release merging
paramiko and it's fork that would fix most of the issues with the
current code base the
the bugs worked out of it before I upload it and
let you take over.
On 12.11.2012 21:18, Michael Gilbert wrote:
On Mon, Nov 12, 2012 at 9:08 PM, Jeremy T. Bouse wrote:
Typically one would contact the maintainer before doing an NMU which
you
failed to do.
Quite the contrary. The message you just
, the issues are
resolved in the new upstream release so as far as I'm concerned their
wont-fix issues in this version. But as I'm turning the package over
to you, do what you like.
On 12.11.2012 21:43, Michael Gilbert wrote:
On Mon, Nov 12, 2012 at 9:34 PM, Jeremy T. Bouse wrote:
Thank you
I would tend to agree with your assessment of the situation. I need to
go back and evaluate it all as I wasn't the one that added the patch, it
was done by an NMU without my involvement which is why I dislike NMUs
being done on my packages as they tend to introduce more issues than solve.
On 07/04/2012 08:57 PM, Luk Claes wrote:
tags 668239 + pending
thanks
Dear maintainer,
I've prepared an NMU for paramiko (versioned as 1.7.7.1-2.1) and
will have it uploaded soon.
Cheers
Luk
Any reason you felt that you couldn't actually follow the process I'd
already
severity 589167 minor
thanks
Sounds as if your have the apt-mirror.lock file still existing in your
var_path directory from a failed attempt to execute. Apt-mirror will not
remove that file as it has no way to tell if it is actually still
running or not, that's for an operator to
tags 576697 upstream
severity 576697 minor
forwarded 576697 robeypoin...@gmail.com
stop
I believe this is partially fixed now that python-crypto 2.1.0 has made
it's way into the distribution mirrors.
r...@solitare:/# dpkg -l python-paramiko python-crypto
forwarded 572960 libes...@stafford.uklinux.net
tags 572960 upstream
thanks
Brian,
I've had this bug [1] filed and given a grave status as it relates to
NULL bytes in the commonNames of certificates. I've not tried to dig
into it myself as I'm not that familiar with it but was merely
Looks good, I'll go ahead and accept and incorporate and get a
0.9.5.dfsg-6 release uploaded as soon as I get back home.
Carsten Hey wrote:
tags 571416 + patch
thanks
Dear maintainer,
I've prepared an NMU for libgcgi (versioned as 0.9.5.dfsg-5.1) and
uploaded it to DELAYED/10. I
Yes, according to Python Crypto's upstream changelog [1] which the
Debian changelog [1] makes no mention of, there were API changes to
Crypto.Util.randpool.RandomPool so this will wait until upstream
paramiko releases a new version that is compatible with the new version.
If I rebuild and simply
Nussbaum wrote:
tags 571316 - unreproducible wontfix
reopen 571416
thanks
(You typoed the bug number)
On 25/02/10 at 15:50 +0100, Lucas Nussbaum wrote:
reopen 571316
thanks
On 25/02/10 at 09:36 -0500, Jeremy T. Bouse wrote:
tags 571316 + unreproducible wontfix
forcemerge 560580
/02/10 at 10:09 -0500, Jeremy T. Bouse wrote:
tags 571416 + unreproducible wontfix
thanks
Doesn't change the fact I can't reproduce it and won't be wasting any
time tracking it down as it's unproducible. So until you can provide a
patch showing me it's the package and not your build system here
Moritz Muehlenhoff wrote:
Gerfried Fuchs wrote:
Hi again!
* Jeremy T. Bouse jbo...@debian.org [2010-02-01 18:19:31 CET]:
Moritz Muehlenhoff wrote:
An additional possibility might be to limit the scope of security support
to local, trusted users behind an authenticated HTTP zone. We're
Gerfried Fuchs wrote:
Hi!
* Jeremy T. Bouse jbo...@debian.org [2009-11-27 19:30:47 CET]:
I am currently working on getting 1.4.4 ready to go and remove David
Gil from the package per (#551636)
Actually, I'm not sure, does this address Moritz' concerns, from a
security team's
Gerfried Fuchs wrote:
Hi!
* Jeremy T. Bouse jbo...@debian.org [2010-02-01 16:12:06 CET]:
Gerfried Fuchs wrote:
* Jeremy T. Bouse jbo...@debian.org [2009-11-27 19:30:47 CET]:
I am currently working on getting 1.4.4 ready to go and remove David
Gil from the package per (#551636
Moritz Muehlenhoff wrote:
Gerfried Fuchs wrote:
Hi!
* Jeremy T. Bouse jbo...@debian.org [2010-02-01 16:12:06 CET]:
Gerfried Fuchs wrote:
* Jeremy T. Bouse jbo...@debian.org [2009-11-27 19:30:47 CET]:
I am currently working on getting 1.4.4 ready to go and remove David
Gil from
I suggest there might be something wrong with the amd64 build box
you're using as the buildd report [1] shows that 0.9.5.dfsg-5 was built
successfully Dec 12th. I've also re-downloaded the 0.9.5.dfsg-5 version
from the mirrors and rebuilt under a pbuilder chroot and it built
successfully
Lucas Nussbaum wrote:
On 24/12/09 at 12:04 -0500, Jeremy T. Bouse wrote:
I suggest there might be something wrong with the amd64 build box
you're using as the buildd report [1] shows that 0.9.5.dfsg-5 was built
successfully Dec 12th. I've also re-downloaded the 0.9.5.dfsg-5 version
from
Lucas Nussbaum wrote:
On 24/12/09 at 13:02 -0500, Jeremy T. Bouse wrote:
Lucas Nussbaum wrote:
On 24/12/09 at 12:04 -0500, Jeremy T. Bouse wrote:
I suggest there might be something wrong with the amd64 build box
you're using as the buildd report [1] shows that 0.9.5.dfsg-5 was built
The paramiko package contains only the upstream files... I'm unaware of
fabric and why it would have a copy of paramiko's files in it's build
rather than depending on paramiko if it uses it.
Ralf Treinen wrote:
Package: fabric,python-paramiko
Version: fabric/0.9.0-1
Version:
Kurt Roeckx wrote:
Source: libgcgi
Version: 0.9.5.dfsg-3
Severity: serious
Hi,
There was an error while trying to autobuild your package:
Start Time: 20091128-0635
[...]
Build-Depends: debhelper (= 7), autotools-dev, libssl-dev, dpatch
[...]
Toolchain package versions:
I am currently working on getting 1.4.4 ready to go and remove David
Gil from the package per (#551636)
signature.asc
Description: OpenPGP digital signature
Unless you can supply evidence that a recent version of acidbase still
produces this error I'm leaning towards closing this bug as 1.3.9 is the
latest version in Debian and I'm working on 1.4.4. 1.2.7 is too old to
even bother with as it shouldn't be being built on Lenny anyway.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Then it will be fixed when I get 1.7.4 packaged and uploaded. Right now
I'm under a deadline at work and paycheck trumps volunteering. I'll get
it up as soon as possible though.
Matthias Klose wrote:
Package: paramiko
Version: 1.7.3-1
Lucas Nussbaum wrote:
On 11/05/07 at 11:02 -0400, Jeremy T. Bouse wrote:
I do not agree with the removal and find the suggestion of it a slap in
the face for the time spent trying to work with upstream to get the
licensing issues that would allow the fix to be done.
Hi Jeremy
Lucas Nussbaum wrote:
On 15/10/07 at 08:33 -0400, Jeremy T. Bouse wrote:
Lucas Nussbaum wrote:
On 11/05/07 at 11:02 -0400, Jeremy T. Bouse wrote:
I do not agree with the removal and find the suggestion of it a slap in
the face for the time spent trying to work
Micha Lenk wrote:
tags 377372 fixed-upstream
stop
Hi,
On Sat, May 05, 2007 at 10:16:52PM +0200, Thijs Kinkhorst wrote:
libphp-phplot does not depend on php5, only php3 and php4. As php4 is about
to
be removed from the archive, this package will become uninstallable. Please
check
on it as it is LGPL licensed as well?
Regards,
Jeremy T. Bouse
signature.asc
Description: OpenPGP digital signature
I do not agree with the removal and find the suggestion of it a slap in
the face for the time spent trying to work with upstream to get the
licensing issues that would allow the fix to be done.
Michael Ablassmeier wrote:
Package: php-image-canvas
Version: 0.2.2-1
Severity: serious
I do not agree with the removal and find the suggestion of it a slap in
the face for the time spent trying to work with upstream to get the
licensing issues that would allow the fix to be done.
Michael Ablassmeier wrote:
Package: php-image-canvas
Version: 0.2.2-1
Severity: serious
I do not agree with the removal and find the suggestion of it a slap in
the face for the time spent trying to work with upstream to get the
licensing issues that would allow the fix to be done.
Michael Ablassmeier wrote:
Package: php-image-graph
Version: 0.7.1-1
Severity: serious
Gee... did you bother to actually look and see if a bug report had
already been made? If you would you would have found that it was already
filed against libfwbuilder and which I've already answered.
Andreas Niemann wrote:
Package: fwbuilder
Version: 2.1.8-1
Severity: grave
I'm currently dealing with password recovery for Alioth at this time. I
expect to get that dealt with in short order as soon as I get the email.
After doing so I'm going to begin working towards setting up an Alioth
project for Xen packaging. I've got two i386 and one amd64 machines
I've got the Alioth project (pkg-xen) created and I'm currently working
to get things setup and configured within the project. I've already
gotten Guido added to the project at this time as well.
As Saku had mentioned Ralph, I've been in communication with Ralph as
well along with
Given that this bug regarded Xen in Sarge which has since been
released and given that Xen has since been updated upstream as evident
by other wishlist bugs already filed, I'd like to get a status from
doogie on where Xen packaging is at this point.
There are several other unofficial
Steve,
Thank you, I've been swamped with work, consulting and newly
re-married life so I've not had time to get to it. Thank you for doing
this. I'll just incorporate them into the new upstream release packaging
before I upload it.
Regards,
Jeremy
Steve Langasek wrote:
tags 344254
This would be because of rushed NMU that I did not do. I'll fix it
when I get 2.0.10 ready for upload.
Regards,
Jeremy
Matthijs Mohlmann wrote:
Package: libfwbuilder6c2a
Severity: serious
Justification: Policy 7.3
Hi,
The package fails to upgrade from libfwbuilder6c2 to
of this it is no wonder I'm growing tired of people not
knowing the full details performing NMUs on my packages and there being
very few that I feel confident about doing one.
Regards,
Jeremy
Steve Langasek wrote:
On Wed, Dec 21, 2005 at 06:06:03AM -0800, Jeremy T. Bouse wrote
Well hopefully we'll finally stop having to keep renaming libraries
because of ABI and other compiler problems and this won't be an issue...
I'll get it fixed as soon as possible but my work that I actually get
paid for will come first.
Regards,
Jeremy
Nathanael Nerode wrote:
That would be because you have been caught running unstable and
running fwbuilder 2.0.7 with libfwbuilder 2.0.9... libfwbuilder 2.0.9 is
wanting to upgrade the XML files to 2.0.9 but fwbuilder 2.0.7 does not
have the XSLT files for 2.0.9.
Wait until fwbuilder 2.0.9 is uploaded!
Sylvain
Please tell me you're not wasting my time with this while I'm
working to get 2.0.9 packaged? Of course fwbuilder 2.0.7 is going to
fail to build when I uploade 2.0.9 libfwbuilder. I have to get
libfwbuilder into the mirror before I can upload fwbuilder 2.0.9 for
this precise reason. Quit
Can have the untested packages uploaded tonite if that's fast
enough. Otherwise I'll have it tested and uploaded Saturday before I
leave for my wedding in Las Vegas.
Regards,
Jeremy
Steve Langasek wrote:
On Tue, Nov 08, 2005 at 11:20:35AM -0800, Jeremy T. Bouse wrote:
Please
tags 334404 moreinfo unreproducible
thanks
I have tried again on my system (AMD64) using my *.fwb data file
which uses most, if not all, of the features of fwbuilder and have had
no problems producing my iptables script. I suspect the issue is a
problem with your fwbuilder data file
The latest unstable upload of fwbuilder *is* 2.0.7-2. The latest
unstable upload of libfwbuilder is 2.0.7-5. I have verified that these
are available on the mirror for atleast half the supported arches.
Regards,
Jeremy
James Hughes wrote:
Pardon my ignorance, but where can I get
This problem is actually caused by a problem with libfwbuilder
2.0.7-4 which is already corrected in 2.0.7-5 which was uploaded last
night as part of the fix for Bug#331575.
Regards,
Jeremy
Michael Setzer wrote:
Hi,
I just installed the Debian unstable packages:
ii fwbuilder
not NMU *ANY* of my packages
without direct direction to do so from me, the DPL or the release
manager as you obviously failed to research the situation.
Regards,
Jeremy
Luk Claes wrote:
Jeremy T. Bouse wrote:
Next time I would appreciate it if you followed section 5.11.1
Next time I would appreciate it if you followed section 5.11.1 of
the Developers Reference a bit more closely.
You did submit a bug report, atleast the snmp dependency was one
that actually did not already have a report submitted on; however giving
less than 24 hours before you uploaded
You're waiting on me to get 2.0.9 which was released yesterday
packaged and tested. Which is in itself dependent on available time
which right now has a great deal of time taking up with an 8 hour
full-time job, 5 hours commuting, working on tasks for paying consulting
clients and preparing
Did you fail to read any of the other bugs that are caused by the C++
ABI transition (#324874, #327017, #327365 or even #327826) and think
this might better fit with one of them? All of them mention the fact
that fwbuilder is broken because of the C++ ABI transition. Why did this
require yet
Thank you for filing a duplicate bug as #324874 way to read existing bug
reports
andreas baetz wrote:
Package: fwbuilder
Version: 2.0.7-1
Severity: grave
Justification: renders package unusable
After upgrading to kde 3.4.2-2 fwbuilder does not install anymore:
# apt-get install fwbuilder
Looks fine to me... I will be sure to include it and #322690 into
the 2.0.8 packaging I've been currently working on. Can you please
forward details on how/why regarding the renaming for my information as
I'm obviously behind on the info relating to the ABI changes.
Regards,
Jeremy
Maintainer has been unable to do anything with it since life
happens and currently writing this email against medical advice to limit
computer usuage to work only as I'm currently dealing with tendonitus.
Please go ahead with any NMU necessary to clear existing bug reports.
65 matches
Mail list logo
