RFS: evilvte (updated package)

[Wen-Yen Chuang]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear mentors,

I am looking for a sponsor for the new version 0.4.4.2-1
of my package "evilvte". (Programming language: C)

It builds the binary package: evilvte

The latest entry in the Debian changelog is:
 evilvte (0.4.4.2-1) unstable; urgency=low
 .
   * New upstream bugfix release
 - fix an CLOSE_DIALOG bug which could destroy the program by
   accident
   * Update debian/rules to use "$(MAKE) distclean" instead of
 "$(MAKE) clean"
   * Bump Standards-Version to 3.8.2, no changes needed.

Description: an VTE based super lightweight terminal emulator
 evilvte is a terminal emulator. It supports almost everything VTE
 provides. It also supports tabs, tabbar autohide, and switch encoding
 at runtime. Configuration is via editing source code and recompilation.
 .
 This build provides all runtime changeable options in the right-click
 menu.

The package is lintian clean.

The package can be found on mentors.debian.net:
- - dget
http://mentors.debian.net/debian/pool/main/e/evilvte/evilvte_0.4.4.2-1.dsc

I would be glad if someone uploaded this package for me. :-)

Kind regards
 Wen-Yen Chuang

- --
My GPG key is signed by Debian Developer Masayuki Hatta.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkp32/IACgkQdEpXpumNYVkoSACcDdaxTmZ6AMo4/U+NVbEk/td8
hEwAnRuq2EMHofiqsXL+i0furNLnNcJZ
=Tyet
-END PGP SIGNATURE-


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

Re: RFS: task-spooler

[Alexander Inyukhin]

On Mon, Aug 03, 2009 at 08:48:52PM -0300, David Bremner wrote:
> 1) I expect whoever does sponsor it will ask you to compress
> debian/changelog a bit. Typically there should be 1 changelog entry
> per debian upload. Sorry I didn't mention this in my mail to BTS.

I've just re-uploaded the package.

http://mentors.debian.net/debian/pool/main/t/task-spooler/task-spooler_0.6.4-3.dsc

> 2) Is there any security risk in the control socket(s) for ts being
> world readable? Or is that just controlled by users umask?

Read and write permissions are required to connect unix socket on Linux.

Socket permissions are controlled by umask, but if security
matters, a more sophisticated way of managing sockets should be used.
Since task-spooler is intented for use in single user environment,
I do not think this is a serious issue.


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

RFS: php-net-ldap2 (updated package)

[Benoit Mortier]

Dear mentors,

I am looking for a sponsor for the new version 2.0.5-1
of my package "php-net-ldap2".

i just adopted the package by ITA the bug number is #529692

It builds these binary packages:
php-net-ldap2 - Object oriented interface for searching and manipulating 
LDAP-entries

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/p/php-net-ldap2
- Source repository: deb-src http://mentors.debian.net/debian unstable 
main contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/p/php-net-ldap2/php-net-ldap2_2.0.5-1.dsc

I would be glad if someone uploaded this package for me.

Kind regards
Benoit Mortier
-- 
Benoit Mortier
CEO 
OpenSides "logiciels libres pour entreprises" : http://www.opensides.be/
Contributor to Gosa Project : http://gosa-project.org/


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

RFS: pdfchain

[Johann Felix Soden]

Dear mentors,

I am looking for a sponsor for my package "pdfchain".

* Package name: pdfchain
  Version : 0.123-1
  Upstream Author : Martin Singer (m_pow...@users.sourceforge.net)
* URL : http://pdfchain.sourceforge.net/
* License : GPL-3+
  Programming Lang: C++
  Section : text

It builds these binary packages:
pdfchain   - a graphical user interface for the PDF Tool Kit

pdfchain a is GUI for pdftk, written in C++ with GTKmm.

The package appears to be lintian clean.

The upload would fix these bugs: 539866

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/p/pdfchain
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/p/pdfchain/pdfchain_0.123-1.dsc

I've used the existing ubuntu-ppa package
( https://launchpad.net/pdfchain ) from Günther Bauer as template, but
reworked it almost completely. Additionally, I've looked through the
Fedora package.

I would be glad if someone uploaded this package for me.

Kind regards
 Johann Felix Soden


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

Automated package build-and-test tools for Debian package maintainers (was: pbuilder: The following packages have unmet dependencies)

[Ben Finney]

Charles Plessy  writes:

> this breakage [of pbuilder] gave me a good opportunity to realise that
> sbuild has become almost as easy to use as cowbuilder.

What are the relative merits of the various automated package testing
tools, from the perspective of someone maintaining packages for Debian
using their own system resources?

That is, if I'm maintaining packages for Debian and want to build and
test them in an easy and automated manner, what tools are available
(‘pbuilder’, ‘sbuild’, ‘cowbuilder’, …) and for each of them why would I
choose that one?

-- 
 \  “If you wish to strive for peace of soul, then believe; if you |
  `\  wish to be a devotee of truth, then inquire.” —Friedrich |
_o__)Nietzsche |
Ben Finney


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

Re: RFS: task-spooler

[Boyd Stephen Smith Jr.]

In <20090804100620.ga8...@shurick.s2s.msu.ru>, Alexander Inyukhin wrote:
>Socket permissions are controlled by umask, but if security
>matters, a more sophisticated way of managing sockets should be used.
>Since task-spooler is intented for use in single user environment,
>I do not think this is a serious issue.

Unfortunately, Debian is not limited to use as a single-user environment so 
you may need to revisit the security implications.  At the very least, you 
may want to warn the administrator that it is not suitable for multi-user 
environments.

Any reason task-spooler can't secure it's sockets the same way ssh-agent 
and/or gpg-agent secure theirs?
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net  ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/



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

Re: Automated package build-and-test tools for Debian package maintainers (was: pbuilder: The following packages have unmet dependencies)

[Boyd Stephen Smith Jr.]

In <87bpmvsux5.fsf...@benfinney.id.au>, Ben Finney wrote:
>That is, if I'm maintaining packages for Debian and want to build and
>test them in an easy and automated manner, what tools are available
>(‘pbuilder’, ‘sbuild’, ‘cowbuilder’, …) and for each of them why would I
>choose that one?

There's really only two that I know of.  pbuilder (and variants: 
qemubuilder, cowbuilder, etc.) and sbuild.  ISTR, sbuild is used on the 
buildds, but all my experience is with pbuilder.  I find it incredibly 
flexible when needed but also very easy to get started with a minimum of 
documentation reading.
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net  ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/



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

Re: Automated package build-and-test tools for Debian package maintainers (was: pbuilder: The following packages have unmet dependencies)

[Jonathan Wiltshire]

On Tue, Aug 04, 2009 at 09:57:49AM -0500, Boyd Stephen Smith Jr. wrote:
> There's really only two that I know of.  pbuilder (and variants: 
> qemubuilder, cowbuilder, etc.) and sbuild.  ISTR, sbuild is used on the 
> buildds, but all my experience is with pbuilder.  I find it incredibly 
> flexible when needed but also very easy to get started with a minimum of 
> documentation reading.

Yes, AIUI sbuild is used on the builders. I build everything in
cowbuilder though, it saves cluttering the machine with dependency
satisfiers. cowbuilder uses copy-on-write and an uncompressed chroot,
which saves waiting ten minutes for the pbuilder tar.gz to decompress.



-- 
Jonathan Wiltshire

1024D: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3  A903 CA6B EA3E DB80 0B52
4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51


signature.asc
Description: Digital signature

Re: RFS: task-spooler

[Alexander Inyukhin]

On Tue, Aug 04, 2009 at 09:52:23AM -0500, Boyd Stephen Smith Jr. wrote:
> In <20090804100620.ga8...@shurick.s2s.msu.ru>, Alexander Inyukhin wrote:
> >Socket permissions are controlled by umask, but if security
> >matters, a more sophisticated way of managing sockets should be used.
> >Since task-spooler is intented for use in single user environment,
> >I do not think this is a serious issue.
> 
> Unfortunately, Debian is not limited to use as a single-user environment so 
> you may need to revisit the security implications.  At the very least, you 
> may want to warn the administrator that it is not suitable for multi-user 
> environments.
> 
> Any reason task-spooler can't secure it's sockets the same way ssh-agent 
> and/or gpg-agent secure theirs?

Actually, it can. It is just not the default behavior.
User may override socket location via environment variables TMPDIR or TS_SOCKET.
As with gpg-agent, this requires additional setup.

Creating socket with predefined name in user's home directory seems to be
a better choice. Is there any policy rules about socket naming?


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

RFS: azureus (updated package)

[Adrian Perez]

Dear friends,

I am looking for a sponsor and reviewer for the new version 4.2.0.4-1
of my package "azureus".

It builds these binary packages:
azureus- BitTorrent client
vuze   - Multimedia BitTorrent client

The package appears to be lintian clean.

The upload would fix these bugs: 329018, 398014, 409952, 412213, 491624, 
515015, 516059

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/a/azureus
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/a/azureus/azureus_4.2.0.4-1.dsc

I would be glad if someone uploaded this package for me.

-- 
Best regards, 

Adrian Perez 


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

Ceasing sponsoring and unsubscribing

[Neil Williams]

I'm still on VAC due to ill health. As part of the management of my
condition, I must reduce my general Debian workload. I'm unsubscribing
from various Debian mailing lists, including this one. I'll update my
sponsoring page appropriately once I am actually back at home. (I
cannot make any uploads right now anyway.)

I am undecided whether to continue sponsoring the packages that I have
done so far - I'll email each maintainer separately. I'll also be
orphaning (or seeking the removal) of some of my current packages as
well as taking a far smaller role in future release cycles. Emdebian
will remain my primary focus but even there, my input will be reduced.

If I do decide to no longer sponsor your package, I will not reverse
such a decision, no matter what the pleading and no matter no urgent
the bug fix. Health is more important than Debian.

I am unsure whether I will return to sponsoring once the current
illness is under control. Pressure to return is likely to be
counter-productive.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpqm2KMYiyUe.pgp
Description: PGP signature

Re: RFS: azureus (updated package)

[Margarita Manterola]

On Tue, Aug 4, 2009 at 1:38 PM, Adrian Perez wrote:

> The upload would fix these bugs: 329018, 398014, 409952, 412213, 491624, 
> 515015, 516059

What about:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509880
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506027
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496461
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=450942
(...)

There are many bugs, I know, but it'd be nice if you could at least
reply to them, giving that you are adopting the package.

I also wonder about the adoption, what happened?  Did Shaun give it up or what?

Is the package going to be team-maintained now?  If so, I doubt that
you need to send it through mentors.

-- 
Besos,
Marga


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

Re: RFS: azureus (updated package)

[Adrian Perez]

I'll fix the remaining bugs manually when I confirm that they are 
a) fixed upstream
b) merged
c) no longer relevant.

So, it's true that I might have skipped sending through mentors, but I
want as many eyes as possible.

Yes Shaun RFA'ed azureus a while ago, he was helping me with reviewing
it, (along with swt-gtk). Hope that answers your question.


Thanks for all. Best regards.

On Tue, 2009-08-04 at 14:35 -0300, Margarita Manterola wrote:
> On Tue, Aug 4, 2009 at 1:38 PM, Adrian Perez wrote:
> 
> > The upload would fix these bugs: 329018, 398014, 409952, 412213, 491624, 
> > 515015, 516059
> 
> What about:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509880
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506027
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496461
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=450942
> (...)
> 
> There are many bugs, I know, but it'd be nice if you could at least
> reply to them, giving that you are adopting the package.
> 
> I also wonder about the adoption, what happened?  Did Shaun give it up or 
> what?
> 
> Is the package going to be team-maintained now?  If so, I doubt that
> you need to send it through mentors.
> 
> -- 
> Besos,
> Marga
> 
> 
-- 
Best regards, 

Adrian Perez 


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

Re: RFS: magicfilter (updated package)

[Rogério Brito]

Hi, Russ and other mentors.

On Aug 03 2009, Russ Allbery wrote:
> Rogério Brito  writes:
>
> > I have one off-topic comment: I've seen some well known maintainers
> > do some things without the rigor that mentors apply to prospective
> > maintainers.
> 
> Yes.  It's a little frustrating.

Frustrating is indeed the right word.

I see some weaknesses in the way that Debian is currently structured and
I think that I will write a longer e-mail about that (things that are
easily changed). Let's hope that I have the energy for that.

> > dget 
> > http://mentors.debian.net/debian/pool/main/m/magicfilter/magicfilter_1.2-62.dsc
> 
> It looks like there's an accidental change to the timestamp for the
> previous release in debian/changelog:

Ooops. Fixed. The updated sources are again at the same address.


Thanks, Rogério Brito.

-- 
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org


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

RFS: remotetea - Sun ONC/RPC support for Java

[PICCA Frédéric-Emmanuel]

Dear mentors,

I am looking for a sponsor for my package "remotetea".

* Package name: remotetea
  Version : 1.0.7-1
  Upstream Author : [fill in name and email of upstream]
* URL : http://remotetea.sourceforge.net/
* License : LGPL
  Section : java

It builds these binary packages:
remotetea  - Sun ONC/RPC support for Java

The package appears to be lintian clean.

The upload would fix these bugs: 539375

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/r/remotetea
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/r/remotetea/remotetea_1.0.7-1.dsc

This package use the dh build system with the javahelper.
It have been review by peoples on the debian-java list.
the description was approved by the l10-english list.

It provides a java Sun RPC implementation.

I would appreciate if someone uploaded this package for me.

Kind regards
 Picca Frédéric


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

Re: RFS: yajl

[George Danchev]

> Dear mentors,

Hi,

> I am looking for a sponsor for my package "yajl".
>
> * Package name: yajl
>   Version : 1.0.5.dfsg-1
>   Upstream Author : Lloyd Hilaiel 
> * URL : http://lloyd.github.com/yajl/
> * License : BSD
>   Section : libs
>
> It builds these binary packages:
> libyajl-dev - Yet Another JSON Library - development files
> libyajl-doc - Yet Another JSON Library - library documentation
> libyajl1   - Yet Another JSON Library
> libyajl1-dbg - Yet Another JSON Library - library documentation
> yajl-tools - Yet Another JSON Library - tools
>
> The package appears to be lintian clean.
>
> The upload would fix these bugs: 537199
>
> The package can be found on mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/y/yajl
> - Source repository: deb-src http://mentors.debian.net/debian unstable main
> contrib non-free - dget
> http://mentors.debian.net/debian/pool/main/y/yajl/yajl_1.0.5.dfsg-1.dsc
>
> I would be glad if someone uploaded this package for me.

I haven't review the package, but it would be very nice if anyone can compare 
that to the json-c project [1], which looks quite serious to me, at least as 
briefly scanning through the code. We have JSON implementations in almost any 
language already available in Debian (including a C++ one, which is nice), but 
not for C. I haven't used neither of these, but would appreciate a review by 
someone who has used any of these in their apps.

[1] http://oss.metaparadigm.com/json-c/
(documentation is scarce)

-- 
pub 4096R/0E4BD0AB 2003-03-18 


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

Re: RFS: task-spooler

[Boyd Stephen Smith Jr.]

In Tuesday 04 August 2009, you wrote:
>On Tue, Aug 04, 2009 at 09:52:23AM -0500, Boyd Stephen Smith Jr. wrote:
>> In <20090804100620.ga8...@shurick.s2s.msu.ru>, Alexander Inyukhin wrote:
>> >Socket permissions are controlled by umask, but if security
>> >matters, a more sophisticated way of managing sockets should be used.
>> >Since task-spooler is intented for use in single user environment,
>> >I do not think this is a serious issue.
>>
>> Unfortunately, Debian is not limited to use as a single-user environment
>> so you may need to revisit the security implications.  At the very
>> least, you may want to warn the administrator that it is not suitable
>> for multi-user environments.
>>
>> Any reason task-spooler can't secure it's sockets the same way ssh-agent
>> and/or gpg-agent secure theirs?
>
>Actually, it can. It is just not the default behavior.
>User may override socket location via environment variables TMPDIR or
> TS_SOCKET. As with gpg-agent, this requires additional setup.

Hrm, I'm not using any special GPG settings and my socket resides in 
/tmp/gpg-6qK7UK/S.gpg-agent; my ssh-agent is in a similar location.

>Creating socket with predefined name in user's home directory seems to be
>a better choice. Is there any policy rules about socket naming?

I think secure-by-default would be the better choice.  I don't know what 
kind of information is passed over the socket, but if it is in a 
(group/world) writable directory[1] or (group/world) readable/writable 
itself it is possible a local attacker could hijack the connection.

As far as I know there is no policy.  I'm not a DD and speak only for 
myself.  I don't mean to hold up the sponsoring of the package if my issues 
don't bother the sponsors.

Creating the socket as mode 600 in the user's home directory seems 
relatively safe, but isolating it in a mode 700 directory doesn't seem like 
a bad idea.
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net  ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/

[1] I suppose a user's home directory might be group writable, but that 
seems unusual.


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

Re: RFS: yajl

[John Stamp]

On Tuesday 04 August 2009 12:07:11 pm George Danchev wrote:
> I haven't review the package, but it would be very nice if anyone can
> compare that to the json-c project [1], which looks quite serious to
> me, at least as briefly scanning through the code. We have JSON
> implementations in almost any language already available in Debian
> (including a C++ one, which is nice), but not for C. I haven't used
> neither of these, but would appreciate a review by someone who has
> used any of these in their apps.
>
> [1] http://oss.metaparadigm.com/json-c/
> (documentation is scarce)

Hi,

I haven't done a comparison either, but it looks like yajl was created 
partly out of frustration with json-c.[1]

As for applications, argyll[2] includes libyajl in its private 
libraries, and when lastfm-desktop[3] is released it will most likely 
have it among its build-depends.  gdal[4] embeds json-c.

[1] http://trickyco.de/2009/05/parse-json-in-ruby-in-14-the-time-of-yaml/
[2] http://packages.qa.debian.org/a/argyll.html
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537200
[4] http://packages.qa.debian.org/g/gdal.html


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

Re: RFS: magicfilter (updated package)

[Russ Allbery]

Rogério Brito  writes:
> On Aug 03 2009, Russ Allbery wrote:
>> Rogério Brito  writes:

>>> I have one off-topic comment: I've seen some well known maintainers
>>> do some things without the rigor that mentors apply to prospective
>>> maintainers.

>> Yes.  It's a little frustrating.

> Frustrating is indeed the right word.

> I see some weaknesses in the way that Debian is currently structured and
> I think that I will write a longer e-mail about that (things that are
> easily changed). Let's hope that I have the energy for that.

Code review is well-known to significantly improve quality.  People who
need sponsored uploads get code review by the sponsor, so those packages
end up being of higher quality.  Full Debian developers aren't required to
seek code review, so on average the packages are of lower quality.

Code review takes a lot of time, so requiring it for every package in
Debian probably isn't feasible.  But it's the code review of the
sponsoring process that results in most of the quality improvements.
Team-based packaging also gets at least some code review, particularly if
committed patches are sent to the team mailing list.

> Ooops. Fixed. The updated sources are again at the same address.

Uploaded.  Thank you!

-- 
Russ Allbery (r...@debian.org)   


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

Re: RFS: yajl

[Paul Wise]

On Tue, Aug 4, 2009 at 10:58 PM, John Stamp
 wrote:

> As for applications, argyll[2] includes libyajl in its private
> libraries,

I've added a note about this to the testing security team's
embedded-code-copies file, please file a bug on argyll once yajl
enters Debian and let the team know which bug number and if it gets
fixed.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Ceasing sponsoring and unsubscribing

[Ben Finney]

Neil Williams  writes:

> I'm still on VAC due to ill health. As part of the management of my
> condition, I must reduce my general Debian workload.
[…]
> Health is more important than Debian.

Absolutely right. Free software is not something for which we can ask
anyone to exacerbate an illness.

> I am unsure whether I will return to sponsoring once the current
> illness is under control. Pressure to return is likely to be
> counter-productive.

Thank you for informing us. Take whatever time you need to get well, and
make your decisions with a clear head.

-- 
 \   “We must respect the other fellow's religion, but only in the |
  `\   sense and to the extent that we respect his theory that his |
_o__) wife is beautiful and his children smart.” —Henry L. Mencken |
Ben Finney 


pgp0R1VX1PcZ7.pgp
Description: PGP signature

Re: RFS: yajl

[George Danchev]

Hi,

> On Tuesday 04 August 2009 12:07:11 pm George Danchev wrote:
> > I haven't review the package, but it would be very nice if anyone can
> > compare that to the json-c project [1], which looks quite serious to
> > me, at least as briefly scanning through the code. We have JSON
> > implementations in almost any language already available in Debian
> > (including a C++ one, which is nice), but not for C. I haven't used
> > neither of these, but would appreciate a review by someone who has
> > used any of these in their apps.
> >
> > [1] http://oss.metaparadigm.com/json-c/
> > (documentation is scarce)
>
> Hi,
>
> I haven't done a comparison either, but it looks like yajl was created
> partly out of frustration with json-c.[1]
>
> As for applications, argyll[2] includes libyajl in its private
> libraries, and when lastfm-desktop[3] is released it will most likely
> have it among its build-depends.  gdal[4] embeds json-c.
>
> [1] http://trickyco.de/2009/05/parse-json-in-ruby-in-14-the-time-of-yaml/
> [2] http://packages.qa.debian.org/a/argyll.html
> [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537200
> [4] http://packages.qa.debian.org/g/gdal.html

Aha, it is the stream parsing and data representation independence which makes 
the difference. It looks to me that as the time goes by the applications will 
slowly migrate to yajl if they want to benefit from the above two key features. 
Json-c would need a major restructure to provide these, which is highly 
unlikely.

The package looks solid, everything is put in place and I was unable to find 
any flaws other than boring nitpicking:

* the short description of the libyajl1-dbg should read `... - debugging 
symbols', instead of ` - library documentation'. Probably a copy/paste ;-)
* examples would help users to bootstrap more easily (optional)
* a watch file would help package monitoring
* send man pages upstream along with the patch of `PIC does not make sense for 
static libs' ;-)

* Why the integer test fails on 64-bit machines? Aligning issues?
* I imagine that at this stage the API is stable enough and drifts should be 
highly unlikely, is that assumption correct for yajl?

Let's give some days to the rest interested to look at that library package, 
to see if they can find any flaws. Then we can upload.

-- 
pub 4096R/0E4BD0AB 2003-03-18 


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