Package: wnpp
Severity: wishlist
Owner: Eric Dorland
* Package name: golang-github-cloudflare-circl
Version : 1.0.0
Upstream Author : Cloudflare
* URL : https://github.com/cloudflare/circl
* License : BSD
Programming Lang: Go
Description : Cloudflare In
On 7/28/19 10:59 PM, Joaquin de Andres wrote:
[..]
> * Active helping developers with the utilization of Salsa CI pipeline. At
> least 4 project were initialized.
Actually there were more than 10! 😄
--
TiN
signature.asc
Description: OpenPGP digital signature
Hi!
Part of the Salsa CI Team met at Debconf 2019 in Curitiba, and during the past
two weeks we managed to work on continuing to improve the project on different
topics:
* Diffusion on the usage and the importance of the project have been made.
We presented two Long talks, one by Agustin Henze
Hi Marco,
After the merger of (64bit-indexing) * (multi-thread flavor)
feature enhancement, an libopenblas-julia package will
look abrupt, and break the symmetry of package layout
(libopenblas-julia doesn't need development files) :
~/D/o/o/debian ❯❯❯ rg \^Package control
19:Package: libopenblas0
I wrote:
>in GCC 6 IIRC and *still* pertinent in GCC 8 and I believe 9,
Still present in (sid/amd64):
• gcc-8 (= 8.3.0-19)
• gcc-9 (= 9.1.0-10)
• gcc-snapshot (= 1:20190719-1)
>>I'm currently compiling e2fsprogs with LTO for Debian --- and I'm
>>seriously considering ditching that change. The
>We just had SuSE embracing LTO
Not entirely.
With my DD hat doffed and wearing the mksh upstream developer hat,
I’ve been asking the package maintainers of mksh in all distributions
to remove the LTO flags, and will remove the built-in support for
using LTO in the next release.
Why?
mksh’s tes
I actually have a use case: injecting packages from
/var/cache/pbuilder/base.cow-somedist/repo/ into APT
from an optional cowbuilder hook script that I can
enable (chmod +x) when needed.
The hook script has the interesting constraint that
it adds a repository to APT with*out* running apt-get
updat
On Jul 28, Bernd Zeimetz wrote:
> So I think the best thing to do is to get sha256 working in git and
> force the usage of sha256 if you want to sign a tag for upload.
This cannot be a goal for this project since git upstream will need
apparently a few more years for the transition to sha-256 to
On Jul 28, Mo Zhou wrote:
> 2. Specifically compile a libopenblas64_.so
>from src:openblas for julia's use.
>This looks very bad for src:openblas's
>package layout.
Why would this look bad? We have plenty of source packages which
generate multiple variations of binary packages.
udebs
On Wed, Jul 24, 2019 at 06:03:21PM +0200, Steffen Möller wrote:
> Hello,
>
> We just had SuSE embracing LTO
> (https://www.linuxtoday.com/infrastructure/opensuse-enables-lto-by-default-for-tumbleweed-smaller-faster-binaries.html).
> I am not sure about the progress on issues summarised in
> http:/
On Sun, Jul 28, 2019 at 10:33 PM Johannes Schauer wrote:
> If we choose the "src:" prefix to pick source instead of binary packages, then
> it's important that we don't have any binary packages called "src" and no
> source packages with a name equal to a valid debian architecture.
Could we have a
On Sun, Jul 28, 2019 at 10:04 PM Mo Zhou wrote:
> Is such demand common enough among developers?
There are several ways this would be useful:
To replace all librust-*-dev and golang-*-dev packages (they contain
source code).
To replace all toolchain -source packages, so that cross-compiling
too
On 7/27/19 8:16 PM, Rebecca N. Palmer wrote:> As a way to avoid relying
on SHA-1, would it work to have git-debpush
> include a longer hash in the tag message, and tag2upload also verify
> that hash?
>
The other idea would be to convince git upstream to use something
better than sha1 - and after
On 28/07/2019 20:01, Sean Whitton wrote:
When I read your first e-mail what I thought you had in mind was just
this -- having git-debpush compute a stronger hash of the tree object
and add that to the tag metadata, ignoring commit objects.
Of the files in the signer's repository, not of an actu
Hello,
On Sun 28 Jul 2019 at 07:05pm +01, Rebecca N. Palmer wrote:
> On 28/07/2019 16:18, Ian Jackson wrote:
>> What it amounts to is a parallel Merkle tree to the
>> git one, just with a different data format and a better hash.
>
> Not really: it wouldn't need the history tree structure (in Git
Am 26.07.19 um 20:02 schrieb Andrey Rahmatullin:
> On Fri, Jul 26, 2019 at 01:26:52PM -0400, PICCORO McKAY Lenz wrote:
>> the https://packages.debian.org/search?keywords=libmyodbc show only
>> for sid and oldstable.. so what will happened.. users now must
>> compiled own mysql odbc?
> It's in sid,
On 28/07/2019 16:18, Ian Jackson wrote:
What it amounts to is a parallel Merkle tree to the
git one, just with a different data format and a better hash.
Not really: it wouldn't need the history tree structure (in Git terms
[0], it would be a tree object not a commit object), and if we use
ta
Mo Zhou 于 2019年7月28日周日 16:03写道：
> On 2019-07-28 13:13, Ian Jackson wrote:
> > This is maybe not directly helpful to you right now, but:
> >
> > If we could build-depend on source packages, you could combine these
> > two ideas into something that might be less awful.
>
> More than once have I tho
Philipp Kern wrote...
> On 2019-07-27 10:01, Vincent Bernat wrote:
> > I am upstream for a project using seccomp since a long time and I have
> > never been comfortable to enable it in Debian for this reason. However,
> > they enable it in Gentoo and I get the occasional patches to update the
> >
On 28/07/2019 10:58, Bernd Zeimetz wrote:
On 7/27/19 8:16 PM, Rebecca N. Palmer wrote:
As a way to avoid relying on SHA-1, would it work to have git-debpush
include a longer hash in the tag message, and tag2upload also verify
that hash?
what exactly would you create that long hash of?
The si
Rebecca N. Palmer writes ("Re: tag2upload (git-debpush) service architecture -
draft"):
> The signer's local files when they run git-debpush. (To be decided: how
> to define the hash of a directory tree (as opposed to a single file),
> i.e. "tar | sha256 like a .dsc" or "what git uses but sha25
Hi,
Quoting Mo Zhou (2019-07-28 16:03:43)
> On 2019-07-28 13:13, Ian Jackson wrote:
> > This is maybe not directly helpful to you right now, but:
> >
> > If we could build-depend on source packages, you could combine these
> > two ideas into something that might be less awful.
> More than once ha
On Sun, Jul 28, 2019 at 07:03:43AM -0700, Mo Zhou wrote:
> > This is maybe not directly helpful to you right now, but:
> >
> > If we could build-depend on source packages, you could combine these
> > two ideas into something that might be less awful.
>
> More than once have I thought of "what if
On 2019-07-28 13:13, Ian Jackson wrote:
> This is maybe not directly helpful to you right now, but:
>
> If we could build-depend on source packages, you could combine these
> two ideas into something that might be less awful.
More than once have I thought of "what if I can B-D on a source
package
Hi Phil,
On 2019-07-28 10:14, Phil Morrell wrote:
> Without knowing anything more than what you've written here (which I
> didn't find too long), it sounds like maintenance burden is the concern.
The situation forces we Julia package maintainers to decide whether
to use such a non-standard openbl
Steffen Möller writes ("And in 2019? Re: -flto to become more of a routine -
any change in opinion since 2011?"):
> We just had SuSE embracing LTO
> (https://www.linuxtoday.com/infrastructure/opensuse-enables-lto-by-default-for-tumbleweed-smaller-faster-binaries.html).
> I am not sure about the pr
On 2019, ജൂലൈ 28 6:36:21 PM IST, Phil Morrell wrote:
>On Tue, Jan 01, 2019 at 05:49:37PM +0530, Pirate Praveen wrote:
>> I think STS (Short term support) will fit nicely with LTS. If there
>is
>> no serious objections, I'd go with this.
>
>As debconf is finishing, though I don't know if either
Mo Zhou writes ("Challenge from Julia's non-standard vendored openblas"64_""):
> [stuff]
How awkward.
> 2. Specifically compile a libopenblas64_.so
>from src:openblas for julia's use.
...
> 3. Embed openblas source and let Julia's
This is maybe not directly helpful to you right now, but:
If
Marc Haber writes ("Re: do packages depend on lexical order or
{daily,weekly,monthly} cron jobs?"):
> On Sat, 27 Jul 2019 19:02:16 +0100, Ian Jackson
> >I worry about additional concurrency. Unlike ordering bugs,
> >concurrency bugs are hard to find by testing. So running these
> >scripts in par
On Tue, Jan 01, 2019 at 05:49:37PM +0530, Pirate Praveen wrote:
> I think STS (Short term support) will fit nicely with LTS. If there is
> no serious objections, I'd go with this.
As debconf is finishing, though I don't know if either of you attended
this year, has there been any progress on this
❦ 28 juillet 2019 12:11 +02, Philipp Kern :
>> Just a quick note: seccomp filters may need adaptations from one libc
>> to another (and from one kernel to another as the libc may adapt to
>> the current kernel). For example, with the introduction of "openat"
>> syscall, the libc has started to us
(debian-devel following Holger's advice, guessing all authors are subscribed)
On Thu, Jul 25, 2019 at 10:43:12PM -0300, Yao Wei (魏銘廷) wrote:
> What if, one of the upstream authors consider it violating GPL _without_ the
> clause? I mean, it could happen.
Indeed, and I'd argue this is already t
On 2019-07-27 10:01, Vincent Bernat wrote:
Just a quick note: seccomp filters may need adaptations from one libc
to
another (and from one kernel to another as the libc may adapt to the
current kernel). For example, with the introduction of "openat"
syscall,
the libc has started to use it for "
On Sun, Jul 28, 2019 at 02:30:15AM -0700, Mo Zhou wrote:
> problem is that the 64-bit indexing variant doesn't
> have a standard SONAME.
Without knowing anything more than what you've written here (which I
didn't find too long), it sounds like maintenance burden is the concern.
Am I right in think
On 7/27/19 8:16 PM, Rebecca N. Palmer wrote:
> As a way to avoid relying on SHA-1, would it work to have git-debpush
> include a longer hash in the tag message, and tag2upload also verify
> that hash?
what exactly would you create that long hash of?
If we don't trust sha-1, then we might also not
On 7/28/19 8:47 AM, Marc Haber wrote:
> Setting RandomizeDelaySecs sufficiently high on our daily jobs would
> probably help to chop off the load pike that especially virtualization
> setups running many Debian instances suffer from at 06:25 or 07:35. I
> think this could be a net gain worth pur
Hi developers,
A long existing historical problem that stems from
Fortran finally started to bite people.
--- Background
BLAS/LAPACK is a set of very stable API/ABIs for
dense numerical linear algebra, of "libc-level"
importance to scientific computing users. The
standard/reference/low-performan
37 matches
Mail list logo
