On Sat, Feb 22, 2014 at 07:52:38AM +0800, Paul Wise wrote:
> I'm not part of DSA but it looks like quantz is suitable...
thanks Paul, I think I will go for quantz then.
Cheers -Ralf.
--
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contac
[Fixed CC to point to d-a@ldo. There's nothing secret in this discussion.]
On Sat, 22 Feb 2014, Paul Wise wrote:
> > 4 Disk space (for the static web pages that hold the results): this depends
> > on the number of days for which we will hold old results. A rough
> > estimate is
> > 10M * nu
I'm not part of DSA but it looks like quantz is suitable...
On Fri, Feb 21, 2014 at 10:11 PM, Ralf Treinen wrote:
> 1 the Packages files on which we run our analysis in their latest version
> (the ones that you find as dists/sid/main/binary-/Packages on a
> mirror):
> sid, testing, stable;
Hello,
On Thu, Feb 20, 2014 at 10:01:59PM +, Stephen Gran wrote:
> This one time, at band camp, Lucas Nussbaum said:
> > Now, that's my perception. If DSA is fine with adding another service
> > under qa.d.o, I personally don't have anything against it.
>
> I guess there are two parts to this
This one time, at band camp, Lucas Nussbaum said:
> Now, that's my perception. If DSA is fine with adding another service
> under qa.d.o, I personally don't have anything against it.
I guess there are two parts to this:
Does the service have resource needs that make it appropriate or
inappropriat
On Wed, Feb 19, 2014 at 09:11:20 +0100, Ralf Treinen wrote:
> Julien (and anyone else who is using this service), can you please tell me
> which of the features of the old edos-debcheck are in your opinion
> useful or not useful:
>
> - checking stable
I don't use this much.
> - keeping summarie
On Thu, Feb 20, 2014 at 08:16:42AM +0100, Lucas Nussbaum wrote:
> (Cc += dsa@d.o)
>
> On 20/02/14 at 00:14 +0100, Julien Cristau wrote:
> > On Wed, Feb 19, 2014 at 06:56:26 +0100, Lucas Nussbaum wrote:
> >
> > > On 19/02/14 at 09:42 +0800, Paul Wise wrote:
> > > > On Wed, Feb 19, 2014 at 4:39 AM
(Cc += dsa@d.o)
On 20/02/14 at 00:14 +0100, Julien Cristau wrote:
> On Wed, Feb 19, 2014 at 06:56:26 +0100, Lucas Nussbaum wrote:
>
> > On 19/02/14 at 09:42 +0800, Paul Wise wrote:
> > > On Wed, Feb 19, 2014 at 4:39 AM, Julien Cristau wrote:
> > >
> > > > Ralf, QA folks, does that seem reasonab
On Wed, Feb 19, 2014 at 06:56:26 +0100, Lucas Nussbaum wrote:
> On 19/02/14 at 09:42 +0800, Paul Wise wrote:
> > On Wed, Feb 19, 2014 at 4:39 AM, Julien Cristau wrote:
> >
> > > Ralf, QA folks, does that seem reasonable?
> >
> > Seems reasonable to me.
>
> OTOH, we are not quite good at maintai
Hello,
On Tue, Feb 18, 2014 at 09:39:05PM +0100, Julien Cristau wrote:
> Hi,
>
> for a while Ralf has taken care of the edos.debian.net service which
> runs an installability checker over the unstable/testing/stable Packages
> files. In recent months that service has suffered fr
On 19/02/14 at 09:42 +0800, Paul Wise wrote:
> On Wed, Feb 19, 2014 at 4:39 AM, Julien Cristau wrote:
>
> > Ralf, QA folks, does that seem reasonable?
>
> Seems reasonable to me.
OTOH, we are not quite good at maintaining stuff under qa.d.o. Maybe it
would be better to setup a separate edos.d.o
On Wed, Feb 19, 2014 at 4:39 AM, Julien Cristau wrote:
> Ralf, QA folks, does that seem reasonable?
Seems reasonable to me.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas..
Hi,
for a while Ralf has taken care of the edos.debian.net service which
runs an installability checker over the unstable/testing/stable Packages
files. In recent months that service has suffered from availability
issues. Since I use it quite frequently, that makes me sad :)
I believe it might
On 02/12/2007, Ralf Treinen wrote:
> should be working starting with this night's run (23:40 CET).
Perfect, thanks!
I was wondering how much resources it consumes, and whether it would be
feasible to have an edos run after each dinstall run, so as to keep a
close track of uninstallable packages.
> timestamp or the links to the diffs.
>
> 1. http://edos.debian.net/edos-debcheck/results/unstable/latest/
> 2. http://edos.debian.net/edos-debcheck/unstable.php
should be working starting with this night's run (23:40 CET).
Cheers -Ralf.
--
To UNSUBSCRIBE, email to [EMA
On 01/12/2007, Ralf Treinen wrote:
> No problem. You just need the symlink in the filesystem, right?
That's it, right.
> Or do you also wish a html link on the generated html pages?
No thanks, I'll just use the static URL with latest/ to fetch the
updates of the history.xml file, then do some co
timestamp or the links to the diffs.
>
> 1. http://edos.debian.net/edos-debcheck/results/unstable/latest/
> 2. http://edos.debian.net/edos-debcheck/unstable.php
No problem. You just need the symlink in the filesystem, right?
Or do you also wish a html link on the generated ht
Hi,
I'd like to know whether it would be feasible to have a symlink from
e.g. [1] pointing to the latest run, so that we can fetch the diffs
directly without having to parse the summary page [2] to get the
timestamp or the links to the diffs.
1. http://edos.debian.net/edos-debcheck/re
Hi,
On Thu, Jan 04, 2007 at 10:13:10PM +0100, Ralf Treinen wrote:
> On Wed, Dec 27, 2006 at 01:14:39PM +0100, Frederic Lehobey wrote:
> > On my side, I would ask edos.debian.net maintainers to add, if not too
> > difficult, the kfreebsd-i386 and kfreebsd-amd64 architectures as is
removed from
> > > > stable...
> > > Why ? etch-m68k is alive and kicking.
> >
> > Because it makes the statistics less useful: if you look at
> > http://edos.debian.net/edos-debcheck/ you will see that m68k has the most
> > broken packages, thus contr
Hi,
On Wednesday 27 December 2006 13:14, Frederic Lehobey wrote:
> So your request to edos.debian.net is 'please remove m68k from etch'
> statistics which is something very different from testing
right. (bit it's labeled "testing" on that page atm, not et
ause it makes the statistics less useful: if you look at
> http://edos.debian.net/edos-debcheck/ you will see that m68k has the most
> broken packages, thus contributing heavily to the number of packages which
> are broken on "some" arch (see there).
>
> The "whic
Hi,
On Friday 22 December 2006 15:25, Bill Allombert wrote:
> > m68k can be removed from testing and amd64 should be removed from
> > stable...
> Why ? etch-m68k is alive and kicking.
Because it makes the statistics less useful: if you look at
http://edos.debian.net/edos-debchec
On Mon, Dec 18, 2006 at 04:59:13PM +0100, Holger Levsen wrote:
> Hi,
>
> On Monday 18 December 2006 16:45, Holger Levsen wrote:
> > Can you please update it twice a day (after britney/dinstall runs) via
> > cron?! Would be very cool!
>
> And while you're at it ;) (or add it to your todo-list...):
On Mon, Dec 18, 2006 at 04:59:13PM +0100, Holger Levsen wrote:
> On Monday 18 December 2006 16:45, Holger Levsen wrote:
> > Can you please update it twice a day (after britney/dinstall runs) via
> > cron?! Would be very cool!
>
> And while you're at it ;) (or add it to your todo-list...):
>
> m6
Hi,
On Monday 18 December 2006 16:45, Holger Levsen wrote:
> Can you please update it twice a day (after britney/dinstall runs) via
> cron?! Would be very cool!
And while you're at it ;) (or add it to your todo-list...):
m68k can be removed from testing and amd64 should be removed from stable...
Hi,
http://edos.debian.net/ shows outdated information from this saturday only ;)
Can you please update it twice a day (after britney/dinstall runs) via cron?!
Would be very cool!
In today's build of debian-edu nagios2-common isn't installable.
main-server+thin-client-server fail
27 matches
Mail list logo