Hi Russ,
On Sun, Aug 17, 2014 at 10:31:26AM -0700, Russ Allbery wrote:
> Thomas Goirand writes:
>
> > As Charles wrote, pristine-tar works with small tarballs, but when
> > upstream has multi-megabytes tarballs and releases often, the Git
> > repository quickly grows to something not manageable.
On 08/17/2014 07:41 PM, Andreas Cadhalpun wrote:
> Michael Niedermayer already volunteered to help with all security
> related problems of FFmpeg in Debian.
> So what should he do to relieve the impact on the security and release
> teams?
Let's say he would take the role of patching stuff in Stabl
Hi DD folks!
recently a bug has been opened against a package I maintain (debian science is
the maintainer, while I'm the only uploader), but I did not notice with a mail,
because:
A) I forgot to subscribe to debian-science archives
B) Even if subscribed I don't think I would have seen it, becau
On 08/16/2014 11:30 PM, Nicolas George wrote:
> So what about the code? Shall the FFmpeg developers discard three years of
> work and start working on libav? Or shall the libav developers accept to
> work with the code from FFmpeg that they do not like?
FFmpeg folks should rework the code to make
On 08/16/2014 11:11 PM, Nicolas George wrote:
> 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 migrate
On 08/16/2014 11:44 PM, wm4 wrote:
>> This reasoning may work when you have only a small amount of information
>> to read. When you are overwhelmed with it, having different places to do
>> different things is a much better approach. Sending patches to a list
>> simply doesn't scale.
>>
>> Also, wi
On Sat, Aug 16, 2014 at 02:03:18PM +0200, Raphael Hertzog wrote:
> The vast majority (all?) of git packaging repositories have the upstream
> sources.
>
> I think this point is not really contentious.
Others have demonstrated that this is not the case. However, I believe the
majority of git packa
On Sun, 17 Aug 2014 23:14:33 -0500, Josh Triplett
wrote:
>Why a requirement to not improve upstream? Ideally, the Debian patches
>for a piece of software should trend to zero over time, as fixes make
>their way upstream.
Imagine an upstream author having the cooperation level of the systemd
team
Hi,
the libfreerdp1 package changed its soname without a transition and
without introducing a new package.
That broke binary compatibility of at least remmina and
libguac-client-rdp0 [0].
I expect more rebuilds / binNMUs to be necessary. As I do not find
anything about that triggered by the main
On Sun, Aug 17, 2014 at 09:24:33PM -0700, Ludovico Cavedon wrote:
> On Sun, Aug 17, 2014 at 9:14 PM, Josh Triplett wrote:
> > On Sun, Aug 17, 2014 at 08:48:40PM -0700, Ludovico Cavedon wrote:
> >> On Sun, Aug 17, 2014 at 1:40 AM, Josh Triplett
> >> wrote:
> >> > 3) Teach ntopng to understand /et
On Sun, Aug 17, 2014 at 9:14 PM, Josh Triplett wrote:
> On Sun, Aug 17, 2014 at 08:48:40PM -0700, Ludovico Cavedon wrote:
>> On Sun, Aug 17, 2014 at 1:40 AM, Josh Triplett wrote:
>> > 3) Teach ntopng to understand /etc/ntopng.conf natively and migrate the
>> > settings there.
>>
>> yes, that woul
On Sun, Aug 17, 2014 at 08:48:40PM -0700, Ludovico Cavedon wrote:
> On Sun, Aug 17, 2014 at 1:40 AM, Josh Triplett wrote:
> > 3) Teach ntopng to understand /etc/ntopng.conf natively and migrate the
> > settings there.
>
> yes, that would be an option. I forgot to add the requirement "without
> pa
On Sun, Aug 17, 2014 at 4:20 AM, Marc Haber
wrote:
> On Sun, 17 Aug 2014 12:17:21 +0200, Michael Biebl
> wrote:
>>I also happen to notice, that you use a ENABLED=1 flag.
>>It would be a good idea to deprecate that as well and remove that.
>>
>>We have better mechanisms nowadays to enable/disable
Josh,
On Sun, Aug 17, 2014 at 1:40 AM, Josh Triplett wrote:
> 3) Teach ntopng to understand /etc/ntopng.conf natively and migrate the
> settings there.
yes, that would be an option. I forgot to add the requirement "without
patching upstream code" :)
> 4) Teach ntopng to automatically detect the
On Sun, Aug 17, 2014 at 01:44:15PM +0200, Marco d'Itri wrote:
> On Aug 17, Marc Haber wrote:
> > Please. The attitute of requiring Debian maintainers to modify
> > upstream software instead of having simple two-line extension to an
> > init script is really unfriendly. Why do only systemd friends
On Sun, Aug 17, 2014 at 04:20:34PM +0800, Thomas Goirand wrote:
> As Charles wrote, pristine-tar works with small tarballs, but when
> upstream has multi-megabytes tarballs and releases often, the Git
> repository quickly grows to something not manageable.
Only if you're lacking a proper branch t
On Sun, Aug 17, 2014 at 07:57:55PM +, Sune Vuorela wrote:
> On 2014-08-16, Raphael Hertzog wrote:
> > I believe that most of the current workflows do respect this rule (except
> > for the case where you only store the debian directory).
> I do think that this is quite common, and my preferred
On Sun, 17 Aug 2014, Thomas Goirand wrote:
> On 08/17/2014 03:52 AM, Raphael Hertzog wrote:
> > 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 diffe
On Sun, Aug 17, 2014 at 09:14:47PM +0200, Luca Barbato wrote:
[...]
> > Ive asked [1][2] back then what "policy in place" was broken
>
> - you tried to commit code that was blatantly below the already lax
> quality requirements (e.g. it contained tabs, it was (and still is) hard
> to read, it cont
On 2014-08-16, Raphael Hertzog wrote:
> I believe that most of the current workflows do respect this rule (except
> for the case where you only store the debian directory).
I do think that this is quite common, and my preferred way of doing
things. It is easy for newcomers to handle, easy for me
On 17/08/14 10:28, Michael Niedermayer wrote:
> On Fri, Aug 15, 2014 at 01:19:38AM +0200, Luca Barbato wrote:
>> Stefano Sabatini wrote:
> [...]
>>
>> The list is quite long and debunking each of the statements could take a
>> lot of time.
>>
>> I'm going to address two historical "misrepresentatio
On Sun, 17 Aug 2014 10:36:22 -0700, Russ Allbery
wrote:
>It's good to be aware of the option to improve the upstream source so that
>packaging it is easier and so that it works better for everyone with less
>configuration.
I find packaging easier when I work around a limitation in the
upstream so
Am 17.08.2014 20:33, schrieb Ansgar Burchardt:
> Michael Biebl writes:
>> It's also very easy to forget this particular caveat when you do
>> stable-security uploads.
>> And as the stable-security archive will *not* reject such a tarball, you
>> can end up with tarballs which have different md5sum
Michael Biebl writes:
> On the other hand, downloading the tarball from the archive is not
> automated by any tool afaics.
> That means, git-buildpackage will happily re-create the dist tarball
> from the upstream branch.
> If you are not watching really carefully, this step is very easy to miss.
Marc Haber writes:
> Josh Triplett wrote:
>> 3) Teach ntopng to understand /etc/ntopng.conf natively and migrate the
>> settings there.
>> 4) Teach ntopng to automatically detect the available network devices
>> on the system (including new ones that show up dynamically) and
>> automatically ha
Reinhard Tartler writes:
> Other than that, I am really curious to learn more about the
> fundamental design problems with pristine-tar.
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=pristine-tar doesn't
> look great, but not too bad either.
The fundamental concern with pristine-tar is tha
On Sun, Aug 17, 2014 at 1:31 PM, Russ Allbery wrote:
> Thomas Goirand writes:
>
>> As Charles wrote, pristine-tar works with small tarballs, but when
>> upstream has multi-megabytes tarballs and releases often, the Git
>> repository quickly grows to something not manageable.
>
> This does not mat
Thomas Goirand writes:
> As Charles wrote, pristine-tar works with small tarballs, but when
> upstream has multi-megabytes tarballs and releases often, the Git
> repository quickly grows to something not manageable.
This does not match my experience at all. I have packaged software like
that wi
On Fri, Aug 15, 2014 at 04:16:01PM +0200, Raphael Hertzog wrote:
> - encoding (due to git restrictions):
> ":" -> "%"
> "~" -> "_"
I think I'd prefer to see something like X -> _Y where chr(Y) = X and
hex(ord(X)) = Y, e.g.
"_" -> "_5f"
":" -> "_3a"
"~" -> "_7e"
There is
Marco wrote:
>On Aug 17, Marc Haber wrote:
>
>> Please. The attitute of requiring Debian maintainers to modify
>> upstream software instead of having simple two-line extension to an
>> init script is really unfriendly. Why do only systemd friends keep
>> recommending this?
>Maybe because the other
On Sun, 17 Aug 2014 13:14:27 +0100, Simon McVittie
>if ! [ -e /etc/foo.conf ]
>then
>echo -n "(not starting, you need to create /etc/foo.conf)"
>return 0
>fi
if ! grep '^important-option' foo.conf;
looks like a rather common idiom.
Greetings
Marc
--
---
On Sun, 17 Aug 2014 13:48:44 +0200, m...@linux.it (Marco d'Itri) wrote:
>On Aug 17, Marc Haber wrote:
>> Does Debian no longer care about easy updates, or have we accepted
>> that updating to jessie will be a nightmare anyway and recommend
>> reinstallation instead?
>Yes, I hate users and I want t
On Sun, Aug 17, 2014 at 12:03:44PM -0300, Antonio Terceiro wrote:
> On Sun, Aug 17, 2014 at 12:07:58AM +0200, Ansgar Burchardt wrote:
> > First, the archive used by buildds is now publically accessible in
> > http://incoming.debian.org/debian-buildd/. This location provides access
> > to all recent
On Sun, Aug 17, 2014 at 12:07:58AM +0200, Ansgar Burchardt wrote:
> First, the archive used by buildds is now publically accessible in
> http://incoming.debian.org/debian-buildd/. This location provides access
> to all recently uploaded packages, split into individual suites, and
> provides the nec
On 17/08/14 12:48, Marco d'Itri wrote:
> On Aug 17, Marc Haber wrote:
>> It is not
>> always possible to come with a working default configuration or to
>> build one in postinst.
>
> If unconfigured software really cannot fail cleanly then the package can
> install it without enabling the service
Hi,
>> 3) Teach ntopng to understand /etc/ntopng.conf natively and migrate the
>> settings there.
>> 4) Teach ntopng to automatically detect the available network devices on
>> the system (including new ones that show up dynamically) and
>> automatically handle all of them unless configured to do
Marc Haber writes:
> Quite a number of packages also refrain from starting the daemon on an
> unconfigured newly installed package until the user has configured it.
> I guess that this needs to be replaced "by native mechanisms (i.e.
> implemented as a patch to the upstream software)" as well? It
On Aug 17, Marc Haber wrote:
> Please. The attitute of requiring Debian maintainers to modify
> upstream software instead of having simple two-line extension to an
> init script is really unfriendly. Why do only systemd friends keep
> recommending this?
Maybe because the others do not care enough
On Aug 17, Marc Haber wrote:
> Does Debian no longer care about easy updates, or have we accepted
> that updating to jessie will be a nightmare anyway and recommend
> reinstallation instead?
Yes, I hate users and I want them to suffer.
> Quite a number of packages also refrain from starting the
On Aug 17, Ludovico Cavedon wrote:
> 2) instead of doing Exec=ntopng, Exec a script that does the mangling
> and then execs ntopng.
If you cannot improve the software enough then this is the best choice.
--
ciao,
Marco
signature.asc
Description: Digital signature
Hi Russ,
On 16.08.2014 18:33, Russ Allbery wrote:
All the renaming and cordial co-existence in the world won't change this.
The things that would change this is for one or both projects to develop a
better security track record and a history of higher-quality code releases
that require less ongo
On Sun, 17 Aug 2014 12:17:21 +0200, Michael Biebl
wrote:
>I also happen to notice, that you use a ENABLED=1 flag.
>It would be a good idea to deprecate that as well and remove that.
>
>We have better mechanisms nowadays to enable/disable SysV init scripts
>(and systemd service files).
In my packa
On 17/08/14 10:38, Thomas Goirand wrote:
> I had the same problem as you describe above, even a bit more
> complicated because, in what we did, /etc/default/ sometimes
> doesn't exist (it's not mandatory in what we did).
EnvironmentFile takes precedence over Environment, and EnvironmentFile
starti
On Sun, 17 Aug 2014 12:05:13 +0200, Michael Biebl
wrote:
>But yeah, such wrapper scripts should be avoided if possible and native
>mechanisms used.
Having read quite of system docs in the last weeks to find a way to
key /etc/crypttab keyscript functionality back, I have found that
"using the nati
On Sun, 17 Aug 2014 01:40:27 -0700, Josh Triplett
wrote:
>Ludovico Cavedon wrote:
>> 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
Le Sun, Aug 17, 2014 at 09:00:57AM +0200, Raphael Hertzog a écrit :
>
> debian/unstable also doesn't follow / because unstable's
> codename is sid. And I really mean that is a better choice than
> (e.g. unstable, testing, stable).
Hi all,
for suites that are never released, I think that it is
Am 17.08.2014 05:51, schrieb Ludovico Cavedon:
> 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 op
Am 17.08.2014 11:38, schrieb Thomas Goirand:
> How about teaching systemd that script is sometimes necessary? It's
> annoying to write a wrapper, because then, it does a fork to start the
> daemon, so the PID changes. Has this been reported upstream? If yes,
> what's upstream opinion about it?
I
Am 17.08.2014 10:20, schrieb Thomas Goirand:
> On 08/17/2014 01:08 AM, Michael Biebl wrote:
>> More importantly (at least in my experience): If you are working in a
>> team and you regenerate the tarball from git, it's very likely that
>> the md5sum of the generated tarball differs from what has b
On 08/17/2014 11:51 AM, Ludovico Cavedon wrote:
> 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 o
Ludovico Cavedon wrote:
> 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
On 08/17/2014 03:13 AM, Raphael Hertzog wrote:
> 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 resposi
On Fri, Aug 15, 2014 at 01:19:38AM +0200, Luca Barbato wrote:
> Stefano Sabatini wrote:
[...]
>
> The list is quite long and debunking each of the statements could take a
> lot of time.
>
> I'm going to address two historical "misrepresentations":
>
> # The change of management
>
> Michael Nied
On 08/17/2014 12:20 AM, Russ Allbery wrote:
> 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 pref
On 08/17/2014 03:52 AM, Raphael Hertzog wrote:
> 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 l
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: python-xstatic-jquery.quicksearch
Version : 2.0.4.1
Upstream Author : Radomir Dopieralski
* URL : https://github.com/stackforge/xstatic-jquery.quicksearch
* License : Expat
Programming La
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: libjs-jquery.quicksearch
Version : 2.0.4
Upstream Author : Nicolas Brassard
* URL : https://github.com/DeuxHuitHuit/quicksearch
* License : Expat
Programming Lang: Javascript
Descriptio
On Sun, 17 Aug 2014, Thomas Goirand wrote:
> Well, I have nothing against derivative/downstream distros, but if
> you're about to do a new DEP, please consider Debian first. In such
> case, debian/unstable makes a lot more sense than just debian/master.
> Like I wrote in another post, "master" does
58 matches
Mail list logo
