> "Paul" == Paul Wise writes:
Paul> On Mon, Jan 13, 2020 at 4:11 PM Wouter Verhelst wrote:
>> You'll make it unnecessarily harder to bootstrap environments that need
>> themselves to build if you do that.
Paul> The idea here is that bootstrap builds are special and so they sh
Hi,
Quoting Simon McVittie (2020-01-16 19:47:02)
> I think I dimly remember someone setting up "the buildd from hell" which
> deliberately did this as a QA mechanism, but it doesn't seem to have
> continued in any systematic way.
is there more information about it somewhere? My inbox has only two
Hi Daniel, Sam and all,
Quoting Sam Hartman (2020-01-17 01:27:52)
> > "Daniel" == Daniel Schepler writes:
>
> Daniel> (Incidentally, another offshoot was creating local patches to
> sbuild
> Daniel> which add an operation mode using systemd-nspawn --ephemeral to
> start
> Danie
Johannes Schauer writes:
> My advice would also be to switch from debootstrap to mmdebstrap because the
> latter is able to create a chroot with only Essential:yes packages in it while
> debootstrap includes Priority:required packages as well. Alternatively,
> debootstrap could gain a variant only
Hi,
On Thu, Jan 16, 2020 at 08:50:25AM -0800, Daniel Schepler wrote:
> I've been running a manual test bootstrap of Debian (starting with
> cross-compiled packages amd64 -> i386 up to the point I was able to
> install debhelper), and posting a few bugs I've found along the way.
> These are where
On Fri, 2020-01-17 at 11:12:50 +0100, Ansgar wrote:
> Johannes Schauer writes:
> > My advice would also be to switch from debootstrap to mmdebstrap because the
> > latter is able to create a chroot with only Essential:yes packages in it
> > while
> > debootstrap includes Priority:required packages
Quoting Sam Hartman (2020-01-17 09:45:43)
> > "Paul" == Paul Wise writes:
>
> Paul> On Mon, Jan 13, 2020 at 4:11 PM Wouter Verhelst wrote:
> >> You'll make it unnecessarily harder to bootstrap environments that need
> >> themselves to build if you do that.
>
> Paul> The idea
Hi,
I tried uploading node-webpack with DEB_BUILD_PROFILES=nocheck sbuild
-s --source-only-changes
https://tracker.debian.org/news/1094664/accepted-node-webpack-4300-2-source-into-experimental/
But it seems the buildd did not consider Built-For-Profiles: nocheck in
the source.changes file. I
> "Johannes" == Johannes Schauer writes:
Johannes> or have a mechanism that allows maintainers to tell buildds
"please build this
Johannes> source package with build profiles X and Y enabled". That would
then build the
Johannes> binary packages necessary to do a full build in a
On Fri, Jan 17, 2020 at 02:41:26AM +, Paul Wise wrote:
> On Thu, Jan 16, 2020 at 7:06 PM Roberto C. Sánchez wrote:
>
> > I've read the distro-tracker documentation and it seems like interaction
> > is by visiting with a web browser or via email. Is there an official or
> > even unofficial API
On Fri, 17 Jan 2020 at 18:08:59 +0530, Pirate Praveen wrote:
> I tried uploading node-webpack with DEB_BUILD_PROFILES=nocheck sbuild -s
> --source-only-changes
That doesn't mean what you think it does. My understanding is that the
profiles only affect the binaries that *you* built, which were omit
Package: wnpp
Severity: wishlist
Owner: Wookey
* Package name: tvm
Version : 0.6.0
Upstream Author : Apache tvm incubator project
* URL : https://tvm.apache.org/
* License : Apache 2.0
Programming Lang: C++, (with go, java, python, rust parts)
Description
Hi Roberto
> does source package 'foo' exist in release 'bar'?
>
> Looking at the UDD wiki page and the associated examples, it seems like
> the query I need is something roughly like:
>
> SELECT COUNT(*) FROM public.packages WHERE source='foo' AND release='bar';
>
> Is this the best approach?
Hi Daniel,
On Thu, Jan 16, 2020 at 12:04:12PM -0800, Daniel Schepler wrote:
> Also, by the way, the amd64 -> i386 cross built core packages largely
> worked OK, with the exception of gcc-9, which ended up with incorrect
> include-fixed/limits.h, and with a compiler that required -lssp when
> build
Hi Daniel,
On Thu, Jan 16, 2020 at 08:50:25AM -0800, Daniel Schepler wrote:
> However, I've been getting push back on some of these, with
> maintainers of the opinion that it isn't actually a bug. So, I
> thought I'd consult here to get more opinions on whether these are
> true bugs, or whether I
On Mi, 15 ian 20, 23:11:38, Julian Andres Klode wrote:
> Starting with APT 2.0 (1.9.6 in experimental), the apt(8) binary will
> not try to interpret package names passed on the command-line as regular
> expressions or fnmatch() style patterns. Future versions of apt-get(8)
> and apt-cache(8) will
Hi,
Quoting Daniel Schepler (2020-01-17 17:58:09)
> > I'm also very excited about having yet another chroot backend being
> > integrated into sbuild! Though my first comment would be the same as I gave
> > those asking for a docker backend in #867176: maybe try adding that backend
> > to autopkgte
On Fri, Jan 17, 2020 at 2:05 AM Johannes Schauer wrote:
> yes, probably a communication problem. I think you are talking about [1] from
> August 11 last year? I replied the same day, telling you to please file a bug
> with your patches to continue discussion there. But then there was no response
>
On 1/17/20 6:55 AM, Sam Hartman wrote:
>> "Johannes" == Johannes Schauer writes:
>
> Johannes> or have a mechanism that allows maintainers to tell buildds
> "please build this
> Johannes> source package with build profiles X and Y enabled". That would
> then build the
> Johannes
Package: wnpp
Severity: wishlist
Owner: "Paulo Henrique de Lima Santana (phls)"
* Package name: python3-clap
Version : 0.14.0
Upstream Author : Marek Marecki
* URL : https://github.com/marekjm/clap
* License : GPL-3+
Programming Lang: Python
Description
On Fri, 2020-01-17 at 10:58 +0100, Johannes Schauer wrote:
> Quoting Simon McVittie (2020-01-16 19:47:02)
> > I think I dimly remember someone setting up "the buildd from hell" which
> > deliberately did this as a QA mechanism, but it doesn't seem to have
> > continued in any systematic way.
>
> i
Subject: ITP: parsero -- Audit tool for robots.txt of a site
Package: wnpp
Owner: Thiago Andrade Marques
Severity: wishlist
* Package name: parsero
Version : 0.0+git20140929.e5b585a
Upstream Author : Javier Nieto
* URL : https://github.com/behindthefirewalls/Parsero/
On Fri, 2020-01-17 at 03:45 -0500, Sam Hartman wrote:
> Bootstrap uploads of compilers etc are actually more common than I
> thought before I started following debian-release.
The important part of my statement is that they are special, rather
than that they are rare.
> They are common enough th
On Fri, Jan 17, 2020 at 6:18 PM Richard Laager wrote:
> If I'm following correctly: The packager would use rustcc >= y+3 (in
> practice, likely rustcc y+5) to locally build rustcc y+5 and then do a
> binary upload. But if dak (or whatever, I'm not so familiar with the
> server side here) throws aw
On Fri, Jan 17, 2020 at 3:18 PM Stuart Prescott wrote:
> FWIW there are python bindings and CLI tools for UDD floating around ... I
> really should package them (and having people interested in them would be
> good motivation for that)
I think it would be great to have those in devscripts, please
On Fri, Jan 17, 2020 at 1:11 PM Roberto C. Sánchez wrote:
> My initial thought was to query the tracker for a given package to
> determine its availability.
>
> does source package 'foo' exist in release 'bar'?
I don't know the context for this question but if command-line is
enough then just run
26 matches
Mail list logo
