Hi,
I am writing a systemd service file for a daemon (ntopng) and I would
like to know what you think is the best way to load some
configuration.
The ntopng daemon takes multiple interfaces in the format of multiple
-i command-line options. For example.
ntopng -i eth0 -i wlan0
Currently the inte
On 08/16/2014 07:59 PM, Raphael Hertzog wrote:
> Hi,
>
> On Fri, 15 Aug 2014, Guido Günther wrote:
>> The gbp manual has a recommended branch layout:
>>
>>
>> http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.BRANCH.NAMING
>>
>> which could serve as a basis. Ther
On 16 August 2014 17:36, Thomas Goirand wrote:
> On 08/16/2014 09:07 AM, Brian May wrote:
> > Note that there is a huge number of Python packages in Debian. It is
> > very possible that your favourite packages aren't available as Python3
> > Debian packages, either because upstream doesn't suppor
On 08/16/2014 04:18 PM, Raphael Hertzog wrote:
>>> - the above layout is for the traditional case of non-native packages,
>>> what would be the layout for native packages? how can be differentiate
>>> between native/non-native layout?
>>
>> I've never maintained a native package so I don't real
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: python-xstatic-rickshaw
Version : 1.5.0.0
Upstream Author : Radomir Dopieralski
* URL : https://github.com/stackforge/xstatic-rickshaw
* License : Expat
Programming Lang: Python
Descrip
On Sat, 16 Aug 2014 21:31:58 +0200
Raphael Hertzog wrote:
> Hi,
>
> On Sat, 16 Aug 2014, Philip Muskovac wrote:
> > I'm writing this from a Kubuntu POV which should be close to
> > debian-qt-kde as we have a pretty close workflow (one of the
> > reasons why we're talking about moving our branche
On Sat, 16 Aug 2014 14:03:18 +0200
Raphael Hertzog wrote:
> (Please trim the quoted mail when you answer)
>
> On Fri, 15 Aug 2014, Scott Kitterman wrote:
> > >- are there other important things to standardize?
> >
> > We don't even agree on if repositories should be full source or
> > Debian di
Derek Buitenhuis writes:
> On 8/16/2014 11:27 PM, wm4 wrote:
>> That is very valuable advice. We'll get to work right away.
> I've added it to my TODO:
> * Don't write bugs.
That's a really bad way of avoiding security bugs.
I'm sure you know that and are just being flippant, but I have to sa
wm4 writes:
> Russ Allbery wrote:
>> Note that all of the above statements also apply to libav. As near as I
>> can tell, this is not a distinguishing characteristic between the two
>> projects.
> And that's an argument against switching to FFmpeg exactly how?
It's not. Nor was I trying to m
On 8/16/2014 11:27 PM, wm4 wrote:
> That is very valuable advice. We'll get to work right away.
I've added it to my TODO:
* Don't write bugs.
- Derek
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Hi,
On 16.08.2014 17:49, Pau Garcia i Quiles wrote:
On Sat, Aug 16, 2014 at 5:30 PM, Nicolas George mailto:geo...@nsup.org>> wrote:
The only option is to make sure the users do not suffer from the
fork, by
making sure they can easily use the version that is most suited for
thei
On Sat, 16 Aug 2014 11:59:20 -0700
Russ Allbery wrote:
> The problem, however, is that taking security seriously, while possibly
> necessary, is not sufficient. I'm glad that FFmpeg takes security
> seriously, but what FFmpeg needs is to *have fewer security bugs*.
That is very valuable advice.
Ansgar Burchardt (2014-08-17):
> incoming.debian.org is used to publish recently uploaded source and
> binary packages before they reach the mirror network of the main
> archive. Until now, however, with the exception of the buildd network,
> it has not been possible to verify the integrity of the
m...@linux.it (Marco d'Itri) writes:
> And anyway I'd say that downloading the original archive is simpler than
> having to deal with pristine-tar...
I'm mystified. What is there to deal with? I literally never touch it.
It just works, completely transparently and silently.
--
Russ Allbery (
On Aug 16, Don Armstrong wrote:
> Because you're a Debian Developer and might want to upload a package to
> the archive without downloading the uploaded tarball which substantially
> duplicates what you have in your source tree? Or you're collaborating
> with someone and need to use a repacked ta
On Sat, 16 Aug 2014, Bernd Zeimetz wrote:
> On 08/16/2014 02:03 PM, Raphael Hertzog wrote:
> > I don't know of any git helper tools that work on git repositories with
> > Debian directory only.
>
> git-buildpackage --git-overlay
>
> works just fine since ~2009.
Thanks for the information.
> I'm
On 08/16/2014 02:03 PM, Raphael Hertzog wrote:
> I don't know of any git helper tools that work on git repositories with
> Debian directory only.
git-buildpackage --git-overlay
works just fine since ~2009.
I'm wondering if you actually ever investigated if there is a tool instead of
blindly assum
On 08/16/2014 03:53 AM, Henrique de Moraes Holschuh wrote:
> On Fri, 15 Aug 2014, Steve Langasek wrote:
>> The alternative is handwaving and ignoring the fact that your package
>> repository is not a complete representation of your package as it exists in
>> the archive.
>
> What's wrong with stor
On Sat, Aug 16, 2014 at 1:59 PM, Raphael Hertzog wrote:
> Hi,
>
> On Fri, 15 Aug 2014, Guido Günther wrote:
>> The gbp manual has a recommended branch layout:
>>
>>
>> http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.BRANCH.NAMING
>>
>> which could serve as a ba
Hi,
On Fri, 15 Aug 2014, Henrique de Moraes Holschuh wrote:
> > - the above layout is for the traditional case of non-native packages,
> > what would be the layout for native packages? how can be differentiate
> > between native/non-native layout?
>
> Please don't. It would be Really Trouble
Hi,
On Sat, 16 Aug 2014, Philip Muskovac wrote:
> I'm writing this from a Kubuntu POV which should be close to
> debian-qt-kde as we have a pretty close workflow (one of the reasons why
> we're talking about moving our branches to their repositories) as we
> also only keep the debian/ dir in the V
On 16/08/14 17:09, Raphael Hertzog wrote:
> On Fri, 15 Aug 2014, Simon McVittie wrote:
>> It is possible to use git-buildpackage with --git-export (either
>> explicitly, or configured in debian/gbp.conf) for packages that only
>> keep debian/ in git.
>
> Are you sure that --git-export is the right
Hi Thomas,
On Sat, 16 Aug 2014, Thomas Goirand wrote:
> > The goal here is to be able to host in the same repository the branches
> > for
> > multiple cooperating distributions (at least so that downstream can
> > clone the debian respository and inject their branches next to the
> > debi
Ivan Kalvachev writes:
> I'm quite sure the Security team is full of capable people who can
> handle one more package.
One, no, this statement is not correct. Not because the security team is
not capable -- they are very capable -- but because they are not *full*.
You imply that the security te
Hi Russ,
2014-08-16 18:59 GMT+02:00 Russ Allbery :
> Cyril Brulebois writes:
>> Russ Allbery (2014-08-16):
>
>>> None of this is why libav and FFmpeg can't both be in the archive.
>>> They can't both be in the archive because both the release team and
>>> the security team have said that they're
Hi Nicolas,
2014-08-16 17:11 GMT+02:00 Nicolas George :
> L'octidi 28 thermidor, an CCXXII, Bálint Réczey a écrit :
>> Using Gerrit and "file ownersip" are not mutually exclusive. Gerrit
>> can be configured to automatically invite the right people for review
>> based on the changed path. We recen
On 8/16/14, Pau Garcia i Quiles wrote:
> On Sat, Aug 16, 2014 at 5:30 PM, Nicolas George wrote:
>
>
>> The only option is to make sure the users do not suffer from the fork, by
>> making sure they can easily use the version that is most suited for their
>> need without being sucked into the devel
Am 16.08.2014 18:20, schrieb Russ Allbery:
> Thomas Goirand writes:
>> On 08/16/2014 07:05 AM, Jeremy Stanley wrote:
>
>>> However upstream may build tarballs through a (hopefully
>>> repeatable/automated) process at release time, publish checksums and
>>> signatures for them, et cetera and prefe
Cyril Brulebois writes:
> Russ Allbery (2014-08-16):
>> None of this is why libav and FFmpeg can't both be in the archive.
>> They can't both be in the archive because both the release team and
>> the security team have said that they're not interested in trying to
>> support both, due to the am
On Saturday 16 August 2014 17:09:54 Raphael Hertzog wrote:
> On Sat, 16 Aug 2014, Scott Kitterman wrote:
> > Silly or not in your opinion, the Qt-KDE team repositories are set up this
> > way.
>
> Sorry, I wasn't aware of that and didn't want to imply anything on people
> using such a scheme.
>
Hi Russ,
Russ Allbery (2014-08-16):
> None of this is why libav and FFmpeg can't both be in the archive.
> They can't both be in the archive because both the release team and
> the security team have said that they're not interested in trying to
> support both, due to the amount of work involved.
Pau Garcia i Quiles writes:
> If libav and ffmpeg maintainers cannot reach an agreement regarding
> library names and it's not possible to simply use either ffmpeg or libav
> indistinctly due missing features binary compatibility, etc, the obvious
> solution is that BOTH libav and ffmpeg rename t
Thomas Goirand writes:
> On 08/16/2014 07:05 AM, Jeremy Stanley wrote:
>> However upstream may build tarballs through a (hopefully
>> repeatable/automated) process at release time, publish checksums and
>> signatures for them, et cetera and prefer packagers use those as the
>> original tarballs f
Hi,
On Fri, 15 Aug 2014, Simon McVittie wrote:
> I've been hesitating on whether to ask this because it gets into
> questions of workflow and repo structure that are very much a matter of
> taste and don't have a single widely-declared-to-be-good answer, but I
> think one of the important question
On Sat, 16 Aug 2014 23:29:56 +0800
Thomas Goirand wrote:
> On 08/15/2014 11:53 PM, The Wanderer wrote:
> > It's also something the Linux kernel is still doing, with apparent
> > success.
>
> Yes, the Linux kernel is a successful project. Does this mean using a
> list for reviewing patches is a g
On Sat, Aug 16, 2014 at 5:30 PM, Nicolas George wrote:
> The only option is to make sure the users do not suffer from the fork, by
> making sure they can easily use the version that is most suited for their
> need without being sucked into the developers' disagreements.
>
Can we get back on top
Le septidi 27 thermidor, an CCXXII, Thomas Goirand a écrit :
> If you guys could find a solution to try to work together
> again, and merge back both projects, that'd be best for everyone.
When people suggest that, I always wonder how they see that happening with
regard to the code.
On 08/15/2014 11:53 PM, The Wanderer wrote:
> It's also something the Linux kernel is still doing, with apparent
> success.
Yes, the Linux kernel is a successful project. Does this mean using a
list for reviewing patches is a good thing? No! The workflow with a list
is simply horrible. Using git-r
L'octidi 28 thermidor, an CCXXII, Bálint Réczey a écrit :
> Using Gerrit and "file ownersip" are not mutually exclusive. Gerrit
> can be configured to automatically invite the right people for review
> based on the changed path. We recently migrated to Gerrit at the
> Wireshark project and it helps
On Sat, 16 Aug 2014, Guido Günther wrote:
> On Sat, Aug 16, 2014 at 10:18:29AM +0200, Raphael Hertzog wrote:
> [..snip..]
> > We do this for Kali Linux too but there are always cases where some
> > contributors forget about the suffix (in particular when we package stuff
> > not yet in Debian, or n
On Sat, 16 Aug 2014, Scott Kitterman wrote:
> Silly or not in your opinion, the Qt-KDE team repositories are set up this
> way.
Sorry, I wasn't aware of that and didn't want to imply anything on people
using such a scheme.
Still it would be interesting to know why the team made this choice and
w
On August 16, 2014 8:03:18 AM EDT, Raphael Hertzog wrote:
>(Please trim the quoted mail when you answer)
>
>On Fri, 15 Aug 2014, Scott Kitterman wrote:
>> >- are there other important things to standardize?
>>
>> We don't even agree on if repositories should be full source or
>Debian
>> directory
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: python-xstatic-spin
Version : 1.2.8.0+dfsg1
Upstream Author : Radomir Dopieralski
* URL : https://github.com/stackforge/xstatic-spin
* License : Expat
Programming Lang: Python
Descripti
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: libjs-spin.js
Version : 1.2.8
Upstream Author : Felix Gnass
* URL : https://github.com/fgnass/spin.js
* License : Expat
Programming Lang: Javascript
Description : animated CSS3 load
(Please trim the quoted mail when you answer)
On Fri, 15 Aug 2014, Scott Kitterman wrote:
> >- are there other important things to standardize?
>
> We don't even agree on if repositories should be full source or Debian
> directory only. Not sure how we can even start to discuss the rest if we
> d
Hi,
On Fri, 15 Aug 2014, Guido Günther wrote:
> The gbp manual has a recommended branch layout:
>
>
> http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.BRANCH.NAMING
>
> which could serve as a basis. There's plenty of room for improvement,
> e.g. the case where
Hi,
On Sat, 16 Aug 2014, intrigeri wrote:
> Marco d'Itri wrote (15 Aug 2014 18:17:16 GMT) :
> > On Aug 15, Raphael Hertzog wrote:
> >> - we can more easily share our git repositories with upstreams
> >> and downstreams
> > Did they ask for this?
>
> Wrt. downstreams: I guess that Raphaël is im
On Sat, Aug 16, 2014 at 10:18:29AM +0200, Raphael Hertzog wrote:
[..snip..]
> We do this for Kali Linux too but there are always cases where some
> contributors forget about the suffix (in particular when we package stuff
> not yet in Debian, or new upstream releases of packages that lag behind in
Hi,
Marco d'Itri wrote (15 Aug 2014 18:17:16 GMT) :
> On Aug 15, Raphael Hertzog wrote:
>> - we can more easily share our git repositories with upstreams
>> and downstreams
> Did they ask for this?
Wrt. downstreams: I guess that Raphaël is implicitly asking for this
(with his Kali hat) in this
Brian May wrote:
> On 16 Aug 2014 16:19, "Lars Wirzenius" wrote:
>> If you upload things to unstable that depend on things in NEW, nobody
>> will be able to install or upgrade that package (until the dependency
>> gets through NEW).
> In this case however the 2nd package will also get blocked in
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: python-xstatic-qunit
Version : 1.14.0.2
Upstream Author : Radomir Dopieralski
* URL : https://github.com/stackforge/xstatic-qunit
* License : Expat
Programming Lang: Python
Description
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: python-xstatic-jsencrypt
Version : 2.0.0.2
Upstream Author : Radomir Dopieralski
* URL : https://github.com/stackforge/xstatic-jsencrypt
* License : Expat
Programming Lang: Python
Descr
upstream prefers that we use something generated
from his git repository? Shouldn't all what upstream generates in the
release tarball also done by the Debian package build anyway?
Also, what if I need to build a Debian package out of an upstream
commit, because there's some bug fixes which I n
Hi,
On Fri, 15 Aug 2014, Alessandro Ghedini wrote:
> Additionally, using the / scheme would allow for very simple
> enumeration of debian vs. ubuntu vs. other with something like "git tag | grep
> ^/" without the need to actually parse debian/changelog or the
> specific
> version of the tag (dunn
On 08/16/2014 02:46 PM, Brian May wrote:
> On 16 Aug 2014 16:19, "Lars Wirzenius" mailto:l...@liw.fi>>
> wrote:
>> If you upload things to unstable that depend on things in NEW, nobody
>> will be able to install or upgrade that package (until the dependency
>> gets through NEW).
>
> In this case h
On 08/16/2014 09:07 AM, Brian May wrote:
> Note that there is a huge number of Python packages in Debian. It is
> very possible that your favourite packages aren't available as Python3
> Debian packages, either because upstream doesn't support Python 3, or
> because nobody has done the work yet to
On 08/15/2014 11:24 PM, Scott Kitterman wrote:
> On August 15, 2014 4:57:19 PM EDT, Diogene Laerce wrote:
>>
>>
>> On 08/15/2014 10:20 PM, Scott Kitterman wrote:
>>> On August 15, 2014 1:42:04 PM EDT, Paul Tagliamonte
>> wrote:
On Fri, Aug 15, 2014 at 07:28:06PM +0200, Diogene Laerce wrote
On Sat, Aug 16, 2014 at 04:46:17PM +1000, Brian May wrote:
> On 16 Aug 2014 16:19, "Lars Wirzenius" wrote:
> > If you upload things to unstable that depend on things in NEW, nobody
> > will be able to install or upgrade that package (until the dependency
> > gets through NEW).
>
> In this case ho
58 matches
Mail list logo
