Re: KDE/Qt Package Manager (Re: Google Summer of Code 2009: Debian's Shortlist)

[Fathi Boudra]

> > I have no issue with Adept, and I would love to see a good Qt/KDE
> > package manager, but if we're to get KPackageKit, I'd like to be sure
> > that we won't sponsor yet another APT front-end that won't be used.

Still, it remains the aptitude-qt solution.
But it seems aptitude code is tighten with the gtk backend and extending it to 
add the qt backend cannot be done now.

Does it make sense to finish Adept3 when it can(should?) be superseeded later 
by aptitude ?

Why not finish aptitude-gtk separation then properly add qt pieces ?

please note that I never looked aptitude source code.

cheers,

Fathi


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

Re: KDE/Qt Package Manager (Re: Google Summer of Code 2009: Debian's Shortlist)

[Obey Arthur Liu]

Fathi Boudra a écrit :
>>> I have no issue with Adept, and I would love to see a good Qt/KDE
>>> package manager, but if we're to get KPackageKit, I'd like to be sure
>>> that we won't sponsor yet another APT front-end that won't be used.
> 
> Still, it remains the aptitude-qt solution.
> But it seems aptitude code is tighten with the gtk backend and extending it 
> to 
> add the qt backend cannot be done now.
> 
> Does it make sense to finish Adept3 when it can(should?) be superseeded later 
> by aptitude ?

aptitude-qt would not be possible before squeeze. That would leave us
with no usable Qt4 package manager.

> Why not finish aptitude-gtk separation then properly add qt pieces ?

Another strategy is to replace the adept/ept backend of adept 3.0 with
the aptitude backend once it is transformed into a library. It seems to
have become some sort of habit for aptitude to explore new features
before having them ported back to the common apt code.

Cheers

Arthur

-- 
Obey Arthur Liu




signature.asc
Description: OpenPGP digital signature

Bug#523736: ITP: god -- Monitors various attributes of running processes and can start/restart/stop them under certain situations

[Sebastien Delafond]

Package: wnpp
Severity: wishlist
Owner: Sebastien Delafond 


* Package name: god
  Version : 0.7.12
  Upstream Author : Tom Preston-Werner 
* URL : http://god.rubyforge.org
* License : MIT
  Programming Lang: Ruby
  Description : Monitors various attributes of running processes and can 
start/restart/stop them under certain situations

-- System Information:
Debian Release: 5.0
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'oldstable'), (500, 'stable'), 
(1, 'unstable')
Architecture: i386 (i686)



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

Re: [Soc-coordination] Google Summer of Code 2009: Debian's Shortlist

[Obey Arthur Liu]

Stefano Zacchiroli a écrit :
> On Fri, Apr 10, 2009 at 10:24:47AM +0200, Lucas Nussbaum wrote:
>> On 10/04/09 at 09:18 +0200, Obey Arthur Liu wrote:
>>> * Debian Autobuilding Infrastructure Rewrite *
>>> --
>>> Student: Philipp Kern, Mentor: Luk Claes
>> I'm a bit puzzled by this. Philipp has been involved in Debian and a DD
>> for years. He is already involved in buildd management.
>>
>> That proposal totally looks like he will get paid to work on things he
>> already does in Debian.
>>
>> I thought that there was no consensus that this is OK.
> 
> I thought the same, and the thread which developed from this objection
> is kind of a proof of the fact that there is no consensus, IMO.

Note that you could also use that argument for the other side.. :)

> The fact that in the past there were DDs acting a students is no
> excuse, even more so because several of such projects were
> unsuccessful in terms of what they brought to Debian. Unfortunately, I
> cannot find evidence of the discussion I happen to remember in the
> archives of this list.

We did take note of the phenomenon of DDs continuing their usual duties
and not using their time exclusively on their GSoC project, resulting in
failures. We believe it won't happen for the projects we retained.

2008 here: 
I'm pretty sure we have 2007 and 2006 but I don't feel like digging that up.

> I don't want to ruin the organization of Obey for this year, at this
> point. Nevertheless I think that assigning a project to a student-DD
> is an error and I also thought it was clear to everybody before this.
> So, better to set up a clear guideline *at least* for next year.

Everyone is perfectly fine with discussing this issue, as long as it
remains civil and it happens outside of the GSoC period when students
are scrutinizing us. Bringing dunc-tank et al. up is certainly not a
good way to to attract fresh blood to our project.

I hope we can have a fruitful discussion about this in, say,
november-december and come to a guideline everyone can agree with. In
the meantime, we're choosing option (3) in Lucas' mail: compromise.

Also, only 45 DD/DMs signed up to review, discuss and score proposals,
converging to our current shortlist. This number could be higher and I
hope more DDs will be interested in reviewing or mentoring in the future.

Cheers

Arthur

-- 
Obey Arthur Liu




signature.asc
Description: OpenPGP digital signature

Re: Google Summer of Code 2009: Debian's Shortlist

[Philipp Kern]

On 2009-04-11, Filipus Klutiero  wrote:
> Obey Arthur Liu wrote:
>> === And the details: ===
> [...]
> These descriptions are very short. Assuming these are the abstracts, 
> that's not the students' fault. The abstracts were shortened this year 
> to 500 characters. I struggled to shorten mine to fit this. At this 
> length, it's probably impossible to fit a decent summary of most 
> projects. It would normally make sense to use abstracts for this use 
> case. Maybe Google should be asked to change the limit. Otherwise I'd 
> like to see a custom description which describes a little further. I 
> currently can't comment on all projects presented.
> That said, this shortlist remains useful, and I thank you for this great 
> jump in transparency.

Mind to tell us what your proposed project was?  For more transparency?

Kind regards,
Philipp Kern


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

Bug#523755: ITP: libtest-email-perl -- Test Email Contents

[Yves AGOSTINI]

Package: wnpp
Severity: wishlist
Owner: AGOSTINI Yves 


* Package name: libtest-email-perl
  Version : 0.07
  Upstream Author : James Tolley, 
* URL : http://search.cpan.org/dist/Test-Email/
* License : Perl
  Programming Lang: Perl
  Description : Test Email Contents 
 Test::Email is a subclass of MIME::Entity with header_is, body_is, or _ok or
 _like and part_ok, mime_type_ok methods.

 Tests for equality remove trailing newlines from strings before testing. Some
 mail messages have newlines appended to them during the mailing  process, 
 which could cause unnecessary confusion.



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

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

[Michael Meskes]

On Mon, Apr 06, 2009 at 09:55:39PM +0200, Michael Biebl wrote:
> As (co-)maintainer of pm-utils and hal, I'd prefer if we could work towards
> standardizing on one power management stack in Debian (and not install 3 by
> default [1]), i.e. I'd support in phasing out acpi-support and would gladly
> accept patches for hal and pm-utils which add (if there are) any missing bits
> from acpi-support.

Not sure whether most users agree after reading #515214.

Michael

-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: mes...@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!


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

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

[Julien Cristau]

On Sun, 2009-04-12 at 14:04 +0200, Michael Meskes wrote:
> On Mon, Apr 06, 2009 at 09:55:39PM +0200, Michael Biebl wrote:
> > As (co-)maintainer of pm-utils and hal, I'd prefer if we could work towards
> > standardizing on one power management stack in Debian (and not install 3 by
> > default [1]), i.e. I'd support in phasing out acpi-support and would gladly
> > accept patches for hal and pm-utils which add (if there are) any missing 
> > bits
> > from acpi-support.
> 
> Not sure whether most users agree after reading #515214.

515214 isn't most users.  most users just want things to work.

Cheers,
Julien


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

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

[Michael Meskes]

On Sun, Apr 12, 2009 at 01:11:26PM +0100, Julien Cristau wrote:
> 515214 isn't most users.  most users just want things to work.

But then 515214 appears to be at least a significant amount of users. Anyway,
having things "just work" and being able to run a system without hal do not
contradict each other.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: mes...@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!


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

Needs help testing apt-xapian-index

[Enrico Zini]

Hello,

I've prepared a fix for a bug that I cannot reproduce, so I'd like
others to test it before I upload:

Preconditions:
 1. On sid or experimental
 2. apt-get install apt-xapian-index OR run update-apt-xapian-index as
root
 3. See if you get the problem at #521346

To test:
 1. git clone git://git.debian.org/collab-maint/apt-xapian-index.git
 2. cd apt-xapian-index
 3. ./testrun

If the packaged version didn't work, let me know of the results.  More
details at http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=25;att=0;bug=521346


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini 


signature.asc
Description: Digital signature

Re: UDD gatherer for DDTP translations (Was: Extended descriptions size)

[Martijn van Oosterhout]

On Tue, Apr 7, 2009 at 9:49 AM, Andreas Tille  wrote:
> Well, I did not said that it is actually hard and in UDD you can get this
> easily by
>
>   SELECT md5(description || E'\n' || long_description || E'\n' ) AS md5
>          FROM packages WHERE ...

Ok, I see why you're having trouble now; you're splitting up the
description in your DB and thus need to stick it back together. That
does indeed make the process a bit less reliable. The DDTP/DDTSS
treats the description as a single string, the exact string in the
Packages file (the Description field is a single entry in the file) so
we had no issues. By doing extra processing like splitting/stripping
parts of the string it's quite possible you're doing a not invertible
conversion, which would make matching later harder.

It'd be nice if someone went over the version number stuff in
DDTP/DDTSS since by and large it was never used (user display only and
even then it wasn't accurate) and so probably there's plenty of work
there.

It might actually be easier to write a script which simply collected
Packages files from say snapshot.debian.org, calculated all the MD5
sums (you can extract the description field using a regex so it's easy
enough in Perl) and built a database of description MD5s and version
numbers. That would give a reliable mapping, far more reliable than
the DDTP/DDTSS is ever likely to do.

Keep in mind that all dpkg frontends with description only work on the
basis of the complete description string, I'm not sure if anyone is
likely to switch to using versions.

Have a nice day,
-- 
Martijn van Oosterhout  http://svana.org/kleptog/


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

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

[Julien Cristau]

On Sun, 2009-04-12 at 15:01 +0200, Michael Meskes wrote:
> On Sun, Apr 12, 2009 at 01:11:26PM +0100, Julien Cristau wrote:
> > 515214 isn't most users.  most users just want things to work.
> 
> But then 515214 appears to be at least a significant amount of users. Anyway,

no, it doesn't.

> having things "just work" and being able to run a system without hal do not
> contradict each other.

in this case, yes they do.

Cheers,
Julien


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

Re: Needs help testing apt-xapian-index

[David Paleino]

On Sun, 12 Apr 2009 14:13:22 +0100, Enrico Zini wrote:

> Hello,

Ciao Enrico,

> I've prepared a fix for a bug that I cannot reproduce, so I'd like
> others to test it before I upload:
> 
> Preconditions:
>  1. On sid or experimental

Running sid/experimental on i386 here.

>  2. apt-get install apt-xapian-index OR run update-apt-xapian-index as
> root
>  3. See if you get the problem at #521346

Yes, I am able to reproduce it on my system.

In a sid chroot (cowbuilder), the 0.18 package even fails with a different
error:

---8<---
# update-apt-xapian-index 
Reading current timestamp failed: [Errno 2] No such file or directory: 
'/var/lib/apt-xapian-index/update-timestamp'. Assuming the index has not been 
created yet.
Rebuilding Xapian index... 
0%/usr/share/apt-xapian-index/plugins/apttags.py:104: DeprecationWarning: 
Accessed deprecated property Package.candidateRecord, please see the Version 
class for alternatives.
  rec = pkg.candidateRecord

Traceback (most recent call last):
  File "/usr/sbin/update-apt-xapian-index", line 596, in 
buildIndex(dbdir, addons, progress)
  File "/usr/sbin/update-apt-xapian-index", line 298, in buildIndex
addon.obj.index(document, pkg)
  File "/usr/share/apt-xapian-index/plugins/apttags.py", line 104, in index
rec = pkg.candidateRecord
  File "/usr/lib/python2.5/site-packages/apt/package.py", line 106, in __get__
return property.__get__(self, obj, type)
  File "/usr/lib/python2.5/site-packages/apt/package.py", line 613, in 
candidateRecord
return self.candidate.recor
AttributeError: 'Version' object has no attribute 'recor'
--->8---

Maybe a typo there? Fixing it to "record" seems to help:

---8<---
# update-apt-xapian-index 
Reading current timestamp failed: [Errno 2] No such file or directory: 
'/var/lib/apt-xapian-index/update-timestamp'. Assuming the index has not been 
created yet.
Rebuilding Xapian index... 
0%/usr/share/apt-xapian-index/plugins/apttags.py:104: DeprecationWarning: 
Accessed deprecated property Package.candidateRecord, please see the Version 
class for alternatives.
  rec = pkg.candidateRecord
/usr/share/apt-xapian-index/plugins/descriptions.py:75: DeprecationWarning: 
Accessed deprecated property Package.rawDescription, please see the Version 
class for alternatives.
  self.indexer.index_text_without_positions(pkg.rawDescription)
/usr/share/apt-xapian-index/plugins/sizes.py:74: DeprecationWarning: Accessed 
deprecated property Package.installedSize, please see the Version class for 
alternatives.
  instSize = pkg.installedSize
/usr/share/apt-xapian-index/plugins/sizes.py:75: DeprecationWarning: Accessed 
deprecated property Package.packageSize, please see the Version class for 
alternatives.
  pkgSize = pkg.packageSize
Rebuilding Xapian index: done.
--->8---

> To test:
>  1. git clone git://git.debian.org/collab-maint/apt-xapian-index.git
>  2. cd apt-xapian-index
>  3. ./testrun
> 
> If the packaged version didn't work, let me know of the results.  More
> details at
> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=25;att=0;bug=521346

The cloned repository failed the same way the packaged version did (on my host 
system):

---8<---
Rebuilding Xapian index... 15% 
Traceback (most recent call last):
  File "./update-apt-xapian-index", line 596, in 
buildIndex(dbdir, addons, progress)
  File "./update-apt-xapian-index", line 298, in buildIndex
addon.obj.index(document, pkg)
  File "plugins/descriptions.py", line 77, in index
self.indexer.index_text_without_positions(version.raw_description)
  File "/usr/lib/python2.5/site-packages/apt/package.py", line 257, in 
raw_description
return self._records.LongDesc
  File "/usr/lib/python2.5/site-packages/apt/package.py", line 214, in _records
if self.package._pcache._records.Lookup(self._cand.FileList[0]):
AttributeError: 'NoneType' object has no attribute 'FileList'
--->8---

In a clean sid chroot however, it seems to work fine:

---8<---
pingu:/apt-xapian-index# ./testrun 
Reading current timestamp failed: [Errno 2] No such file or directory: 
'testdb/update-timestamp'. Assuming the index has not been created yet.
Rebuilding Xapian index: done.  
pingu:/apt-xapian-index#
--->8---


Ciao,
David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

[Raphael Hertzog]

On Sun, 12 Apr 2009, Michael Meskes wrote:
> But then 515214 appears to be at least a significant amount of users. Anyway,
> having things "just work" and being able to run a system without hal do not
> contradict each other.

Expect grumpy people every time that you add something new that they have
to learn. I also had troubles with hal and X when I tried the X servers in
experimental. But I have not read any serious criticism based on technical
facts in the bug report you showed.

That said, it looks like that having things just work on the desktop
require hal anyway and I fail to see why we would have to reinvent other
solutions (like continuing to maintain/create many hacks in acpi-support)
when we could centralize the knowledge in one place.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


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

Bug#523794: ITP: php-version-control-svn -- wrapper interface for the Subversion command-line client

[Artur R. Czechowski]

Package: wnpp
Severity: wishlist
Owner: "Artur R. Czechowski" 

* Package name: php-version-control-svn
  Version : 0.3.1
  Upstream Author : Clay Loveless 
http://pear.php.net/account-mail.php?handle=clay
* URL : http://pear.php.net/package/VersionControl_SVN
* License : BSD
  Programming Lang: PHP
  Description : wrapper interface for the Subversion command-line client

(following description has been copied from upstream page)

Simple OO-style interface for Subversion, the free/open-source version control
system.

It can be used to manage trees of source code, text files, image files -- just
about any collection of files.

Some of VersionControl_SVN's features:
* Full support of svn command-line client's subcommands.
* Use of flexible error reporting provided by PEAR_ErrorStack.
* Multi-object factory.
* Source fully documented with PHPDoc.
* Stable, extensible interface.
* Collection of helpful quickstart examples and tutorials.

What can be done with VersionControl_SVN?
* Make your source code available to your remote dev team or project manager.
* Build your own WYSIWYG web interface to a Subversion repository.
* Add true version control to a content management system!

-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)



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

Bug#523797: ITP: svnmanager -- webbased tool to administer a Unix Apache WebDAV Subversion repository server.

[Artur R. Czechowski]

Package: wnpp
Severity: wishlist
Owner: "Artur R. Czechowski" 

* Package name: svnmanager
  Version : 1.05
  Upstream Author : M. Verkerk 
* URL : http://svnmanager.sourceforge.net/
* License : BSD
  Programming Lang: PHP
  Description : webbased tool to administer Subversion repository server

SVNManager is a webbased tool to administer a Unix Apache WebDAV Subversion
repository server. With this tool you can remotely:
* Create, remove, load and dump repositories
* Manage user accounts for access to the repositories
* Manage groups for acces to the repositories
* Invite users by email to create an account on the server 

-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)



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

New version of kernel-package now in unstable

[Manoj Srivastava]

Hi,

This brings to an end an enhancement for kernel-package that
 have been in development for over an year. These changes make
 kernel-package more nimble (you can just update the sources, hack on a
 file, and run make-kpkg and it should just work to incorporate your
 changes, no need for clean).

It also pulls out the postint functionality into hook scripts,
 using the same /etc/kernel.d infrastructure as upstreams native deb-pkg
 target, but provides for more packages.

Also supported now is a linux-image-$version-dbg package, that
 contains just the debugging information, and which is compatible with
 SystemTap.

Looking at the reverse dependencies, there should be no impact
 whatsoever on the module packages; everything should still work the
 same.

However, since ./debian is now ephemeral, anyone who puts things
 in ./debian will be affected. Those users should depend on
 kernel-package (<< 12.001).  The only user I know of that did that
 was linux-2.6, but since kernel-package has been deprecated and
 pronounced broken by the kernel team, this is not an issue: if it is
 deprecated, and obsolescent, development if kernel-package need not be
 tied to linux-2.6. In any case, official kernels are no longer
 supported as of k-p 12.001.

manoj
-- 
"Bug #523423: Plesase Remove bitchx from the archive. Full of crap." -
Debian BTS
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

[Marc Haber]

On Sun, 12 Apr 2009 13:11:26 +0100, Julien Cristau
 wrote:
>515214 isn't most users.  most users just want things to work.

While were at it, I find it unacceptable to set a bug wontfix without
explanation.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


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

Re: Google Summer of Code 2009: Debian's Shortlist

[Guillem Jover]

Hi!

On Fri, 2009-04-10 at 09:18:32 +0200, Obey Arthur Liu wrote:
> === And the details: ===
> 
> 
> * Control Files Parsing/Editing Library/Qt4-Debconf Qt4-Perl bindings *
> ---
> Student: Jonathan Yu, Mentor: (probably) Dominique Dumont *see below*
> 
> This project proposes a common library for parsing and manipulating
> Debian Control files, including control, copyright and changelog. Main
> ideas include validating and parsing of these files, with both Strict
> and Quirks modes for the parser. The second idea is a new frontend for
> Debconf using Qt4 (for which Perl bindings will be written).

I've some comments after checking the more detailed project proposal at:


There's already several libraries to parse debian control and
changelog files, but I don't think there's anything for copyright as the
format is not yet standardized.

dpkg has a C library (albeit not yet public) for parsing and dumping
control-style files, and dpkg-dev has also perl modules supporting
control and changelog files. I'm also aware of apt's implementation in C++,
and there's others in python, ruby, etc.

There's also mention of rewritting debconf in C/C++, but that has also
already been done in the form of cdebconf.

regards,
guillem


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

Re: [Soc-coordination] Google Summer of Code 2009: Debian's Shortlist

[Colin Watson]

On Sun, Apr 12, 2009 at 07:28:14PM +0200, Guillem Jover wrote:
> On Fri, 2009-04-10 at 09:18:32 +0200, Obey Arthur Liu wrote:
> > === And the details: ===
> > 
> > 
> > * Control Files Parsing/Editing Library/Qt4-Debconf Qt4-Perl bindings *
> > ---
> > Student: Jonathan Yu, Mentor: (probably) Dominique Dumont *see below*
> > 
> > This project proposes a common library for parsing and manipulating
> > Debian Control files, including control, copyright and changelog. Main
> > ideas include validating and parsing of these files, with both Strict
> > and Quirks modes for the parser. The second idea is a new frontend for
> > Debconf using Qt4 (for which Perl bindings will be written).
> 
> I've some comments after checking the more detailed project proposal at:
> 
> 
> There's already several libraries to parse debian control and
> changelog files, but I don't think there's anything for copyright as the
> format is not yet standardized.
> 
> dpkg has a C library (albeit not yet public) for parsing and dumping
> control-style files, and dpkg-dev has also perl modules supporting
> control and changelog files.

As a general system-design style point, dpkg is the logical place for
this and there are a number of reasons not to create yet another library
elsewhere, particularly if it's going to be done in C. Getting dpkg's
library for control parsing up to the point where it has a stable,
advertised API would be very good for Debian, IMO.

> There's also mention of rewritting debconf in C/C++, but that has also
> already been done in the form of cdebconf.

We will probably be moving to cdebconf eventually, but not within the
lifetime of this GSoC project as there are still a number of things left
to be added before it can be a full replacement. A second C rewrite
would very likely do more harm than good (due to fracturing development
effort). It wouldn't hurt to add a Qt4 frontend to cdebconf, and there
would be some future value in that; but the only immediate use for that
would be to produce a Qt-based graphical installer, which I doubt the
installer team has time to maintain as we already have enough to do with
one graphical frontend.

Right now, fixing the Perl Qt4 bindings and updating the existing
debconf "KDE" frontend (it really just uses Qt, but such is its
historical name) seems to be the preferable approach by a long way.

-- 
Colin Watson   [cjwat...@debian.org]


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

Bug#523821: ITP: stardict-woaifayu-english-french -- This English-French dictionary is one of the most complete for the stardict

[Patrice Karatchentzeff]

Package: wnpp
Severity: wishlist
Owner: Patrice Karatchentzeff 



* Package name: stardict-woaifayu-english-french
  Version : 2.4.2
  Upstream Author : Luc 
* URL : 
http://prdownloads.sourceforge.net/stardict/stardict-woaifayu-ef-2.4.2.tar
.bz2?download
* License : GPL
  Programming Lang: data
  Description : Very complete English-French dictionary
This English-French dictionary is one of the most complete for the stardict


-- System Information:
Debian Release: 5.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)



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

dash as default /bin/sh and bashisms-free archive RGs

[Raphael Geissert]

Hello everyone,

I would like to propose the following Release Goals for squeeze:

* Dash as default /bin/sh
A lot of work was done on this RG already for lenny but, sadly, it didn't make 
it. Further improvements to checkbashisms as well as support for checking for 
bashisms in all /bin/sh and debian/rules in lintian should follow.
The previous advocate was Petter Reinholdtsen, this time I'm offering myself 
to drive this RG and make it real.

* Bashisms-free archive
Similar to the above and thus included in this same email, the propposed goal 
is free all /bin/sh from bashisms (bashism in this context: a shell feature 
that is not required to be supported by Debian Policy), not just the issues 
needed to support dash as /bin/sh. The pourpose of this goal is to let people 
use whatever shell interpreter that complies with policy as /bin/sh without 
any breakage other than those that result from bugs in the interpreter 
itself.

[-release BCCed as  requested]

Cheers,
-- 
Raphael Geissert - Debian Maintainer
www.debian.org - get.debian.net


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

Re: dash as default /bin/sh and bashisms-free archive RGs

[Marco d'Itri]

On Apr 12, Raphael Geissert  wrote:

> * Dash as default /bin/sh
This is good.

> * Bashisms-free archive
This is useless. You are basically proposing to remove every usage of
"local" and a few other directives for no good reason but at a huge cost.

> needed to support dash as /bin/sh. The pourpose of this goal is to let people 
> use whatever shell interpreter that complies with policy as /bin/sh without 
> any breakage other than those that result from bugs in the interpreter 
> itself.
And what is the purpose of this, exactly? The only shell which does not
support these directives is posh, which was created specifically with
the purpose of not supporting them and has no real world usage.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: dash as default /bin/sh and bashisms-free archive RGs

[Russ Allbery]

m...@linux.it (Marco d'Itri) writes:
> On Apr 12, Raphael Geissert  wrote:

>> * Bashisms-free archive

> This is useless. You are basically proposing to remove every usage of
> "local" and a few other directives for no good reason but at a huge
> cost.

No, he's not -- look at the current Policy.

If there are more exceptions that we should add, do say which ones.

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


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

Re: dash as default /bin/sh and bashisms-free archive RGs

[Roberto C . Sánchez]

On Sun, Apr 12, 2009 at 09:35:37PM +0200, Marco d'Itri wrote:
> 
> > * Bashisms-free archive
> This is useless. You are basically proposing to remove every usage of
> "local" and a few other directives for no good reason but at a huge cost.
> 

Policy specifically states that use of "local" is permitted [0]:

* local to create a scoped variable must be supported, including
  listing multiple variables in a single local command and assigning
  a value to a variable at the same time as localizing it. local may
  or may not preserve the variable value from an outer scope if no
  assignment is present. Uses such as:

   fname () {
   local a b c=delta d
   # ... use a, b, c, d ...
   }

  must be supported and must set the value of c to delta.


Regards,

-Roberto

[0] http://www.debian.org/doc/debian-policy/ch-files.html#s-scripts

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: dash as default /bin/sh and bashisms-free archive RGs

[Marco d'Itri]

On Apr 12, "Roberto C. Sánchez"  wrote:

> Policy specifically states that use of "local" is permitted [0]:
So exactly what do you want to disallow which is supported by dash but
not by policy, and for which purpose?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: dash as default /bin/sh and bashisms-free archive RGs

[Raphael Geissert]

Marco d'Itri wrote:
> On Apr 12, "Roberto C. Sánchez"  wrote:
> 
>> Policy specifically states that use of "local" is permitted [0]:
> So exactly what do you want to disallow which is supported by dash but
> not by policy, and for which purpose?
> 

I don't have a list at hand (I do have a sort of list in another machine
which is unreachable atm); but the first one that comes to my mind is the
use of 'type', it's output is unreliable and in some shell interpreters it
is not implemented. Another one is 'ulimit'.

Cheers,
Raphael Geissert



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

Bug#523839: ITP: libany-moose-perl -- use Moose or Mouse modules

[Ryan Niebur]

Package: wnpp
Owner: Ryan Niebur 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: libany-moose-perl
  Version : 0.07
  Upstream Author : Shawn M Moore , Florian Ragwitz 
, Stevan Little , Tokuhiro Matsuno 

* URL : http://search.cpan.org/dist/Any-Moose/
* License : Artistic | GPL-1+
  Programming Lang: Perl
  Description : use Moose or Mouse modules
 Any::Moose allows a perl package that doesn't care whether it's using
 Moose or Mouse to use either Mouse or Moose.


-- 
_
Ryan Niebur
ryanrya...@gmail.com


signature.asc
Description: Digital signature

Bug#523840: ITP: libdata-alias-perl -- Comprehensive set of aliasing operations

[Ryan Niebur]

Package: wnpp
Owner: Ryan Niebur 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: libdata-alias-perl
  Version : 1.07
  Upstream Author : Idea by Tony Bowden and Paul Johnson, code by Michael G 
Schwern
, wardrobe by Calvin Klein.
* URL : http://search.cpan.org/dist/Data-Alias/
* License : Artistic | GPL-1+
  Programming Lang: Perl
  Description : Comprehensive set of aliasing operations
 Aliasing is the phenomenon where two different expressions actually
 refer to the same thing. Modifying one will modify the other, and if
 you take a reference to both, the two values are the same.
 .
 Data::Alias is a module that allows you to apply "aliasing semantics"
 to a section of code, causing aliases to be made whereever Perl would
 normally make copies instead. You can use this to improve efficiency
 and readability, when compared to using references.


-- 
_
Ryan Niebur
ryanrya...@gmail.com


signature.asc
Description: Digital signature

Re: Bug#523794: ITP: php-version-control-svn -- wrapper interface for the Subversion command-line client

[Bernd Zeimetz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Artur R. Czechowski wrote:

>   Programming Lang: PHP
>   Description : wrapper interface for the Subversion command-line client

A php wrapper around the svn command-line client sounds like an completely
braindead idea. Not only that php is utter crap, but relying on exit codes and
output of svn is the worst idea ever. It also sounds like a security nightmare -
allowing php to use exec() and system() is a pretty bad idea, and trying to
parse the output of programs is error-prone, too.

libsvn-dev is the only sane way to create a binding to svn for another language.
Please use that instead of the command line client.


- --
 Bernd Zeimetz   Debian GNU/Linux Developer
 GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkniZQwACgkQBnqtBMk7/3ny2gCfSNgVV9naN1mXo2Zs7dvDZyl2
/58An0XPQ6XDIJUSfSfxZhLILEZaXKXy
=EboJ
-END PGP SIGNATURE-


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

Re: UDD gatherer for DDTP translations (Was: Extended descriptions size)

[Andreas Tille]

On Sun, 12 Apr 2009, Martijn van Oosterhout wrote:


  SELECT md5(description || E'\n' || long_description || E'\n' ) AS md5
         FROM packages WHERE ...


Ok, I see why you're having trouble now; you're splitting up the
description in your DB and thus need to stick it back together.


That's the format other tables in UDD are using.  But it does not
really make the worst part of the problem - as you see It can
perfectly be joined again.  It is just the md5 sum calsulation which
slows down things and the calculation of the version number is
not reliable in all cases - which I regard as a problem.


That does indeed make the process a bit less reliable.


I don't think that it is the split which causes the problem.  I was
able to reproduce the correct description the way I described above.


The DDTP/DDTSS
treats the description as a single string, the exact string in the
Packages file (the Description field is a single entry in the file) so
we had no issues. By doing extra processing like splitting/stripping
parts of the string it's quite possible you're doing a not invertible
conversion, which would make matching later harder.


In how far?  This is done in UDD with all descriptions and never
caused a problem.


It might actually be easier to write a script which simply collected
Packages files from say snapshot.debian.org, calculated all the MD5
sums (you can extract the description field using a regex so it's easy
enough in Perl) and built a database of description MD5s and version
numbers. That would give a reliable mapping, far more reliable than
the DDTP/DDTSS is ever likely to do.


Can you elaborate a bit more why you regard it as not reliable to
add a version number to DDTP Translation files?

Kind regards

  ANdreas.

--
http://fam-tille.de

Re: Bug#523794: ITP: php-version-control-svn -- wrapper interface for the Subversion command-line client

[Philipp Kern]

On 2009-04-12, Bernd Zeimetz  wrote:
> Artur R. Czechowski wrote:
>>   Programming Lang: PHP
>>   Description : wrapper interface for the Subversion command-line client
> A php wrapper around the svn command-line client sounds like an completely
> braindead idea. Not only that php is utter crap, but relying on exit codes and
> output of svn is the worst idea ever. It also sounds like a security 
> nightmare -
> allowing php to use exec() and system() is a pretty bad idea, and trying to
> parse the output of programs is error-prone, too.

I also found svn to be not Ctrl-C-able at time.  I don't know if that applies
to other signals too but if so I can imagine quite some hanging processes
on a server.

Kind regards,
Philipp Kern


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

Re: dash as default /bin/sh and bashisms-free archive RGs

[Marco d'Itri]

On Apr 12, Raphael Geissert  wrote:

> I don't have a list at hand (I do have a sort of list in another machine
> which is unreachable atm); but the first one that comes to my mind is the
> use of 'type', it's output is unreliable and in some shell interpreters it
> is not implemented. Another one is 'ulimit'.
If you want to propose something like this then you are really supposed
to provide details of what exactly you want to change and estimates of
how many packages will have to be modified.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: dash as default /bin/sh and bashisms-free archive RGs

[Raphael Geissert]

Marco d'Itri wrote:

> On Apr 12, Raphael Geissert  wrote:
> 
>> I don't have a list at hand (I do have a sort of list in another machine
>> which is unreachable atm); but the first one that comes to my mind is the
>> use of 'type', it's output is unreliable and in some shell interpreters
>> it is not implemented. Another one is 'ulimit'.
> If you want to propose something like this then you are really supposed
> to provide details of what exactly you want to change and estimates of
> how many packages will have to be modified.
> 

Like I said, I have a list on another machine which, after some
investigation, appears to have a hw failure.
I can provide some figures based on the last archive-wide checkbashisms run
that included all those issues that were not relevant for the dash RG.
Saying that there are around 100 packages, or even less, that would be
affected by this RG is, IMO, close to reality.

Cheers,
Raphael Geissert
 



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