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
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 librar
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 proce
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 : Pyth
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.
>>
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
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 re
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
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 fak
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 quest
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
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 lik
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
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?
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 Hu
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
(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
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 plugi
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
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?
B
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-target
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
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:
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 pr
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 w
25 matches
Mail list logo
