Good day, Felix-
First, thank you for maintaining reiser4progs for Debian alive.
I wanted to suggest if you are willing to backport reiser4progs
1.0.1.0-x.y for the upcoming 'Jessie and a half ' release?
< https://lists.debian.org/debian-boot/2016/07/msg00037.html >
Although I have built reiser4
The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.
Total number of orphaned packages: 909 (new: 29)
Total number of packages offered up for adoption: 167 (new: 2)
Total number of packages reques
On Thu, 08 Sep 2016, Russ Allbery wrote:
> gregor herrmann writes:
> > IIRC (I didn't re-read the whole bug log now) the intention in
> > #770016 was indeed more than "not affect the build result" but
> > "explicitly forbid any attempt to access the network because leak".
>
> > As a result policy
Hello,
On Thu, Sep 08, 2016 at 08:39:01AM -0700, 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
> t
gregor herrmann writes:
> IIRC (I didn't re-read the whole bug log now) the intention in
> #770016 was indeed more than "not affect the build result" but
> "explicitly forbid any attempt to access the network because leak".
> As a result policy 4.9. now says:
> For packages in the main arc
On Wed, 07 Sep 2016 08:41:19 +0200, Christoph Biedl wrote:
> > One of the package that I maintain (python-asyncssh) makes a DNS request
> > during build and expects it to fail. Since Policy 4.9 forbids network
> > access (in a rather confusing wording "may not"), I got this serious
> > bug:
> > h
Package: wnpp
Severity: wishlist
Owner: Vincent Danjean
* Package name: khronos-opencl-clhpp
Version : 2.0.10
Upstream Author : The Khronos Group Inc.
* URL : https://github.com/KhronosGroup/OpenCL-CLHPP/releases
* License : adapted MIT
Programming Lang: C++
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-Version field? And more precisely, why is it
There is also the full set of DVDs for source code for Jessie - look on
cdimage.debian.org
http://cdimage.debian.org/debian-cd/8.5.0/source/iso-dvd/
10 DVDs
Hope this helps,
Andy C
On Thu, Sep 08, 2016 at 06:37:33PM +0200, Markus Koschany wrote:
>
> On 08.09.2016 17:39, Russ Allbery wrote:
> >
> > Markus Koschany writes:
> >
> > >
> > > I have written a macro to update the Standards-Version field
> > > because it
> > > is such a boring task. Declaring compliance with the
[Please CC me on replies.]
Steve McIntyre wrote:
> Josh Triplett wrote:
> >Ian Jackson wrote:
> >> Editing the Standards-Version field is surely a small task, compared
> >> to the work of checking the policy updates against the package.
> >
> >Not necessarily. You can check Policy once for the di
Josh Triplett writes ("Re: Standards-Version field should be deprecated"):
> Ian Jackson wrote:
> > Editing the Standards-Version field is surely a small task, compared
> > to the work of checking the policy updates against the package.
>
> Not necessarily. You can check Policy once for the diffe
On Thu, 08 Sep 2016 at 08:44:54 -0700, Russ Allbery wrote:
> I don't see any inherent reason why that
> should have to be the case (other than, of course, that this Python
> behavior is long-standing and lots of software depends on it
I suspect that Python scripts relying on their own directory be
On Thu, Sep 08, 2016 at 10:35:03AM +0200, Matthieu Caneill wrote:
> On Thu, Sep 08, 2016 at 04:22:58PM +0900, 우승훈 wrote:
> > I can download a lot of full source code of open source project
> > easily, however, in Debian case, I cannot find the full source code.
> > If is it possible, could you tell
On Thu, 08 Sep 2016, Moritz Mühlenhoff wrote:
> We could reduce the policy checklist to issues not covered/coverable by
> Lintian tests (which should be a rather small subset of overall policy
> changes).
Please don't. Feel free to annotate these, but don't remove them...
I would rather not depe
On Thu, Sep 08, 2016 at 10:35:03AM +0200, Matthieu Caneill wrote:
> On Thu, Sep 08, 2016 at 04:22:58PM +0900, 우승훈 wrote:
> > I can download a lot of full source code of open source project
> > easily, however, in Debian case, I cannot find the full source code.
> > If is it possible, could you tell
Josh Triplett schrieb:
> I do see value in documenting the version of Policy a package complies
> with. However, I can also imagine some approaches to eliminate the
> busywork.
We could reduce the policy checklist to issues not covered/coverable by
Lintian tests (which should be a rather small s
Josh Triplett wrote:
>Ian Jackson wrote:
>> Editing the Standards-Version field is surely a small task, compared
>> to the work of checking the policy updates against the package.
>
>Not necessarily. You can check Policy once for the differences
>introduced with a new version, determine quickly fr
Package: wnpp
Severity: wishlist
Owner: Emanuele Rocca
* Package name: prometheus-varnish-exporter
Version : 0.1.0+git20160622.2.a3e-1
Upstream Author : Jonne Nauha
* URL : https://github.com/jonnenauha/prometheus_varnish_exporter
* License : MIT
Programm
Ian Jackson wrote:
> Editing the Standards-Version field is surely a small task, compared
> to the work of checking the policy updates against the package.
Not necessarily. You can check Policy once for the differences
introduced with a new version, determine quickly from the nature of the
change
Markus Koschany writes ("Standards-Version field should be deprecated"):
> > The field is useful because it shows the most recent version of the
> > policy that the package has been checked against. It is useful to
> > occasionally update packages to the latest standards, and the
> > Standards-Ver
On 08.09.2016 17:39, Russ Allbery wrote:
> Markus Koschany writes:
>
>> I have written a macro to update the Standards-Version field because it
>> is such a boring task. Declaring compliance with the Policy over and
>> over again by updating this field and mentioning it in the d/changelog,
>> doe
Jakub Wilk writes ("Re: [Request] Is there any way to get the full source codes
of Debian?"):
> * Christoph Egger , 2016-09-08, 15:55:
> >>>(resending with less-mangled To field)
> >>
> >>It's actually still mangled, in a different way though.
> >>
> >>Was: "우승훈 , "@bendel.debian.org
> >>
>
Lars Wirzenius writes:
> On Thu, Sep 08, 2016 at 11:55:26AM +0100, Dimitri John Ledkov wrote:
>> Other languages do that too. E.g. python, Doesn't python have the same
>> concerns then too?
> Python doesn't put . in sys.path (the search path for imported
> modules). It puts the absolute path whe
Markus Koschany writes:
> I have written a macro to update the Standards-Version field because it
> is such a boring task. Declaring compliance with the Policy over and
> over again by updating this field and mentioning it in the d/changelog,
> doesn't strike me as being a useful task. There are
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-Version field? And more precisely, why is it considered an
>> error [1] to omit it?
>
> The field is useful because
2016-09-08 12:55 GMT+02:00 Dimitri John Ledkov :
> Hello,
>
> On 29 August 2016 at 14:39, Dominic Hargreaves wrote:
>> tl;dr: '.' is being removed from perl's @INC by default; some breakage
>> in apps expected.
>>
>> For some years[1], it's been known that perl's habit of including '.'
>> in its m
On Tue, Sep 06, 2016 at 11:27:49PM -0400, Jeffrey Walton wrote:
>> There's something I've been pondering for a while, along with some
>> other folks - it might be useful to do a "jessie and a half" release,
>> similarly to what we did in the etch days. That's *basically* just
>> like a normal jessi
On Tue, Sep 06, 2016 at 11:27:49PM -0400, Jeffrey Walton wrote:
> > There's something I've been pondering for a while, along with some
> > other folks - it might be useful to do a "jessie and a half" release,
> > similarly to what we did in the etch days. That's *basically* just
> > like a normal j
On Thu, 8 Sep 2016 15:55:20 +0200, Christoph Egger wrote:
> Andrew Shadura writes:
> > On 08/09/16 14:43, Ian Jackson wrote:
> >> (resending with less-mangled To field)
> >
> > It's actually still mangled, in a different way though.
> >
> > Was: "우승훈 , "@bendel.debian.org
> >
> > Now: =?utf
* Christoph Egger , 2016-09-08, 15:55:
(resending with less-mangled To field)
It's actually still mangled, in a different way though.
Was: "우승훈 ,"@bendel.debian.org
Now: =?utf-8?Q?=EC=9A=B0=EC=8A=B9=ED=9B=88
It is not? The ``Now`` part is proper, compliant encoding of header
lines
Andrew Shadura writes:
> On 08/09/16 14:43, Ian Jackson wrote:
>> (resending with less-mangled To field)
>
> It's actually still mangled, in a different way though.
>
> Was: "우승훈 , "@bendel.debian.org
>
> Now: =?utf-8?Q?=EC=9A=B0=EC=8A=B9=ED=9B=88
It is not? The ``Now`` part is proper, compliant
Package: wnpp
Severity: wishlist
Owner: Riku Voipio
* Package name: glshim
Version : 0.0.20160225
Upstream Author : Ryan Hileman
* URL : https://github.com/lunixbochs/glshim
* License : Expat
Programming Lang: C
Description : Shim that translates OpenG
(resending with less-mangled To field)
우승훈 writes ("[Request] Is there any way to get the full source codes of
Debian?"):
> I can download a lot of full source code of open source project easily,
> however, in Debian case, I cannot find the full source code.
Others have suggested apt-get, which
우승훈 writes ("[Request] Is there any way to get the full source codes of
Debian?"):
> I can download a lot of full source code of open source project easily,
> however, in Debian case, I cannot find the full source code.
Others have suggested apt-get, which is the conventional answer.
If you want
Emmanuel Bourg writes ("Re: Network access during build"):
> That makes sense, but in this case what is the usefulness of the
> Standards-Version field? And more precisely, why is it considered an
> error [1] to omit it?
The field is useful because it shows the most recent version of the
policy th
On Thu, Sep 08, 2016 at 02:04:21PM +0300, Lars Wirzenius wrote:
> On Thu, Sep 08, 2016 at 11:55:26AM +0100, Dimitri John Ledkov wrote:
> > On 29 August 2016 at 14:39, Dominic Hargreaves wrote:
> > > tl;dr: '.' is being removed from perl's @INC by default; some breakage
> > > in apps expected.
> >
On Thu, Sep 08, 2016 at 11:55:26AM +0100, Dimitri John Ledkov wrote:
> On 29 August 2016 at 14:39, Dominic Hargreaves wrote:
> > tl;dr: '.' is being removed from perl's @INC by default; some breakage
> > in apps expected.
> >
> > For some years[1], it's been known that perl's habit of including '.
Hello,
On 29 August 2016 at 14:39, Dominic Hargreaves wrote:
> tl;dr: '.' is being removed from perl's @INC by default; some breakage
> in apps expected.
>
> For some years[1], it's been known that perl's habit of including '.'
> in its module load path, (@INC) is potentially dangerous, since it
On Thu, Sep 08, 2016 at 11:19:47AM +0100, Ian Jackson wrote:
> Dominic Hargreaves writes ("Upcoming change to perl: current directory in
> @INC"):
> > tl;dr: '.' is being removed from perl's @INC by default; some breakage
> > in apps expected.
>
> I seem to have missed this. So, belatedly:
>
>
Ian Jackson writes ("Re: Upcoming change to perl: current directory in @INC"):
> And: is there a way I can make this change in an installation of
> jessie or earlier ? That would be useful for various testing
> purposes, and also might be appropriate in production systems where
> security is impor
Dominic Hargreaves writes ("Upcoming change to perl: current directory in
@INC"):
> tl;dr: '.' is being removed from perl's @INC by default; some breakage
> in apps expected.
I seem to have missed this. So, belatedly:
Hooray!
Thank you for taking care of our users' security. I'm pleased to se
On Thu, Sep 08, 2016 at 09:42:57AM +0200, Emmanuel Bourg wrote:
> That makes sense, but in this case what is the usefulness of the
> Standards-Version field? And more precisely, why is it considered an
> error [1] to omit it?
As far as I care, the only point of the field is to document which
polic
Am 2016-09-08 um 10:35 schrieb Matthieu Caneill:
>I don't know the best way to download all the source packages by once,
>but be aware it will take a lot of network traffic and disk space. Let
>me know your use-case and I'll see how I can help. :)
If you just like to get all sourcecodes for the p
Hi,
>I can download a lot of full source code of open source project easily,
>however, in Debian case, I cannot find the full source code.
>
>If is it possible, could you tell me how to get the full source codes of
>Debian? ( Especially jessie ver. )
You can use the debmirror com
Hi,
On Thu, Sep 08, 2016 at 04:22:58PM +0900, 우승훈 wrote:
> I can download a lot of full source code of open source project easily,
> however, in Debian case, I cannot find the full source code.
> If is it possible, could you tell me how to get the full source codes of
> Debian? ( Especially jess
Dear debian development department,
Hi, I'm Seunghoon Woo who is studying for master course in Korea.
My major is computer science, especially computer security.These days, I try to
research about security of may Open-Source-Softwares, such as Linux kernel,
freebsd, android etc..
I can download a
Le 7/09/2016 à 09:35, Lars Wirzenius a écrit :
> That's not how policy compliance actually works. All packages for a
> given Debian release must conform to the version of policy that was
> current when it was frozen for release. Otherwise we effectively have
> no policy, if every package gets to c
48 matches
Mail list logo
