On 11/12/2016 08:10 AM, Andrey Rahmatullin wrote:
> On Sat, Nov 12, 2016 at 12:58:13AM +0100, Adam Borowski wrote:
>>> What stops us from throwing away .debs from maintainers starting tomorrow?
>>
>> The machinery for arch:all binaries is still incomplete:
> Fine, what stops us from throwing away a
Hi,
Quoting Ximin Luo (2016-11-10 18:13:00)
> Holger Levsen wrote:
> > On Thu, Nov 10, 2016 at 08:59:48AM -0200, Johannes Schauer wrote:
> > > One solution would be to increase SOURCE_DATE_EPOCH by 1 second for every
> > > binNMU to a package.
> > >
> > > Any other ideas?
> > set SOURCE_DATE_EPOC
On Sat, Nov 12, 2016 at 12:58:13AM +0100, Adam Borowski wrote:
> > What stops us from throwing away .debs from maintainers starting tomorrow?
>
> The machinery for arch:all binaries is still incomplete:
Fine, what stops us from throwing away arch:!all .debs?
--
WBR, wRAR
signature.asc
Descrip
Hi,
Quoting Colin Watson (2016-11-12 03:58:04)
> On Sat, Nov 12, 2016 at 12:58:13AM +0100, Adam Borowski wrote:
> > * wanna-build(?)'s resolution of arch-specific build-depends is buggy. For
> > example, my package arch-test wants, among others:
> > binutils-x86-64-linux-gnu [!amd64 !i386 !x32] w
On Thu, Nov 10, 2016 at 08:52:15PM -0800, Nikolaus Rath wrote:
> On Nov 11 2016, Christoph Biedl wrote:
> > b) This is a serious issue as John D. Rebuilder should be free to choose
> >on which architecture to build "src:foo".
> >
> > Personally, I tend to b) since
> >
> > * there is no sane wa
Hi!
On Wed, 2016-11-09 at 12:12:43 +, Ian Jackson wrote:
> Peter Colberg writes ("What to do when a maintainer is blocking maintenance
> for stretch?"):
> > Improving the package would require significant changes that are not
> > appropriate for a minimal NMU. With the maintainer not respondi
On Sat, Nov 12, 2016 at 12:58:13AM +0100, Adam Borowski wrote:
> The machinery for arch:all binaries is still incomplete:
> * it supports only packages buildable on amd64, there are some which require
> a specific host[1] arch
We (Ubuntu) discussed this with Debian ftpmaster/buildd-admin types a
On Fri, Nov 11, 2016 at 7:32 AM, Christoph Biedl wrote:
> implies "src:foo" must build on *all* architectures
In general, Debian does not define the build architecture for any
package, no matter what the Architecture of the package is.
In practice, arch:all packages must build on either amd64 (a
On Sat, Nov 12, 2016 at 6:32 AM, Christoph Biedl wrote:
> How would this affect your assessment of the situation?
The details matter, without them I don't think any assessment is useful.
> In my feeling, revealing the packages' names would give the story some kind of
> blaming. That's not my int
On Sat, Nov 12, 2016 at 03:53:39AM +0500, Andrey Rahmatullin wrote:
> On Fri, Nov 11, 2016 at 10:38:27PM +0100, Sebastian Andrzej Siewior wrote:
> > there are a bunch of package which were missing -dbgsym packages on
> > their arch upload. The buildd built them on the remaining architectures.
> > H
On Sat, Nov 12, 2016 at 03:53:39AM +0500, Andrey Rahmatullin wrote:
> What stops us from throwing away .debs from maintainers starting tomorrow?
The need of being able to upload .debs for bootstrapping reasons?
Sure, if dak's going to implement some override mechanism there should
really be no pr
On Fri, Nov 11, 2016 at 10:38:27PM +0100, Sebastian Andrzej Siewior wrote:
> there are a bunch of package which were missing -dbgsym packages on
> their arch upload. The buildd built them on the remaining architectures.
> Here are a few examples:
> - missing on amd64: aptly, meep, xdelta3
And coreu
On 2016-11-11 22:38 +0100, Sebastian Andrzej Siewior wrote:
> there are a bunch of package which were missing -dbgsym packages on
> their arch upload. The buildd built them on the remaining architectures.
> Here are a few examples:
> - missing on amd64: aptly, meep, xdelta3
> - missing on i386: ch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi there,
Am 02.11.2016 um 21:15 schrieb Kurt Roeckx:
> I don't think having libssl1-1-dev vs libssl1.0-dev is going to
> make much differences in the end. The build conflicts will always
> have to be sorted out.
thats the point where I rushed in
Paul Wise wrote...
> On Fri, Nov 11, 2016 at 7:32 AM, Christoph Biedl wrote:
>
> > Other suggestions?
>
> Include information about which packages/issues you are talking about.
How would this affect your assesment of the situation?
In my feeling, revealing the pakages' names would give the sto
Nikolaus Rath wrote...
> Just fix it in "bar", and don't bother worrying about the right
> severity?
If it was that simple ... The maintainers of "bar" haven't reacted to
the bug report for a few months although it contains a clear statement
the current state breaks the build of other packages. A
Package: wnpp
Severity: wishlist
Owner: "Jérémy Lal"
* Package name: node-tap-parser
Version : 3.0.3
Upstream Author : James Halliday (http://substack.net)
* URL : https://github.com/substack/tap-parser
* License : Expat
Programming Lang: JavaScript
Descr
Package: wnpp
Severity: wishlist
Owner: "Jérémy Lal"
* Package name: node-marked-man
Version : 0.1.6
Upstream Author : Jérémy Lal
* URL : https://github.com/kapouer/marked-man
* License : Expat
Programming Lang: JavaScript
Description : Markdown to man
Package: wnpp
Severity: wishlist
Owner: "Jérémy Lal"
* Package name: node-marked-man
Version : 0.1.5
Upstream Author : Jérémy Lal
* URL : https://github.com/kapouer/marked-man
* License : Expat
Programming Lang: JavaScript
Description : Markdown to man
there are a bunch of package which were missing -dbgsym packages on
their arch upload. The buildd built them on the remaining architectures.
Here are a few examples:
- missing on amd64: aptly, meep, xdelta3
- missing on i386: chasen, cronutils, maildrop
my understanding is that those are built and
Package: wnpp
Severity: wishlist
Owner: "Çağrı ULAŞ"
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-...@lists.debian.org
* Package name: deepnano
Upstream Author : Vladimir Boza
* URL : https://bitbucket.org/vboza/deepnano/
* License : (BSD-3-clause)
Programming
On viernes, 11 de noviembre de 2016 16:05:49 ART Jan Niehusmann wrote:
> On Fri, Nov 11, 2016 at 03:15:09PM +0100, Kurt Roeckx wrote:
> > At least something like that also came up with xmltooling.
> > It's probably caused by this:
> > curl_easy_setopt(easy, CURLOPT_SSL_CTX_FUNCTION, &sslCtxFunction
Package: wnpp
Severity: wishlist
Owner: Stefano Rivera
* Package name: ruby-knife-acl
Version : 1.0.3
Upstream Author : Seth Falcon , Jeremiah Snapp
* URL : https://github.com/chef/knife-acl
* License : Apache-2.0
Programming Lang: Ruby
Description :
Package: wnpp
Severity: wishlist
Owner: "Jérémy Lal"
* Package name: node-tmatch
Version : 3.0.0
Upstream Author : Isaac Z. Schlueter (http://blog.izs.me/)
* URL : https://github.com/isaacs/tmatch#readme
* License : ISC
Programming Lang: JavaScript
Descrip
On Fri, Nov 11, 2016 at 03:15:09PM +0100, Kurt Roeckx wrote:
> At least something like that also came up with xmltooling.
> It's probably caused by this:
> curl_easy_setopt(easy, CURLOPT_SSL_CTX_FUNCTION, &sslCtxFunction_cb);
>
> You get an SSL_CTX from OpenSSL 1.1 and you call an OpenSSL 1.0
> fu
Package: wnpp
Severity: wishlist
Owner: Micah Anderson
* Package name: ruby-ya2yaml
Version : 0.31
Upstream Author : Akira FUNAI
* URL : http://rubyforge.org/projects/ya2yaml/
* License : MIT
Programming Lang: Ruby
Description : An UTF8 safe YAML dumpe
On Fri, Nov 11, 2016 at 01:23:31PM +0100, Jan Niehusmann wrote:
> Hi,
>
> But who knows which other packages are silently broken the same way?
At least something like that also came up with xmltooling.
It's probably caused by this:
curl_easy_setopt(easy, CURLOPT_SSL_CTX_FUNCTION, &sslCtxFunction_
Hi,
(Cc to Alessandro because this causes issues with libcurl)
On Wed, Nov 02, 2016 at 09:15:13PM +0100, Kurt Roeckx wrote:
> I don't think having libssl1-1-dev vs libssl1.0-dev is going to
> make much differences in the end. The build conflicts will always
> have to be sorted out.
Well I think
On Tuesday 01 November 2016 02:01 PM, Pirate Praveen wrote:
> We shifted out focus to grunt from browserify realizing grunt is needed
> by more packages.
Final update before the fund raising closes in about 20 hours
https://poddery.com/posts/2734574
Summary: all new dependencies are completed (4
On Fri, 11 Nov 2016, Christoph Biedl wrote:
> a proof of concept for all this (I can resist, though). The apt programs
> could obfuscate their request behaviour, the TLS layer could add random
> padding of data and time, but I doubt this would help much.
AFAIK, the TLS layer *does* bit-stuffing an
Package: wnpp
Severity: wishlist
Owner: picca
* Package name: ufo-core
Version : 0.11.0
Upstream Author : matthias.vogelges...@kit.edu
* URL : http://ufo.kit.edu/
* License : LGPL-3+
Programming Lang: C, Python
Description : Library for high-performance
Package: wnpp
Severity: wishlist
Owner: Jordi Mallach
* Package name: goiardi
Version : 0.11.0+git20161027.4.7d585ad-1
Upstream Author : Jeremy Bingham
* URL : https://github.com/ctdk/goiardi
* License : Apache-2.0
Programming Lang: Go
Description : A C
Hi,
On Fri, Nov 04, 2016 at 11:58:44PM +0200, Adrian Bunk wrote:
> You could enforce that no Qt-using package uses the wrong OpenSSL by
> adding libssl1.0-dev dependencies to libqt4-dev and qtbase5-dev.
How can I handle the case of a package which uses both qt and curl? The
latter already switch
33 matches
Mail list logo
