Toni Mueller wrote:
[...]
> That turns smaller adjustments in applications into
> developing entirely different interfaces for each application, while
> GnuTLS itself still lacks a lot of features.
[...]
Do you have any reference for this? I have not followed this closely
but historically GnuTLS
Hi Mattia,
On Tue, Jul 15, 2014 at 03:26:30AM +0200, Mattia Rizzolo wrote:
> Yesterday I touched another package without the debian/source/format file.
> It was sad: I had to repackage the entire upstream tarball to switch from .xz
> to
> .gz only to make dpkg happy and recognize it as non-native
Le Tue, Jul 15, 2014 at 03:26:30AM +0200, Mattia Rizzolo a écrit :
>
> In fact I'm wondering what is the rationale to stay with the 1.0 format, given
> all the benefits of the 3.0 (quilt) format:
Hi Mattia,
I am not a big fan of the 3.0 (quilt) format because it imposes a patch system.
In partic
Yesterday I touched another package without the debian/source/format file.
It was sad: I had to repackage the entire upstream tarball to switch from .xz to
.gz only to make dpkg happy and recognize it as non-native.
For me this is a nonsense.
Lintian has a info tag for this for a lot of time:
http
Jeff Epler wrote:
> Russ Allbery wrote:
> > I use apt dist-upgrade normally and then, periodically, run:
> > dpkg --get-selections | grep deinstall | awk '{ print $1 }' \
> > | xargs dpkg --purge
> >
> > This is obviously somewhat unsafe. It would be neat to have a tool that
> > would
Dimitri John Ledkov writes:
> Huh, I'm not quite sure that multiple hashes actually gain us anything
> at all in terms of compromisation, since ultimately all our archive
> metadata is protected by a single hash only.
> Whilst replacing individual files & simultaneously matching multiple
> hash
On 14 July 2014 20:57, Henrique de Moraes Holschuh wrote:
> On Mon, 14 Jul 2014, Jakub Wilk wrote:
>> * Peter Palfrader , 2014-07-14, 20:25:
>> >>The basic idea is that it's much harder to come up with a
>> >>simultaneoush hash collision with both SHA-1 and SHA-2 than
>> >>breaking either of them
Package: wnpp
Severity: wishlist
Owner: Tonnerre LOMBARD
* Package name: golang-nfnt-resize
Version : 0.0~git20140715
Upstream Author : Jan Schlicht
* URL : http://github.com/nfnt/resize/
* License : Expat
Programming Lang: Go
Description : Image resiz
Hi Fernando,
AFAIK nobody in JavaScript Team is working on.
Consider to join us[0] if you want to package it.
Cheers!
Leo.
[0] - https://wiki.debian.org/Javascript
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@
Steven Chamberlain writes:
> So, merely as a result of the licensing, we could have a fascinating
> situation whereby:
> * BSD-licensed software contemplates switching from OpenSSL to LibreSSL
> * GNU-licensed software keeps using OpenSSL with license exception, or
> maybe someday switches to Gnu
On 14/07/14 21:08, Toni Mueller wrote:
>> > You forget one of the big problems with OpenSSL that LibreSSL doesn't
>> > fix: the license.
> Granted. Due to the amount of inherited code, it can't. We'll see how
> things evolve as the amount of inherited code will dwindle.
So, merely as a result of t
On Mon, Jul 14, 2014 at 10:08:01PM +0200, Toni Mueller wrote:
> On Sun, Jul 13, 2014 at 12:22:49PM +0200, Jeroen Dekkers wrote:
> > OpenSSL was part of OpenBSD before they created the LibreSSL fork, so
> > how isn't OpenSSL part of the OpenBSD track record?
>
> it is in the way that they include i
Hi Jeroen,
On Sun, Jul 13, 2014 at 12:22:49PM +0200, Jeroen Dekkers wrote:
> At Sat, 12 Jul 2014 14:46:45 +0200, Toni Mueller wrote:
> > Ok, but for whatever reason, they have an imho not as shiny track
> > record, as has OpenBSD. Which is no wonder, given all the revelations we
> > have had rece
On Mon, 14 Jul 2014, Jakub Wilk wrote:
> * Peter Palfrader , 2014-07-14, 20:25:
> >>The basic idea is that it's much harder to come up with a
> >>simultaneoush hash collision with both SHA-1 and SHA-2 than
> >>breaking either of them independently.
> >
> >ISTR reading papers that put this "much har
On Mon, 14 Jul 2014, Nathan Schulte wrote:
> "ASCII hex" encodes 4 bits as 8 (or 7. but really 8.), as each ASCII
> character is a nibble of the digest; that's a 100% increase (factor
> of 2) over the bare digest (or a "raw mapping" of 8 bits of digest
> to an 8 bit character set).
The figures giv
Jakub Wilk writes:
> You might have had this paper in mind:
> https://www.iacr.org/archive/crypto2004/31520306/multicollisions.pdf
> Quoting §4: “If F and G are good iterated hash functions with no attack
> better than the generic birthday paradox attack, we claim that the hash
> function F||G ob
* Peter Palfrader , 2014-07-14, 20:25:
The basic idea is that it's much harder to come up with a
simultaneoush hash collision with both SHA-1 and SHA-2 than breaking
either of them independently.
ISTR reading papers that put this "much harder" into doubt. But I
can't find those references, a
Jeff Epler wrote:
First, I tried encoding the various digests as base64 or base93, rather
than hex. In each case, the file grew in size; base93 was the worst.
Are you sure you performed this calculation correctly?
"ASCII hex" encodes 4 bits as 8 (or 7. but really 8.), as each ASCII
character
Peter Palfrader writes:
> On Mon, 14 Jul 2014, Russ Allbery wrote:
>> Using multiple hashes gives us some theoretical robustness against a
>> break in one of the hash functions provided that all clients check all
>> the hashes and the hashes would fail independently (which is likely).
> I would
Hi Thomas,
On Sun, Jul 13, 2014 at 11:52:24AM +0800, Thomas Goirand wrote:
> On 07/12/2014 08:46 PM, Toni Mueller wrote:
> > As libressl is currently under
> > heavy development, it is imho not to be expected to have that stable ABI
> > you are asking for.
>
> Well, I don't agree with this view.
On Mon, 14 Jul 2014, Russ Allbery wrote:
> ابراهیم محمدی writes:
>
> > Isn't a single (rather small) hash value enough for almost all users?
>
> Using multiple hashes gives us some theoretical robustness against a break
> in one of the hash functions provided that all clients check all the
> ha
is somebody working on node-webkit packaging?
https://github.com/rogerwang/node-webkit
--
Fernando Toledo
Dock Sud BBS
http://bbs.docksud.com.ar
telnet://bbs.docksud.com.ar
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm
ابراهیم محمدی writes:
> Isn't a single (rather small) hash value enough for almost all users?
Using multiple hashes gives us some theoretical robustness against a break
in one of the hash functions provided that all clients check all the
hashes and the hashes would fail independently (which is l
Isn't a single (rather small) hash value enough for almost all users?
On Mon, Jul 14, 2014 at 8:55 PM, Jakub Wilk wrote:
> Food for thought:
> Which fields take up most space in Packages.xz[0]?
>
> (whole file) 6662.0 KiB 100.0%
> SHA256 1463.8 KiB 22.0%
> SHA1
On Mon, Jul 14, 2014 at 09:52:12AM -0700, Russ Allbery wrote:
> I use apt dist-upgrade normally and then, periodically, run:
>
> dpkg --get-selections | grep deinstall | awk '{ print $1 }' \
> | xargs dpkg --purge
>
> This is obviously somewhat unsafe. It would be neat to have a tool
I performed a few little experiments, too.
First, I tried encoding the various digests as base64 or base93, rather
than hex. In each case, the file grew in size; base93 was the worst.
Eliminating all the headers (e.g., replacing Package: foo with simply
foo) saved 3.2%. Replacing each one with
On Mon, 14 Jul 2014, Kurt Roeckx wrote:
> On Mon, Jul 14, 2014 at 02:09:55PM -0300, Henrique de Moraes Holschuh wrote:
> > On Mon, 14 Jul 2014, Kurt Roeckx wrote:
> > > I plan to try and get them to use symbol versioning, at least on
> > > those platforms that support it. This will probably be jus
On Mon, Jul 14, 2014 at 02:09:55PM -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 14 Jul 2014, Kurt Roeckx wrote:
> > I plan to try and get them to use symbol versioning, at least on
> > those platforms that support it. This will probably be just like
>
> Thank you.
>
> > the patch currentl
On 2014-07-14 18:52 +0200, Russ Allbery wrote:
> Thorsten Glaser writes:
>
>> * Running dist-upgrade without --purge will keep packages in 'rc'
>> state around, which a later APT call will not even recognise;
>> you need to manually "dpkg --purge pkg1 pkg2 ..." to get rid
>> of them
>
> I u
On Mon, 14 Jul 2014, Kurt Roeckx wrote:
> I plan to try and get them to use symbol versioning, at least on
> those platforms that support it. This will probably be just like
Thank you.
> the patch currently in Debian. I don't plan to add multiple
> versions of a symbol to try and keep the same
Thorsten Glaser writes:
> * Running dist-upgrade without --purge will keep packages in 'rc'
> state around, which a later APT call will not even recognise;
> you need to manually "dpkg --purge pkg1 pkg2 ..." to get rid
> of them
I use apt dist-upgrade normally and then, periodically, run:
Food for thought:
Which fields take up most space in Packages.xz[0]?
(whole file) 6662.0 KiB 100.0%
SHA256 1463.8 KiB 22.0%
SHA1938.9 KiB 14.1%
Description-md5 794.3 KiB 11.9%
MD5sum 752.4 KiB 11.3%
Depends 473.0 KiB7.1%
Hi,
On Mon, Jul 14, 2014 at 04:46:54PM +0100, Dominic Hargreaves wrote:
> I've agreed to give a one day Debian packaging workshop at $dayjob aimed at
> sysadmins and developers, and I'd be interested in hearing from those who
> have already run similar sessions to get advice/tips for how to approa
Hello,
I've agreed to give a one day Debian packaging workshop at $dayjob aimed at
sysadmins and developers, and I'd be interested in hearing from those who
have already run similar sessions to get advice/tips for how to approach
such a thing. Would there be any interest at attending/contributing
On 07/14/2014 10:01 PM, Steve McIntyre wrote:
> z...@debian.org wrote:
>> On 07/13/2014 09:48 PM, Mike Hommey wrote:
>>>
>>> Well, it kind of is. Because those versioned symbols in openssl come
>>> from a debian patch, afaict. So while debian may be fine (as long as all
>>> build-rdeps have been re
z...@debian.org wrote:
>On 07/13/2014 09:48 PM, Mike Hommey wrote:
>>
>> Well, it kind of is. Because those versioned symbols in openssl come
>> from a debian patch, afaict. So while debian may be fine (as long as all
>> build-rdeps have been rebuilt since openssl got those versioned
>> symbols),
> I would like to make it co-installable with OpenSSL, but in general,
> this should be a drop-in replacement until APIs really diverge in a
> visible way. Yes, it would provide 'openssl', but I intend to place them
> into a different directory, so you might have to use LD_PATH to get
> them.
That
bofh80 dixit:
>"apt-get --purge dist-upgrade"
> How does this now translate to over the new apt full-upgrade?
I do not use “the new apt ” anything command. It is purely optional,
and you can use apt-cache and apt-get as you are used to.
>"apt-get --purge dist-upgrade --auto-remove pkgtoinstall p
Package: wnpp
Severity: wishlist
Owner: "Martín Ferrari"
* Package name: python-flask-httpauth
Version : 2.2.1
Upstream Author : Miguel Grinberg
* URL : https://github.com/miguelgrinberg/flask-httpauth/
* License : MIT
Programming Lang: Python
Description
Le dimanche 13 juillet 2014 à 15:28 +0200, Arno Töll a écrit :
> > Moving them to apache2 package would mean you won't have to move them
> > again in the upgrade to apache 2.4, but it would create a new and
> > circular dependency of apache2.2-common on apache2. Given that
> > apache2.2-common alre
h01ger wrote:
>On Sonntag, 13. Juli 2014, Thorsten Glaser wrote:
>> >Furthermore, we will change the people.debian.org web-service such that
>> >only HTTPS connections will be supported (unencrypted requests will be
>> >redirected).
>> This means that requests from wget (since it switched from Open
On Mon, Jul 14, 2014 at 10:36:10AM +0100, Iain R. Learmonth wrote:
> If Debian stops supporting embedded platforms, it stops being a universal
> operating system.
FSVO universal.
I think this is not a good argument unless/until we have some more-or-less
common and official agreement about what does
On Mon, Jul 14, 2014 at 11:16:01AM +0200, Holger Levsen wrote:
> am I getting this right, that there are architectures which are too slow to
> use https??? if so: "wow"...
This seems likely, especially for embedded platforms where power is a
massive constraint.
> (And, if that's the case, I don
Hi,
On Sonntag, 13. Juli 2014, Thorsten Glaser wrote:
> >Furthermore, we will change the people.debian.org web-service such that
> >only HTTPS connections will be supported (unencrypted requests will be
> >redirected).
> This means that requests from wget (since it switched from OpenSSL to
> GnuTL
Hi,
Am Montag, den 14.07.2014, 08:49 + schrieb Thorsten Glaser:
> Kibi wrote:
> >Joachim Breitner (2014-07-13):
> >>Am Sonntag, den 13.07.2014, 13:02 +0200 schrieb Cyril Brulebois:
> >> >> [10]https://www.debian.org/intro/organization
> >>not really helpful. It links to
> >> [11]https://build
h01ger wrote:
>I've never used "upgrade --purge" _in one step_ and I don't think it's a
>particularily smart idea at all. But if people want to shoot themselves in
The --purge is a no-op with "upgrade".
But I normally use "apt-get --purge dist-upgrade" both to upgrade
across distros and to stay
Kibi wrote:
>Joachim Breitner (2014-07-13):
>>Am Sonntag, den 13.07.2014, 13:02 +0200 schrieb Cyril Brulebois:
>> >> [10]https://www.debian.org/intro/organization
>>not really helpful. It links to
>> [11]https://buildd.debian.org/
>> from where no information about how to query for rebuilds can be
Hi Arno,
On Sun, Jul 13, 2014, at 13:17, Arno Töll wrote:
> Hello,
>
> we've got a problem with Apache that causes problems during upgrades
> (e.g. #716880, #752922, #711925). In short, the issue is that Apache 2.4
> changed ABIs, so that we need to ensure that dpkg properly removes
> packages li
48 matches
Mail list logo
