On Wed, Mar 03, 2010 at 06:30:34AM +, Sune Vuorela wrote:
> On 2010-03-03, Wouter Verhelst wrote:
> > wou...@celtic:/var/lib/dpkg/info$ ls *md5sums|wc -l
> > 2340
>
> > In this day and age of completely and utterly broken MD5[0], I think we
> > should stop providing these files, and maybe pro
Quoting Raphael Hertzog (hert...@debian.org):
> and it might meant again supplementary changes in the infrastructutre if
> people want to see those descriptions translated (but I'm not convinced
> we need translations on Sources, users of those are mostly developers
> contrary to Packages).
Thos
Quoting Ben Finney (ben+deb...@benfinney.id.au):
> Sounds great, with the minor caveat that I'd rather not have the vars
> using different terms from what is already used to describe those
> fields. Instead, (bikeshed mode activate) I'd prefer
> ‘${source:Description:synopsis}’ and ‘${source:Descr
On 2010-03-03, Wouter Verhelst wrote:
> wou...@celtic:/var/lib/dpkg/info$ ls *md5sums|wc -l
> 2340
> In this day and age of completely and utterly broken MD5[0], I think we
> should stop providing these files, and maybe provide something else
> instead. Like, I dunno, shasums? Or perhaps gpgsigs
Erik de Castro Lopo writes:
> Russ Allbery wrote:
>> I don't understand why you say this. Cryptographic attacks on MD5
>> aren't going to happen as a result of random file corruption. The MD5
>> checksums are still very effective at finding file corruption or
>> modification from what's in the
Russ Allbery wrote:
> Wouter Verhelst writes:
>
> > Or is it useful to be able to say "if it doesn't check out, it's
> > certainly corrupt, and if it does check out, it may be corrupt"? Didn't
> > think so.
>
> I don't understand why you say this. Cryptographic attacks on MD5 aren't
> going to
Raphael Geissert writes:
> Wasn't at some point proposed to include the generic part of the description
> _at the end_?
> I'm now used to finding the different part of the description at the end,
> but I remember at the beginning it was annoying having to skip a bunch of
> text.
I've looked
[ message irrelevant to the bug report, so not CC'ing it ]
Raphael Hertzog wrote:
> On Wed, 11 Nov 2009, Stefano Zacchiroli wrote:
>> The expansion would simply copy
>> the COMMON TEXT from the source package description (if any) at the
>> beginning of each binary package description (possibly add
Wouter Verhelst writes:
> Or is it useful to be able to say "if it doesn't check out, it's
> certainly corrupt, and if it does check out, it may be corrupt"? Didn't
> think so.
I don't understand why you say this. Cryptographic attacks on MD5 aren't
going to happen as a result of random file co
Hello world,
wou...@celtic:/var/lib/dpkg/info$ ls *md5sums|wc -l
2340
wou...@celtic:/var/lib/dpkg/info$ ls *sums|wc -l
2340
wou...@celtic:/var/lib/dpkg/info$ dpkg -l|sed -e'1,/=/d'|wc -l
2483
I must say I was somewhat surprised by these numbers. Out of 2483
packages installed on my laptop, 23
Package: wnpp
Severity: wishlist
Owner: Adrian Glaubitz
* Package name: gkrellm-cpufreq
Version : 0.6.1
Upstream Author : Christoph Winkelmann
* URL : http://mathicse.epfl.ch/~winkelma/gkrellm2-cpufreq/
* License : GPL
Programming Lang: C
Description
Raphael Hertzog writes:
> If I do something like that it's rather with substvars. You could use
> ${source:Description:body} and ${source:Description:title} in the
> binary package description to refer to the the corresponding parts of
> the source description.
Sounds great, with the minor cavea
On 02.03.2010 13:38, Josselin Mouette wrote:
> Le mardi 02 mars 2010 à 11:05 +0100, Raphael Hertzog a écrit :
>> If I do something like that it's rather with substvars. You could use
>> ${source:Description:body} and ${source:Description:title} in the binary
>> package description to refer to the
Raphael Hertzog writes:
> If I do something like that it's rather with substvars. You could use
> ${source:Description:body} and ${source:Description:title} in the binary
> package description to refer to the the corresponding parts of the
> source description.
That sounds like a great idea to m
Package: wnpp
Severity: wishlist
Owner: Sebastien Delafond
* Package name: mpdcron
Version : 0.3
Upstream Author : Ali Polatel
* URL : http://alip.github.com/mpdcron/
* License : GPL-2
Programming Lang: C
Description : Call hooks triggered by MPD event
On Fri, 2010-02-26 at 11:29 +0100, Olivier Bonvalet wrote:
>
> But xen-tools have be removed from Squeeze, so I suppose it will be
> more difficult to create new installations (require much more work to
> replace the xen-create-image script).
Squeeze (32- and 64-bit) and Lenny (32-bit only) both
Package: wnpp
Severity: wishlist
Owner: Kel Modderman
* Package name: wireless-regdb
Upstream Author : Luis R. Rodriguez
* URL :
http://wireless.kernel.org/en/developers/Regulatory/#Theregulatorydatabase
* License : ISC
Programming Lang: C, Python
Description :
On 02/03/2010 14:04, Raphael Hertzog wrote:
> On Tue, 02 Mar 2010, Stefano Zacchiroli wrote:
>> On Tue, Mar 02, 2010 at 01:03:57PM +0100, Emilio Pozuelo Monfort wrote:
>>> The substvars approach sounds good to me. I think I'd use it quite a
lot,
>>> specially in libraries.
>>
>> That, however, does
On Tue, 02 Mar 2010, Stefano Zacchiroli wrote:
> On Tue, Mar 02, 2010 at 01:03:57PM +0100, Emilio Pozuelo Monfort wrote:
> > The substvars approach sounds good to me. I think I'd use it quite a lot,
> > specially in libraries.
>
> That, however, does not solve the problem of how to access a source
Hi,
Olivier Bonvalet wrote:
> But xen-tools have be removed from Squeeze, so I suppose it will be more
> difficult to create new installations (require much more work to replace
> the xen-create-image script).
I took over upstream developement from Steve and I'm working on
reintroduction of x
Package: wnpp
Severity: wishlist
Owner: "Ernesto Hernández-Novich (USB)"
* Package name: libbusiness-paypal-api-perl
Version : 0.62
Upstream Author : Scott Wiersdorf
* URL : http://search.cpan.org/dist/Business-PayPal-API/
* License : GPL or Artistic
Progra
On Tue, Mar 02, 2010 at 01:03:57PM +0100, Emilio Pozuelo Monfort wrote:
> The substvars approach sounds good to me. I think I'd use it quite a lot,
> specially in libraries.
That, however, does not solve the problem of how to access a source
package description from infrastructure tools such as DD
Le mardi 02 mars 2010 à 11:05 +0100, Raphael Hertzog a écrit :
> If I do something like that it's rather with substvars. You could use
> ${source:Description:body} and ${source:Description:title} in the binary
> package description to refer to the the corresponding parts of the source
> descriptio
On 02/03/10 11:05, Raphael Hertzog wrote:
> On Wed, 11 Nov 2009, Stefano Zacchiroli wrote:
>> What is the stance of dpkg-dev maintainers on this?
>
> I think it's ok. But some more feedback would be welcome, CCing -devel for
> this.
The substvars approach sounds good to me. I think I'd use it qui
On Tue, Mar 02, 2010 at 11:05:14AM +0100, Raphael Hertzog wrote:
> > 0) (Starting intuition) most source package have a description per se,
> >intuitively, that is the same description you'd find on the upstream
> >homepage that made you download a specific software. Sure different
> >b
Package: wnpp
Severity: wishlist
Owner: Didier Raboud
Package name: fosfat
Version : 0.3.2
Upstream Author : Mathieu Schroeter
URL : http://home.gna.org/fosfat
License : GPLv3+
Programming Lang: C
Description : library to access Smaky formatted d
Hi,
On Wed, 11 Nov 2009, Stefano Zacchiroli wrote:
> It would be nice to have support for a Description field in the source
> stanza of debian/control.
>
> My rationale for that is manyfold:
>
> 0) (Starting intuition) most source package have a description per se,
>intuitively, that is the
27 matches
Mail list logo
