Bug#1071322: Bug#1068782: Bug#1071322: News on those issues?

[Jeremy T. Bouse]

My dev machine is currently DOA, and I'm still working on rebuilding it.

On Sat, Sep 7, 2024 at 3:39 AM Salvatore Bonaccorso 
wrote:

> Hi Jeremy,
>
> On Thu, Aug 01, 2024 at 07:22:34AM +0200, Salvatore Bonaccorso wrote:
> > Hi Jeremy,
> >
> > On Sun, Jun 30, 2024 at 02:47:41PM +0200, Salvatore Bonaccorso wrote:
> > > Hi Jeremy,
> > >
> > > On Mon, Jun 17, 2024 at 04:31:04PM -0400, Jeremy T. Bouse wrote:
> > > > Upstream had been MIA for years; its last release was in 2010. It
> appears
> > > > he has finally returned, but I haven't had time to deal with the new
> > > > version that was released two weeks ago.
> > >
> > > Thanks for the answer.
> > >
> > > Question: will you find time to deal with those issues, before 17th of
> > > upciming month? Because then libesmtp and reverse dependencies will be
> > > removed otherwise from trixie.
> >
> > FWIW, libesmtp and its reverse dependencies are now removed from
> > testing, so I'm pretty much interested seeing it in trixie.
> >
> > Upstream has not responded to the Ubuntu proposed patches in
> > https://github.com/libesmtp/libESMTP/issues/21 .
> >
> > Can you try to approach upstream to see if upstream can deal with the
> > issue in their preferred way and we can cherry-pick the fixes as
> > needed?
>
> Any news here? Currently libesmtp and reverse dependencies are out of
> Debian trixie/testing and the package needs to come back before the
> freeze.
>
> Regards,
> Salvatore
>


-- 

Jeremy T. Bouse

Sr. DevOps Engineer

321.525.3280

UnderGrid.net <https://undergrid.net/>

<https://www.credly.com/badges/69208741-17c8-4876-a5c0-bcaa9078ba29>
<https://www.credly.com/badges/8613a442-3830-42c9-a629-8e1576dfec5e>

Bug#1068782: Bug#1071322: News on those issues?

[Jeremy T. Bouse]

Upstream had been MIA for years; its last release was in 2010. It appears
he has finally returned, but I haven't had time to deal with the new
version that was released two weeks ago.

On Mon, Jun 17, 2024 at 4:09 PM Salvatore Bonaccorso 
wrote:

> Hi Jeremy,
>
> Any news on #1068782 and #1071322?  There are a couple of reverse
> dependencies as well scheduled for autoremoval if libesmtp is removed.
>
> Regards,
> Salvatore
>


-- 

Jeremy T. Bouse

Sr. DevOps Engineer

321.525.3280

UnderGrid.net <https://undergrid.net/>

<https://www.credly.com/badges/69208741-17c8-4876-a5c0-bcaa9078ba29>
<https://www.credly.com/badges/8613a442-3830-42c9-a629-8e1576dfec5e>

Bug#997697: libesmtp-dev: Missing dependency on libssl-dev

[Jeremy T. Bouse]

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 changes.

Working on an updated version and hopefully will have it released shortly
for you try.



On Sun, Oct 24, 2021 at 8:09 AM Salvatore Bonaccorso 
wrote:

> Package: libesmtp-dev
> Version: 1.1.0-2
> Severity: serious
> Justification: Missing dependency
> X-Debbugs-Cc: car...@debian.org
>
> Hi
>
> libesmtp-1.0.pc contains
>
> Requires.private: openssl >= 1.1.0
>
> but the libesmtp-dev binary package misses a Depends on libssl-dev
> accordingly.
>
> Accordingly:
>
> $ pkg-config --print-errors --exists libesmtp-1.0
> Package openssl was not found in the pkg-config search path.
> Perhaps you should add the directory containing `openssl.pc'
> to the PKG_CONFIG_PATH environment variable
> Package 'openssl', required by 'libesmtp-1.0', not found
>
> Regards,
> Salvatore
>

Bug#844254: NMU to DELAYED/5

[Jeremy T. Bouse]

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 a 1.0.6-5 build to accept it.


On 11/18/2016 5:52 PM, Hilko Bengen wrote:
> Hi,
>
> I have just made a non-maintainer upload (libesmtp/1.0.6-4.1) to
> DELAYED/5-day. If necessary, feel free to reschedule or cancel my
> upload.
>
> The simple change I made can be found in my Github fork at
> . I have verified that the libesmtp6
> package (built using sbuild) indeed depends on libssl1.1.
>
> Cheers,
> -Hilko

Bug#821617: Bumping severity of PHP 7.0 transition bugs to serious

[Jeremy T. Bouse]

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 doesn't pass lintian checks when it uses php-cli instead of
php5-cli. The build itself is using pkg-php-tools to build and it is
simply a PHP class not compiled code.

On 5/5/2016 4:20 AM, Ondřej Surý wrote:
> Dear maintainer(s),
>
> I am bumping the severity of this bug to serious, as we are going to
> remove src:php5 from Debian and your package is blocking the first
> step which is removal of php5 from testing.  Please either update your
> package to support PHP 7.0 or remove the package from Debian unstable
> alltogether.
>
> Cheers,
> Ondrej
>

Bug#804582: (no subject)

[Jeremy T. Bouse]

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 PPA and the build succeeded.
> 
> The timeout failure must just have been a problem with my local sbuild.
> 

Bug#804582: (no subject)

[Jeremy T. Bouse]

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 cease.

On 04/07/2016 06:28 PM, Barry Warsaw wrote:
> I'm running across this too now.  I think part of the problem is that pybuild
> invokes unittest discover by default, but this isn't how paramiko's test suite
> is actually run, at least if you go by what's in the tox.ini file.
> 
> This gets me closer:
> 
> diff --git a/debian/rules b/debian/rules
> index 9c04662..8d5d25b 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -1,6 +1,7 @@
>  #!/usr/bin/make -f
>  
>  export PYBUILD_NAME=paramiko
> +export PYBUILD_TEST_ARGS={interpreter} $(CURDIR)/test.py
>  
>  %:
>   dh $@ --with python2,python3 --buildsystem=pybuild
> @@ -11,3 +12,5 @@ ifeq (,$(findstring nodocs, $(DEB_BUILD_OPTIONS)))
>  endif
>   dh_installdocs
>  
> +override_dh_auto_test:
> + PYBUILD_SYSTEM=custom dh_auto_test
> 
> 
> But I'm still seeing two failures and two errors:
> 
> ==
> ERROR: test_K_utf8 (tests.test_sftp.SFTPTest)
> --
> Traceback (most recent call last):
>   File "/<>/tests/test_sftp.py", line 171, in tearDown
> sftp.rmdir(FOLDER)
>   File "/<>/paramiko/sftp_client.py", line 390, in rmdir
> self._request(CMD_RMDIR, path)
>   File "/<>/paramiko/sftp_client.py", line 729, in _request
> return self._read_response(num)
>   File "/<>/paramiko/sftp_client.py", line 776, in _read_response
> self._convert_status(msg)
>   File "/<>/paramiko/sftp_client.py", line 806, in 
> _convert_status
> raise IOError(text)
> IOError: Failure
> 
> ==
> ERROR: test_L_utf8_chdir (tests.test_sftp.SFTPTest)
> --
> Traceback (most recent call last):
>   File "/<>/tests/test_sftp.py", line 679, in test_L_utf8_chdir
> sftp.mkdir(FOLDER + '/' + unicode_folder)
>   File "/<>/paramiko/sftp_client.py", line 380, in mkdir
> self._request(CMD_MKDIR, path, attr)
>   File "/<>/paramiko/sftp_client.py", line 729, in _request
> return self._read_response(num)
>   File "/<>/paramiko/sftp_client.py", line 776, in _read_response
> self._convert_status(msg)
>   File "/<>/paramiko/sftp_client.py", line 806, in 
> _convert_status
> raise IOError(text)
> IOError: Failure
> 
> ==
> FAIL: test_K_utf8 (tests.test_sftp.SFTPTest)
> --
> Traceback (most recent call last):
>   File "/<>/tests/test_sftp.py", line 675, in test_K_utf8
> self.fail('exception ' + str(e))
> AssertionError: exception Failure
> 
> ==
> FAIL: test_O_getcwd (tests.test_sftp.SFTPTest)
> --
> Traceback (most recent call last):
>   File "/<>/tests/test_sftp.py", line 734, in test_O_getcwd
> self.assertEqual(None, sftp.getcwd())
> AssertionError: None != u'/'
> 
> --
> Ran 148 tests in 34.596s
> 
> FAILED (failures=2, errors=2)
> 




signature.asc
Description: OpenPGP digital signature

Bug#759745: gdm3: Unable to login post-upgrade without systemd-sysv installed

[Jeremy T. Bouse]

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 running
startx but was presented with a systemd-login error on the console shell
when logging in. Installed systemd-sysv which purged sysinit-core, rebooted
and the system was once again usable.

Suggest that there is a dependency not properly resolving in there to
ensure that systemd is running as PID 1.


-- System Information:
Debian Release: jessie/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gdm3 depends on:
ii  accountsservice  0.6.37-3
ii  adduser  3.113+nmu3
ii  dconf-cli0.20.0-2
ii  dconf-gsettings-backend  0.20.0-2
ii  debconf [debconf-2.0]1.5.53
ii  gir1.2-gdm3  3.12.2-2.1
ii  gnome-session [x-session-manager]3.12.1-3
ii  gnome-session-bin3.12.1-3
ii  gnome-session-flashback [x-session-manager]  3.8.1-1
ii  gnome-settings-daemon3.12.2-1
ii  gnome-shell  3.12.2-3
ii  gnome-terminal [x-terminal-emulator] 3.12.3-2
ii  gsettings-desktop-schemas3.12.2-1
ii  libaccountsservice0  0.6.37-3
ii  libatk1.0-0  2.12.0-1
ii  libaudit11:2.3.7-1
ii  libc62.19-9
ii  libcairo-gobject21.12.16-2
ii  libcairo21.12.16-2
ii  libcanberra-gtk3-0   0.30-2
ii  libcanberra0 0.30-2
ii  libgdk-pixbuf2.0-0   2.30.7-1
ii  libgdm1  3.12.2-2.1
ii  libglib2.0-0 2.40.0-4
ii  libglib2.0-bin   2.40.0-4
ii  libgtk-3-0   3.12.2-3
ii  libpam-modules   1.1.8-3.1
ii  libpam-runtime   1.1.8-3.1
ii  libpam-systemd   208-8
ii  libpam0g 1.1.8-3.1
ii  libpango-1.0-0   1.36.6-1
ii  libpangocairo-1.0-0  1.36.6-1
ii  librsvg2-common  2.40.3-1
ii  libselinux1  2.3-1
ii  libsystemd-daemon0   208-8
ii  libsystemd-id128-0   208-8
ii  libsystemd-journal0  208-8
ii  libsystemd-login0208-8
ii  libwrap0 7.6.q-25
ii  libx11-6 2:1.6.2-3
ii  libxau6  1:1.0.8-1
ii  libxdmcp61:1.1.1-1
ii  libxrandr2   2:1.4.2-1
ii  lsb-base 4.1+Debian13
ii  metacity [x-window-manager]  1:3.12.0-2
ii  policykit-1  0.105-6.1
ii  ucf  3.0030
ii  x11-common   1:7.7+7
ii  x11-xserver-utils7.7+3
ii  xterm [x-terminal-emulator]  308-1

Versions of packages gdm3 recommends:
ii  at-spi2-core   2.12.0-2
ii  desktop-base   7.0.3
ii  gnome-icon-theme   3.12.0-1
ii  gnome-icon-theme-symbolic  3.12.0-1
ii  x11-xkb-utils  7.7+1
ii  xserver-xephyr 2:1.16.0-1
ii  xserver-xorg   1:7.7+7
ii  zenity 3.12.1-1.1

Versions of packages gdm3 suggests:
ii  gnome-orca3.12.2-1
ii  libpam-gnome-keyring  3.8.2-2+b1

-- debconf information:
* shared/default-x-display-manager: gdm3
  gdm3/daemon_name: /usr/sbin/gdm3


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#755910: collides with python-bzrlib

[Jeremy T. Bouse]

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, as
maintainer think this needs to be handled in python-bzrlib, by all 
means

re-assign it.
The current situation as it stands though is, that this combination 
of

package is not installable, which to me is RC.


No, it's not a threat. It's just the fact that this BTS ticket has 
absolutely nothing to do with python-paramiko package as it is 
python-bzrlib that put a Conflict in place. The problem with paramiko 
already has it's own ticket and it's being addressed by an upstream 
ticket already as well. The python-bzrlib made their package 
uninstallable on purpose and I can't do anything about that. Even when I 
get the fixed version of paramiko uploaded and available through the 
mirror network, python-bzrlib will still be uninstallable until it 
releases a new version removing the Conflict. In my opinion that only 
makes matters worse. Nothing I will do will affect python-bzrlib being 
installable. Therefore this ticket is a "wontfix" ticket as there is no 
"cantfix" tag.



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#755910: collides with python-bzrlib

[Jeremy T. Bouse]

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 is already 
reported as #750517 and has been forwarded to the paramiko upstream 
python-bzrlib will still be uninstallable until it uploads a new 
version. I'm therefore tagging as "wontfix" and will be closing it 
unless you want to re-assign it to python-bzrlib.


On 24.07.2014 09:15, Michael Biebl wrote:

Package: python-paramiko
Version: 1.14.0-2
Severity: serious

python-paramiko is no longer installable once bzr is installed, since
the latest python-bzrlib has a Conflicts against python-paramiko >= 
1.12.


The python-bzrlib changelog suggests that python-paramiko needs an
update:

  * Conflict and build-conflict with newer versions of paramiko that 
no
longer accept 'buffer' objects. This is a stop-gap until paramiko 
is

fixed. Closes: #750347


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages python-paramiko depends on:
ii  python 2.7.8-1
ii  python-crypto  2.6.1-5+b1
ii  python-ecdsa   0.11-1

python-paramiko recommends no packages.

python-paramiko suggests no packages.

-- no debconf information



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753027: libesmtp6: does not ship libesmtp.so.6

[Jeremy T. Bouse]

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 proposed debdiff.
> 
> Regards,
> Salvatore
> 


Salvatore,

Thank you... I've taken a look at your debdiff and incorporated the fix
into my package repo [1] with credit given. I'll work on getting the
fixed package uploaded this evening when I'm back at home and can get my
DSA key out of my vault to sign it as apparently keymaster is having
trouble getting my new RSA key to be accepted.

Regards,
Jeremy

1.
https://github.com/jbouse-debian/libesmtp/commit/0c21ed1f98c16946b2d81e5abe54181fdc3ad614



signature.asc
Description: OpenPGP digital signature

Bug#718004: paramiko: diff for NMU version 1.10.1-1.1

[Jeremy T. Bouse]

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 github repo.
> so i misunderstood this package was not active about half year.
> i cancelled my NMU.  sorry to give you many trouble.
> 

I began to make the move over to GitHub after repeated unreliability
with anonscm.d.o when I tried to access it in the past and because that
is what upstream utilizes so it allows me to track both easily. I began
the GitHub repo from the anonscm repo copy that I had off-line locally
during one such outage and haven't bothered trying to keep it updated.
As soon as I release a new upload with the Vcs-* lines in debian/control
updated I'll get that repo removed.

Again this confusion would have easily been cleared up with an email
to the maintainer, who as you can tell does respond to them.



signature.asc
Description: OpenPGP digital signature

Bug#718004: paramiko: diff for NMU version 1.10.1-1.1

[Jeremy T. Bouse]

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 working on 1.10.1. So for wasting the time
>> that I do have I thank you.
> 
> if this DELAYED NMU could put pressure or somthing on you, i am really sorry.
> if your working goes on, i will cancel my NMU.  please tell me.
> 

https://github.com/jbouse-debian/paramiko/commits/master

I've been working on 1.12.2 even though 1.14.0 is released as well but
between
1.10 and 1.12 was fork, merge and change of upstream which has made the
process
as simple. Then complicated by still trying to get my new 4096 bit RSA
key into
the keyring and issues at work which have delayed my time to actually
work on it.

Attempt to help work within the packaging done within Git would have
been much more
helpful. As well I recall more than a couple tickets which looking
through would
have identified efforts being made before attempts to do a NMU without
having
first attempted contact with the maintainer of the package in question.

I guess I expect more of Debian Developers but this seems to be a
continuing trend
those that have joined the project within the past 3-5 years now. I
might suggest
going back to the Developers Corner and re-reading the content... Maybe
starting
with https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu



signature.asc
Description: OpenPGP digital signature

Bug#718004: paramiko: diff for NMU version 1.10.1-1.1

[Jeremy T. Bouse]

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 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 working on 1.10.1. So for wasting 
the time that I do have I thank you.



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#682050: nmu

[Jeremy T. Bouse]

Now see if you had contacted the maintainer prior to performing the NMU 
upload you would have found out that your information was in fact 
flawed. BTS #690080 was to inform of the new upstream maintainer only a 
month ago and I've been in contact privately. Furthermore 1.9 was only 
released within the last week by said new upstream maintainer. That my 
friend is why you contact the maintainer and find out if assistance is 
in fact needed or else you're just mucking shit up and pissing the 
maintainer off considerably.


On 12.11.2012 22:17, Michael Gilbert wrote:

On Mon, Nov 12, 2012 at 9: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, and the latest maintainer activity was four
months ago.  That's usually a strong indicator that the package needs
help.

The RC issues were introduced by a previous NMU, the issues are 
resolved in
the new upstream release so as far as I'm concerned their "wont-fix" 
issues

in this version.


I understand that this was introduced by the prior nmu, and that's 
why

this nmu is reverting that broken one.


But as I'm turning the package over to you, do what you like.


You may as well orphan it so it can get cared for either by the QA
team or someone who really cares about it.

Best wishes,
Mike



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#682050: nmu

[Jeremy T. Bouse]

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.


The RC issues were introduced by a previous NMU, 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 for volunteering to become the new paramiko package 
maintainer

since you have so much spare time.


I did this nmu to try to help make progress against the huge list of
rc issues we have in many packages.  I'm not that interested in this
one so much.

I'll be updating the debian/control file with the 1.9.0 upstream 
release as

soon as I've completed it.


The release team will probably not accept new upstream versions at
this point in the freeze.

Since you've put a gun to my head with the 8 day delay hopefully 
I'll get
all the bugs worked out of it before I upload it and let you take 
over.


That delay wasn't meant to be pressuring.  It was just a choice that
seemed kind of long.  Please feel free to go ahead and cancel it if
you need more time.

Best wishes,
Mike



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#682050: nmu

[Jeremy T. Bouse]

Thank you for volunteering to become the new paramiko package 
maintainer since you have so much spare time. I'll be updating the 
debian/control file with the 1.9.0 upstream release as soon as I've 
completed it. Since you've put a gun to my head with the 8 day delay 
hopefully I'll get all 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 replied to is my contact
prior to the nmu.  It has not happened yet.  It is currently in a 
kind

of limbo land called deferred.  Importantly, you have the power to
review it there and cancel it if you don't like it:
http://manpages.ubuntu.com/manpages/en/man1/dcut.1.html


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
patches introduced by the last NMU improperly fixed and caused 
regressions.


Thanks for the info.

Best wishes,
Mike



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#682050: nmu

[Jeremy T. Bouse]

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 patches introduced by the last NMU improperly 
fixed and caused regressions.


On 12.11.2012 18:21, Michael Gilbert wrote:

Hi, I've uploaded an nmu fixing this issue to delayed/8.  The extra
time is to give you a chance to do a maintainer upload taking into
account your stated dislike for nmus.  Please see attached patch.

Best wishes,
Mike



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#682050: fails to connect to server using non default port

[Jeremy T. Bouse]

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/28/2012 08:00 PM, Josh Triplett wrote:
> Package: python-paramiko
> Version: 1.7.7.1-3
> Followup-For: Bug #682050
> 
> As far as I can tell, no "original issue" exists.  Bug 668239 seems to
> complain that paramiko distinguishes between host keys for different
> ports on the same server.  That's not a bug, that's a feature, and
> removing it results in this bug.  The correct fix (which I've just
> tested) involves dropping hostkey.patch entirely.
> 
> - Josh Triplett
> 
> -- System Information:
> Debian Release: wheezy/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 
> Versions of packages python-paramiko depends on:
> ii  python 2.7.3-2
> ii  python-crypto  2.6-2
> 
> python-paramiko recommends no packages.
> 
> python-paramiko suggests no packages.
> 
> -- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#668239: paramiko: diff for NMU version 1.7.7.1-2.1

[Jeremy T. Bouse]

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 established to submit the patch to the VCS that the package is
maintained out of? I purposely put the package maintenance on
git.debian.org within collab-maint so that any DD could submit commits
for the package back. You obviously looked at the BTS so did you not
bother to check out the PTS and see it was in VCS?



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#589167: apt-mirror is already running, exiting at /usr/bin/apt-mirror line 187.

[Jeremy T. Bouse]

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 determine and clean up after a
failure. Also as var_path is configuration dependent there is no easy
way for the package management to remove it when you remove the package.

Look in your configuration file and determine where var_path is set to
and remove the apt-mirror.lock file in that path and apt-mirror should
execute. However, note that if the same issue that caused apt-mirror to
fail to execute and properly clean up it's lock file occurs again you
will have the same issue.



signature.asc
Description: OpenPGP digital signature

Bug#572960: #572960 - libesmtp does not check NULL bytes in commonNames of certificates

[Jeremy T. Bouse]

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
forwarding it on to you to look into. This has been assigned
CVE-2010-1192 and shows vulnerable in every version of libESMTP that is
within the Debian mirrors (1.0.3 and 1.0.4).

Regards,
Jeremy

1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572960

On 05/28/2010 01:45 AM, Salvatore Bonaccorso wrote:
> Hi all
> 
> On Fri, May 28, 2010 at 03:29:42AM +0200, Alexander Sack wrote:
>> Any update on this security issue?
> 
> There was an ongoing discussion about that, in [1] still. RedHat
> Bugtracker has two proposed patches too [2,3,4].
> 
>  [1] http://thread.gmane.org/gmane.comp.security.oss.general/2637
>  [2] https://bugzilla.redhat.com/attachment.cgi?id=399130&action=diff
>  [3] https://bugzilla.redhat.com/attachment.cgi?id=399131&action=diff
>  [4] https://bugzilla.redhat.com/show_bug.cgi?id=571817
> 
> Some comments on this?
> 
> Bests
> Salvatore




signature.asc
Description: OpenPGP digital signature

Bug#576697: python-paramiko: paramiko fails to load :, ImportError: No module named Crypto.Util.randpool

[Jeremy T. Bouse]

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
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ NameVersion Description
+++-===-===-==
ii  python-crypto   2.1.0-2 cryptographic algorithms and
protocols for Python
ii  python-paramiko 1.7.6-2 Make ssh v2 connections with
Python

Now paramiko does not produce an ImportError but rather a
DeprecationWarning which can be resolved by changes in upstream to not
call RandomPool in rng.py. Otherwise the deprecation warning should not
affect operations.

r...@solitare:/# python
Python 2.6.5+ (release26-maint, Jul  6 2010, 14:48:45)
[GCC 4.4.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import paramiko
/usr/lib/python2.6/dist-packages/Crypto/Util/randpool.py:40:
RandomPool_DeprecationWarning: This application uses RandomPool, which
is BROKEN in older releases.  See http://www.pycrypto.org/randpool-broken
  RandomPool_DeprecationWarning)



signature.asc
Description: OpenPGP digital signature

Bug#571416: libgcgi: diff for NMU version 0.9.5.dfsg-5.1

[Jeremy T. Bouse]

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 also commited my changes to collab-maint.
> 
> You touch Makefile.* to fix a previous FTBFS and let find decide which
> one to touch first which leads to the described problems with tmpfs.
> Now debian/rules takes this decision and this package builds even on
> weird build environments like autobuild clusters using tmpfs.
> 
> 
> Regards
> Carsten
> 




signature.asc
Description: OpenPGP digital signature

Bug#576697: python-paramiko: paramiko fails to load : ImportError: No module named Crypto.Util.randpool

[Jeremy T. Bouse]

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 state it requires python-crypto < 2.1.0 it will
simply make the package completely uninstallable.


[1]
http://gitweb.pycrypto.org/?p=crypto/pycrypto-2.x.git;a=blob;f=ChangeLog;h=9325e0d5592f075065b1cd86d27dc7dceda93c6b;hb=033fc936155115b3a541387804e0a94820978498
[2]
http://packages.debian.org/changelogs/pool/main/p/python-crypto/python-crypto_2.1.0-1/changelog

Julien Bigot wrote:
> Package: python-paramiko
> Version: 1.7.6-2
> Severity: grave
> Justification: renders package unusable
> 
> Hi,
> 
> paramiko fails to load on my system with the following backtrace:
> import paramiko
>   File "/usr/lib/pymodules/python2.5/paramiko/__init__.py", line 69, in 
> 
> from transport import randpool, SecurityOptions, Transport
>   File "/usr/lib/pymodules/python2.5/paramiko/transport.py", line 32, in 
> 
> from paramiko import util
>   File "/usr/lib/pymodules/python2.5/paramiko/util.py", line 32, in 
> from paramiko.common import *
>   File "/usr/lib/pymodules/python2.5/paramiko/common.py", line 98, in 
> from rng import StrongLockingRandomPool
>   File "/usr/lib/pymodules/python2.5/paramiko/rng.py", line 23, in 
> from Crypto.Util.randpool import RandomPool as _RandomPool
> ImportError: No module named Crypto.Util.randpool
> 
> I guess python-crypto somehow changed its API as it works well with
> python-crypto 2.0.1+dfsg1-5 for example.
> 
> Regards,
> Julien
> 
> -- System Information:
> Debian Release: squeeze/sid
>   APT prefers unstable
>   APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental')
> Architecture: i386 (i686)
> 
> Kernel: Linux 2.6.32-3-686 (SMP w/2 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 
> Versions of packages python-paramiko depends on:
> ii  python2.5.4-9An interactive high-level 
> object-o
> ii  python-crypto 2.1.0-1cryptographic algorithms and 
> proto
> ii  python-support1.0.7  automated rebuilding support for 
> P
> 
> python-paramiko recommends no packages.
> 
> python-paramiko suggests no packages.
> 
> -- no debconf information
> 
> 




signature.asc
Description: OpenPGP digital signature

Bug#571416: libgcgi: FTBFS: /bin/bash: line 11: automake-1.11: command not found

[Jeremy T. Bouse]

The package is already using dpatch to patch and upgrade libtool...
Adding automake causes more issues... The only problem appears to be in
building on your amd64 box because of tmpfs which no other buildd box
uses apparently so only you exhibit the problem.

Lucas Nussbaum wrote:
> On 25/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 it
>> shall remain until hell freezes over.
> 
> From my mail (but I don't think you read it):
> 
>>> After 5 minutes of investigation, which I'm sure you could have done
>>> yourself, here is the problem:
>>> if the filesystem has sub-second precision, like tmpfs (which I'm using)
>>> has, it will be used by make.
>>> libgcgi_0.9.5.dfsg.orig.tar.gz contains Makefile.in before Makefile.am,
>>> so Makefile.in ends up with a timestamp older than Makefile.am.
>>>
>>> *** lu...@beothuk:/dev/shm/libgcgi-0.9.5.dfsg$ stat Makefile.am 
>>>   File: `Makefile.am'
>>>   Size: 506 Blocks: 8  IO Block: 4096   regular file
>>> Device: 10h/16d Inode: 230 Links: 1
>>> Access: (0600/-rw---)  Uid: ( 1000/   lucas)   Gid: ( 1000/   lucas)
>>> Access: 2010-02-25 15:54:33.614583094 +0100
>>> Modify: 2010-02-25 15:54:25.890582840 +0100
>>> Change: 2010-02-25 15:54:25.890582840 +0100
>>> *** lu...@beothuk:/dev/shm/libgcgi-0.9.5.dfsg$ stat Makefile.in 
>>>   File: `Makefile.in'
>>>   Size: 22872   Blocks: 48 IO Block: 4096   regular file
>>> Device: 10h/16d Inode: 2556061 Links: 1
>>> Access: (0600/-rw---)  Uid: ( 1000/   lucas)   Gid: ( 1000/   lucas)
>>> Access: 2010-02-25 15:54:31.974609365 +0100
>>> Modify: 2010-02-25 15:54:25.882583570 +0100
>>> Change: 2010-02-25 15:54:25.882583570 +0100
>>>
>>> As a result, the refresh rule in Makefile is called, and fails.
> 
> Do you want me to provide a patch that adds automake to your build-deps,
> or can you do that?




signature.asc
Description: OpenPGP digital signature

Bug#571416: libgcgi: FTBFS: /bin/bash: line 11: automake-1.11: command not found

[Jeremy T. Bouse]

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 it
shall remain until hell freezes over.

Lucas 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 571416
>>> thanks
>>>
>>> This is a duplicated bug that has already been determined to be an
>>> issue with the amd64 build system in question and not an issue with the
>>> package that builds perfectly on every other arch and on other amd64
>>> machines. Continue wasting my time and I will immediately kill any bug
>>> filled by you with extreme prejudice. When you run a non-standard setup
>>> from every other build server it's not my problem.
>> It is not an issue why my build system, but with your package.
> 
> After 5 minutes of investigation, which I'm sure you could have done
> yourself, here is the problem:
> if the filesystem has sub-second precision, like tmpfs (which I'm using)
> has, it will be used by make.
> libgcgi_0.9.5.dfsg.orig.tar.gz contains Makefile.in before Makefile.am,
> so Makefile.in ends up with a timestamp older than Makefile.am.
> 
> *** lu...@beothuk:/dev/shm/libgcgi-0.9.5.dfsg$ stat Makefile.am 
>   File: `Makefile.am'
>   Size: 506   Blocks: 8  IO Block: 4096   regular file
> Device: 10h/16d   Inode: 230 Links: 1
> Access: (0600/-rw---)  Uid: ( 1000/   lucas)   Gid: ( 1000/   lucas)
> Access: 2010-02-25 15:54:33.614583094 +0100
> Modify: 2010-02-25 15:54:25.890582840 +0100
> Change: 2010-02-25 15:54:25.890582840 +0100
> *** lu...@beothuk:/dev/shm/libgcgi-0.9.5.dfsg$ stat Makefile.in 
>   File: `Makefile.in'
>   Size: 22872 Blocks: 48 IO Block: 4096   regular file
> Device: 10h/16d   Inode: 2556061 Links: 1
> Access: (0600/-rw---)  Uid: ( 1000/   lucas)   Gid: ( 1000/   lucas)
> Access: 2010-02-25 15:54:31.974609365 +0100
> Modify: 2010-02-25 15:54:25.882583570 +0100
> Change: 2010-02-25 15:54:25.882583570 +0100
> 
> As a result, the refresh rule in Makefile is called, and fails.




signature.asc
Description: OpenPGP digital signature

Bug#552235: acidbase: multiple security flaws, needs maintenance or removal?

[Jeremy T. Bouse]

Moritz Muehlenhoff wrote:
> Gerfried Fuchs wrote:
>>  Hi again!
>>
>> * Jeremy T. Bouse  [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 doing that
>>>> for a few applications already, e.g. sql-ledger or ocsinventory.
>>>> You wouldn't expose your accounting or hardware inventory to untrusted 
>>>> users and the same should apply to IDS results.
>>> In which case this is a non-issue to anyone who uses the default Apache
>>> configuration which limits access to localhost and has since 1.2.7.
> 
> We should make it explicit through the proper debtag, though. If you agree
> as the maintainer, I'll add the respective debtag and send a short note to
> t...@security.debian.org
> 

Sounds fine with me...

>>  In this case I guess we can close this bug for lenny. Is this fine with
>> you, Moritz?
>>
>>  Thanks for the quick responses!
>> Rhonda
> 
> We tagged the current issues as no-dsa anyway, so that's fine.
> 
> Cheers,
> Moritz




signature.asc
Description: OpenPGP digital signature

Bug#552235: acidbase: multiple security flaws, needs maintenance or removal?

[Jeremy T. Bouse]

Moritz Muehlenhoff wrote:
> Gerfried Fuchs wrote:
>>  Hi!
>>
>> * Jeremy T. Bouse  [2010-02-01 16:12:06 CET]:
>>> Gerfried Fuchs wrote:
>>>> * Jeremy T. Bouse  [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 point of view, especially with respect to stable? I
>>>> don't see any update that would have fixed the security issues for
>>>> lenny, what is your plan for that?
>>> 1.4.4 reportedly fixes all current outstanding CVS reports. Short of
>>> going and simply upgrading the old versions trying to go through the
>>> code and find the specific fixes to these issues, as I've found no patch
>>> files specific to the problem, would take much more time than I have
>>> available when a fixed upstream version is already available in the
>>> repository. 1.4.4-1 hit the unstable repository in late November and I
>>> had a few fixes until 1.4.4-3 was migrated to testing just before Christmas.
>>  You are aware that maintaining a package doesn't mean only taking care
>> for it in unstable but also to at least try to give the security team a
>> helping hand for trying to get things straight in a stable release? I
>> wonder, how severe are the issues actually? Is it better to pull the
>> package from the stable release (like Moritz suggested already) if you
>> don't see the posibility to get the issues fixed for stable, or do you
>> consider the issues minor enough to ignore them for this time - but what
>> will happen when more severe ones pop up?
> 
> An additional possibility might be to limit the scope of security support
> to local, trusted users behind an authenticated HTTP zone. We're doing that
> for a few applications already, e.g. sql-ledger or ocsinventory.
> You wouldn't expose your accounting or hardware inventory to untrusted 
> users and the same should apply to IDS results.
> 
> Cheers,
> Moritz

In which case this is a non-issue to anyone who uses the default Apache
configuration which limits access to localhost and has since 1.2.7.

   1 
   2   Alias /acidbase "/usr/share/acidbase"
   3 
   4
   5 
   6   Options +FollowSymLinks
   7   AllowOverride None
   8   order deny,allow
   9   deny from all
  10   allow from 127.0.0.0/255.0.0.0
  11   
  12 php_flag magic_quotes_gpc Off
  13 php_flag track_vars On
  14 php_value include_path .:/usr/share/php
  15   
  16 



signature.asc
Description: OpenPGP digital signature

Bug#552235: acidbase: multiple security flaws, needs maintenance or removal?

[Jeremy T. Bouse]

Gerfried Fuchs wrote:
>   Hi!
> 
> * Jeremy T. Bouse  [2010-02-01 16:12:06 CET]:
>> Gerfried Fuchs wrote:
>>> * Jeremy T. Bouse  [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 point of view, especially with respect to stable? I
>>> don't see any update that would have fixed the security issues for
>>> lenny, what is your plan for that?
>>  1.4.4 reportedly fixes all current outstanding CVS reports. Short of
>> going and simply upgrading the old versions trying to go through the
>> code and find the specific fixes to these issues, as I've found no patch
>> files specific to the problem, would take much more time than I have
>> available when a fixed upstream version is already available in the
>> repository. 1.4.4-1 hit the unstable repository in late November and I
>> had a few fixes until 1.4.4-3 was migrated to testing just before Christmas.
> 
>  You are aware that maintaining a package doesn't mean only taking care
> for it in unstable but also to at least try to give the security team a
> helping hand for trying to get things straight in a stable release? I
> wonder, how severe are the issues actually? Is it better to pull the
> package from the stable release (like Moritz suggested already) if you
> don't see the posibility to get the issues fixed for stable, or do you
> consider the issues minor enough to ignore them for this time - but what
> will happen when more severe ones pop up?
> 
>  Thanks,
> Rhonda

If I knew exactly what fixes occurred between 1.3.9 and 1.4.4 that
fixed the CVS reported problems I'd be more than happy to fix them and
get a new 1.3.9 version made available for the security team to release.
However, there are no patches that specifically identify fixing the
problem and trying to perform a diff between 1.3.9 and 1.4.4 garners so
many changes in the code base that identifying will take much more time
than I currently have.

All I know of the problem is from the vague information given in the
CVS reports which are all listed as medium or high as they report
cross-site scripting and SQL injection issues. BASE itself confirmed the
problem and released 1.4.4 to fix them.

If security team wants to simply pull 1.2.7-4 from etch (oldstable) and
1.3.9-1 from lenny (stable) go ahead  and recommend pulling acidbase
from squeeze/testing if it's required to be installed on any systems
running stable or oldstable. PopCon shows low numbers of installs though
doesn't distinquish if they are oldstable, stable, testing or unstable
installations.



signature.asc
Description: OpenPGP digital signature

Bug#552235: acidbase: multiple security flaws, needs maintenance or removal?

[Jeremy T. Bouse]

Gerfried Fuchs wrote:
>   Hi!
> 
> * Jeremy T. Bouse  [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 point of view, especially with respect to stable? I
> don't see any update that would have fixed the security issues for
> lenny, what is your plan for that?
> 
>  Thanks,
> Rhonda

1.4.4 reportedly fixes all current outstanding CVS reports. Short of
going and simply upgrading the old versions trying to go through the
code and find the specific fixes to these issues, as I've found no patch
files specific to the problem, would take much more time than I have
available when a fixed upstream version is already available in the
repository. 1.4.4-1 hit the unstable repository in late November and I
had a few fixes until 1.4.4-3 was migrated to testing just before Christmas.



signature.asc
Description: OpenPGP digital signature

Bug#562443: libgcgi: FTBFS: /bin/bash: line 11: automake-1.11: command not found

[Jeremy T. Bouse]

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
>>>> 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 as well. The -4 version of the package had a problem in the
>>>> debian/rules that caused this behavior but it was fixed in the -5 release.
>>> Could you please diff your log with mine, to see if the problem was
>>> possibly caused by different build-dep versions ?
>>>
>>  I'm building on i386 as my amd64 boxes are currently still offline
>> along with my hppa and alpha machines. The official amd64 buildd I sent
>> the URL that was available for the log. When looking through it I didn't
>> see any failures. However that log format and your log format are
>> completely different and do not lend themselves to diff comparison.
> 
> I'm talking about a build in an up-to-date sid chroot, not something
> that happened 10 days ago.

Here's the build for me... The source is from the mirror using dget and
not from the git repo [1] that it was originally built and submitted to
the mirror from. Prior to the build I did a 'pbuilder update' for
DIST=sid to ensure it was current.

Jeremy

[1] git://git.debian.org/collab-maint/libgcgi.git
I: using fakeroot in build.
I: Current time: Thu Dec 24 19:51:17 EST 2009
I: pbuilder-time-stamp: 1261702277
I: Building the build Environment
I: extracting base tarball [/var/cache/pbuilder/sid-i386-base.tgz]
I: creating local configuration
I: copying local configuration
I: mounting /proc filesystem
I: mounting /dev/pts filesystem
I: policy-rc.d already exists
I: Obtaining the cached apt archive contents
I: Installing the build-deps
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: i386
Maintainer: Debian Pbuilder Team 
Description: Dummy package to satisfy dependencies with aptitude - created by 
pbuilder
 This package was created automatically by pbuilder and should
Depends: debhelper (>= 7), libssl-dev, dpatch
dpkg-deb: building package `pbuilder-satisfydepends-dummy' in 
`/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Reading package lists...
Building dependency tree...
Reading state information...
aptitude is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Selecting previously deselected package pbuilder-satisfydepends-dummy.
(Reading database ... 11014 files and directories currently installed.)
Unpacking pbuilder-satisfydepends-dummy (from 
.../pbuilder-satisfydepends-dummy.deb) ...
dpkg: dependency problems prevent configuration of 
pbuilder-satisfydepends-dummy:
 pbuilder-satisfydepends-dummy depends on debhelper (>= 7); however:
  Package debhelper is not installed.
 pbuilder-satisfydepends-dummy depends on libssl-dev; however:
  Package libssl-dev is not installed.
 pbuilder-satisfydepends-dummy depends on dpatch; however:
  Package dpatch is not installed.
dpkg: error processing pbuilder-satisfydepends-dummy (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 pbuilder-satisfydepends-dummy
Reading package lists...
Building dependency tree...
Reading state information...
Initializing package states...
Writing extended state information...
The following NEW packages will be installed:
  bsdmainutils{a} debhelper{a} dpatch{a} file{a} gettext{a} gettext-base{a} 
  groff-base{a} html2text{a} intltool-debian{a} libcroco3{a} 
  libglib2.0-0{a} libmagic1{a} libpcre3{a} libssl-dev{a} libssl0.9.8{a} 
  libxml2{a} man-db{a} po-debconf{a} zlib1g-dev{a} 
The following partially installed packages will be configured:
  pbuilder-satisfydepends-dummy 
0 packages upgraded, 19 newly installed, 0 to remove and 0 not upgraded.
Need to get 0B/13.8MB of archives. After unpacking 38.5MB will be used.
Writing extended state information...
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously deselected package libmagic1.
(Reading database ... 11014 files and directories currently installed.)
Unpacking libmagic1 (from .../libmagic1_5.03-5_i386.deb) ...
Selecting previously deselected package file.
Unpacking file (from .../archives/file_5.03-5_i386.deb) ...
Selecting previously deselected package html2text.
Unpacking html2text (from .../html2text_1.3.2a-14_i386.deb) ...
Selecting previously deselected package libpcre3.
Unpacking 

Bug#562443: libgcgi: FTBFS: /bin/bash: line 11: automake-1.11: command not found

[Jeremy T. Bouse]

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 the mirrors and rebuilt under a pbuilder chroot and it built
>> successfully as well. The -4 version of the package had a problem in the
>> debian/rules that caused this behavior but it was fixed in the -5 release.
> 
> Could you please diff your log with mine, to see if the problem was
> possibly caused by different build-dep versions ?
> 
I'm building on i386 as my amd64 boxes are currently still offline
along with my hppa and alpha machines. The official amd64 buildd I sent
the URL that was available for the log. When looking through it I didn't
see any failures. However that log format and your log format are
completely different and do not lend themselves to diff comparison.

Jeremy



signature.asc
Description: OpenPGP digital signature

Bug#562443: libgcgi: FTBFS: /bin/bash: line 11: automake-1.11: command not found

[Jeremy T. Bouse]

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 as well. The -4 version of the package had a problem in the
debian/rules that caused this behavior but it was fixed in the -5 release.

Jeremy

[1]https://buildd.debian.org/fetch.cgi?pkg=libgcgi;ver=0.9.5.dfsg-5;arch=amd64;stamp=1260598069

Lucas Nussbaum wrote:
> Source: libgcgi
> Version: 0.9.5.dfsg-5
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20091223 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part:
>>  /usr/bin/fakeroot debian/rules clean
>> dh_testdir
>> dh_testroot
>> dh_auto_clean
>> dh_clean 
>> find . \( -type d -a -name .deps -prune -exec rm -rf {} \; \)
>> dpatch  deapply-all  
>> 01_update_libtool not applied to ./ .
>> rm -rf patch-stamp patch-stampT debian/patched
>>  dpkg-source -b libgcgi-0.9.5.dfsg
>> dpkg-source: info: using source format `1.0'
>> dpkg-source: info: building libgcgi using existing 
>> libgcgi_0.9.5.dfsg.orig.tar.gz
>> dpkg-source: info: building libgcgi in libgcgi_0.9.5.dfsg-5.diff.gz
>> dpkg-source: warning: executable mode 0755 of 
>> 'debian/patches/01_update_libtool.dpatch' will not be represented in diff
>> dpkg-source: info: building libgcgi in libgcgi_0.9.5.dfsg-5.dsc
>>  debian/rules build
>> test -d debian/patched || install -d debian/patched
>> dpatch  apply-all  
>> applying patch 01_update_libtool to ./ ... ok.
>> dpatch  cat-all  >>patch-stampT
>> mv -f patch-stampT patch-stamp
>> dh_testdir
>> find . \( -type f -a -name "Makefile.*" -prune -exec touch {} \; \)
>> # Add here commands to configure the package.
>> CFLAGS="-Wall -g -O2" ./configure --host=x86_64-linux-gnu 
>> --build=x86_64-linux-gnu --prefix=/usr --mandir=\${prefix}/share/man 
>> --infodir=\${prefix}/share/info --with-openssl
>> checking for a BSD-compatible install... /usr/bin/install -c
>> checking whether build environment is sane... yes
>> /build/user-libgcgi_0.9.5.dfsg-5-amd64-eqxp1F/libgcgi-0.9.5.dfsg/config/missing:
>>  Unknown `--run' option
>> Try 
>> `/build/user-libgcgi_0.9.5.dfsg-5-amd64-eqxp1F/libgcgi-0.9.5.dfsg/config/missing
>>  --help' for more information
>> configure: WARNING: `missing' script is too old or missing
>> checking for a thread-safe mkdir -p... /bin/mkdir -p
>> checking for gawk... no
>> checking for mawk... mawk
>> checking whether make sets $(MAKE)... yes
>> checking for x86_64-linux-gnu-gcc... x86_64-linux-gnu-gcc
>> checking whether the C compiler works... yes
>> checking for C compiler default output file name... a.out
>> checking for suffix of executables... 
>> checking whether we are cross compiling... no
>> checking for suffix of object files... o
>> checking whether we are using the GNU C compiler... yes
>> checking whether x86_64-linux-gnu-gcc accepts -g... yes
>> checking for x86_64-linux-gnu-gcc option to accept ISO C89... none needed
>> checking for style of include used by make... GNU
>> checking dependency style of x86_64-linux-gnu-gcc... gcc3
>> checking how to run the C preprocessor... x86_64-linux-gnu-gcc -E
>> checking for grep that handles long lines and -e... /bin/grep
>> checking for egrep... /bin/grep -E
>> checking for ANSI C header files... yes
>> checking whether make sets $(MAKE)... (cached) yes
>> checking build system type... x86_64-pc-linux-gnu
>> checking host system type... x86_64-pc-linux-gnu
>> checking for a sed that does not truncate output... /bin/sed
>> checking for fgrep... /bin/grep -F
>> checking for ld used by x86_64-linux-gnu-gcc... /usr/bin/ld
>> checking if the linker (/usr/bin/ld) is GNU ld... yes
>> checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
>> checking the name lister (/usr/bin/nm -B) interface... BSD nm
>> checking whether ln -s works... yes
>> checking the maximum length of command line arguments... 3458764513820540925
>> checking whether the shell understands some XSI constructs... yes
>> checking whether the shell understands "+="... yes
>> checking for /usr/bin/ld option to reload object files... -r
>> checking for x86_64-linux-gnu-objdump... no
>> checking for objdump... objdump
>> checking how to recognize dependent libraries... pass_all
>> checking for x86_64-linux-gnu-ar... no
>> checking for ar... ar
>> checking for x86_64-linux-gnu-strip... no
>> checking for strip... strip
>> checking for x86_64-linux-gnu-ranlib... no
>> checking for ranlib... ranlib
>> checking command to parse /usr/bin/nm -B output from x86_64-linux-gnu-gcc 
>> object... ok
>> checking for sys/types.h... yes
>> checking for sys/stat.h... yes
>> checking for stdlib.h... yes
>> checking for string.h... yes
>> checking for memory.h... yes
>> checking for strings.h... yes
>> 

Bug#561903: python-paramiko and fabric: error when trying to install together

[Jeremy T. Bouse]

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: python-paramiko/1.7.6-2
> Severity: serious
> User: trei...@debian.org
> Usertags: edos-file-overwrite
> 
> Date: 2009-12-21
> Architecture: amd64
> Distribution: sid
> 
> Hi,
> 
> automatic installation tests of packages that share a file and at the
> same time do not conflict by their package dependency relationships has
> detected the following problem:
> 
> 
> WARNING: The following packages cannot be authenticated!
>   libdb4.5 libsqlite3-0 mime-support python2.5-minimal python2.5
>   python-minimal python python-central python-support libgmp3c2 python-crypto
>   python-paramiko python-pkg-resources fabric
> W: cowdancer: unsupported operation flock, read-only open and 
> fchown/fchmod/flock are not supported: tried openning dev:inode of 
> 2055:5408818
> W: cowdancer: unsupported operation flock, read-only open and 
> fchown/fchmod/flock are not supported: tried openning dev:inode of 
> 2055:5407760
> W: cowdancer: unsupported operation flock, read-only open and 
> fchown/fchmod/flock are not supported: tried openning dev:inode of 
> 2055:5406907
> Authentication warning overridden.
> Can not write log, openpty() failed (/dev/pts not mounted?)
> Selecting previously deselected package libdb4.5.
> (Reading database ... 10441 files and directories currently installed.)
> Unpacking libdb4.5 (from .../libdb4.5_4.5.20-13.1_amd64.deb) ...
> Selecting previously deselected package libsqlite3-0.
> Unpacking libsqlite3-0 (from .../libsqlite3-0_3.6.21-2_amd64.deb) ...
> Selecting previously deselected package mime-support.
> Unpacking mime-support (from .../mime-support_3.48-1_all.deb) ...
> Selecting previously deselected package python2.5-minimal.
> Unpacking python2.5-minimal (from .../python2.5-minimal_2.5.4-3_amd64.deb) ...
> Selecting previously deselected package python2.5.
> Unpacking python2.5 (from .../python2.5_2.5.4-3_amd64.deb) ...
> Selecting previously deselected package python-minimal.
> Unpacking python-minimal (from .../python-minimal_2.5.4-4_all.deb) ...
> Selecting previously deselected package python.
> Unpacking python (from .../python_2.5.4-4_all.deb) ...
> Selecting previously deselected package python-central.
> Unpacking python-central (from .../python-central_0.6.14+nmu2_all.deb) ...
> Selecting previously deselected package python-support.
> Unpacking python-support (from .../python-support_1.0.6_all.deb) ...
> Selecting previously deselected package libgmp3c2.
> Unpacking libgmp3c2 (from .../libgmp3c2_2%3a4.3.1+dfsg-3_amd64.deb) ...
> Selecting previously deselected package python-crypto.
> Unpacking python-crypto (from .../python-crypto_2.0.1+dfsg1-4_amd64.deb) ...
> Selecting previously deselected package python-paramiko.
> Unpacking python-paramiko (from .../python-paramiko_1.7.6-2_all.deb) ...
> Selecting previously deselected package python-pkg-resources.
> Unpacking python-pkg-resources (from 
> .../python-pkg-resources_0.6.8-1_all.deb) ...
> Selecting previously deselected package fabric.
> Unpacking fabric (from .../fabric_0.9.0-1_all.deb) ...
> dpkg: error processing /var/cache/apt/archives/fabric_0.9.0-1_all.deb 
> (--unpack):
>  trying to overwrite '/usr/share/pyshared/paramiko/hostkeys.py', which is 
> also in package python-paramiko 0:1.7.6-2
> dpkg-deb: subprocess paste killed by signal (Broken pipe)
> Processing triggers for man-db ...
> W: cowdancer: unsupported operation flock, read-only open and 
> fchown/fchmod/flock are not supported: tried openning dev:inode of 
> 2055:5408818
> W: cowdancer: unsupported operation flock, read-only open and 
> fchown/fchmod/flock are not supported: tried openning dev:inode of 
> 2055:5407760
> W: cowdancer: unsupported operation flock, read-only open and 
> fchown/fchmod/flock are not supported: tried openning dev:inode of 
> 2055:5406907
> Errors were encountered while processing:
>  /var/cache/apt/archives/fabric_0.9.0-1_all.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> 
> This is a serious bug as it makes installation fail, and violate
> section 7.6.1 of the policy. Possible solutions are to have the two
> packages conflict, to rename the common file in one of the two
> packages, or to remove the file from one package and have this package
> depend on the other package. File diversions or a Replace relation are
> another possibility.
> 
> Here is a list of files that are known to be shared by both packages
> (according to the Contents file for sid/amd64, which may be
> slightly out of sync):
> 
> 
>   usr/share/pyshared/paramiko/__init__.py
>   usr/share/pyshared/paramiko/agent.py
>   usr/share/pyshared/paramiko/auth_handler.py
>   usr/share/pyshared/paramiko/ber.py
>   usr/share/pyshared/paramiko/buffered_pipe.py
>   u

Bug#558667: libgcgi: FTBFS: /bin/bash: aclocal: command not found

[Jeremy T. Bouse]

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: libc6-dev_2.10.2-2 
>> linux-libc-dev_2.6.32~rc8-1~experimental.1 g++-4.3_4.3.4-6 gcc-4.3_4.3.4-6 
>> binutils_2.20-4 libstdc++6_4.4.2-3 libstdc++6-4.3-dev_4.3.4-6
>>
> 
> [...]
> 
>> config.status: creating examples/Makefile
>> config.status: creating doc/Makefile
>> config.status: creating config.h
>> config.status: executing depfiles commands
>> config.status: executing libtool commands
>> dh_testdir
>> # Add here commands to compile the package.
>> /usr/bin/make
>> make[1]: Entering directory 
>> `/build/buildd-libgcgi_0.9.5.dfsg-3-amd64-bQXojb/libgcgi-0.9.5.dfsg'
>> CDPATH="${ZSH_VERSION+.}:" && cd . && aclocal -I config 
>> /bin/bash: aclocal: command not found
>> make[1]: *** [aclocal.m4] Error 127
>> make: *** [build-stamp] Error 2
>> make[1]: Leaving directory 
>> `/build/buildd-libgcgi_0.9.5.dfsg-3-amd64-bQXojb/libgcgi-0.9.5.dfsg'
>> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> 
> A full build log can be found at:
> http://buildd.debian.org/build.php?arch=amd64&pkg=libgcgi&ver=0.9.5.dfsg-3
> 
> 
> Kurt
> 

I was already on this...



signature.asc
Description: OpenPGP digital signature

Bug#533336: acidbase: error when installed on Lenny

[Jeremy T. Bouse]

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.



signature.asc
Description: OpenPGP digital signature

Bug#552235: acidbase: multiple security flaws, needs maintenance or removal?

[Jeremy T. Bouse]

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

Bug#490961: paramiko random number regression: Stop using RandomPool

[Jeremy T. Bouse]

-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
> Severity: serious
> Tags: security, patch
> 
> See http://www.lag.net/pipermail/paramiko/2008-April/000678.html
> 
> "Revision #486 [1] (and therefore Paramiko 1.7.3) re-introduces the
> problems associated with PyCrypto's RandomPool class that I described
> in my post back in January.  RandomPool is not a simple "get random
> bits" primitive, but paramiko is again using it as one."
> 
> Patch at http://www.lag.net/pipermail/paramiko/2008-April/000679.html
> 
> This is fixed in the new upstream 1.7.4 as well.
> 
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iF0EARECAB0FAkh8zd8WGGhrcDovL3N1YmtleXMucGdwLm5ldAAKCRBALeRNdPfm
QJwxAJ9wavCmwyp+pg9yT2jkWqDiQEXCKgCgt36XRaV7SLPtOhTCPiyyJIC2aZo=
=6dQ+
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#423353: php-image-canvas: should this package be removed?

[Jeremy T. Bouse]

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 with upstream to get the
>>>> licensing issues that would allow the fix to be done.
>>>> 
>>>> 
>>> Hi Jeremy,
>>>
>>> The bugs about thoose license issues have been quiet for a very long
>>> time (since November 2005). If the situation has evolved, and you expect
>>> a change soon, it could be a good idea to document that in the bug logs.
>>>
>>> Thank you,
>>>   
>>>   
>> At this point I'm abandoning all hope that upstream will make any
>> effort to correct the issue. There appears to be no interest in
>> upstreams part to even respond and continually just passes it off as not
>> their problem. Consider any PHP Licensed PEAR module package currently
>> with a bug due to licensing abandoned and ideal candidate for complete
>> removal from the distribution unless someone with more free time on
>> their hands cares to adopt them.
>>
>> I've tried to get responses from upstream but the attempts were
>> useless and a waste of my time.
>> 
>
> Arg. is there some place (besides -legal@) where coordination could take
> place about this issue?
>   
I don't see where coordinating through d-legal would accomplish any
more than what I have. Upstream is not very cooperative and doesn't
appear to think there is anything wrong with the licensing or attempting
to fix it. Best hope is that those applications using it and wanting to
be included within Debian will write a new module, or find one already
written, that doesn't have the licensing issues and move to use it instead.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#423353: php-image-canvas: should this package be removed?

[Jeremy T. Bouse]

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,
>
> The bugs about thoose license issues have been quiet for a very long
> time (since November 2005). If the situation has evolved, and you expect
> a change soon, it could be a good idea to document that in the bug logs.
>
> Thank you,
>   
At this point I'm abandoning all hope that upstream will make any
effort to correct the issue. There appears to be no interest in
upstreams part to even respond and continually just passes it off as not
their problem. Consider any PHP Licensed PEAR module package currently
with a bug due to licensing abandoned and ideal candidate for complete
removal from the distribution unless someone with more free time on
their hands cares to adopt them.

I've tried to get responses from upstream but the attempts were
useless and a waste of my time.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#435176: phplot: Doesn't work with PHP5

[Jeremy T. Bouse]

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 whether the package works with PHP5, and then add the dependency on it.
> 
> I just tried to figure out a fix for this bug, but whereas phplot is
> still working using PHP4 it does not work using PHP5. I checked whether
> it works by running all examples provided with the package.  While I get
> quite nice plots and chart with PHP4 I didn't succeed with PHP5. Using
> PHP5 phplot apparently gets into an endless loop giving following error
> messages repeated all again:
> 
> Warning: array_merge() [function.array-merge]: Argument #1 is not an
> array in /usr/share/phplot/phplot.php on line 4084
> Warning: array_merge() [function.array-merge]: Argument #2 is not an
> array in /usr/share/phplot/phplot.php on line 4084
> 
> Note: I needed to adapt the include() statements for the correct paths
> of phplot in order to get the examples running.
> 
> As there is a new upstream version available which - according to a
> brief test - seems to work using PHP5 I suggest to upload a new upstream
> version rather than a bugfix. Thus I tag this bug fixed-upstream.
> 
> So, please update the package.
> 
> Greetings
>   Micha
> 

As I find myself currently living out of a hotel as my wife and I try
to close on our first home purchase I'm down to a laptop with my devel
server packed in a box and sitting in a storage unit offline. As soon as
I have everything back online I will endeavor to get the latest version
of phplot ready and uploaded to the mirrors.

With any luck we'll be in our house by this time next week but may not
have internet for awhile after we do get in. Please be patient and I'll
get it addressed ASAP.

Regards,
Jeremy


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#400989: Image_Color PEAR module licensing

[Jeremy T. Bouse]

Andrew,

It's almost two years since I had opened the bug #5721 which you
suspended saying it was irrelevant. As Image_Canvas and Image_Graph
depend on Image_Color and both of them are LGPL the PHP licensing is
incompatible. As a result I'm either looking at 1) having to fork both
of them and strip out any reference to Image_Color; 2) removing both
Image_Graph and Image_Canvas from the Debian distribution; or 3) moving
them to non-free/contrib which will ensure that anything depending on
them also has to move to non-free/contrib and out of the main distribution.

You had mentioned in your reply to #5721 that you were going to discuss
on pear-dev list and ask what other developers thought. That's been over
a year now have you not gotten anything back? Has Image_Color2 been
written to be API compatible with Image_Color so Image_Graph and
Image_Canvas can depend on it as it is LGPL licensed as well?

Regards,
    Jeremy T. Bouse



signature.asc
Description: OpenPGP digital signature

Bug#423310: php-image-graph: should this package be orphaned?

[Jeremy T. Bouse]

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
> User: [EMAIL PROTECTED]
> Usertags: proposed-orphan
> 
> Hi,
> 
> While reviewing packages that were not included in Etch, your package came
> up as a package that should maybe be orphaned by its maintainer, because:
> 
>   * Long standing Release Critical Bugs 
>   * Last upload in 2005
> 
> If you think that it should be removed from Debian instead of being orphaned,
> please reply to this bug and tell so.
> 
> If you agree that it should be orphaned, sending the following commands to
> [EMAIL PROTECTED] should do it (after replacing nn with this bug's
> number):
> severity nn normal
> reassign nn wnpp
> retitle nn O: php-image-graph -- 
> thanks
> 
> For more information, see
> http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-archive-manip
> http://www.debian.org/devel/wnpp/
> 
> If you disagree and want to continue to maintain this package, please close
> this bug, preferably in an upload also fixing the other issues.
> 
> Thank you,
>   - michael
> 




signature.asc
Description: OpenPGP digital signature

Bug#423313: php-image-canvas: should this package be orphaned?#

[Jeremy T. Bouse]

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
> User: [EMAIL PROTECTED]
> Usertags: proposed-orphan
> 
> Hi,
> 
> While reviewing packages that were not included in Etch, your package came
> up as a package that should maybe be orphaned by its maintainer, because:
> 
>   * Several Release Critical Bugs open for more than Years
>   * Last upload in 2005
> 
> If you think that it should be removed from Debian instead of being orphaned,
> please reply to this bug and tell so.
> 
> If you agree that it should be orphaned, sending the following commands to
> [EMAIL PROTECTED] should do it (after replacing nn with this bug's
> number):
> severity nn normal
> reassign nn wnpp
> retitle nn O: php-image-canvas -- 
> thanks
> 
> For more information, see
> http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-archive-manip
> http://www.debian.org/devel/wnpp/
> 
> If you disagree and want to continue to maintain this package, please close
> this bug, preferably in an upload also fixing the other issues.
> 
> Thank you,
>   - michael
> 




signature.asc
Description: OpenPGP digital signature

Bug#423353: php-image-canvas: should this package be removed?

[Jeremy T. Bouse]

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
> User: [EMAIL PROTECTED]
> Usertags: proposed-removal
> 
> Hi,
> 
> While reviewing packages that were not included in Etch, your package came
> up as a possible candidate for removal from Debian, because:
> 
>   * Several Release Critical Bugs
>   * last upload in 2005
>   * Low popcon stats
> 
> If you think that it should be orphaned instead of being removed from Debian,
> please reply to this bug and tell so.
> 
> If you agree, sending the following commands to [EMAIL PROTECTED]
> should do it (after replacing nn with this bug's number):
> severity nn normal
> reassign nn ftp.debian.org
> retitle nn RM:  -- RoM;  
> thanks
> 
> For more information, see
> http://wiki.debian.org/ftpmaster_Removals
> http://ftp-master.debian.org/removals.txt
> 
> If you disagree and want to continue to maintain this package, please just
> close this bug, preferably in an upload also fixing the other issues.
> 
> Thank you,
>   - michael
> 




signature.asc
Description: OpenPGP digital signature

Bug#422478: fwbuilder - broken depencies - libsnmp9 missing

[Jeremy T. Bouse]

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
> Justification: renders package unusable
> 
> fwbuilder is uninstallable, libsnmp9 is not in sid anymore
> Can you update the dependcies to use libsnmp10 ?
> 
> 
> 
> -- System Information:
> Debian Release: lenny/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: i386 (i686)
> 
> Kernel: Linux 2.6.20 (SMP w/2 CPU cores; PREEMPT)
> Locale: [EMAIL PROTECTED], LC_CTYPE=iso_8859_15 (charmap=ISO-8859-15) 
> (ignored: LC_ALL set to [EMAIL PROTECTED])
> Shell: /bin/sh linked to /bin/bash
> 
> Versions of packages fwbuilder depends on:
> pn  fwbuilder-common   (no description available)
> pn  fwbuilder-linux | fwbui(no description available)
> ii  libc6   2.5-5GNU C Library: Shared libraries
> pn  libfwbuilder6  (no description available)
> ii  libgcc1 1:4.2-20070405-1 GCC support library
> pn  libqt3c102-mt  (no description available)
> pn  libsnmp5   (no description available)
> pn  libssl0.9.7(no description available)
> ii  libstdc++5  1:3.3.6-15   The GNU Standard C++ Library v3
> ii  libwrap07.6.dbs-13   Wietse Venema's TCP wrappers 
> libra
> ii  libx11-62:1.0.3-7X11 client-side library
> ii  libxext61:1.0.3-2X11 miscellaneous extension 
> librar
> ii  libxml2 2.6.28.dfsg-1GNOME XML library
> ii  libxslt1.1  1.1.20-1 XSLT processing library - 
> runtime 
> ii  zlib1g  1:1.2.3-13   compression library - runtime
> 
> fwbuilder recommends no packages.
> 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#271051: Bug#342249: Help proposal :) [u]

[Jeremy T. Bouse [c]]

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 Yvette Chanco so I've included as well in reply. I'd
hope to start getting something together in short order and in CVS for
testing. As we want to do this with minimal changes to upstream and to
save space in CVS I think we should only need to maintain the debian/
directory of the build within CVS but I'd like to get input as well.

I do have a couple of mailing lists waiting to be setup for the project
as well so that discussion can be moved from BTS.

Regards,
Jeremy

Guido Trotter wrote:
> On Mon, Feb 13, 2006 at 10:51:43AM +0200, Saku Ytti wrote:
> 
> Hi,
> 
> 
>> I've CC'd Ralph Passgang, he's previously expressed his will to 
>>help packaging XEN to debian. He's done unofficials packages
>>which work very nicely, although do not comply 100% to
>>debian standards.
>>
>> Thanks in advance for taking steps to bring updated
>>XEN to debian. And if at all possible, I'd like to see unstable
>>packaged too.
>>
> 
> 
> And "official" backports.org, of course! ;)
> Ok, count me in! I'm 'ultrotter' on alioth! Also interested since I have some
> machines running xen and I'm also writing my master thesis on it!
> 
> Bye!
> 
> Guido
> 
> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#271051: Bug#342249: Help proposal :) [u]

[Jeremy T. Bouse [c]]

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
running locally to work on Xen with and frankly I'm tired of the absence
of any decent packaging and the total void that is called the current
maintainership of the package. The list of unresolved bugs range from
over 60 days to a year and a half. The last upload was almost 6 months
ago for 2.0.6 which has since had 2.0.7, 3.0.0 and 3.0.1 released since
then.

I'll begin the work and welcome those wanting to assist, which will
give Adam more time to decide whether he wishes to finally make an
appearance and respond to the maintaining of Xen before I begin to deal
with attempting a hostile take-over of maintainership which I would
rather not do but in the void of any response seems the only course for
the benefit of Xen within Debian.

Regards,
Jeremy

Guido Trotter wrote:
> On Mon, Feb 06, 2006 at 03:59:21PM +0100, Julien Danjou wrote:
> 
> Hi Everybody!
> 
> 
>>Since I really would like official Xen 3.0 packages, I am just offering
>>help about packaging this.
>>
>>Adam, I don't know if you have time for this or not, but if you can at
>>least let me know if you need help, and how I can help, it would be
>>great !
>>
> 
> 
> Yeah, I agree we should do something on Xen's status? How about the idea of
> starting a project on Alioth as Jeremy said, and going to group maintenance?
> 
> Adam, can you please comment on this... Even a "fine with me, go ahead" or a
> "no, please, don't" would be nice... If nobody hears from you probably someone
> will just end up doing it anyway, so it's better if you can speak up, please! 
> :)
> 
> Thanks,
> 
> Guido
> 
> 


signature.asc
Description: OpenPGP digital signature

Bug#271051: Status of Xen in Debian [u]

[Jeremy T. Bouse [c]]

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 packages available, which I'm
afraid to say are more put together and complete than the current
official Debian packages doogie has uploaded. I am also using Xen
full-time now and would rather have packages coming from one archive
with properly signed releases than various unofficial personal archives.

Might it be time to form a Debian-Xen package team of those parties
interested in furthering the Xen packages to make them more stable and
worthy of making it into the next Debian release?

Regards,
Jeremy


signature.asc
Description: OpenPGP digital signature

Bug#344254: libfwbuilder6c2a: Fails to upgrade from libfwbuilder6c2 [u]

[Jeremy T. Bouse [c]]

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 patch
>thanks
>
>Hi Jeremy,
>
>I've prepared an NMU for this bug, which will be uploaded shortly so that we
>can get a non-RC-buggy (i.e., c2a instead of c2) libfwbuilder into etch. 
>The trivial patch against -3.1 is attached.
>
>Thanks,
>  
>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#344254: libfwbuilder6c2a: Fails to upgrade from libfwbuilder6c2

[Jeremy T. Bouse]

   What I'm saying, is that with the exception of the NMU done by 
yourself Steve there have been problems with every NMU done. As well, 
again with all but the exception of you, they were done with disregard 
to the Developer reference regarding NMUs and how they should be done.


   Because 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:
 


   This would be because of rushed NMU that I did not do.
   



Are you suggesting that you had this right in 2.0.9-3, and the NMUer
reverted it in 2.0.9-3.1?

 





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#344254: libfwbuilder6c2a: Fails to upgrade from libfwbuilder6c2

[Jeremy T. Bouse]

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 libfwbuilder6c2a, I
>think this has to do with wrong Conflicts/Replaces pair. Please add
>libfwbuilderc2 to Conflicts and Replaces and this problem is fixed.
>
>Regards,
>
>Matthijs Mohlmann
>
>-- System Information:
>Debian Release: testing/unstable
>  APT prefers unstable
>  APT policy: (500, 'unstable'), (1, 'experimental')
>Architecture: i386 (i686)
>Shell:  /bin/sh linked to /bin/bash
>Kernel: Linux 2.6.14
>Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
>
>
>  
>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#341669: libfwbuilder-dev: Broken upload

[Jeremy T. Bouse]

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:

>Package: libfwbuilder-dev
>Version: 2.0.9-3
>Severity: grave
>Justification: renders package unusable
>
>libfwbuilder-dev depends on libfwbuilder6c2.  It should of course
>depend on libfwbuilder6c2a.
>
>
>  
>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#338293: Failed to load /usr/share/fwbuilder/objects_init.xml

[Jeremy T. Bouse]

   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 Le Gall wrote:


Package: fwbuilder
Version: 2.0.7-2
Severity: grave
Justification: renders package unusable

Hello,

While trying to launch fwbuilder, i get 2 screens concerning the fact
that fwbuilder cannot load :
- /usr/share/fwbuilder/objects_init.xml
- /usr/share/fwbuilder/templates.xml

The program explains that "the library file you are trying to open has
been saved in an older version of Firewall Builder and needs to be
upgraded. To upgarde it, just load it in the Firewall Builder GUI and
save back to file again."

It proposes me to upgrade the file, and then segfault.

Kind regard 
Sylvain Le Gall



-- System Information:
Debian Release: testing/unstable
 APT prefers unstable
 APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.3-grand
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages fwbuilder depends on:
ii  fwbuilder-common 2.0.7-2 Firewall administration tool GUI (
ii  fwbuilder-linux [fwbuild 2.0.7-2 Firewall Builder policy compiler(s
ii  libc62.3.5-7 GNU C Library: Shared libraries an
ii  libfwbuilder6c2  2.0.9-1 Firewall Builder API library
ii  libgcc1  1:4.0.2-3   GCC support library
ii  libqt3-mt3:3.3.5-1   Qt GUI Library (Threaded runtime v
ii  libsnmp9 5.2.1.2-4   NET SNMP (Simple Network Managemen
ii  libssl0.9.7  0.9.7g-5SSL shared libraries
ii  libstdc++6   4.0.2-3 The GNU Standard C++ Library v3
ii  libwrap0 7.6.dbs-8   Wietse Venema's TCP wrappers libra
ii  libx11-6 6.8.2.dfsg.1-10 X Window System protocol client li
ii  libxext6 6.8.2.dfsg.1-10 X Window System miscellaneous exte
ii  libxml2  2.6.22-2GNOME XML library
ii  libxslt1.1   1.1.15-1XSLT processing library - runtime 
ii  xlibs6.8.2.dfsg.1-10 X Window System client libraries m

ii  zlib1g   1:1.2.3-6   compression library - runtime

fwbuilder recommends no packages.

-- no debconf information


 




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#338113: fwbuilder: FTBFS: needs new version of libfwbuilder

[Jeremy T. Bouse]

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 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 wasting my time and check things before you 
>>file a useless bug that wastes my valuable time.
>>
>>
>
>If your time is so valuable, why are you spending it on being rude to people
>who are providing an important service to the project by tracking
>non-buildable packages, instead of on getting the fwbuilder package updated?
>
>Obviously libfwbuilder already *is* on the mirrors, or else this bug
>wouldn't have been filed.  In fact, it's been there for two days now.  It's
>not the end of the world if fwbuilder isn't updated yet, but it's still a
>bug (in either fwbuilder or libfwbuilder) that fwbuilder can't build against
>*any* version of libfwbuilder-dev providing the interface to the same
>libfwbuilder6c2 library.  When can we look forward to a fix for this?
>
>  
>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#338113: fwbuilder: FTBFS: needs new version of libfwbuilder

[Jeremy T. Bouse]

   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 wasting my time and check things before you 
file a useless bug that wastes my valuable time.


   Regards,
   Jeremy

Roland Stigge wrote:


Package: fwbuilder
Version: 2.0.7-2
Severity: serious

Hi,

building the package fwbuilder in a clean sid build environment
(with pbuilder) on i386 results in:

=
[...]
checking how to run the C++ preprocessor... g++ -E
checking for strchr... yes
checking for memcpy... yes
checking whether make is GNU Make... no
checking for pty.h... yes
checking for libutil.h... no
checking for util.h... no
checking for forkpty in -lc... no
checking for forkpty in -lutil... yes
checking whether make sets $(MAKE)... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking getopt.h usability... yes
checking getopt.h presence... yes
checking for getopt.h... yes
checking for rcs... rcs
checking for rcsdiff... rcsdiff
checking for rlog... rlog
checking for ci... ci
checking for co... co
checking for libfwbuilder-config-2... /usr/bin/libfwbuilder-config-2
checking libfwbuilder version... configure: error: *** Need libfwbuilder version 2.0.7, found 2.0.9 
make: *** [stampdir/config] Error 1

=

Thanks for considering.


--
DARTS - Debian Archive Regression Test Suite
http://darts.alioth.debian.org/

Please note that this report has not been generated fully automatically.
DARTS just helped finding the problem.


 




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#334404: fwbuilder-linux: fwbuilder fails to build fw script with "Unrecognized host OS linux24 (family linux24)" message

[Jeremy T. Bouse]

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 configuration and not the
application itself as I have the same versions of the packages as you. I
also installed under a clean chroot to make sure there was no contamination.

The fwbuilder-linux package does provide the fwb_ipt policy compiler
which was able to successfully reproduce my scripts for all my firewalls
without so much as an error. I would recommend either forwarding your
.fwb data file to me, privately if you wish, so I can try to determine
what is wrong. Otherwise I would encourage you to edit the firewall
properties by right clicking on the firewall object in the left pane and
selecting "Edit" to make sure that you have the Platform, Version and
Host OS settings set properly.

Regards,
Jeremy

Nicolas wrote:

>Package: fwbuilder-linux
>Version: 2.0.7-2
>Severity: grave
>Justification: renders package unusable
>
>
>fwbuilder can't build a firewall script for linux. Here's the message
>written when compiling:
>Unrecognized host OS linux24  (family linux24)
>
>Here are some fwbuilder related packages installed on my computer:
>
># dpkg -l | grep fwbuil
>ii  fwbuilder  2.0.7-2 Firewall administration tool GUI
>ii  fwbuilder-bsd  2.0.7-2 Firewall Builder policy compiler(s) 
>for BSD based firewalls
>ii  fwbuilder-common   2.0.7-2 Firewall administration tool GUI 
>(common files)
>ii  fwbuilder-linux2.0.7-2 Firewall Builder policy compiler(s) 
>for Linux based firewalls
>ii  libfwbuilder-dev   2.0.7-5 Firewall Builder API library 
>development files
>rc  libfwbuilder5  1.0.2-1 Firewall Builder API library
>rc  libfwbuilder6  2.0.7-1 Firewall Builder API library
>ii  libfwbuilder6c22.0.7-5 Firewall Builder API library
>
>I think the fwbuilder-linux package should provide support for iptables.
>
>Nicolas.
>
>-- System Information:
>Debian Release: testing/unstable
>  APT prefers unstable
>  APT policy: (500, 'unstable')
>Architecture: i386 (i686)
>Shell:  /bin/sh linked to /bin/bash
>Kernel: Linux 2.6.12.3
>Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
>
>Versions of packages fwbuilder-linux depends on:
>ii  fwbuilder 2.0.7-2Firewall administration tool GUI
>ii  libc6 2.3.5-7GNU C Library: Shared libraries an
>ii  libfwbuilder6c2   2.0.7-5Firewall Builder API library
>ii  libgcc1   1:4.0.2-2  GCC support library
>ii  libqt3-mt 3:3.3.5-1  Qt GUI Library (Threaded runtime v
>ii  libsnmp9  5.2.1.2-4  NET SNMP (Simple Network Managemen
>ii  libssl0.9.7   0.9.7g-5   SSL shared libraries
>ii  libstdc++64.0.2-2The GNU Standard C++ Library v3
>ii  libwrap0  7.6.dbs-8  Wietse Venema's TCP wrappers libra
>ii  libx11-6  6.8.2.dfsg.1-9 X Window System protocol client li
>ii  libxext6  6.8.2.dfsg.1-9 X Window System miscellaneous exte
>ii  libxml2   2.6.22-1   GNOME XML library
>ii  libxslt1.11.1.15-1   XSLT processing library - runtime 
>ii  xlibs 6.8.2.dfsg.1-9 X Window System client libraries m
>ii  zlib1g1:1.2.3-4  compression library - runtime
>
>fwbuilder-linux recommends no packages.
>
>-- no debconf information
>
>  
>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#327963:

[Jeremy T. Bouse]

   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 these updated packages? They
don't seem to be available at packages.debian.org yet, and apt-getting
still leaves me at 2.0.7-2.

thanks,
James

--
James Hughes
Web application developer
Centre for Health Services and Policy Research
Vancouver, BC

 




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#327963: (no subject)

[Jeremy T. Bouse]

   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 2.0.7-2Firewall 
administration tool GUI
ii  fwbuilder-common  2.0.7-2Firewall 
administration tool GUI (common fil
ii  fwbuilder-linux   2.0.7-2Firewall Builder 
policy compiler(s) for Linu
ii  libfwbuilder6c2   2.0.7-4Firewall Builder 
API library


After starting I get this error:

/usr/bin/fwbuilder: error while loading shared libraries: libfwbuilder.so.6: 
can not open shared object file: No such file or directory


Seems to me that the library hasn't been added to the libfwbuilder6c2 package.

Regards, Michael

 




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#330336: Patch for NMU 2.0.7-1.2

[Jeremy T. Bouse]

Next time you think about doing an NMU make sure it is fully
functional. Even the NMU you did would have failed to build on arm, m68k
and hppa. I have spent the past 48 hours working on the proper fix for
it. My current 2.0.7-3 doesn't even fix it yet and you're NMU didn't
even come close.

I knew the upstream release was secondary to the transition. Had you
taken proper attempts at communication with the maintainer you would
have been able to determine the issues I was already working on before I
dealt with the new version.

I fail to see how you're jumping the gun did anything to help. The
only package currently held up with the libfwbuilder package issue is
fwbuilder itself. So it was not holding up the Qt/KDE transition. You
also failed to even acknowledge #323133, which by itself was not
directly apparent from the bugs you attempted to close, that has a
direct impact on the build. If you only built on i386 or any other arch
besides the three it affects you would not have known that unless you
had actually had some communication with me. Instead you were impatient
to get went ahead without all the facts in the situation.

Next time I would appreciate you 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 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 not only the NMU but the patch to the
>>BTS hardly gives time for a response from the developer. Submitting the
>>patch within 24 hours and not uploading the NMU after giving some time
>>for a response would have been better.
>>
>>   5.11.1 states the following order, please abid by it:
>>
>>  1) File a bug report *Hurray you did that atleast*
>>  2) Wait a few days for a response. File a 'patch' if no response
>>  3) Wait a few more days if you get no answer, then mail announcing
>>the intent to NMU
>>  4) Upload your package to DELAYED/7-day (not 3-DAY, not 5-DAY,
>>*7-DAY*)
>>
>>
>
>It's part of the gcc and Qt/KDE transition. At least for libfwbuilder
>3-DAY is apropriate... Open RC bugs are an intent to NMU... and an NMU
>is no attack, it's just to help you...
>
>  
>
>>   If you had checked all the other bugs you closed and read them you
>>would have noticed that I was working on the 2.0.9 packaging already as
>>it had been released. I had been working on 2.0.8 when the C++ ABI
>>transition hit the mirrors. You would have also noticed I respond to
>>just about every bug report filed, so not getting a response from a bug
>>filed within 24 hours isn't a problem.
>>
>>
>
>Fixing RC bugs is more important than a new upstream...
>
>  
>
>>   I won't go on about the fact that some of the items in the bugs you
>>closed were not addressed in your NMU to begin with and would have been
>>closed without being addressed.
>>
>>
>
>You mean the bug that was already fixed, but not closed by you?
>
>  
>
>>   Checking the QA mia-history would have also showed I wasn't MIA as
>>well; however you made no attempt, other than the one bug report to,
>>contact me prior to doing the NMU.
>>
>>
>
>Note that the NMU has not reached the archive yet and that your packages
>are holding the Qt/KDE transition... The other option next to NMUing was
>asking its removal from testing in a couple of days...
>
>Note also that NMUing is to help you. I'm sorry if you misunderstood
>this NMUs as an attack. The procedure for NMUing described in the
>Developers Reference is indeed a good one for fixing random bugs, but
>please understand that it is too much hassle for a testing migration of
>a *big* transition.
>
>So, sorry again if it came over as an attack.
>
>Cheers
>
>Luk
>
>  
>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#330336: Patch for NMU 2.0.7-1.2

[Jeremy T. Bouse]

   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 not only the NMU but the patch to 
the BTS hardly gives time for a response from the developer. Submitting 
the patch within 24 hours and not uploading the NMU after giving some 
time for a response would have been better.


   5.11.1 states the following order, please abid by it:

  1) File a bug report *Hurray you did that atleast*
  2) Wait a few days for a response. File a 'patch' if no response
  3) Wait a few more days if you get no answer, then mail 
announcing the intent to NMU
  4) Upload your package to DELAYED/7-day (not 3-DAY, not 5-DAY, 
*7-DAY*)


   If you had checked all the other bugs you closed and read them you 
would have noticed that I was working on the 2.0.9 packaging already as 
it had been released. I had been working on 2.0.8 when the C++ ABI 
transition hit the mirrors. You would have also noticed I respond to 
just about every bug report filed, so not getting a response from a bug 
filed within 24 hours isn't a problem.


   I won't go on about the fact that some of the items in the bugs you 
closed were not addressed in your NMU to begin with and would have been 
closed without being addressed.


   Checking the QA mia-history would have also showed I wasn't MIA as 
well; however you made no attempt, other than the one bug report to, 
contact me prior to doing the NMU.


   Regards,
   Jeremy

Luk Claes wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi

Attached the patch for the version I uploaded to DELAYED-3. If you want
to override this NMU, then please upload a fixed version before this
upload reaches the archive.

Cheers

Luk
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDOrOv5UTeB5t8Mo0RAroWAKCJJKSp8C0rxiRy5hodedzYL1DUDgCeOEFU
SHa/IFchE6QIA22kbkjHRuQ=
=kq6O
-END PGP SIGNATURE-
 




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#327017: Addendum...

[Jeremy T. Bouse]

   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 for a wedding in less than 2 months time.


   If you are in such a hurry for it than you are more than welcome to 
grab the existing 2.0.7 source DEBs and work on them to build 2.0.9 and 
submit them to me for testing and I'll rebuild and upload with credit 
given. Since you apparently have more time than I do at the current moment.


   Regards,
   Jeremy

Jeff Wiegley wrote:


Here's an idea... Instead of complaining that everybody keeps filing
duplicate bugs why not just fix the packages in sid?  That way you
can close out all of these bugs and nobody is motivated to file
yet another duplicate.

Yes, that's acidic. But I feel I've been pretty patient with this
package. I use it regularly on a variety of machines and one day
it got removed and I haven't been able to reinstall it since and
that was something like a month ago (At least 18 days.)

If the packages cannot be fixed right now then, instead of
reprimanding us duplicate filers, explain what we're waiting for.
Is one of the dependencies not getting updated by its maintainer or
what?

Thanks,




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#327963: fwbuilder: uninstallable; needs rebuild for the Qt/KDE transition

[Jeremy T. Bouse]

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 another bug report?


Adeodato Simó wrote:


Package: fwbuilder
Version: 2.0.7-1
Severity: grave
Tags: sid

Hello,

 This is a grave bug filed against your package because it depends on
 libqt3c102-mt, which no longer exists, thus rendering yor package
 uninstallable in unstable. As part of the C++ ABI transition, this
 library has moved to the libqt3-mt package.

 Simply recompiling and uploading your package should be enough to fix
 this; as per this mail [1], you need not bump your Qt, kdelibs or aRts
 build-dependencies. Beware, though, that that may not be the case for
 all the involved librares. Also, make sure that you build the package
 in an up to date and clean sid environment, so that final dependencies
 are correct. Please do this as soon as possible in order to accelerate
 the Qt/KDE transition to testing.

   [1] http://lists.debian.org/debian-devel-announce/2005/09/msg0.html

 Perhaps you find that your package fails to compile with gcc4. If
 that's the case, there's probably a bug about it in the BTS, and it
 may include a patch. If not (or if you have doubts about the
 correctness of the patch), you may be able to find a fix in upstream's
 CVS, or in the Ubuntu distribution. If your package fails only in arm,
 m68k, and hppa, see instructions in the above mail.

 Finally, if there's a strong reason for which your package should not
 be NMUed, please note so in this bug report. Prospective NMUers will
 read your reasoning, and will decide if it's strong enough to delay
 their upload.

 Thanks for your cooperation, and happy hacking!
 


 P.S.: There may be an already reported bug against this package for
 this very same reason. I've checked for that, and will be merging the
 bugs soon. The reason for still filing this bug was to have the
 opportunity of including the small bits of information above. I
 apologize for the inconvenience.


 

Bug#327017: fwbuilder is not installed after upgrade to kde 3.4.2.

[Jeremy T. Bouse]

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
Reading package lists... Done
Building dependency tree... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.

Since you only requested a single operation it is extremely likely that
the package is simply not installable and a bug report against
that package should be filed.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 fwbuilder: Depends: libfwbuilder6 (>= 2.0.7-0) but it is not going to
be installed
Depends: libqt3c102-mt (>= 3:3.3.4) but it is not going to
be installed
Depends: libsnmp5 (>= 5.1) but it is not going to be
installed
Depends: fwbuilder-linux but it is not going to be
installed or
 fwbuilder-backend
E: Broken packages


-- System Information:
Debian Release: testing/unstable
 APT prefers unstable
 APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11.050718-skas3-v8
Locale: LANG=en, LC_CTYPE=en (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)

Versions of packages fwbuilder depends on:
ii  fwbuilder-common  2.0.7-1Firewall administration tool GUI (
pn  fwbuilder-linux | fwbuild  (no description available)
ii  libc6 2.3.5-6GNU C Library: Shared libraries an
pn  libfwbuilder6  (no description available)
ii  libgcc1   1:4.0.1-6  GCC support library
pn  libqt3c102-mt  (no description available)
ii  libsnmp5  5.2.1.2-2  NET SNMP (Simple Network Managemen
ii  libssl0.9.7   0.9.7g-1   SSL shared libraries
ii  libstdc++51:3.3.6-9  The GNU Standard C++ Library v3
ii  libwrap0  7.6.dbs-8  Wietse Venema's TCP wrappers libra
ii  libx11-6  6.8.2.dfsg.1-6 X Window System protocol client li
ii  libxext6  6.8.2.dfsg.1-6 X Window System miscellaneous exte
ii  libxml2   2.6.20-1   GNOME XML library
ii  libxslt1.11.1.14-1   XSLT processing library - runtime 
ii  xlibs 6.8.2.dfsg.1-6 X Window System client libraries m

ii  zlib1g1:1.2.3-4  compression library - runtime

fwbuilder recommends no packages.

 




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#322671: libfwbuilder: rebuild needed for C++ ABI transition (NMU patch attached)

[Jeremy T. Bouse]

   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

Steve Langasek wrote:


Package: libfwbuilder
Version: 2.0.7-1
Severity: serious
Tags: patch

Hi Jeremy,

Under the 0-day NMU policy for the C++ ABI transition, I have prepared an
NMU for libfwbuilder, because this library provides C++ interfaces and
must be rebuilt so that a number of other C++-based packages can transition
to g++ 4.0.  The diff for this NMU is attached; the NMU will be uploaded
shortly.  If you see any problems with the patch, let me know so I can have
the package rejected out of NEW.

Thanks,
 




diff -u libfwbuilder-2.0.7/debian/changelog libfwbuilder-2.0.7/debian/changelog
--- libfwbuilder-2.0.7/debian/changelog
+++ libfwbuilder-2.0.7/debian/changelog
@@ -1,3 +1,12 @@
+libfwbuilder (2.0.7-1.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * High-urgency upload for RC bugfix.
+  * Rebuild against g++-4.0 for the C++ ABI transition, renaming
+libfwbuilder6 to libfwbuilder6c2 and conflicting with libfwbuilder6.
+
+ -- Steve Langasek <[EMAIL PROTECTED]>  Thu, 11 Aug 2005 05:54:54 -0700
+
libfwbuilder (2.0.7-1) unstable; urgency=low

  * New upstream release
diff -u libfwbuilder-2.0.7/debian/control libfwbuilder-2.0.7/debian/control
--- libfwbuilder-2.0.7/debian/control
+++ libfwbuilder-2.0.7/debian/control
@@ -8,7 +8,7 @@
Package: libfwbuilder-dev
Section: libdevel
Architecture: any
-Depends: libfwbuilder6 (= ${Source-Version}), libc6-dev
+Depends: libfwbuilder6c2 (= ${Source-Version}), libc6-dev
Description: Firewall Builder API library development files
 This package contains the libraries  and header files that programmer would
 need to develop applications using Firewall Builder API.
@@ -16,11 +16,11 @@
 This package contains the development files needed to compile software to
 use the libfwbuilder API.

-Package: libfwbuilder6
+Package: libfwbuilder6c2
Section: libs
Architecture: any
-Replaces: libfwbuilder0, libfwbuilder3, libfwbuilder4, libfwbuilder5
-Conflicts: libfwbuilder0, libfwbuilder3, libfwbuilder4, libfwbuilder5
+Replaces: libfwbuilder0, libfwbuilder3, libfwbuilder4, libfwbuilder5, 
libfwbuilder6
+Conflicts: libfwbuilder0, libfwbuilder3, libfwbuilder4, libfwbuilder5, 
libfwbuilder6
Depends: ${shlibs:Depends}
Description: Firewall Builder API library
 This package contains the libraries  and header files that programmer would
diff -u libfwbuilder-2.0.7/debian/rules libfwbuilder-2.0.7/debian/rules
--- libfwbuilder-2.0.7/debian/rules
+++ libfwbuilder-2.0.7/debian/rules
@@ -129,8 +129,8 @@
dh_strip -a
dh_compress -a
dh_fixperms -a
-   # dh_makeshlibs -V "libfwbuilder6 (>= $$(sed 's/^.*(\(.*\)-.*).*/\1/; q' 
debian/changelog)-0), libfwbuilder6 (<< $$(sed 's/^.*(\(.*\)-.*).*/\1/; q' 
debian/changelog).0-0)"
-   dh_makeshlibs -V "libfwbuilder6 (>= $$(sed 's/^.*(\(.*\)-.*).*/\1/; q' 
debian/changelog)-0)" -a
+   # dh_makeshlibs -V "libfwbuilder6c2 (>= $$(sed 's/^.*(\(.*\)-.*).*/\1/; q' 
debian/changelog)-0), libfwbuilder6c2 (<< $$(sed 's/^.*(\(.*\)-.*).*/\1/; q' 
debian/changelog).0-0)"
+   dh_makeshlibs -V "libfwbuilder6c2 (>= $$(sed 's/^.*(\(.*\)-.*).*/\1/; q' 
debian/changelog)-0)" -a
dh_installdeb -a
dh_shlibdeps -a
dh_gencontrol -a -u-isp
reverted:
--- libfwbuilder-2.0.7/debian/packages.d/libfwbuilder6.in
+++ libfwbuilder-2.0.7.orig/debian/packages.d/libfwbuilder6.in
@@ -1,11 +0,0 @@
-%dirs%
-usr/lib
-usr/share
-%install%
-usr/lib/lib*.so.*
-usr/lib/lib*.la
-usr/share/libfwbuilder/*
-%docs%
-debian/tmp/usr/share/doc/libfwbuilder/AUTHORS
-debian/tmp/usr/share/doc/libfwbuilder/Credits
-debian/tmp/usr/share/doc/libfwbuilder/PatchAcceptancePolicy.txt
only in patch2:
unchanged:
--- libfwbuilder-2.0.7.orig/debian/packages.d/libfwbuilder6c2.in
+++ libfwbuilder-2.0.7/debian/packages.d/libfwbuilder6c2.in
@@ -0,0 +1,11 @@
+%dirs%
+usr/lib
+usr/share
+%install%
+usr/lib/lib*.so.*
+usr/lib/lib*.la
+usr/share/libfwbuilder/*
+%docs%
+debian/tmp/usr/share/doc/libfwbuilder/AUTHORS
+debian/tmp/usr/share/doc/libfwbuilder/Credits
+debian/tmp/usr/share/doc/libfwbuilder/PatchAcceptancePolicy.txt
 




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#266707: Description proposal

[Jeremy T. Bouse]

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.

Regards,
Jeremy

On Wed, Feb 09, 2005 at 03:41:28PM +, Colin Watson wrote:
> On Sat, Dec 04, 2004 at 09:59:17PM +0100, Cl?ment Stenac wrote:
> > Here is a proposal for an updated description of gcipher
> > 
> > --- gcipher-1.0.orig/debian/control 2004-12-04 21:36:53.0 +0100
> > +++ gcipher-1.0/debian/control  2004-12-04 21:47:45.0 +0100
> > @@ -8,7 +8,12 @@
> >  Package: gcipher
> >  Architecture: all
> >  Depends: ${python:Depends}, python-gnome2, python-glade2
> > -Description: A simple encryption tool
> > - This is a simple encryption tool to work with home-grown encryption
> > - algorithms. It can run as either a GUI, a command-line application,
> > - or a network proxy.
> > +Description: A simple "encryption" tool
> > + This is a simple "encryption" tool to work with common simple encryption
> > + algorithms (Rot13, Cesar, Vigui?re, ...)
> > + .
> > + Gcipher does not provide any strong encryption and should not be used to
> > + encrypt any private data.
> > + . 
> > + Gcipher can run as either a GUI, a command-line application, or a network
> > + proxy.
> > 
> > Please apply or use another description.
> 
> Since there's been no response by the maintainer to this bug yet, I've
> uploaded a patch almost identical to the above (with just a few spelling
> corrections) to the 3-day delayed incoming queue in
> gluck.debian.org:~tfheen/DELAYED/3-day/. I'd welcome a maintainer upload
> superseding this.
> 
> The NMU patch is attached.
> 
> Thanks,
> 
> -- 
> Colin Watson   [EMAIL PROTECTED]

> diff -Nru /tmp/1Z1QConRKX/gcipher-1.0/debian/changelog 
> /tmp/3mpZ80qBzO/gcipher-1.0/debian/changelog
> --- /tmp/1Z1QConRKX/gcipher-1.0/debian/changelog  2004-06-01 
> 07:19:19.0 +0100
> +++ /tmp/3mpZ80qBzO/gcipher-1.0/debian/changelog  2005-02-09 
> 15:32:47.0 +
> @@ -1,3 +1,11 @@
> +gcipher (1.0-3.1) unstable; urgency=low
> +
> +  * Non-maintainer upload.
> +  * Improve description to make it clear that gcipher doesn't provide strong
> +encryption (thanks, Cl?ment Stenac; closes: #266707).
> +
> + -- Colin Watson <[EMAIL PROTECTED]>  Wed,  9 Feb 2005 15:32:46 +
> +
>  gcipher (1.0-3) unstable; urgency=low
>  
>* Reverted back to ${python:Depends} in debian/control
> diff -Nru /tmp/1Z1QConRKX/gcipher-1.0/debian/control 
> /tmp/3mpZ80qBzO/gcipher-1.0/debian/control
> --- /tmp/1Z1QConRKX/gcipher-1.0/debian/control2004-06-01 
> 07:25:46.0 +0100
> +++ /tmp/3mpZ80qBzO/gcipher-1.0/debian/control2005-02-09 
> 15:25:38.0 +
> @@ -8,7 +8,12 @@
>  Package: gcipher
>  Architecture: all
>  Depends: ${python:Depends}, python-gnome2, python-glade2
> -Description: A simple encryption tool
> - This is a simple encryption tool to work with home-grown encryption
> - algorithms. It can run as either a GUI, a command-line application,
> - or a network proxy.
> +Description: A simple "encryption" tool
> + This is a simple "encryption" tool to work with common simple encryption
> + algorithms (ROT13, Caesar, Vigen?re, ...)
> + .
> + Gcipher does not provide any strong encryption and should not be used to
> + encrypt any private data.
> + . 
> + Gcipher can run as either a GUI, a command-line application, or a network
> + proxy.



signature.asc
Description: Digital signature