Re: Minified javascripts in packages

2015-04-10 Thread Riley Baird
On Fri, 10 Apr 2015 17:44:06 +0200
m...@linux.it (Marco d'Itri) wrote:
> On Apr 10, Thomas Goirand  wrote:
> 
> > To put it simply: no, you should build everything from source, and not
> > using pre-compiled code (yes, minified scripts can be (and actually are)
> > considered as pre-compiled code...).
> You should, but this is not mandatory.
> What is mandatory is being able to rebuild everything from source with 
> tools available in Debian (main), but in some cases there are valid 
> reasons to not do it every time the package is being built.

An example that comes to mind is the firmware-linux-free package. It
would be impractical to rebuild so many toolchains just to make the
package.


pgptFHh6fmIfm.pgp
Description: PGP signature


Bug#782367: ITP: python-psycogreen -- psycopg2 integration with coroutine libraries

2015-04-10 Thread Dmitry Smirnov
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: python-psycogreen
Version: 1.0
Upstream Author: Daniele Varrazzo 
  Copyright: 2010-2012, Daniele Varrazzo
License: BSD-3-clause
URL: https://pypi.python.org/pypi/psycogreen
Vcs-Browser: 
http://anonscm.debian.org/cgit/collab-maint/python-psycogreen.git
Description: psycopg2 integration with coroutine libraries
 This package enables "psycopg2" to work with coroutine libraries, using
 asynchronous calls internally but offering a blocking interface so that
 regular code can run unmodified.

"python-psycogreen" is a dependency of Odoo.

-- 
Cheers,
 Dmitry Smirnov.


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


Re: Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)

2015-04-10 Thread Niels Thykier
On 2015-04-09 09:25, Esokrates wrote:
> On Tuesday, April 07, 2015 10:11:18 PM Niels Thykier wrote:
>> [...]
> 
> So mostly that is more a decision making (political) problem, than a 
> technical 
> one.

It is not entirely clear to me that we any have (major) political issues
IRT ddebs.

People generally seem to be positive (or "worst case" indifferent) to
the idea itself.  There also seem to be agreement about what goes into
the ddebs, where it is placed and they are "just another deb" (etc.).
  As mentioned, the only real concern seem to be whether or not it
should be a ".ddeb" or ".deb".  Though I doubt it is going to be
problematic - if this was truly something people felt for strongly, I am
certain they would have expressed their opinion by now.

> Stretch is a two year time frame though, which makes me kinda sad. Thanks 
> for you effort though, keep up the amazing work! If I understand correctly, 
> if 
> it would have been something for stretch, either A or B would have been 
> decided already and partly implemented, right?

I believe we can implement this for Stretch if we wanted to.  Unlike
multi-arch, build-profiles (etc.), ddebs are already supported by our
(14-days-from-now-new) stable release.  Namely,

 * All the groundwork requirements (pkg:arch dependencies etc.) are
   already covered by previous efforts.
   - I.e. everything that would require a full-cycle for support are
 already done in time for Jessi

 * What we are missing is mostly support from our infrastructure and
   repository tools.  As far as I am informed, the main blockers here
   are:
   - With .ddebs => dak, debhelper
   - With .debs  => dak, debhelper, dpkg-dev
   None of which

 * Known list of tools where support is (very) "nice-to-have", but not a
   strict blocker.
   - lintian - though people on d-mentors might disagree. ;)
   - reprepro and similar
   - others?

 * List of (assumed) "support is completely optional or even
   unnecessary"
   - buildd/sbuild/wanna-build - it should just be a regular build for
 these with debhelper doing the heavy lifting.
   - britney - the ddebs build by debhelper are just as (co-)
 installable as the .deb they are based on.

> I am looking forward to the day, when both reproducible builds and automatic 
> debug package exist, that will be an awesome future! 
> Thanks very much for outlining this, Niels!
> 
> 

I certainly agree!  I cannot take credit for the reproducible builds
though. :)

[Different mail, same sender]:
> 
> Or maybe another question: Will it be ready for sid, soon? Sorry, I am really 
> excited about this.

Good question really.  I can certainly upload a version of debhelper to
unstable that has /opt-in/ support for ddebs when Stretch opens.
However, to have them on the mirror largely depends on when dak gets
support for ddebs.  Unfortunately, I do not have any ETA on that.

Thanks,
~Niels



-- 
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/5528adb6.8050...@thykier.net