On Thu, 2014-10-30 at 01:40 -0400, Michael Gilbert wrote:
> There are also end-of-life announcements, which maybe the
> debian-security-support package now addresses in a somewhat automated
> fashion.
I wasn't aware of that. Thanks.
> Anyway, it is entirely understandable that reading can be har
On Thu, Oct 30, 2014 at 1:12 AM, Russell Stuart wrote:
> On Wed, 2014-10-29 at 21:58 -0700, Russ Allbery wrote:
>> Also, this means that you completely miss security advisories that *don't*
>> involve changing a package in the archive, like "this thing is a disaster,
>> so we're pulling it from the
On Thu, Oct 30, 2014 at 12:09 AM, Christoph Anton Mitterer wrote:
> On Wed, 2014-10-29 at 19:39 -0700, Russ Allbery wrote:
>> Packages appearing on mirrors is not how we notify Debian users of
>> security updates. We do that by issuing a security advisory.
> Aha,... well... sounds like nitpicking,
Russell Stuart writes:
> If it is so that much of a disaster that it warrants pulling a package
> from stable, surely a little more notification than an email to a list
> most people don't monitor would be warranted?
See, for example, DSA-2819. Or, on a different front, DSA-2907, which was
rath
On Wed, 2014-10-29 at 21:58 -0700, Russ Allbery wrote:
> Also, this means that you completely miss security advisories that *don't*
> involve changing a package in the archive, like "this thing is a disaster,
> so we're pulling it from the archive entirely and suggest you stop using
> it."
If it i
Christoph Anton Mitterer writes:
> Even apart from the above problems, I doubt that mail is the appropriate
> mean for many admins to get notified about security upgrades.
If you don't read the mail, you're going to miss some really vital
information, like packages that we are no longer supporti
Russell Stuart writes:
> If there are two "ways" and one requires a human and the other is
> completely automatic, all other things being equal for me the "right"
> way is the automated one. I know my limitations - not being
> conscientious when doing manual repetitive labour is one of them.
Th
Hey Russ.
On Wed, 2014-10-29 at 19:39 -0700, Russ Allbery wrote:
> Packages appearing on mirrors is not how we notify Debian users of
> security updates. We do that by issuing a security advisory.
Aha,... well... sounds like nitpicking,... I guess the least of the
users have subscribed the respe
On Wed, 2014-10-29 at 19:39 -0700, Russ Allbery wrote:
> But we shouldn't confuse that with the right way to check
> for security updates for Debian systems. People who
> care about security updates need to be subscribed to
> debian-security-announce and reading the DSAs.
If there are two "ways"
Le Wed, Oct 29, 2014 at 04:09:03PM -0500, Jose-Luis Rivas a écrit :
> On 29/10/14, 07:44pm, Thorsten Glaser wrote:
> >
> > This is a dangerous habit to get into – I’d prefer users of even
> > dgit, no matter how good it may be, to not rely on that. This is
> > a social issue, not a technical one.
On Wed, Oct 29, 2014 at 05:02:11PM +0100, Jonas Smedegaard wrote:
> Quoting Russ Allbery (2014-10-28 17:20:02) at debian-vote@l.d.o
> > For the compiler, all of Debian is built with GCC, but some teams do
> > test builds with Clang and report bugs, which most maintainers merge
> > and some don't.
Christoph Anton Mitterer writes:
> Anyway this should demonstrate quite practical, how fast attackers are
> these days and that severely reducing the validity times doesn't just
> help against some completely unreal attack vectors.
> Even if the security team is as fast as above, then a victim m
On Wed, 29 Oct 2014, Jonas Smedegaard wrote:
> Speaking of which: Is it Policy or just habit to use GCC over Clang?
gcc still generates better machine code than clang in the *general* case for
C source (I don't know about the rest). There is no policy to use gcc: if
your program builds better usi
Hi,
> Marco d'Itri:
>> On Oct 27, Tobias Frost wrote:
>>
> Ok, so you are for removing audio group from user default groups?
Eventually, yes.
>>> Did you mean "maybe" or "for sure, someone"
>
> s/someone/sometime/
>
>> No.
>>
> Then what *did* you mean?
Well, probably the correct Engl
Package: wnpp
Severity: wishlist
Owner: Christian Kastner
* Package name: librscode
Version : 1.3
Upstream Author : Henry Minsky
* URL : http://rscode.sourceforge.net
* License : GPL-3+
Programming Lang: C
Description : library implementing a Reed-Solo
Package: wnpp
Severity: wishlist
Owner: Christian Kastner
* Package name: python-cachetools
Version : 0.6.0
Upstream Author : Thomas Kremmer
* URL : https://github.com/tkem/cachetools
* License : Expat
Programming Lang: Python
Description : extensible m
Hey Henrique, et al.
I've had lost my interest a bit, since it feels like fighting
windmills... but one month has passed and it's perhaps a good time to
revisit this.
On Mon, 2014-09-29 at 08:08 -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 29 Sep 2014, Christoph Anton Mitterer wrote:
> >
On 29/10/14, 07:44pm, Thorsten Glaser wrote:
> Ian Jackson dixit:
>
> [ NMU ]
> >A dgit user should be able to do this without reading the debdiff:
>
> This is a dangerous habit to get into – I’d prefer users of even
> dgit, no matter how good it may be, to not rely on that. This is
> a social is
Ian Jackson dixit:
[ NMU ]
>A dgit user should be able to do this without reading the debdiff:
This is a dangerous habit to get into – I’d prefer users of even
dgit, no matter how good it may be, to not rely on that. This is
a social issue, not a technical one.
bye,
//mirabilos
--
„Cool, /usr/s
On Wed, Oct 29, 2014 at 5:48 PM, Scott Kitterman wrote:
> On Wednesday, October 29, 2014 17:44:11 Cyril Brulebois wrote:
>> Scott Kitterman (2014-10-29):
>> > Would another option be to use "built-using" the doxygen version in
>> > question. Since effectively this is embedded code from the doxyg
Hi,
Jonas Smedegaard:
> Speaking of which: Is it Policy or just habit to use GCC over Clang?
>
Well, when Debian was started, clang didn't even exist – also, for a
long time it wasn't compatible with quite a few GCCisms in our sources
and/or rules files.
--
-- Matthias Urlichs
--
To UNSUBSCR
On Wednesday, October 29, 2014 17:44:11 Cyril Brulebois wrote:
> Scott Kitterman (2014-10-29):
> > Would another option be to use "built-using" the doxygen version in
> > question. Since effectively this is embedded code from the doxygen
> > package if I understand it correctly. Using doxygen to
On 29/10/2014 17:02, Jonas Smedegaard wrote:
> Quoting Russ Allbery (2014-10-28 17:20:02) at debian-vote@l.d.o
>> For the compiler, all of Debian is built with GCC, but some teams do
>> test builds with Clang and report bugs, which most maintainers merge
>> and some don't.
>
> Speaking of which:
Scott Kitterman (2014-10-29):
> Would another option be to use "built-using" the doxygen version in
> question. Since effectively this is embedded code from the doxygen
> package if I understand it correctly. Using doxygen to regenerate
> things is the preferred form of modification and all the
On Wednesday, October 29, 2014 15:59:44 Jonas Smedegaard wrote:
> Quoting Gianfranco Costamagna (2014-10-29 15:18:30)
>
> > >For the source package I believe you should either...
>
> [...]
>
> > the documentation is usually regenerated into debian, not ship with
> > the source code
>
> Silly me
On Wed, 2014-10-29 at 17:02 +0100, Jonas Smedegaard wrote:
> doxygen (and a very few others) links against libclang1-3.5
> "where available" according to the changelog, ...
> libllvm3.5 is also used for another few, including mesa.
It's not so much a question whether these packages are compiled
On Wed, Oct 29, 2014 at 5:02 PM, Jonas Smedegaard wrote:
> Quoting Russ Allbery (2014-10-28 17:20:02) at debian-vote@l.d.o
>> For the compiler, all of Debian is built with GCC, but some teams do
>> test builds with Clang and report bugs, which most maintainers merge
>> and some don't.
>
> Speaking
Jonas Smedegaard writes:
> Quoting Russ Allbery (2014-10-28 17:20:02) at debian-vote@l.d.o
>> For the compiler, all of Debian is built with GCC, but some teams do
>> test builds with Clang and report bugs, which most maintainers merge
>> and some don't.
> Speaking of which: Is it Policy or just
Quoting Russ Allbery (2014-10-28 17:20:02) at debian-vote@l.d.o
> For the compiler, all of Debian is built with GCC, but some teams do
> test builds with Clang and report bugs, which most maintainers merge
> and some don't.
Speaking of which: Is it Policy or just habit to use GCC over Clang?
I
On Oct 29, 2014, at 01:47 PM, Ian Jackson wrote:
>I got the impression that sbuild is winning over pbuilder BICBW.
Especially now that bug #607228 has been fixed!
Cheers,
-Barry
signature.asc
Description: PGP signature
Hi,
On Wed, Oct 29, 2014 at 11:54:41AM -0200, Antonio Terceiro wrote:
> On Wed, Oct 29, 2014 at 02:32:04PM +0100, Guido Günther wrote:
> > On Wed, Oct 29, 2014 at 12:06:59PM +, Ian Jackson wrote:
> > > Dimitri John Ledkov writes ("Re: dgit and git-dpm (was Re:
> > > Standardizing the layout o
Hi Paul,
>This is the place in which I remind people javascript-common with
>multiple versions of jQuery would reduce maintainer burden and avoid
>filling the archive with tons of binaries if someone has a spare few hours.
this can fix the problem about symlinking a javascript version that gets
>IMO the proper solution is for Debian packaging of doxygen to untangle
>jQuery from extensions, depend on + symlink the jQuery part, provide the
>extensions as a shared package, and patch doxygen code to generate
>docuementation referencing each separately instead of the entangled one.
>...b
Package: wnpp
Severity: wishlist
Owner: Benjamin Drung
* Package name: pyapi-gitlab
Version : 6.2.3
Upstream Author : Itxaka Serrano Garcia
* URL : https://github.com/Itxaka/pyapi-gitlab
* License : GPL-3
Programming Lang: Python
Description : Python w
On Wed, Oct 29, 2014 at 03:59:44PM +0100, Jonas Smedegaard wrote:
> IMO the proper solution is for Debian packaging of doxygen to untangle
> jQuery from extensions, depend on + symlink the jQuery part, provide the
> extensions as a shared package, and patch doxygen code to generate
> docuementat
Quoting Gianfranco Costamagna (2014-10-29 15:18:30)
> >For the source package I believe you should either...
[...]
> the documentation is usually regenerated into debian, not ship with
> the source code
Silly me, you are right, off course.
>>For the [binary] package I believe you should either.
Dear Jonas,
>For the source package I believe you should either...
>a) ensure that the code is truly the code that it claims to be
>(filename "jquery-1.2.3" quite arguably is not adequate ensurance
>that it contains unaltered version 1.2.3 of jQuery).
>This can be difficult to ensure
Hi Gianfranco,
Quoting Gianfranco Costamagna (2014-10-29 13:41:30)
> I'm stuck with this jquery problem, and I don't know the best solution
> for it.
>
> Doxygen creates and embeds a patched jquery version (why they don't
> extend jquery in another file or rename it to avoid clashes is obscure
On Wed, Oct 29, 2014 at 02:32:04PM +0100, Guido Günther wrote:
> On Wed, Oct 29, 2014 at 12:06:59PM +, Ian Jackson wrote:
> > Dimitri John Ledkov writes ("Re: dgit and git-dpm (was Re: Standardizing
> > the layout of git packaging repositories)"):
> > > dpkg-source removes it, by default, for
Guido Günther writes ("Re: dgit and git-dpm (was Re: Standardizing the layout
of git packaging repositories)"):
> I do wonder if we should switch to using git-pbuilder by default and
> rather offer to invoke 'git-pbuilder create' in case we don't find a
> proper base.cow for it.
I got the impress
Simon McVittie writes ("Re: dgit and git-dpm (was Re: Standardizing the layout
of git packaging repositories)"):
> On 29/10/14 12:08, Ian Jackson wrote:
> > The contents of the default ignore
> > list is in dpkg-source, but it is not enabled unless the caller says
> > -I. git-buildpackage passes
On Wed, Oct 29, 2014 at 12:06:59PM +, Ian Jackson wrote:
> Dimitri John Ledkov writes ("Re: dgit and git-dpm (was Re: Standardizing the
> layout of git packaging repositories)"):
> > dpkg-source removes it, by default, for 3.0 based formats as it's part
> > of the default ignore list.
> > (or
Thorsten Glaser writes ("Re: dgit and git-dpm"):
> On Wed, 29 Oct 2014, Ian Jackson wrote:
> > maintainers of other tools. It does seem to me to imply that using
> > git-buildpackage to do an NMU is risky, because:
>
> Yes, it is – anything other than the standard Debian tool
> (dpkg-buildpackage
On 29/10/14 12:08, Ian Jackson wrote:
> The contents of the default ignore
> list is in dpkg-source, but it is not enabled unless the caller says
> -I. git-buildpackage passes -I.
To be completely clear (because I misread it twice in a row), you mean
that it is not enabled unless the caller uses
On Wed, 29 Oct 2014, Ian Jackson wrote:
> maintainers of other tools. It does seem to me to imply that using
> git-buildpackage to do an NMU is risky, because:
Yes, it is – anything other than the standard Debian tool
(dpkg-buildpackage) is.
> If some user of git-buildpackage (without dgit) tri
Hi dear Debian Developers and Maintainers,
I'm stuck with this jquery problem, and I don't know the best solution for it.
Doxygen creates and embeds a patched jquery version (why they don't extend
jquery in another file or rename it to avoid clashes is obscure to me), then
symlink can result i
[resending because my MUA failed to mangle the headers]
Dimitri John Ledkov writes ("Re: dgit and git-dpm (was Re: Standardizing the
layout of git packaging repositories)"):
> dpkg-source removes it, by default, for 3.0 based formats as it's part
> of the default ignore list.
> (or rather ignores
On 10/29/2014 12:54 AM, Steve McIntyre wrote:
> On Wed, Oct 22, 2014 at 03:58:04PM +0200, Juerg Haefliger wrote:
>> Hi,
>>
>> On Sat, Jul 19, 2014 at 10:12 AM, Thomas Goirand wrote:
>>>
>>> On 07/18/2014 07:49 PM, Steve McIntyre wrote:
> [2] I contacted Steve McIntyre privately about it, but h
On 29 October 2014 05:39, Guido Günther wrote:
> On Tue, Oct 28, 2014 at 07:17:49PM +, Ian Jackson wrote:
>> Brian May writes ("Re: Standardizing the layout of git packaging
>> repositories"):
>> > However, with git-dpm, no branch is ever destroyed. Every branch is always
>> > merged into the
Postovani,
ovim putem zelimo da Vam ponudimo asortiman zimskih guma putem nase
veleprodaje - zastupnici smo za SAVU, DUNLOP, GY i mogucnost ugradnje
istih u nasem servisu.
Servis se nalazi u ulici Jovanke Radakovic 25i ( od Bogoslovije ka
Mirijevu na samom glavnom putu).
Uz ponudu pneumatika za
50 matches
Mail list logo
