On Tue, May 19, 2015 at 10:43:53PM +0200, Stephen Kitt wrote:
>
> > I was always wondering whether I should file a bug report against
> > pbuilder to do exactly this but was not clever enough to know how to
> > propose a patch. Now, since I saved this problem for myself due to this
> > great tip
On 05/19/2015 06:41 AM, Geert Stappers wrote:
On Tue, May 19, 2015 at 01:19:44AM +0200, Thomas Goirand wrote:
On 05/13/2015 06:14 PM, ?? ?? wrote:
At the moment we're trying to collect more information about existing
packaging systems. Our self-written scripts no longer meet
On Tue, 19 May 2015 17:22:06 -0400, James McCoy wrote:
> Why is man-db even installed in a build chroot?
debhelper depends on man-db, so it will get installed for almost all
builds.
Cheers,
gregor
--
.''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
: :' : Debian
On Fri, May 15, 2015 at 10:04:35AM +0200, Vincent Bernat wrote:
> A good timesaver is to have libeatmydata or similar. But this is still
> slow. For example, the manual page step.
Why is man-db even installed in a build chroot?
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy
s
Hi Andreas,
On Tue, 19 May 2015 10:12:57 +0200, Andreas Tille wrote:
> On Fri, May 15, 2015 at 05:57:06PM +0200, gregor herrmann wrote:
> > For pbuilder/cowbuilder I'm using the following hook:
> >
> > % cat /var/cache/pbuilder/hooks/D10-man-db
> > #!/bin/sh
> > # Don't rebuild man-db
> >
> >
Thank you Thomas, I'm going to try it.
--
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/555afbcc.3050...@corp.sputnik.ru
Thank you! I gave it a try, but it failed at the first attempt... Guess
I need to study Jenkins first.
--
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/555afb40.7070.
Hi,
On Fri, May 15, 2015 at 05:57:06PM +0200, gregor herrmann wrote:
>
> 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
On Tue, May 19, 2015 at 01:19:44AM +0200, Thomas Goirand wrote:
> On 05/13/2015 06:14 PM, ?? ?? wrote:
> >At the moment we're trying to collect more information about existing
> >packaging systems. Our self-written scripts no longer meet our needs.
> >Now we have faced a choice:
On 05/13/2015 06:14 PM, Исаев Виталий wrote:
Hello! I'm looking for a convenient wrapper of standard Debian packaging
toolchain in order to automatize the deployment process. We use Ubuntu
and Debian, and the most part of code is written in C++, therefore we
need to compile and build binary debs.
On Mon, 2015-05-18 at 21:57 +0200, Guido Günther wrote:
> On Thu, May 14, 2015 at 11:16:23AM +0200, Tzafrir Cohen wrote:
> > On Wed, May 13, 2015 at 07:14:36PM +0300, Исаев Виталий wrote:
> > > Hello! I'm looking for a convenient wrapper of standard Debian packaging
> > > toolchain in order to auto
On Thu, May 14, 2015 at 11:16:23AM +0200, Tzafrir Cohen wrote:
> On Wed, May 13, 2015 at 07:14:36PM +0300, Исаев Виталий wrote:
> > Hello! I'm looking for a convenient wrapper of standard Debian packaging
> > toolchain in order to automatize the deployment process. We use Ubuntu and
> > Debian, and
❦ 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 rebui
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 rebuil
]] 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 "mode
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
❦ 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
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 sec
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
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 h
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,
>
❦ 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. Al
❦ 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.
Le mercredi 13 mai 2015 à 19:14 +0300, Исаев Виталий a écrit :
> Hello! I'm looking for a convenient wrapper of standard Debian
> packaging toolchain in order to automatize the deployment process. We
> use Ubuntu and Debian, and the most part of code is written in C++,
> therefore we need to compil
Hello Tzafrir, thanks for pointing the mini-buildd. I've never heared
about this tool. Will try to grab more info about it.
Sincerely,
Vitaly Isaev
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Ar
Hi, Neil, thanks for a prompt reply.
I need to clarify our use case indeed. Some of our projects contain both
free and proprietary code. So the "Privacy" feature I mentioned in the
initial message means that packages built from these projects
(currently) is only for internal use. We have priva
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
On Thu, 14 May 2015 15:45:01 +0200
Vincent Bernat wrote:
> ❦ 14 mai 2015 14:02 +0100, Neil Williams :
>
> >> 1. Gitlab;
> >> 2. Isolated build environment inside Docker containers (where we
> >> usually do `git clone && mk-build-deps && debuild`);
> >> 3. Aptly;
> >> 4. Self-written Py
❦ 14 mai 2015 14:02 +0100, Neil Williams :
>> 1. Gitlab;
>> 2. Isolated build environment inside Docker containers (where we
>> usually do `git clone && mk-build-deps && debuild`);
>> 3. Aptly;
>> 4. Self-written Python scripts linking all these components;
>
> What is the reason for doc
On Wed, 13 May 2015 19:14:36 +0300
Исаев Виталий wrote:
> Hello! I'm looking for a convenient wrapper of standard Debian
> packaging toolchain in order to automatize the deployment process.
It would seem to be attainable, but then each use case goes off on a
particular tangent:
> We
> use Ubunt
On Wed, May 13, 2015 at 07:14:36PM +0300, Исаев Виталий wrote:
> Hello! I'm looking for a convenient wrapper of standard Debian packaging
> toolchain in order to automatize the deployment process. We use Ubuntu and
> Debian, and the most part of code is written in C++, therefore we need to
> compil
On Thu, May 14, 2015 at 11:58:36AM +0800, Paul Wise wrote:
> On Thu, May 14, 2015 at 12:14 AM, ?? ?? wrote:
>
> > It seems like none of the well-known open-source solutions (Open Build
> > Service, Launchpad, Travis CI) meets this requirements. Please share how
> > exactly you
On 2015-05-14 09:28, Paul Wise wrote:
On Thu, May 14, 2015 at 12:14 AM, Исаев Виталий wrote:
It seems like none of the well-known open-source solutions (Open Build
Service, Launchpad, Travis CI) meets this requirements. Please share
how
exactly you build deb packages from your projects and wha
On Thu, May 14, 2015 at 12:14 AM, Исаев Виталий wrote:
> It seems like none of the well-known open-source solutions (Open Build
> Service, Launchpad, Travis CI) meets this requirements. Please share how
> exactly you build deb packages from your projects and what tools do you use?
> Any help will
34 matches
Mail list logo
