Bug#886815: ITP: r-cran-git2r -- GNU R access to Git repositories

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-git2r
  Version : 0.21.0
  Upstream Author : Stefan Widgren 
* URL : https://cran.r-project.org/package=git2r
* License : GPL
  Programming Lang: GNU R
  Description : GNU R access to Git repositories
 This GNU R package provides an interface to the 'libgit2' library, which is
 a pure C implementation of the 'Git' core methods. Provides access to 'Git'
 repositories to extract data and running some basic 'Git' commands.


Remark: I'm currently trying to get all dependencies for Shiny-Server
and this package is one of these.  It will be maintained in r-pkg-team
(since there is no mailing list yet
debian-science-maintain...@lists.alioth.debian.org is used as
Maintainer).  The maintenance repository is

https://salsa.debian.org/r-pkg-team/r-cran-git2r.git

Bug#886819: ITP: aims-live -- Live media package for AIMS Desktop

[Jonathan Carter]

Package: wnpp
Severity: wishlist
Owner: Jonathan Carter 

* Package name: aims-live
  Version : 10.0.1
  Upstream Author : AIMS Desktop Team 
* URL : https://salsa.debian.org/aims-desktop-team/aims-live
* License : GPL-2
  Programming Lang: metapackage, shell
  Description : Live media package for AIMS Desktop

This package is part of AIMS Desktop.

It provides:

 - The dependencies in order to boot up a system from live media such
   as a DVD-RW disc or a USB disk.
 - Settings for Calamares, the installer framework used to install
   AIMS Desktop.
 - A list of conflicts that are used during the installation process
   in order to remove unwanted or very large packages.

For more information about AIMS Desktop, see: https://desktop.aims.ac.za

Bug#886821: ITP: aims-desktop -- AIMS Desktop main meta-package

[Jonathan Carter]

Package: wnpp
Severity: wishlist
Owner: Jonathan Carter 

* Package name: aims-desktop
  Version : 10.0.1
  Upstream Author : AIMS Desktop Team 
* URL : https://desktop.aims.ac.za
* License : GPL-2
  Programming Lang: metapackage, shell
  Description : AIMS Desktop main meta-package

This metapackage configures an AIMS Desktop system and installs
related artwork, a large ammount of utilities and scientific packages
including Jupyter, RStudio, Sagemath and Texmaker.

It will be team maintained in salsa.

Bug#886824: ITP: aims-artwork -- wallpapers, icons and other assets used in AIMS Desktop

[Jonathan Carter]

Package: wnpp
Severity: wishlist
Owner: Jonathan Carter 

* Package name: aims-artwork
  Version : 10.0.1
  Upstream Author : AIMS Desktop packages 
* URL : https://salsa.debian.org/aims-desktop-team/aims-artwork
* License : GPL-2
  Programming Lang: data
  Description : wallpapers, icons and other assets used in AIMS Desktop

Contains wallpaper, icons, theming and other assets used in AIMS Desktop.

This will be team maintained in salsa:
https://salsa.debian.org/aims-desktop-team/aims-artwork

Bazy biznesowe

[Adam Strzelecki]

Witam,

Chciałem zaproponować skorzystanie z oferty bazy danych biznesowych. Baza jest 
aktualna na 31 grudnia 2017, zawiera ponad 4 miliony rekordów, w tym ponad 700 
tys. adresów e-mail. Bazę można segregować według branż, województw, 
zatrudnienia, daty powstania i innych kryteriów. 
Jeżlei to Państwa interesuje - proszę odpowiedzieć na tego maila wpisując w 
treści TAK - wtedy będę mógł przekazać szczegółowe dane, a także próbkę bazy do 
sprawdzenia. 

z poważaniem,
Adam Strzelecki 



Aby zrezygnować z podobnych zapytań proszę o informację zwrotną.

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

[Geert Stappers]

On Wed, Jan 10, 2018 at 07:47:20AM +1300, Michael Hudson-Doyle wrote:
> 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 is already packaged, as golang-go-flags-dev or something like that.

https://tracker.debian.org/pkg/golang-go-flags

and there is also

https://tracker.debian.org/pkg/golang-github-svent-go-flags

both originate from https://github.com/jessevdk/go-flags

both packages are maintaint by pkg-go-maintain...@lists.alioth.debian.org


Closing this ITP  could be an option.



Groeten
Geert Stappers
-- 
Leven en laten leven

two packages of https://github.com/jessevdk/go-flags

[Geert Stappers]

Control: retitle -1  two packages of https://github.com/jessevdk/go-flags

On Wed, Jan 10, 2018 at 01:47:06PM +0100, Geert Stappers wrote:
> On Wed, Jan 10, 2018 at 07:47:20AM +1300, Michael Hudson-Doyle wrote:
> > On 10/01/2018 7:08 AM, "Hector Oron"  wrote:
> > > Package: wnpp
> > > 
> > > * Package name: go-flags
> > >   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 is already packaged, as golang-go-flags-dev or something like that.
> 
> https://tracker.debian.org/pkg/golang-go-flags
> 
> and there is also
> 
> https://tracker.debian.org/pkg/golang-github-svent-go-flags
> 
> both originate from https://github.com/jessevdk/go-flags
> 
> both packages are maintaint by pkg-go-maintain...@lists.alioth.debian.org
> 
> 
> Closing this ITP  could be an option.

Using this bugreport for discussion what to do with
the "duplicate" is another option.


Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#886838: ITP: python-pygerrit2 -- Python library to interact with Gerrit Code Review via the REST API

[Filip Pytloun]

Package: wnpp
Severity: wishlist
Owner: Filip Pytloun 

* Package name: python-pygerrit2
  Version : 2.0.4
  Upstream Author : David Pursehouse 
* URL : https://github.com/dpursehouse/pygerrit2
* License : Expat
  Programming Lang: Python
  Description : Client library to interact with Gerrit Code Review via the 
REST API

pygerrit2 is simple Python library to provide interface to interact with
Gerrit Code Review via it's REST API.


signature.asc
Description: PGP signature

Bug#886843: ITP: node-yn -- Parse yes/no like values - Node.js module

[Paolo Greppi]

Package: wnpp
Severity: wishlist
Owner: Paolo Greppi 

* Package name: node-yn
  Version : 2.0.0
  Upstream Author : Sindre Sorhus  (sindresorhus.com)
* URL : https://github.com/sindresorhus/yn#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Parse yes/no like values - Node.js module

 This Node.js module parses strings with yes/no like values and returns a bool
 or undefined. It has options to return a default instead of undefined and
 a lenient mode to gracefully handle typos.
 .
 It can useful for validating answers of a CLI prompt.
 .
 Node.js is an event-based server-side JavaScript engine.

This is required for node-yarnpkg, see ITP:
https://bugs.debian.org/843021

My intention is to package it within the JavaScript maintainers team.

The repo will be on salsa:
https://salsa.debian.org/js-team/node-yn

Paolo

Bug#886844: ITP: node-babel-plugin-transform-inline-imports-commonjs

[Paolo Greppi]

Package: wnpp
Severity: wishlist
Owner: Paolo Greppi 

* Package name: node-babel-plugin-transform-inline-imports-commonjs
  Version : 1.2.0
  Upstream Author : Andres Suarez 
* URL : 
https://github.com/zertosh/babel-plugin-transform-inline-imports-commonjs#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Babel plugin that lazily transforms ES2015 modules to 
CommonJS

 This babel plugin transforms ES2015 modules to CommonJS and can be used
 instead of node-babel-plugin-transform-es2015-modules-commonjs; it uses lazy
 module loading i.e. your modules are not really imported before you accessxi
 their exports.
 Lazy module import skips all modules besides those which are really needed,
 it is faster and works nicer with circular dependencies between modules.
 .
 Babel is a JavaScript compiler to use next generation JavaScript, today.
 .
 Node.js is an event-based server-side JavaScript engine.

This is required to build node-yarnpkg, see ITP:
https://bugs.debian.org/843021

My intention is to package it within the JavaScript maintainers team.

The repo will be on salsa:
https://salsa.debian.org/js-team/node-babel-plugin-transform-inline-imports-commonjs

Paolo

Bug#886849: ITP: node-puka -- Safely pass strings through shells - Node.js module

[Paolo Greppi]

Package: wnpp
Severity: wishlist
Owner: Paolo Greppi 

* Package name: node-puka
  Version : 1.0.0
  Upstream Author : Ryan Hendrickson 
* URL : https://gitlab.com/rhendric/puka
* License : Expat
  Programming Lang: JavaScript
  Description : Safely pass strings through shells - Node.js module

 A Node.js module that provides a simple and platform-agnostic way
 to build shell commands with arguments that pass through your shell
 unaltered and with no unsafe side effects, whether you are running
 on Windows or a Unix-based OS.
 .
 It is useful when launching a child process from Node.js using a shell
 (as with child_process.exec); in that case you have to construct your
 command as a single string instead of using an array of arguments.
 And doing that can be buggy (if not dangerous) if you don't take care
 to quote any arguments correctly for the shell you're targeting, and
 the quoting has to be done differently on Windows and non-Windows shells.
 .
 Node.js is an event-based server-side JavaScript engine.

This is required for node-yarnpkg, see ITP:
https://bugs.debian.org/843021

My intention is to package it within the JavaScript maintainers team.

It will be built with rollup, and requires:
- rollup-plugin-babel, ITP: http://bugs.debian.org/886404
- rollup-plugin-cleanup

The repo will be on salsa:
https://salsa.debian.org/js-team/node-puka

Paolo

Bug#886864: ITP: gitlint -- A git commit message linter written in python.

[Patrik Hagedorn]

Package: wnpp
Severity: wishlist
Owner: Patrik Hagedorn 

* Package name: gitlint
  Version : 0.9.0
  Upstream Author : Patrik Hagedorn 
* URL : https://github.com/jorisroovers/gitlint
* License : Expat
  Programming Lang: Python2/3
  Description : A git commit message linter written in python.

Git commit message linter written in python, checks your
commit messages for style.

Great for use as a commit-msg git hook or as part of your
gating script in a CI pipeline (e.g. Jenkins).

I plan to maintain it together with my sponsor (Benjamin Drung), but I'm open
for anybody willing to help.

Bug#886865: ITP: nlohmann-json3 -- JSON for Modern C++

[Hubert Chathi]

Package: wnpp
Owner: Hubert Chathi 
Severity: wishlist

* Package name: nlohmann-json3
  Version : 3.0.0
  Upstream Author : Niels Lohmann
* URL or Web page : https://github.com/nlohmann
* License : MIT (Expat)
  Description : JSON for Modern C++

nlohmann-json is already in Debian, but the API has changed for version
3.  This package will provide the new API, while nlohmann-json will
provide the v2 API.

Bug#886866: ITP: node-dnscache -- Dns cache for Node.js

[Paolo Greppi]

Package: wnpp
Severity: wishlist
Owner: Paolo Greppi 

* Package name: node-dnscache
  Version : 1.0.1
  Upstream Author : Vinit Sacheti 
* URL : https://github.com/yahoo/dnscache#readme
* License : BSD
  Programming Lang: JavaScript
  Description : Dns cache for Node.js

 This Node.js module wraps the dns module methods and caches the
 most used/most recent dns calls, to avoid the network delay and
 improve the performance.
 .
 Every call to a dns method is first looked into the local cache,
 in case of cache hit the value from cache is returned,
 in case of cache miss the original dns call is made and the
 return value is cached in the local cache.
 .
 Node.js is an event-based server-side JavaScript engine.

This is required for node-yarnpkg, see ITP:
https://bugs.debian.org/843021

My intention is to package it within the JavaScript maintainers team.

The repo will be on salsa:
https://salsa.debian.org/js-team/node-dnscache

Paolo

Bug#886869: ITP: node-query-string -- Parse and stringify URL query strings - Node.js module

[Paolo Greppi]

Package: wnpp
Severity: wishlist
Owner: Paolo Greppi 

* Package name: node-query-string
  Version : 5.0.1
  Upstream Author : Sindre Sorhus  (sindresorhus.com)
* URL : https://github.com/sindresorhus/query-string#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Parse and stringify URL query strings - Node.js module

 This Node.js module can parse query strings (the part of a URL that follows
 the path, containing form parameters data) to JS dictionaries.
 And it can convert those dictionaries back to query string format (stringify).
 .
 Node.js is an event-based server-side JavaScript engine.

This is required by normalize-url which in turn is required for node-yarnpkg, 
see ITP:
https://bugs.debian.org/843021

My intention is to package it within the JavaScript maintainers team.

The repo will be on salsa:
https://salsa.debian.org/js-team/node-query-string

Paolo

Bug#886873: ITP: node-normalize-url -- Normalize a URL - Node.js module

[Paolo Greppi]

Package: wnpp
Severity: wishlist
Owner: Paolo Greppi 

* Package name: node-normalize-url
  Version : 2.0.1
  Upstream Author : Sindre Sorhus  (sindresorhus.com)
* URL : https://github.com/sindresorhus/normalize-url#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Normalize a URL - Node.js module

 This Node.js module normalizes URLs, i.e. modifies and standardizes them in
 a consistent manner.
 Normalized URLs can be displayed, stored, deduplicated, sorted, compared,
 while taking into account that certain syntactically different URLs are in
 fact equivalent.
 .
 Node.js is an event-based server-side JavaScript engine.

This is required for node-yarnpkg, see ITP:
https://bugs.debian.org/843021

My intention is to package it within the JavaScript maintainers team.

The repo will be on salsa:
https://salsa.debian.org/js-team/node-normalize-url

Paolo

Re: two packages of https://github.com/jessevdk/go-flags

[Héctor Orón Martínez]

Hello,

On Wed, 10 Jan 2018 13:54:02 +0100 Geert Stappers 
wrote:
> Control: retitle -1  two packages of https://github.com/jessevdk/go-flags
> 
> On Wed, Jan 10, 2018 at 01:47:06PM +0100, Geert Stappers wrote:
> > On Wed, Jan 10, 2018 at 07:47:20AM +1300, Michael Hudson-Doyle wrote:
> > > On 10/01/2018 7:08 AM, "Hector Oron"  wrote:
> > > > Package: wnpp
> > > > 
> > > > * Package name: go-flags
> > > >   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 is already packaged, as golang-go-flags-dev or something like that.
> > 
> > https://tracker.debian.org/pkg/golang-go-flags
> > 
> > and there is also
> > 
> > https://tracker.debian.org/pkg/golang-github-svent-go-flags
> > 
> > both originate from https://github.com/jessevdk/go-flags
> > 
> > both packages are maintaint by pkg-go-maintain...@lists.alioth.debian.org
> > 
> > 
> > Closing this ITP  could be an option.
> 
> Using this bugreport for discussion what to do with
> the "duplicate" is another option.

FWIW, for now I'll use a build dependency on `golang-go-flags-dev`.
However, according to Go packaging policy, I understand the proper
package should be named `golang-github-jessevdk-go-flags`.

What do you think? Should we rename them all to
`golang-github-jessevdk-go-flags` and keep only one copy in the archive?

Best regards,
-- 
Héctor Orón Martínez

Collabora Ltd
The Platinum Building
St John's Innovation Park, Cambridge
CB4 0DS, United Kingdom
Telephone: +44 (0)1223 362967
Fax: +44 (0) 1223 351966

   
   Visit Collabora on the Web at https://www.collabora.com/
   Follow Collabora on Twitter https://twitter.com/collabora
   



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#886238: Please introduce official nosystemd build profile

[Steve Langasek]

On Mon, Jan 08, 2018 at 08:36:50PM -0500, Michael Stone wrote:
> On Mon, Jan 08, 2018 at 12:09:09PM -0800, Steve Langasek wrote:
> > Top-posting to just say +1, and that I was going to reply with much the
> > same.

> > I don't even think the requirement for the bootstrap profiles to not
> > functionally change the packages is necessary, but it's the way the folks
> > working on bootstrappability have chosen to do it, so it's their call.  But
> > that's definitely not a binding precedent on other build profiles that might
> > be implemented.

> How, then, would you tell by looking at the package name+version which kind
> of package you have? If you're going to change the name or version string
> anyway, why use some complicated profile system instead of just applying a
> patch? This seems overly complicated for simple cases and overly fragile for
> complex cases.

The fact that this information is no longer exposed in the binary control
file is news to me, and very disappointing.  It seems clear to me that one
*should* be able to determine what profile(s) a package was built with by
looking at the package itself.

As a policy, I think it's clear that packages built with non-default
profiles should never be included in the Debian archive; and segregating
packages into archives by stage is a sensible way to do this for
bootstrapping.  I don't know /what/ one should expect in a world where
profiles are used for other purposes but aren't documented in the binary
control; I guess it just reinforces the fact that you can't trust
third-party deb packages...

In any case, I think the value actually accrues primarily to the simple
cases; because if you want to maintain a package over time, setting a flag
and rebuilding requires much less human involvement than having to
repeatedly merge changes into a package.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

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

[Steve Langasek]

On Tue, Jan 09, 2018 at 03:07:01PM +0100, Johannes Schauer wrote:
> 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.

I think this is an unfortunate case of designing the solution to fit the
particular set of tools.

Build profiles, as a general thing (which they are supposed to be - this is
a major reason support took as long to land in dpkg as it did!), are
significantly less usable if the build profile doesn't follow the resulting
.deb as a tag.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

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

[Steve Langasek]

On Tue, Jan 09, 2018 at 01:23:32PM +0100, Guillem Jover wrote:
> 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.

So, the folks who are working on bootstrappability have made their decision
about the semantics of these profiles, and those that do the work get to
decide, and all that.  But I don't agree that there's anything difficult to
reason about here.

The sole requirement that a stage1 package *must* fulfill is that it's
usable for bootstrapping any stage2 packages that require this package (or,
if no such stage2 packages exist, then "final" packages).  The requirement
that this be done in such a way that the list of files within the stage1
package is no different than the list of files within a final package is an
additional, artificial constraint.  I don't believe it fundamentally makes
the bootstrapping problem any easier than if this were done ad-hoc.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

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

[Johannes Schauer]

Hi,

Quoting Steve Langasek (2018-01-10 21:52:44)
> On Tue, Jan 09, 2018 at 03:07:01PM +0100, Johannes Schauer wrote:
> > 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.
> 
> I think this is an unfortunate case of designing the solution to fit the
> particular set of tools.
> 
> Build profiles, as a general thing (which they are supposed to be - this is
> a major reason support took as long to land in dpkg as it did!), are
> significantly less usable if the build profile doesn't follow the resulting
> .deb as a tag.

Right now, the big difference between build profiles and Gentoo USE flags is,
that build profiles only work for source packages. In contrast to USE flags, it
is (currently) impossible to declare dependencies on binary packages built with
a certain set of build profiles active (or not active). The current crutch we
employ is to make use of the binary package name. By building binary packages
with different names when certain profiles are activated we can use our
existing dependency system.

Our current solution to build profiles does not forbid any future development
that extends the uniqueness of binary packages from name/version/arch to
name/version/arch/profile and introduces a new syntax that allows dependencies
on binary packages with a certain set of profiles activated or deactivated.
This is possible with Gentoo USE flags.

So if we ever decide that we want to make Debian more of a source distribution
and pull a full Gentoo, then we can:

 - come up with a nice syntax for binary package dependencies
 - modify all tools involved in dependency resolution accordingly
 - add the Build-Profiles field to all generated binary packages

If the project at some point in the future decides that this shall be the way
to go, then I shall not stand in the way of such a development. I don't think
that the current way that build profiles work maneuvered us into a dead end if
you have such a future in mind.

But unless we want to pull a full Gentoo here and really make the information
with which build profile a given binary package was built part of the binary
package and thus overhaul all our dependency resolvers, unless the plan is to
do that, I don't see why binary packages should contain this information.

Either it is used for dependency resolution and then we should have the field
or it isn't and then the field is rather making things like comparing packages
with each other difficult. We already accept that the uniqueness of packages
with respect to their name/version/arch only holds within a certain
distribution. But that distribution will also always know with which build
profiles they built all their packages.

So I'm still not convinced.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: [yay for broken usage of was: in the Subject header]

[Philipp Kern]

On 2018-01-10 22:53, Johannes Schauer wrote:
But unless we want to pull a full Gentoo here and really make the 
information
with which build profile a given binary package was built part of the 
binary
package and thus overhaul all our dependency resolvers, unless the plan 
is to
do that, I don't see why binary packages should contain this 
information.


Either it is used for dependency resolution and then we should have the 
field
or it isn't and then the field is rather making things like comparing 
packages
with each other difficult. We already accept that the uniqueness of 
packages

with respect to their name/version/arch only holds within a certain
distribution. But that distribution will also always know with which 
build

profiles they built all their packages.


Why is it making comparing packages with each other difficult? It's an 
additional annotation of what the package actually contains. If you 
upload the set of bootstrap packages and especially if you have multiple 
intermediate stages, you surely would want to know which packages will 
need to be rebuilt to the point of not requiring build profiles anymore, 
no?


At the same time for a stable port the archive can ensure that the build 
profile was actually the default one (or accept divergences with a 
conscious decision, like using NEW or BYHAND).


So I don't think it's as black and white wrt full flexibility in 
dependencies as you paint it. :)


Kind regards
Philipp Kern

Re: enforcing an UTF8 locale while building a package

[Simon McVittie]

On Tue, 09 Jan 2018 at 19:52:23 +0530, Chris Lamb wrote:
> Just as one example, a timezone library that did not work properly
> in timezones beyond UTC+0800, etc.

That's a bug, sure, but is it necessarily a release-critical bug? The
answer is usually "it's up to the maintainer", whereas FTBFS on a
reasonable system under reasonable conditions is automatically RC by
policy, and even if it wasn't, FTBFS on a buildd whose architecture
previously built OK has RC-like implications on testing migration.

If we held, for instance, gcc to this standard ("gcc must work properly
with all valid C inputs") then it would have a lot more RC bugs. Instead,
we accept that, while a bug-free compiler would be great, we aren't
going to have one any time soon, and expect the maintainers of other
software to work around bugs with -O0 or code changes if they need to.

A timezone library should be running its unit tests in lots of timezones
whether it's on the reproducible builds infrastructure or not, but
a tangentially related piece of software that happens to use a timezone
library during build shouldn't be responsible for verifying that its
timezone library works in all reasonable situations.

(Note the weasel word "reasonable", of course - arguably our buildds are
already unreasonable in various ways that make sense for compilation,
but less so for testing.)

smcv

Storing build profiles in binary packages (was: Re: Bug#886238: Please introduce official nosystemd build profile)

[Johannes Schauer]

Quoting Steve Langasek (2018-01-10 21:49:02)
> On Mon, Jan 08, 2018 at 08:36:50PM -0500, Michael Stone wrote:
> > On Mon, Jan 08, 2018 at 12:09:09PM -0800, Steve Langasek wrote:
> > > Top-posting to just say +1, and that I was going to reply with much the
> > > same.
> 
> > > I don't even think the requirement for the bootstrap profiles to not
> > > functionally change the packages is necessary, but it's the way the folks
> > > working on bootstrappability have chosen to do it, so it's their call.  
> > > But
> > > that's definitely not a binding precedent on other build profiles that 
> > > might
> > > be implemented.
> 
> > How, then, would you tell by looking at the package name+version which kind
> > of package you have? If you're going to change the name or version string
> > anyway, why use some complicated profile system instead of just applying a
> > patch? This seems overly complicated for simple cases and overly fragile for
> > complex cases.
> 
> The fact that this information is no longer exposed in the binary control
> file is news to me, and very disappointing.  It seems clear to me that one
> *should* be able to determine what profile(s) a package was built with by
> looking at the package itself.

Why?

Picture two binary packages with the same name/version/arch tuple, they were
maybe even built by the exact same source package but they were built on
different distributions (or at different times with some build dependencies
having changed) so their contents differ. Even today we are not storing the
information on which platform a source package was built in binary packages. We
only expect binary packages with the same name/version/arch from the same
distribution to play well with each other. And that distribution controls the
build profiles it builds binary packages with. What makes build profiles so
different when you compare it with other factors that change binary package
content? We are also not storing that information in binary packages. But we
have a place to store that information: buildinfo files. Those files also store
with which build profiles a source package was built.

I only see one reason for which one could want to store with which build
profile a package was built in the binary package itself: if that information
becomes relevant for dependency resolution.

Though I guess for downstreams who want to have the Build-Profiles field in the
binary packages they build, I guess there could be a solution involving dpkg
vendors.

> As a policy, I think it's clear that packages built with non-default profiles
> should never be included in the Debian archive;

Why? By enforcing (via a policy and checkable via reproducible builds) that the
binary packages that are being built with one (possibly empty) set of build
profiles active are bit-by-bit identical to those built with a different set of
build profiles active, it doesn't matter whether a given binary package was
built with either set.

> and segregating packages into archives by stage is a sensible way to do this
> for bootstrapping.

We don't want "stages" for bootstrapping. This is also why the "stage1" and
"stage2" build profiles are marked as "deprecated" on the wiki page. Those
profile names are only used by toolchain packages for reasons that go beyond
the scope of this thread. The reason we don't want "stageX" profiles but
instead nofoo profiles (disabling foo) are:

 - dependency relationships change regularly. Thus, what is a stage1 today
   might not even be needed for bootstrapping anymore tomorrow. But the profile
   might have other uses, for example by downstreams.

 - dependency relationships change regularly. Thus the notion of what a
   "stage1" build of a package is also changes regularly. At some point, the
   state of the archive might require a source package to be built without
   libfoo-dev and without libbar-dev. At another point in time, it is
   sufficient to build the source package only without libfoo-dev. At another
   point, it would make sense to build it without libfoo-dev and also without
   libbaz-dev. If there are separate profiles for foo, bar and baz, then an
   automated machinery can exactly choose how to build source packages.

 - the functionality removed or changed by a stageX profile might overlap with
   another profile name that is needed for a purpose that is not bootstrapping
   (for example by a downstream). Then, in all places where this functionality
   is activated or deactivated, the full list of profiles that touch it must be
   repeatedly enumerated. It is easier to maintain a single build profile that
   is directly connected with exactly that functionality.  See my argument
   about maintainability of build profiles for each distribution in [1].

[1] https://lists.debian.org/151553652380.1442.14816198615195092481@localhost

> I don't know /what/ one should expect in a world where profiles are used for
> other purposes but aren't documented in the binary control; I guess it 

Re: [yay for broken usage of was: in the Subject header]

[Johannes Schauer]

Quoting Philipp Kern (2018-01-11 00:20:17)
> On 2018-01-10 22:53, Johannes Schauer wrote:
> > But unless we want to pull a full Gentoo here and really make the
> > information with which build profile a given binary package was built part
> > of the binary package and thus overhaul all our dependency resolvers,
> > unless the plan is to do that, I don't see why binary packages should
> > contain this information.
> > 
> > Either it is used for dependency resolution and then we should have the
> > field or it isn't and then the field is rather making things like comparing
> > packages with each other difficult. We already accept that the uniqueness
> > of packages with respect to their name/version/arch only holds within a
> > certain distribution. But that distribution will also always know with
> > which build profiles they built all their packages.
> Why is it making comparing packages with each other difficult?

What I meant here was what I mentioned elsewhere in this thread. We can check
whether two binary packages built with a different set of build profiles active
are actually the same by using the tools from the reproducible builds project.
And the easiest way to do the comparison is to compare their hashes. If the
build profile would be included, then comparing the packages would be made more
difficult.

> It's an additional annotation of what the package actually contains.

I would rather say that the set of build profiles active is a property of the
*build* and not a property of the binary package. Especially considering that
most build profiles require identical package contents. We also don't store in
binary packages which build dependencies were installed in which version during
the build even though this is also something that can have great influence on
the content of the binary package.  Instead, we store this information in the
buildinfo file which I also find a better fit for storing the information which
build profiles were active because build profiles are a property of the package
build.

> If you upload the set of bootstrap packages and especially if you have
> multiple intermediate stages, you surely would want to know which packages
> will need to be rebuilt to the point of not requiring build profiles anymore,
> no?

At all points during the bootstrapping, we know which source packages we built
with with which profiles active either by simply keeping track of what is being
done or by investigating the generated buildinfo files which contain that
information. It is not necessary to have this information stored in the binary
packages itself for this purpose.

> At the same time for a stable port the archive can ensure that the build
> profile was actually the default one (or accept divergences with a conscious
> decision, like using NEW or BYHAND).

The archive can already do this check by investigating the buildinfo file that
was uploaded together with the binary packages.

> So I don't think it's as black and white wrt full flexibility in dependencies
> as you paint it. :)

Surely, rarely anything is really black and white. :)

Thanks!

cheers, josch


signature.asc
Description: signature

Re: [yay for broken usage of was: in the Subject header]

[Guillem Jover]

On Thu, 2018-01-11 at 01:06:06 +0100, Johannes Schauer wrote:
> Quoting Philipp Kern (2018-01-11 00:20:17)
> > Why is it making comparing packages with each other difficult?
> 
> What I meant here was what I mentioned elsewhere in this thread. We can check
> whether two binary packages built with a different set of build profiles 
> active
> are actually the same by using the tools from the reproducible builds project.
> And the easiest way to do the comparison is to compare their hashes. If the
> build profile would be included, then comparing the packages would be made 
> more
> difficult.

Or IOW:

  cmp a.deb b.deb

vs

  dpkg-deb -R a.deb a
  dpkg-deb -R b.deb b
  sed -i -e '/^Built-For-Profiles/d' a/DEBIAN/control
  sed -i -e '/^Built-For-Profiles/d' b/DEBIAN/control
  diff -Naur a b

While then not comparing the actual .deb, for any other suspicious
members, difference in format, strange padding, etc, or control.tar
metadata changes.

> > At the same time for a stable port the archive can ensure that the build
> > profile was actually the default one (or accept divergences with a conscious
> > decision, like using NEW or BYHAND).
> 
> The archive can already do this check by investigating the buildinfo file that
> was uploaded together with the binary packages.

Actually this information is also readily available in the .changes
file which DAK is already parsing.

Thanks,
Guillem

Re: Storing build profiles in binary packages (was: Re: Bug#886238: Please introduce official nosystemd build profile)

[Guillem Jover]

[ Just few comments to complement josch's veyr nice reply, with which I
  completely agree with. ]

On Thu, 2018-01-11 at 00:47:28 +0100, Johannes Schauer wrote:
> Quoting Steve Langasek (2018-01-10 21:49:02)
> > As a policy, I think it's clear that packages built with non-default 
> > profiles
> > should never be included in the Debian archive;
> 
> Why? By enforcing (via a policy and checkable via reproducible builds) that 
> the
> binary packages that are being built with one (possibly empty) set of build
> profiles active are bit-by-bit identical to those built with a different set 
> of
> build profiles active, it doesn't matter whether a given binary package was
> built with either set.

Yes, and in addition this information is recorded in both .changes
and .buildinfo files. I was initially among the ones wanting this
information in the .debs to be able to trace it, but the need
disappeared when we introduced .buildinfo files, because then we've
got the upload specific recording for the archive processor (.changes),
and the supposedly public facing record of what was done during the
build (.buildinfo), although the later can never be fully trusted
anyway. :)

> > and segregating packages into archives by stage is a sensible way to do this
> > for bootstrapping.
> 
> We don't want "stages" for bootstrapping. This is also why the "stage1" and
> "stage2" build profiles are marked as "deprecated" on the wiki page. Those
> profile names are only used by toolchain packages for reasons that go beyond
> the scope of this thread. The reason we don't want "stageX" profiles but
> instead nofoo profiles (disabling foo) are:
> 
>  - dependency relationships change regularly. Thus, what is a stage1 today
>might not even be needed for bootstrapping anymore tomorrow. But the 
> profile
>might have other uses, for example by downstreams.
> 
>  - dependency relationships change regularly. Thus the notion of what a
>"stage1" build of a package is also changes regularly. At some point, the
>state of the archive might require a source package to be built without
>libfoo-dev and without libbar-dev. At another point in time, it is
>sufficient to build the source package only without libfoo-dev. At another
>point, it would make sense to build it without libfoo-dev and also without
>libbaz-dev. If there are separate profiles for foo, bar and baz, then an
>automated machinery can exactly choose how to build source packages.
> 
>  - the functionality removed or changed by a stageX profile might overlap with
>another profile name that is needed for a purpose that is not bootstrapping
>(for example by a downstream). Then, in all places where this functionality
>is activated or deactivated, the full list of profiles that touch it must 
> be
>repeatedly enumerated. It is easier to maintain a single build profile that
>is directly connected with exactly that functionality.  See my argument
>about maintainability of build profiles for each distribution in [1].
> 
> [1] https://lists.debian.org/151553652380.1442.14816198615195092481@localhost

The take home here is that, stages do not scale, they might be fine for
just a toolchain perhaps, but not to automatically bootstrap the entire
build-essential set, or automatically bootstrap dependency cycles.

> > I don't know /what/ one should expect in a world where profiles are used for
> > other purposes but aren't documented in the binary control; I guess it just
> > reinforces the fact that you can't trust third-party deb packages...
> 
> With respect to dependencies you already could not trust third-party deb
> packages. In that sense, a binary package built by a third party with a 
> certain
> build profile active is no different than that third party building the same
> source package without build profiles but with an unknown configuration of the
> build system, for example.

Exactly. Or built with build profiles but the field removed afterwards,
or any other number of changes. Anything that lies outside the confines
of a specific distribution can never be fully trusted within that
distribution.

Thanks,
Guillem

Re: enforcing an UTF8 locale while building a package

[Chris Lamb]

Simon,

> > Just as one example, a timezone library that did not work properly
> > in timezones beyond UTC+0800, etc.
> 
> That's a bug, sure, but is it necessarily a release-critical bug?

Although I don't disagree with anything in particular you said on the
question of what is "reasonable" and on whether such libraries should
have a better testsuites, I'm not sure I see the value in discussing
the severity level of a hypothetical bug?  :) 


Best wishes,

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