On Thu, Feb 6, 2020 at 9:23 PM Richard Laager wrote:
> FWIW, at $DAYJOB, our stance is to accept all debconf defaults (e.g. use
> "hit enter at every prompt" or use noninteractive mode) and then
> configure after / on top of that (via debconf or not). So to me, in
> practice, debconf defaulting to
On Thu, Feb 6, 2020 at 12:34 AM Steffen Möller wrote:
> I think your dispute goes down to the question if Debian's community
> infrastructure should preferably using software packaged for Debian
> (which salsa is doing) with the binaries Debian offers (which salsa is
> not doing).
I personally wo
Package: wnpp
Severity: wishlist
Owner: Guillem Jover
* Package name: liburing
Version : 0.4
Upstream Author : Jens Axboe
* URL : https://git.kernel.dk/cgit/liburing/
* License : LGPL and MIT/X
Programming Lang: C
Description : Linux kernel io_uring ac
* Michael Stone:
> On Fri, Feb 07, 2020 at 02:46:19PM +0200, Wouter Verhelst wrote:
>>On Fri, Feb 07, 2020 at 10:31:16AM +, Simon McVittie wrote:
>>> On Fri, 07 Feb 2020 at 09:28:24 +0200, Wouter Verhelst wrote:
>>> > Why not? This seems like the type of problem that SONAMEs are made for.
>>>
* Sam Hartman:
> Steve, you're presuming that we would not create a new soname for libc6
> on architectures where we want a new time ABI.
That seems to be a reasonable assumption because Debian would have to
use a different soname from upstream. glibc upstream does not seem
likely to change sona
* Steve McIntyre:
> The kernel is *basically* fixed now. Internally, data structures
> should now be safe. There are a small number places where 32-bit time
> is still a thing, but it's in hand. A number of syscalls, ioctls,
> etc. have needed updates for the user-kernel interface level.
XFS is t
On Fri, Feb 7, 2020 at 10:17 AM Sudip Mukherjee
wrote:
>
> On Thu, Feb 6, 2020 at 10:53 PM Christian Barcenas
> wrote:
> >
> > I just noticed that your packaging repo is currently empty.
> > Would you be able to push your current progress to Github
> > so that it's easier to review the source pac
Wouter Verhelst, le ven. 07 févr. 2020 14:46:19 +0200, a ecrit:
> On Fri, Feb 07, 2020 at 10:31:16AM +, Simon McVittie wrote:
> > On Fri, 07 Feb 2020 at 09:28:24 +0200, Wouter Verhelst wrote:
> > > Why not? This seems like the type of problem that SONAMEs are made for.
> > > What am I missing?
On Fri, Feb 07, 2020 at 02:46:19PM +0200, Wouter Verhelst wrote:
On Fri, Feb 07, 2020 at 10:31:16AM +, Simon McVittie wrote:
On Fri, 07 Feb 2020 at 09:28:24 +0200, Wouter Verhelst wrote:
> Why not? This seems like the type of problem that SONAMEs are made for.
> What am I missing?
SONAMEs a
On Fri, Feb 07, 2020 at 10:31:16AM +, Simon McVittie wrote:
> On Fri, 07 Feb 2020 at 09:28:24 +0200, Wouter Verhelst wrote:
> > Why not? This seems like the type of problem that SONAMEs are made for.
> > What am I missing?
>
> SONAMEs are set by the upstream developer in their build system
Ye
On Fri, 2020-02-07 at 11:49:55 +, Philip Hands wrote:
> It seems that most (26) packages are explicitly preferring bsd-mailx,
> which seems fair enough to me.
Ack.
> heirloom-mailx is a dummy package that depends on s-nail, where s-nail
> does not actually provide mailx, so I suspect that men
On Thu, 2020-02-06 at 09:39:29 +0100, Michael Biebl wrote:
> Am 06.02.20 um 09:22 schrieb Adam D. Barratt:
> > On 2020-02-06 08:12, Paul Gevers wrote:
> > > But, if I am correct, the source could be using a version without epoch
> > > and only use the epoch in the binary package (which can be dropp
Hi,
While installing a new system, I was bitten by #253513 which lead me to
wonder how I had ended up with mailutils rather than bsd-mailx.
It seems that this was the result of installing emacs, which pulled in
exim4 and thus exim4-base, which recommends the virtual package 'mailx'
which is provi
On Tue, 04 Feb 2020 at 13:14:10 +, Steve McIntyre wrote:
> Arnd scanned the library packages in the Debian archive and identified
> that about one third of our library packages would need rebuilding
> (and tracking) to make a (recursive) transition.
Is a list of affected/unaffected packages av
On Fri, 07 Feb 2020 at 09:28:24 +0200, Wouter Verhelst wrote:
> Why not? This seems like the type of problem that SONAMEs are made for.
> What am I missing?
SONAMEs are set by the upstream developer in their build system (building
the same source code produces the same SONAME), and are cross-distr
On Thu, Feb 6, 2020 at 10:53 PM Christian Barcenas
wrote:
>
> I just noticed that your packaging repo is currently empty.
> Would you be able to push your current progress to Github
> so that it's easier to review the source package?
Pushed now. Its without any epoch in the version. I will add th
On Thu, 6 Feb 2020 15:23:17 -0600, Richard Laager
wrote:
>FWIW, at $DAYJOB, our stance is to accept all debconf defaults (e.g. use
>"hit enter at every prompt" or use noninteractive mode) and then
>configure after / on top of that (via debconf or not). So to me, in
>practice, debconf defaulting to
Package: wnpp
Severity: wishlist
Owner: Sophie Brun
* Package name: ospd-openvas
Version : 1.0.0
Upstream Author : Greenbone Networks GmbH
* URL : https://github.com/greenbone/ospd-openvas
* License : GPL-2+
Programming Lang: Python3
Description : OSP s
Package: wnpp
Severity: wishlist
Owner: Sophie Brun
* Package name: ospd
Version : 2.0.0
Upstream Author : Greenbone Networks GmbH
* URL : https://github.com/greenbone/ospd
* License : GPL-2+
Programming Lang: Python3
Description : Open Scanner Protocol
19 matches
Mail list logo
