On Fri, Sep 9, 2016 at 3:39 PM, Emmanuel Bourg wrote:
> "For packages in the main archive, no build step may attempt network
> access in a way that:
> - leaks sensitive data
> - changes the build result or the operations performed to produce it"
>
> (with the build result defined as the binary pac
While the Debian Release team has some citation about the quality of the
toolchain on their status page, it is not one of the release criteria documented
by the release team. I'd like to document the status how I do understand it for
some of the toolchains available in Debian.
I appreciate that t
Package: wnpp
Severity: wishlist
Owner: Wookey
Package name: ne10
Version : 1.2.1
Upstream Author : ARM Limited and Contributors
URL : http://projectne10.github.io/Ne10/doc/index.html
License : BSD
Programming Lang: C, assembler
Description : ARM
Hi,
thanks for the work on this. I'd like to defer the final decision to the
release team, however I'm not keen on having these defaults turned on
architectures which already have enough issues on their own. In the recent
porters call people claim that turning on these "should not be a problem"
Adam Borowski writes:
> As there's no way to distinguish such details automatically, and as
> data/privacy leaks can be quite surprising, I'd strongly prefer the
> nice, simple rule of "no attempt to access outside network, period".
> If _some_ network accesses are allowed, we can't easily spot
Vincent Lefevre writes:
> On 2016-09-08 08:44:54 -0700, Russ Allbery wrote:
>> That's a little better but not a lot better. It means that it's still
>> unsafe to run any script out of a world-writeable directory such as
>> /tmp, even if the sticky bit is set.
> Running things in /tmp or its sub
On Fri, 09 Sep 2016 at 18:11:05 +0200, Markus Koschany wrote:
> On 08.09.2016 21:54, Ralf Treinen wrote:
> > That is certainly not true for orphaned packages with minimal maintenance
> > by the QA team. At least when I do a QA upload I usually don't bump the
> > Standards-Version field, simply bec
* Marcin Kulisz , 2016-09-09, 13:08:
I have a package (libpqxx) where I was using my own repack script for
quite a long time.
Now I want to upload new (Debian) version of it with existing (in the
archive) upstream version but fixing some issues including
reproducibility, etc. and using **File
On Fri, Sep 09, 2016 at 02:33:51PM +0200, Rene Engelhard wrote:
> On Fri, Sep 09, 2016 at 12:17:49PM +, Mattia Rizzolo wrote:
> > Actually you don't, there are ways to do that without, but that's ugly.
> > Please bump the version (usually I add a '1' in the +dfsg (a là +dfsg1)
> ^^
On 08.09.2016 21:54, Ralf Treinen wrote:
> On Thu, Sep 08, 2016 at 05:28:18PM +0200, Markus Koschany wrote:
>> On 08.09.2016 14:30, Ian Jackson wrote:
>>> Emmanuel Bourg writes ("Re: Network access during build"):
That makes sense, but in this case what is the usefulness of the
Standards-
* Guus Sliepen , 2016-09-09, 16:19:
AFAIK, at the moment it's only the buildds that block network access.
Do they? [citation needed]
--
Jakub Wilk
Guus Sliepen writes ("Re: Network access during build"):
> But should this perhaps also be enforced in our build tools? Ie, have
> dpkg-buildpackage set up an empty namespace before executing
> debian/rules? AFAIK, at the moment it's only the buildds that block
> network access. A malicious upstrea
On Fri, Sep 09, 2016 at 03:57:42PM +0200, Adam Borowski wrote:
> > "For packages in the main archive, no build step may attempt network
> > access in a way that:
> > - leaks sensitive data
> > - changes the build result or the operations performed to produce it"
>
> As there's no way to distingui
On Friday, September 09, 2016 03:57:42 PM Adam Borowski wrote:
> On Fri, Sep 09, 2016 at 09:39:09AM +0200, Emmanuel Bourg wrote:
> > Le 9/09/2016 à 01:13, Henrique de Moraes Holschuh a écrit :
> > > "must not change build behavior or build result depending on network
> > > availability" is also nee
Hi,
First of all thanks to Lucas Nussbaum who ran the first test build!
2016-08-31 19:21 GMT+02:00 Steve Langasek :
> On Wed, Aug 31, 2016 at 11:26:55AM +0100, Dimitri John Ledkov wrote:
>> Hello,
>> > Results are available at
>> > https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-2016
On Fri, Sep 09, 2016 at 09:39:09AM +0200, Emmanuel Bourg wrote:
> Le 9/09/2016 à 01:13, Henrique de Moraes Holschuh a écrit :
>
> > "must not change build behavior or build result depending on network
> > availability" is also needed somewhere, if it is not already in there.
>
> If some tests are
>>> Is anybody else interested in helping? Thoughts/comments?
>>
>>Sorry to bump an old thread
>>
>>Please consider moving to Clang 3.8 or 4.0 as the LLVM front end for
>>the platform.
>>
>>Clang 3.5 and 3.6 are no longer maintained. The bugs we are
>>discovering and reporting are being closed
On 2016-09-09 12:17:49, Mattia Rizzolo wrote:
> On Fri, Sep 09, 2016 at 03:13:07PM +0300, Lars Wirzenius wrote:
> > On Fri, Sep 09, 2016 at 01:08:08PM +0100, Marcin Kulisz wrote:
> > > Unfortunately there is difference in size for *.orig.tar.gz between
> > > what's in
> > > the archive and what's
On Fri, Sep 09, 2016 at 12:17:49PM +, Mattia Rizzolo wrote:
> Actually you don't, there are ways to do that without, but that's ugly.
> Please bump the version (usually I add a '1' in the +dfsg (a là +dfsg1)
> in similar cases).
That *IS* a new version :).
Regards,
On Fri, Sep 09, 2016 at 03:13:07PM +0300, Lars Wirzenius wrote:
> On Fri, Sep 09, 2016 at 01:08:08PM +0100, Marcin Kulisz wrote:
> > Unfortunately there is difference in size for *.orig.tar.gz between what's
> > in
> > the archive and what's updated package produces thus upload fails.
> >
> > I'm
On 2016-09-08 08:44:54 -0700, Russ Allbery wrote:
> That's a little better but not a lot better. It means that it's still
> unsafe to run any script out of a world-writeable directory such as /tmp,
> even if the sticky bit is set.
Running things in /tmp or its subdirectories is prone to security
Package: wnpp
Severity: wishlist
Owner: Ilias Tsitsimpis
* Package name: python-udatetime
Version : 0.0.9
Upstream Author : Simon Pirschel
* URL : https://pypi.python.org/pypi/udatetime
* License : Apache 2.0
Programming Lang: C, Python
Description : F
On Fri, Sep 09, 2016 at 01:08:08PM +0100, Marcin Kulisz wrote:
> Unfortunately there is difference in size for *.orig.tar.gz between what's in
> the archive and what's updated package produces thus upload fails.
>
> I'm not sure why this difference occurs (it's 27 bytes).
>
> Any ideas how can I
Hi all,
I have a package (libpqxx) where I was using my own repack script for quite a
long time.
Now I want to upload new (Debian) version of it with existing (in the archive)
upstream version but fixing some issues including reproducibility, etc. and
using **File-Excluded** instead my repack scr
Emmanuel Bourg writes ("Re: Standards-Version field should be deprecated"):
> Le 8/09/2016 à 17:39, Russ Allbery a écrit :
> > If you're just automatically updating it without ever looking at how
> > Policy has changed, then yes, it's not useful. And I don't think it's
> > very useful to publish.
On Fri, Sep 09, 2016 at 01:10:52PM +0200, Dominique Dumont wrote:
> On Thursday, September 8, 2016 8:39:01 AM CEST Russ Allbery wrote:
> > If Lintian says that the Standards-Version field is out of date, I then
> > open /usr/share/doc/debian-policy/upgrading-checklist.txt.gz, scroll down
> > to the
On Thursday, September 8, 2016 8:39:01 AM CEST Russ Allbery wrote:
> If Lintian says that the Standards-Version field is out of date, I then
> open /usr/share/doc/debian-policy/upgrading-checklist.txt.gz, scroll down
> to the current value of Standards-Version, and then read backwards to the
> top,
Le 8/09/2016 à 17:39, Russ Allbery a écrit :
> If you're just automatically updating it without ever looking at how
> Policy has changed, then yes, it's not useful. And I don't think it's
> very useful to publish.
That's indeed what happens most of the time. The set of packages
maintained by the
Le 9/09/2016 à 01:13, Henrique de Moraes Holschuh a écrit :
> "must not change build behavior or build result depending on network
> availability" is also needed somewhere, if it is not already in there.
If some tests are automatically disabled when the network isn't
available one could argue tha
29 matches
Mail list logo
