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
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
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,
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
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.
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
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
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 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
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 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 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
>>> 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 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
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 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
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
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
* 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
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-
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)
> ^^
* 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, 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
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
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
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"
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
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
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
29 matches
Mail list logo
