2014.04.20. 7:47, "Riku Voipio" ezt írta:
>
> On Sat, Apr 19, 2014 at 02
>
> On Sat, Apr 19, 2014 at 02:06:45PM +0200, Bálint Réczey wrote:
> > Hi Riku,
> >
> > 2014-04-19 13:26 GMT+02:00 Riku Voipio :
> > > On Tue, Apr 15, 2014 at 12:00:33PM +0200, Balint Reczey wrote:
> > >> Facing last week's H
Stuart Prescott debian.org> writes:
> Unfortunately, the people who understand multiarch well enough to write it
> up for policy haven't done so which leaves us with no normative
> documentation in policy for the the Multi-Arch field in Packages, no
> description of how the package manager sho
Jonas Smedegaard jones.dk> writes:
> >> How to reconfigure debconf from postinst of another package?
I also thought that was absolutely forbidden.
> > Note that, if, as an admin, I explicitly choose an option in debconf
> > and then, latter, another package overwrite my choice (or even
>
Quoting Thorsten Glaser (2014-04-20 14:04:22)
> Jonas Smedegaard jones.dk> writes:
>
How to reconfigure debconf from postinst of another package?
>
> I also thought that was absolutely forbidden.
>
>>> Note that, if, as an admin, I explicitly choose an option in debconf
>>> and then, latte
On 20 April 2014 12:58, Thorsten Glaser wrote:
> Stuart Prescott debian.org> writes:
>
>> Unfortunately, the people who understand multiarch well enough to write it
>> up for policy haven't done so which leaves us with no normative
>> documentation in policy for the the Multi-Arch field in Packag
Le Fri, Apr 18, 2014 at 03:56:41PM +0200, Jonas Smedegaard a écrit :
>
> I find it worrisome if only mutually coordinated packages can configure
> each other: I fear that that scales badly.
Hi Jonas,
first, thanks for working on the concept of using Debian packages to
extensively reconfigure a
Hi Wookey,
Wookey (2014-04-20):
> You may or may not have noticed that 'arm64' is coming. This a 64-bit
> arm architecture also known as 'aarch64' and implemented in the ARM
> CPU architecture 'v8'. Apart from iphones there is no publically
> available 64-bit silicon yet, but that'll be changing
+++ Stuart Prescott [2014-04-18 17:25 +1000]:
> Hi Eugene,
>
> > It seems that in jessie (and similar in sid) a number of packages [1]
> > started to use ':' symbol in their dependency lists as part of package
> > names. This is, if I'm not misreading the Debian Policy §7.1 and §5.6.1,
> > is not
Thorsten Glaser wrote:
> Stuart Prescott debian.org> writes:
>
>> Unfortunately, the people who understand multiarch well enough to write
>> it up for policy haven't done so which leaves us with no normative
>> documentation in policy for the the Multi-Arch field in Packages, no
>> description o
On Sun, Apr 20, 2014 at 02:27:01AM +0100, Wookey wrote:
> You may or may not have noticed that 'arm64' is coming. This a 64-bit
> arm architecture also known as 'aarch64' and implemented in the ARM
> CPU architecture 'v8'. Apart from iphones there is no publically
> available 64-bit silicon yet
qe
Hi Charles,
Quoting Charles Plessy (2014-04-20 15:14:17)
> Le Fri, Apr 18, 2014 at 03:56:41PM +0200, Jonas Smedegaard a écrit :
>>
>> I find it worrisome if only mutually coordinated packages can
>> configure each other: I fear that that scales badly.
> [...] I do not see how [reconfiguring one
On 20 April 2014 15:30, Adam Borowski wrote:
> On Sun, Apr 20, 2014 at 02:27:01AM +0100, Wookey wrote:
>> You may or may not have noticed that 'arm64' is coming. This a 64-bit
>> arm architecture also known as 'aarch64' and implemented in the ARM
>> CPU architecture 'v8'. Apart from iphones there
Hi,
Quoting Wookey (2014-04-20 16:24:46)
> So far as I know that spec doc is correct for Debian and Ubuntu. The only
> significant difference is that Ubuntu has patched apt to assume that :all
> packages are M-A:foreign by default. Debian has not, and requires all
> packages to be so marked explic
> As xnox says there is still some pending changes around the interpreter
> problem, as described here:
> https://wiki.debian.org/HelmutGrohne/MultiarchSpecChanges
>
> And that debate is part of the reason this stuff hasn't been
> considered 'finalised' and thus ready for policy. But I think the
* Russ Allbery:
>> The correct long-term fix is to change autotools to check a list of
>> well-known paths for more recent versions of the scripts and use them
>> instead of what is provided in the package.
>
> This doesn't regenerate the other files from scratch. This only addresses
> config.{su
* Julien Cristau:
> There's no reason the binary packages can't be named conquest-postgres
> and conquest-mysql even if the source is conquest-dicom-server. And the
> source package name is mostly user-invisible. A shorter name is very
> much not a better one.
Agreed, we had quite a bit fun wit
> You may or may not have noticed that 'arm64' is coming. This a 64-bit
> arm architecture also known as 'aarch64' and implemented in the ARM
> CPU architecture 'v8'. Apart from iphones there is no publically
> available 64-bit silicon yet, but that'll be changing rapidly later
> this year and this
On Sun, 2014-04-20 at 16:30 +0200, Adam Borowski wrote:
> On Sun, Apr 20, 2014 at 02:27:01AM +0100, Wookey wrote:
> > You may or may not have noticed that 'arm64' is coming. This a 64-bit
> > arm architecture also known as 'aarch64' and implemented in the ARM
> > CPU architecture 'v8'. Apart from i
On Sun, 2014-04-20 at 16:13 +0100, Ben Hutchings wrote:
> On Sun, 2014-04-20 at 16:30 +0200, Adam Borowski wrote:
> > On Sun, Apr 20, 2014 at 02:27:01AM +0100, Wookey wrote:
> > > You may or may not have noticed that 'arm64' is coming. This a 64-bit
> > > arm architecture also known as 'aarch64' an
On Sun, 2014-04-20 at 17:08 +0200, Florian Weimer wrote:
> > You may or may not have noticed that 'arm64' is coming. This a 64-bit
> > arm architecture also known as 'aarch64' and implemented in the ARM
> > CPU architecture 'v8'. Apart from iphones there is no publically
> > available 64-bit silico
On Sun, 2014-04-20 at 16:28 +0100, Ian Campbell wrote:
> That said I can't see any reason not to get started on an arm64 kernel.
Except:
The following packages have unmet dependencies:
sbuild-build-depends-linux-dummy : Depends: python but it is not going to be
installed
On Sun, 2014-04-20 at 16:28 +0100, Ian Campbell wrote:
> On Sun, 2014-04-20 at 16:13 +0100, Ben Hutchings wrote:
> > On Sun, 2014-04-20 at 16:30 +0200, Adam Borowski wrote:
> > > On Sun, Apr 20, 2014 at 02:27:01AM +0100, Wookey wrote:
> > > > You may or may not have noticed that 'arm64' is coming.
Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij
* Package name: python-topia.termextract
Version : 1.1.0
Upstream Author : Stephan Richter, Russ Ferriday et al.
* URL : https://pypi.python.org/pypi/topia.termextract
* License : ZPL 2.1
Programming Lan
On Sun, Apr 20, 2014 at 04:28:45PM +0100, Ian Campbell wrote:
> On Sun, 2014-04-20 at 16:13 +0100, Ben Hutchings wrote:
> > Given that, it seems like a good time to add arm64 to src:linux with a
> > configuration that will run on at least a typical QEMU ARM64 emulation.
>
> AIUI qemu 2.0 only does
On Sun, 2014-04-20 at 09:08 -0700, Vagrant Cascadian wrote:
> On Sun, Apr 20, 2014 at 04:28:45PM +0100, Ian Campbell wrote:
> > On Sun, 2014-04-20 at 16:13 +0100, Ben Hutchings wrote:
> > > Given that, it seems like a good time to add arm64 to src:linux with a
> > > configuration that will run on a
Hi all,
Quoting Stuart Prescott (2014-04-20 16:58:21)
> > As xnox says there is still some pending changes around the interpreter
> > problem, as described here:
> > https://wiki.debian.org/HelmutGrohne/MultiarchSpecChanges
> >
> > And that debate is part of the reason this stuff hasn't been
> >
Package: wnpp
Severity: wishlist
Owner: Zygmunt Krynicki
* Package name: twine
Version : 1.3.1
Upstream Author : Donald Stufft
* URL : https://github.com/dstufft/twine
* License : Apache 2.0
Programming Lang: Python
Description : Collection of utilit
Hi,
A few things led me to question whether it is safe for OpenSSL to enable
so many features. The heartbeat extension was not likely being used by
anyone for its stated legitimate purpose. I've yet to use/need DTLS. I
wondered if we could have had something along the lines of an
openssl-heavy
Package: wnpp
Severity: wishlist
Owner: Philipp Huebner
* Package name: erlang-ibrowse
Version : 4.1.0
Upstream Author : 2003-2014 Chandrashekhar Mullaparthi
* URL : https://github.com/cmullaparthi/ibrowse
* License : LGPL-2.1+ or BSD 3-Clause
Programming L
Heya,
On Sun, Apr 20, 2014 at 07:07:45PM +0100, Steven Chamberlain wrote:
> I wonder if this might result in an alternate SSL/TLS library we could
> use in Debian?
Probably - but I think there is enough time left for jessie that we
don't need to jump to conclusion already and can watch this unfol
Package: wnpp
Severity: wishlist
Owner: Zygmunt Krynicki
* Package name: releases
Version : 0.6.1
Upstream Author : Jeff Forcier
* URL : https://github.com/bitprophet/releases
* License : BDS
Programming Lang: Python
Description : A Sphinx extension
Florian Weimer writes:
> * Russ Allbery:
>> This doesn't regenerate the other files from scratch. This only
>> addresses config.{sub,guess}, which is only a small part of the
>> problem.
> Is the generated libtool file dependent on the package configuration?
No, but you have to re-run autoconf
On Apr 20, Steven Chamberlain wrote:
> I wonder if this might result in an alternate SSL/TLS library we could
> use in Debian?
Let's see next year how much the OpenBSD thing will be:
- portable
- interoperable
- gaining new features
They are removing things like FIPS support which are vital for
On Sun, Apr 20, 2014 at 07:07:45PM +0100, Steven Chamberlain wrote:
> Hi,
>
> But meanwhile, OpenBSD developers are extensively cleaning up OpenSSL
> 1.0.1g.
One of the problems with anything from OpenBSD is that they only
care about OpenBSD, and if you want to use that fork you'll
actually have
Le Sun, Apr 20, 2014 at 07:53:57PM +0200, Johannes Schauer a écrit :
>
> I wholeheartedly agree with Stuart's email. I would love to see policy lead
> the
> way. But as somebody who comes up with new things that might end up in policy:
> how to proceed? My current approach is to write countless m
On Sun, Apr 20, 2014 at 03:24:46PM +0100, Wookey wrote:
> So far as I know that spec doc is correct for Debian and Ubuntu. The
> only significant difference is that Ubuntu has patched apt to assume
> that :all packages are M-A:foreign by default. Debian has not, and
> requires all packages to be s
On Sun, Apr 20, 2014 at 11:58:59AM +, Thorsten Glaser wrote:
> Stuart Prescott debian.org> writes:
>
> > Unfortunately, the people who understand multiarch well enough to write it
> > up for policy haven't done so which leaves us with no normative
> > documentation in policy for the the Mul
previously on this list people contributed:
> On Sun, Apr 20, 2014 at 07:07:45PM +0100, Steven Chamberlain wrote:
> > Hi,
> >
> > But meanwhile, OpenBSD developers are extensively cleaning up OpenSSL
> > 1.0.1g.
>
> One of the problems with anything from OpenBSD is that they only
> care about Op
Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho
* Package name: heartbleeder
Upstream Author : Jonathan Rudenberg
* URL : https://github.com/titanous/heartbleeder
* License : BSD-3-Clause
Programming Lang: Go (golang)
Description : test servers
Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij
* Package name: quassel-irssi
Upstream Author : Pierre-Hugues Husson
* URL : http://github.com/phhusson/quassel-irssi
* License : Unknown (contacted upstream about this)
Programming Lang: C
Description : An
I agree it's not going to be portable in the near term, though there are
interesting changes being made and good code review happening.
Some dubious entropy sources were (only potentially?) used with
RAND_seed/add:
digests:
http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/dsa/dsa_a
On Mon, 21 Apr 2014, Charles Plessy wrote:
> things are too slow or not happening is the lack of manpower. See for example
> the documentation of the Dpkg triggers: we miss only one single Debian
> Developer to review the discussion and the patch in #582109 (I even offered to
> go piece by piece,
Le Sun, Apr 20, 2014 at 11:06:00PM -0300, Henrique de Moraes Holschuh a écrit :
> On Mon, 21 Apr 2014, Charles Plessy wrote:
> > things are too slow or not happening is the lack of manpower. See for
> > example
> > the documentation of the Dpkg triggers: we miss only one single Debian
> > Develop
On 17/04/14 00:23, Aaron Zauner wrote:
> Now shipping grsec is a really good idea. I'd like to see that as well.
There has been an attempt to provide an official grsec-flavour of the
Debian kernel, but it didn't worked:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605090
For those interested
Package: wnpp
Severity: wishlist
Owner: Praveen Arimbrathodiyil
* Package name: ruby-omniauth-wordpress
Version : 0.2.0
Upstream Author : Magda Sikorska
* URL : https://rubygems.org/gems/omniauth-wordpress
* License : https://github.com/elrosa/omniauth-wordpres
45 matches
Mail list logo
