Bug#886717: ITP: coreapi -- Python client library for Core API

[Pierre-Elliott Bécue]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= 

* Package name: coreapi
  Version : 2.3.3
  Upstream Author : Tom Christie
* URL : https://github.com/core-api/python-client
* License : BSD
  Programming Lang: Python
  Description : Python client library for Core API

Core API is a format-independent Document Object Model for representing
Web APIs.

It can be used to represent either Schema or Hypermedia responses, and
allows one to interact with an API at the layer of an application
interface, rather than a network interface.

This package would provide a python client for such APIs. It's an
optional dependency of djangorestframework.

This package would be maintained under the DPMT flag.

-- 
PEB

Re: sysvinit-utils essentialness

[Simon McVittie]

On Tue, 09 Jan 2018 at 04:04:39 +0100, Andreas Henriksson wrote:
> Using the pidof implementation provided by procps (upstream) would
> mean we atleast use the same implementation as other distros, but
> wouldn't gain us much else and could even give us new problems.

The other gain would be that one more binary in the Essential set comes
from a source package with an active maintainer, and that the maintainers
of src:sysvinit (who appear to be too busy with other things to be unable
to respond to RC bugs at the moment[0]) can concentrate on supporting
systems that boot using the sysvinit/sysv-rc/initscripts cluster of
packages, while able to ignore all systems that boot using systemd
(and chroots/containers that don't really "boot" at all) as outside
their scope. Ian Jackson was positive about that approach in [1].

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811377#104
(I'm not saying that #872039 *should* necessarily be RC, but it's
been 4½ months without a maintainer response or a downgrade.)
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851747#56

> The most practical thing to do at this point seems to be to just wait
> until sysvinit is eventually removed from Debian

There's a circular dependency here: that can't happen, regardless of
the quality or maintenance status of sysv-rc/initscripts, as long as
sysvinit-utils is Essential. If there was consensus that booting with
sysv-rc/initscripts was no longer something the project had any interest
in, then a more likely implementation would be to simplify src:sysvinit
by removing all binary packages except sysvinit-utils, which is what's
happened in derivatives that require/assume systemd, like Ubuntu (and
if Debian was as hostile to non-systemd init systems as some people
apparently believe it is, then the same would presumably have happened
in Debian).

I agree that, if sysvinit *was* ever removed from Debian, that would be
a great time to reassess whether pidof needs to be Essential.

smcv

Bug#886238: Please introduce official nosystemd build profile

[Ian Campbell]

On Tue, 2018-01-09 at 05:03 +, Wookey wrote:
> And the reason why you'd use it for something like this is that it
> lets you upstream patches (which change dependencies) in a reasonably
> clean way.

And is the reason this is preferable to `dpkg-vendor` based stuff
because `dpkg-vendor` cannot affect debian/control in the same way
(without tricks to autogenerate control at build time)?

> Clearly a downstream distro can instead maintain patches, but we
> encourage upstreaming in general and this mechanism allows that. 

This requires that Debian defines (together with the downstream(s)) a
semantic for the profile which satisfies them. Previously in the thread
you said "I think that is up to the derivative to define" which I think
isn't the case, it has to be a Debian based policy if the patches are
to go into Debian. What happens if two downstreams have different ideas
of what a given profile should mean?

Going down this path starts to look a lot like the USE flags used by
source base distros, and while it might be tollerable as a one off it
seems likely that once the precedent is established the usage will
proliferate (noselinux, noapparmor, nodbus, noblah,...) which would
seem to go against our current principal of enabling most options if
they cause no harm if not used.

I also agree with Russ' point that on the case of `nosystemd` we
actually want to be able to support that use case in Debian, and a
profile for use by downstreams doesn't appear to satisfy that need.

Ian.

Bug#886730: ITP: python-twodict -- Simple two way ordered dictionary for Python

[Félix Sipma]

Package: wnpp
Severity: wishlist
Owner: Félix Sipma 

* Package name: python-twodict
  Version : 1.2-1
  Upstream Author : Sotiris Papadopoulos 
* URL : https://github.com/MrS0m30n3/twodict
* License : Public domain
  Programming Lang: Python
  Description : Simple two way ordered dictionary for Python

TwoWayOrderedDict is a custom dictionary in which you can get the key:value 
relationship but you can also get the value:key relationship. It also remembers 
the order in which the items were inserted and supports almost all the features 
of the build-in dict.

This package is a dependency of youtube-dl-gui, another ITP of mine.
I intend to maintain the package in the Debian Python Modules Team.


signature.asc
Description: PGP signature

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

[Guillem Jover]

Hi!

[ Thanks, I also wanted to chime in and mention this, because it seems
  other people might not be clear on the history and motivations for
  build-profiles! ]

On Mon, 2018-01-08 at 18:37:11 +, Wookey wrote:
> On 2018-01-03 13:30 +, Simon McVittie wrote:
> > On Wed, 03 Jan 2018 at 15:12:51 +0300, Hleb Valoshka wrote:
> > > Please introduce official nosystemd build profile so downstream
> > > distributions can send patches to package maintainers with
> > > systemd-less build instead of keep them in home.
> > 
> > In general, build profiles are not meant
> > to result in functional changes to packages
> > (),
> 
> This is correct for the mechanism's main/original purpose of
> bootstrapping/removing cyclic dependencies.  The idea is that you
> can't change functionality and still use a dependency with the same
> name, if you actually want to automate the bootstrap process (because
> you don't know which features of a package the depending-on package
> uses).

Exactly, pretty much because otherwise doing automatic bootstrapping
(reusing existing package names and dependency relationships) becomes
either very hard or impossible to handle or reason about.

But, indeed, when I first envisioned build-profiles [B] it was due to
the embedded case, as a way to trim down packages and dependencies,
and trying come up with something that could make things like
debian/control.in (or worse :) unnecessary. Of course I also had
bootstrapping in mind, but it was secondary at the time. Which is
funny because, the reason this got finally implemented and deployed
in Debian was due to the boostrapping side, when an alternative and
less general proposal was put forward.

  [B] 

So, yes, the distinction between the tooling implenting just mechanism,
and letting the distribution specify policy was very much on purpose.
And while we were drafting the current spec, we also had in mind making
it powerful enough to be able to handle Gentoo USE flags cases, or
provide the features necessary to make things like openembedded and
co, unnecessary.

> > The speculation about a possible nosystemd profile in
> >  is
> > not consistent with that design principle. 
> 
> Right. But I'm not sure that the principles developed around
> bootstrapping necessarily have to apply to profiles developed for
> other purposes, and especially not for downstream distros who can
> define their own policy (within reason).
> 
> The other similar example is 'embedded'. You could have an 'embedded'
> profile that did more rigorous minimisation of packages for space or
> functionality, and exactly what that meant in local policy terms would
> be defined by the derivative using it.

Yes, build-profiles can be used any way we want to. Of course reusing
package-names while breaking the package-visible interface can be
dangerous or might outright break the dependency system. So that's
why we have tried to make that very clear on the spec.

There's also a distinction (which might not always be very clear)
between user-visible and package-visible interfaces. Say if something
is exclusively a user-visible interface, then disabling it via
build-profiles could be fine.

But in any case, nothing says we cannot introduce a namespace for such
interface breaking build-profiles, say: mutable.nosystemd, mutable.nopam,
mutable.nokrb5, mutable.nonls, mutable.noselinux, etc.

> > If the nosystemd profile is (exceptionally) allowed to cause functional
> > changes, what would the policy be for this build profile? Would it be
> > acceptable for a package built with nosystemd to be unusable or have
> > incompatible behaviour if it is used on a system booted with systemd?
> 
> I think that is up to the derivative to define.

Yes and no. When we specified that specific build-profiles are
distribution policies, that means that whoever defines those
build-profiles specifies their semantics. In case downstream want to
integrate those upstream (that is, Debian for example), then we'd
need to collectively agree on the semantics. But if a downstream or
independent project defines their own profiles, because they use their
own packaging or diverge w/o problem, then they can do whatever they
want, obviously.

Given the background of build-profiles, I'm very much in favor of
introducing the equivalent usage as Gentoo USE flags, which was its
main intention! :) It could make Debian a viable source-based
distribution to use or base on, could make many of the embedded specific
distribution solutions obsolete, and might make some downstreams life
easier. Of course using one of these mutable profiles might imply some
kind of flag day for their users, because either everything you want to
use is annotated or the dependency system might be broken, but given that
Debian does not enable an

enforcing an UTF8 locale while building a package

[Norbert Preining]

Hi all,

(please Cc)

it seems that msgfmt has problems when run in a C locale, because what
is produced is not utf8 parsable.

For calibre I need proper utf8 stuff, but I don't see a way to enforce
an utf8 locale during the build process. I can depend on locales etc,
but en_US.utf8 or C.utf8 seems not to be guaranteed to be available.

What is the proper way to deal with these kind of setups?

(Please Cc)

Thanks

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: enforcing an UTF8 locale while building a package

[Andrey Rahmatullin]

On Tue, Jan 09, 2018 at 10:31:53PM +0900, Norbert Preining wrote:
> Hi all,
> 
> (please Cc)
> 
> it seems that msgfmt has problems when run in a C locale, because what
> is produced is not utf8 parsable.
> 
> For calibre I need proper utf8 stuff, but I don't see a way to enforce
> an utf8 locale during the build process. I can depend on locales etc,
> but en_US.utf8 or C.utf8 seems not to be guaranteed to be available.
No, C.UTF-8 is guaranteed to be available in Debian.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#886748: ITP: salt-pepper -- A library and stand-alone CLI tools to access a salt-api instance

[Filip Pytloun]

Package: wnpp
Severity: wishlist
Owner: Filip Pytloun 

* Package name: salt-pepper
  Version : 0.5.2
  Upstream Author : Seth House 
* URL : https://github.com/saltstack/pepper
* License : Apache-2.0
  Programming Lang: Python
  Description : A library and stand-alone CLI tools to access a salt-api 
instance

 pepperlib abstracts the HTTP calls to salt-api so existing Python projects can
 easily integrate with a remote Salt installation just by instantiating a
 class.
 .
 The pepper CLI script allows users to execute Salt commands from computers
 that are external to computers running the salt-master or salt-minion daemons
 as though they were running Salt locally.


signature.asc
Description: PGP signature

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Raphael Hertzog]

Hello,

On Thu, 04 Jan 2018, Adam Borowski wrote:
> On Thu, Jan 04, 2018 at 01:01:15PM +0100, Raphael Hertzog wrote:
> > I agree. I have plans to create email addresses like
> > team+@tracker.debian.org that could be used for this purpose.
> > The package tracker would automatically add those packages to the
> > respective team.
> 
> Sounds much better, yeah.
[...]
> So please give me something that I can stick into the maintainer field to
> have as many tools as possible DTRT.

As a first step, I have implemented team+@tracker.debian.org as
a black hole (i.e. incoming emails are dropped):
https://salsa.debian.org/qa/distro-tracker/commit/bf4706f53b4fff7c102d1355b4af72553bc96500

On Thu, 04 Jan 2018, Jeremy Bicha wrote:
> On Thu, Jan 4, 2018 at 7:01 AM, Raphael Hertzog  wrote:
> > We could then expand the use of this email address also for discussion
> > between team members.
> 
> If it looks like an email address, I think people will expect to be
> able to email it without having to join a team first. Or at least I
> think people would expect a reject message explaining what to do for
> the email to be delivered. (Maybe that's what you meant, but it wasn't
> clear to me.)

Yes, it should be usable by everybody, and not restricted to team members.

But to avoid spam, we will probably have to implement a whitelist of some
sort.

Another open question is who should get the mails sent to that address.

Currently mails should probably be sent to all team members who have not muted 
the
team and who have not disabled the "contact" keyword. But this makes it
hard to subscribe to a very large team to get the team-level messages but
not the package-level messages.

We should really have different subscriptions models:
- team emails only
- team emails and all package emails
- team emails, all package emails except for (blacklist)
- team emails, no package emails except for (whitelist)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: enforcing an UTF8 locale while building a package

[Chris Lamb]

Hi Norbert et al.,

> it seems that msgfmt has problems when run in a C locale
[…]
> [force a] utf8 locale during the build process

I'm not sure whether the following applies in the case of msgfmt;
this is more of a general remark.

One thing I picked up via the Reproducible Builds project (has it
happens to vary such things) is that simply forcing the locale in
the build (or the timezone, etc. etc.) can move errors/warnings/bugs
to our users at runtime.

In other words, simply forcing the *build* to do the right thing
can mean we are hiding issues that should be fixed elsewhere

Just as one example, a timezone library that did not work properly
in timezones beyond UTC+0800, etc. Forcing the build to be in UTC
would certainly fix the FTBFS but... *grin*


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

(was: Re: Bug#886238: Please introduce official nosystemd build profile)

[Johannes Schauer]

Quoting Wookey (2018-01-09 06:03:26)
> On 2018-01-08 20:36 -0500, Michael Stone wrote:
> > How, then, would you tell by looking at the package name+version which kind
> > of package you have? 
> The package header says what profiles it was built with. The package
> name+version doesn't change - that's part of the point. No-one should be
> trying to put more than one instance of a package built with different
> profiles in one repo at one time because stuff will break. But a downstream
> distro could enable a profile and build everything that way and that should
> be fine.

No, there is no header in the binary packages that indicates with which profile
a source package was built to generate the given binary package.

Such a header could be introduced but that would be undesirable for two
reasons:

 - it would make it hard to check whether the binary packages a source package
   produces are really not different with a certain build profile active. Right
   now, because of the lack of such a header, we can use the tools from the
   reproducible builds project to verify that a build profile does not tamper
   with package contents

 - right now, a package is uniquely defined by dependency solvers through their
   the name/version/architecture tuple. It would be possible to make this a
   quadruplet and let packages be unique by their
   name/version/architecture/profile property but that would require massive
   changes in even more parts of our infrastructure than the introduction of
   build profiles already required.

Thus, we keep packages built with a different build profile but the same
name/version/arcitecture bit-by-bit identical to each other.

> > If you're going to change the name or version string anyway, why use some
> > complicated profile system instead of just applying a patch?
> 
> It's not really complicated. It's just a mechanism for variant package
> builds which is formalised in dpkg and related tools (without changing
> the package name/version).
> 
> And the reason why you'd use it for something like this is that it
> lets you upstream patches (which change dependencies) in a reasonably
> clean way.
> 
> Clearly a downstream distro can instead maintain patches, but we encourage
> upstreaming in general and this mechanism allows that.

One has to differentiate between the implementation of build profiles and the
policy of how we want to use them in Debian.

Technically speaking you are correct. We can add any arbitrary functionality or
build dependencies or package sets that are activated or deactivated through a
certain set of build profiles. It is up to the derivatives which policy they
use for the technical possibilities that build profiles offer.

So here on this list we can discuss the policies that we want to use for build
profiles in Debian. As others already explained, a nosystemd profile does not
make much sense, even if it were fine to change binary package contents. So we
could talk about whether we should allow more build profiles that change binary
package contents but so far I don't see the use case for them and thus the
discussion would be a bit academic.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: enforcing an UTF8 locale while building a package

[Andrey Rahmatullin]

On Tue, Jan 09, 2018 at 11:52:47PM +0900, Norbert Preining wrote:
> > No, C.UTF-8 is guaranteed to be available in Debian.
> 
> Thanks, good to know - I couldn't find it/set it up, but this is
> probably my very old chroot.
It's avaiable only since libc-bin 2.13-1 (so since wheezy I think).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: enforcing an UTF8 locale while building a package

[Norbert Preining]

> No, C.UTF-8 is guaranteed to be available in Debian.

Thanks, good to know - I couldn't find it/set it up, but this is
probably my very old chroot.

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: enforcing an UTF8 locale while building a package

[Norbert Preining]

Hi Chris,

> In other words, simply forcing the *build* to do the right thing
> can mean we are hiding issues that should be fixed elsewhere

Indeed, but in this case it was simply a .mo file based on a latin1
encoding instead of UTF8, while the main program was loading/running
the files/translations always in utf8.

It is fixed already, there was a bug in the source tar ball that was
fixed a few hours after the initial release, but I got the bad one :-(
Upload of new calibre done.

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: enforcing an UTF8 locale while building a package

[Norbert Preining]

> It's avaiable only since libc-bin 2.13-1 (so since wheezy I think).

Ah, that explains why not in my case. Thanks!

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: (was: Re: Bug#886238: Please introduce official nosystemd build profile)

[Wookey]

On 2018-01-09 15:07 +0100, Johannes Schauer wrote:
> Quoting Wookey (2018-01-09 06:03:26)
> > On 2018-01-08 20:36 -0500, Michael Stone wrote:
> > > How, then, would you tell by looking at the package name+version which 
> > > kind
> > > of package you have? 
> > The package header says what profiles it was built with. The package
> > name+version doesn't change - that's part of the point. 
> 
> No, there is no header in the binary packages that indicates with which 
> profile
> a source package was built to generate the given binary package.

Oh. OK. My bad - apologies for putting bad info in this already-long
thread.  This was definitiely something we considered along the way
and I had thought it got implemented. Ah and in fact it did, but has
since been removed for reproducible-build compatibility, so I'm out
of date, not wrong :-)

An aside, but I'm not convinced this was the right thing to do. A
reproducible build doesn't mean 'reproductible even if you do
different things, like use a different build profile'. Having the
header had utility.

> Thus, we keep packages built with a different build profile but the same
> name/version/arcitecture bit-by-bit identical to each other.

OK, so the mechanism has morphed quite a lot from Guillem's (and then
my) original ideas, in the light of actually using it, to essentially
only be used at package granularity. And that makes sense because it
preserves the 'name/version/arch' tuple as a dependency identifier.

However we do have 'nodoc', which can't possibly produce bit-by-bit
identical packages (unless the docs are in a separate package) so I
don't see how it can be right to say "packages built with a different
build profile but the same name/version/arcitecture are bit-by-bit
identical to each other". Are you saying that you can't use nodoc if
there are docs in a package, or at least that you can only use it as a
build option, not a build profile?

Again, this is very much policy, not mechanism, and seems to me to be
more restrictive than is necessary.

> Technically speaking you are correct. We can add any arbitrary functionality 
> or
> build dependencies or package sets that are activated or deactivated through a
> certain set of build profiles. It is up to the derivatives which policy they
> use for the technical possibilities that build profiles offer.
> 
> So here on this list we can discuss the policies that we want to use for build
> profiles in Debian. As others already explained, a nosystemd profile does not
> make much sense, even if it were fine to change binary package contents. So we
> could talk about whether we should allow more build profiles that change 
> binary
> package contents but so far I don't see the use case for them and thus the
> discussion would be a bit academic.

I was talking about the general case of the possibilities of use for
build profiles. I have no strong opinion on how well that works in the
particular nosystemd case as I've not followed all that
discussion.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: build profiles and functional differences

[Simon McVittie]

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 possibly produce bit-by-bit
> identical packages (unless the docs are in a separate package) so I
> don't see how it can be right to say "packages built with a different
> build profile but the same name/version/arcitecture are bit-by-bit
> identical to each other".

The policy on the wiki is phrased in terms of no functional differences,
and ideally no differences at all. Missing some man pages is a difference,
but hopefully not one that matters when satisfying dependencies.

(One interesting example of documentation being a functional
difference is that it's *technically* not right to omit gtk-doc
documentation from a package under the nodoc build profile, because
other packages with Build-Depends-Indep on that documentation can use
it to rewrite cross-references from web links into relative local file
references. Luckily most libraries that are documented with gtk-doc
build a separate -doc package for other reasons anyway, so that
package can easily be marked Build-Profiles: .)

> Again, this is very much policy, not mechanism

Yes. You've been in Debian longer than I have; surely you know by now
how much importance we put on policies? :-)

smcv

Re: (was: Re: Bug#886238: Please introduce official nosystemd build profile)

[Jeremy Bicha]

On Tue, Jan 9, 2018 at 9:07 AM, Johannes Schauer  wrote:
> So we
> could talk about whether we should allow more build profiles that change 
> binary
> package contents but so far I don't see the use case for them and thus the
> discussion would be a bit academic.

Ok, let me try to provide a more practical use case for you then.

At times, Ubuntu needs to avoid certain build-dependencies because
they would add an unwanted "universe" binary dependency to a "main"
package. In some cases, that is the *only* change Ubuntu makes to the
package. I believe it benefits Debian for Ubuntu and Debian packaging
to be as shared as much as possible.

https://launchpad.net/bugs/1734339

Thanks,
Jeremy Bicha

ITP: golang-github-14rcole-gopopulate -- A small library to populate a directory with random data

[Hector Oron]

Package: wnpp
Severity: wishlist
Owner: Héctor Orón Martínez 

* Package name: golang-github-14rcole-gopopulate
  Version : 0.0~git20171207.91c73a7-1
  Upstream Author : Ryan Cole
* URL : https://github.com/14rcole/gopopulate
* License : MIT License
  Programming Lang: Go
  Description : A small library to populate a directory with random data

 populate a directory with random data. This package is used for ostree Go
 bindings testing.

 This is a build dependency for `debos' Go application.

-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.


-- Would you like to make a donation for Debian Conference?
   ** http://debconf18.debconf.org/ **

ITP: golang-github-ostreedev-ostree-go -- Golang bindings for OSTree

[Hector Oron]

Package: wnpp
Severity: wishlist
Owner: Héctor Orón Martínez 

* Package name: golang-github-ostreedev-ostree-go
  Version : 0.0~git20171027.cb6250d-1
  Upstream Author : OSTree Project
* URL : https://github.com/ostreedev/ostree-go
* License : ISC
  Programming Lang: Go
  Description : Golang bindings for OSTree

 OSTree-Go Go bindings for OSTree. Find out more about OSTree here
 (https://github.com/ostreedev/ostree)

-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.


-- Would you like to make a donation for Debian Conference?
   ** http://debconf18.debconf.org/ **

ITP: go-flags -- go command line option parser

[Hector Oron]

Package: wnpp
Severity: wishlist
Owner: Héctor Orón Martínez 

* Package name: go-flags
  Version : 1.3.0+git20170926.f88afde-1
  Upstream Author : Jesse van den Kieboom
* URL : https://github.com/jessevdk/go-flags
* License : BSD-3-clause
  Programming Lang: Go
  Description : go command line option parser

 go-flags: Go library for parsing command line arguments
 .
 This library provides similar functionality to the builtin flag library
 of Go, but provides much more functionality and nicer formatting. From
 the documentation:
 .
 Package flags provides an extensive command line option parser.  The flags
 package is similar in functionality to the go builtin flag package but
 provides more options and uses reflection to provide a convenient and
 succinct way of specifying command line options.
 .
 More information can be found in the godocs:
 http://godoc.org/github.com/jessevdk/go-flags

 This is build dependency for `debos' Go application.

-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.


-- Would you like to make a donation for Debian Conference?
   ** http://debconf18.debconf.org/ **

ITP: fakemachine -- create and spawn virtual machines

[Hector Oron]

Package: wnpp
Severity: wishlist
Owner: Héctor Orón Martínez 

* Package name: fakemachine
  Version : 0.0~git20171207.6af110d-1
  Upstream Author : Sjoerd Simons 
* URL : https://github.com/go-debos/fakemachine
* License : Apache-2.0
  Programming Lang: Go
  Description : create and spawn virtual machines

  Create and spawn virtual machines for building images with debos tool.

  This is a build dependency for `debos'.

-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.


-- Would you like to make a donation for Debian Conference?
   ** http://debconf18.debconf.org/ **

ITP: debos -- Debian OS builder

[Hector Oron]

Package: wnpp
Severity: wishlist
Owner: Héctor Orón Martínez 

* Package name: debos
  Version : 1.0.0+git20171222.87b0d5e-1
  Upstream Author :
* URL : https://github.com/go-debos/debos
* License : Apache-2.0
  Programming Lang: Go
  Description : Debian OS builder

 debos Debian OS builder. debos is a tool to make creation of various
 debian based os "images" simpler. While most other tools focus on
 specific use-case, debos is more meant as a toolchain to make comon
 actions trivial while providing enough rope to do whatever tweaking that
 might be required behind the scene.
 debos Debian OS builder. debos is a tool to make creation of various
 debian based os "images" simpler. While most other tools focus on
 specific use-case, debos is more meant as a toolchain to make comon
 actions trivial while providing enough rope to do whatever tweaking that
 might be required behind the scene.
 .
 debos expects a yaml file as input, syntax description can be found at:
   https://godoc.org/github.com/go-debos/debos/actions
 .
 and examples are to be found at:
   https://github.com/go-debos/debos-recipes

-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.


-- Would you like to make a donation for Debian Conference?
   ** http://debconf18.debconf.org **

Re: (was: Re: Bug#886238: Please introduce official nosystemd build profile)

[Michael Stone]

On Tue, Jan 09, 2018 at 11:35:30AM -0500, Jeremy Bicha wrote:

At times, Ubuntu needs to avoid certain build-dependencies because
they would add an unwanted "universe" binary dependency to a "main"
package. In some cases, that is the *only* change Ubuntu makes to the
package. I believe it benefits Debian for Ubuntu and Debian packaging
to be as shared as much as possible.

https://launchpad.net/bugs/1734339


$64k question: does having to maintain some notion of which build 
profiles to use for a package (and actually maintaining the build 
profile upstream) end up being less effort than a couple of lines of 
patch to remove a dependency?


Mike Stone

Re: ITP: go-flags -- go command line option parser

[Michael Hudson-Doyle]

This is already packaged, as golang-go-flags-dev or something like that.

On 10/01/2018 7:08 AM, "Hector Oron"  wrote:

Package: wnpp
Severity: wishlist
Owner: Héctor Orón Martínez 

* Package name: go-flags
  Version : 1.3.0+git20170926.f88afde-1
  Upstream Author : Jesse van den Kieboom
* URL : https://github.com/jessevdk/go-flags
* License : BSD-3-clause
  Programming Lang: Go
  Description : go command line option parser

 go-flags: Go library for parsing command line arguments
 .
 This library provides similar functionality to the builtin flag library
 of Go, but provides much more functionality and nicer formatting. From
 the documentation:
 .
 Package flags provides an extensive command line option parser.  The flags
 package is similar in functionality to the go builtin flag package but
 provides more options and uses reflection to provide a convenient and
 succinct way of specifying command line options.
 .
 More information can be found in the godocs:
 http://godoc.org/github.com/jessevdk/go-flags

 This is build dependency for `debos' Go application.

--
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.


-- Would you like to make a donation for Debian Conference?
   ** http://debconf18.debconf.org/ **

Re: Bug#886238: Please introduce official nosystemd build profile

[Sam Hartman]

> "Russ" == Russ Allbery  writes:


Russ, I'm somewhat confused by the above.
It sounds like Debian as a whole is fairly OK with dependencies on
libsystemd0 etc.
We want systems to run without systemd as pid 1 but we don't mind
systemd libraries being installed.

I thought the point here was to provide build profiles for building
without depending on the systemd libraries.
I don't understand why Debian itself would want that?

--Sam

Re: Bug#886238: Please introduce official nosystemd build profile

[Russ Allbery]

Sam Hartman  writes:

> Russ, I'm somewhat confused by the above.
> It sounds like Debian as a whole is fairly OK with dependencies on
> libsystemd0 etc.
> We want systems to run without systemd as pid 1 but we don't mind
> systemd libraries being installed.

> I thought the point here was to provide build profiles for building
> without depending on the systemd libraries.
> I don't understand why Debian itself would want that?

The discussion has forked into a serious discussion about how to enable
software to run properly without systemd being PID 1, and a separate
discussion about attempting to build without libsystemd.

The latter serves no actual purpose that anyone can discern other than
getting software to build on systems where libsystemd doesn't exist at all
(Hurd, etc.), which currently is already largely solved via architecture
exclusions and arguably even better solved via libsystemd-dummy (which
already exists but needs some love).  My impression was that we'd already
put that discussion mostly to rest.

I was therefore remarking on the former point: how to enable software to
run properly without systemd being PID 1, something that Debian also
wants, and for which a build profile seems like a very poor fit.

-- 
Russ Allbery (r...@debian.org)   

Re: (was: Re: Bug#886238: Please introduce official nosystemd build profile)

[Adrian Bunk]

On Tue, Jan 09, 2018 at 01:22:33PM -0500, Michael Stone wrote:
> On Tue, Jan 09, 2018 at 11:35:30AM -0500, Jeremy Bicha wrote:
> > At times, Ubuntu needs to avoid certain build-dependencies because
> > they would add an unwanted "universe" binary dependency to a "main"
> > package. In some cases, that is the *only* change Ubuntu makes to the
> > package. I believe it benefits Debian for Ubuntu and Debian packaging
> > to be as shared as much as possible.
> > 
> > https://launchpad.net/bugs/1734339
> 
> $64k question: does having to maintain some notion of which build profiles
> to use for a package (and actually maintaining the build profile upstream)
> end up being less effort than a couple of lines of patch to remove a
> dependency?

We already have plenty of packages that use dpkg-vendor to check for 
ubuntu or raspbian in debian/rules, and adding something similar for 
build dependencies would sound reasonable to me.

> Mike Stone

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

[Adrian Bunk]

On Tue, Jan 09, 2018 at 01:23:32PM +0100, Guillem Jover wrote:
>...
> Given the background of build-profiles, I'm very much in favor of
> introducing the equivalent usage as Gentoo USE flags, which was its
> main intention! :) It could make Debian a viable source-based
> distribution to use or base on, could make many of the embedded specific
> distribution solutions obsolete,
>...

Who would then implement, maintain and support this in all packages?

Implementing that global flags like
  USE="-systemd -alsa -pulseaudio -wayland"
work across all 30k source packages would be a huge amount of work.

And then supporting that any combination of disabling/enabling various 
flags builds and works for all packages at the quality level people 
expect from a Debian stable - that's completely out of scope of what 
Debian could achieve with its already stretched developer resources.

> Thanks,
> Guillem

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#886783: ITP: coreschema -- Python utilities to describe an abstract data schema to coreapi

[Pierre-Elliott Bécue]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= 

* Package name: coreschema
  Version : 0.0.4
  Upstream Author : Tom Christie 
* URL : https://github.com/core-api/python-coreschema
* License : BSD
  Programming Lang: Python
  Description : Python utilities to describe an abstract data schema to 
coreapi

Core API is a format-independent Document Object Model for representing
Web APIs.

It can be used to represent either Schema or Hypermedia responses, and
allows one to interact with an API at the layer of an application
interface, rather than a network interface.

This package, which is required by coreapi, provides an abstract Python library
to describe classic data (Integers, Strings et al.).

This package would be maintained under DPMT umbrella.

-- 
PEB

Bug#886786: ITP: python-jsonhyperschema-codec -- A JSON Hyperschema codec for Core API.

[Pierre-Elliott Bécue]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= 

* Package name: python-jsonhyperschema-codec
  Version : 1.0.2
  Upstream Author : Tom Christie 
* URL : https://github.com/core-api/python-jsonhyperschema-codec
* License : BSD
  Programming Lang: Python
  Description : A JSON Hyperschema codec for Core API.

Core API is a format-independent Document Object Model for representing
Web APIs.

It can be used to represent either Schema or Hypermedia responses, and
allows one to interact with an API at the layer of an application
interface, rather than a network interface.

This package provides a third-party codec to coreapi in order to allow it
to support jsonhyperschema.

-- 
PEB

Bug#886787: ITP: r-cran-whisker -- GNU R mustache, logicless templating

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-whisker
  Version : 0.3-2
  Upstream Author : Edwin de Jonge 
* URL : https://cran.r-project.org/package=whisker
* License : GPL
  Programming Lang: GNU R
  Description : GNU R mustache, logicless templating
 This GNU R package enables logicless templating, reuse templates in many
 programming languages including R.


Remark: This package will be maintained by the r-pkg-team.  Since there
is no list for the packaging team yet the Debian Science maintainers list
is used for the moment.  The repository is
https://salsa.debian.org/r-pkg-team/r-cran-whisker.git

Bug#886788: ITP: python-hal-codec -- A HAL codec for Core API

[Pierre-Elliott Bécue]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= 

* Package name: python-hal-codec
  Version : 1.0.2
  Upstream Author : Tom Christie 
* URL : https://github.com/core-api/python-hal-codec
* License : BSD
  Programming Lang: Python
  Description : A HAL codec for Core API

Core API is a format-independent Document Object Model for representing
Web APIs.

It can be used to represent either Schema or Hypermedia responses, and
allows one to interact with an API at the layer of an application
interface, rather than a network interface.

This package provides a third-party codec to handle HAL Hypermedia
format.

This package would be maintained unter the DPMT roof.

-- 
PEB

Bug#886789: ITP: python-openapi-codec -- An OpenAPI codec for Core API

[Pierre-Elliott Bécue]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= 

* Package name: python-openapi-codec
  Version : 1.3.2
  Upstream Author : Tom Christie 
* URL : https://github.com/core-api/python-openapi-codec
* License : BSD
  Programming Lang: Python
  Description : An OpenAPI codec for Core API

Core API is a format-independent Document Object Model for representing
Web APIs.

It can be used to represent either Schema or Hypermedia responses, and
allows one to interact with an API at the layer of an application
interface, rather than a network interface.

This package provides a third-party codec for core API to support OpenAPI
format.

This package would be maintained under the DPMT sky.

-- 
PEB

Re: build profiles and functional differences

[Johannes Schauer]

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.
> > However we do have 'nodoc', which can't possibly produce bit-by-bit
> > identical packages (unless the docs are in a separate package) so I
> > don't see how it can be right to say "packages built with a different
> > build profile but the same name/version/arcitecture are bit-by-bit
> > identical to each other".
> 
> The policy on the wiki is phrased in terms of no functional differences,
> and ideally no differences at all. Missing some man pages is a difference,
> but hopefully not one that matters when satisfying dependencies.
> 
> (One interesting example of documentation being a functional
> difference is that it's *technically* not right to omit gtk-doc
> documentation from a package under the nodoc build profile, because
> other packages with Build-Depends-Indep on that documentation can use
> it to rewrite cross-references from web links into relative local file
> references. Luckily most libraries that are documented with gtk-doc
> build a separate -doc package for other reasons anyway, so that
> package can easily be marked Build-Profiles: .)

If you look at the table at [1] then you will see that there are exactly four
profile names that allow changes. The pkg.$source.$foo namespace where any kind
of change is allowed and the stage1, stage2 and nodoc profiles where changes
are limited to non-functional changes. The nodoc profile is interesting here
because when we talk about not making "functional" changes to packages, then
this is because we don't want to break assumptions made by other packages
depending on it. 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. [6] Any files that are used or read by programs but are
 | also useful as stand alone documentation should be installed elsewhere, such
 | as under /usr/share/package/, and then included via symbolic links in
 | /usr/share/doc/package.

So by that logic gtk-doc documentation should be put into /usr/share/package
because it is "read by programs" to rewrite cross-references from web links as
you say.

When we we added this exception to the nodoc profile, we thought that given
this policy paragraph, it logically followed that we could allow non-functional
changes here. This exception is indeed interesting and I guess it's debatable
whether generating "cross-references" counts as something a package needs "in
order to function" such that it falls under this "must" clause of Debian
policy.

But I'll leave figuring this out to somebody else. :)

Thanks!

cheers, josch

[1] https://wiki.debian.org/BuildProfileSpec#Registered_profile_names


signature.asc
Description: signature

Re: (was: Re: Bug#886238: Please introduce official nosystemd build profile)

[Johannes Schauer]

Quoting Adrian Bunk (2018-01-09 20:54:31)
> On Tue, Jan 09, 2018 at 01:22:33PM -0500, Michael Stone wrote:
> > On Tue, Jan 09, 2018 at 11:35:30AM -0500, Jeremy Bicha wrote:
> > > At times, Ubuntu needs to avoid certain build-dependencies because
> > > they would add an unwanted "universe" binary dependency to a "main"
> > > package. In some cases, that is the *only* change Ubuntu makes to the
> > > package. I believe it benefits Debian for Ubuntu and Debian packaging
> > > to be as shared as much as possible.
> > > 
> > > https://launchpad.net/bugs/1734339
> > $64k question: does having to maintain some notion of which build profiles
> > to use for a package (and actually maintaining the build profile upstream)
> > end up being less effort than a couple of lines of patch to remove a
> > dependency?
> We already have plenty of packages that use dpkg-vendor to check for ubuntu
> or raspbian in debian/rules, and adding something similar for build
> dependencies would sound reasonable to me.

Currently, the value of the Build-Depends field is just copied to the final
source package without making modifications. This is in contrast to the Depends
fields of the binary packages in debian/control which can get mangled depending
on their architecture annotations or substvars. What you propose would require
mangling the Build-Depends field at build-time which is a bad idea for several
reasons. Check out the following bugs:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677474

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751437

Thanks!

cheers, josch


signature.asc
Description: signature

Re: Why do we list individual copyright holders?

[Adrian Bunk]

On Fri, Dec 22, 2017 at 08:51:37AM -0500, Scott Kitterman wrote:
>...
> I intend to work within the FTP Team to get some clarification on the team's 
> position on this, but I don't expect it to be quick.  I agree we could do 
> with 
> better documentation of what the policy is and why.
>...

Thanks for doing this.

One result of a clear policy with rationale should be that it gets 
applied without any too-big-too-fail exceptions to all packages that 
pass through NEW.

This would remove the perception that e.g. src:linux seems to be able to 
pass NEW all the time with a debian/copyright that would result in a 
reject for every other package - either a requirement is enforced for 
all packages, or it clearly isn't required.

src:linux, where complete authorship information is often not easily 
available [1] and copyright ownership information is in many cases not 
available at all [2], would actually be a good litmus test for what 
requirements are workable in practice. With the Linux Foundation behind 
the kernel and lawsuits around kernel copyright already taken place, 
there should also be plenty of lawyer opinion available and implemented 
regarding what copyright information is actually required in the real 
world for (corporate) users worldwide.

A new debian/copyright for src:linux could also be a good example
to be published together with the documentation of this policy to
make it clear what copyright information the ftp team requires
from non-trivial packages.

> Scott K
>...

cu
Adrian

BTW: My pet rant about debian/copyright is that too much emphasis
 is placed on the copyright years that are usually irrelevant,
 since copyright expires no earlier than 50 years [3] after
 the death of the author.[4][5]

BTW2: IANAL


[1] especially from the pre-git times
[2] for none of the 2k commits that have me as author is the
information available whether the copyright is owned by me,
employer or 3rd party customer
[3] in some places longer, e.g. the EU has 70 years after death
[4] an author could be in one of the few countries that are not a party 
to the Berne Convention, but at that point we already hit the 
complete lack of information about the applicable copyright law
[5] the Berne Convention convention is from 1886 (sic) but the
US only joined in 1989; many formalities around copyright
people in the US have heard of are from the pre-1989 rules
how copyright had to be registered in the US - now copyright
is automatic in the US just like everywhere else

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Derivative specific build profiles (was: Re: Bug#886238: Please introduce official nosystemd build profile)

[Johannes Schauer]

Quoting Jeremy Bicha (2018-01-09 17:35:30)
> On Tue, Jan 9, 2018 at 9:07 AM, Johannes Schauer  wrote:
> > So we
> > could talk about whether we should allow more build profiles that change 
> > binary
> > package contents but so far I don't see the use case for them and thus the
> > discussion would be a bit academic.
> 
> Ok, let me try to provide a more practical use case for you then.
> 
> At times, Ubuntu needs to avoid certain build-dependencies because
> they would add an unwanted "universe" binary dependency to a "main"
> package. In some cases, that is the *only* change Ubuntu makes to the
> package. I believe it benefits Debian for Ubuntu and Debian packaging
> to be as shared as much as possible.
> 
> https://launchpad.net/bugs/1734339

That bug references [1] which lists reason for why derivative specific build
profiles are a bad idea. Even though I wrote most of the page it is of course
not up to me whether Debian at large thinks that derivative specific build
profiles are a good or bad idea. But if you want to discuss this topic, then
here are the downsides I see:

 - They are not self-explanatory. Building with nofoo active makes it clear
   that the source package is built without foo. What does it mean to build
   with the profile for ubuntu active, the profile for mint deactivated but at
   the same time the profile for kali active? Remember that more than one build
   profile can be enabled at a time. The same bug even admits that the src:git
   example could be solved with a nopcre2 build profile instead of a
   distribution specific profile.

 - What is more maintainable? This:

  ifeq (,$(filter ubuntu kali raspian steamos elementaryos, 
$(DEB_BUILD_PROFILES)))

   or this:

  ifeq (,$(filter nofoo, $(DEB_BUILD_PROFILES)))

   Who maintains the list of downstreams that we support? Who cleans up the
   archive once one of our downstreams is not maintained anymore? Who decides
   which downstreams are eligible to be included in every package that wants
   them? How do we prevent bitrot if we list all derivatives specifically?

 - Learning from others: Gentoo has a similar concept with USE flags and they
   also have downstreams but they do did not introduce derivative specific USE
   flags.

I thus believe that the superior solution is to name build profiles after the
feature that they modify. Then each downstream can pick and choose which set of
build profiles they activate when they build packages.

Thanks!

cheers, josch

[1] https://wiki.debian.org/BuildProfileSpec#Derivative_specific_profiles


signature.asc
Description: signature

Bug#886800: ITP: python-itypes -- Python basic immutable containers types library.

[Pierre-Elliott Bécue]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= 

* Package name: itypes
  Version : 1.1.0
  Upstream Author : Tom Christie 
* URL : https://github.com/tomchristie/itypes
* License : BSD
  Programming Lang: Python
  Description : Python basic immutable containers types library.

This package provides basic immutable container types for Python.

Upstream source code is designed for simplicity over performance.

The classic use case of these is in circumstances where it may result in more
comprehensible code, or when one wants to create custom types with restricted,
immutable interfaces.

This package is a dependency of coreapi, and will be maintained under DPMT
banner.

-- 
PEB

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

[Sam Hartman]

> "Adrian" == Adrian Bunk  writes:

Adrian> On Tue, Jan 09, 2018 at 01:23:32PM +0100, Guillem Jover wrote:
>> ...  Given the background of build-profiles, I'm very much in
>> favor of introducing the equivalent usage as Gentoo USE flags,
>> which was its main intention! :) It could make Debian a viable
>> source-based distribution to use or base on, could make many of
>> the embedded specific distribution solutions obsolete, ...

Adrian> Who would then implement, maintain and support this in all
Adrian> packages?

No one.  People would implement and test the feature where it was
sufficiently useful to implement and test.  I don't think all of the use
flags combinations are tested in source distributions that have them
today.

Even so, users find those flags useful enough to spend a fair bit of
work on them.

A build profile seems like a great way to express the flag, and like
many things in Debian, the work would fall on those who would benefit
from it.

So, I do support the use of build profiles for use flags.
I also believe there's sufficient utility for downstreams and users to
justify this.

--Sam

Re: build profiles and functional differences

[Simon McVittie]

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 documentation should be put into /usr/share/package
> because it is "read by programs" to rewrite cross-references from web links as
> you say.

Arguably yes. A significant number of packages that ship gtk-doc (about
half of what's on my laptop) put it in /usr/share/gtk-doc/html (which
is necessary anyway because it's where gtk-doc and devhelp will look),
with a symlink in /usr/share/doc/$package; IMO that's correct. The
other half are the other way round, with the real documentation in
/usr/share/doc/$package and a symlink in /usr/share/gtk-doc/html.

(It doesn't particularly matter in practice, because gtk-doc HTML tends
to be large enough that maintainers want to break it out into libfoo-doc,
which means the sort of people who want to delete /usr/share/doc will
just not install it.)

smcv

Re: (was: Re: Bug#886238: Please introduce official nosystemd build profile)

[Paul Wise]

On Tue, Jan 9, 2018 at 10:07 PM, Johannes Schauer wrote:

> No, there is no header in the binary packages that indicates with which 
> profile
> a source package was built to generate the given binary package.

Is this information present in the new buildinfo files?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: (was: Re: Bug#886238: Please introduce official nosystemd build profile)

[Johannes Schauer]

Quoting Paul Wise (2018-01-10 02:40:07)
> On Tue, Jan 9, 2018 at 10:07 PM, Johannes Schauer wrote:
> > No, there is no header in the binary packages that indicates with which
> > profile a source package was built to generate the given binary package.
> Is this information present in the new buildinfo files?

Yes. When --build-profiles option of dpkg-buildpackage sets the
DEB_BUILD_PROFILES environment variable. The value of that variable is captured
in the Environment field of the generated buildinfo file.

Thanks!

cheers, josch


signature.asc
Description: signature