Re: lilo about to be dropped?

[Frans Pop]

On Monday 06 April 2009, Christian Perrier wrote:
> Quoting William Pitcock (neno...@dereferenced.org):
> > lilo is due for removal anyway due to being unmaintained upstream and
> > the widespread availability of alternatives.

I think that last part is debatable.

> > I do not have time to manage the removal at this point, but it will
> > be gone by June.

Has the package already been offered for adoption? Preferably with an 
overview of its current (upstream) status and main issues. I'd say that 
if there's anybody willing to (actively) maintain it, it should not be 
removed.

> This is a heads up mail for the D-I team.

I'm not sure where the original mail comes from, but IMO this should be 
discussed on d-devel, especially since it impacts more than just D-I. I 
suspect there are quite a few packages that make some sort of provisions 
for lilo.
There are also significant numbers of people still using lilo for, at 
least for them, very good reasons.

Anyone remember the fairly big upset when lilo was removed from testing 
around D-I Lenny Beta2?

> Don't we have some install paths that still depend on LILO?

Yes: /boot on LVM is the main one.

> Anyway, even if we don't, I think we should track that lilo removal
> and coordinate with William, in order to stop providing
> lilo-installer.
>
> And, I think this should be mentioned as a release goal (dropping
> lilo). Either high priority if we have install paths depending on
> lilo, or normal priority otherwise.

D-I release goal or Debian release goal [1]?
IMO the latter could well be justified as there will also need to be some 
kind of upgrade strategy for existing users that does not make 
uncontrolled changes on their hard disk or loses them the ability to boot 
alternative OSes on dual (or multi) boot systems.

Cheers,
FJP

[1] "goal" is a somewhat strange term here...


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

Re: "Team uploads"

[Lionel Elie Mamane]

On Mon, Apr 06, 2009 at 11:52:54AM +0800, Paul Wise wrote:

> In Debian we have several teams working on maintaining large numbers
> of packages (pkg-games, pkg-perl, pkg-gnome for example). I
> proposed[1] to silence the lintian NMU warnings in the case of "team
> uploads"; where the person doing the upload is a member of the team
> in Maintainers but is not present in Uploaders. Does anyone think
> this concept of "team uploads" has merit?

It is a useful concept, but I would like to consider them as "special
case NMUs" rather than "special case MUs".

 - NMU version number
 - first changelog line contains "TU" / "team upload" / "team NMU" /
   ...
 - no need to put patch in bug
 - no need for NMU delay
 - no need to upload to delayed queue

My reasoning is that a package that has had only "team uploads" for
three years is a package where effectively no human is taking charge
for maintaining it, just as a package that has had only NMU uploads in
three years; I'd like QA / potential adopters to see that in the
sequence of version numbers as they do now.

-- 
Lionel


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

Re: Re: DEP-4: The TDeb specification.

[Filipus Klutiero]

Neil Williams wrote:

On Fri, 03 Apr 2009 16:45:46 -0400
Filipus Klutiero  wrote:

[...] 

> > > That would be a nice improvement, but let me suggest another 
> > > implementation. To avoid introducing a second diff, why not updating the 
> > > regular diff (in the case of non-native packages) but indicating that 
> > > the package shouldn't be entirely rebuilt when uploading? This seems 
> > > simpler.

> >
> > That breaks the existing source package in Debian - the .dsc referring
> > to that .diff.gz has been signed by the maintainer and any changes will
> > break that signature.

> Right - unless the .dsc is also updated. And if there is to be a tdiff, 
> I don't see why .dsc-s wouldn't include the tdiff's digest.


There will be a complementary dsc using the +t1 version suffix.

That can work, though I don't see what you were trying to say.

[...]

> > > > > What is the purpose of creating a new binary package format for this (as 
> > > > > opposed to reusing, say, the deb format)?

> > > >
> > > > To support easier management of the translations, including allowing
> > > > users to only install the translations that are needed for one
> > > > particular installation, instead of every user getting every
> > > > translation for every package they install, whether those translations
> > > > are even supported or not.
> >
> > > There are two ways to achieve this. One is per-language packages, the 
> > > other is localization packages with multiple languages but using 
> > > something like dpkg class support. Currently, the only way supported is 
> > > language packages, but introducing a new package format will not 
> > > necessarily allow the second way. Implementing this would take about the 
> > > same amout of work as implementing something like dpkg class support for 
> > > the deb file format.

> >
> > ? It's already implemented via a patch devised by Thomas Viehmann.
> >   
> Great. Then it should be little work to implement the same for .deb.


Package management tools need a way to tell a .deb from a .tdeb - the
two need to be handled differently by tools like dak, britney, apt,
dpkg, reprepro, deb-gview and others.
Do you mean that package management tools need a way to tell a 
traditional/current .deb from a package containing what the DEP proposes 
to put in a .tdeb? If you're only talking about the tdeb format per se, 
I don't understand your reasoning.



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

Bug#522721: ITP: shutter -- feature-rich screenshot program

[Ryan Niebur]

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

* Package name: shutter
  Version : 0.70
  Upstream Author : Mario Kemper  and Shutter Team
* URL : http://shutter-project.org/
* License : GPL-3+
  Programming Lang: Perl
  Description : feature-rich screenshot program
 Shutter is a feature-rich screenshot program. You can take a
 screenshot of a specific area, window, your whole screen, or even of
 a website - apply different effects to it, draw on it to highlight
 points, and then upload to an image hosting site, all within one
 window.
 .
 Features:
* take a screenshot of your complete desktop, a rectangular area
  or capture a website
* take screenshot directly or with a specified delay time
* save the screenshots to a specified directory and name them in a
  convenient way (using special wild-cards)
* Shutter is fully integrated into the Gnome Desktop (TrayIcon etc.)
* generate thumbnails directly when you are taking a screenshot
  and set a size level in %
* Shutter session collection
  o keep track of all screenshots during session
  o copy screeners to clipboard
  o print screenshots
  o delete screenshots
  o rename your file
* upload your files directly to Image-Hosters
  (e.g. http://ubuntu-pics.de), retrieve all the needed links and
  share them with others
* edit your screenshots directly using the embedded drawing tool


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


signature.asc
Description: Digital signature

Bug#522719: ITP: libgoo-canvas-perl -- Perl interface to the GooCanvas

[Ryan Niebur]

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

* Package name: libgoo-canvas-perl
  Version : 0.05
  Upstream Author : Ye Wenbin 
* URL : http://search.cpan.org/dist/Goo-Canvas/
* License : Artistic | GPL-1+
  Programming Lang: Perl
  Description : Perl interface to the GooCanvas
 GTK+ doesn't have a builtin canvas widget. Goo::Canvas fills that
 gap. It is easy to use and has powerful and extensible ways to create
 items in canvases.


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


signature.asc
Description: Digital signature

Bug#522720: ITP: libproc-simple-perl -- Perl interface to launch and control background processes

[Ryan Niebur]

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

* Package name: libproc-simple-perl
  Version : 1.24
  Upstream Author : Michael Schilli 
* URL : http://search.cpan.org/dist/Proc-Simple/
* License : Artistic | GPL-1+
  Programming Lang: Perl
  Description : Perl interface to launch and control background processes
 The Proc::Simple package provides objects mimicing real-life processes from a
 user's point of view.
 .
 Either external programs or perl subroutines can be launched and
 controlled as processes in the background.


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


signature.asc
Description: Digital signature

"Team uploads"

[Paul Wise]

Hi all,

In Debian we have several teams working on maintaining large numbers
of packages (pkg-games, pkg-perl, pkg-gnome for example). I
proposed[1] to silence the lintian NMU warnings in the case of "team
uploads"; where the person doing the upload is a member of the team in
Maintainers but is not present in Uploaders. Does anyone think this
concept of "team uploads" has merit?

1. http://lists.debian.org/debian-lint-maint/2009/04/threads.html#00043

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

[Steve Langasek]

On Sun, Apr 05, 2009 at 11:06:15PM +0200, Bart Samwel wrote:
> 1. The upstream for this package is Ubuntu. Ubuntu has never been very
> cooperative at accepting changes, until recently: our contact Steve
> Langasek has indicated that he is interested in merging most or all of
> our changes, provided that we send them in in chunks, with proper
> rationales.

I have to say here in defense of Ubuntu that I don't see any record of these
patches being submitted to the Ubuntu package via Launchpad, which, since
Ubuntu does not have individual package maintainers, is the only reliable
way to ensure that proposed changes are seen and considered by the people
working on the package at any given time.

I don't have time to work on the Debian package myself (either as maintainer
or for sifting through the delta between Debian and Ubuntu), but I
definitely am happy to accept fixes "upstream" in reasonable-sized chunks.

Anyway, as Bart points out, there's another issue:

> 4. Ubuntu is PHASING OUT this package. They have already moved suspend
> to pm-utils (but have failed to remove suspend support from
> acpi-support). They're currently moving hotkey translation to hal. This
> means that soon we will have no upstream that we can follow! Or we
> should ensure that Ubuntu's hal changes are included in our version of
> hal as well -- no clue how those packages are related, or whether
> Ubuntu's changes are going into upstream hal.

Since the last time I had a chance to speak with Bart about this, there's
been quite a bit of progress on phasing out the package for Ubuntu; in
jaunty, we've dropped a number of quirk scripts related to suspend/resume,
as well as close to 30 of the ACPI event-handling scripts from /etc/acpi -
basically:  all those scripts that were being used to synthesize key
events (which doesn't work with recent kernels anyway) and which we could
verify were being handled by hal.

And yes, Martin Pitt works very closely with hal upstream to ensure fixes
are incorporated.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


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

Re: New architectures

[Luk Claes]

Vincent Bernat wrote:
> OoO Lors de  la soirée naissante du dimanche 05  avril 2009, vers 17:53,
> Paul Wise  disait :
> 
>>> How packages that run on Linux only should handle those new architectures?
> 
>> Same as for stuff that only runs on i386; port them to kFreeBSD or
>> restrict them to linux architectures and add them to P-a-s.
> 
> Hum, what's "P-a-s"?

Packages-arch-specific: it's a list of packages that will for a *long*
time not be supported on all architectures. File a bug against
buildd.debian.org if you think an entry should be added for your package.

Cheers

Luk


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

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Vincent Bernat]

OoO En  ce début de soirée du  dimanche 05 avril 2009,  vers 21:56, Russ
Allbery  disait :

>> I don't  know for proftpd,  but a daemon  can use an empty  directory in
>> /var/run to chroot into it.

> Seems like a good use for /var/lib to me.  There's no reason that I can
> see  to put  such  a directory  on  a file  system  that's defined  as
> transient.

Both   /var/lib  and   /var/run  are   for  files,   not   really  empty
directories. It seems to be more usual to put an empty (or almost empty)
directory into  /var/run than into /var/lib.  Googling a bit,  I did not
find  any  rationale  behind  this.   It  seems  not  advisable  to  use
/var/empty (an hole in an  application could permit to share the exploit
with another for example).

This  is not  an  argument against  having  /var/run in  tmpfs, just  an
information about what  kind of daemon could be run  from inetd and need
something in /var/run.
-- 
I WILL NOT HANG DONUTS ON MY PERSON
I WILL NOT HANG DONUTS ON MY PERSON
I WILL NOT HANG DONUTS ON MY PERSON
-+- Bart Simpson on chalkboard in episode 2F13


pgpJs7ykkZEwH.pgp
Description: PGP signature

Re: New architectures

[Vincent Bernat]

OoO Lors de  la soirée naissante du dimanche 05  avril 2009, vers 17:53,
Paul Wise  disait :

>> How packages that run on Linux only should handle those new architectures?

> Same as for stuff that only runs on i386; port them to kFreeBSD or
> restrict them to linux architectures and add them to P-a-s.

Hum, what's "P-a-s"?


pgpavALVk5BJn.pgp
Description: PGP signature

Re: Japanese Font Transition (step for applications)

[Hideki Yamane]

On Thu, 20 Nov 2008 14:51:28 +0100
Josselin Mouette  wrote:
> Le jeudi 20 novembre 2008 à 22:08 +0900, Junichi Uekawa a écrit :
> > You are correct.  I'm a bit ambivalent on that, since we've seen a
> > pattern that new and better fonts pop up every year (full-featured
> > free fonts are a very nascent thing in Japanese), and I think a
> > standard tasksel installation of Debian should already satisfy the
> > dependency with a good enough font of the year.
> 
> In which case the correct approach, I think, is to remove all the
> ttf-japanese-* in Provides:, and upload new ttf-japanese-gothic/mincho
> packages that depend on a set of alternative fonts, with a reasonable
> default.

 Does it mean that 
  - craete virtual "ttf-japanese-gothic/mincho" package
  - it depends on ttf-vlgothic or so
 
 Is it correct? If so, I'll make package for that and do ITP.


-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp
 http://wiki.debian.org/HidekiYamane


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

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

[Bart Samwel]

Dear all,

I'm putting the acpi-support package up for adoption. The RFA bug is here:

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

I have copied the text of the bug report below (since my mail client did
not allow me to set X-Debbugs-CC). If anyone is interested to adopt this
package, please get in touch!

Cheers,
Bart

-SNIP-

I want to stop maintaining the acpi-support package and am looking for
an adopter. This package is relatively high-profile, since it is
installed by default on all laptops, and part of it is installed on all
ACPI machines. There are some specific challenges with the package that
make it "interesting" to maintain, for some value of interesting. The
package provides the following:

1. Power button support for all systems, in the form of package
acpi-support-base.

2. Button support for laptops. Special laptop button translations are
included for various laptop brands and types. This also includes default
scripts for button functionality for some laptops, including wireless
buttons etc.

3. Suspend/resume support. Acpi-support used to be one of the primary
suspend packages, before pm-utils came along. Right now, it still
contains the suspend logic, but in the default configuration it
delegates any suspend requests to pm-utils. Still, the legacy suspend
support should keep working for now.

This package receives a pretty steady stream of bug reports due to new
hardware with new button quirks, and it requires active maintenance.
There are several challenges involved in maintaining this package:

1. The upstream for this package is Ubuntu. Ubuntu has never been very
cooperative at accepting changes, until recently: our contact Steve
Langasek has indicated that he is interested in merging most or all of
our changes, provided that we send them in in chunks, with proper
rationales.

2. Even though we have an upstream, we build the package as a
Debian-native package, since we have extensively changed the package. We
moved files around etc., and specifying an upstream source tarball
results in an incorrect package being built. :-/

3. Changes from the upstream are extensive:

- We build two packages: acpi-support-base and acpi-support. The
upstream builds only one, for laptops only.

- We have support for "suspend methods", i.e., we can delegate suspend
to pm-utils but we can also handle it ourselves, depending on configuration.

- A very large variety of small changes have been made as well, in
response to bug reports. None of these changes have been sent upstream. :-/

4. Ubuntu is PHASING OUT this package. They have already moved suspend
to pm-utils (but have failed to remove suspend support from
acpi-support). They're currently moving hotkey translation to hal. This
means that soon we will have no upstream that we can follow! Or we
should ensure that Ubuntu's hal changes are included in our version of
hal as well -- no clue how those packages are related, or whether
Ubuntu's changes are going into upstream hal.

5. The kernel is adding more and more native support for these buttons,
so that acpi-support does not need to translate them anymore.


In the end, the package may need phasing out in Debian as well, or it
may need to become the upstream instead of Ubuntu, in which case it
requires extra maintenance. Whatever happens, it will be a challenge to
keep all hardware working properly. Whoever adopts this package will
help to keep extremely large numbers of laptop users happy!



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

Re: Re: Gratituous dependences among packages

[Filipus Klutiero]

What purpose is served by the existence of kde (the metapackage)?
  
kde is the package which administrators who want to try KDE should 
generally install.

Is there a reason why not to clarify its meaning by renaming it as
'kde-full'
kde doesn't depend on the full KDE (for example, it doesn't depend on 
KDevelop).

 and having a 'kde-slim' package which includes the entire kde
minus development, games, texlive and other heavyweights?
I think it's late to suggest it.  For the development packages, that is 
kdewebdev, see #401862, which is solved in experimental. kde will 
recommend kdewebdev. Maybe it should be downgraded further to a 
suggestion. The tex issue will be resolved with okular replacing kdvi, 
which should happen during squeeze's development.



That leaves games, but I don't think it's worth creating a new 
metapackage for that.



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

Re: Request for Comments: Standardize enabling/disabling of system services

[Filippo Giunchedi]

On Wed, Apr 01, 2009 at 03:04:10PM -0700, Russ Allbery wrote:
> * Renaming init script links, for which we have no adequate tool and which
>   is not an easily reversible process because nothing remembers what the
>   init script links were originally and what runlevels they were enabled
>   in.  This is particularly a problem if you have a custom runlevel
>   configuration, want to disable an init script, and then want to put it
>   back where you had it.

FWIW I'm using sysv-rc-conf and it seems to do the right thing (i.e. remember
the previous level)

filippo
--
Filippo Giunchedi - http://esaurito.net - 0x6B79D401

Frustra fit per plura, quod fieri potest per pauciora.
It is vain to do with more what can be done with less.
-- W. of Ockham


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

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Russ Allbery]

Vincent Bernat  writes:

> I don't  know for proftpd,  but a daemon  can use an empty  directory in
> /var/run to chroot into it.

Seems like a good use for /var/lib to me.  There's no reason that I can
see to put such a directory on a file system that's defined as transient.

-- 
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: [Debian-med-packaging] Bug#503367: Again: Bug#503367: plink: file conflict with putty-tools

[Colin Watson]

On Sun, Apr 05, 2009 at 05:57:37PM +0200, Morten Kjeldgaard wrote:
> On 03/04/2009, at 19.04, Steffen Moeller wrote:
>> I personally think that we should not rename it. And putty's plink
>> should not be renamed either. The two are in a technical conflict,
>> though with little  practical consequences. To me, this situation is
>> preferable over the renaning of the binary of  either.
>
> Couldn't this be handled by the alternatives system?

Alternatives are only suitable when the programs provide essentially the
same or similar functions. They aren't suitable for programs that have
completely different functions but whose names happen to clash.

Cheers,

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

Re: New architectures

[Joerg Jaspert]

On 11711 March 1977, Vincent Bernat wrote:

> How packages that run on Linux only should handle those new architectures?

The same as with any other portability problem. Either fix it, or if it
really doesn't work out mark it as such. P-a-s is one way for it.

-- 
bye, Joerg
 I've annoyed Ganneff enough with that package already, no
reason to top it off by a build-depend on emacs for writing control
files


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

Re: New architectures

[Paul Wise]

On Sun, Apr 5, 2009 at 11:44 PM, Vincent Bernat  wrote:

> How packages that run on Linux only should handle those new architectures?

Same as for stuff that only runs on i386; port them to kFreeBSD or
restrict them to linux architectures and add them to P-a-s.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: New architectures

[Vincent Bernat]

OoO Vers la  fin de l'après-midi du dimanche 05  avril 2009, vers 16:23,
Joerg Jaspert  disait :

> we just added two new architectures to the Debian archive. Everybody
> please welcome

>   kfreebsd-i386 AKA GNU/kFreeBSD i386
>   kfreebsd-amd64 AKA GNU/kFreeBSD amd64


> Note that this enables porter NMUs for those two. In case you have a
> bug with a patch waiting for your package that has to do with one of
> them, please either fix it soon or expect a porter NMU to be done soon.

> The two new architectures (well, better named OS i think, as they use a
> different kernel) are available in unstable and experimental. We do
> start out empty, importing only what is needed to get a buildd
> running. For this reason you will not be able to directly use it
> immediately. Please wait until they catched up, which I expect to happen
> soon.

Hi Joerg!

How packages that run on Linux only should handle those new architectures?
-- 
# Basic IBM dingbats, some of which will never have a purpose clear
# to mankind
2.4.0 linux/drivers/char/cp437.uni


pgpZdExSTLIgE.pgp
Description: PGP signature

Bug#522642: ITP: ethervendors -- Ehernet Vendor utils

[Eduardo Ferro]

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

--- Please fill out the fields below. ---

   Package name: ethervendors
Version: 1.0.0
Upstream Author: Alea Soluciones / Eduardo Ferro 
URL: http://oss.alea-soluciones.com/trac/wiki/EtherVendors
License: GPL
Description: Ehernet Vendor utils
 Simple  Ehernet Vendor ids utilities. Includes programs for lookup the
 Vendor / Manufacturer name from a Ethernet MAC address, show all
 the Vendor Ids assigned to a Manufacturer. etc.
 .



-- 
Hasta otra!!!

Eduardo Ferro Aldama
Alea Soluciones



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

Bug#522640: ITP: gpesyncd -- synchronisation agent for GPE PIM data

[gregor herrmann]

Package: wnpp
Severity: wishlist
Owner: gregor herrmann 


/*
Background:
gpesyncd is the "missing link" between opensync-plugin-gpe and
gpe-{calendar,contacts,todo}. opensync-plugin-gpe needs gpesyncd on
the machine that has the gpe-* sqlite databases.
Since I want to use gpe-calendar on my Openmoko Freerunner and sync
the calendar I need this package. I've built my preliminary package on
the Freerunner (!) and it works fine.
*/


* Package name: gpesyncd
  Version : 2.0
  Upstream Author : Martin Felis 
* URL : http://gpe.linuxtogo.org/projects/gpesyncd.shtml
http://gpe.linuxtogo.org/download/source/ (source)
* License : GPL-2+
  Programming Lang: C
  Description : synchronisation agent for GPE PIM data

 gpesyncd synchronises PIM data by transforming vCards, vEvents, vTtodo and
 iCals to the apropriate format in the SQLite database of the respective GPE
 applications and vice versa.
 .
 gpesyncd exports and imports PIM data either to stdout or over tcp/ip.
 It can also be used as a command line tool to access all the PIM data.
 .
 opensync-plugin-gpe needs gpesynd to run on the machine where the GPE
 application data are stored.


Cheers,
gregor
-- 
 .''`.   Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
   `-NP: Kurt Ostbahn & die Chefpartie


signature.asc
Description: Digital signature

Bug#522638: ITP: docsis -- Encode/Decode DOCSIS configuration files

[Eduardo Ferro]

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

--- Please fill out the fields below. ---

  Package name: docsis
       Version: 0.9.5
Upstream Author: Cornel Ciocirlan  & The
Evvolve Team 
           URL: http://docsis.sourceforge.net
       License: GPL
   Description: Encode/Decode DOCSIS configuration files

This program encodes text configuration files which contain Configuration
File Settings into binary configuration files, as specified by the
DOCSIS Radio Frequency Interface]


--
Hasta otra!!!

   Eduardo Ferro Aldama
   Alea Soluciones



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

Bug#522637: ITP: libbackgroundrb-ruby -- BackgrounDRb is a job server and scheduler for moving long-running tasks into the background

[Micah Anderson]

Package: wnpp
Severity: wishlist
Owner: Micah Anderson 

* Package name: libbackgroundrb-ruby
  Version : 1.2
  Upstream Author : Hement Kumar 
* URL : http://backgroundrb.rubyforge.org/
* License : MIT
  Programming Lang: Ruby
  Description : BackgrounDRb is a job server and scheduler for moving 
long-running tasks into the background

BackgrounDRb is a Ruby job server and scheduler. Its main intent is to
be used with Ruby on Rails applications for offloading long-running
tasks. Since a Rails application blocks while serving a request it is
best to move long-running tasks off into a background process that is
divorced from http request/response cycle.

The source can be found here: git clone 
git://github.com/gnufied/backgroundrb.git 



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

Bug#522636: ITP: libpacket-ruby -- ruby library for Event driven network programming

[Micah Anderson]

Package: wnpp
Severity: wishlist
Owner: Micah Anderson 

* Package name: libpacket-ruby
  Version : 0.1.15
  Upstream Author : Hemant Kumar 
* URL : http://packet.googlecode.com/
* License : MIT
  Programming Lang: Ruby
  Description : ruby library for Event driven network programming

Packet is a pure ruby library for writing network applications in Ruby.
It follows Evented Model of network programming and implements almost all the
features provided by EventMachine.

It also provides real easy to user UNIX workers for concurrent programming.

Source code is here: http://github.com/gnufied/packet



-- 
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)

[Martijn van Oosterhout]

On Wed, Apr 1, 2009 at 9:47 PM, Andreas Tille  wrote:
> On Wed, 1 Apr 2009, Goswin von Brederlow wrote:
>
>> Then the version number will not be needed when an arch lags
>> behind. The translation for the old md5sum can just be kept.
>
> Well, this thread was missused to discuss several issues. Would you mind
> reading my original posting why version numbers
> in Translation files make sense and would you please base your arguing on
> this posting.  Perhaps I'm just wrong but version
> numbers are really handy in this case and I see an extra benefit
> in making these files somehow human readable (in the sense that
> I doubt you are able to calculate md5sums manually to find out
> the matching description.

While I'm not against the idea of version numbers (though it would
have to be a list since a single translation may apply to dozens of
versions) it's not that hard to identify the description you want.
What I often did was simply open up the description file to find the
description I wanted to test, cut and paste it into another console
running md5sum and that would be the md5 I needed to look for.

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: ITH: xournal

[Andreas]

Carlo Segre wrote:
> This can 
> be fixed with a known patch.

Can you tell me a source to this patch?

> I will be preparing an updated package for upload by the weekend unless I 
> hear from the current maintainer before then.

Did you finish it already?

I have the same problem and reported the bug. I found out, that the
libgtk and xournal from unstable have this problem on i386 arch. So i
can't "paint" in PDF files anymore with Xournal on my Thinkpad X61t. On
my Desktop i have amd64 arch, and there everything is working fine
although the version of libgtk and Xournal are the same like on the
i386. A downgrade to the stable  libgtk at the laptop made it work
again, but other programs like gajim stopped working. So i am really
looking forward to a patch for my laptop debian system and i would be
happy if u can help, because i need it when University starts in 2 weeks.

thx


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

Re: [DEHS] packages without a checkable upstream?

[Hideki Yamane]

Hi Raphael,

On Sun, 05 Apr 2009 00:53:24 -0600
Raphael Geissert  wrote:
> IOW: your watch file is broken, DEHS is fine, blame uscan

 No, DEHS is fine, uscan is useful, blame me ;)
 I'll post to debian-qa next time.


> A version of uscan detecting invalid regexes should soon be available.

 Okay, thanks.

-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp
 http://wiki.debian.org/HidekiYamane


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

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Vincent Bernat]

OoO En cette nuit striée d'éclairs  du samedi 04 avril 2009, vers 02:14,
Russ Allbery  disait :

>> There are still daemons though (like proftpd comes to mind), which ship a
>> subdirectory in /var/run and support inetd.

> What does it use the directory for?

I don't  know for proftpd,  but a daemon  can use an empty  directory in
/var/run to chroot into it.
-- 
FUNNY NOISES ARE NOT FUNNY
FUNNY NOISES ARE NOT FUNNY
FUNNY NOISES ARE NOT FUNNY
-+- Bart Simpson on chalkboard in episode 8F20


pgpaTIof8Ed1U.pgp
Description: PGP signature

Bug#522616: ITP: live-f1 -- Formula 1 live timing

[Matthew Johnson]

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

  Source package: live-f1
   Binary package(s): live-f1
 Version: 0.2.7-1
 Licence: GPL-2
  Author: Scott James Remnant 
Homepage: 

Description: Formula 1 live timing
 Command line program for monitoring live timing from Formula 1 races.
 Requires a free account on the Formula 1 website.



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

Re: Transition of initscripts to new order / sequence number

[Wouter Verhelst]

On Sat, Apr 04, 2009 at 08:07:16PM +0200, Jan Wagner wrote:
> Hi,
> 
> On Saturday 04 April 2009, Kel Modderman wrote:
> > On Thursday 19 March 2009 00:35:06 Jan Wagner wrote:
> > > while thinking about how to solve #508189, where I need to change the
> > > position of the initscript in bootorder, I thought it would not
> > > sufficient to change only the call of dh_installinit in the rules file.
> > An update-rc.d interface for this was proposed here [0]. An analogous
> > solution would need to be provided for dependency based boot (insserv
> > diverts update-rc.d) and any other boot system in Debian which diverts
> > update-rc.d.
> 
> hmm .. doesn't looks like this is available for now and all other statements 
> seems not to lead me to a short-/midterm solution ... so what should I do 
> with the bugreport?

When I had a similar issue with nbd-client, I just changed the call to
update-rc.d, and added an entry to NEWS.Debian documenting what the user
would need to do to transition to the new setup.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


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