Source of shared runners containers used in salsa CI system
Hi I see salsagitlab ci is using docker containers for its shared runners like for instance in https://salsa.debian.org/cloud-team/debian-cloud-images/-/blob/master/.gitlab-ci.yml#L23 How are these containers images built ? I specifically wanted to check if xz-utils is included or not in the debian:buster image. Regards Manu -- You know an upstream is nice when they even accept m68k patches. - John Paul Adrian Glaubitz
Re: DFSG of disk image with contrib package
Le 17/03/2020 à 07:26, Richard Laager a écrit : > On 3/16/20 12:25 PM, Emmanuel Kasper wrote: >> For extended functionality, I build some of the disk images with a >> package from contrib, namely virtualbox-dkms > > Could you use KVM (and if necessary, libvirt) instead? > I do have KVM/libvirt disk images to use with vagrant-libvirt too. But Vagrant with VirtualBox is more popular, as it runs multiplatform, and has an extra shared folder functionality which works as unpriviledged user. vagrant-libvirt requires root rights for the shared folder functionality.
DFSG of disk image with contrib package
Hi I am building debian disk images for the Vagrant tool, distributed at https://app.vagrantup.com/debian/ For extended functionality, I build some of the disk images with a package from contrib, namely virtualbox-dkms Due to having this virtualbox-dkms from contrib, the disk images are labelled "contrib" in the distribution channel. Now virtualbox-dkms is in contrib, because the compiler (openwatcom), needed to compile a *different* part of the virtualbox source package, the BIOS, is not DFSG. Am I right in keeping these disk image as "contrib", or I am overcomplicating by keeping these multiple disk image builds ? Cc involved debian-cloud people and virtualbox maintainer Don't beat to hard, it is my first post on -devel :) Manu
Re: Debian policy recommended snippet prevents building packages from external Makefile
On 04/14/2016 03:27 PM, Jakub Wilk wrote: > * Emmanuel Kasper , 2016-04-14, 13:29: >> in the Debian policy 4.9.1 we recommend to add build flags as such: >> >> MAKEFLAGS += -j$(NUMJOBS) >> >> and I guess most packages, like tar, will then call >> >> $(MAKE) $(MAKEFLAGS) > > You don't need to pass $(MAKEFLAGS) here. > > And, as you noticed, you shouldn't, because it's not always suitable as > arguments for make. > OK thanks for the hint, I am going to investigate this in details. The policy document how to make set the make flags for parallel building, but do not go further shows how to call these flags, so the policy is OK.
Debian policy recommended snippet prevents building packages from external Makefile
Hi
The Problem
~~~
While preparing a backport of GNU tar, I notice that calling
dpkg-buildpackage from an external Makefile errors when we use the
parallel jobs options fails.
A Makefile with something like
do-build:
cd ${EXTRACTED}; dpkg-buildpackage -b -uc -us
does not work.
The Details
~~~
Suppose you have these files
$PWD/Makefile
all:
cd subdir && $(MAKE)
and
$PWD/subdir/Makefile
$(info $(MAKEFLAGS))
if you call make from $PWD you will get an output of w ( this is the
make switch --print-directory is added, I don't know why at the momment)
Now in the Debian policy 4.9.1 we recommend to add build flags as such:
MAKEFLAGS += -j$(NUMJOBS)
and I guess most packages, like tar, will then call
$(MAKE) $(MAKEFLAGS)
now if dpkg-buildpackages is called from a Makefile in a parent folder
w is passed without being prepended a dash, and it will be interpreted
as a target name, causing make to bail out with
RSH="/usr/bin/rsh" CPPFLAGS="`dpkg-buildflags --get CPPFLAGS`"
CFLAGS="`dpkg-buildflags --get CFLAGS` -Wall" \
LDFLAGS="`dpkg-buildflags --get LDFLAGS`" /usr/bin/make w -j
--jobserver-fds=3,4
make[2]: Entering directory '/home/e.kasper/pve/tar/tar-1.28'
make[2]: *** No rule to make target 'w'. Stop.
my workaround at the momment is to override dpkg-buildpackage make
call by doing
cd ${EXTRACTED}; dpkg-buildpackage -b -uc -us -R"$(MAKE)
--no-print-directory -f debian/rules"
So am I missing something here ? are we using MAKEFLAGS in a sane way ?
If you came down to here, thanks for your attention !
Emmanuel
Debian policy recommended snippet prevents building packages from external Makefile
Hi
The Problem
~~~
While preparing a backport of GNU tar, I notice that calling
dpkg-buildpackage from an external Makefile errors when we use the
parallel jobs options fails.
A Makefile with something like
do-build:
cd ${EXTRACTED}; dpkg-buildpackage -b -uc -us
does not work.
The Details
~~~
Suppose you have these files
$PWD/Makefile
all:
cd subdir && $(MAKE)
and
$PWD/subdir/Makefile
$(info $(MAKEFLAGS))
if you call make from $PWD you will get an output of w ( this is the
make switch --print-directory is added, I don't know why at the momment)
Now in the Debian policy 4.9.1 we recommend to add build flags as such:
MAKEFLAGS += -j$(NUMJOBS)
and I guess most packages, like tar, will then call
$(MAKE) $(MAKEFLAGS)
now if dpkg-buildpackages is called from a Makefile in a parent folder
w is passed without being prepended a dash, and it will be interpreted
as a target name, causing make to bail out with
RSH="/usr/bin/rsh" CPPFLAGS="`dpkg-buildflags --get CPPFLAGS`"
CFLAGS="`dpkg-buildflags --get CFLAGS` -Wall" \
LDFLAGS="`dpkg-buildflags --get LDFLAGS`" /usr/bin/make w -j
--jobserver-fds=3,4
make[2]: Entering directory '/home/e.kasper/pve/tar/tar-1.28'
make[2]: *** No rule to make target 'w'. Stop.
my workaround at the momment is to override dpkg-buildpackage make
call by doing
cd ${EXTRACTED}; dpkg-buildpackage -b -uc -us -R"$(MAKE)
--no-print-directory -f debian/rules"
So am I missing something here ? are we using MAKEFLAGS in a sane way ?
If you came down to here, thanks for your attention !
Emmanuel
Re: Need advice about a package installing no files at all
On 2012-09-12 16:04:02 +0200 (+0200), Emmanuel Kasper wrote: >> After doing an upgrade from debian 6 to 7, the packge xmess-sdl is >> list as installed but does not contains any file at all. [...] > According to the package description, xmess-sdl is now a transitional dummy package depending on the new mess package. In fact, the unrelated bug report you linked even mentions that. This is how package renames are generally supposed to work. > In short, what used to be xmess-sdl is now in a package called mess instead. If your upgrade was successful, you should see that package installed too and that should have actual contents. Yes mess gets installed too and have actual content. Maybe I was not clear enough: is it normal that dpkg -L xmess-sdl lists unexisting files after an upgrade ? When I do aptitude reinstall xmess-sdl then the package files are really installed. Manu Ps: I am off-list thanks to CC me for further reply ! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5050a406.3090...@libera.cc
Need advice about a package installing no files at all
Hello After doing an upgrade from debian 6 to 7, the packge xmess-sdl is list as installed but does not contains any file at all. ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685470 ) (s2w)root@dakar:/# dpkg -L xmess-sdl /. /usr /usr/share /usr/share/doc /usr/share/doc/xmess-sdl /usr/share/doc/xmess-sdl/changelog.Debian.gz /usr/share/doc/xmess-sdl/changelog.gz /usr/share/doc/xmess-sdl/copyright (s2w)root@dakar:/# cat /usr/share/doc/xmess-sdl/copyright cat: /usr/share/doc/xmess-sdl/copyright: No such file or directory (s2w)root@dakar:/# I don't see anything suspicious in /var/log/dpkg.log, I have no clues about what could cause that or where to get a debug mode. Where shoud I look for ? Emmanuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50509652.8050...@libera.cc
