Re: changes to upload queue for security archive

[Brian May]

Brian May  writes:

> Michael Hudson-Doyle  writes:
>
>> Sounds like MTU related fun perhaps?
>
> Hmmm I am doubtful, however I will conduct some more experiments
> tomorrow to test this.

Was all set to debug MTU issues today, but found that it is working
without problem.

Hope it stays this way :-)
-- 
Brian May 

Re: Concerns about infrastructure for Alioth replacement

[Ondřej Surý]

Also please note that Ruby programs are usually very picky about particular
versions of their dependencies.

I call it a "gem hell" and it was a reason why I gave up helping with Ruby
packaging and switched to redmine from source and bundler. Same for gitlab.
I believe the time can be spent more productively than tackling with
upstream with totally different world views.

Ondřej

On Wed, 18 Oct 2017, 08.14 Alexander Wirt,  wrote:

> On Tue, 17 Oct 2017, Nicholas D Steeves wrote:
>
> > CCing the Javascript Team.
> >
> > Original post on debian-devel, see:
> > Message-Id: <20171016001558.a9c2e92f9155e844f43ce...@paranoici.org>
> >
> > Or alternatively:
> > https://lists.debian.org/debian-devel/2017/10/msg00262.html
> >
> > On Tue, Oct 17, 2017 at 11:32:55PM +0200, Alexander Wirt wrote:
> > > On Tue, 17 Oct 2017, Francesco Poli wrote:
> > >
> > > > On Mon, 16 Oct 2017 04:28:09 + Ondřej Surý wrote:
> > > >
> > > > [...]
> > > > > Francesco, great idea, go ahead. You would be most welcome to help
> with
> > > > > Debian Ruby Extra packaging.
> > > >
> > > > Unfortunately, I have basically zero knowledge about Rails,
> JavaScript
> > > > and Node.js: I could not be of much help in packaging GitLab.
> > > >
> > > > What I meant was that the time that will be spent in manually
> installing,
> > > > manually adapting, and manually upgrading the upstream version, would
> > > > perhaps be better spent in helping the maintainers to keep the Debian
> > > > package up-to-date and in using the Debian package in stead of the
> upstream
> > > > version...
> > > Nope. I know how to setup gitlab, I don't - and I don't want to have
> > > knowledge (and I don't have time to do it) to maintain numerous ruby
> and
> > > nodejs modules.
> > >
> > > Alex
> > >
> >
> > On 16 October 2017 at 06:52, Pirate Praveen 
> wrote:
> > > On 10/16/2017 03:45 AM, Francesco Poli wrote:
> > >> I would say that this issue with the Debian packages of GitLab should
> > >> be addressed by helping the Debian Ruby Extras Maintainers to improve
> > >> the Debian packages and to keep them more up-to-date.
> > >
> > > gitlab 9.x has switched to using node modules + webpack for front end.
> > > So any help in packaging the node dependencies welcome.
> > >
> > > See https://wiki.debian.org/Javascript/Nodejs/Tasks/gitlab for the
> > > current status.
> > >
> > > Btw all ruby dependencies for 9.5.x are packaged already.
> > >
> >
> > Dear Javascript Team,
> >
> > Would you please consider maintaining the "numerous [...] nodejs
> > modules" necessary for Debian's Alioth replacement to run on a
> > Debian-built GitLab package?  We are facing a scenario that confirms
> > that Debian packaging is not good enough--even for Debian's own
> > infrastructure.
> >
> > I would join the team, but it would take me weeks/months to learn
> > about Javascript and Nodejs, and it seems this transition is imminent.
> >
> > In the worst-case scenario, if that work cannot be completed on time,
> > a deadline should be set for transitioning to official Debian-built
> > packages.  Let's say well before DebConf18 so that it will be well
> > tested for DebCamp.
> >
> > Please reply to debian-devel and CC Francesco Poli <
> invernom...@paranoici.org>
> Please don't get me wrong, but even if gitlab packages are recent tomorrow
> (which I
> don't think) we won't migrate. The work is done and we have all the things
> in
> place to maintain them. So please do me a favour and don't mention alioth
> as
> the reason.
>
> Alex
>
> --
Ondřej Surý 

Bug#878973: ITP: python-lupa -- Python wrapper around LuaJIT

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-lupa
  Version : 1.5
  Upstream Author : Stefan Behnel 
* URL : https://github.com/scoder/lupa/
* License : Expat
  Programming Lang: Python
  Description : Python wrapper around LuaJIT

Lupa integrates the runtimes of Lua or LuaJIT2 into CPython. It is a partial
rewrite of LunaticPython in Cython with some additional features such as proper
coroutine support.
.
Features:
 * separate Lua runtime states through a LuaRuntime class
 * Python coroutine wrapper for Lua coroutines
 * iteration support for Python objects in Lua and Lua objects in Python
 * proper encoding and decoding of strings (configurable per runtime, UTF-8 by
   default)
 * frees the GIL and supports threading in separate runtimes when calling into
   Lua
 * written for LuaJIT2, but also works with the normal Lua interpreter
 * easy to hack on and extend as it is written in Cython, not C

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAlnnFK4RHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WrtKQgAwRo+V0Owemu+zu3hJya2Lq2Kc9ng18tL
XCWqbZdCEN3/yPiE99lHkX74d6alc3v+BtgHDZtKf8VQELqoRxwNKQWOVW6QNrfO
CNAeF5w6ZIjyMRc1twajJ/ZMGP2gWVDMejOCXlXclftXNxDLEi++X355APxR/8pP
Vk/OyBGUqxlqvyHLsfKIso3uAMHvBpoaCsO89dFRfQWsqMifoJNnGQFCAKu3eihY
OdVlfEkSk7EoJYJKsHDR8o9gyGHrx8kNZKSqg/EEn9rKI7mn+nYgZhqMx9Zd5eVu
mweeVlpGLmVetEU3OmotEPd9Fy1GEBhfx9A+xmtbUwloLHGdEfmV8Q==
=DHBf
-END PGP SIGNATURE-

Bug#878975: ITP: gnome-shell-extension-workspaces-to-dock -- GNOME Shell extension that transforms the workspaces of the overview mode into an intelligent dock

[Jonathan Carter]

Package: wnpp
Severity: wishlist
Owner: Jonathan Carter 

* Package name: gnome-shell-extension-workspaces-to-dock
  Version : 44-1
  Upstream Author : passingthru67 (https://github.com/passingthru67)
* URL : https://github.com/passingthru67/workspaces-to-dock
* License : GPL-3
  Programming Lang: JavaScript
  Description : GNOME Shell extension that transforms the workspaces of the 
overview mode into an intelligent dock

A GNOME Shell extension that adds extra features to the workspaces area 
including:

 - Multiple display preferences
 - Select which side of display to keep workspaces
 - Adjust size of workspace area
 - Adjust background and colours
 - Adjust autohide behaviour
 - Display window icons in thumbnail area

Unsustainable debian/rules as official build entry point?

[Guillem Jover]

Hi!

So, dpkg 1.19.0 and 1.19.0.1 had a bug where the build target was not
being called when building packages.

Apparently this caused mass build failures, all due to packages (or
their helpers) being very Debian policy non-compliant! These are all
MUST requirements. Stuff like:

  - binary-targets are the only thing required to build a package, and
the needed build-targets must be depended on by the binary-targets.
  - build-targets must not require root privs, but must be able to be
run with root privs (via binary-target invocation).
  - debian/rules must not assume any pre-existing environment variable,
as it still needs to be runnable as debian/rules.

From what I've been told (thanks Niels and Helmut! :), we have lots of
packages in the archive that FTBFS due to, at least:

  - debhelper compat levels < 9 not recursing into debian/rules to
call the build target.
  - dh-elpa's test failing when executed as root.
  - debian/rules assuming DEB_*_MULTIARCH being present w/o defining it.

The first will just solve itself as people upgrade compat, the second
does really need fixing (although might get shadowed again with the
upcoming R³ support), the last is a recurring problem.


Given the above, and that these are clear regressions, it seems
obvious to me that we are (collectively) not checking/using debian/rules
as the official build entry point interface.

And I've got to question whether we should keep supporting it or just
declare dpkg-buildpackage to be that entry point.


Using debian/rules as the official build entry point has the beauty
that it makes source packages be somewhat self-contained (although
they will still require dpkg-dev tools internally), has perhaps less
interface surface than dpkg-buildpackage provides, and does not tie
it to a specific implementation (dpkg in this case).

Using dpkg-buildpackage as the official build entry point would allow
for much debian/rules refactoring and reduction, and optimizations. We
could predefine multiple environment variables from data sources
dpkg-buildpackage has already needed to parse, or to get a defined and
cleaner environment (see recent LC_ALL=C.UTF-8 thread). It could allow
us to make packaging easier by possbly (and conditionally) reversing the
current inside-out build nature, where the bulk of the building logic is
inside debian/rules via some helper, and even perhaps reduce the need
for a helper, making packaging easier. Etc.


In the past there's been quite strong opposition to switching the
official build entry point from debian/rules to dpkg-buildpackage
(well, even to debian/rules being a Makefile! :). But it seems obvious
that the current situation is not very sustainable. So if there's
still opposition, it might make sense for those opposing to at least
try to attest the conformance of that interface from time to time, and
file bugs etc.? Thoughts?

Thanks,
Guillem

Re: Unsustainable debian/rules as official build entry point?

[Svante Signell]

On Wed, 2017-10-18 at 11:36 +0200, Guillem Jover wrote:
> Hi!
> 
> So, dpkg 1.19.0 and 1.19.0.1 had a bug where the build target was not
> being called when building packages.

Thanks, this problem has finally been revealed officially. Are you sure
this problem is not older than version 1.19.x? 

Building some packages for GNU/Hurd has been impossible in the past,
since also tests are run under fakeroot. And they should not, they are
part of the build target, not the binary target. We have tried to point
this out several times, but until now was not taken seriously.

Bug#878997: ITP: python-language-server -- Python Language Server for the Language Server Protocol

[Ghislain Antony Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 

* Package name: python-language-server
  Version : 0.8.0
  Upstream Author : Palantir Technologies, Inc.
* URL : https://github.com/palantir/python-language-server
* License : Expat
  Programming Lang: Python
  Description : Python Language Server for the Language Server Protocol

This package will be team-maintained by the DPMT.

Bug#878998: ITP: pyls-mypy -- mypy plugin for the Python Language Server

[Ghislain Antony Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 

* Package name: pyls-mypy
  Version : 0.1.2
  Upstream Author : Tom van Ommeren
* URL : https://github.com/tomv564/pyls-mypy
* License : Expat
  Programming Lang: Python
  Description : mypy plugin for the Python Language Server

This package will be team-maintained by the DPMT. It requires
python-language-server to be packaged first.

Re: build* targets as root

[Simon McVittie]

(Changing subject line because I think this is a semi-separate issue)

On Wed, 18 Oct 2017 at 11:36:41 +0200, Guillem Jover wrote:
> Apparently this caused mass build failures, all due to packages (or
> their helpers) being very Debian policy non-compliant! These are all
> MUST requirements. Stuff like:
...
>   - build-targets [...] must be able to be
> run with root privs (via binary-target invocation)

Which Policy requirements combine to imply this?

If this is really a Policy MUST then I'm not sure how realistic it
is to combine this with build-time testing, particularly if the root
privileges are allowed to be a lie and not actually imply any privilege
(fakeroot). fakeroot has some important limitations: in particular,
anything that has build-time tests involving a protocol that uses AF_UNIX
credentials passing (D-Bus, Wayland, PostgreSQL, some uses of X11)
is going to have a hard time.

I would be reluctant to introduce new incentives for maintainers to
disable build-time testing, given how frequent it seems to be for a
maintainer to turn on build-time tests and discover that their package
has always built but not actually worked on some architectures. If
there were enough autopkgtest workers for all architectures (perhaps
as a requirement for being in testing?) then we could perhaps rely on
autopkgtest to do that smoke-testing, but at the moment Debian only
tests amd64, and Ubuntu only tests 5 architectures (I'm not sure whether
that represents all the supported Ubuntu architectures or not, but it's
certainly fewer than the Debian release architectures).

I also don't think it's reasonable to expect test developers to support
running their tests under fakeroot, and I for one would not like to find
myself trying to explain to an upstream why we had considered this to
be a sensible thing to do. dbus fails tests under fakeroot, but with my
dbus upstream hat on I don't really consider that to be a bug - the tests
are successfully finding inconsistencies in the emulation of real root.

Requiring build-time tests to pass when run as real root (by inserting a
check and skip/early-return into tests that assume they are unprivileged,
if necessary) sounds a much more reasonable thing to expect to work,
although again, I could easily imagine reporting that failure to an
upstream and being told (quite justifiably) that I should never build as
root and the resulting failure was therefore not a bug.

So if Policy indirectly requires the build* targets to work under
fakeroot, I would prefer to see that part of Policy change.

Regards,
smcv

Re: MBF: please drop transitional dummy package foo (if they were part of two releases or more)

[Holger Levsen]

Hi,

On Sat, Oct 14, 2017 at 09:27:25PM +, Holger Levsen wrote:
> I'm doing an small mass bug filing against obsolete transitional packages
> which are at least marked "dummy transitional" since the jessie release,
> though many of them existed already in wheezy. I think it's rather undoubtful
> those are normal bugs we want to get rid off.
 
This has been done now, with the result of 172 open bugs about transitional
packages which exists since at least jessie, sometimes wheezy. (Didnt check
squeeze…) - plus an additional of 34 of those bugs which have been fixed since
the stretch release.

IOW: hopefully buster will get rid of 200 useless packages eventually.

> I'm currently undecided whether I think it's useful to file wishlist bugs
> against transitional dummy packages which only are that since stretch. What 
> do 
> you think? Probably it's more useful to file wishlist bugs against packages
> depending on those… or should those be normal severity?

Next will be running this script on jenkins (then slightly changed), to point
out packages in buster (which are not fixed in sid) with reverse dependencies
to packages which are transitional packages since stretch. And then I might 
file some (normal) bugs then too, but I guess this will be in some time only…

Plus, *once we've released buster* I plan to again file bugs, that time against
transitional packages which have been traditional since stretch (and are still
transitional in buster and sid).


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Re: Unsustainable debian/rules as official build entry point?

[Simon McVittie]

On Wed, 18 Oct 2017 at 11:57:55 +0200, Svante Signell wrote:
> Building some packages for GNU/Hurd has been impossible in the past,
> since also tests are run under fakeroot.

Is there some reason why this would be Hurd-specific? Is fakeroot's
emulation of real root significantly more limited on Hurd, or do the
Hurd buildds invoke builds differently, or something?

dbus fails build-time tests under fakeroot on all architectures
(or at least, I would expect it to, because it tests AF_UNIX
credentials-passing), which makes me wonder why this failure mode would
have manifested on Hurd and not Linux in the past. I would have expected
packages whose tests don't like fakeroot to either succeed equally
on both, or fail equally on both, if unrelated reasons for failure
are ignored.

smcv

Re: Unsustainable debian/rules as official build entry point?

[Guillem Jover]

On Wed, 2017-10-18 at 11:54:57 +0100, Simon McVittie wrote:
> On Wed, 18 Oct 2017 at 11:57:55 +0200, Svante Signell wrote:
> > Building some packages for GNU/Hurd has been impossible in the past,
> > since also tests are run under fakeroot.
> 
> Is there some reason why this would be Hurd-specific? Is fakeroot's
> emulation of real root significantly more limited on Hurd, or do the
> Hurd buildds invoke builds differently, or something?

The Hurd has had its own fakeroot implementation for a long time.

Regards,
Guillem

Re: Unsustainable debian/rules as official build entry point?

[Svante Signell]

On Wed, 2017-10-18 at 11:54 +0100, Simon McVittie wrote:
> On Wed, 18 Oct 2017 at 11:57:55 +0200, Svante Signell wrote:
> > Building some packages for GNU/Hurd has been impossible in the
> > past, since also tests are run under fakeroot.
> 
> Is there some reason why this would be Hurd-specific? Is fakeroot's
> emulation of real root significantly more limited on Hurd, or do the
> Hurd buildds invoke builds differently, or something?

The problems was revealed when fakeroot was flaky (native
implementation). That fakeroot problem is now solved.

> dbus fails build-time tests under fakeroot on all architectures
> (or at least, I would expect it to, because it tests AF_UNIX
> credentials-passing), which makes me wonder why this failure mode
> would have manifested on Hurd and not Linux in the past. I would have
> expected packages whose tests don't like fakeroot to either succeed
> equally on both, or fail equally on both, if unrelated reasons for
> failure are ignored.

Yes, you are right. From what I remember most packages either succeed
or fail when tests are run when run under fakeroot for all
architectures. In my opinion tests should never be run under fakeroot
(i.e. in the binary target) except when requested specifically (cannot
be solved by a buildd?). The problem is the same as for tests requiring
internet connections, which are not allowed, right?

Re: build* targets as root

[Guillem Jover]

On Wed, 2017-10-18 at 11:30:29 +0100, Simon McVittie wrote:
> On Wed, 18 Oct 2017 at 11:36:41 +0200, Guillem Jover wrote:
> > Apparently this caused mass build failures, all due to packages (or
> > their helpers) being very Debian policy non-compliant! These are all
> > MUST requirements. Stuff like:
> ...
> >   - build-targets [...] must be able to be
> > run with root privs (via binary-target invocation)
> 
> Which Policy requirements combine to imply this?

From 4.9§:

,---
   binary (required), binary-arch (required), binary-indep (required)

 The binary target must be all that is necessary for the user to
 build the binary package(s) produced from this source package. It
 is split into two parts: binary-arch builds the binary packages
 which are specific to a particular architecture, and binary-indep
 builds those which are not.

 …

 Both binary-* targets should depend on the build target, or on the
 appropriate build-arch or build-indep target, so that the package
 is built if it has not been already. It should then create the
 relevant binary package(s), using dpkg-gencontrol to make their
 control files and dpkg-deb to build them and place them in the
 parent of the top level directory.

 …

 The binary targets must be invoked as root.
`---

And while the second paragraph is strictly speaking a SHOULD, I take
it to mean that these targets should be depended on somehow even if
transitively (there's a bug on policy about precisely that). Because
the first paragraph overrides the second one. Otherwise if we had
different build paths depending on whether one has just called «binary»
or «build + binary» that would be broken too IMO. See for example this
paragraph:

,---
   build (required)

 …

 For some packages, notably ones where the same source tree is
 compiled in different ways to produce two binary packages, the
 build target does not make much sense. For these packages it is
 good enough to provide two (or more) targets (build-a and build-b
 or whatever) for each of the ways of building the package, and a
 build target that does nothing. The binary target will have to
 build the package in each of the possible ways and make the binary
 package out of each.

 …
`---

> If this is really a Policy MUST then I'm not sure how realistic it
> is to combine this with build-time testing, particularly if the root
> privileges are allowed to be a lie and not actually imply any privilege
> (fakeroot). fakeroot has some important limitations: in particular,
> anything that has build-time tests involving a protocol that uses AF_UNIX
> credentials passing (D-Bus, Wayland, PostgreSQL, some uses of X11)
> is going to have a hard time.
…

> So if Policy indirectly requires the build* targets to work under
> fakeroot, I would prefer to see that part of Policy change.

On the general problem of using (fake)root, the correct solution is IMO
to stop having to use (fake)root at all. This should be possible in the
future with R³, which we'll be announcing shortly on a separate thread.

But IMO that's a bit besides the point here, the real point is that the
current debian/rules full interface is not being checked for comformance,
and it's decaying anyway. And only what dpkg-buildpackage exposes is. :/

Thanks,
Guillem

Re: Unsustainable debian/rules as official build entry point?

[Felipe Sateler]

On Wed, 18 Oct 2017 11:36:41 +0200, Guillem Jover wrote:

> And I've got to question whether we should keep supporting it or just
> declare dpkg-buildpackage to be that entry point.

I think it makes sense to declare dpkg-buildpackage the official entry 
point. Reasons for:

1. It is already the de-facto entry point, since buildds use dpkg-
buildpackage, and so do pbuilder and sbuild.

2. Most (all?) of the archive already depends on dpkg-dev, by using the /
usr/share/dpkg/*.mk helpers (either directly or indirectly via CDBS) and 
using dpkg-* tools (either directly or indirectly via debhelper).

3. Providing a clean environment helps the reproducibility efforts, by 
providing a single place where many weird environment variables can be 
neutered. It probably will also help other archive-wide efforts

4. dpkg-buildpackage has the --target and --as-root flags to invoke any 
debian/rules target since 1.15 (oldoldstable has 1.16).


Reasons against:

1. Finger memory. This can be alleviated via a suitable alias 
drules='dpkg-buildpackage --target'.

I can't come up with other reasons.

Let's make dpkg-buildpackage the official entry point.

-- 
Saludos,
Felipe Sateler

Re: Unsustainable debian/rules as official build entry point?

[Ian Jackson]

Guillem Jover writes ("Unsustainable debian/rules as official build entry 
point?"):
> Given the above, and that these are clear regressions, it seems
> obvious to me that we are (collectively) not checking/using debian/rules
> as the official build entry point interface.
> 
> And I've got to question whether we should keep supporting it or just
> declare dpkg-buildpackage to be that entry point.

tl;dr: I think I agree with your suggestion but I would definitely
  express it rather differently.


There are two entry points which are relevant:

1. The interface provided by packages.
2. The interface consumed by programs which want to build packages.

Up to now, both of these have been, officially, the same:
debian/rules.

But for purpose 2 most programs invoke dpkg-buildpackage now.  This is
because the official interface 1 keeps becoming more complex,
particularly because of backward compatibility requirements.

The compatibility and protocol negotiation functionality in
dpkg-buildpackage, where dpkg-buildpackage arranges to work with new
packages in new ways and old packages in old ways, becomes harder and
harder to reproduce.  So de facto, most consumers of source packages
consume them via dpkg-buildpackage.

I think there is a lot of value in interposing a common
compatibility/adjustment layer between the two interfaces I mention
above.  So I would support a proposal to official declare that
programs which want to build (unrelated) packages should do so via
dpkg-buildpackage.

However:

I would _not_ support a proposal to abolish the package-provided rules
interface as de-jure standard.  It's just that this standard would
gradually lose its other consumers.  After there is only one consumer
it will be somewhat easier to change it.

Additionally, although there being one consumer makes it seem as if we
could just add new mandatory features to packages (ie, changes which
require new dpkg-buildpackage), I don't think we should do that.

It is important for backporting, downstreams, etc. etc., that old
versions of dpkg-buildpackage can build new packages.

Important consequences of my views include:

* The package-provided rules interface needs to remain managed as part
  of policy (and to continue to have a controlled approach to updates,
  etc.).

* The interface is not *defined by* dpkg-buildpackage: ie it is still
  possible for dpkg-buildpackage to have a bug where it does not
  implement the de-jure interface.

* Packages may still need to work around bugs in old versions of
  dpkg-buildpackage; conversely, new versions of dpkg-buildpackage may
  need to work around bugs in old packages.

* For a long time, packages should try to be compatible with old
  builders which invoke rules directly, even old builders other than
  dpkg-buildpackage.


I think you will probably agree, but I wanted to set it all out.

Ian.

Re: Unsustainable debian/rules as official build entry point?

[Samuel Thibault]

Svante Signell, on mer. 18 oct. 2017 13:51:25 +0200, wrote:
> On Wed, 2017-10-18 at 11:54 +0100, Simon McVittie wrote:
> > On Wed, 18 Oct 2017 at 11:57:55 +0200, Svante Signell wrote:
> > > Building some packages for GNU/Hurd has been impossible in the
> > > past, since also tests are run under fakeroot.
> > 
> > Is there some reason why this would be Hurd-specific? Is fakeroot's
> > emulation of real root significantly more limited on Hurd, or do the
> > Hurd buildds invoke builds differently, or something?
> 
> The problems was revealed when fakeroot was flaky (native
> implementation). That fakeroot problem is now solved.

It's also not always flakiness. Sometimes there are just several ways to
emulate root behavior, and the hurdish implementation happened to use a
different one from the non-Hurd fakeroot.

Samuel

Re: Unsustainable debian/rules as official build entry point?

[Wookey]

On 2017-10-18 12:08 +, Felipe Sateler wrote:
> On Wed, 18 Oct 2017 11:36:41 +0200, Guillem Jover wrote:
> 
> > And I've got to question whether we should keep supporting it or just
> > declare dpkg-buildpackage to be that entry point.
> 
> I think it makes sense to declare dpkg-buildpackage the official entry 
> point.

I too am reasonably happy with this idea, for the reasons you and
Felipe gave, however I can think of one potential issue.

> Reasons against:

I quite often use the debian/rules binary{-arch,-indep} interface when
doing porting/bootstrapping work (i.e the package built but something
goes wrong in the packaging process so I want to retry with a tweak or a bodge)

In theory I should be able to do 
dpkg-buildpackage -nc --target=binary

but in practice I find that this often doesn't work as intended and it
tries to do the whole build again. I have not investigated exactly why
this is, and I guess you'll want me to give you a concrete example next.

Doing the whole build again is sometimes just slow (very slow!), but
can also be a PITA when porting, and you really do just want to
package up what you have.

I guess my point is that I do not find these interfaces to be
equivalent in practice so there is value for me in retaining the
debian/rules binary interface at least until the dpkg-buidpackage one
reliably does the same thing. Perhaps I am missing some magic switch.

It seems like this is a bug/interaction, rather than a fundamental
reason for retaining the debian/rules interface in the long term, but
I do see it as a reason to proceed cautiously. 

Sadly I am failing to remember whch package did this to me most
recently, even though it wasn't long ago. (Something in the bottom
'debootstrap' 144 :-)

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


signature.asc
Description: Digital signature

Re: Unsustainable debian/rules as official build entry point?

[Svante Signell]

On Wed, 2017-10-18 at 16:31 +0100, Wookey wrote:
> On 2017-10-18 12:08 +, Felipe Sateler wrote:

> I quite often use the debian/rules binary{-arch,-indep} interface when
> doing porting/bootstrapping work (i.e the package built but something
> goes wrong in the packaging process so I want to retry with a tweak or a
> bodge)
> 
> In theory I should be able to do 
> dpkg-buildpackage -nc --target=binary
> 
> but in practice I find that this often doesn't work as intended and it
> tries to do the whole build again. I have not investigated exactly why
> this is, and I guess you'll want me to give you a concrete example next.

Couldn't agree more. Porting packages is mostly the task of my work on GNU/Hurd
and being able to issue debian/rules configure, build, binary, clean, etc is
extremely useful. Especially for source packages building a lot of binaries.

> Doing the whole build again is sometimes just slow (very slow!), but
> can also be a PITA when porting, and you really do just want to
> package up what you have.

See above. Also, when testing if a package can be built twice in a row (not
necessarily for Hurd) it is important. I've encountered several such packages in
the Debian repository (still there).

Easy discovery of ‘debian/rules’ build problems (was: Unsustainable debian/rules as official build entry point?)

[Ben Finney]

Ian Jackson  writes:

> After there is only one consumer [of the package-provided
> ‘debian/rules’ build interface], it will be somewhat easier to change
> [the policy so that interface is not the standard].

>From the rest of your message I infer that the mention of “one consumer”
there refers to (current or future) ‘dpkg-buildpackage’, is that correct?

> Important consequences of my views include:
>
> * The package-provided rules interface needs to remain managed as part
>   of policy (and to continue to have a controlled approach to updates,
>   etc.).
>
> * The interface is not *defined by* dpkg-buildpackage: ie it is still
>   possible for dpkg-buildpackage to have a bug where it does not
>   implement the de-jure interface.
>
> * Packages may still need to work around bugs in old versions of
>   dpkg-buildpackage; conversely, new versions of dpkg-buildpackage may
>   need to work around bugs in old packages.
>
> * For a long time, packages should try to be compatible with old
>   builders which invoke rules directly, even old builders other than
>   dpkg-buildpackage.

I had been under the impression the build tools (SBuild, PBuilder, etc.)
invoke ‘debian/rules’ directly, and so are a good way to test that
compatibility. Evidently that impression is wrong, and the use of those
build tools is not helping to find such bugs.

What tools exist to allow package maintainers – as many as possible – to
get easy (automatic?) notification when the package they maintain is not
presenting a compatible ‘debian/rules’ build interface?

-- 
 \  “Very few things happen at the right time, and the rest do not |
  `\ happen at all. The conscientious historian will correct these |
_o__)  defects.” —Mark Twain, _A Horse's Tale_ |
Ben Finney

Re: Unsustainable debian/rules as official build entry point?

[Felipe Sateler]

On Wed, 18 Oct 2017 16:31:58 +0100, Wookey wrote:

> On 2017-10-18 12:08 +, Felipe Sateler wrote:
>> On Wed, 18 Oct 2017 11:36:41 +0200, Guillem Jover wrote:
>> 
>> > And I've got to question whether we should keep supporting it or just
>> > declare dpkg-buildpackage to be that entry point.
>> 
>> I think it makes sense to declare dpkg-buildpackage the official entry
>> point.
> 
> I too am reasonably happy with this idea, for the reasons you and Felipe
> gave, however I can think of one potential issue.
> 
>> Reasons against:
> 
> I quite often use the debian/rules binary{-arch,-indep} interface when
> doing porting/bootstrapping work (i.e the package built but something
> goes wrong in the packaging process so I want to retry with a tweak or a
> bodge)
> 
> In theory I should be able to do dpkg-buildpackage -nc --target=binary

Two things:

1. -nc is not necessary when passing --target. 
2. You mentioned binary{-arch,-indep} earlier but here --target=binary.
   Perhaps that is the source of the discrepancy? Note that you can call
   any target, not just the official ones. (You may need to also pass 
   --as-root too though).

> 
> but in practice I find that this often doesn't work as intended and it
> tries to do the whole build again. I have not investigated exactly why
> this is, and I guess you'll want me to give you a concrete example next.

This sound a lot like a bug somewhere. So yeah, discussion in the 
abstract is not going to do much because what you describe is not 
supposed to happen. Clearly something is failing somewhere, but without 
concrete examples I don't think there's anything actionable.



-- 
Saludos,
Felipe Sateler

Bug#879050: ITP: python-json-rpc -- Python implementation of JSON-RPC 1.0 and 2.0

[Ghislain Antony Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 

* Package name: python-json-rpc
  Version : 1.10.3
  Upstream Author : Kirill Pavlov 
* URL : https://github.com/pavlov99/json-rpc
* License : Expat
  Programming Lang: Python
  Description : Python implementation of JSON-RPC 1.0 and 2.0

This package will be co-maintained by the DPMT. It is a dependency for
the python-language-server package.

Bug#879051: ITP: prose -- golang library for text processing

[Dr. Tobias Quathamer]

Package: wnpp
Severity: wishlist
Owner: Dr. Tobias Quathamer 

* Package name: prose
  Version : 1.1.0-1
  Upstream Author : Joseph Kato
* URL : https://github.com/jdkato/prose
* License : Expat
  Programming Lang: Go
  Description : golang library for text processing

 prose is Go library for text (primarily English at the moment)
 processing that supports tokenization, part-of-speech tagging,
 named-entity extraction, and more. The library's functionality
 is split into subpackages designed for modular use.


This package is needed for the new upstream version of hugo.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#879062: ITP: libepc -- Easy Publish and Consume library

[Jeremy Bicha]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Owner: jbi...@debian.org

Package Name: libepc
Version: 4.99.11
Upstream Authors : Openismus GmbH
License : LGPL-2.1+.
Programming Lang: C

Description: Easy Publish and Consume library
 The Easy Publish and Consume library provides an easy method to publish
 data per HTTPS announce that information via DNS-SD, find that information
 and finally consume it.

Other Info
--
The Debian GNOME team intends to maintain this package.

libepc was in Debian, maintained by the Debian GNOME team until 2015
when it was removed because nothing used it.

It is being packaged now in order to package glom (#258096). According
to wnpp [1], glom is the 4th oldest requested package for Debian
(2004).

Packaging is at
https://anonscm.debian.org/git/pkg-gnome/libepc.git

The original ITP for libepc is https://bugs.debian.org/454805

The other ITP needed for glom is goocanvasmm-2.0: https://bugs.debian.org/878822

[1] https://www.debian.org/devel/wnpp/being_packaged_byage

Thanks,
Jeremy Bicha

Re: Unsustainable debian/rules as official build entry point?

[Russ Allbery]

Guillem Jover  writes:

> Given the above, and that these are clear regressions, it seems
> obvious to me that we are (collectively) not checking/using debian/rules
> as the official build entry point interface.

> And I've got to question whether we should keep supporting it or just
> declare dpkg-buildpackage to be that entry point.

I'm definitely in favor of declaring dpkg-buildpackage to be the only
officially supported entry point for kicking off a package build.  Insofar
as we can without losing anything significant, I'm in favor of
standardizing and simplifying how Debian packages are built, if for no
other reason than that it means we're not theoretically promising things
we're not actually testing.

It's rarely a good idea in computing to promise that something works when
no one uses it seriously or consistently.  In that case, it rarely
actually works, and people who rely on that promise will just be
frustrated.

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