Re: Should the X packages pre-depend on awk?

[Santiago Vila]

On Sat, 2 Aug 2008, Steve Langasek wrote:

> Santiago, please see
>  for an
> explanation of why I've reassigned this bug; I think awk has been
> accidentally left outside the Essential set in a subtle way that has gone
> largely unnoticed, probably because no one uses awk in their preinst
> scripts. :)

Thanks a lot for the explanation.

My only fear is: Will debootstrap manage gracefully a base-files
package having a pre-depends: awk?

If yes, would the fix for this (a pre-depends: awk) be allowed in lenny?


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

Re: Bits from the Debian Eee PC team, summer 2008

[Robert Millan]

On Sun, Aug 03, 2008 at 08:28:19AM -0300, Ben Armstrong wrote:
> 
> Earliest Eee models fully supported in Lenny
> 
>Lenny will release with the atl2 ethernet driver and the non-free
>madwifi-source now works with the earliest Eee models as well,

Hi Ben

Lenny is Debian.  non-free is not part of Debian.  Check the Social Contract.

Friendly,

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


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

Re: Bits from the Debian Eee PC team, summer 2008

[Ben Armstrong]

On Sun, 3 Aug 2008 13:53:54 +0200
Robert Millan <[EMAIL PROTECTED]> wrote:
> Lenny is Debian.  non-free is not part of Debian.  Check the Social Contract.

In light of the point of that follows this one, is it perhaps not too
far of a stretch to imagine that I understand this, and expected my
readers to understand this?

Ben


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

confusion about non-free (Re: Bits from the Debian Eee PC team, summer 2008)

[Robert Millan]

[ adding debian-project ]

On Sun, Aug 03, 2008 at 01:53:54PM +0200, Robert Millan wrote:
> On Sun, Aug 03, 2008 at 08:28:19AM -0300, Ben Armstrong wrote:
> > 
> > Earliest Eee models fully supported in Lenny
> > 
> >Lenny will release with the atl2 ethernet driver and the non-free
> >madwifi-source now works with the earliest Eee models as well,
> 
> Hi Ben
> 
> Lenny is Debian.  non-free is not part of Debian.  Check the Social Contract.

I wonder what is it that we do wrong to spread this confusion so much that it
affects even Debian developers themselves.

What is this to blame?  Would it be the FTP archive layout?  Perhaps having an
unified BTS?

I'd be very interested in finding an answer to that question, and proposing a
reform if we find something conclussive.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


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

Re: confusion about non-free (Re: Bits from the Debian Eee PC team, summer 2008)

[Ben Armstrong]

On Sun, 3 Aug 2008 14:17:46 +0200
Robert Millan <[EMAIL PROTECTED]> wrote:
> I wonder what is it that we do wrong to spread this confusion so much that it
> affects even Debian developers themselves.
> 
> What is this to blame?  Would it be the FTP archive layout?  Perhaps having an
> unified BTS?
> 
> I'd be very interested in finding an answer to that question, and proposing a
> reform if we find something conclussive.

I'm speechless.


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

Bug#493593: ITP: cdde -- CD Detect & Execute utility

[Stanislav Maslovski]

Package: wnpp
Severity: wishlist
Owner: Stanislav Maslovski <[EMAIL PROTECTED]>


* Package name: cdde
  Version : 0.2.0
  Upstream Author : Eric Lathrop <[EMAIL PROTECTED]>
* URL : http://ericlathrop.com/cdde/
* License : GPL
  Programming Lang: C
  Description : CD Detect & Execute utility

CDDE is a program that detects when a CD/DVD-ROM drive has a disc 
inserted. When it finds a disc inserted in the drive it will attempt 
to determine the type of the disc, and execute a specified command. 
This means a DVD can be inserted and your favorite DVD software will 
start, or a data CD can be automatically mounted, etc. The commands 
are defined in a configuration file that has simple XML syntax.



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

Re: Bits from the Debian Eee PC team, summer 2008

[Ben Armstrong]

As Robert Millan brought to my attention, in my enthusiasm to present
our progress towards fully Lenny support for the Eee in the best
possible light, my announcement muddied the distinction between Lenny
and non-free when I said that the earliest Eee models are now "fully
supported" in Lenny. I have corrected my blog article to make it clear
that full support will not be realized until we have ath5k. The new
first point of the article reads:

Earliest Eee models supported in Lenny

Lenny will release with the atl2 ethernet driver and the non-free
madwifi-source now works with the earliest Eee models as well, so our
patched version is no longer needed.  This means Lenny will work with
all of the earliest models of the Eee PC: 701 (2G and 4G surf, 4G, 8G)
and 900! All we need now for full support in Lenny is to replace the
non-free wireless driver with the free ath5k driver when it is ready.

Sorry for the confusion,
Ben
--
 ,-.  nSLUGhttp://www.nslug.ns.ca   [EMAIL PROTECTED]
 \`'  Debian   http://www.debian.org[EMAIL PROTECTED]
  `  [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
 [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]


signature.asc
Description: PGP signature

Available papersizes vs. default papersizes

[Frank Küster]

Hi all,

I would like to solve a long-standing bug and finally make TeX aware of
libpaper and its system-wide paper size setting. In a way, upstream's
configuration scripts already provide most of the infrastructure needed.
However, taking the intersection of paper sizes the different program's
configuration files accept as default, I end up with a4paper and letter.

Therefore I asked upstream whether they'd be willing to add more paper
sizes, and they said they would accept patches. However, they also said
that they didn't want to bloat the code with information about paper
sizes which no one will ever use as a system-wide default paper.

On the upstream list, the discussion which papers would make sense as a
system-wide default paper did not lead anywhere. Some said that only
a4paper and letter make sense (my question whether asian or african
countries use nothing else stayed unanswered). Some argued that every
paper which can be fed to a printer on the market might be used as
default size on a particular system.

Do you have any suggestions?

Regards, Frank

-- 
Frank Küster
Debian Developer (TeXLive)
ADFC Miltenberg
B90/Grüne KV Miltenberg


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

Re: Bug#53121: Gerador de sistemas - Convite

[Flávio Soares]

Nome: Flávio Campos Soares
Email: [EMAIL PROTECTED]
Telefone: (27) 9936-1322  /  (27) 3229-0359

_
Instale a Barra de Ferramentas com Desktop Search e ganhe EMOTICONS para o 
Messenger! É GRÁTIS!
http://www.msn.com.br/emoticonpack

Re: Perl symbol problem - release critical (Re: Bug#489132)

[Niko Tyni]

On Thu, Jul 03, 2008 at 10:17:47PM +0200, Raphael Hertzog wrote:
> On Thu, 03 Jul 2008, Ian Jackson wrote:

> > * This problem is clearly release critical.  I don't think documenting
> >   a release critical bug of this severity in the release notes is
> >   acceptable.  Furthermore, the proposed workaround is very cumbersome
> >   due to the necessary installation ordering.
> 
> It's clearly release critical but doesn't necessarily happen on all
> upgrades. It depends if update-alternatives/dpkg-divert is called
> between the liblocale-gettext-perl and perl-base unpack.

Sorry to join in this late, I've been on a family vacation.  Although my
name is on the perl package, I'm really a bit out of my depth here.
Help is welcome.

For the record, at least #489132 (Cc'd), #479220, #479711, #488300, and
#479681 (Cc'd) are related.

As far as I understand, in the case of Etch->Lenny upgrades and
Locale::gettext (which is the most pressing issue here):

- apt will always upgrade both liblocale-gettext-perl and perl-base in
  the same go because of their dependencies
- dpkg will always unpack (and configure) perl-base before unpacking
  liblocale-gettext-perl because the latter Pre-Depends on the former

Furthermore, in my test upgrades with apt the new perl-base is unpacked
(and configured) right before liblocale-gettext-perl gets unpacked, so
no maintainer scripts from other packages get run in between. I don't
claim that this behaviour is guaranteed, only that I don't have a recipe
for reproducing the problem in a real upgrade situation.

My tentative assumption is that the breakage only bites when a version of
liblocale-gettext-perl lacking the perl pre-dependency (that's 1.05-2,
1.05-3 and 1.05-3+b1) is involved, or when the upgrade is done by
installing some packages 'manually' with dpkg. I haven't seen any bug
reports to the contrary yet.

One recipe for breaking update-alternatives and dpkg-divert in such a
'manual' way starting from a minimal Etch install is:

# apt-get install liblocale-gettext-perl
# perl -pi -e 's/etch/lenny/' /etc/apt/sources.list
# apt-get update
# apt-get install libc6
# apt-get -d install perl-base
# dpkg -i /var/cache/apt/archives/perl-base_5.10.0-11.1_amd64.deb 

Note that dpkg doesn't refuse to do this: the dependencies of the old
liblocale-gettext-perl package are violated, but they aren't checked
because liblocale-gettext-perl is not being configured.

> In general a package offers no guaranty to be functionnal until it is
> successfully configured... so the perl module rely on this assumption.
> The problem is that some of the non-core modules are used by part of our
> essential infrastructure. Locale::gettext is the most important one.
> Any script using this module is potentially broken when called in
> some preinst script.

... or a prerm one ("old-prerm upgrade new-version"), and "only" if the
script doesn't set $ENV{PERL_DL_NONLAZY}.

> > * Suppressing lazy symbol resolution may work in this case, but it is
> >   not correct.  ABI changes may result in random crashes due to
> >   different structure sizes and do not necessarily involve missing
> >   symbols - so the problem may go undetected.  If we think that we
> >   want to fix it in etch->lenny by suppressing lazy symbol resolution,
> >   we need to:
> > (a) check what the actual ABI differences are and that either
> > there aren't any others besides missing symbols, or that
> > every module will definitely fail to load
> > (b) regard this as a workaround and do something sensible next
> > time.
> 
> I leave that to perl maintainers. :)

FWIW, modifying Perl to always disable lazy symbol resolution in "eval"
blocks was explicitly discouraged upstream because it conceivably could
break existing setups using partly broken binary modules. See

 http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2008-05/msg00426.html

> > * One of the Perl upstream commenters in #479711 suggests that the
> >   answer is to use a `pre-inst dependency' which apparently none of
> >   the submitters have realised is what dpkg already has and calls
> >   Pre-Depends.  However, a Pre-Depends doesn't solve this problem
> >   because there is no correct order to upgrade the packages:
> >   regardless of whether you upgrade Perl first, or the modules first,
> >   something may break.
> 
> This is why I suggested to integrate liblocale-gettext-perl in perl-base
> itself. This would be the simplest/nicest solution IMO. It would always be
> synchronized with the current perl.
> 
> See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479681

There's also the suggestion in #489132 to make perl-base Pre-Depend on
dpkg (>= 1.14.20), whose scripts set $ENV{PERL_DL_NONLAZY} to avoid the
breakage.  As far as I can see, this should work too for the immediate
problem, and it would be even simpler. But maybe I'm missing something?

Brendan already acked the liblocale-gettext-perl/perl-base integration
option in #479681, so 

Re: Available papersizes vs. default papersizes

[Ben Hutchings]

On Sun, 2008-08-03 at 18:44 +0200, Frank Küster wrote:

> Therefore I asked upstream whether they'd be willing to add more paper
> sizes, and they said they would accept patches. However, they also said
> that they didn't want to bloat the code with information about paper
> sizes which no one will ever use as a system-wide default paper.

Why does this need to be in code?  So long as you only care about
rectangular sizes, it seems like it would be trivial to implement a
configuration file syntax for specifying sizes.  Then that would be easy
to extend without "bloat".

> On the upstream list, the discussion which papers would make sense as a
> system-wide default paper did not lead anywhere. Some said that only
> a4paper and letter make sense (my question whether asian or african
> countries use nothing else stayed unanswered).

Asian and African countries may use other sizes, but if printers don't
support them then we don't have to be worry about them.  A4 and related
sizes are part of an ISO standard, not just European - still, some might
want other ISO sizes like A3 as a default.


> Some argued that every
> paper which can be fed to a printer on the market might be used as
> default size on a particular system.

Well, why not?

Ben.

-- 
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth


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

Re: Available papersizes vs. default papersizes

[Frank Küster]

Ben Hutchings <[EMAIL PROTECTED]> wrote:

> On Sun, 2008-08-03 at 18:44 +0200, Frank Küster wrote:
> 
>> Therefore I asked upstream whether they'd be willing to add more paper
>> sizes, and they said they would accept patches. However, they also said
>> that they didn't want to bloat the code with information about paper
>> sizes which no one will ever use as a system-wide default paper.
>
> Why does this need to be in code?  So long as you only care about
> rectangular sizes, it seems like it would be trivial to implement a
> configuration file syntax for specifying sizes.  Then that would be easy
> to extend without "bloat".

The only problem is that the configuration file syntax is already there
(and has been for more than a decade).  And although the lines
specifying a paper size are rather simple in most of them, parsing and
writing the complete file is hard. 

On the other hand, there is already upstream code to parse and write
these files, and there's even a script which can, in principle, handle
the default paper size for at least the three most relevant programs. I
don't think it makes sense to reinvent all this. And for sure I'm not
going to do it.

> 
>> Some argued that every
>> paper which can be fed to a printer on the market might be used as
>> default size on a particular system.
>
> Well, why not?

Don't know, but the bottom line is that if I want TeXLive in Debian to
support all libpaper-supported sizes, I have to keep a patch, since
upstream doesn't like the idea. If I could come up with four or eight
"sensible" or "frequently used" ones, I could spare myself the patching.

Regards, Frank

-- 
Frank Küster
Debian Developer (TeXLive)
ADFC Miltenberg
B90/Grüne KV Miltenberg


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

Bug#493645: ITP: nostromo -- small, simple, fast and secure httpd

[Kai Hendry]

Package: wnpp
Severity: wishlist
Owner: Kai Hendry <[EMAIL PROTECTED]>

* Package name: nostromo
  Version : 1.8.6
  Upstream Author : Marcus Glocker <[EMAIL PROTECTED]>
* URL : http://www.nazgul.ch/dev.html
* License : MIT
  Programming Lang: C
  Description : small, simple, fast and secure httpd

 Runs as a single process, handling connections with select. For CGIs
 and directory listing it forks. Supports HTTP/1.1, CGI/1.1, chroot,
 setuid, basic authentication, SSL, IPv6, custom repsonses, aliases, and
 virtual hosts.


A prerelease test version of the package resides on:
http://hendry.iki.fi/debian/unstable

Seems smaller than lighttpd and looks on first impressions more secure
than thttpd. At least nicer looking code. I have in mind embedding
nhttpd on small low powered devices.

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



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

Statically linking against bundled libagg

[Dominic Hargreaves]

The upstream for my package mapnik builds against an embedded copy of
agg, basically an unmodified agg 2.4. I am aware that this is an
undesirable situation and would like to try and fix this.

As far as I can tell from upstream, the decision to bundle AGG is only a
convenience for building on systems which don't have agg available
already.

Building and rudimentary testing against the agg 2.5 shipped with
unstable works, however I have a couple of concerns which make me
reluctant to change the build:

When building against system agg, I get the lintian error:

E: libmapnik0.5: shlib-with-non-pic-code usr/lib/libmapnik.so.0.5.0

this does not occur when compiling mapnik's own agg library.
I'm not sure what's happening here; does it indicate a mistake in the
way the agg library was built to start with or the way I'm building
mapnik?

The other concern is basically about the possibility of introducing
regressions in functionality by changing the build at this late stage.
This is entirely my own fault; I have left this issue unresolved for too
long.

So, questions:

1) can anyone offer advice about how to correct the above lintian error?
2) assuming I can fix the problem and upload a fix, should I ask for it
   to enter testing -- ie is it better to fix the embedded code copy
   issue for lenny or minimise the possibility of regressions?

For reference I attach the patch against the version of mapnik in
unstable I am using to build against the system agg library.

Thanks,
Dominic.

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)
Index: debian/control
===
--- debian/control	(revision 1047)
+++ debian/control	(working copy)
@@ -1,7 +1,7 @@
 Source: mapnik
 Priority: optional
 Maintainer: Dominic Hargreaves <[EMAIL PROTECTED]>
-Build-Depends: libboost-thread-dev (>= 1.34.0), libboost-filesystem-dev (>= 1.34.0), libboost-regex-dev (>= 1.34.0), libboost-program-options-dev (>= 1.34.0), libboost-python-dev (>= 1.34.1-9), libpng12-dev, libjpeg62-dev, libtiff4-dev, zlib1g-dev, libfreetype6-dev, libpq-dev, proj, libltdl3-dev, libfribidi-dev, python, debhelper (>= 5.0.38), python2.5-dev, python-central (>= 0.5.6), libgdal1-dev, libxml2-dev, libagg-dev, libboost-iostreams-dev (>= 1.34.0)
+Build-Depends: libboost-thread-dev (>= 1.34.0), libboost-filesystem-dev (>= 1.34.0), libboost-regex-dev (>= 1.34.0), libboost-program-options-dev (>= 1.34.0), libboost-python-dev (>= 1.34.1-9), libpng12-dev, libjpeg62-dev, libtiff4-dev, zlib1g-dev, libfreetype6-dev, libpq-dev, proj, libltdl3-dev, libfribidi-dev, python, debhelper (>= 5.0.38), python2.5-dev, python-central (>= 0.5.6), libgdal1-dev, libxml2-dev, libagg-dev, libboost-iostreams-dev (>= 1.34.0), libagg-dev
 Standards-Version: 3.7.3
 Section: libs
 XS-Python-Version: 2.5
Index: debian/changelog
===
--- debian/changelog	(revision 1047)
+++ debian/changelog	(working copy)
@@ -1,3 +1,9 @@
+mapnik (0.5.1-3~test.1) unstable; urgency=low
+
+  * Link against system agg library
+
+ -- Dominic Hargreaves <[EMAIL PROTECTED]>  Sun,  6 Jul 2008 18:21:06 +0100
+
 mapnik (0.5.1-2) unstable; urgency=low
 
   * Update mapnik-utils extended description to fix formatting problem
Index: src/SConscript
===
--- src/SConscript	(revision 1047)
+++ src/SConscript	(working copy)
@@ -30,7 +30,7 @@
 prefix = env['PREFIX']
 install_prefix = env['DESTDIR'] + '/' + prefix
 
-libraries = ['agg'] + env['LIBS']
+libraries = env['LIBS']
 # Debian hack to clean up linking of main library (fixes dpkg-shlibdeps
 # warnings)
 libraries.remove('z')
Index: SConstruct
===
--- SConstruct	(revision 1047)
+++ SConstruct	(working copy)
@@ -94,7 +94,7 @@
 if not val in env[key]: env[key].append(val)
 
 # Libraries and headers dependency checks
-env['CPPPATH'] = ['#agg/include', '#include', '#']
+env['CPPPATH'] = ['/usr/include/agg2', '#include', '#']
 env['LIBPATH'] = ['#agg', '#src']
 
 # Solaris & Sun Studio settings (the `SUNCC` flag will only be
@@ -204,7 +204,7 @@
  Build instructions & settings 
 
 # Build agg first, doesn't need anything special
-SConscript('agg/SConscript')
+#SConscript('agg/SConscript')
 
 # Build the core library
 SConscript('src/SConscript')

Re: Bits from the Debian Eee PC team, summer 2008

[Ben Finney]

Ben Armstrong <[EMAIL PROTECTED]> writes:

> Earliest Eee models supported in Lenny
> 
> Lenny will release with the atl2 ethernet driver and the non-free
> madwifi-source now works with the earliest Eee models as well
[…]

> Sorry for the confusion,

Thanks very much for correcting this important distinction, and
congratulations to you and all the team for continued progress!

-- 
 \ “Our task must be to free ourselves from our prison by widening |
  `\our circle of compassion to embrace all humanity and the whole |
_o__)   of nature in its beauty.” —Albert Einstein |
Ben Finney


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

Re: Statically linking against bundled libagg

[Rene Engelhard]

Hi,

Dominic Hargreaves wrote:
> When building against system agg, I get the lintian error:
> 
> E: libmapnik0.5: shlib-with-non-pic-code usr/lib/libmapnik.so.0.5.0
> 
> this does not occur when compiling mapnik's own agg library.
> I'm not sure what's happening here; does it indicate a mistake in the
> way the agg library was built to start with or the way I'm building
> mapnik?

You want -fPIC, both for your lib and agg. Try -lagg_pic if it exists
(when I maintained agg I created it - OOo once used agg too and still
has agg 2.4 in the code - unused by distros, though)

> The other concern is basically about the possibility of introducing
> regressions in functionality by changing the build at this late stage.
> This is entirely my own fault; I have left this issue unresolved for too
> long.

I can't (and won't) judge that as I don't know mapnik.

Regards,

Rene


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

Re: Statically linking against bundled libagg

[Russ Allbery]

Dominic Hargreaves <[EMAIL PROTECTED]> writes:

> Building and rudimentary testing against the agg 2.5 shipped with
> unstable works, however I have a couple of concerns which make me
> reluctant to change the build:
>
> When building against system agg, I get the lintian error:
>
> E: libmapnik0.5: shlib-with-non-pic-code usr/lib/libmapnik.so.0.5.0
>
> this does not occur when compiling mapnik's own agg library.  I'm not
> sure what's happening here; does it indicate a mistake in the way the
> agg library was built to start with or the way I'm building mapnik?

It looks like libagg is only available as a static library and not as a
shared library?  If so, to link it into a shared library, it must be built
position-independent (-fPIC) on almost every platform except i386.  This
error message, if libagg isn't PIC on any architecture, will likely result
in FTBFS on many architectures, such as amd64.

Ideally, libagg should provide a shared library.  Otherwise, any package
that links against the existing library would require a rebuild for any
security vulnerabilities in the library.

Policy 10.2 covers this somewhat.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: lzma: New upstream version available (#460501)

[Robert Millan]

Hi,

Please could you aim at 4.58beta instead?  It's the first version that can
be used by grub-pc for compression of boot blocks.

See:

  http://lists.gnu.org/archive/html/grub-devel/2008-07/msg00036.html

thanks

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


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

Bug#53121: Top video today

[tozhan]

Why we hate our bosses
http://sincor-rj.org.br/index1.html



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

ITP: laconica -- distributed microblogging tool

[Daniel Watkins]

I have claimed and converted the RFP at bug #491723.  All that has
changed from that RFP is the Version number.

* Package name: laconica
  Version : 0.5.0
  Upstream Author : Evan Prodromou and others
* URL : http://laconi.ca/
* License : GNU Affero General Public License
  Programming Lang: PHP
  Description : distributed microblogging tool

Laconica is an open source microblogging tool written in PHP. All data
is stored in a MySQL database. Laconica was created as a direct
response of a need to create an open source, distributed alternative to
Twitter. Laconica implements the OpenMicroBlogging standard. It was
originally used by the identi.ca microblogging service.

-- 
Daniel Watkins (Odd_Bloke)


signature.asc
Description: PGP signature

Bug#493683: ITP: libmarkdown-php -- a port to PHP of the Markdown program

[Daniel Watkins]

Package: wnpp
Severity: wishlist
Owner: Daniel Watkins <[EMAIL PROTECTED]>


* Package name: libmarkdown-php
  Version : 1.0.1m
  Upstream Author : Michel Fortin <[EMAIL PROTECTED]>
* URL : http://michelf.com/projects/php-markdown/
* License : BSD
  Programming Lang: PHP
  Description : a port to PHP of the Markdown program

“Markdown” is two things: a plain text markup syntax, and a software
tool that converts the plain text markup to HTML for publishing on the
web.

The Markdown syntax allows you to write text naturally and format it
without using HTML tags. More importantly: in Markdown format, your text
stays enjoyable to read for a human being, and this is true enough that
it makes a Markdown document publishable as-is, as plain text. If you
are using text-formatted email, you already know some part of the
syntax.

PHP Markdown can work as a plug-in for WordPress and bBlog, as a
modifier for the Smarty templating engine, or as a remplacement for
textile formatting in any software that support textile.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)



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