Re: Bug#793644: ITP: hadoop -- Apache Hadoop distributed processing framework

2015-08-07 Thread Emmanuel Bourg 
Le 07/08/2015 04:42, Dmitry Smirnov a écrit :

> Perhaps packaging could be brought to the custody of Debian-Java team?

Yes that's the plan.


> Also what about FUSE client?

The FUSE client will be included.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55c45b46.1090...@apache.org

Re: Bug#793644: ITP: hadoop -- Apache Hadoop distributed processing framework

2015-08-07 Thread Alexandre Detiste 
2015-07-28 12:27 GMT+02:00 Emmanuel Bourg :
>> I doubt that anybody would use a debian version of hadoop now as long as it
>> isn't backed by upstream, cloudera or hortonworks.
>
> I don't think this package will be widely adopted either, not everyone
> churns an amount of data that justifies the use of Hadoop. I'm mainly
> packaging it as a dependency of Solr, which is more likely to be popular.

Hadoop is listed on so many job offers, and that seems a nice exit-way
to escape from "SAS B.I." hell, that would be really nice to be able to give
it a try without going through some contrived manual build process
as told here: https://wiki.debian.org/Hadoop .

In a learning/academic mindset, the amount of data doesn't matter.

> backed by upstream, cloudera or hortonworks.

I guess that people paid to handle this stuff 9 to 5
can handle the existing manual build.

Thanks !


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CADsTwjKhavikoVxKEJNrZUm0Z9XssxBBk_O++cwArRiYsNE=g...@mail.gmail.com

Bug#794839: ITP: djoser -- REST implementation of Django authentication system.

2015-08-07 Thread Michael Fladischer 
Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: djoser
  Version : 0.3.1
  Upstream Author : SUNSCRAPERS 
* URL : https://github.com/sunscrapers/djoser
* License : Expat
  Programming Lang: Python
  Description : REST implementation of Django authentication system.

REST implementation of Django authentication system. Djoser library provides a
set of Django Rest Framework views to handle basic actions such as registration,
login, logout, password reset and account activation. It works with custom user
models.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJVxG9tAAoJEGlMre9Rx7W2zTEQAIq5XHT5J8cbmp1u6fURFAGb
z3OviJ/MqmniVaDxQEh0uuyeQUjhKgqzaUnmP6FtZeR9A2yPuzC+seQw5TSXRcnk
9IAtUiGuiexBTX4MGX/2c0A2GV0Z60x2l/mQZ7XGXkquUXeo7GxkPIIu9GpZh/wv
Zs8OB8kJTgui5JSKqO1YNbokWLZN5ApdtV+dx4DTtcsxc8gz75ZNMJaYigOWYKPi
cYZ/tXzuFJuWz/oWwqrmhvBCswPmcFwykAkLAggG1XFU02fAalEAFkfGe/H1/l81
MT5A+Cj5yIC1Qad4jBbaLaXXOnvDQM7rKM/Xr+9OQ1zfDUesAzoHN2vBoHSYbiRZ
ZXzMYUN8lYrRETWIxVgv7kQAwg0Ta9CkATGD4I1Rg7odAhL7sWsRLF9+61OKZ+bc
vJZ5wr4PmglwL5rKcT2D4YzmNKTy+ech/jplHCuSXXFnd/+nc2QS7PoAjW92CqTJ
C4WsRrR9wsHaeeJmxggYsCs8BjR9NHo1yiClmKiAaM/T5f3sWG4+kt+ls3sFr2N5
7TR386DGrmKhmyii5dIBcffXamaOuvCv6DPh3nhHmZO8Bl8+/8mp2o+F7+WRaoQP
ysRLO1gbJR5ECcipScWLb8l4L5cdWsYGfJApsv579ygiybkhcUo7xybHXCAb+Kpy
H2bCCfXysnpxerDTCXc/
=oL7b
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150807084225.7789.5065.reportbug@kashyyyk

Bug#794842: ITP: r-cran-vcdextra -- GNU R package providing extensions and additions to the vcd package

2015-08-07 Thread Jonathon 
Package: wnpp
Severity: wishlist
Owner: Jonathon 

* Package name: r-cran-vcdextra
  Version : 0.6-9
  Upstream Author : Michael Friendly 
* URL : http://cran.r-project.org/package=vcdExtra
* License : GPL2
  Programming Lang: R
  Description : GNU R package providing extensions and additions to the vcd 
package
 A GNU R package providing additional data sets, methods and
 documentation to complement the 'vcd' package for Visualizing
 Categorical Data and the 'gnm' package for Generalized Nonlinear Models.
 In particular, 'vcdExtra' extends mosaic, assoc and sieve plots from
 'vcd' to handle 'glm()' and 'gnm()' models and adds a 3D version in
 'mosaic3d'. Additionally, methods are provided for comparing and
 visualizing lists of 'glm' and 'loglm' objects. This package is now a
 support package for the book, "Discrete Data Analysis with R" by Michael
 Friendly and David Meyer.

 This package is being packaged by Jonathon Love, under the sponsorship of 
Andreas Tilles


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150807095433.5471.96631.reportbug@debian.bruce

Mass bug filing about non free lena image.

2015-08-07 Thread Gianfranco Costamagna 
Hi Debian Developers, I would like to let you know I would like to do an MBF 
for ~11 packages
(not so mass bug filing actually) because they use a lena.jpg (or whatever is 
called) that is 

non DFSG for Debian.

The list of the packages can be seen here [1]

and I'm adding it below



cl-plplot 0.6.0-5 (source)
- src/examples/lena.png

codeblocks 13.12-3.1 (source)
- src/plugins/scriptedwizard/resources/opencv/files/lena.jpg
- src/plugins/contrib/source_exporter/wxPdfDocument/samples/minimal/lena.jpg

libvigraimpex 1.10.0+dfsg-9 (source)
- src/examples/lenna.bmp

matplotlib 1.4.2-3.1 and 1.4.3-1 (source)
- lib/matplotlib/mpl-data/sample_data/lena.jpg
- lib/matplotlib/mpl-data/sample_data/lena.png

mgltools-vision 1.5.7~rc1+cvs.20140424-1 (source)
- Vision/regression/lena.jpg
- Vision/doc/Examples/lena.jpg
- Vision/doc/Examples/matplotlib/Data/lena.jpg

opencv 2.4.9.1+dfsg-1.1 (source)
- samples/c/lena.jpg
- samples/cpp/lena.jpg
- samples/cpp/tutorial_code/images/lena.png
- doc/tutorials/introduction/clojure_dev_intro/images/lena.png
- doc/tutorials/introduction/desktop_java/images/lena.png
- modules/java/android_test/res/drawable/lena.jpg
- samples/winrt/OcvImageProcessing/OcvImageProcessing/Assets/Lena.png
- samples/java/clojure/simple-sample/resources/images/lena.png

plplot 5.10.0+dfsg-1 (source)
- examples/lena.pgm
- examples/c/lena.pgm

sivp 0.5.3+svn287-2.1 (source)
- images/lena.png

skimage 0.10.1-2 (source)
- skimage/data/lena.png

spandsp 0.0.6-2.1 (source)
- test-data/local/lenna-colour.tif

visp 2.10.0-4 (source)
- doc/image/img-lena-blured-default.png
- doc/image/img-lena-blured-var2.png
- doc/image/img-lena-canny.png
- doc/image/img-lena-dIxy.png
- doc/image/img-lena-gray.png
- doc/image/img-lena-pyr.png
- doc/image/img-lena-sobel.png
- doc/image/img-lena-win.jpg
- doc/image/img-lena.png
- tutorial/image/lena.bmp
- tutorial/image/lena.jpeg
- tutorial/image/lena.pgm
- tutorial/image/lena.png
- tutorial/image/lena.ppm

the only false positive I saw was
ns3 3.22+dfsg-1 (source)
- ns-3.22/src/lte/doc/source/figures/lena-dual-stripe.eps


NOTE: I didn't check all the files for all the packages, I stopped when I found
one good match.

[1] https://lintian.debian.org/tags/license-problem-non-free-img-lenna.html


I'll open the 11 RC bugs later today or tomorrow.

cheers,

Gianfranco


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/531346913.662412.1438942673913.javamail.ya...@mail.yahoo.com

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

2015-08-07 Thread Antonio Diaz Diaz 

Jakub Wilk wrote:

The purpose of adding garbage could be to make a modified tarball
match the signature.


Which is why we also supply the length.


I thought the idea was to create a smaller malicious tarball, then
append "garbage" until the size and the hash match.


With xz you don't need trailing garbage to match the size and the hash. 
Xz allows you to insert as much garbage inside the file as you want. Xz 
is an ideal vector for malware because it is strict with the envelope 
but lax with the message.


I have no experience at all rigging tarballs, but it took me just 
minutes to obtain two xz compressed tarballs with very different 
contents that match in size and sum(1). I did it just with an editor, 
ddrescue and data from /dev/urandom, by brute force, without any 
knowledge about the algorithm of sum. And I did it not once, but twice.


The original tarballs are 1 and 2. 1b and 2b are the altered versions 
yielding the same sum as the opposite original tarball:


-rw-r--r-- 1 10292 2015-08-07 11:52 collision1.tar.xz
-rw-r--r-- 1 10292 2015-08-07 13:32 collision1b.tar.xz
-rw-r--r-- 1 10292 2015-08-07 11:53 collision2.tar.xz
-rw-r--r-- 1 10292 2015-08-07 13:04 collision2b.tar.xz

$ sum collision*.tar.xz
4287011 collision1.tar.xz
5334111 collision1b.tar.xz
5334111 collision2.tar.xz
4287011 collision2b.tar.xz

$ xz -t collision*.tar.xz ; echo $?
0

$ tar -tf collision1.tar.xz ; echo $?
configure
0
$ tar -tf collision1b.tar.xz ; echo $?
configure
0

$ tar -tf collision2.tar.xz ; echo $?
Makefile
0
$ tar -tf collision2b.tar.xz ; echo $?
Makefile
0

If a weak hash is used, or if a way of creating hash collisions is 
found, xz makes it easy to create altered tarballs with the same hash 
and size. Just try to do the same with bzip2, gzip or lzip without 
adding trailing garbage.



Best regards,
Antonio.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55c4b892.5010...@gnu.org

Bug#794874: ITP: libdbicx-sugar-perl -- syntax sugar for DBIx::Class

2015-08-07 Thread Jonas Smedegaard 
Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: libdbicx-sugar-perl
  Version : 0.0001
  Upstream Author : Naveed Massjouni 
* URL : http://search.cpan.org/dist/DBICx-Sugar/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : syntax sugar for DBIx::Class

 DBICx::Sugar provides some syntax sugar for your DBIx::Class
 applications.
 .
 DBIx::Class is an SQL to OO mapper with an object API inspired by
 Class::DBI and a resultset API that allows abstract encapsulation of
 database operations.

Package is needed for recent releases of libdancer-plugin-dbic-perl.

Package will be maintained in the Debian Perl team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJVxLlMAAoJECx8MUbBoAEh2HwP/jQdVRHG0RpfG4t7EH2fY2Zg
g6zgm2AUOnWLefHzwLIJPQ4yupLfGDUo+cPtYIk4PdwkaS296M8btiJaO2piRhVw
YyaF5zPDxaqFxadXIVKyImDR9xNJdckR3FBPtUhbTJREBOe/3Xy9Umagt0d7qQF+
ednPXqs7sh65IqJOJX5/kofRTJytKcE1R/dVRC7KuZdRhPyJtPvGdBN+ZqzUHBQQ
yzUHd6qi7m74HSNdPNokgyrlR5Of4Hr1GFJmaAKLYZqkrfYW5pn7gGwpXMyVvIvo
D+H0EggjRTEkmDMxdVYEISA3PETOga3JaHvcxV9knnv9NnOp5v/KtnZPCT/DH0MN
odDM99iO+I3fgRxfKj5LgJo3moBMJ19qBxhOu1fw4i87icV86+3LaiCc2/DglDCX
To3wRqFysUcUK0wzwcAzP8SMGze5mqMPVW9v0FRGDTfUe22N93EKl5LDH+fb6nz1
27QDSF4b6zdekE2uTjH2zlnghrk8HFSrYs4Ii8oMoc8FOTjZpc9gJx+tQInIOTaF
J+FY9UABloVO0OSbAB7ZxpgOBKbjx50sADJ+1/dJJUZjChl9HMjVafHKnQIvc0WU
jDt+lexOxxYhIJSNJ5YNaS1f29nKx57p2FWrv3F889wZDhSjwd7+s1owRYWHxOgZ
P2BVFxl7KgaA3LoVkb7O
=pbHb
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150807135732.17039.9817.report...@auryn.jones.dk

Bug#794880: ITP: libmoox-strictconstructor-perl -- make Moo-based object constructors blow up on unknown attributes

2015-08-07 Thread Jonas Smedegaard 
Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: libmoox-strictconstructor-perl
  Version : 0.008
  Upstream Author : George Hartzell 
* URL : https://metacpan.org/release/MooX-StrictConstructor
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : make Moo-based object constructors blow up on unknown 
attributes

 Simply loading MooX::StrictConstructor makes your constructors
 "strict".  If your constructor is called with an attribute init
 argument that your class does not declare, then it dies.  This is a
 great way to catch small typos.

Package is needed with reent releases of libhttp-throwable-perl.

Package will be maintained in the Debian Perl team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJVxMY4AAoJECx8MUbBoAEhiLoQAK3L++UL3ivtE7qA6kkjM69G
GN5XMKYmV5WdTMB4hi6t0Ngus4jv5QZ7gWFY/uVmGYqOxfwKvZQjg7ixXmi0Rkld
RCq9khTJgP1mdJ6zzX16wxz1aXT51+yeSI7i+twZOT0mQgJEwe7NyhRXMZFJu+LJ
NPseoC8wdhtVVIoFwdHYQb62aSoD4RAkSerpB4KiyxkMf2Lq5UofFoVM0gJXrWLV
5xN8QlQG/qCH66UOPpqX1HfhDTRZsO42Fqt6NHyfSm2vR42ZdiOOmRbdZUOgOEc1
3ZvxzE3YoRbEg1lpMyh11Xwjuo2G3OumS9WHAiktxNFuGEPlhuhcxvAxmgK3CX1K
CNqVXoNo9DEJOqIANHM2fOgL4FHFIZUuk6SywyJ3acOtcMUrSu/Nix7oS6Kr62yZ
in4bMtMytrhTVfrmsa0kZUMqAdZmh2fJC2uVHZy5TohxJ4eXEQmLqfrmb9xA/gvv
smBLRY42ImDeXgJdK3gd+X4qcHF6Mwd5JrOcQ/+c7R88LGisoTh2MxWnLM3Ujjo7
dYfo9JFOzVvditWHLL0wYFhrkFbg2fgJD8hzIfinp2Y/WYxUP30gFkSKeQvDsbEt
JanbUVoPju4PjyZiydWNSVDmdY51tSiGMN+S1Db3t76VuXDwcUZT0UKoKcG36xmp
fWBbiucy9HVoBKFlnN8c
=7QMC
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150807145243.15757.21468.report...@auryn.jones.dk

Bug#794885: ITP: django-rest-swagger -- Swagger Documentation Generator for Django REST Framework

2015-08-07 Thread Michael Fladischer 
Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: django-rest-swagger
  Version : 0.3.3
  Upstream Author : Marc Gibbons 
* URL : https://github.com/marcgibbons/django-rest-swagger
* License : BSD-2-clause
  Programming Lang: Python
  Description : Swagger Documentation Generator for Django REST Framework

This project is built on the Django REST Framework Docs and uses the Swagger
from Wordnik as an interface. This application introspectively generates
documentation based on your Django REST Framework API code. Comments are
generated in combination from code analysis and comment extraction. Here are
some of the features that are documented:

 * API title - taken from the class name
 * Methods allowed
 * Serializers & fields in use by a certain method
 * Field default values, minimum, maximum, read-only and required attributes
 * URL parameters (ie. /product/{id})
 * Field help_text property is used to create the description from the
   serializer or model.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJVxNdEAAoJEGlMre9Rx7W2DVkP/24/tfAqG9TSLx+xb8JxD8m5
uZwOWSgtcW/QbWkhwaZe6cNOydb5d1mSJ57wj14Q9YvyfS1frRBnj/xEEeKPJDQK
AmhZuNcSuMOTEiZ6wwI3Qfy0cydu3H5zWZw1SEoCfu3XOvlt4RWgGvDLI1MHgMat
uqHavkYpN87OcvkrMYah92TchTHzX8SiKJ+cGhkI7boPz6sLNqXdrvk5C4ktawti
zqxDU3e5f0ILhhjnM8D+UZC8xiTk9da3Qvx1g72q62S0XdsG7b3ni0lWxreywFAQ
a4M7Vo4lMRwu2PfIIYeJCgtWDLgo8TLiZ7XqYTTyWUYGRwpuNiX3lW+mYI0tVFov
fbRS2EULS7b9dBBW69oZh85lDZfUd1QvCYGv16jeKmupAJ9EL1srGZzlBugOGdmx
E1jTfaYe263dysnSBpIl+/iqB1TnPUY+Xugt2ikPjr2pgF60RzIc26CXoKL7WIVs
R9TAV5JP3ZKhRQncejTBJtSqMwT8ZFb58Ox/esf0vxOyP6wYrogCYUadiqzuMxum
OgiiLKEupgkpNA7an9NsneQSvTJtBDpt9xaaauZSj7CwlwZw1V8dxyBhaq0pfoJT
3qVlY4rMgfzas4+AaVZ9ijD2ZctVSIskoi52ZWrKzwPAu3RsIk+MctA1aWS483zC
U5Aviq26OFngj9Lu10Y8
=PPSe
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150807160527.9959.47901.reportbug@kashyyyk

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

2015-08-07 Thread Vincent Lefevre 
On 2015-08-07 15:54:26 +0200, Antonio Diaz Diaz wrote:
> I have no experience at all rigging tarballs, but it took me just
> minutes to obtain two xz compressed tarballs with very different
> contents that match in size and sum(1). I did it just with an
> editor, ddrescue and data from /dev/urandom, by brute force, without
> any knowledge about the algorithm of sum. And I did it not once, but
> twice.

sum(1) just gives a 16-bit checksum! So, it suffices to generate
N*65536 random compressed tarballs to get around N collisions with
a given file. Then the only problem is to get the right size, but
if one has random input, it is (almost) not compressible, so that
one will get "almost" the same size for each tarball. By controlling
how compression is done to reach the right size, this should even be
easier.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150807192703.ga12...@zira.vinc17.org

Re: interested in (co-)maintaining midori

2015-08-07 Thread Sergio Durigan Junior 
On Saturday, August 01 2015, Andres Salomon wrote:

>> I'm interested in helping out with Midori packaging.  I'm not sure
>> who's still interested in the package at this point (I know Corsac
>> isn't, so I didn't Cc him).  I've created a git branch for the 0.5.10
>> release here:
>> 
>> git://lunge.queued.net/git/midori
>> http://lunge.queued.net/gitweb/?p=midori;a=shortlog;h=refs/heads/0.5.10
>> 
>> It builds (on sid and jessie) and runs (on jessie) for me, though it
>> definitely needs more work tightening up deps, cleaning up lintian
>> errors, etc.
>> 
>> I'm happy to co-maintain the package, or take it over; whatever folks
>> prefer.  Please let me know what I should do, since it was never
>> formally orphaned.
>
>
> I haven't heard anything regarding this, and it's been over a month.
> Should I just clean up my midori packages and upload?  If I don't hear
> anything back and there's no activity with the package, that's my
> plan.

Hi Andres,

I saw your message only yesterday, sorry about that.  As it turns out, I
have also been working on getting Midori fixed.  My intention is to
maintain it; Thadeu Cascardo is going to help me take over the package.
However, as you are also willing to co-maintain the package, maybe we
could create a group on Alioth to work together?

I also looked at your branch.  What I am doing is basically a
"repackaging", from scratch, trying to figure out what's important and
what's not.  I'll publish my branch later today.

So, any opinions on how to proceed?

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8737zulwfp@sergiodj.net

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

2015-08-07 Thread Vincent Lefevre 
On 2015-08-07 21:27:03 +0200, Vincent Lefevre wrote:
> On 2015-08-07 15:54:26 +0200, Antonio Diaz Diaz wrote:
> > I have no experience at all rigging tarballs, but it took me just
> > minutes to obtain two xz compressed tarballs with very different
> > contents that match in size and sum(1). I did it just with an
> > editor, ddrescue and data from /dev/urandom, by brute force, without
> > any knowledge about the algorithm of sum. And I did it not once, but
> > twice.
> 
> sum(1) just gives a 16-bit checksum! So, it suffices to generate
> N*65536 random compressed tarballs to get around N collisions with
> a given file. Then the only problem is to get the right size, but
> if one has random input, it is (almost) not compressible, so that
> one will get "almost" the same size for each tarball. By controlling
> how compression is done to reach the right size, this should even be
> easier.

The following script gives lzip collisions after a few seconds between
arbitrary lzip tarballs. This is easier that a collision with a fixed
tarball because of the birthday paradox. But one can do something
similar by going to at most a few millions to get a collision with
some given tarball of about 64 KB.

A real test should be based on a hash for which one knows to build
collisions only by using well-chosen garbage, like MD5.

If xz can contain arbitrary garbage without affecting other parts
of the file (while still keeping its validity), this is quite bad,
but still safer than garbage at the end, which is IMHO the worst
for incremental hashes.

#!/usr/bin/env zsh

typeset -A a

r=test-random
head -c 65536 /dev/urandom > $r

rm -f foo*.tar.lz

for i in {1..1000}
do
  file=file$i
  tarf=foo$i.tar
  ln -f $r $file
  tar cf $tarf $file
  lzip $tarf
  rm $file
  tarz=$tarf.lz
  s="$(sum $tarz | cut -d' ' -f1) $(command stat -c %s $tarz)"
  if [[ -n $a[$s] ]] then
echo $a[$s]
echo $tarz
break
  fi
  a[$s]=$tarz
done

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150807201702.ga12...@zira.vinc17.org

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

2015-08-07 Thread Joerg Jaspert 
On 14026 March 1977, Vincent Lefevre wrote:

>> > contents that match in size and sum(1). I did it just with an
>> > editor, ddrescue and data from /dev/urandom, by brute force, without
>> > any knowledge about the algorithm of sum. And I did it not once, but
>> > twice.
>> sum(1) just gives a 16-bit checksum! So, it suffices to generate
>> N*65536 random compressed tarballs to get around N collisions with
>> a given file. Then the only problem is to get the right size, but
>> if one has random input, it is (almost) not compressible, so that
>> one will get "almost" the same size for each tarball. By controlling
>> how compression is done to reach the right size, this should even be
>> easier.
> The following script gives lzip collisions after a few seconds between
> arbitrary lzip tarballs. This is easier that a collision with a fixed
> tarball because of the birthday paradox. But one can do something
> similar by going to at most a few millions to get a collision with
> some given tarball of about 64 KB.

Is it only me thinking it now or is this really gone over way into the
comedy section? Why isn't this on -curiosa?

Person 1: xz is shit, use lzip, change around all your tools, invest
  tons of work

Debian: Na, we selected this, we stay with it, unless proven it gains
something in OUR use case

Person 1: But xz is shit!

Debian: It doesn't matter in our use case.

Person 1: But xz is shit! [loads of examples of things that may go
  wrong]

[repeat forever]


This is not only getting annoying and ensuring that we won't ever switch
to lzip - the only way people now think about it is "thats the tool that
has this really annoying supporter" - it is also not getting anywhere.

If one wants to switch something in Debian one does not demand that
Debian switches $foo - one starts by doing as much of the work as can be
done. And providing good reasons why Debian should switch. Reasons that
consider the way we use it and all the tools around it.

Could we please end this thread? Thanks.

-- 
bye, Joerg
Just because I don't care doesn't mean I don't understand.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/877fp6rexy@gkar.ganneff.de

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

2015-08-07 Thread Philip Hands 
Joerg Jaspert  writes:

> On 14026 March 1977, Vincent Lefevre wrote:
>
>>> > contents that match in size and sum(1). I did it just with an
>>> > editor, ddrescue and data from /dev/urandom, by brute force, without
>>> > any knowledge about the algorithm of sum. And I did it not once, but
>>> > twice.
>>> sum(1) just gives a 16-bit checksum! So, it suffices to generate
>>> N*65536 random compressed tarballs to get around N collisions with
>>> a given file. Then the only problem is to get the right size, but
>>> if one has random input, it is (almost) not compressible, so that
>>> one will get "almost" the same size for each tarball. By controlling
>>> how compression is done to reach the right size, this should even be
>>> easier.
>> The following script gives lzip collisions after a few seconds between
>> arbitrary lzip tarballs. This is easier that a collision with a fixed
>> tarball because of the birthday paradox. But one can do something
>> similar by going to at most a few millions to get a collision with
>> some given tarball of about 64 KB.
>
> Is it only me thinking it now or is this really gone over way into the
> comedy section? Why isn't this on -curiosa?

NO, it definitely isn't just you -- and the rest of your post was spot on too.

Please stop this nonsense forthwith.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: interested in (co-)maintaining midori

2015-08-07 Thread Andres Salomon 
On Fri, 07 Aug 2015 15:39:54 -0400
Sergio Durigan Junior  wrote:

> On Saturday, August 01 2015, Andres Salomon wrote:
> 
> >> I'm interested in helping out with Midori packaging.  I'm not sure
> >> who's still interested in the package at this point (I know Corsac
> >> isn't, so I didn't Cc him).  I've created a git branch for the
> >> 0.5.10 release here:
> >> 
> >> git://lunge.queued.net/git/midori
> >> http://lunge.queued.net/gitweb/?p=midori;a=shortlog;h=refs/heads/0.5.10
> >> 
> >> It builds (on sid and jessie) and runs (on jessie) for me, though
> >> it definitely needs more work tightening up deps, cleaning up
> >> lintian errors, etc.
> >> 
> >> I'm happy to co-maintain the package, or take it over; whatever
> >> folks prefer.  Please let me know what I should do, since it was
> >> never formally orphaned.
> >
> >
> > I haven't heard anything regarding this, and it's been over a month.
> > Should I just clean up my midori packages and upload?  If I don't
> > hear anything back and there's no activity with the package, that's
> > my plan.
> 
> Hi Andres,
> 
> I saw your message only yesterday, sorry about that.  As it turns
> out, I have also been working on getting Midori fixed.  My intention
> is to maintain it; Thadeu Cascardo is going to help me take over the
> package. However, as you are also willing to co-maintain the package,
> maybe we could create a group on Alioth to work together?

There's already a midori packaging group/git repo:

http://anonscm.debian.org/cgit/collab-maint/midori.git/

My repo is based on this, and my plan was to get access permission
from Corsac after uploading the package to sid.  Then I could push
my changes, maintaining history.  That would be my preference.

> 
> I also looked at your branch.  What I am doing is basically a
> "repackaging", from scratch, trying to figure out what's important and
> what's not.  I'll publish my branch later today.

Why from scratch?

I'll take a look at your branch once it's published.

> 
> So, any opinions on how to proceed?
> 
> Thanks,
> 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150807225117.4a586...@e7240.queued.net

Re: interested in (co-)maintaining midori

2015-08-07 Thread Sergio Durigan Junior 
On Saturday, August 08 2015, Andres Salomon wrote:

>> I saw your message only yesterday, sorry about that.  As it turns
>> out, I have also been working on getting Midori fixed.  My intention
>> is to maintain it; Thadeu Cascardo is going to help me take over the
>> package. However, as you are also willing to co-maintain the package,
>> maybe we could create a group on Alioth to work together?
>
> There's already a midori packaging group/git repo:
>
> http://anonscm.debian.org/cgit/collab-maint/midori.git/

Hello Andres,

Yes, I know that.  I have been using this repository as the base, too.
But the idea is to get a real group for Midori, like the Mozilla
packagers have (for example).  This git repository is just this: a git
repository.  With a group we would have the advantage of having an
official mailing list to coordinate efforts, and also interested
(co-)maintainers for the package working together.

> My repo is based on this, and my plan was to get access permission
> from Corsac after uploading the package to sid.  Then I could push
> my changes, maintaining history.  That would be my preference.

Sure, I certainly don't want to throw away any existing changes...

>> I also looked at your branch.  What I am doing is basically a
>> "repackaging", from scratch, trying to figure out what's important and
>> what's not.  I'll publish my branch later today.
>
> Why from scratch?

... and maybe I should have been more clear about the "from scratch"
part.  It was just a stronger way of saying that I am actually reviewing
every file under debian/ to see if everything is really needed or not.

What I noticed from your branch is that you don't really delete the "old
stuff"; you are mostly making sure that the latest version works.  I am
spending time removing unnecessary things and figuring out how to
optimize other things there.  My intention is to get the package in good
shape again (but not take too long doing that, of course).

> I'll take a look at your branch once it's published.

Thanks.  I have just published it:

  

This is *not* based on the official repository, but that's just because
I found it more convenient.  As I said above, I intend to merge it to
the original repository very soon.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87twsajnm3@sergiodj.net