Re: Bug#1104643: Don't consider tests during build that can use internet if available as rc buggy

El 06/05/25 a las 02:20, Pirate Praveen escribió: > > On 06/05/2025 1:33 am, Bill Allombert wrote: > > On Tue, May 06, 2025 at 01:12:43AM +0530, Pirate Praveen wrote: > > > I think we have to consider test target in rules differently from build > > > targets as th

Re: why is Perl Build-Essential: yes?

Hi, Quoting Jonathan Dowland (2025-05-06 10:51:45) > On Thu May 1, 2025 at 8:37 PM BST, Chris Hofstaedtler wrote: > > Does anything actually _use_ the Build-Essential: yes line? > > I honestly don't know. I've never seen it being used. > I expect so, or the ftp-mast

Re: why is Perl Build-Essential: yes?

On Thu May 1, 2025 at 8:37 PM BST, Chris Hofstaedtler wrote: Does anything actually _use_ the Build-Essential: yes line? I honestly don't know. I expect so, or the ftp-masters wouldn't be adding it to packages. Having it in the control metadata makes it visible to users (apt show

Re: Bug#1104643: Don't consider tests during build that can use internet if available as rc buggy

On 06/05/2025 1:33 am, Bill Allombert wrote: On Tue, May 06, 2025 at 01:12:43AM +0530, Pirate Praveen wrote: I think we have to consider test target in rules differently from build targets as the effect on these on the final binaries we ship is different. I agree the current policy fit well

Re: Bug#1104643: Don't consider tests during build that can use internet if available as rc buggy

On Tue, May 06, 2025 at 01:12:43AM +0530, Pirate Praveen wrote: > I think we have to consider test target in rules differently from build > targets as the effect on these on the final binaries we ship is different. > > I agree the current policy fit well when applied to the build t

Re: Bug#1104643: Don't consider tests during build that can use internet if available as rc buggy

non-free archive with the Autobuild control field unset or set to no, required targets must not attempt network access, except, via the loopback interface, to services on the build host that have been started by the build. I think it should be changed to, Except for packages in the non-free

Re: why is Perl Build-Essential: yes?

* Jonathan Dowland [250428 18:02]: On Mon Apr 28, 2025 at 4:46 PM BST, Sven Joachim wrote: On 2025-04-28 15:57 +0100, Jonathan Dowland wrote: Thanks! For reasons I cannot explain, installing build-essential (in a Salsa CI environment) did not pull in perl. The tag is coming from an FTP

Re: why is Perl Build-Essential: yes?

On Mon Apr 28, 2025 at 4:46 PM BST, Sven Joachim wrote: On 2025-04-28 15:57 +0100, Jonathan Dowland wrote: "apt-cache show perl" lists it as "Build-Essential: yes". But why? It's not in the transitive dependencies of build-essential, It is, dpkg-dev depends on perl:a

Re: why is Perl Build-Essential: yes?

On 2025-04-28 15:57 +0100, Jonathan Dowland wrote: > "apt-cache show perl" lists it as "Build-Essential: yes". But why? It's > not in the transitive dependencies of build-essential, It is, dpkg-dev depends on perl:any. > nor /usr/share/doc/build-essential/

why is Perl Build-Essential: yes?

"apt-cache show perl" lists it as "Build-Essential: yes". But why? It's not in the transitive dependencies of build-essential, nor /usr/share/doc/build-essential/list, and I can't find that header verbatim in Perl's debian/control in the source, nor in the bin

Re: Troubleshooting experimental build - how to replicate the sbuild?

ally use --anything-failed-commands=%s which gives you a shell that > you can use to investigate the build independent of the chroot backend. That was the hint I needed, many thanks. I was able to confirm that the cmake configuration was identical when using the unshare backend. So I sta

Re: Troubleshooting experimental build - how to replicate the sbuild?

dpkg-buildpackage -B Note: I tried that (once) and unfortunately it built ok for me, so maybe it's a makefile bug. You might want to try GNUMAKEFLAGS=--shuffle, which sometimes amplifies the probability that an existing makefile bug manifests itself. If it's a makefile bug, dh --no-parallel mig

Re: Troubleshooting experimental build - how to replicate the sbuild?

Hi. Given that the buildds are able to build the Arch:all packages but not the arch:amd64 packages, the way to reproduce this would be to do this in a regular directory chroot: dpkg-buildpackage -B In particular, I see that debian/rules does different things depending on the type of build

Re: Troubleshooting experimental build - how to replicate the sbuild?

ix now. > > Okay, I don't know how to solve this. The package is uploaded now for > unstable so the --aspcud thing no longer matters. > > Using sbuild --dist=sid --chroot-mode=schroot insighttoolkit5_5.4.3-3.dsc, > the > package will build seemingly

Re: Troubleshooting experimental build - how to replicate the sbuild?

. Using sbuild --dist=sid --chroot-mode=schroot insighttoolkit5_5.4.3-3.dsc, the package will build seemingly fine. Using sbuild --dist=sid --chroot-mode=unshare insighttoolkit5_5.4.3-3.dsc, the errors seen in the buildd logs appear ("error: ‘FFTW_ESTIMATE’ was not declared in this scope&

Re: Troubleshooting experimental build - how to replicate the sbuild?

ow how to solve this. The package is uploaded now for unstable so the --aspcud thing no longer matters. Using sbuild --dist=sid --chroot-mode=schroot insighttoolkit5_5.4.3-3.dsc, the package will build seemingly fine. Using sbuild --dist=sid --chroot-mode=unshare insighttoolkit5_5.4.3-3.dsc, the err

Re: Troubleshooting experimental build - how to replicate the sbuild?

table so the --aspcud thing no longer matters. Using sbuild --dist=sid --chroot-mode=schroot insighttoolkit5_5.4.3-3.dsc, the package will build seemingly fine. Using sbuild --dist=sid --chroot-mode=unshare insighttoolkit5_5.4.3-3.dsc, the errors seen in the buildd logs appear ("erro

Re: Troubleshooting experimental build - how to replicate the sbuild?

On Sunday, April 20, 2025 12:18:28 p.m. Central Daylight Saving Time Otto Kekäläinen wrote: > Hi, > > I am not able to reproduce the test failure visible at > https://buildd.debian.org/status/fetch.php?pkg=insighttoolkit5&arch=amd64&ve > r=5.4.3-2&stamp=1745014062&am

Re: Troubleshooting experimental build - how to replicate the sbuild?

Hi, I am not able to reproduce the test failure visible at https://buildd.debian.org/status/fetch.php?pkg=insighttoolkit5&arch=amd64&ver=5.4.3-2&stamp=1745014062&raw=0 in a local build myself, so I can't help with that. I did however notice that the size of the resulting pack

Re: Troubleshooting experimental build - how to replicate the sbuild?

Hi Steven, Looks like the distribution is being picked up correctly, but you may be missing the aspcud criteria used by the buildd's, see the `--aspcud-criteria` option in [1]. Cheers! [1] https://wiki.debian.org/sbuild#Enabling_experimental

Troubleshooting experimental build - how to replicate the sbuild?

Hi, I recently uploaded a package to experimental and was suprised at the build failures [1]. I have built it locally and on a porter box without issue -- each time using a clean unstable chroot. [1] https://buildd.debian.org/status/fetch.php? pkg=insighttoolkit5&arch=amd64&ver=5.4.3

Bug#1101938: ITP: python-nanoemoji -- build color fonts

: build color fonts A wee tool to build color fonts, including the proposed COLRv1. Relies heavily on Skia via picosvg, as well as resvg to rasterize SVG to PNG for the bitmap color formats.

Bug#1099615: ITP: gitlab-buildpkg-tools -- Build a Gitlab-PPA using GitLab CI

* License : (GPL-2) Programming Lang: (Bash) Description : Build a Gitlab-PPA using GitLab CI Gitlab-buildpkg-tools is a set of tools to build a "Gitlab-PPA" using GitLab CI, with automatic package rebuild triggered by a push/merge on a branch of your own repository. Afte

Re: Bug#1093222: Minimizing build-arch for pam

>> all packages. Simon> I find that it's often better to do this in terms of "am I Simon> building package X?" instead of "am I building arch: all Simon> packages?" because that way, you will also get the correct Simon> answer whe

Re: Bug#1093222: Minimizing build-arch for pam

>> all packages. Simon> I find that it's often better to do this in terms of "am I Simon> building package X?" instead of "am I building arch: all Simon> packages?" because that way, you will also get the correct Simon> answer wh

Re: Bug#1093222: Minimizing build-arch for pam

g package X?" instead of "am I building arch: all packages?" because that way, you will also get the correct answer when dealing with build-profiles. We do this a lot in GNOME and GNOME-adjacent packages. Something like this (in this case taken from gobject-introspection, and enabling

Bug#1093222: Minimizing build-arch for pam

package: pam version: 1.5.3-1 severity: wishlist tags: help >>>>> "Helmut" == Helmut Grohne writes: [talking about pam manpages] Helmut> From a package building pov, I'd appreciate if you could Helmut> also move the tools for building the manual page

Bug#1090980: ITP: golang-github-awslabs-soci-snapshotter -- A containerd snapshotter plugin which enables standard OCI images to be lazily loaded without requiring a build-time conversion step.

Programming Lang: Go Description : snapshotter plugin for containerd to be lazy load OCI images SOCI Snapshotter is a containerd snapshotter plugin. It enables standard OCI images to be lazily loaded without requiring a build-time conversion step. "SOCI" is short for "Seekab

Re: help with build failing on powerpc?

Le jeudi 5 décembre 2024, 00:12:00 UTC+1 Salvo Tomaselli a écrit : > Hello, > > for weborf the build fails on powerpc. > > It seems that 1 test is failing and the others are passing, so I presume it > is > not something very foundamental that is not working. > > Ho

Re: help with build failing on powerpc?

Hello Salvo, El jue, 5 dic 2024 a las 0:12, Salvo Tomaselli () escribió: > for weborf the build fails on powerpc. > > It seems that 1 test is failing and the others are passing, so I presume it is > not something very foundamental that is not working. > > How can I access o

Re: libtool -D_FILE_OFFSET_BITS= (empty) breaks build

* Simon McVittie , 2024-10-29 14:38: I would suggest looking for the root cause in some higher-level component or in the lcmaps package itself. $ grep -rP 'D_FILE_OFFSET_BITS=(?!64)' /usr /usr/lib/x86_64-linux-gnu/pkgconfig/globus-common.pc:Cflags: -D_FILE_OFFSET_BITS= -I${includedir} -- Jak

Re: libtool -D_FILE_OFFSET_BITS= (empty) breaks build

On Tue, 29 Oct 2024 at 16:03:17 +0100, Jakub Wilk wrote: > $ grep -rP 'D_FILE_OFFSET_BITS=(?!64)' /usr > /usr/lib/x86_64-linux-gnu/pkgconfig/globus-common.pc:Cflags: > -D_FILE_OFFSET_BITS= -I${includedir} Thanks, I've reported (plus a wishlist bug report suggest

Re: libtool -D_FILE_OFFSET_BITS= (empty) breaks build

is not defining this at all; leaving it empty makes the expression > syntax > invalid. libtool is not choosing to set this to an empty string: some higher-level component (perhaps Autoconf or Automake or the package-specific build system) is asking libtool to set _FILE_OFFSET_BITS empty (by

libtool -D_FILE_OFFSET_BITS= (empty) breaks build

I just got report https://buildd.debian.org/status/fetch.php?pkg=lcmaps&arch=amd64&ver=1.6.6-3.1%2Bb2&stamp=1730151515&file=log which shows an error: In file included from /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33, from /usr/include/stdio.h:28,

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

when you're ready to make an upload), but it should be present. Leaving > > it empty isn't the usual practice among other developers as far as I've > > seen, and it's just making trouble for yourself. > > I leave it empty exactly because the build scripts co

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

t's just making trouble for yourself. I leave it empty exactly because the build scripts complain when I do that, so that I'll remember to finalize it with the correct date before I put out a release. I also leave it empty to remind me to review the commit history and make sure there

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

On Mon, Sep 02, 2024 at 11:15:50AM -0400, Jonathan Kamens wrote: > I was suggesting that perhaps the root cause of /why/ the .deb files are not > identical is because if there's no timestamp in the trailer line of the top > changelog entry, that impacts the contents of the .deb. IMO your debian/ch

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

On Mon, Sep 02, 2024 at 11:15:50AM -0400, Jonathan Kamens wrote: > P.S. Wow, diffoscope has a /lot/ of dependencies. I understand why, but > still... wow. (Note that those are Recommends and that there is diffoscope-minimal) -- WBR, wRAR signature.asc Description: PGP signature

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

e's no timestamp in the trailer line of the top changelog entry, that impacts the contents of the .deb. And indeed, I just confirmed that theory. It appears that when there is a timestamp in the trailer line, the build process uses that timestamp as the modification time of all the file

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

reprotest locally and still have a closer > look at the differences, you can download the build-artifacts (that > is: the .deb files produced by the job at [1]) and inspect them with > diffoscope, to see that the files in the tarballs have different > timestamps (which obviously makes them n

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

ler line is badly formatted. :shrug: nope. it's failing, because the .deb files are not identical. if you do not want to run reprotest locally and still have a closer look at the differences, you can download the build-artifacts (that is: the .deb files produced by the job at [1]) and i

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

r, I can't see it.) Over to you, Russ. ;-) In any case, thank you to everyone who responded to my request for assistance. I was able to fix this Salsa pipeline problem by adding pybuild-plugin-pyproject to Build-Depends as suggested by Colin Watson. However, the pipeline is still fa

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

y `pip install --use-pep517`. > > As well as the other replies you've got here, you can fix this deprecation warning by adding pybuild-plugin-pyproject to Build-Depends so that pybuild will call into Python packaging in

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

me changes to > Salsa, I discovered that the build pipeline—which is configured outside my > Salsa project so as far as I know I am unable to modify it—is failing. See, > for example, this job > <https://salsa.debian.org/debian/apt-listchanges/-/jobs/6211246#L1089>,

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

Jonathan Kamens writes: > Hey folks, > > I had to step away from working on apt-listchanges > <https://salsa.debian.org/debian/apt-listchanges/> for quite a while > (nearly a year), and upon stepping back into it today and pushing some > changes to Salsa, I discovered

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

overed that the build pipeline—which is configured outside my Salsa project so as far as I know I am unable to modify it—is failing. It is possible that your build dependencies are wrong. You should make sure that it is possible to run the "clean" target while only satifying the dep

Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

Hey folks, I had to step away from working on apt-listchanges <https://salsa.debian.org/debian/apt-listchanges/> for quite a while (nearly a year), and upon stepping back into it today and pushing some changes to Salsa, I discovered that the build pipeline—which is configured outs

Re: RFC: packages that can be installed by the user but not used as build dependencies

On Tue Aug 20, 2024 at 12:17 AM BST, Lisandro Damián Nicanor Pérez Meyer wrote: > But users would love to have something like 'qt6-full-dev'. And the > reason we never provided them with this meta-package is that package > maintainers would use it almost everywhere, dragging the whole Qt > installa

Re: RFC: packages that can be installed by the user but not used as build dependencies

Thanks Samuel and Russ for the feedback! On Mon, 19 Aug 2024 at 20:52, Russ Allbery wrote: > > Lisandro Damián Nicanor Pérez Meyer writes: > > > So, what about if we could have [meta] packages that can be installed by > > the user but not used as Build-Depends entries? Ple

Re: RFC: packages that can be installed by the user but not used as build dependencies

systems when testing in bare chroots etc. > So I don't think maintainers would use it that much in practice. > (similarly to no package currently build-depending on texlive-full) Oh, we've seen that before, that's why we did not add these metapackages to start with :-/ Now back at

Re: RFC: packages that can be installed by the user but not used as build dependencies

Lisandro Damián Nicanor Pérez Meyer writes: > So, what about if we could have [meta] packages that can be installed by > the user but not used as Build-Depends entries? Please note that for the > moment I'm targeting more at the idea itself rather than at the > implementation (b

Re: RFC: packages that can be installed by the user but not used as build dependencies

ilarly to no package currently build-depending on texlive-full) Samuel

RFC: packages that can be installed by the user but not used as build dependencies

Sounds weird, doesn't it? I would like to know what is the general feeling about this idea, with a use case. Let me start with a practical use case: Qt. As you might or not know, Qt is build by using "submodules" that create the whole SDK: https://qt-kde-team.pages.de

Re: Strange armel build error

On 18/08/2024 11:35, Adam D. Barratt wrote: On Sun, 2024-08-18 at 14:23 +0500, Andrey Rakhmatullin wrote: On Sun, Aug 18, 2024 at 11:02:03AM +0200, Alec Leamas wrote: [...]-- If you can’t fix the build, you don’t need to exclude the architecture — you can ask for removal of the armel

Re: Strange armel build error

the build, you don’t need to exclude the architecture — you can ask for removal of the armel package in testing. That will allow the package to migrate even if armel is missing. This looks to me like a sound solution in this case. After all, opencpn is a full-fledged GUI leaf package without reverse

Re: Strange armel build error

armel? If you can’t fix the build, you don’t need to exclude the architecture — you can ask for removal of the armel package in testing. That will allow the package to migrate even if armel is missing. This looks to me like a sound solution in this case. After all, opencpn is a full-fledged GUI leaf

Re: Strange armel build error

Hi; On 18/08/2024 06:11, Wookey wrote: On 2024-08-17 17:58 +0200, Alec Leamas wrote: To make it more interesting, the simple -latomic fix doesn't seem to cut it That's a pity, it sounds plausible. I'll try to take a look. Thanks! That said, unless you have oceans of time, perhaps it might m

Re: Strange armel build error

On Sun, 2024-08-18 at 14:23 +0500, Andrey Rakhmatullin wrote: > On Sun, Aug 18, 2024 at 11:02:03AM +0200, Alec Leamas wrote: > > Hi Stephen, > > > > On 18/08/2024 09:04, Stephen Kitt wrote: > > [...] > > > If you can’t fix the build, you don’t need to

Re: Strange armel build error

On Sun, Aug 18, 2024 at 11:02:03AM +0200, Alec Leamas wrote: > Hi Stephen, > > On 18/08/2024 09:04, Stephen Kitt wrote: > > On Fri, 16 Aug 2024 17:46:45 +0200, Alec Leamas > > wrote: > > > Or just exclude that architecture i. e., list all archs but armel? >

Re: Strange armel build error

Hi Stephen, On 18/08/2024 09:04, Stephen Kitt wrote: On Fri, 16 Aug 2024 17:46:45 +0200, Alec Leamas wrote: Or just exclude that architecture i. e., list all archs but armel? If you can’t fix the build, you don’t need to exclude the architecture — you can ask for removal of the armel package

Re: Strange armel build error

On Fri, 16 Aug 2024 17:46:45 +0200, Alec Leamas wrote: > Or just exclude that architecture i. e., list all archs but armel? If you can’t fix the build, you don’t need to exclude the architecture — you can ask for removal of the armel package in testing. That will allow the package to migr

Re: Strange armel build error

On 2024-08-17 17:58 +0200, Alec Leamas wrote: > > > Fair enough. But TBH, i just cannot wait "a couple of weeks" for a possible > reply; there are users waiting for the backports as I write. Fair enough. If you can't wait then you can't wait. > To make it more interesting, the simple -latomic

Re: Strange armel build error

On 17/08/2024 14:42, Wookey wrote: On 2024-08-16 17:46 +0200, Alec Leamas wrote: From another perspective: what is the right thing to do in a situation like this? Trying to hunt down the problem, and thus causing all sorts of noise like this message? This is what the policy says, but still

Re: Strange armel build error

On 2024-08-16 17:46 +0200, Alec Leamas wrote: > > From another perspective: what is the right thing to do in a situation like > this? Trying to hunt down the problem, and thus causing all sorts of noise > like this message? This is what the policy says, but still... > > Or just exclude that arc

Re: Strange armel build error

Hi Timo and Paul, On 16/08/2024 18:10, Timo Röhling wrote: Hi Alec, * Alec Leamas [2024-08-16 17:46]: /usr/include/c++/14/bits/atomic_futex.h:278:(.text+0x16dc): undefined reference to `std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*)' /usr/bin/ld: /usr/include/c++/14/b

Re: Strange armel build error

Hi Alec, * Alec Leamas [2024-08-16 17:46]: /usr/include/c++/14/bits/atomic_futex.h:278:(.text+0x16dc): undefined reference to `std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*)' /usr/bin/ld: /usr/include/c++/14/bits/atomic_futex.h:278:(.text+0x29d8): undefined reference to

Re: Strange armel build error

Hi, On 16-08-2024 17:46, Alec Leamas wrote: All other builds are OK. Has anyone a hint about what might be going on here? https://release.debian.org/testing/arch_qualify.html armel column. Paul OpenPGP_signature.asc Description: OpenPGP digital signature

Strange armel build error

Dear list, Still trying to maintain opencpn. Now looking at an error in the armel build [1]. The core is a bunch of messages like /usr/include/c++/14/bits/atomic_futex.h:278:(.text+0x16dc): undefined reference to `std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*)'

Bug#1078192: ITP: pbs-installer -- An installer for @indygreg's python-build-standalone

: MIT/X Programming Lang: Python Description : An installer for @indygreg's python-build-standalone The list of python versions are kept sync with the upstream automatically, via a periodically GitHub Action. This is an unpackaged dependency of PDM. I intend to maintain this packa

Re: Produce extra build artifacts during package builds

at > the same time, where once had ICE errors and the other had not). If it's really $TMPDIR, then that's easy to implement. The $TMPDIR could even be inside the build directory, like you would often want to do in Gitlab-CI to avoid any weird effects of /tmp being on an overlayfs (

Re: Produce extra build artifacts during package builds

e for copying the > relevant test files into my proposed directory. Sure, but is this assuming that the only relevant build artifacts for most packages are the logs that are integrated with the build system (Autotools config.log and test-suite.log, Meson meson-logs/, etc.) and having the tests ou

Re: Produce extra build artifacts during package builds

for copying the relevant test files into my proposed directory. > In the design that I prototyped, it's declarative, loosely inspired by > the equivalent Gitlab-CI feature: > > - the maintainer can write patterns into debian/build-artifacts for > package-specific quirks like GTK&#

Re: Produce extra build artifacts during package builds

Simon McVittie: On Fri, 02 Aug 2024 at 18:17:52 +0200, Niels Thykier wrote: Simon McVittie: In the design that I prototyped, it's declarative, loosely inspired by the equivalent Gitlab-CI feature: - the maintainer can write patterns into debian/build-artifacts for package-specific q

Re: Produce extra build artifacts during package builds

On Fri, 02 Aug 2024 at 18:17:52 +0200, Niels Thykier wrote: > Simon McVittie: > > In the design that I prototyped, it's declarative, loosely inspired by > > the equivalent Gitlab-CI feature: > > > > - the maintainer can write patterns into debian/build-artifacts fo

Re: Produce extra build artifacts during package builds

Simon McVittie: On Fri, 02 Aug 2024 at 16:40:15 +0900, Mattia Rizzolo wrote: [...] * decide on a directory name (`./debian/export_artifacts/`?) * the build process will dump any files that could be interesting to export in there (no decision if/how to define the structure within

Re: Produce extra build artifacts during package builds

t this did not stay as my top priority, but I can only have one top priority at a time. (There is also some good input from Paul Wise in the 2022 thread) > * decide on a directory name (`./debian/export_artifacts/`?) > * the build process will dump any files that could be interesting to &

Produce extra build artifacts during package builds

#Design_proposal I'm copying it here for reference: * decide on a directory name (`./debian/export_artifacts/`?) * the build process will dump any files that could be interesting to export in there (no decision if/how to define the structure within this directory) * potentially, all

Re: Bug#1033747: chromium: Build Chromium without the embedded libtiff

; waiting for repeated repacking every few weeks when updating rustc/cargo. I >> assume there's a few other packages that do involved pruning of bloated >> upstream tarballs like that that would also benefit. For Rust, we remove >> about 2/3 of the upstream tarball[0], both file

Re: Bug#1033747: chromium: Build Chromium without the embedded libtiff

o > waiting for repeated repacking every few weeks when updating rustc/cargo. I > assume there's a few other packages that do involved pruning of bloated > upstream tarballs like that that would also benefit. For Rust, we remove > about 2/3 of the upstream tarball[0], both file size

Re: Bug#1033747: chromium: Build Chromium without the embedded libtiff

(or rather, has to do). It's a mix of embedded copies of other projects (e.g., LLVM) that we don't want since we use those provided by standalone packages, and removing toolchain components and their vendored deps that are not used for the Debian build. Technically we could also keep all o

Bug#1077697: ITP: libdist-build-perl -- modern Perl module builder

Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libdist-build-perl Version : 0.007 Upstream Author : Leon Timmermans * URL : https://metacpan.org/release/Dist-Build

Re: Bug#1033747: chromium: Build Chromium without the embedded libtiff

On Monday, July 29, 2024 1:28:31 PM MST Andres Salomon wrote: > On 7/29/24 16:10, Soren Stoutner wrote: > I replaced the first three steps with a single 'tar --exclude-from', so > that we save time by not writing deleted files to disk only to manually > delete them: > https://salsa.debian.org/chr

Re: Bug#1033747: chromium: Build Chromium without the embedded libtiff

On 7/29/24 16:10, Soren Stoutner wrote: On Monday, July 29, 2024 1:18:05 AM MST Andres Salomon wrote: It's unfortunately going to have to wait. We're switching standard libraries, and linking to external libs is a bit rocky right now. Waiting until things settle is fine. This has been an issu

Bug#1077300: ITP: golang-github-charmbracelet-huh -- Build interactive forms and prompts in the terminal

Package: wnpp Severity: wishlist Owner: Arthur Diniz * Package name: golang-github-charmbracelet-huh Version : 0.5.2-1 Upstream Author : Charm * URL : https://github.com/charmbracelet/huh * License : Expat Programming Lang: Go Description : Build

Bug#1076595: ITP: golang-github-minio-selfupdate -- Build self-updating Go programs

* License : Apache-2.0 Programming Lang: Go Description : Build self-updating Go programs Package update provides functionality to implement secure, self-updating Go programs (or other single-file targets) A program can update itself by replacing its executable file with a new version

Re: dh_auto_clean, autoconf, and building packages twice (was: Potential MBF: packages failing to build twice in a row)

h a target exists. But > that's not the case until ./configure has been run, because until then, there > are no makefiles. So The first time you run debian/rules build, the shipped > version of the files will be untouched and used in the final package, but > when > you then

dh_auto_clean, autoconf, and building packages twice (was: Potential MBF: packages failing to build twice in a row)

o makefiles. So The first time you run debian/rules build, the shipped version of the files will be untouched and used in the final package, but when you then clean and build again, they will be deleted and rebuilt (or the second build fails because of missing build dependencies). Besides bui

Bug#1073118: ITP: protobuild -- Build protobufs in Go, easily

Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: protobuild Version : 0.3.0-1 Upstream Author : containerd * URL : https://github.com/containerd/protobuild * License : Apache-2.0 Programming Lang: Go Description : Build

Bug#1072781: ITP: python-cmake-build-extension -- Setuptools extension to build and package CMake projects

Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-cmake-build-extension Version : 0.6.0 Upstream Author : Diego Ferigo * URL : https://github.com

Bug#1072313: ITP: debpic -- Build Debian packages in a docker container

Programming Lang: Python Description : Build Debian packages in a docker container Debpic allows developers to build Debian package in an isolated environment. Invoke debpic in a repository without any arguments to simply build packages. The environment is composed from: * The Debian

Re: Tool to build Debian packages not requiring root in containers ?

none of the packages involved require root priviledges to build. Have you tried the unshare backend for sbuild? It uses Linux namespaces instead of full-blown root privileges, and works really great for my regular packaging work. I have not tried running it inside a virtualization container, though

Re: Tool to build Debian packages not requiring root in containers ?

Le Wed, May 08, 2024 at 08:02:41AM -0700, Otto Kekäläinen a écrit : > > I read the docs on how Singularity is able to pull Docker images of Debian > Sid and build on top of them, and run and exec just like Docker/Podman. > Unfortunately it has its own Containerfile form

Re: Tool to build Debian packages not requiring root in containers ?

Hi! ti 7. toukok. 2024 klo 23.01 Charles Plessy kirjoitti: > Le Tue, May 07, 2024 at 08:17:31PM -0700, Otto Kekäläinen a écrit : > > > > Can you give me an example of a package you want to build and what is > > the starting point, and I can tell you what command

Re: Tool to build Debian packages not requiring root in containers ?

Le Tue, May 07, 2024 at 08:17:31PM -0700, Otto Kekäläinen a écrit : > > Can you give me an example of a package you want to build and what is > the starting point, and I can tell you what command to issue to > https://salsa.debian.org/otto/debcraft to achieve it? > > It suppo

Re: Tool to build Debian packages not requiring root in containers ?

engines like sbuild, as none of the packages involved require > root priviledges to build. > > Do you have a suggestion for a tool can run in user mode in a container > image having access to local storage on the host, and that given a > Debian source control file will download the

Tool to build Debian packages not requiring root in containers ?

engines like sbuild, as none of the packages involved require root priviledges to build. Do you have a suggestion for a tool can run in user mode in a container image having access to local storage on the host, and that given a Debian source control file will download the dependencies and build the

Bug#1070211: ITP: krb5-wallet -- The wallet system manages secure data. It is build on top of remctl. One of the object types it supports is Kerberos keytabs, making it suitable as a user-accessible

Package: wnpp Severity: wishlist Owner: Bill MacAllister X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: krb5-wallet Version : 1.5 Upstream Contact: Bill MacAllister * URL : https://salsa.debian.org/whm/krb5-wallet * License : (Expat) Programming

Bug#1061548: ITP: tippecanoe -- build vector tilesets from large collections of GeoJSON features

: https://github.com/felt/tippecanoe * License : BSD-2-Clause, etc. Programming Lang: C++ Description : build vector tilesets from large collections of GeoJSON features Tippecanoe builds vector tilesets from large (or small) collections of GeoJSON, FlatGeobuf, or CSV

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?

Re: build profile proposal: nogir (second try)

Jan 2024 at 18:30:02 +, 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? If you want to skip a p

  1   2   3   4   5   6   7   8   9   10   >