Bug#629204: Fixed version ready for test

2011-08-30 Thread Federico Gimenez Nieto
Hi,

I've written a patch that seems to work with both gnustep-base/1.20 and 1.22. 
I'm waiting for
upstream's approval [1], it can be grabbed here [2] if anyone wants to test it.

Cheers,
Federico

[1] http://lists.gnu.org/archive/html/gnustep-dev/2011-08/msg00095.html
[2] git://git.debian.org/pkg-gnustep/gnustep-dl2.git




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



Bug#622674: Updated package due to bug 622674, CVE 2011-1522

2011-04-18 Thread Federico Gimenez Nieto
Hi, i am one of the maintainers of the doctrine debian package. A security 
related bug has arised
recently [1] and i've prepared a new package following upstream recomendations 
[2]. The fix involves
upgrading to a new upstream version, i've tested it and all seems to work fine, 
although i don't
know if this is acceptable for a security issue in the debian stable 
distribution.

It is uploaded at mentors [3], please, let me know if all is in good shape. I'm 
not sure if things
are done properly, for example, as long as it is targeted to stable-security, 
i've built the package
on stable...

Thanks a lot, cheers
Federico

[1] http://bugs.debian.org/622674
[2] http://www.doctrine-project.org/blog/doctrine-security-fix
[3] http://mentors.debian.net/debian/pool/main/d/doctrine/doctrine_1.2.4-1.dsc






signature.asc
Description: OpenPGP digital signature


Bug#622674: [Pkg-symfony-maint] Bug#622674: CVE-2011-1522: SQL injection

2011-04-14 Thread Federico Gimenez Nieto
Hi, thanks for your bug report. I'll try to prepare a fixed package as soon as 
posible.

Cheers,
Federico

On 04/13/2011 08:45 PM, Moritz Muehlenhoff wrote:
 Package: doctrine
 Severity: grave
 Tags: security
 
 Please see http://www.doctrine-project.org/blog/doctrine-security-fix  
 
 This has been assigned CVE-2011-1522.
 
 Cheers,
 Moritz
 
 -- System Information:
 Debian Release: wheezy/sid
   APT prefers unstable
   APT policy: (500, 'unstable')
 Architecture: amd64 (x86_64)
 
 Kernel: Linux 2.6.38-1-amd64 (SMP w/2 CPU cores)
 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 
 
 
 ___
 Pkg-symfony-maint mailing list
 pkg-symfony-ma...@lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/pkg-symfony-maint
 

-- 
Federico Giménez Nieto
fgime...@coit.es




signature.asc
Description: OpenPGP digital signature


Bug#618181: gnustep-dl2: FTBFS: EOModelerEditor.m:52:38: fatal error: GNUstepBase/GSCategories.h: No such file or directory

2011-03-16 Thread Federico Gimenez Nieto


On 03/15/2011 05:39 PM, Yavor Doganov wrote:
 
 Without investigation: most probably this is related to the new
 behavior of GCC 4.5 to bail out immediately if an #include'd header is
 not present.
 

Thanks Yavor, i'll prepare the fixed package.

Cheers
Federico



signature.asc
Description: OpenPGP digital signature


Bug#591115: Bug forwarded

2010-11-30 Thread Federico Gimenez Nieto
Hi Alexander,

Alexander Reichle-Schmehl wrote:
 Hi!

[...]
 
 Has there been any progress with this bug?  

None so far...

 I see the new package is
 still on mentors, but I don't think the release managers will accept a
 new upstream release at this stage of the freeze, therefore I'm
 currently not considering sponsoring your package.
 
 However, if I understood it correctly, upstream removed the failed
 test causing this FTBFS?  

Yes, in the last upstream version there are no tests.

 So my understanding would be, that a
 legitimate fix would be to disbale this test (without uploading a NEW
 upstream version).  If you could prepere that, I'm willing to sponsor
 the upload; if you got the OK from the release team for the new upstream
 version, I'm also willing to upload the version on mentors.
 

Ok, i've prepared a package with the old upstream version and the tests
disabled at build time, which prevents the FTBFS. It is uploaded at
mentors [1]

Thanks a lot, cheers

[1]
http://mentors.debian.net/debian/pool/main/d/doctrine/doctrine_1.2.2-2.dsc




signature.asc
Description: OpenPGP digital signature


Bug#591115: Bug forwarded

2010-10-11 Thread Federico Gimenez Nieto
Hi Julien,

Julien Cristau wrote:
 
 did you manage to make any progress on this?
 
 

I haven't received any response from upstream. After this problem raised
a new version of doctrine came out, this time without the test suite.
Since the cause of the FTBFS is a failing test (the package didn't build
if any test didn't pass), i've packaged this new version and at first
glance the bug would be solved (the package is uploaded to mentors [1]).
This doesn't solve the root cause of the test failure, of course.

[1]
http://mentors.debian.net/debian/pool/main/d/doctrine/doctrine_1.2.3-1.dsc


Although there is code in the source package that seems to be very
32-bit specific (for example the size of integer fields in the DBTable
class), the documentation doesn't say that the package is arch-specific.
Moreover, i have a doctrine instance working in a amd64 machine whitout
any problem, and i haven't seen any bug report regarding arch issues,
besides this FTBFS.

So perhaps the problem was with the unit test itself, or with the
features being tested. I'm not sure if it is a good idea to upload the
new version with the fixed FTBFS or to prepare an architecture specific
version, what do you think?

Thanks,
Federico



signature.asc
Description: OpenPGP digital signature


Bug#595344: php-xml-serializer uses deprecated return value of new by reference

2010-09-05 Thread Federico Gimenez Nieto
Hi Thomas,

El 05/09/2010, a las 01:10, Thomas Goirand escribió:
 
 Hi,
 
 I don't agree. Some scripts (like mine) run with error_reporting(E_ALL);
 In my case, I run it from a cron job, and this would send me a mail
 every 10 minutes (because it outputs to the standard error).
 

Did you try the test case that i attached on the previous message? With 
error_reporting(E_ALL) it serializes a xml document to a file and then reads 
and unserializes it back without noticing any error or warning interfering the 
overall operation. The problem may be related to your code.

 Anyway, it's silly to discuss the seriousness of the bug anyway, we just
 need to have it fixed for Squeeze. The fix is just remove 3 characters
 in the Unserialize.php, so it's trivial. If you don't have time to fix
 it, let me know, and I will NMU the fix.
 

As i can't reproduce the bug i can't prepare a fix for it. Don't hesitate to 
make the NMU if you feel that it is needed and you are sure that it won't 
introduce any flaws. Anyway, in my opinion it would be a good idea to report 
this upstream, it can be done at [1]

Cheers
Federico

[1]http://pear.php.net/bugs/search.php?cmd=displaypackage_name[]=XML_Serializer

Bug#595344: php-xml-serializer uses deprecated return value of new by reference

2010-09-04 Thread Federico Gimenez Nieto
Hi Thomas, this warning only appears if you require
'XML/Unserializer.php' (that is, you are going to  unserialize a xml
string) and only if you have set your error level to show warnings at
the output.

So, it won't make the package unusable for most users, because if an
user wants to return a xml document it can be done without noticing any
warning. Hence the severity of the bug shouldn't be 'serious'.

I'll forward this bug upstream and try to work on a patch by myself.

Cheers,
Federico

Thomas Goirand wrote:
 Hi,
 
 I simply have a cron job that does:
 
 require_once 'XML/Serializer.php';
 require_once XML/Unserializer.php;
 
 it doesn't even need to call any of the methods of Unserializer.php.
 When there's a:
 
 $myvar = new [...]
 
 PHP 5.3.x generates a warning even before you start using the file. It
 does it at parsing time. Just try by yourself in Squeeze / SID, or with
 any system that is running PHP 5.3, then you'll see it.
 
 Can you get in touch with upstream and have them fix it? Will you need
 sponsoring for this issue, once the package is fixed? Let me know, I'll
 be available for such help.
 
 Thomas Goirand (zigo)
 
 
 

-- 
Federico Giménez Nieto
fgime...@coit.es




signature.asc
Description: OpenPGP digital signature


Bug#595344: php-xml-serializer uses deprecated return value of new by reference

2010-09-04 Thread Federico Gimenez Nieto
Hi Thomas,

First of all, thanks for the sponsoring offer, i forget to thank you on
the previous response :)

I haven't been able to reproduce the bug, it would be fine to do so
before forwarding it upstream. I've attached a simple test case which
works without problems on sid, could you please review it and let me
know if it works for you?

Cheers
Federico

Federico Gimenez Nieto wrote:
 Hi Thomas, this warning only appears if you require
 'XML/Unserializer.php' (that is, you are going to  unserialize a xml
 string) and only if you have set your error level to show warnings at
 the output.
 
 So, it won't make the package unusable for most users, because if an
 user wants to return a xml document it can be done without noticing any
 warning. Hence the severity of the bug shouldn't be 'serious'.
 
 I'll forward this bug upstream and try to work on a patch by myself.
 
 Cheers,
 Federico
 
 Thomas Goirand wrote:
 Hi,

 I simply have a cron job that does:

 require_once 'XML/Serializer.php';
 require_once XML/Unserializer.php;

 it doesn't even need to call any of the methods of Unserializer.php.
 When there's a:

 $myvar = new [...]

 PHP 5.3.x generates a warning even before you start using the file. It
 does it at parsing time. Just try by yourself in Squeeze / SID, or with
 any system that is running PHP 5.3, then you'll see it.

 Can you get in touch with upstream and have them fix it? Will you need
 sponsoring for this issue, once the package is fixed? Let me know, I'll
 be available for such help.

 Thomas Goirand (zigo)



 

-- 
Federico Giménez Nieto
fgime...@coit.es

attachment: test.php


signature.asc
Description: OpenPGP digital signature


Bug#595344: php-xml-serializer uses deprecated return value of new by reference

2010-09-03 Thread Federico Gimenez Nieto
Hi Thomas, thanks for the bug report.

Could you please explain a bit more about the conditions in which the
warnings raised? I have been trying the examples of XML generation at
[1] and all of them worked without problems and without noticing any
warning.

[1] http://pear.php.net/manual/en/package.xml.xml-serializer.intro.php

As you point out, php-xml-serializer can be used to produce a xml
document, this is done with the 'serialize' method. If any text is
thrown while outputing the xml document the package would be certainly
unusable for most users, because the generated document could be at
least not well formed.

But the warnings that you found are refering to code in the
Unserialize.php file, how are you getting them?

Cheers,
Federico

Thomas Goirand wrote:
 Package: php-xml-serializer
 Version: 0.20.0-2
 Severity: grave
 
 Hi,
 
 When using the package with PHP 5.3.2 that is currently in Squeeze and
 SID, there are 3 big warnings:
 
 PHP Deprecated:  Assigning the return value of new by reference is
 deprecated in /usr/share/php/XML/Unserializer.php on line 801
 
 PHP Deprecated:  Assigning the return value of new by reference is
 deprecated in /usr/share/php/XML/Unserializer.php on line 804
 
 PHP Deprecated:  Assigning the return value of new by reference is
 deprecated in /usr/share/php/XML/Unserializer.php on line 974
 
 As php-xml-serializer can be used to produce an XML document, having
 these warnings could render the produced XML documents as totally broken,
 which is what pushed me to set the seriousness of this bug to Grave (eg:
 renders the package unusable for most users). This has to be fixed before
 Squeeze is release. I'll try to work on a patch for it, but if you have
 more work time available than I do, please fix the package.
 
 Cheers,
 
 Thomas Goirand (zigo)
 
 -- System Information:
 Debian Release: 5.0.5
   APT prefers stable
   APT policy: (500, 'stable')
 Architecture: amd64 (x86_64)
 
 Kernel: Linux 2.6.32-4-xen-amd64 (SMP w/2 CPU cores)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/bash
 
 
 

-- 
Federico Giménez Nieto
fgime...@coit.es




signature.asc
Description: OpenPGP digital signature


Bug#591115: Bug forwarded

2010-08-30 Thread Federico Gimenez Nieto
forwarded 591115 http://www.doctrine-project.org/jira/browse/DC-772
thanks

Hi, thanks for the bugreport and sorry for the late response.

The bug has been already forwarded upstream, it seems that, although not
stated anywhere in the documentation, there are some arch-dependent
features, at least for 1.2.2 version.

I'll keep trying to find the cause of the problem and post here any
progress.

Cheers,
Federico



signature.asc
Description: OpenPGP digital signature


Bug#594443: Workaround: libsteptalk0 replaces steptalk

2010-08-27 Thread Federico Gimenez Nieto
Yavor Doganov wrote:
 
 I think you actually need Conflicts, because Replaces would sneakily
 replace libraries in the old package, 

Ok, it is corrected and reuploaded, i'll try to find a sponsor now.

Thanks
Federico



signature.asc
Description: OpenPGP digital signature


Bug#594443: Workaround: libsteptalk0 replaces steptalk

2010-08-26 Thread Federico Gimenez Nieto
Hi, i've uploaded a new version of gnustep-dl2 stating that
libgnustep-dl2-0d replaces libgnustep-dl2-0. I hope that this will
resolve the issue, could you please take a look [1]?

[1]
http://mentors.debian.net/debian/pool/main/g/gnustep-dl2/gnustep-dl2_0.12.0-5.dsc

Cheers
Federico

Yavor Doganov wrote:
 В 12:31 +0200 на 26.08.2010 (чт), Yves Lambert написа:
 A clean and probably safe workaround is to remove steptalk as it is
 replaced by libsteptalk0 which does not depend on libgnustep-dl2-0.

 Due to bug #594443 (this bug), libgnustep-dl2-0 and steptalk 
 must be removed priorly to installing libgnustep-dl2-0 
 
 libgnustep-dl2-0d must simply declare proper package relationship wrt
 libgnustep-dl2-0; then it would be a human decision whether to hold the
 upgrade of gnustep-dl2 or remove steptalk.  dpkg errors like these are
 clear bugs which should be fixed, not worked around.
 
 
 
 

-- 
Federico Giménez Nieto
fgime...@coit.es




signature.asc
Description: OpenPGP digital signature


Bug#581934: GNUstep transition

2010-08-23 Thread Federico Gimenez Nieto
Hi,

Yavor Doganov wrote:
 
 I'm afraid I don't understand the question.  If upstream bumps the
 SONAME, it isn't distro-specific in anyway, right?  AFAICT, (in Debian
 at least; I'm not aware of other practices) a distro-specific SONAME
 for a library is introduced when
 
 1) An ABI breaking Debian-specific patch has been added; which
- might be rejected by upstream (for whatever reason);
- might be a bugfix already present upstream, but
  ABI-incompatible with the version in Debian (as is the case).
 2) A new upstream release is ABI incompatible, but upstream forgot
to indicate that with the proper mechanism (this happens quite
often for ObjC libraries, unfortunately).
 3) Upstream is providing a library, but it doesn't have any
interface versioning mechanism (as some of the Mozilla
libraries).
 4) Something else I surely forget.

Thanks for the clarification, i am pretty lost here.

 
 So, you should make sure that upstream bumps the SONAME for next
 release (0.13?), because there are ABI breaks all over the place
 (affecting all public libraries).  For the current transition, the
 attached minimized patch seems to work for me, 

Ok, thanks a lot, it have worked in my tests too.

 but don't forget to:
 
   - Perform extensive runtime tests; most changes are not trivial.
   - Rename the runtime library to libgnustep-dl-0d (debian/control);
 and update dependencies (this implies passing through NEW).
   - Amend debian/rules to cater for the package rename.
   - Rename debian/libgnustep-dl-0.install as
 debian/libgnustep-dl-0d.install and adjust the EOControl entry for
 soname change.
 

I've uploaded to mentors a new version with all these changes applied,
could you please take a look [1]?


[1]
http://mentors.debian.net/debian/pool/main/g/gnustep-dl2/gnustep-dl2_0.12.0-4.dsc


Cheers,
Federico



signature.asc
Description: OpenPGP digital signature


Bug#581934: GNUstep transition

2010-08-23 Thread Federico Gimenez Nieto
Yavor Doganov wrote:
 В 09:58 +0200 на 23.08.2010 (пн), Federico Gimenez Nieto написа:
 Thanks for the clarification, i am pretty lost here.
 
 I'd be glad to explain in detail if you let me know what you find
 confusing.
 

Thanks, with your previous explanations i understand the big picture,
i'll ping you if i have questions about any details related to this.

Cheers
Federico



signature.asc
Description: OpenPGP digital signature


Bug#581934: GNUstep transition

2010-08-23 Thread Federico Gimenez Nieto
Hi,

Mehdi Dogguy wrote:
 Do you have a sponsor for this upload? If not, I can upload it. I'll
 just wait for gorm.app and renaissance to be available on all
 architectures and then proceed with the upload. Is this ok for you?
 

Of course, thanks a lot! :)

Cheers,
Federico



signature.asc
Description: OpenPGP digital signature


Bug#583006: Bug#581934: gnustep-dl2: FTBFS with gnustep-base/1.20.0: EONSAddOns.m:102: error: ‘GSMethodList’ undeclared (first use in this function)

2010-05-27 Thread Federico Gimenez Nieto
On Wed, 2010-05-26 at 22:03 +0300, Yavor Doganov wrote:

Thanks, now it is bulding without problems, it is uploaded at mentors
[1]

[1]
http://mentors.debian.net/debian/pool/main/g/gnustep-dl2/gnustep-dl2_0.12.0-3.dsc

 
 (The GSMethodList FTBFS is gnustep-base/1.20.x-specific so you can't
 notice it in sid, but it will become RC when the new Base is uploaded
 in unstable.  It is fixed upstream, easily backportable, but
 unfortunately the change is ABI-breaking for EOControl :-(.)
 

Is there any chance to prevent this FTBFS while keeping EOControl in
good shape?

Cheers, 
Federico


signature.asc
Description: This is a digitally signed message part


Bug#583006: Bug#581934: gnustep-dl2: FTBFS with gnustep-base/1.20.0: EONSAddOns.m:102: error: ‘GSMethodList’ undeclared (first use in this function)

2010-05-26 Thread Federico Gimenez Nieto
On Tue, 2010-05-25 at 13:30 +0300, Yavor Doganov wrote:
 
 I bet that once you fix the above in the usual way (i.e. conditionally
 define `debug', not `OPTLFAG'), you'll be able to reproduce it with
 gnustep-base/1.20.0.
 

It is strange, conditionally defining 'debug=yes' leads to the same
NSDebugMLog related error... Finally i managed to get rid of it (without
noticing the GSMethodList related error) by patching
EOAccess/EOAttribute.m (replacing all Foundation related import
statements by unconditionally importing Foundation/Foundation.h) but now
the docs are not being generated, why might this be happening?

Cheers,
Federico


signature.asc
Description: This is a digitally signed message part


Bug#544405: #544405 already fixed?

2009-10-13 Thread Federico Gimenez Nieto
Hi Jonas,

Jonas Smedegaard wrote:
 Sorry - I am unable to verify due to bug#548015. :-(

If you want to give it a try i have a qemu sid image at [1] (209mb and
slightly outdated, apt-get upgrade required). root password is 'fossy'

[1]
http://www.adrive.com/public/4cb78428ae7c9ed81d7330c916ebab53e96dce709669d36bb07f1cf5f52e8865.html

Hope this helps, cheers,
Federico




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



Bug#546164: Already fixed

2009-09-23 Thread Federico Gimenez Nieto
Hi,

This seems to be fixed after the upload of 5.2.11.dsfg.1-1.

Thanks,
Federico



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



Bug#544405: #544405 already fixed?

2009-09-23 Thread Federico Gimenez Nieto
Hi Jonas,

cid:part1.02050506.00090002@coit.esThis seems to be fixed with the
latest version of php-pear, 5.2.11.dsfg.1-1, could you please check if
it is properly working?

Thanks,
Federico



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