Re: Is distro-tracker accessible by some sort of API?
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 running `rmadison foo`, `rmadison -u debian foo` or `rmadison -u udd foo` should work. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Is distro-tracker accessible by some sort of API?
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 also mention them in DevNews once they get accepted into the archive. -- bye, pabs https://wiki.debian.org/PaulWise
Re: https://tracker.debian.org/pkg/dballe
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 away the binary, then we're sunk. So there > needs to be a way to note that the binary needs to be kept. > > Assuming I'm on the right track, here are a couple of questions: Right. > In such a case, would the source package have a Build-Depends of >= y+3? > It seems like it would. Presumably, but it is definitely possible the maintainer wouldn't know or wouldn't record which version was needed. > Could that be the way to indicate a bootstrap upload? In other words, if > the package has a Build-Depends on one of the binary packages it > produces that is _not_ satisfied in the suite it's being uploaded to but > is satisfied by this upload, then it's a bootstrap upload, and the > binaries should be kept. This would avoiding adding a new field for this > and would ensure the Build-Depends are set correctly in bootstrapping > scenarios. At this time the workflow is like this: ftp-master.d.o accepts or rejects the source/binaries, then it passes the source to buildd.d.o, which checks for build-dep installability and passes the source to the buildds. I think for your proposal to work the build-dep installability checks would also have to move to ftp-master.d.o. > Regardless of how the "keep the binaries" flag is implemented... should > the uploaded binary be published, or should the package be rebuilt? I > think I'd argue for the latter. The uploaded binary package should be > installed on the buildd and then the package should be rebuilt from > source, with _that_ result being put into the archive. This doesn't > protect against the trojaned-compiler problem, but it does at least > ensure that the package builds from source. I definitely agree that all bootstrap binaries, whether built automatically by the buildds (as proposed by Josch) or hacky maintainer-built binaries, should get rebuilt on the buildds. We already did that in the past when importing new architecture packages from ftp.ports.d.o to ftp-master.d.o. -- bye, pabs https://wiki.debian.org/PaulWise
Re: https://tracker.debian.org/pkg/dballe
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 that requiring interactions from ftpmaster and/or > release team would make being a developer of such packages suck > significantly more. Hmm, OK. I can't recall seeing any recently on debian-release. > If we throw away binaries by default, I do believe we need a mechanism > for maintainers to signal that this is a bootstrap upload. My proposed mechanism is that when the buildds cannot do the job due to need for a bootstrap process, the maintainer should do a binary-only build (using whatever ugly hacks are needed), dak should import that into a special part of the archive for bootstrapping packages that need that and then tell the buildds to do a new non-bootstrap build but using the bootstrap archive. If bikesheds become a thing, we could even have one bootstrap archive per instance of a bootstrap being needed. Like Josch says, where possible, we also want the buildds to be capable of doing automated bootstrap builds that are enabled by automatic or maintainer-selected addition of bootstrap related build profiles. Until the special bootstrap archive and automated bootstrap builds are implemented, we could of course just import the maintainer bootstrap binaries into the main archive with a flag saying they need to be rebuilt before they can enter testing, and then do binNMUs. ISTR we have done similar things when importing whole architectures to ftp-master so I think some parts or flags for some of these things might already be in place. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#949198: (no subject)
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/ * License : (GPL-2+ Programming Lang: Python3 Description : Audit tool for robots.txt of a site Parsero reads the Robots.txt file of a web server and looks at the Disallow entries. The Disallow entries tell the search engines what directories or files hosted on a web server must not be indexed. For example, "Disallow: /portal/login" means that the content on www.example.com/portal/login it's not allowed to be indexed by crawlers like Google, Bing, Yahoo... This is the way the administrator have to not share sensitive or private information with the search engines.
Re: Is running dpkg-buildpackage manually from the command line forbidden?
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. > > is there more information about it somewhere? My inbox has only two emails > from > xnox and pabs (in CC) about it. How did it work? I found a reference to it on the wiki: https://wiki.debian.org/qa.debian.org/ArchiveTesting#TODO Some discussions about it that I found: Subject: rebuilding the archive in a dirty chroot: results <20080125142515.ga18...@xanadu.blop.info> Subject: Meaning of the "Altering package upload rules" <20080216130228.ga32...@pcpool00.mathematik.uni-freiburg.de> <20080216181247.GA13475@garfield> Subject: Use of the Build-Conflicts field Subject: Re: Please drop anacron from task-desktop -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#949186: ITP: python3-clap -- command line arguments parser
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 : command line arguments parser CLAP aims at being powerful and advanced command line interface library for Python 3 language. Having built-in support for modes, optional and obligatory options, options with arguments (with type-checking with arbitrary types) it enables programmers to create rich command line interfaces for Python 3 programs. . Features: * Support for single-level and nested modes (with per-mode and global options). * Support for grouped short options (ls -lhR). * Support for long options with or without equal-sign-connected arguments (--log=./file.log and --log ./file.log are both correct). * Support for option aliases (short/long names). * Support for typed arguments (str, int, float built-in and other arbitrary types via callbacks). * Built-in type checking of option arguments. * Support for multiple arguments for options (e.g. --point 0 0). * Checking for missing arguments with options which require them. * Checking for conflicting options (eg. --quiet must not come with option --verbose). * Support for options that MUST be passed to the program. * Support for options required by other options (e.g. --key requires --value). * Support for options wanted by other options (e.g. --which wants --this or --that or both). * Good set of exceptions with detailed error messages. * Ability to load interface from JSON descriptions. * Automatic generation of help screens (for your-tool help command) with per-mode, per-option, and per-operand descriptions, usage examples, and more. * Support for shortcuts for command names (shortest-unique name is sufficient for CLAP to resolve the command, it is not necessary to write full names). . CLAP is not the most easy to use command line arguments parser for Python, but that it is one of the most powerful (if not the most powerful) framework for writing command line interfaces. With excellent support for modes, options, and operands, automatic input verification, and help screen generation you get a big return on your investment.
Re: https://tracker.debian.org/pkg/dballe
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> binary packages necessary to do a full build in a second upload. > > That doesn't help. > > If I need version y+3 of rustcc to build y+5 of rustcc and only y is in > the archive, no build profile is going to help me. 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 away the binary, then we're sunk. So there needs to be a way to note that the binary needs to be kept. Assuming I'm on the right track, here are a couple of questions: In such a case, would the source package have a Build-Depends of >= y+3? It seems like it would. Could that be the way to indicate a bootstrap upload? In other words, if the package has a Build-Depends on one of the binary packages it produces that is _not_ satisfied in the suite it's being uploaded to but is satisfied by this upload, then it's a bootstrap upload, and the binaries should be kept. This would avoiding adding a new field for this and would ensure the Build-Depends are set correctly in bootstrapping scenarios. Regardless of how the "keep the binaries" flag is implemented... should the uploaded binary be published, or should the package be rebuilt? I think I'd argue for the latter. The uploaded binary package should be installed on the buildd and then the package should be rebuilt from source, with _that_ result being put into the archive. This doesn't protect against the trojaned-compiler problem, but it does at least ensure that the package builds from source. -- Richard signature.asc Description: OpenPGP digital signature
Re: Is running dpkg-buildpackage manually from the command line forbidden?
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
> from you anymore and I don't find your bug in the BTS. Maybe my mail got lost
> somehow or I fail finding the bug you filed?
It seems the reply must have gotten lost somehow - I don't see it anywhere.
> 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 autopkgtest
> first. Then more people would profit from having that type of backend
> available
> and no additional changes would be needed in sbuild because sbuild can already
> use autopkgtest backends for package building.
OK, I'll try to get the patch submitted either tonight or tomorrow.
(What I need to clean up is that it's interspersed with changes I made
to have it run with a personal distribution build I've been tinkering
with. On a quick review, I now notice it's also interspersed with
changes to support using eatmydata only on the apt install commands
and only if not in schroot-update mode, instead of having to put it
into schroot config to apply to all commands - which seems reasonable
to split out into a separate patch to submit. I also haven't yet
updated documentation files.)
One quick question: I don't see any mention of
$options->{'DISABLE_NETWORK'} in lib/Sbuild/ChrootAutopkgtest.pm,
whereas my new lib/Sbuild/ChrootNspawn.pm does support it. If I'm not
missing something, then I wonder what it would take to add
DISABLE_NETWORK support to the autopkgtest sbuild engine.
--
Daniel Schepler
Re: Is running dpkg-buildpackage manually from the command line forbidden?
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 autopkgtest first. Then more people would profit from having that type
> > of backend available and no additional changes would be needed in sbuild
> > because sbuild can already use autopkgtest backends for package building.
> OK, I'll try to get the patch submitted either tonight or tomorrow.
thank you!! :)
> One quick question: I don't see any mention of $options->{'DISABLE_NETWORK'}
> in lib/Sbuild/ChrootAutopkgtest.pm, whereas my new lib/Sbuild/ChrootNspawn.pm
> does support it. If I'm not missing something, then I wonder what it would
> take to add DISABLE_NETWORK support to the autopkgtest sbuild engine.
it would require some way to tell the autopkgtest backends to disable network.
To my knowledge that is not possible. So as of today, the only backend where
you can disable network for the build (not the apt install) is the "unshare"
backend.
More info here:
https://wiki.debian.org/sbuild#Disabling_network_access_for_dpkg-buildpackage
Thanks!
cheers, josch
signature.asc
Description: signature
Re: Deprecating regex/fnmatch fallback for package arguments, and 1.9.6 highlights
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 follow that change, following the release of bullseye. [...] > # In other news > > - Cache generation is about 16% faster for a single-arch amd64 > stretch chroot (in memory, on a Core i5-8250U powered T480s) > - Hashing is now done by gcrypt, offering about 50% performance > improvement on the same platform due to hardware-accelerated > implementations of SHA. Any plans to integrate apt-file (functionality) in 'apt search'? Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Is running dpkg-buildpackage manually from the command line forbidden?
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'm at fault for trying to run dpkg-buildpackage > manually instead of using it through pbuilder or sbuild. Given that I'm also bootstrapping Debian (in a different setting), I'm running into much the same problems. However, when I file bugs about build failures in non-standard environments, I don't receive the push-back that you describe. I cannot reproduce your experience. It's a rare thing for maintainers to tell me that I'm filing a non-bug and I do file a *lot* of bugs. Could it be that your sample is very small or biased? Maybe you can give examples? In any case, the consensus seems to be that FTBFS in a non-standard environment is a bug, but not an RC one. And in general, you get to discuss less with maintainers if your bug includes a patch. ;) Helmut
Re: Is running dpkg-buildpackage manually from the command line forbidden?
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 > building with -fstack-protector-strong or -fstack-protector as almost > all Debian packages do. To anybody on the list: is there something I > did wrong with the cross build there, which was to run > "dpkg-buildpackage -a i386 -B -Pcross"?) This sounds a lot like you're running into https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80677. Cross building gcc tends to not work in my experience, see: http://crossqa.debian.net/src/gcc-8 http://crossqa.debian.net/src/gcc-9 For gcc-9, the --host flag is not properly passed down to the gm2 component. This is reported as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92336. I think the expectation that it works is misguided. Adding DEB_BUILD_OPTIONS=nocheck might increase your chances of a successful build. Quite certainly, more work is needed here. Unfortunately, we sorely lack porters and everyone seems to expect that things just work without anyone doing the work. Helmut
Re: Is distro-tracker accessible by some sort of API?
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?
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)
$ ipython3
In [1]: import uddcache.udd
In [2]: udd = uddcache.udd.Udd()
In [3]: pkg = udd.BindPackage('libc6', arch='amd64', release='bullseye')
In [4]: pkg.IsAvailable()
Out[4]: True
In [5]: pkg = udd.BindPackage('no-such-package', arch='amd64',
release='bullseye')
In [6]: pkg.IsAvailable()
Out[6]: False
$ udd-cache versions libc6
Package: libc6 None/amd64
squeeze: 2.11.3-4
wheezy:2.13-38+deb7u10
wheezy-security: 2.13-38+deb7u12
jessie:2.19-18+deb8u10
jessie-security: 2.19-18+deb8u10
stretch-security: 2.24-11+deb9u1
stretch: 2.24-11+deb9u4
buster:2.28-10
bullseye: 2.29-7
sid: 2.29-9
experimental: 2.30-0experimental1
$ udd-cache versions libc6 --release bullseye
Package: libc6 bullseye/amd64
bullseye: 2.29-7
$ udd-cache versions no-such-package --release bullseye
No package named 'no-such-package' was found in bullseye/amd64.
cheers
Stuart
--
Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#949155: ITP: tvm -- Deep Learning compiler
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 : Deep Learning compiler TVM is a deep learning compiler stack for CPUs, GPUs, and specialized accelerators. It interfaces between the productivity-focused deep learning frameworks, and the performance- or efficiency-oriented hardware backends. TVM compiles deep learning models in Keras, MXNet, PyTorch, Tensorflow, CoreML, and DarkNet into minimum deployable modules on various hardware backends (CPUs, GPUs and specialised accelerators). It also provides tools to auto-generate and optimize tensor operators on more backends with better performance. This is part of the growing stack of AI software. If anyone else is interested in helping with this package that would be great because I know very little about AI. I'm mostly interested because this piece is the next step up above low-level support like openCL, arm compute library and armNN (neural network accelerator support), which I am also working on/helping with. I do have access to people with clue in linaro, where this packaging will be initially tested, but in the longer term people actually using AI tools in debian would be best place to look after this.
Re: Source-only upload and build profiles
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 omitted from the source-only .changes anyway. Built-For-Profiles: nocheck is information about the binaries you built not being the "official" version, not a request to buildds to build this source code with different options. > This is required because node-uglifyjs-webpack-plugin has dependency on > webpack (it actually requires files from webpack). I believe the intention is that you might use build-profiles to bootstrap your own build environment, but when you upload binaries to the real Debian archive, they are always meant to be built *without* profiles. So if you have two packages, foo Build-Depends: bar and bar Build-Depends: foo , you'd have to do something like this: - build foo with DEB_BUILD_PROFILES=nocheck - build bar normally - rebuild foo normally - delete the temporary DEB_BUILD_PROFILES=nocheck version of foo (don't upload it) - upload either foo or bar with binaries (built with no profiles) - upload the other package, with or without binaries (This matters more for profiles that might alter the content of the packages, like nodoc, stage1, stage2, or any profile that is not "safe".) smcv
Re: Is distro-tracker accessible by some sort of API?
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 for access to data in distro-tracker? > > There are a few APIs defined in the URL configuration: > > https://salsa.debian.org/qa/distro-tracker/tree/master/distro_tracker/project/urls.py > > Which kind of APIs were you looking for and what did you intend to use > them for? Most of the tracker data is just imports from elsewhere (UDD > mostly) so it might be better for you to use that data instead. > OK. That's helpful. I'm sure I have heard of UDD over the years and just not really paid it much mind since it wasn't relevant to my needs at the time. My initial thought was to query the tracker for a given package to determine its availability. The particular question I'm trying to answer is: 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? Regards, -Roberto -- Roberto C. Sánchez
Re: https://tracker.debian.org/pkg/dballe
> "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 second upload. That doesn't help. If I need version y+3 of rustcc to build y+5 of rustcc and only y is in the archive, no build profile is going to help me. There are a lot of packages that need themselves to build themselves in Debian. It's not just a new arch issue.
Source-only upload and build profiles
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 think I will have to do a binary included upload, but it'd be nice if buildd can support build profiles. This is required because node-uglifyjs-webpack-plugin has dependency on webpack (it actually requires files from webpack). Thanks Praveen
Re: https://tracker.debian.org/pkg/dballe
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 here is that bootstrap builds are special and so they > should > Paul> be very explicit rather than happen as a side effect of regular > upload > Paul> workflows. Since they are relatively rare, making them explicit via > Paul> this mechanism shouldn't be too much of an imposition and on balance > Paul> might be the right way to go. > > Bootstrap uploads of compilers etc are actually more common than I > thought before I started following debian-release. > They are common enough that requiring interactions from ftpmaster and/or > release team would make being a developer of such packages suck > significantly more. > > If we throw away binaries by default, I do believe we need a mechanism for > maintainers to signal that this is a bootstrap upload. or have a mechanism that allows maintainers to tell buildds "please build this source package with build profiles X and Y enabled". That would then build the binary packages necessary to do a full build in a second upload. In an even better world, dak would figure out itself, that a source package first has to be built with build profiles X and Y and then schedule a full build afterwards. Thanks! cheers, josch signature.asc Description: signature
Re: Is running dpkg-buildpackage manually from the command line forbidden?
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 as well. Alternatively, > > debootstrap could gain a variant only installing Essential:yes packages and > > their dependencies (why doesn't it have that already?). > > Debian doesn't support systems that don't have "required" packages > installed. So buildds should have them installed. If these statements are based on the policy quote below, then I do not agree. I don't see why e2fsprogs would need to be installed on a chroot, as long as there's nothing depending on it, for example. > Policy states: > "Removing a required package may cause your system to become totally > broken and you may not even be able to use dpkg to put things back, so > only do so if you know what you are doing." That seems wrong, or inaccurate at best. dpkg should never depend on anything that is not part of the pseudo-essential set (strictly speaking only Essential:yes + awk-virtual), or that it depends on explicitly. So as long as a package has not been forced out, dpkg must work. Removing a required package (that is not Essential:yes) might indeed render your system broken, but what broken means or in what context is not qualified there. This could apply to systems that get booted for example, but not to chroots. A package that relies on another package that is Priority:required and not Essential:yes, and that it does not depend on, is just broken. Here's the current list of these packages on my system: $ aptitude -F '%p' search '~prequired !~E' debconf e2fsprogs gcc-10-base gcc-9-base libpam-modules libpam-modules-bin libpam-runtime mawk mount passwd tzdata And most of these are actually part of the pseudo-essential set anyway, and cannot be removed w/o force. That passage in policy might have made sense some time ago, when Priority:required almost matched the pseudo-essential set, and when we didn't have a separation of "dpkg-essential" and "boot-essential". Regards, Guillem
Re: Is running dpkg-buildpackage manually from the command line forbidden?
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 I found that having extra packages installed during > the dpkg-buildpackage run either failed or resulted in broken > packages. (Some examples of the type of thing I mean: #948522, > #887902.) I would expect a sensible package build to not depend on package relationships that aren't declared, in either way, but things in /usr/local are outside the control of the package system. So a package that enables an optional feature if a particular other package is installed, but there is neither a build dependency nor a build conflict declared is a bug to me. The Build-Conflicts should still be avoided, by an explicit configure option "disable this feature". Simon
Re: Is running dpkg-buildpackage manually from the command line forbidden?
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 installing Essential:yes packages and > their dependencies (why doesn't it have that already?). Debian doesn't support systems that don't have "required" packages installed. So buildds should have them installed. Policy states: "Removing a required package may cause your system to become totally broken and you may not even be able to use dpkg to put things back, so only do so if you know what you are doing." "Essential" packages just have additional requirements (in particular essential packages must work even in the "unpacked" state). Ansgar
Re: Is running dpkg-buildpackage manually from the command line forbidden?
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 > Daniel> a container (along with the base being a BTRFS subvolume to speed > up > Daniel> the cloning), systemd-run -M debian-sid-amd64-xxx > Daniel> [--property=PrivateNetwork=yes] cmd..., etc. When I sent a > message to > Daniel> sbu...@packages.debian.org there didn't seem to be any interest in > Daniel> having me clean up the patches and send them on. > > This sounds like a communication problem or something. Having > systemd-nspawn container support in sbuild would be really helpful. > Would you be willing to try reaching out to the sbuild maintainers > again? If you don't get an answer, in a month or so, please reach out > to me as DPL. My job would not to be to convince the maintainer to > accept your patches, but rather to facilitate communication so you can > get a clear answer. The DPL does that from time to time when things seem to > have broken down. 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 from you anymore and I don't find your bug in the BTS. Maybe my mail got lost somehow or I fail finding the bug you filed? 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 autopkgtest first. Then more people would profit from having that type of backend available and no additional changes would be needed in sbuild because sbuild can already use autopkgtest backends for package building. Let me also use this opportunity to ask for help with maintaining sbuild. If any of you reading this ever felt that sbuild was the thing that is worth your time, please feel free to reach out to me. We need to make a new release fixing some easy but important bugs that accumulated in the BTS. I would be very happy to review and apply people's patches. :) Thanks! cheers, josch [1] cadf0c45pjydq+hmqetg6atdqp8ojw8cr3z1kz2ktu9z3ua3...@mail.gmail.com signature.asc Description: signature
Re: Is running dpkg-buildpackage manually from the command line forbidden?
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 emails from xnox and pabs (in CC) about it. How did it work? > I think in an ideal world, we'd have better tools for those users to build > modified packages in a way that more closely resembles what happens on the > production Debian infrastructure - which might for instance mean CI services, > or my vectis[1] tool, or sbuild-debian-developer-setup, or even autopkgtest > (which is really for testing packages, but as a side-effect, it knows how to > build packages in an environment that in practice is going to be > close-to-minimal). 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 installing Essential:yes packages and their dependencies (why doesn't it have that already?). > pbuilder and the usual sbuild+schroot setup have the disadvantage of > requiring root privileges and crossing privilege boundaries, but vectis uses > virtual machines (in practice this means kvm group membership or udev/logind > uaccess, to get write access to /dev/kvm) and as namespace/container stuff > gets more powerful and more trusted, I'd hope that we'll get a better ability > to install build-dependencies and do builds in unprivileged containers. That can be done with sbuild. With --chroot-mode=unshare, sbuild looks for rootfs tarballs in ~/.cache/sbuild or you can give it your own tarball with the --chroot option. Since you can create rootfs tarballs without sudo using mmdebstrap, you can setup arbitrary chroots and build packages without any process running with root privileges. If you don't like the security implications of unshared user namespaces, then you might want to try --chroot-mode=autopkgtest and --autopkgtest-virt-server=qemu. Using --autopkgtest-virt-server-opts you can then supply any qemu compatible system image. Using mmdebstrap with fakechroot mode and guestfish you can create these system images without becoming root and without having to enable kernel.unprivileged_userns_clone. Or if lxc/lxd are the unprivileged containers you are talking about, then you can just use --autopkgtest-virt-server=lxc and let sbuild do builds in your existing lxc container. Thanks! cheers, josch signature.asc Description: signature
Re: https://tracker.debian.org/pkg/dballe
> "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 should Paul> be very explicit rather than happen as a side effect of regular upload Paul> workflows. Since they are relatively rare, making them explicit via Paul> this mechanism shouldn't be too much of an imposition and on balance Paul> might be the right way to go. Bootstrap uploads of compilers etc are actually more common than I thought before I started following debian-release. They are common enough that requiring interactions from ftpmaster and/or release team would make being a developer of such packages suck significantly more. If we throw away binaries by default, I do believe we need a mechanism for maintainers to signal that this is a bootstrap upload. --Sam
