Re: Modern Debian packaging system for DevOps: does it exist?

[Jonathan Dowland]

On Thu, May 14, 2015 at 02:57:01PM +0100, Neil Williams wrote:
> Vincent Bernat  wrote:
> >  ❦ 14 mai 2015 14:02 +0100, Neil Williams  :
> > > What is the reason for docker vs chroot, LVM snapshot or VM?
> > 
> > It's hype! ;-)
> 
> So can be ignored. Good. The remaining options are LVM snapshot,
> disposable chroot or a disposable VM. Those can be implemented in any
> number of ways but it needs to be a fresh, clean, predictable start to
> each build.

There is a significant amount of hype around docker, but it's not *all*
hype. It's definitely worth a look. I recall Hubert Chathi posted here
about a tool he wrote around Docker back in late March - in
<87lhiduele@desiato.home.uhoreg.ca>. I have a half-finished reply to
him that I'll dig out and send now.

Docker does a lot of heavy lifting around preserving images, having a
tree of related images, etc. which are very useful for COW related stuff.


-- 
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/20150515071421.ga14...@chew.redmars.org

Re: Modern Debian packaging system for DevOps: does it exist?

[Jonathan Dowland]

On Thu, May 14, 2015 at 11:26:38PM +0200, Vincent Bernat wrote:
>  ❦ 14 mai 2015 17:22 +0300, Исаев Виталий  :
> 
> > Regarding the state of containers after the finish of the build
> > process: we surely don't need them anymore. Every container is used
> > just once and removed after a while. We have docker image with
> > preinstalled compilers and packaging toolchain. All the dependencies
> > are being installed every time from scratch.
> 
> There is almost zero value in this solution with Docker. You have to
> reimplement ccache and package cache.

If you are continually rebuilding a given package, there's a lot of worth in
keeping around a base image which is debian standard + build-essential + the
package build dependencies.


-- 
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/20150515071606.gb14...@chew.redmars.org

Re: ANN: whalebuilder - Debian package builder using Docker

[Jonathan Dowland]

Hi, I wrote the below a while ago but never hit send, sorry.

You may also be interested in the Debian Cloud group (debian-cloud@),
and they might be interested in this tool :-)

On Tue, Mar 31, 2015 at 03:55:09PM -0400, Hubert Chathi wrote:
> I've whipped up a quick script that uses Docker images to build Debian
> packages.  It's basically the same idea as pbuilder/cowbuilder (and was
> inspired by them), but using Docker.
> 
> It's in pretty rough shape still and there's a lot of stuff to do still
> (and lots to learn about Docker and Ruby), but it should be functional
> -- at least enough for other people to bang on it.
> 
> http://www.uhoreg.ca/programming/debian/whalebuilder

Thanks for sharing, I've given it a quick look and here are some
suggestions. 

 • don't use docker's base debian images - they're customised in ways that
   might make package builds 'impure'. I've got some makefiles and dockerfiles
   that one can use to build pristine/unmodified base images at
   .

 • don't install binary package dependencies in the build image by default
   (this might mask a missing build dependency bug)

 • I'd suggest adding --no-install-recommends to apt-get install calls,
   e.g. in Dockerfile.base.erb, to avoid masking a "missing-build-depends"
   bug in source packages (where it relies on a package pulled in from a
   recommendation of a package depended in build-essential)

 • parallel build support (passing DEB_BUILD_OPTIONS through)
   be nice

 • default release should be unstable/sid (since that's the most likely place
   people will be building packages for, normal package lifecycle)


-- 
Jonathan Dowland


-- 
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/20150515071942.ga30...@chew.redmars.org

Re: Modern Debian packaging system for DevOps: does it exist?

[Neil Williams]

On Thu, 14 May 2015 23:25:20 +0200
Vincent Bernat  wrote:

>  ❦ 14 mai 2015 14:57 +0100, Neil Williams  :
> 
> >> More seriously, but this needs some additional work, it should be
> >> easier to manage persistent build dependencies. The first time you
> >> build a package, it retrieves and install all deps. The second
> >> time, the build environment is already here.
> >
> > That's a (serious) bug, not a feature.
> >
> > Either you want clean build environments or you are prepared to
> > build in dirty ones, in which case there's little point using a
> > container at all.
> >
> > A package cache is different, that's what pbuilder uses - that
> > avoids the risk of stale packages being installed, not being
> > updated and breaking the build. Either do it by uninstalling at the
> > end of the build or by using a disposable container (LVM snapshot
> > or pbuilder chroot). At all costs, avoid the false appeal of a
> > dirty container which gets you none of the advantages and all of
> > the problems of building on a developer box with no container at
> > all.
> >
> > Were you thinking of a package cache or a dirty container?
> >
> > Any build system which allows for dependencies of a previous build
> > to exist at the start of the next build is irretrievably broken and
> > unfit for purpose. All you can allow to exist at the start of the
> > build is build-essential.
> 
> For some packages, installing the dependencies can take more time than
> building the package. 

An inevitable cost of building software that has a significant stack of
dependencies. However, each of those dependencies needs to be cleaned
up or the build will generate erroneous binaries.

Use a cache if download speeds are a problem (less likely with modern
network connections).

Use an SSD if installation time is a problem.

> This makes use of pbuilder/cowbuilder quite
> tiresome. If the whole dependencies are already here, this becomes
> more enjoyable.

Short term gain for long term pain. It is not worth it - you may save a
small bit of time now, it can take weeks to work out why buildA works,
buildB fails and buildC works when the fault actually exists in a
dependency which wasn't upgraded ahead of buildB because someone was
as lazy as the writers of the build system.

Never underestimate how much time developers will waste on identifying
that the bug isn't in the code they know but in some broken upgrade of
a dependency which should never have been left behind.

You need to build things as close as possible to how Debian builds
things too - otherwise, bug reports won't make any sense (bug reports
relating to the dependencies, even if you don't put your own code into
Debian).
 
> This is not a dirty container. 

Sorry, it is dirty. It just is. It's dirty in the worst possible manner
- stuff directly relating to the builds you care about is going to end
up out of date or possibly even corrupted by a mis-configured build.
There's nothing "modern" about debugging issues arising from dirty
containers, it's completely unnecessary and a false economy.

There are good reasons why all of the existing packaging systems use
clean environments and either remove all build-dependencies beyond
build-essential or throw away the dirty system and replace with a
fresh snapshot, again with only build-essential installed.

Any new build system which deliberately forgoes these lessons deserves
to be ignored and sent to the a permanent home in /dev/null.

> Only the dependencies needed for the
> packages are retrieved. If the build environment for the package
> doesn't exist, a new environment is created. Old environments are
> removed after a day. Something like that.

A container where the dependencies remain installed is a dirty
container. What happens when there is a transition in one and someone
forgets to update the dependencies to save time?

Pybit arose from just this situation - we had (internal) "time saver"
build software and when it cost us 4 weeks work for 4 developers & 2
testers to find out that a previous build had mangled some of the pango
support files, we swore never to do so again.

Fix your software, if necessary. What we did was split the codebase up
into many smaller packages. Most of these needed many fewer
build-dependencies than the code as a whole. Most of these actually
changed only rarely, so the same build could be tested again and again.
That limited the potential scope of problems to a smaller set of code,
making things much easier to track.

This isn't new, this isn't surprising. What *is* surprising and what
needs to be thrown back in the faces of all those who propose such
lunacy is that the need to be "modern" must NOT involve throwing away
both security and established good practice in a vain attempt at
"convenience". That's entirely and utterly the WRONG way to do things.
Please don't reinvent the problems fixed long, long ago. It won't
bother those who do things properly but it will waste vast amounts of
your time which y

Bug#785355: ITP: node-yawl -- yet another web sockets library

[Andrew Kelley]

Package: wnpp
Severity: wishlist
Owner: Andrew Kelley 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-yawl
  Version : 1.0.2
  Upstream Author : Andrew Kelley 
* URL : https://github.com/andrewrk/node-yawl
* License : Expat
  Programming Lang: JavaScript
  Description : yet another web sockets library

 yawl is a Node.js module which provides an API to create a web socket
server
 and a web socket client. It is RFC 6455 compliant with two exceptions:
 .
 First, it uses Node.js's built in UTF-8 decoding instead of strictly
closing
 the connection when decoding errors occur.
 .
 Second, the "payload length" field is limited to 2 to the power of 52
instead
 of 2 to the power of 64.
 .
 yawl uses streams and handles backpressure correctly. It is a pure
JavaScript
 implementation.
 .
 Node.js is an event-based server-side JavaScript engine.
 .
 I plan to maintain this as part of the Debian JavaScript Maintainers team.
 .
 This is a dependency of groovebasin 1.5.1. Currently groovebasin 1.4.0 is
available in jessie.

Re: Modern Debian packaging system for DevOps: does it exist?

[Jonas Smedegaard]

Quoting Vincent Bernat (2015-05-14 23:25:20)
> ❦ 14 mai 2015 14:57 +0100, Neil Williams  :
>
>>> More seriously, but this needs some additional work, it should be 
>>> easier to manage persistent build dependencies. The first time you 
>>> build a package, it retrieves and install all deps. The second time, 
>>> the build environment is already here.
>>
>> That's a (serious) bug, not a feature.
>>
>> Either you want clean build environments or you are prepared to build 
>> in dirty ones, in which case there's little point using a container 
>> at all.
>>
>> A package cache is different, that's what pbuilder uses - that avoids 
>> the risk of stale packages being installed, not being updated and 
>> breaking the build. Either do it by uninstalling at the end of the 
>> build or by using a disposable container (LVM snapshot or pbuilder 
>> chroot). At all costs, avoid the false appeal of a dirty container 
>> which gets you none of the advantages and all of the problems of 
>> building on a developer box with no container at all.
>>
>> Were you thinking of a package cache or a dirty container?
>>
>> Any build system which allows for dependencies of a previous build to 
>> exist at the start of the next build is irretrievably broken and 
>> unfit for purpose. All you can allow to exist at the start of the 
>> build is build-essential.
>
> For some packages, installing the dependencies can take more time than 
> building the package. This makes use of pbuilder/cowbuilder quite 
> tiresome. If the whole dependencies are already here, this becomes 
> more enjoyable.

For that I use a cowbuilder chroot with those additional packages 
included.  And instead of throwing it away after a day I do an "aptitude 
update; aptitude upgrade", just as I do for core-only chroots.

...and then I avoid using that custom chroot for builds targeted Debian, 
to ensure all build-dependencies are correctly declared.


 - 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: Modern Debian packaging system for DevOps: does it exist?

[Vincent Bernat]

 ❦ 15 mai 2015 08:19 +0100, Neil Williams  :

>> For some packages, installing the dependencies can take more time than
>> building the package. 
>
> An inevitable cost of building software that has a significant stack of
> dependencies. However, each of those dependencies needs to be cleaned
> up or the build will generate erroneous binaries.
>
> Use a cache if download speeds are a problem (less likely with modern
> network connections).

Not a problem.

> Use an SSD if installation time is a problem.

Not a problem either.

A good timesaver is to have libeatmydata or similar. But this is still
slow. For example, the manual page step.

>> This is not a dirty container. 
>
> Sorry, it is dirty. It just is. It's dirty in the worst possible manner
> - stuff directly relating to the builds you care about is going to end
> up out of date or possibly even corrupted by a mis-configured build.
> There's nothing "modern" about debugging issues arising from dirty
> containers, it's completely unnecessary and a false economy.
>
> There are good reasons why all of the existing packaging systems use
> clean environments and either remove all build-dependencies beyond
> build-essential or throw away the dirty system and replace with a
> fresh snapshot, again with only build-essential installed.
>
> Any new build system which deliberately forgoes these lessons deserves
> to be ignored and sent to the a permanent home in /dev/null.

Yeah, sure.

The good reason to replace with a fresh snapshot is that usually, a
package is not rebuilt several times in a row. We just workaround
that. Either we work locally and validate with a pbuilder or we work
directly into a shell spawned by pbuilder or we do something else during
the builds.

Docker is a good framework to introduce the ability to have prepared
build environements for a package:

 1. You have your base image "dockerbuild-sid", rebuilt every night
(either from scratch or using apt-get dist-upgrade from the previous
iteration, exactly like we do now).

 2. When you need to build the package foo, you create the image
"dockerbuild-sid-foo" from "dockerbuild-sid" by installing the build
dependencies.

 3. The real build of the package foo is done in a container based on
the image "dockerbuild-sid-foo". All changes made by in this
container are discarded. The image "dockerbuild-sid-foo" is left
pristine.

 4. Once a day, you clean your intermediate images.

>> Only the dependencies needed for the packages are retrieved. If the
>> build environment for the package doesn't exist, a new environment is
>> created. Old environments are removed after a day. Something like
>> that.
>
> A container where the dependencies remain installed is a dirty
> container. What happens when there is a transition in one and someone
> forgets to update the dependencies to save time?

"Old environments are removed after a day". And also, the problem is
exactly the same with pbuilder and the package cache. Until you update
your base image, you can build in an outdated environment because
pbuilder will find the outdated dependencies in the package cache.
-- 
Watch out for off-by-one errors.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Modern Debian packaging system for DevOps: does it exist?

[Jonathan Dowland]

On Fri, May 15, 2015 at 10:04:35AM +0200, Vincent Bernat wrote:
>  3. The real build of the package foo is done in a container based on
> the image "dockerbuild-sid-foo". All changes made by in this
> container are discarded. The image "dockerbuild-sid-foo" is left
> pristine.

You can also do post-build package validation in this image, or in a child
of this image, installing lintian and its dependencies, etc. (which are not
installed in the build image, of course, in case that masks a dependency
bug in the package you are building). Or perhaps more strictly the post-build
validation should occur in an image which doesn't have the build-dependencies
installed, just the run-time dependencies.

-- 
Jonathan Dowland


-- 
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/20150515081659.gc30...@chew.redmars.org

Re: Modern Debian packaging system for DevOps: does it exist?

[Tollef Fog Heen]

]] Neil Williams 

> > This is not a dirty container. 
> 
> Sorry, it is dirty. It just is. It's dirty in the worst possible manner
> - stuff directly relating to the builds you care about is going to end
> up out of date or possibly even corrupted by a mis-configured build.
> There's nothing "modern" about debugging issues arising from dirty
> containers, it's completely unnecessary and a false economy.

It's no more dirty than a prebuilt tarball or chroot with just required
+ build-essential.  It's not like those never change.

> A container where the dependencies remain installed is a dirty
> container. What happens when there is a transition in one and someone
> forgets to update the dependencies to save time?

Then you have a buggy design.  In such a design you would want to have a
list of correct versions to have installed and any mismatches gets fixed
automatically.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/m2bnhmrp9f@rahvafeir.err.no

Re: Modern Debian packaging system for DevOps: does it exist?

[gregor herrmann]

On Fri, 15 May 2015 10:04:35 +0200, Vincent Bernat wrote:

> A good timesaver is to have libeatmydata or similar. But this is still
> slow. For example, the manual page step.

For pbuilder/cowbuilder I'm using the following hook:

% cat /var/cache/pbuilder/hooks/D10-man-db 
#!/bin/sh
# Don't rebuild man-db

echo "I: Preseed man-db/auto-update to false"
debconf-set-selections 

Re: Modern Debian packaging system for DevOps: does it exist?

[Vincent Bernat]

 ❦ 15 mai 2015 17:57 +0200, gregor herrmann  :

>> A good timesaver is to have libeatmydata or similar. But this is still
>> slow. For example, the manual page step.
>
> For pbuilder/cowbuilder I'm using the following hook:
>
> % cat /var/cache/pbuilder/hooks/D10-man-db 
> #!/bin/sh
> # Don't rebuild man-db
>
> echo "I: Preseed man-db/auto-update to false"
> debconf-set-selections < man-db man-db/auto-update boolean false
> EOF

Great tip! Thanks!
-- 
Take care to branch the right way on equality.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#785408: ITP: cppformat -- fast type-safe C++ formatting library

[Eugene V. Lyubimkin]

Package: wnpp
Severity: wishlist
Owner: "Eugene V. Lyubimkin" 

* Package name: cppformat
  Version : 1.1.0
  Upstream Author : Victor Zverovich 
* URL : http://cppformat.github.io/
* License : BSD 2-clause
  Programming Lang: C++
  Description : fast type-safe C++ formatting library

This library provides fast, type-safe, small, C++11-aware replacement of
(s)printf and related machinery. In some cases it's noticeably faster
than boost::format, boost::lexical_cast and even sprintf itself.
(http://zverovich.net/2013/09/07/integer-to-string-conversion-in-cplusplus.html)

I plan to maintain it myself, unless someone wants to take it under a
bigger umbrella. 


-- 
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/20150515184440.19044.91106.reportbug@debian-w500.Elisa

Re: upgrading to jessie on container with old kernel

[Brian May]

On Thu, 7 May 2015 at 14:43 Brian May 
wrote:

> Looks like my system is still using wheezy/pve which has somewhat old
> packages; will need to change that to wheezy/pve-no-subscription and update
> as soon as I can.
>

So I upgraded my kernel, at first glance it seems a lot healthier. I
noticed there are still some issues:

 root@webby:~# systemctl status proc-sys-fs-binfmt_misc.automount
● proc-sys-fs-binfmt_misc.automount - Arbitrary Executable File Formats
File System Automount Point
   Loaded: loaded (/lib/systemd/system/proc-sys-fs-binfmt_misc.automount;
static)
   Active: failed (Result: resources)
Where: /proc/sys/fs/binfmt_misc
 Docs: https://www.kernel.org/doc/Documentation/binfmt_misc.txt
   http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems


root@webby:~# systemctl status proc-sys-fs-binfmt_misc.automount
● proc-sys-fs-binfmt_misc.automount - Arbitrary Executable File Formats
File System Automount Point
   Loaded: loaded (/lib/systemd/system/proc-sys-fs-binfmt_misc.automount;
static)
   Active: failed (Result: resources)
Where: /proc/sys/fs/binfmt_misc
 Docs: https://www.kernel.org/doc/Documentation/binfmt_misc.txt
 http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems

It provides more information if I attempt a restart:

root@webby:~# systemctl start proc-sys-fs-binfmt_misc.automount
Job for proc-sys-fs-binfmt_misc.automount failed. See 'systemctl status
proc-sys-fs-binfmt_misc.automount' and 'journalctl -xn' for details.
root@webby:~# systemctl status proc-sys-fs-binfmt_misc.automount
● proc-sys-fs-binfmt_misc.automount - Arbitrary Executable File Formats
File System Automount Point
   Loaded: loaded (/lib/systemd/system/proc-sys-fs-binfmt_misc.automount;
static)
   Active: failed (Result: resources)
Where: /proc/sys/fs/binfmt_misc
 Docs: https://www.kernel.org/doc/Documentation/binfmt_misc.txt
   http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems

May 16 11:05:13 webby systemd[1]: Starting Arbitrary Executable File
Formats File System Automount Point.
May 16 11:05:13 webby systemd[1]: Failed to initialize automounter: No such
file or directory
May 16 11:05:13 webby systemd[1]: Failed to set up automount Arbitrary
Executable File Formats File System Automount Point.



root@webby:~# systemctl status vzquota.service


● vzquota.service - LSB: Start vzquota at the end of boot
   Loaded: loaded (/etc/init.d/vzquota)
   Active: failed (Result: exit-code) since Sat 2015-05-16 10:51:29 AEST;
5min ago
  Process: 237 ExecStart=/etc/init.d/vzquota start (code=exited, status=2)

May 16 10:51:29 webby systemd[1]: Starting LSB: Start vzquota at the end of
boot...
May 16 10:51:29 webby vzquota[237]: quotaon: using //aquota.group on
/dev/simfs [/]: Device or resource busy
May 16 10:51:29 webby vzquota[237]: quotaon: using //aquota.user on
/dev/simfs [/]: Device or resource busy
May 16 10:51:29 webby systemd[1]: vzquota.service: control process exited,
code=exited status=2
May 16 10:51:29 webby systemd[1]: Failed to start LSB: Start vzquota at the
end of boot.
May 16 10:51:29 webby systemd[1]: Unit vzquota.service entered failed state.



Doing a Google search on the first suggests that I check autofs4 is
compiled into the kernel; it is:

gyro:~# cat  /boot/config-2.6.32-39-pve  | grep -i autofs
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=m

I even tried manually loading the module, but it didn't help.


Looks like /etc/init.d/vzquota is a script not owned by any package:

root@webby:~# sh -ex /etc/init.d/vzquota start
+ start
+ [ ! -L /etc/mtab ]
+ awk ($2 == "/") && ($4 ~ /usrquota/) && ($4 ~ /grpquota/) {print $1}
/etc/mtab
+ dev=/dev/simfs
+ test -z /dev/simfs
+ [ -e /dev/simfs ]
+ quotaon -aug
quotaon: using //aquota.group on /dev/simfs [/]: Device or resource busy
quotaon: using //aquota.user on /dev/simfs [/]: Device or resource busy


I don't particularly care so much about quota support, however the first
one would suggest that systemd isn't running 100%.

Any ideas?

Heads up: Changes in dpkg-shlibdeps directory search list

[Guillem Jover]

[ Please follow up on d-d and d-cross (M-F-T set). ]

Hi!

There are several cleanups and order changes in the pipe for the default
dpkg-shlibdeps shared library directory search list in dpkg 1.18.x.

It was previously, in decreasing order of preference:

  0. «dpkg-shlibdeps -l» (or via «dh_shlibdeps -l»)
  1. ENV{LD_LIBRARY_PATH} (deprecated)
  2. DEFAULT_LIBRARY_PATH (/lib, /usr/lib)
  3. DEFAULT_MULTILIB_PATH (/lib32, /usr/lib32, /lib64, /usr/lib64,
/emul/ia32-linux/lib, /emul/ia32-linux/usr/lib)
  4. If cross-building or building a cross-compiler:
   cross-multiarch (/lib/, /usr/lib/)
   cross-root (//lib, /usr//lib)
   cross-root-multilib (//lib32, /usr//lib32,
//lib64, /usr//lib64)
  5. ld.so.conf

And will become:

  a. «dpkg-shlibdeps -l» (or via «dh_shlibdeps -l»)
  b. ENV{LD_LIBRARY_PATH} (obsolete)
  c. If cross-building or building a cross-compiler:
   cross-multiarch (/lib/, /usr/lib/)
  d. DEFAULT_LIBRARY_PATH (/lib, /usr/lib)
  e. ld.so.conf
  f. DEFAULT_MULTILIB_PATH (legacy: /lib32, /usr/lib32, /lib64, /usr/lib64)

And the rationale for the changes follows:

* Setting LD_LIBRARY_PATH in debian/rules to specify the local build-tree
  has been obsoleted by «dpkg-shlibdeps -l». That variable is for the
  run-time linker, using is also for the build-time environment mixes
  them up, and does not play nice when cross-building, if you've got a
  package doing that, please switch to use the option -l. I'll request
  a lintian check for this.

* The ancient GCC_TARGET environment variable is not honored anymore,
  this was a way to specify cross-compiler builds, DEB_TARGET_GNU_TYPE
  can always be used for that now.

* The cross-root directories (//lib* and /usr//lib*)
  are not added anymore to the default list when cross-building. These are
  legacy from a pre-multiarch era, no package uploaded to Debian should
  be using these, and having them in the default list is just an accident
  waiting to happen. Of course people using local cross-root setups can
  still use those paths, they will just not be used for *packaged*
  binaries, and if people still want to use these paths to package stuff
  outside of Debian they can still use «dpkg-shlibdeps -l».

* When cross-building the cross-multiarch paths should have precedence
  over the native ones, because that's what we are linking against. In
  theory when cross-building no native paths (b. sometimes, d. and f.)
  should be in the list, as that pollutes it, and I'm pondering about
  doing that, but we might need to keep loading ld.so.conf as foreign
  packages might have added required paths for cross-compiling there…

* The ancient multilib paths (/emul/ia32-linux/lib and
  /emul/ia32-linux/usr/lib) inherited from ia64 are gone now, these
  were transitioned away from in squeeze.

* The legacy multilib paths now have lower precedence than the ld.so.conf
  ones, as proper standard or multiarch paths should be always preferred,
  or programs might end up accidentally depending on multilib packages. In
  the near future I'd like to either remove or hide multilib paths from
  the default list if DPKG_ENABLE_DEPRECATED_MULTILIB=yes is not set in
  the environment (for example), to avoid polluting the default list, and
  because they are pretty much non-exhaustive and do not cover all
  current multilib paths anyway.

Thanks,
Guillem


-- 
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/20150516031504.ga21...@gaara.hadrons.org

Bug#785423: ITP: ca-cacert -- CAcert.org root certificates

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: ca-cacert
Version: 2011.0523
Upstream Author: CAcert.org
License: https://www.cacert.org/policy/RootDistributionLicense.html
URL: https://www.cacert.org/index.php?id=3
Vcs-Browser: http://anonscm.debian.org/cgit/collab-maint/ca-cacert.git
Description: CAcert.org root certificates
 This package provides CAcert.org (sub-)root certificates in PEM format.
 Root certificate allows SSL-based applications to check for the
 authenticity of certificates issued by the CAcert authority.
 .
 CAcert.org is a community-driven Certificate Authority that issues
 certificates to the public for free.
 .
 CAcert's goal is to promote awareness and education on computer security
 through the use of encryption, specifically by providing cryptographic
 certificates. These certificates can be used to digitally sign and encrypt
 email, authenticate and authorize users connecting to websites and secure
 data transmission over the internet. Any application that supports the
 Secure Socket Layer Protocol (SSL or TLS) can make use of certificates
 signed by CAcert, as can any application that uses X.509 certificates,
 e.g. for encryption or code signing and document signatures.
 .
 Please note that Debian can neither confirm nor deny whether CAcert
 have in any way been audited for trustworthiness or RFC 3647 compliance.

-- 
Regards,
 Dmitry Smirnov.


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