On Mon, Jun 26, 2017 at 11:09:26PM +0200, Mattia Rizzolo wrote:
> On Mon, Jun 26, 2017 at 10:23:56PM +0200, Ralf Treinen wrote:
> > we currently have in sid 84 maintainer scripts not using strict mode.
> > That is, they neither start on "#!/bin/[ba]sh -e", nor do a "set -e".
> > The list is attache
On Tue, Jun 27, 2017 at 07:01:56AM +0200, Johannes Schauer wrote:
> Hi,
>
> Quoting Christoph Biedl (2017-06-27 00:37:33)
> > Let's be honest: Shell scripts, while easy to write, carry too many risks of
> > unsafe programming. So while your proposed fixing is a step in the right
> > direction, thi
On Tue, Jun 27, 2017 at 01:21:01PM +0800, Paul Wise wrote:
> On Tue, Jun 27, 2017 at 4:23 AM, Ralf Treinen wrote:
>
> > we currently have in sid 84 maintainer scripts not using strict mode.
> > That is, they neither start on "#!/bin/[ba]sh -e", nor do a "set -e".
> > The list is attached. This lis
Christoph Biedl:
> [...] Niels has mentioned declarative approaches which seem
> like a good idea. No idea about the status, though, and I'm interested
> in details if there already are some.
>
> Christoph
>
Hi,
Up till now, we deal with some easy wins by converting debhelper
maintscripts t
* Ben Hutchings:
> On Mon, 2017-06-26 at 08:34 +, Holger Levsen wrote:
>> On Sun, Jun 25, 2017 at 09:19:36AM -0300, Henrique de Moraes Holschuh wrote:
>> [...]
>> > Apparently, Intel had indeed found the issue, *documented it* (see
>> > below) and *fixed it*. There was no direct feedback to t
at bottom :-
On 26/06/2017, Steve McIntyre wrote:
> [ Note the cross-posting... ]
>
> Hey folks,
>
> Background: we released live images for Stretch using new tooling,
> namely live-wrapper. It is better than what we had before (live-build)
> in a number of ways, particularly in terms of build re
Hello, I saw your article on corrupted data and I have reason to believe
that the bad code goes as far back to Intel Pentium D processors, in my
investigation I have seen that when hyperthreading is disabled the cpu acts
ok no corrupted data or corrupted downloads however when enabled the
corrupted
Package: wnpp
Severity: wishlist
Owner: Markus Koschany
* Package name: libtwelvemonkeys-java
Version : 3.3.2
Upstream Author : Harald Kuhr
* URL : https://github.com/haraldk/TwelveMonkeys
* License : BSD-3-clause, ASL
Programming Lang: Java
Description
(updated perl script, it now needs the "liblist-moreutils-perl" package)
On Sun, 25 Jun 2017, Henrique de Moraes Holschuh wrote:
> On Sun, 25 Jun 2017, Henrique de Moraes Holschuh wrote:
> > This warning advisory is relevant for users of systems with the Intel
> > processors code-named "Skylake" a
And I'll add my 2¢ as an end user.
The live images exist IMHO to test compatibility before committing to
installation, and to install what was just tested and demonstrated,
regardless of environment. It's a nice feature (arguably an essential
feature) that the actual install mirror *exactly* the
Package: wnpp
Severity: wishlist
Owner: Mike Gabriel
* Package name: standardskriver
Version : 0.0.2
Upstream Author : Linnea Skogtvedt
Mike Gabriel
* URL :
https://code.it-zukunft-schule.de/cgit/standardskriver/about/
* License : GPL-2+
On Tue, 27 Jun 2017, Armin Avdic wrote:
> Hello, I saw your article on corrupted data and I have reason to believe
> that the bad code goes as far back to Intel Pentium D processors, in my
The Intel Pentium D is a very old processor, and its hyper-threading is
very different from the recent proces
Thanks, I'll check it out.
On 27 Jun 2017 16:32, "Henrique de Moraes Holschuh" wrote:
> On Tue, 27 Jun 2017, Armin Avdic wrote:
> > Hello, I saw your article on corrupted data and I have reason to believe
> > that the bad code goes as far back to Intel Pentium D processors, in my
>
> The Intel P
Ralf Treinen writes:
> On Mon, Jun 26, 2017 at 11:09:26PM +0200, Mattia Rizzolo wrote:
>> sigh.
>> And using `#!/bin(ba)?sh -e` is not good either (there is a lintian tag
>> about it, iirc).
> what is the rationale for this? Is anyone calling maintainer scripts
> like "sh
On Tue, Jun 27, 2017 at 09:03:16AM +0200, Ralf Treinen wrote:
> On Mon, Jun 26, 2017 at 11:09:26PM +0200, Mattia Rizzolo wrote:
> > On Mon, Jun 26, 2017 at 10:23:56PM +0200, Ralf Treinen wrote:
> > > we currently have in sid 84 maintainer scripts not using strict mode.
> > > That is, they neither s
I'd like to know why giving the world (Other) read access is even under
consideration. If user wants a file to have Other readability this
should be on the user to set it, but it should not be the default.
What is the justification that every user be able to read everyone
else's documents?
T
Hi everyone,
as we discussed before in IRC, we plan to eventually replace
our existing curl-based https method with our http method,
by adding TLS support to it. This will move HTTPS support
into apt proper, removing the apt-transport-https package.
I'm not sure how long this will take, I hope we
Hello,
On Mon, Jun 26, 2017 at 10:23:56PM +0200, Ralf Treinen wrote:
> we currently have in sid 84 maintainer scripts not using strict mode.
> That is, they neither start on "#!/bin/[ba]sh -e", nor do a "set -e".
Thanks to everybody for your feedback. I guess I will stick with
severity=normal fo
On Wed, Jun 28, 2017 at 2:00 AM, Julian Andres Klode wrote:
> Hi everyone,
>
> as we discussed before in IRC, we plan to eventually replace
> our existing curl-based https method with our http method,
> by adding TLS support to it. This will move HTTPS support
> into apt proper, removing the apt-t
Hello,
On Tue, Jun 27, 2017 at 09:37:01AM +0200, Florian Weimer wrote:
> > On Mon, 2017-06-26 at 08:34 +, Holger Levsen wrote:
> > Other procesors aren't bug-free, they just don't get as many bug fixes.
>
> And the fixes aren't documented publicly at all.
Similar to the time I was affected b
On 6/27/17 2:00 PM, Julian Andres Klode wrote:
> Hi everyone,
>
> as we discussed before in IRC, we plan to eventually replace
> our existing curl-based https method with our http method,
> by adding TLS support to it. This will move HTTPS support
> into apt proper, removing the apt-transport-https
On Wed, Jun 28, 2017 at 03:42:14AM +0800, Aron Xu wrote:
> On Wed, Jun 28, 2017 at 2:00 AM, Julian Andres Klode wrote:
> > Hi everyone,
> >
> > as we discussed before in IRC, we plan to eventually replace
> > our existing curl-based https method with our http method,
> > by adding TLS support to i
Charles, let me clear up a couple of misconceptions for you. Debian Live
(made with Live Wrapper) is an official Debian project. Live Build (the old
Debian Live) apparently wasn't official but was recognised by Debian for
its official images. Live Build is now officially part of Debian and Rafael
H
On Wed, Jun 28, 2017 at 1:11 AM, gwmfms6 wrote:
> I'd like to know why giving the world (Other) read access is even under
> consideration. If user wants a file to have Other readability this should be
> on the user to set it, but it should not be the default.
I expect for most Debian deployments
On Wed, Jun 28, 2017 at 2:00 AM, Julian Andres Klode wrote:
> Hi everyone,
>
> as we discussed before in IRC, we plan to eventually replace
> our existing curl-based https method with our http method,
> by adding TLS support to it. This will move HTTPS support
> into apt proper, removing the apt-t
Paul Wise writes:
> On Wed, Jun 28, 2017 at 1:11 AM, gwmfms6 wrote:
>> NOTE: this discussion is moot at the present time anyway because it is
>> impossible to set a UMASK at all on Debian Stretch. None of the usual ways
>> work within gnome on Debian Stretch. Can anyone comment on this fact?
>
>
On Wed, Jun 28, 2017 at 12:40:16PM +0800, YunQiang Su wrote:
> I'd guess you have to help process the bootstrap process.
> The TLS stuff is a quilt big trouble when bootstrap Debian for new
> architecture.
> So, I prefer the current schema, aka split https stuff to itself's
> source package.
It's
27 matches
Mail list logo
