On 10/19/18 12:25 PM, Bastian Blank wrote:
> On Fri, Oct 19, 2018 at 11:35:54AM +0200, Martin Steigerwald wrote:
>> So Devuan almost doubles the percentage of sysvinit-core installations.
>
> Devuan is _not_ Debian. They forked it
They *claimed* it was a fork, though in reality Devuan is just y
On Sun, Oct 21, 2018 at 10:00:43PM +, Ivan Shmakov wrote:
It can be argued that libgpgme11 does not “provide a significant
amount of functionality” (7.2) without gnupg.
It won't function at all without gnupg.
However, and it seems to be a common practice in Debian, for a shared
library pa
On Sun, Oct 21, 2018 at 09:57:45PM +, Ivan Shmakov wrote:
I disagree; to the best of my knowledge, anyone can do the testing and
suggest any fixes he or she deems necessary. As such, having an issue
recorded in the BTS is preferable to not having it recorded, and
having a (semi-correct)
> Jonathan Dowland writes:
> On Sun, Oct 21, 2018 at 10:00:43PM +, Ivan Shmakov wrote:
>> It can be argued that libgpgme11 does not “provide a significant
>> amount of functionality” (7.2) without gnupg.
> It won’t function at all without gnupg.
As I’ve said before, havin
> Jonathan Dowland writes:
> On Sun, Oct 21, 2018 at 09:57:45PM +, Ivan Shmakov wrote:
>> I disagree; to the best of my knowledge, anyone can do the testing
>> and suggest any fixes he or she deems necessary. As such, having an
>> issue recorded in the BTS is preferable to not hav
Hi All,
I was not sure to which Mailing list my question belongs so I'm writing here,
if I should use a different list, let me know.
Currently I'm trying to create a .deb package for my Application and I'm kind
of stuck with packaging a shared library that I use. The shared library is not
av
Package: www.debian.org
Control: submitter -1 Holger Wansing
On Sun, Oct 21, 2018 at 11:01:31AM +0200, Holger Wansing wrote:
> Hi,
>
> apparently the two addresses below (spaillard and atterer) are included in
> the cdvendors@d.o alias.
> Please remove them, since they are no longer existing. T
Hi Damir,
On Mon, Oct 22, 2018 at 10:36:12AM +, Damir Porobic wrote:
> I was not sure to which Mailing list my question belongs so I'm writing here,
> if I should use a different list, let me know.
According to the content of your mail I think debian-u...@lists.debian.org
is a more proper pl
Package: wnpp
Severity: wishlist
Owner: Ilias Tsitsimpis
* Package name: haskell-resolv
Version : 0.1.1.1
Upstream Author : Herbert Valerio Riedel
* URL : https://hackage.haskell.org/package/resolv
* License : GPL-3+
Programming Lang: Haskell
Description
Hi Wookey and Bastian,
On Sun, Oct 21, 2018 at 06:51:16PM +0100, Wookey wrote:
> On 2018-10-21 17:16 +0200, Bastian Blank wrote:
> > Hi
> >
> > On Sun, Oct 21, 2018 at 09:51:15AM +, Mo Zhou wrote:
> > > about naming convention of SONAME and package name.
> > >
> > > As discussed in [1][2][3]
Hi Mo,
Thanks for the feedback, I will write on debian-u...@lists.debian.org.
> I don't know what "public repo" mean. If you meant to create debian
> package that installs stuff under /usr/local , then there is no any
> example from Debian's official archive at all.
Well, I mean you can't inst
* Matthias Klumpp [181021 14:04]:
> libgpgme is communicating with gnupg in the background - having
> libgpgme without gnupg itself will render the library completely
> unusable and break existing users of the library.
This keeps getting repeated in this thread in spite of the fact that
multiple
On Mon, 2018-10-22 at 15:07 +, Mo Zhou wrote:
> Hi Wookey and Bastian,
>
> On Sun, Oct 21, 2018 at 06:51:16PM +0100, Wookey wrote:
> > On 2018-10-21 17:16 +0200, Bastian Blank wrote:
> > > Hi
> > >
> > > On Sun, Oct 21, 2018 at 09:51:15AM +, Mo Zhou wrote:
> > > > about naming convention
On Mon, Oct 22, 2018 at 11:32:21AM -0400, Marvin Renich wrote:
> * Matthias Klumpp [181021 14:04]:
> > libgpgme is communicating with gnupg in the background - having
> > libgpgme without gnupg itself will render the library completely
> > unusable and break existing users of the library.
>
> Thi
On Mon, 22 Oct 2018 at 18:17:32 +0100, Ben Hutchings wrote:
> On Mon, 2018-10-22 at 15:07 +, Mo Zhou wrote:
> > Here are some references:
> >
> > 1.
> > https://software.intel.com/en-us/mkl-linux-developer-guide-using-the-ilp64-interface-vs-lp64-interface
> >
> >The Intel MKL ILP64 libra
On 22 Oct 2018, at 18:17, Ben Hutchings wrote:
> On Mon, 2018-10-22 at 15:07 +, Mo Zhou wrote:
>> Hi Wookey and Bastian,
>>
>> On Sun, Oct 21, 2018 at 06:51:16PM +0100, Wookey wrote:
>>> On 2018-10-21 17:16 +0200, Bastian Blank wrote:
Hi
On Sun, Oct 21, 2018 at 09:51:15AM +000
Le lundi 22 octobre 2018 à 18:38 +0100, Simon McVittie a écrit :
> On Mon, 22 Oct 2018 at 18:17:32 +0100, Ben Hutchings wrote:
> > On Mon, 2018-10-22 at 15:07 +, Mo Zhou wrote:
> > > Here are some references:
> > >
> > > 1.
> > > https://software.intel.com/en-us/mkl-linux-developer-guide-usin
On Mon, Oct 22, 2018 at 07:55:10PM +0200, Sébastien Villemot wrote:
> For BLAS/LAPACK implementations implemented in C, like OpenBLAS, they
> will be compiled using LP64, and not ILP64. Only integers exposed
> through the interface will be affected, through the use of appropriate
> types.
So you c
Am Mo., 22. Okt. 2018 um 17:32 Uhr schrieb Marvin Renich :
>
> * Matthias Klumpp [181021 14:04]:
> > libgpgme is communicating with gnupg in the background - having
> > libgpgme without gnupg itself will render the library completely
> > unusable and break existing users of the library.
>
> This k
On 2018-10-22 23:07, Mo Zhou wrote:
Are any
other packages likely to start wanting to use ILP64 ABIs? I guess it's
very much an 'HPC' sort of thing at the moment.
So yeah, some clarification in order I think, and an explanation of
use-cases.
HPC is indeed a related use case. I don't know a
* Mo Zhou:
> Proposal:
>
> * The "-ilp64" postfix should be appended to the SONAME of all the new
> shared objects that provide ILP64 interface. For example:
>
> libblas.so.3 (LP64) -> libblas-ilp64.so.3 (ILP64)
>
> As a result, the same postfix should be added to the binary packag
Adam Borowski writes:
> Thus, I'd re-propose a Policy change that was mentioned in multiple
> threads in the past:
> "A runtime library should not Depend: or Recommend: on any packages than
> other libraries or dormant data, unless the library or its programming
> language provides a convenient
On Mon, Oct 22, 2018 at 01:22:12PM -0700, Russ Allbery wrote:
> Adam Borowski writes:
>
> > Thus, I'd re-propose a Policy change that was mentioned in multiple
> > threads in the past:
>
> > "A runtime library should not Depend: or Recommend: on any packages than
> > other libraries or dormant d
Fixed debian-de...@debian.org -> debian-devel@lists.debian.org so that
people who reply won't have to do this to avoid bounced emails. Sorry
for the mistake!
Hi James,
On Mon, Oct 22, 2018 at 07:16:51PM -0400, James McCoy wrote:
> On Mon, Oct 22, 2018 at 05:33:06PM -0400, Nicholas D Steeves wrot
On Tue, Oct 23, 2018 at 8:10 AM Nicholas D Steeves wrote:
> In terms of "big project" ideas, I think it would be neat if there was
> a tool that integrated the pkg_from_testing->no_change_bpo
> transformation, my tool, and also "Rebuild all the Things" (Sean
> Whitton told me about this tool).
>
>
Hi,
I'm quite concerned by what I think is a user perception problem
around LTS. When the LTS project started up, discussions made it clear
that existing maintainers and teams were *encouraged* but not
*required* to help with the LTS effort. Paid effort would be used to
help fill in for security s
I've seen this sort of thing done elsewhere and the way they did it was to
put a large amount of separation between the two.
So the main site only mentioned the old releases in a historical context
and pointed to a separate website which did the LTS. Any page for the older
versions had a prominent
27 matches
Mail list logo
