Re: build profile proposal: nogir (second try)

On Wed, Jan 24, 2024 at 06:30:02PM +, Alberto Garcia wrote: > - Are packages that ship gobject-introspection files supposed to have >in the relevant build dependencies (gir1.2-*-dev, > gobject-introspection ?), or is the build profile handling this > automatically? This is not automati

Re: build profile proposal: nogir (second try)

As Johannes mentioned earlier in this thread, the first piece of practical advice on nogir should be: if you don't know that you need to use it, then perhaps you shouldn't. It's primarily aimed at breaking cycles, and enabling buildability in lower-level packages during bootstrapping. (Having said

Re: build profile proposal: nogir (second try)

On Wed, Jan 17, 2024 at 10:00:35PM +, Simon McVittie wrote: > Here is the draft text that I added to the GObject-Introspection > mini-policy in 1.78.1-11: Hi, thanks for the explanation. A couple of questions about this: - Are packages that ship gobject-introspection files supposed to have

Re: build profile proposal: nogir (second try)

Hi Simon, On Sun, Jan 21, 2024 at 03:24:25PM +, Simon McVittie wrote: > > How annoying would it actually be to split this to a > > different source package? > > Really quite annoying. [...] You gave more than sufficient reason. I won't argue. > If porters are interested in making bootstrap

Re: build profile proposal: nogir (second try)

On Thu, 18 Jan 2024 at 11:08:30 +0100, Helmut Grohne wrote: > On Wed, Jan 17, 2024 at 11:38:09PM +, Simon McVittie wrote: > > The only package where I'm sure that I intend to separate out the GIR > > XML in the short term is src:glib2.0 > > How annoying would it actually be to split this to a

Re: build profile proposal: nogir (second try)

On Wed, Jan 17, 2024 at 11:38:09PM +, Simon McVittie wrote: > On Wed, 17 Jan 2024 at 23:15:03 +0100, Matthias Geiger wrote: > > Does this mean we should should split out the .gir XML files from existing > > source packages into a separate gir1.2-foo-dev (in the long run) ? > > That's a good qu

Re: build profile proposal: nogir (second try)

Hi, On 2024-01-18 00:38, Simon McVittie wrote: On Wed, 17 Jan 2024 at 23:15:03 +0100, Matthias Geiger wrote: Am 17.01.24 um 23:00 schrieb Simon McVittie: > Public GIR XML (Foo-1.gir) is normally in the -dev package alongside the > C headers, but recent versions of gobject-introspection define a

Re: build profile proposal: nogir (second try)

On Wed, 17 Jan 2024 at 23:15:03 +0100, Matthias Geiger wrote: > Am 17.01.24 um 23:00 schrieb Simon McVittie: > > Public GIR XML (Foo-1.gir) is normally in the -dev package alongside the > > C headers, but recent versions of gobject-introspection define a canonical > > virtual package name gir1.2-fo

Re: build profile proposal: nogir (second try)

Am 17.01.24 um 23:00 schrieb Simon McVittie: Last year, Helmut Grohne proposed a nogir build profile to help with cross-compiling the GLib ecosystem: . After some discussion on #1030223, I have a revised proposal, with the same name but

Re: build profile proposal: nogir

Hi Simon, On Mon, Apr 17, 2023 at 04:17:10PM +0100, Simon McVittie wrote: > Unfortunately, I don't think this profile as stated will be practically > useful, so I object to its addition on behalf of the GNOME team. I would > support its addition if it was practically useful, but in the current > s

Re: build profile proposal: nogir

On Sun, 16 Apr 2023 at 13:22:57 +0200, Helmut Grohne wrote: > when adding new general build profiles, we're supposed to consult with > debian-devel. Thus I propose the "nogir" profile. This profile is > supposed to skip building "gir*" packages containing typelib files. Unfortunately, I don't thin

Re: Build libzstd using cmake; add a non-cmake build profile?

On Mon, Dec 26, 2022 at 04:35:09PM +, Simon McVittie wrote: > On Mon, 26 Dec 2022 at 14:00:31 +0100, Andrea Pappacoda wrote: > > or patch zstd's makefiles to install a small Find > > module itself (this is not really a good practice, as ideally upstreams > > should install CMake Config files, b

Re: Build libzstd using cmake; add a non-cmake build profile?

Hi Timo, On Mon, Dec 26, 2022 at 10:08:18AM +0100, Timo Röhling wrote: > I appreciate your concern for the implications for the Debian > ecosystem as a whole; in this particular case, I believe I can put > your mind at ease: cmake has a bootstrap profile already, because > dependency loops have co

Re: Build libzstd using cmake; add a non-cmake build profile?

On Mon, 26 Dec 2022 at 14:00:31 +0100, Andrea Pappacoda wrote: > or patch zstd's makefiles to install a small Find > module itself (this is not really a good practice, as ideally upstreams > should install CMake Config files, but should work nonetheless). If you're considering patching zstd's make

Re: Build libzstd using cmake; add a non-cmake build profile?

On Mon, Dec 26, 2022 at 02:00:31PM +0100, Andrea Pappacoda wrote: > Il giorno lun 26 dic 2022 alle 08:37:51 +02:00:00, Peter Pentchev > ha scritto: > > In #1020403 there is a request to install the CMake build glue for > > the zstd library in its -dev package. I think that this is a good > > idea,

Re: Build libzstd using cmake; add a non-cmake build profile?

Il giorno lun 26 dic 2022 alle 08:37:51 +02:00:00, Peter Pentchev ha scritto: In #1020403 there is a request to install the CMake build glue for the zstd library in its -dev package. I think that this is a good idea, and I have a pretty much ready-for-uploading set of changes that do that. For t

Re: Build libzstd using cmake; add a non-cmake build profile?

* Peter Pentchev [2022-12-26 08:37]: Hi, In #1020403 there is a request to install the CMake build glue for the zstd library in its -dev package. I think that this is a good idea, and I have a pretty much ready-for-uploading set of changes that do that. For the purposes of this discussion I hav

Re: Build libzstd using cmake; add a non-cmake build profile?

On Mon, Dec 26, 2022 at 08:37:51AM +0200, Peter Pentchev wrote: > Hi, > > In #1020403 there is a request to install the CMake build glue for > the zstd library in its -dev package. I think that this is a good > idea, and I have a pretty much ready-for-uploading set of changes > that do that. For t

Re: build-depend on autoconf-archive and rm convenience copy in orig.tar.gz?

On 2022-01-19 11:03:15 -0800, Russ Allbery wrote: > Jonas Smedegaard writes: > > > Thanks for elaborating. > > > The concern is not licensing, but maintenance. It is covered in Debian > > Policy § 4.13: > > https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies > >

Re: build-depend on autoconf-archive and rm convenience copy in orig.tar.gz?

On Wed, 2022-01-19 at 18:43 +0200, Thomas Koch wrote: > My package ships two convenience copies from autoconf-archive in it's > m4 folder. Should I In my experience with libpst, it had embedded copies of Python/boost macros from autoconf-archive that were modified and the modifications hadn't bee

Re: build-depend on autoconf-archive and rm convenience copy in orig.tar.gz?

Jonas Smedegaard writes: > Thanks for elaborating. > The concern is not licensing, but maintenance. It is covered in Debian > Policy § 4.13: > https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies Debian packages should not make use of these convenience copies unle

Re: build-depend on autoconf-archive and rm convenience copy in orig.tar.gz?

Am 19.01.22 um 18:44 schrieb Jonas Smedegaard: Quoting Stefan Weil (2022-01-19 18:07:28) As I wrote in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949119#15 autoconf-archive is not needed for building because the two required files are also provided as part of the Tesseract source tree.

Re: build-depend on autoconf-archive and rm convenience copy in orig.tar.gz?

Quoting Stefan Weil (2022-01-19 18:07:28) > Am 19.01.22 um 17:43 schrieb Thomas Koch: > > > I searched but apparently this has not yet been discussed anywhere below > > lists.debian.org. > > > > My package ships two convenience copies from autoconf-archive in it's m4 > > folder. Should I > > > >

Re: build-depend on autoconf-archive and rm convenience copy in orig.tar.gz?

Am 19.01.22 um 17:43 schrieb Thomas Koch: I searched but apparently this has not yet been discussed anywhere below lists.debian.org. My package ships two convenience copies from autoconf-archive in it's m4 folder. Should I a) leave these files and add the corresponding data to d/copyright or

Re: build-depend on autoconf-archive and rm convenience copy in orig.tar.gz?

Quoting Thomas Koch (2022-01-19 17:43:39) > I searched but apparently this has not yet been discussed anywhere below > lists.debian.org. > > My package ships two convenience copies from autoconf-archive in it's m4 > folder. Should I > > a) leave these files and add the corresponding data to d/c

Re: `Build-Depends` parsing problem for node-* packages

Hi Jonas, Le 17/03/2021 à 18:35, Jonas Smedegaard a écrit : > Hi Arnaud, > > Quoting Arnaud Ferraris (2021-03-17 16:52:38) >> I've been confronted with an issue affecting a number of node-* >> packages (and maybe others): apt is unable to parse the Build-Depends >> field, making `apt build-dep`

Re: `Build-Depends` parsing problem for node-* packages

Hi David, Le 17/03/2021 à 19:22, David Kalnischkies a écrit : > Hi, > > On Wed, Mar 17, 2021 at 04:52:38PM +0100, Arnaud Ferraris wrote: >> I've been confronted with an issue affecting a number of node-* packages >> (and maybe others): apt is unable to parse the Build-Depends field, >> making `ap

Re: `Build-Depends` parsing problem for node-* packages

Hi, On Wed, Mar 17, 2021 at 04:52:38PM +0100, Arnaud Ferraris wrote: > I've been confronted with an issue affecting a number of node-* packages > (and maybe others): apt is unable to parse the Build-Depends field, > making `apt build-dep` effectively unusable with those packages. > > One good exa

Re: `Build-Depends` parsing problem for node-* packages

Hi Arnaud, Quoting Arnaud Ferraris (2021-03-17 16:52:38) > I've been confronted with an issue affecting a number of node-* > packages (and maybe others): apt is unable to parse the Build-Depends > field, making `apt build-dep` effectively unusable with those > packages. You seem to be reportin

Re: Build profile proposal: nocil

08.09.2020 18:58, Helmut Grohne пишет: On Tue, Sep 08, 2020 at 01:35:50PM +0300, Alexander Volkov wrote: This profile could be used to build packages without installing dependencies on mono/cil. Name: nocil Changes content of binary packages: No ("C: N" on the wiki) Changes set of binary packa

Re: Build failure on mips64el

The problem has been solved by a give-back. Thanks to Tobias Frost for his help! On 9/21/20 5:09 PM, Fabian Wolff wrote: > Hi, > > today, I uploaded a new version of the z3 package, but the build > failed on mips64el with an interesting error message [0]: > > [ 56%] Building CXX object > src/

Re: Build profile proposal: nocil

On Tue, Sep 08, 2020 at 01:35:50PM +0300, Alexander Volkov wrote: > This profile could be used to build packages without installing dependencies > on mono/cil. > > Name: nocil > Changes content of binary packages: No ("C: N" on the wiki) > Changes set of binary packages: Yes ("S: Y" on the wiki) >

Re: Build profile proposal: nocil

On Tue, 08 Sep 2020 at 13:35:50 +0300, Alexander Volkov wrote: > Description: Disable CIL (Common Intermediate Language) bindings This seems like a useful profile to have. Perhaps a slightly longer Description with more keywords would give people a better hint about what this means, since the CIL

Re: Build-Depends-If-Available

Package: debian-policy On Sun, Aug 09, 2020 at 06:28:50PM +0100, Barak A. Pearlmutter wrote: > I understand what you're saying, and indeed trying to encode > "Build-Depends-If-Available: foo" as "Build-Depends: foo | something" > is a bad idea from the get-go. After all, foo can have three states

Re: Build-Depends-If-Available

On Sun, 9 Aug 2020 at 19:01, Adrian Bunk wrote: > The number of tools parsing build dependencies or doing dependency > resolution is larger than you might expect. Yeah, I can only imagine. And they're not all in one great big git repo either! That's one reason I thought pushing it into the archit

Re: Build-Depends-If-Available

On Sun, Aug 09, 2020 at 06:28:50PM +0100, Barak A. Pearlmutter wrote: >... > "Build-Depends-If-Available: foo" as "Build-Depends: foo | something" > is a bad idea from the get-go. After all, foo can have three states on > an architecture: installable, unavailable, or > available-but-uninstallable-f

Re: Build-Depends-If-Available

On Sun, 9 Aug 2020 at 17:05, Adrian Bunk wrote: > The pragmatic solution is to list the 3 architectures where julia > currently builds. Okay, thanks for the hints, Adrian. That's what I'll do for now. > The software engineering solution would be a dependency package > julia-or-nothing that depen

Re: Build-Depends-If-Available

Hi, Le dim. 9 août 2020 à 18:16, Simon McVittie a écrit : > Unfortunately, to the best of my knowledge, this is currently the least bad > thing to do. > if the current practices/software doesn't give enough leeway, perhaps we should seek to improve the situation. How would that fly if there we

Re: Build-Depends-If-Available

On Sun, Aug 09, 2020 at 03:22:20PM +0100, Barak A. Pearlmutter wrote: > I'm maintaining mlpack. It is able to generate julia bindings, so on > architectures in which julia is available I'd like to generate julia > bindings, and this requires julia to be installed at build time. I've > set up debian

Re: Build-Depends-If-Available

On Sun, 09 Aug 2020 at 15:22:20 +0100, Barak A. Pearlmutter wrote: > I could check which architectures have julia, and which have clang, > and list them. > > Build-Depends: julia [amd64 arm64 i386 ...], clang [amd64 arm64 armel > armhf i386 ...] > > but that makes my skin crawl because it is high

Re: Build-Depends-If-Available

On Sun, Aug 09, 2020 at 03:22:20PM +0100, Barak A. Pearlmutter wrote: > I'm maintaining mlpack. It is able to generate julia bindings, so on > architectures in which julia is available I'd like to generate julia > bindings, and this requires julia to be installed at build time. I've > set up debian

Re: build profiles and functional differences

On Tue, 09 Jan 2018 at 22:47:07 +0100, Johannes Schauer wrote: > As by policy §12.3, removing (or changing) content from > /usr/share/doc should always be fine: > > | Packages must not require the existence of any files in /usr/share/doc/ in > | order to function. > > So by that logic gtk-doc d

Re: build profiles and functional differences

Quoting Simon McVittie (2018-01-09 17:42:04) > On Tue, 09 Jan 2018 at 15:40:04 +, Wookey wrote: > > On 2018-01-09 15:07 +0100, Johannes Schauer wrote: > > > Thus, we keep packages built with a different build profile but the same > > > name/version/arcitecture bit-by-bit identical to each other

Re: build profiles and functional differences

On Tue, 09 Jan 2018 at 15:40:04 +, Wookey wrote: > On 2018-01-09 15:07 +0100, Johannes Schauer wrote: > > Thus, we keep packages built with a different build profile but the same > > name/version/arcitecture bit-by-bit identical to each other. > > However we do have 'nodoc', which can't possib

Re: build 2 similar binary packages from one source tree

On Sun, Dec 24, 2017 at 08:16:19PM +0100, Adam Borowski wrote: > While autotools in principle do support out-of-tree builds, a particular > program might still fail. In practice, this is rare, unless the developer doesn't try to run "make distcheck" before a build (like they really really should).

Re: build 2 similar binary packages from one source tree

Osamu Aoki writes: > maildrop source tree can be build with different build option to produce > maildrop program in 2 ways for each arch. > * set GID mail without restricted caller (maildrop) > * set UID root with restricted caller for courier-mta >(maildrop-courier) -- This is now missing

Re: build 2 similar binary packages from one source tree

Hi Osamu, On Mon, Dec 25, 2017 at 01:43:13AM +0900, Osamu Aoki wrote: > Any pointer to a simple example which uses autotools as its build script > is appreciated. The rxvt-unicode source package generates three binary packages, each containing a version of rxvt-unicode built with different config

Re: build 2 similar binary packages from one source tree

On Mon, Dec 25, 2017 at 01:43:13AM +0900, Osamu Aoki wrote: > maildrop source tree can be build with different build option to produce > maildrop program in 2 ways for each arch. > > * set GID mail without restricted caller (maildrop) > * set UID root with restricted caller for courier-mta >

Re: build 2 similar binary packages from one source tree

On Mon, 25 Dec 2017 at 01:43:13 +0900, Osamu Aoki wrote: > Of course we can build 2 source packages to do this. But is there any > easy clean way to do [two builds with different options] without making > 2 source packages with identical upstream tarball. > > Any pointer to a simple example which

Re: build* targets as root

On Wed, 2017-10-18 at 11:30:29 +0100, Simon McVittie wrote: > On Wed, 18 Oct 2017 at 11:36:41 +0200, Guillem Jover wrote: > > Apparently this caused mass build failures, all due to packages (or > > their helpers) being very Debian policy non-compliant! These are all > > MUST requirements. Stuff lik

Re: build* targets as root

(Changing subject line because I think this is a semi-separate issue) On Wed, 18 Oct 2017 at 11:36:41 +0200, Guillem Jover wrote: > Apparently this caused mass build failures, all due to packages (or > their helpers) being very Debian policy non-compliant! These are all > MUST requirements. Stuff

Re: Build a sort-of-systemd-dependent package on kfreebsd

On 08/11/16 16:05, Samuel Thibault wrote: Jens Reyer, on Tue 08 Nov 2016 15:31:00 +0100, wrote: The dh-exec-filter manpage should help. I assume you want something like: debian/install: #! /usr/bin/dh-exec [!kfreebsd-any] debian/some-linux-only-file /usr/lib/my-package For linuxish things,

Re: Build a sort-of-systemd-dependent package on kfreebsd

Thibaut Paumard, on Tue 08 Nov 2016 15:50:01 +0100, wrote: > Le 08/11/2016 à 15:13, Alec Leamas a écrit : > > Trying to understand the debhelper, dh-exec and dh-exec-subst > > manpages. However, I just don't get it. All these tools seems to > > be about changing the actual location of certain fil

Re: Build a sort-of-systemd-dependent package on kfreebsd

On 08/11/16 15:50, Thibaut Paumard wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 08/11/2016 à 15:13, Alec Leamas a écrit : Trying to understand the debhelper, dh-exec and dh-exec-subst manpages. However, I just don't get it. All these tools seems to be about changing the actual

Re: Build a sort-of-systemd-dependent package on kfreebsd

Jens Reyer, on Tue 08 Nov 2016 15:31:00 +0100, wrote: > The dh-exec-filter manpage should help. I assume you want something like: > > debian/install: > #! /usr/bin/dh-exec > [!kfreebsd-any] debian/some-linux-only-file /usr/lib/my-package For linuxish things, please use [linux-any] debian/some-li

Re: Build a sort-of-systemd-dependent package on kfreebsd

On 08/11/16 15:40, Christian Seiler wrote: However, my need is to actually *remove* some files from e. g., debian/install since they are not built on kfreebsd. How could I do this? cat > debian/$FOO.install < OK, got it. Thanks! That said, if you're using dh-systemd, that shouldn't be nece

Re: Build a sort-of-systemd-dependent package on kfreebsd

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 08/11/2016 à 15:13, Alec Leamas a écrit : > > Trying to understand the debhelper, dh-exec and dh-exec-subst > manpages. However, I just don't get it. All these tools seems to > be about changing the actual location of certain files by > substi

Re: Build a sort-of-systemd-dependent package on kfreebsd

> However, my need is to actually *remove* some files from e. g., > debian/install since they are not built on kfreebsd. How could I do > this? cat > debian/$FOO.install <

Re: Build a sort-of-systemd-dependent package on kfreebsd

On 08.11.2016 15:13, Alec Leamas wrote: > > > > On 08/11/16 14:56, Jens Reyer wrote: > >> Hi Alec [answering on debian-mentor > > Hi Jens! thanks for reply! We are in cross-posting hell... redirecting > to debian-devel Yup, but I agree with Henrique that mentors would've been the right list,

Re: Build a sort-of-systemd-dependent package on kfreebsd

Am 08.11.2016 um 14:48 schrieb Vincent Danjean: > DEB_HOST_ARCH_OS:=$(shell dpkg-architecture -qDEB_HOST_ARCH_OS) dpkg-dev includes some ready to use makefile snippets which you can include like include /usr/share/dpkg/architecture.mk to just get DEB_HOST_ARCH_OS etc, or include /usr/share/dpk

Re: Build a sort-of-systemd-dependent package on kfreebsd

On 08/11/16 15:31, Jens Reyer wrote: On 08.11.2016 15:13, Alec Leamas wrote: On 08/11/16 14:56, Jens Reyer wrote: Hi Alec [answering on debian-mentor Hi Jens! thanks for reply! We are in cross-posting hell... redirecting to debian-devel Yup, but I agree with Henrique that mentors woul

Re: Build a sort-of-systemd-dependent package on kfreebsd

On 08/11/16 14:56, Jens Reyer wrote: Hi Alec [answering on debian-mentor Hi Jens! thanks for reply! We are in cross-posting hell... redirecting to debian-devel On 08.11.2016 13:39, Alec Leamas wrote: In particular: - How can I handle that kfreebsd should install a different set of f

Re: Build a sort-of-systemd-dependent package on kfreebsd

On 08/11/16 14:48, Vincent Danjean wrote: Hi, Le 08/11/2016 à 13:39, Alec Leamas a écrit : I'm now trying to wrap my head around how to conditionalize a packet such as lirc. I'm coming from Fedora/RPM and used to just spread some %ifarch in the spec file. Now, is something similar possible

Re: Build a sort-of-systemd-dependent package on kfreebsd

Hi, Le 08/11/2016 à 13:39, Alec Leamas a écrit : > I'm now trying to wrap my head around how to conditionalize a packet such as > lirc. I'm coming from Fedora/RPM and used to just spread some > %ifarch in the spec file. Now, is something similar possible in debian? It should be. Here are some

Re: Build a sort-of-systemd-dependent package on kfreebsd

On 08/11/16 14:13, Henrique de Moraes Holschuh wrote: On Tue, Nov 8, 2016, at 10:39, Alec Leamas wrote: I'm now trying to wrap my head around how to conditionalize a packet such as lirc. I'm coming from Fedora/RPM and used to just spread some %ifarch in the spec file. Now, is something similar

Re: Build a sort-of-systemd-dependent package on kfreebsd

On Tue, Nov 8, 2016, at 10:39, Alec Leamas wrote: > I'm now trying to wrap my head around how to conditionalize a packet > such as lirc. I'm coming from Fedora/RPM and used to just spread some > %ifarch in the spec file. Now, is something similar possible in debian? It should be possible, yes. I

Re: Build depend on version range?

On Tue, Feb 23, 2016 at 03:53:54PM -0800, Nikolaus Rath wrote: > Is there a way to build-depend on a range of versions (e.g. newer than > 0.43, but older than 1.0)? [...] > What's the best practice here? Would listing the package twice, i.e. > > | Build-Depends: foo (>= 0.43), foo (<< 1.0) > > ha

Re: build own web-gui

> Use simple Auth should be fine usingHtaccess I and thanks for the reply webmin does not use apache with auth I need build something like it Thanks! Pol -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.de

Re: build warnings treated as failures

On Wed, Aug 07, 2013 at 09:07:48PM +0100, Neil Williams wrote: > On Wed, 07 Aug 2013 22:01:33 +0530 > Ritesh Raj Sarraf wrote: > > > Taking this topic forward, I also reached out to upstream folks, > > asking them to fix these build errors on various architectures. > > > > I already did an uploa

Re: build warnings treated as failures

On Wed, 07 Aug 2013 22:01:33 +0530 Ritesh Raj Sarraf wrote: > Taking this topic forward, I also reached out to upstream folks, > asking them to fix these build errors on various architectures. > > I already did an upload of -3 and -4 to experimental. And I still see > newer build failures poppin

Re: build warnings treated as failures

Taking this topic forward, I also reached out to upstream folks, asking them to fix these build errors on various architectures. I already did an upload of -3 and -4 to experimental. And I still see newer build failures popping up. My question to rest of the folks: How do you guys cope up with fo

Re: build warnings treated as failures

On Wednesday 17 July 2013 11:03 PM, Guillem Jover wrote: >> > >> > See configure.ac in your package: >> > >> > AM_INIT_AUTOMAKE([-Wall -Werror foreign]) > Actually, those are automake options dealing with automake warnings. > The culprit here is in Makefile.am (AM_CFLAGS). > Yes. Thanks Guille

Re: build warnings treated as failures

On Wednesday 17 July 2013 10:45 PM, Samuel Thibault wrote: > See configure.ac in your package: > > AM_INIT_AUTOMAKE([-Wall -Werror foreign]) > > You probably want to remove -Werror and tell upstream that it's not so > good an idea. > > That being said, the warnings at stake do produce a bug: %lx

Re: build warnings treated as failures

On Wed, 2013-07-17 at 19:15:42 +0200, Samuel Thibault wrote: > Ritesh Raj Sarraf, le Wed 17 Jul 2013 22:38:51 +0530, a écrit : > > I see a sudden surge of build failures against my latest upload of > > packages[1]. From the build logs, it looks like all warnings are treated > > as errors now. > >

Re: build warnings treated as failures

Ritesh Raj Sarraf, le Wed 17 Jul 2013 22:38:51 +0530, a écrit : > I see a sudden surge of build failures against my latest upload of > packages[1]. From the build logs, it looks like all warnings are treated > as errors now. > > If that is the case, I would like to know how others are dealing with

Re: build-time testing of pure arch:all packages

On 22/06/12 19:23, Goswin von Brederlow wrote: > Yaroslav Halchenko writes: > >> On Fri, 22 Jun 2012, Goswin von Brederlow wrote: archive-wide rebuilds of arch:all packages as we routinely do rebuilds of arch:any packages. (Cc:-ing Lucas, for his great work on QA rebuilds.) >>> Are

Re: build-time testing of pure arch:all packages

Yaroslav Halchenko writes: > On Fri, 22 Jun 2012, Goswin von Brederlow wrote: >> > archive-wide rebuilds of arch:all packages as we routinely do rebuilds >> > of arch:any packages. >> > (Cc:-ing Lucas, for his great work on QA rebuilds.) >> Are archive wide rebuilds done on anythiong but i386/amd

Re: build-time testing of pure arch:all packages

On Fri, 22 Jun 2012, Goswin von Brederlow wrote: > >> I was thinking about a bit more automated way... ideally (in the long > >> run) even that FTBFS (e.g. due to failed tests or some other arch > >> specific quirks) would forbid automatic migration to wheezy etc -- > >> kinda full blown benefits

Re: build-time testing of pure arch:all packages

On 22/06/12 at 10:56 +0200, Goswin von Brederlow wrote: > Are archive wide rebuilds done on anythiong but i386/amd64? A long time ago, I played with archive rebuilds inside qemu for mips or mipsel. It is probably doable, but needs someone to do the work. Lucas -- To UNSUBSCRIBE, email to debia

Re: build-time testing of pure arch:all packages

Hi, On 22/06/12 at 09:37 +0200, Stefano Zacchiroli wrote: > On Fri, Jun 22, 2012 at 12:29:48AM -0400, Yaroslav Halchenko wrote: > > I was thinking about a bit more automated way... ideally (in the long > > run) even that FTBFS (e.g. due to failed tests or some other arch > > specific quirks) would

Re: build-time testing of pure arch:all packages

Stefano Zacchiroli writes: > On Fri, Jun 22, 2012 at 12:29:48AM -0400, Yaroslav Halchenko wrote: >> I was thinking about a bit more automated way... ideally (in the long >> run) even that FTBFS (e.g. due to failed tests or some other arch >> specific quirks) would forbid automatic migration to w

Re: build-time testing of pure arch:all packages

On Fri, Jun 22, 2012 at 12:29:48AM -0400, Yaroslav Halchenko wrote: > I was thinking about a bit more automated way... ideally (in the long > run) even that FTBFS (e.g. due to failed tests or some other arch > specific quirks) would forbid automatic migration to wheezy etc -- > kinda full blown be

Re: build-time testing of pure arch:all packages

On Fri, 22 Jun 2012, Paul Wise wrote: > > I package a few Python modules and enable build-time testing in them for > > at least some QA.  Some of the packages, although being pure Python > > (thus architecture all), deal with data I/O thus prone to bugs related > > to alignment/endianness etc.  

Re: build-time testing of pure arch:all packages

On Fri, Jun 22, 2012 at 1:21 AM, Yaroslav Halchenko wrote: > I package a few Python modules and enable build-time testing in them for > at least some QA.  Some of the packages, although being pure Python > (thus architecture all), deal with data I/O thus prone to bugs related > to alignment/endian

Re: build-time testing of pure arch:all packages

On Thu, Jun 21, 2012 at 01:21:00PM -0400, Yaroslav Halchenko wrote: > I wonder if we have a way to achieve that. I think this is best handled with autopkgtest. See recent efforts to set up Debian infrastructure to use it. -- I wrote a book: http://gtdfh.branchable.com/ signature.asc Descripti

Re: Build environment bug: 675125

Le 19/06/2012 16:20, Alastair McKinstry a écrit : > While i'm still investigating, _something_ in the sid environment is the > real culprit and > I can't assign a bug to it yet until I pin it down. Has anyone seen a > similar issue elsewhere, > or got a hint as to how to handle it? I want to make

Re: Build environment bug: 675125

Hello, On Tue, 19 Jun 2012 15:11:33 -0700 Josh Triplett wrote: > Variables in the .bss section will by definition get initialized to 0. > For example, a C variable defined as "static typename varname;" must > get initialized to 0, and the compiler and linker will stick it in > the .bss section e

Re: Build environment bug: 675125

Andrew Shadura wrote: > By the way, it might be a good idea to fill .bss section with random > values intentionally for debug builds to detect non-properly-initialised > things more effectively :) Variables in the .bss section will by definition get initialized to 0. For example, a C variable defi

Re: Build environment bug: 675125

Hello, On Tue, 19 Jun 2012 23:03:17 +0200 Bernd Zeimetz wrote: > Try gcc/g++ 4.6 instead of 4.7. Maybe check if "S-Lang load > path" (wherever that is stored) is initialized in a sane way. I had a > similar issue where an integer was 0 all the time - although not > being initialized with somethi

Re: Build environment bug: 675125

Hi, > I've an interesting problem: bug #675125. > Its a grave bug against slang2, as it breaks jed, (and other things). > slang2-2.2.14-12+ (in sid) breaks jed for certain locales (C is broken, > *.UTF-8 look fine); > but slang2_2.2.14-10 (in testing) looks fine. > > The trouble is, while downgr

Re: Build error form Ubuntu regarding xz compression

Thanks for clarification 2011/10/19 Colin Watson > On Wed, Oct 19, 2011 at 02:09:47PM +0200, olivier sallou wrote: > > I received an email error from Ubuntu regarding build of a package > > (extracted from debian): > > I'm sorry you received this error; this is a Launchpad bug > (https://bugs.la

Re: Build error form Ubuntu regarding xz compression

On Wed, Oct 19, 2011 at 02:09:47PM +0200, olivier sallou wrote: > I received an email error from Ubuntu regarding build of a package > (extracted from debian): I'm sorry you received this error; this is a Launchpad bug (https://bugs.launchpad.net/launchpad/+bug/876594). We obviously don't want to

Re: Build error form Ubuntu regarding xz compression

olivier sallou wrote: > Rejected: > Require Pre-Depends: dpkg (>= 1.15.6) when using xz compression. > > Package indeed uses xz compression, but do you know what I should put > in package for this on debian side? > > Should I add in debian control a pre-depends on dpkg as said in message? Yes,

Re: build self-contained repository for offline use

Paul Wise writes: > On Wed, Jul 6, 2011 at 10:11 AM, Hamish Moffatt wrote: > >> Thanks all for the replies. I checked out apt-zip, apt-offline, aptoncd, >> CDD and apt-clone. None of them really suited my needs, as I want to >> generate this repository automatically, and want to do a whole class

Re: build self-contained repository for offline use

On Wed, Jul 6, 2011 at 10:11 AM, Hamish Moffatt wrote: > Thanks all for the replies. I checked out apt-zip, apt-offline, aptoncd, > CDD and apt-clone. None of them really suited my needs, as I want to > generate this repository automatically, and want to do a whole class of > target systems which

Re: build self-contained repository for offline use

Am Mittwoch, den 06.07.2011, 04:11 -0400 schrieb Hamish Moffatt: > On Tue, Jul 05, 2011 at 10:52:02PM +0200, Paul Wise wrote: > > One of apt-zip/aptoncd/apt-offline might meet your needs. > > Thanks all for the replies. I checked out apt-zip, apt-offline, aptoncd, > CDD and apt-clone. None of them

Re: build self-contained repository for offline use

On Tue, Jul 05, 2011 at 10:52:02PM +0200, Paul Wise wrote: > One of apt-zip/aptoncd/apt-offline might meet your needs. Thanks all for the replies. I checked out apt-zip, apt-offline, aptoncd, CDD and apt-clone. None of them really suited my needs, as I want to generate this repository automaticall

Re: build self-contained repository for offline use

One of apt-zip/aptoncd/apt-offline might meet your needs. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/caktje6g11sm

Re: build self-contained repository for offline use

On 05/07/2011 09:59, Hamish Moffatt wrote: > I need to build a repository to allow some specified packages to be > installed on computers without internet access. It needs to contain the > specified packages plus any dependencies (new packages and new versions) > from squeeze plus other repositorie

Re: build self-contained repository for offline use

Hamish Moffatt, 2011-07-05 03:59:59 -0400 : > I need to build a repository to allow some specified packages to be > installed on computers without internet access. It needs to contain the > specified packages plus any dependencies (new packages and new versions) > from squeeze plus other repositor

  1   2   3   4   >