Re: automatically maintaining/tracking repackaged upstream tarballs

[Daniel Pocock]

On 23/04/14 01:09, Paul Wise wrote:
> On Wed, Apr 23, 2014 at 4:40 AM, Daniel Pocock wrote:
>
>> Given all the recent issues with popular packages containing minified
>> JavaScript and other sourceless files, I'm hoping to get feedback from
>> people about how the solution can be generalized to help as many
>> developers as possible.
> You may have missed the fact that uscan now supports removing files
> specified by the Files-Excluded field in debian/copyright when it
> repacks archives.
>
>> In the Java world, some of these things stick out like a sore thumb
>> (e.g. copies of junit or other *.jar files in upstream tarball) - it is
>> not hard to extrapolate this to match other patterns though.
> If they are automatically detectable, please submit bugs or patches to
> lintian about support for detecting them.
>

Some of this is in "wishlist" territory though:

- could/should uscan be run centrally, e.g. creating a pool of +dfsg
tarballs on alioth?

- uscan is only for existing packages - should it be generalized to also
read directly from watch files that are not in a source package?



-- 
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/53576b60.7070...@pocock.pro

Re: automatically maintaining/tracking repackaged upstream tarballs

[Joachim Breitner]

Hi,

Am Mittwoch, den 23.04.2014, 09:27 +0200 schrieb Daniel Pocock:
> On 23/04/14 01:09, Paul Wise wrote:
> > On Wed, Apr 23, 2014 at 4:40 AM, Daniel Pocock wrote:
> >
> >> Given all the recent issues with popular packages containing minified
> >> JavaScript and other sourceless files, I'm hoping to get feedback from
> >> people about how the solution can be generalized to help as many
> >> developers as possible.
> > You may have missed the fact that uscan now supports removing files
> > specified by the Files-Excluded field in debian/copyright when it
> > repacks archives.
>
> - uscan is only for existing packages - should it be generalized to also
> read directly from watch files that are not in a source package?

This functionality, together with renaming a tarball to the correct name
and possibly changing the compression will be broken out in a new tool
(uncreatively named mk-origtargz), so you can
 * unpack the original tarball
 * create the debian/ directory as usual, including a debian/copyright 
   file with File-Excluded.
 * run "mk-origtargz ../strangely-named-and-partially-free.tar.gz"
   which will create _.orig.tar.gz
 * done

Early adaptors are invited to build devscripts from the git repo
(http://anonscm.debian.org/gitweb/?p=collab-maint/devscripts.git) and
tell us if this works as expected.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



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

Re: automatically maintaining/tracking repackaged upstream tarballs

[Adam D. Barratt]

On 2014-04-23 8:27, Daniel Pocock wrote:

- uscan is only for existing packages


No, it's not.


- should it be generalized to also
read directly from watch files that are not in a source package?


$ cat tempwatch
version=3
http://ftp.gnome.org/pub/GNOME/sources/anjal/([\d\.]+)/anjal-([\d\.]+)\.tar\.gz

$ uscan --watchfile tempwatch --package anjal --upstream-version 0 
--download

anjal: Newer version (0.3.2) available on remote site:
  http://ftp.gnome.org/pub/GNOME/sources/anjal/0.3/anjal-0.3.2.tar.gz
  (local version is 0)
anjal: Successfully downloaded updated package anjal-0.3.2.tar.gz
and symlinked anjal_0.3.2.orig.tar.gz to it

Regards,

Adam


--
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/bbc1d85ef459f863ede36e234cd6a...@mail.adsl.funky-badger.org

Question about binNMU and transition, how can this package NOT segfault?

[Gianfranco Costamagna]

Hi Debian Developers,

A while ago sdlgfx [1] package changed the API/ABI, and for this reason we 
started a transition from .23 to .25 release

the new package has been uploaded on unstable (after two experimental 
releases), on
[2014-04-07] Accepted 2.0.25-3 in unstable (medium)

so after that time every package uploaded on debian has been built with the new 
soname.

Another package (just an example) is this one, gambas3 [2] that uses sdlgfx as 
B-D
that has been uploaded on unstable on
[2014-04-11] Accepted 3.5.2-2 in unstable (low)

So you might see that everything is correct, but (please correct me if I'm 
wrong)
I see TWO bugs:
-gambas3 reached testing prior to sdlgfx 2.0.25, so how can people installing 
it be sure the package won't segfault for the library change?
-gambas3 has been uploaded on debian after TWO weeks in new queue, so the amd64 
package has been built on
Date: Wed, 02 Apr 2014 16:23:48 +1100

the situation now is:
gambas3 for amd64 still uses the old sdlgfx
for other archs uses the new API/ABI,

it has reached testing for an unknown reason to me

[1] http://packages.qa.debian.org/s/sdlgfx.html
[2] http://packages.qa.debian.org/g/gambas3.html


I know it might not be a bug, but I would like to ask, because I have many 
doubts about the correctness of this procedure.

Why you still allow binary uploads?
I mean I know that people might upload wrong versions, FTBFS and so on, but 
what about "allowing only binary uploads, then discard the binary and rebuild 
again?"

many and many times I would like to see changelogs for arch-all packages, but I 
obviously can't.

Cheers,
(I hope to find somebody helping me, and I hope to be on the right mail list, 
and sorry Julien for ccing you, but I wan't to let you know in case of troubles 
in the transition process)


thanks

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/1398240626.81350.yahoomail...@web171801.mail.ir2.yahoo.com

Re: Question about binNMU and transition, how can this package NOT segfault?

[Julien Cristau]

On Wed, Apr 23, 2014 at 09:10:26 +0100, Gianfranco Costamagna wrote:

> Another package (just an example) is this one, gambas3 [2] that uses sdlgfx 
> as B-D
> that has been uploaded on unstable on
> [2014-04-11] Accepted 3.5.2-2 in unstable (low)
> 
gambas3 has no runtime dependency on sdlgfx.  Do you have a better
example?

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Arm64 port live on debian-ports

[Matthias Klose]

Am 20.04.2014 03:27, schrieb Wookey:
> There are about 270 pending arm64 bugfixes, some of which will be for those 
> build failures:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.org;tag=arm64

note that more recent bug reports for autoconf related arm64 build failures were
filed at
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=autoreconf;users=debian-devel@lists.debian.org


-- 
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/53577cf5.6080...@debian.org

Re: automatically maintaining/tracking repackaged upstream tarballs

[Daniel Pocock]

On 23/04/14 10:07, Adam D. Barratt wrote:
> On 2014-04-23 8:27, Daniel Pocock wrote:
>> - uscan is only for existing packages
>
> No, it's not.

>From the man page:


SYNOPSIS
   uscan [options] [path-to-debian-source-packages ...]



could be more verbose:

uscan [options] [path-to-debian-source-packages ...]

uscan [options] --watchfile 


>
>> - should it be generalized to also
>> read directly from watch files that are not in a source package?
>
> $ cat tempwatch
> version=3
> http://ftp.gnome.org/pub/GNOME/sources/anjal/([\d\.]+)/anjal-([\d\.]+)\.tar\.gz
>
>
> $ uscan --watchfile tempwatch --package anjal --upstream-version 0
> --download
> anjal: Newer version (0.3.2) available on remote site:
>   http://ftp.gnome.org/pub/GNOME/sources/anjal/0.3/anjal-0.3.2.tar.gz
>   (local version is 0)
> anjal: Successfully downloaded updated package anjal-0.3.2.tar.gz
> and symlinked anjal_0.3.2.orig.tar.gz to it
>
> Regards,
>
> Adam
>
>


-- 
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/53577e5d.4070...@pocock.pro

Re: Question about binNMU and transition, how can this package NOT segfault?

[Julien Cristau]

On Wed, Apr 23, 2014 at 09:48:35 +0100, Gianfranco Costamagna wrote:

> 
> 
> > Il Mercoledì 23 Aprile 2014 10:29, Julien Cristau  ha 
> > scritto:
> 
> > > On Wed, Apr 23, 2014 at 09:10:26 +0100, Gianfranco Costamagna wrote:
> > 
> >>  Another package (just an example) is this one, gambas3 [2] that uses 
> >> sdlgfx 
> > as B-D
> >>  that has been uploaded on unstable on
> >>  [2014-04-11] Accepted 3.5.2-2 in unstable (low)
> >> 
> > gambas3 has no runtime dependency on sdlgfx.  Do you have a better example?
> 
> ok fair enough, so why is it listed here? [1]
> 
> [1] https://release.debian.org/transitions/html/libsdl-gfx1.2-5.html
> 
Because it has a build-dependency on sdlgfx.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Question about binNMU and transition, how can this package NOT segfault?

[Gianfranco Costamagna]

> Il Mercoledì 23 Aprile 2014 10:29, Julien Cristau  ha 
> scritto:

> > On Wed, Apr 23, 2014 at 09:10:26 +0100, Gianfranco Costamagna wrote:
> 
>>  Another package (just an example) is this one, gambas3 [2] that uses sdlgfx 
> as B-D
>>  that has been uploaded on unstable on
>>  [2014-04-11] Accepted 3.5.2-2 in unstable (low)
>> 
> gambas3 has no runtime dependency on sdlgfx.  Do you have a better example?

ok fair enough, so why is it listed here? [1]

[1] https://release.debian.org/transitions/html/libsdl-gfx1.2-5.html

So for gambas building against both old and new libsdl-gfx1.2-dev is considered 
harmless? I though it would be cause of troubles or at least bugs, but I think 
I understand that a segfault is not possible in this case, thanks

> Cheers,

Have a nice day,

Gianfranco

> Julien
>


--
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/1398242915.14588.yahoomail...@web171805.mail.ir2.yahoo.com

Re: automatically maintaining/tracking repackaged upstream tarballs

[Jonas Smedegaard]

Quoting Daniel Pocock (2014-04-23 10:48:29)
> On 23/04/14 10:07, Adam D. Barratt wrote:
> > On 2014-04-23 8:27, Daniel Pocock wrote:
> >> - uscan is only for existing packages
> >
> > No, it's not.
> 
> >From the man page:
> 
> 
> SYNOPSIS
>uscan [options] [path-to-debian-source-packages ...]
> 
> 
> 
> could be more verbose:
> 
> uscan [options] [path-to-debian-source-packages ...]
> 
> uscan [options] --watchfile 

Please file bugreports about such details, instead of posting to d-devel 
(or if you must then least in addition to - mentioning the bug number).


Regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: automatically maintaining/tracking repackaged upstream tarballs

[Lars Wirzenius]

On Wed, Apr 23, 2014 at 12:58:40PM +0200, Jonas Smedegaard wrote:
> Please file bugreports about such details, instead of posting to d-devel 
> (or if you must then least in addition to - mentioning the bug number).

Or better yet, provide patches. I did, on IRC, to Adam. A few lines of
patch to improve a manpage a little bit is almost no effort at all (I
did it while waiting for a test run to finish at work), and is a
constructive approach to dealing with the issue.

(See, e.g., http://liw.fi/manpages/ if you haven't written manpages
before.)

-- 
http://www.cafepress.com/trunktees -- geeky funny T-shirts
http://gtdfh.branchable.com/ -- GTD for hackers


-- 
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/20140423110754.ga5...@mavolio.codethink.co.uk

Re: Bug#605090: Proposing amd64-hardened architecture for Debian

[Ben Hutchings]

On Tue, 2014-04-22 at 22:41 +0200, Yves-Alexis Perez wrote:
[...]
> NOTE: I don't want to dismiss Mempo attempts, especially the
> reproducible build part, and I also think it's valuable to provide our
> users a grsec kernel as part of the distribution, just that I prefered
> to go the featureset way.

I do want to see the Mempo reproducible build work go upstream and/or
into src:linux, as appropriate.  Unfortunately it's currently siloed
just like grsec itself.

> I had the impression that adding a new copy of the linux sources was not
> really something appreciated by the project, and re-using linux-source
> (binary) package means the patch porting needs to be done anyway.

That was what I thought, too.  Specifically, the security team is
generally opposed to such duplication.

> But if I'm wrong or if things have changed since them, and there's
> indeed a consensus for the vanilla + grsecurity + make deb-pkg as an
> easy way to provide grsec kernels in the Debian archive, then I'm all
> for it.

Well 'make deb-pkg' doesn't work with a source package so you can't use
it as a basis for official Debian packages.

The options I see are:
- Provide a source package based on src:linux that includes only the
grsec featureset on top of an appropriate base version
- Provide a source package that builds only a 'source' binary package
(like linux-source-3.13)

In any case, it needs long-term upstream support, which for jessie would
presumably mean using 3.13 as a base, whereas src:linux will be a later
version.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein


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

Re: Glom DEBIAN packaging

[Paul Wise]

This looks like the relevant part of the log file:

On Wed, 2014-04-23 at 14:21 +0200, Oscar Tark wrote:

> You need to install postgresql-server-dev-X.Y for building a server-side 
> extension or libpq-dev for building a client-side application.
> ./configure: line 19641: /pg_ctl: No such file or directory
> configure:19644: error: 
> The Postgres utilities could not be found. They are needed for
> self-hosting of Glom databases. Please make sure that Postgres
> is installed, and if necessary specify the correct directory
> explicitly with the --with-postgres-utils option.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: automatically maintaining/tracking repackaged upstream tarballs

[Gunnar Wolf]

Paul Wise dijo [Wed, Apr 23, 2014 at 07:09:53AM +0800]:
> > Given all the recent issues with popular packages containing minified
> > JavaScript and other sourceless files, I'm hoping to get feedback from
> > people about how the solution can be generalized to help as many
> > developers as possible.
> 
> You may have missed the fact that uscan now supports removing files
> specified by the Files-Excluded field in debian/copyright when it
> repacks archives.

Just note that, in order for Files-Excluded to work, you have to
declare the current version of the copyright format. Some days ago, I
had quite a bit of head scratching after I added this header to
Collabtive¹, only to find I was using still the DEP5 version instead
of the 1.0 Copyright Format version².

(hint: I'd have rather appreciated uscan or lintian to tell me, "it
seems you want to do something, but I prefer not to interpret you
unless I'm sure)


¹ 
http://anonscm.debian.org/gitweb/?p=collab-maint/collabtive.git;a=blobdiff;f=debian/copyright;h=eaee1b11fc099cadaa71484ffc501f7e84403aa8;hp=03d8473ee1d9ded60d036bbb11a4ef155836672f;hb=e17be66192df19836c0f255adb31cf72f0ac9cbd;hpb=4036925713d23ee6d42a5b9cf9925333ee4d9d9a
² 
http://anonscm.debian.org/gitweb/?p=collab-maint/collabtive.git;a=blobdiff;f=debian/copyright;h=0794435d3875c6ed21ccb678f0e82e667db67e3d;hp=eaee1b11fc099cadaa71484ffc501f7e84403aa8;hb=4827cce4b98c38779d61855da371857693c8df50;hpb=e17be66192df19836c0f255adb31cf72f0ac9cbd


-- 
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/20140423141016.ga21...@gwolf.org

Bug#745627: ITP: django-testproject -- Django test project support

[Neil Williams]

Package: wnpp
Severity: wishlist
Owner: Neil Williams 

* Package name: django-testproject
  Version : 0.1.2
  Upstream Author : Zygmunt Krynicki 
* URL : https://pypi.python.org/pypi/django-testproject
* License : LGPL
  Programming Lang: Python
  Description : Django test project support

 This package provides django test project support to
 make it easier to run application unit tests without
 testing other parts of django core.
 .
 Projects can use run_tests to specify which parts of
 the codebase listed in INSTALLED_APPLICATIONS will
 run unit tests.

https://git.linaro.org/lava/django-testproject.git


-- 
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/20140423141820.8259.42555.reportbug@sylvester.codehelp

Re: automatically maintaining/tracking repackaged upstream tarballs

[Joachim Breitner]

Hi,

Am Mittwoch, den 23.04.2014, 09:10 -0500 schrieb Gunnar Wolf:
> Just note that, in order for Files-Excluded to work, you have to
> declare the current version of the copyright format. Some days ago, I
> had quite a bit of head scratching after I added this header to
> Collabtive¹, only to find I was using still the DEP5 version instead
> of the 1.0 Copyright Format version².
> 
> (hint: I'd have rather appreciated uscan or lintian to tell me, "it
> seems you want to do something, but I prefer not to interpret you
> unless I'm sure)

hint taken:
http://anonscm.debian.org/gitweb/?p=collab-maint/devscripts.git;a=commitdiff;h=6b50047

Greetings,
Joachim


-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



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

new netcdf packages: first review

[Nico Schlömer]

Hi all,

as noted earlier, I'm working on moving the long-outdated netCDF
version in Debian .
This is not entirely trivial since upstream as decided to split netcdf
in three separate packages, supporting C (the basis package), Fortran,
and C++.

I've been working with upstream to get some solid builds on dev/master
and put the result on

https://github.com/nschloe/debian-netcdfc
https://github.com/nschloe/debian-netcdff
https://github.com/nschloe/debian-netcdfcxx

As soon as the new version is released (we're not at rc3 I think, so
it should take much longer), I'll put it on alioth.

For now, please let me know if you spot some obvious mistakes in the builds.

Cheers,
Nico


-- 
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/cak6z60c2+myo_s0qejzomjrwszmbgcu2_kzpwmw67a-pgbb...@mail.gmail.com

Re: Bug#605090: Proposing amd64-hardened architecture for Debian

[Yves-Alexis Perez]

On Wed, Apr 23, 2014 at 12:45:10PM +0100, Ben Hutchings wrote:
> On Tue, 2014-04-22 at 22:41 +0200, Yves-Alexis Perez wrote:
> [...]
> > NOTE: I don't want to dismiss Mempo attempts, especially the
> > reproducible build part, and I also think it's valuable to provide our
> > users a grsec kernel as part of the distribution, just that I prefered
> > to go the featureset way.
> 
> I do want to see the Mempo reproducible build work go upstream and/or
> into src:linux, as appropriate.  Unfortunately it's currently siloed
> just like grsec itself.

Well, I guess the non-grsec related stuff can go upstream/src:linux, but
as I'm not involved in the project, I can't really say.
> 
> > I had the impression that adding a new copy of the linux sources was not
> > really something appreciated by the project, and re-using linux-source
> > (binary) package means the patch porting needs to be done anyway.
> 
> That was what I thought, too.  Specifically, the security team is
> generally opposed to such duplication.

Well, speaking with my security team hat, I can't say I really like it,
but that's not really like having multiple copies of a library either.

Sharing an orig.tar.xz between multiple source packages would be nice
here (although it wouldn't help in case we have different versions).

In any case, that's something I'd accept, but I don't think I can have
the final word on this :)

> > But if I'm wrong or if things have changed since them, and there's
> > indeed a consensus for the vanilla + grsecurity + make deb-pkg as an
> > easy way to provide grsec kernels in the Debian archive, then I'm all
> > for it.
> 
> Well 'make deb-pkg' doesn't work with a source package so you can't use
> it as a basis for official Debian packages.

Yeah, sorry my words were a bit confusing. I really mean “using a
vanilla linux.tar.xz, adding the grsecurity patch and the Debian .config
and building a Debian package with that”.
> 
> The options I see are:
> - Provide a source package based on src:linux that includes only the
> grsec featureset 

Which is more or less what I do with my current patchset (except that I
keep the src:linux name, but that could be changed pretty easily I
think).

> on top of an appropriate base version

I'm not sure I understand what you mean here. You mean staying at
3.2/3.13 for example?

> - Provide a source package that builds only a 'source' binary package
> (like linux-source-3.13)

I'm not sure what's the point here? Is it about having a source package
providing a binary package containing the unpatched vanilla linux sources,
which a src:linux-grsec package could build-depend on, then I guess we
can just have vanilla linux as orig.tar.xz instead of having to
build-dep on a linux-source-vanilla-3.13.
> 
> In any case, it needs long-term upstream support, which for jessie would
> presumably mean using 3.13 as a base, whereas src:linux will be a later
> version.

I guess so.

Regards,
-- 
Yves-Alexis Perez


signature.asc
Description: Digital signature

Re: Bug#605090: Proposing amd64-hardened architecture for Debian

[Ben Hutchings]

On Wed, 2014-04-23 at 17:34 +0200, Yves-Alexis Perez wrote:
> On Wed, Apr 23, 2014 at 12:45:10PM +0100, Ben Hutchings wrote:
> > On Tue, 2014-04-22 at 22:41 +0200, Yves-Alexis Perez wrote:
[...]
> > The options I see are:
> > - Provide a source package based on src:linux that includes only the
> > grsec featureset 
> 
> Which is more or less what I do with my current patchset (except that I
> keep the src:linux name, but that could be changed pretty easily I
> think).
> 
> > on top of an appropriate base version
> 
> I'm not sure I understand what you mean here. You mean staying at
> 3.2/3.13 for example?

Yes.

> > - Provide a source package that builds only a 'source' binary package
> > (like linux-source-3.13)
> 
> I'm not sure what's the point here? Is it about having a source package
> providing a binary package containing the unpatched vanilla linux sources,
> which a src:linux-grsec package could build-depend on, then I guess we
> can just have vanilla linux as orig.tar.xz instead of having to
> build-dep on a linux-source-vanilla-3.13.
[...]

No, I meant that you might build a single binary package that would
contain the grsec-patched source.  That would encourage building custom
kernels with build-time randomisation.  I understand that's not the way
you want to go.

Presumably your current package builds a linux-source-3.13 which
includes an upstream source tarball plus a grsec patch?

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein



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

Re: Bug#605090: Proposing amd64-hardened architecture for Debian

[Yves-Alexis Perez]

On Wed, Apr 23, 2014 at 05:02:03PM +0100, Ben Hutchings wrote:
> No, I meant that you might build a single binary package that would
> contain the grsec-patched source.  That would encourage building custom
> kernels with build-time randomisation.  I understand that's not the way
> you want to go.

Indeed. There's already a (quite outdated) linux-patch-grsecurity2
package which contains the patch for people wanting to patch the kernel
themselves. But that's not really useful imho.
> 
> Presumably your current package builds a linux-source-3.13 which
> includes an upstream source tarball plus a grsec patch?

In my case, it's actually the src:linux orig.tar.xz with the (adapted)
grsec patch added to debian/patches (like other featuresets).

Regards,
-- 
Yves-Alexis Perez


signature.asc
Description: Digital signature

Bug#745640: ITP: hazelcast - distributed cache

[Daniel Pocock]

Package: wnpp
Severity: wishlist
Owner: Daniel Pocock 
X-Debbugs-CC: debian-j...@lists.debian.org,debian-devel@lists.debian.org

(Would appreciate feedback from other Java users)

Brief: Hazelcast claims to be quite simple and powerful at the same
time.  Well documented.  Not using millions of dependencies from Maven,
all but two are already packaged.

Upstream:

  http://www.hazelcast.org

Source:

  https://github.com/hazelcast/hazelcast

License:

  Apache 2 License

Hazelcast is a clustering and highly scalable data distribution platform
for Java.

With its various distributed data structures, distributed caching
capabilities, elastic nature, memcache support, integration with Spring
and Hibernate and more importantly with so many happy users, Hazelcast
is feature-rich, enterprise-ready and developer-friendly in-memory data
grid solution.
Features:

Distributed implementations of java.util.{Queue, Set, List, Map}
Distributed implementation of java.util.concurrency.locks.Lock
Distributed implementation of java.util.concurrent.ExecutorService
Distributed MultiMap for one-to-many relationships
Distributed Topic for publish/subscribe messaging
Synchronous (write-through) and asynchronous (write-behind) persistence
Transaction support
Socket level encryption support for secure clusters
Second level cache provider for Hibernate
Monitoring and management of the cluster via JMX
Dynamic HTTP session clustering
Support for cluster info and membership events
Dynamic discovery, scaling, partitioning with backups and fail-over


-- 
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/5357f6bb.1000...@pocock.pro

Bug#745656: are binary-indep -dev packages really worth the space savings?

[Matthias Klose]

Package: general
Severity: important

looking at recent GCC uploads, I see install ability problems for the build
dependencies for GCC packages (triggered by libgcj build dependencies, gtk+2.0).
 I can't think of any value besides some minor space savings to have -dev
packages to be architecture independent.   If you really need some newer -dev
version you should be able to do this with an updated build dependency.

A source upload for a library always requires a rebuild on any architecture, so
there is no buildd time savings to make the -dev package architecture 
independent.

So why are people trying to optimize for space instead of turn-around-time?


-- 
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/53581c80.30...@debian.org

Re: About a mass bug report not based on Sid or Jessie.

[manuel . montezelo]

2014-04-22 22:37 Santiago Vila:

Back in the early kfreebsd-* days, there was a server called
ftp.gnuab.org where every kind of hack was allowed in the source to
make packages build. Moreover, we could make NMUs at will without
having to ask the maintainer for permission, because they were for
the "unreleased" distribution. This allowed config.{guess,sub} and
similar bugs to be fixed quickly (at least in a temporary way).

Have things changed such at lot since then for new ports? How are they
made now?


I don't know if Wookey is doing something different with the help of the
mythical hardware, but I am using a quasi-mythical Qemu instead, poor man's
mythical hardware substitute.

But we are doing basically what you say for OpenRISC/or1k port, yes.

I do not understand your question very well, though.  We have packages compiled
in our repositories with config.{guess,sub} and maybe disabling a
build-dependency here, or with empty documentation there, and it's fine.  But
what after that?

Having 20k+ source packages and going through hundreds/thousands with outdated
config.*, and requesting them to update those files just for the set of ports
this year (when there are new ports every year), is not very scalable or
efficient -- even if maintainers acted so quickly as you did.  Or upload source
NMUs -- I think that much bigger number now than the 200 that you mention in
kfreebsd time.


Basically, as discussed elsewhere in the thread, if we don't do something to
solve this in the packages themselves, we are condemned to repeat this work
forever, so if there's a way to put a stop to it, it would be great.  Thanks to
all people participating in the thread for the suggestions.


On a personal note, I think that it is sad that something like autotools, which
was devised as a way to write portable code and so on, is one of the major
hindrances when it comes to create new Debian ports (at least, that's what I am
experiencing).

I completely agree with you, when you said in a previous message that this is a
serious design flaw.


Cheers.
--
Manuel


--
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/20140423210116.gb4...@lugh.itsari.org

Bug#745673: ITP: wheel -- PEP 427-based built-package format for Python

[Barry Warsaw]

Package: wnpp
Severity: wishlist
Owner: Barry Warsaw 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: wheel
  Version : 0.23.0
  Upstream Author : Daniel Holth 
* URL : http://wheel.readthedocs.org/en/latest/
* License : Expat/MIT
  Programming Lang: Python
  Description : PEP 427-based built-package format for Python

A wheel is a ZIP-format archive with a specially formatted filename
and the .whl extension.  It is designed to contain all the files for a
PEP 376 compatible install in a way that is very close to the on-disk
format.  Many packages will be properly installed with only the
“Unpack” step (simply extracting the file onto sys.path), and the
unpacked archive preserves enough information to “Spread” (copy data
and scripts to their final locations) at any later time.

The wheel project provides a bdist_wheel command for setuptools. 

This package will be team maintained by the Debian Python Modules Team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJTWESlAAoJEBJutWOnSwa/XWUQAKBv87yqSQ7n8PfenfNNQlbp
BAtbP+nmFTost7t1Ooc2/k5EEkEH70yWqqEWw6bTWHCHRJiC62rT4iy1h1+LKX8T
natPvzYlSwodiO0szFj3+RgRZWgIBjoRF1ZOto5CfcaajXC46sQGrvoVVaoHWC0j
YCB74U3KV60zL3wxuCatBI/gYMS5GnFpr6lZmdS/HlYgS2Rk8nSh9SZIKBK8uInJ
v+OwA3XEGfwYckq6VpFC5Tm+GLPsEaCaYm3JzW4T9lx3L0Hv1i6BsyUDp53hDv54
/g1COu4B9f+A6AAPfwtzm3fwj8znUwj9/xluYZPhDE13fAjbKsVGs2tyf3drs/aL
z7bYAGD0azvnBDXkmBOwY2z5BNf643dTqtUIg58en8FicEJ/Gb9vfeowN/Yvmd+w
8pTCDIoeFQRQIN4I1pXyPuJs2sbpVGaO+xCUh6vuTlt10IXsQo5S0+PKeB7MJKxk
6HWkTjO20InXXbxWeJY7hK3MtOrCBf1XzxJfq1JBrptUO7mjksQxfygXDHbLlRKD
pVGn0/hlGcQZzOttQ2K4pkKyRJgAevkMDfStpUzqsbt93GGT9014m3WmUm9OE98i
KgWMpWGjDCsNfBISYknA+SAsaTUbmaH6gesVHXuGS2aOX/uFNj2nB/SwC8NDBICG
h00Kyii3ngcwZm4rHBTO
=KFyP
-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/20140423225432.2517.5700.report...@chemistry.wooz.org

goals for hardening Debian: ideas and help wanted

[Paul Wise]

Hi all,

I have written a non-exhaustive list of goals for hardening the Debian
distribution, the Debian project and computer systems of the Debian
project, contributors and users.

https://wiki.debian.org/Hardening/Goals

If you have more ideas, please add them to the wiki page.

If you have more information, please add it to the wiki page.

If you would like to help, please choose an item and start work.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: goals for hardening Debian: ideas and help wanted

[Cameron Norman]

El Wed, 23 de Apr 2014 a las 7:57 PM, Paul Wise  
escribió:

Hi all,

I have written a non-exhaustive list of goals for hardening the Debian
distribution, the Debian project and computer systems of the Debian
project, contributors and users.

https://wiki.debian.org/Hardening/Goals

If you have more ideas, please add them to the wiki page.

If you have more information, please add it to the wiki page.

If you would like to help, please choose an item and start work.



Would the inclusion of more AppArmor profiles be applicable?

Thanks,
--
Cameron Norman

Re: goals for hardening Debian: ideas and help wanted

[Paul Wise]

On Thu, 2014-04-24 at 02:53 -0007, Cameron Norman wrote:

> Would the inclusion of more AppArmor profiles be applicable?

Thanks, added along with SELinux/etc.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: goals for hardening Debian: ideas and help wanted

[Jean-Baptiste Boisseau]

2014-04-24 4:57 GMT+02:00 Paul Wise :

> Hi all,
>
> I have written a non-exhaustive list of goals for hardening the Debian
> distribution, the Debian project and computer systems of the Debian
> project, contributors and users.
>
> https://wiki.debian.org/Hardening/Goals
>
> If you have more ideas, please add them to the wiki page.
>
> If you have more information, please add it to the wiki page.
>
> If you would like to help, please choose an item and start work.
>
> --
> bye,
> pabs
>
> http://wiki.debian.org/PaulWise
>

What about challenging a bit more default packages regarding
security/feature ? We had such a debate about exim but I guess we could
have the same about bind and much more.

-- 
Cordialement,

Jean-Baptiste Boisseau
Eutech SSII
Tel : +33 3 25 81 29 65
Mob: +33 6 63 11 79 40
Fax : +33 9 56 21 06 96

Re: automatically maintaining/tracking repackaged upstream tarballs

[Bastien ROUCARIES]

Le 23 avr. 2014 16:10, "Gunnar Wolf"  a écrit :
>
> Paul Wise dijo [Wed, Apr 23, 2014 at 07:09:53AM +0800]:
> > > Given all the recent issues with popular packages containing minified
> > > JavaScript and other sourceless files, I'm hoping to get feedback from
> > > people about how the solution can be generalized to help as many
> > > developers as possible.
> >
> > You may have missed the fact that uscan now supports removing files
> > specified by the Files-Excluded field in debian/copyright when it
> > repacks archives.
>
> Just note that, in order for Files-Excluded to work, you have to
> declare the current version of the copyright format. Some days ago, I
> had quite a bit of head scratching after I added this header to
> Collabtive¹, only to find I was using still the DEP5 version instead
> of the 1.0 Copyright Format version².
>
> (hint: I'd have rather appreciated uscan or lintian to tell me, "it
> seems you want to do something, but I prefer not to interpret you
> unless I'm sure)

Please report a bug against Lintian.
>
>
> ¹
http://anonscm.debian.org/gitweb/?p=collab-maint/collabtive.git;a=blobdiff;f=debian/copyright;h=eaee1b11fc099cadaa71484ffc501f7e84403aa8;hp=03d8473ee1d9ded60d036bbb11a4ef155836672f;hb=e17be66192df19836c0f255adb31cf72f0ac9cbd;hpb=4036925713d23ee6d42a5b9cf9925333ee4d9d9a
> ²
http://anonscm.debian.org/gitweb/?p=collab-maint/collabtive.git;a=blobdiff;f=debian/copyright;h=0794435d3875c6ed21ccb678f0e82e667db67e3d;hp=eaee1b11fc099cadaa71484ffc501f7e84403aa8;hb=4827cce4b98c38779d61855da371857693c8df50;hpb=e17be66192df19836c0f255adb31cf72f0ac9cbd
>
>
> --
> 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/20140423141016.ga21...@gwolf.org
>