On 3/7/24 3:50 AM, Boyuan Yang wrote:
I am not sure where vcswatch is running on
quantz, see: https://db.debian.org/machines.cgi
search for "qa" in the Description column.
, but obviously the machine
now has a full disk that makes vcswatch fail:
See https://qa.debian.org/cgi-bin/vcswatch?pa
Processing control commands:
> tags -1 + patch
Bug #1016203 [qa.debian.org] vcswatch: check debian/latest branch as well
(DEP-14)
Added tag(s) patch.
--
1016203: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016203
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
On Mon, Apr 30, 2018 at 10:18 PM, Thorsten Glaser wrote:
> a bug report against what?
Package: qa.debian.org
User: qa.debian@packages.debian.org
Usertags: vcswatch
> There’s no indication where bugreports should go, except this list.
Please file a second bug report about that :)
--
bye,
p
Hi Paul,
> > fatal: dumb http transport does not support shallow capabilities
> >
> > Just unshallow then ☺
>
> Please file a bug about this so it isn't forgotten.
a bug report against what? Surely not against myon… the page says:
“To report a problem with the QA web site, e-mail
debian-qa@list
On Sat, Apr 21, 2018 at 5:57 AM, Thorsten Glaser
> fatal: dumb http transport does not support shallow capabilities
>
> Just unshallow then ☺
Please file a bug about this so it isn't forgotten.
--
bye,
pabs
https://wiki.debian.org/PaulWise
On Thu, Aug 10, 2017 at 03:37:37PM +0200, Thorsten Glaser wrote:
> Although I have to admit the VCS-{Browser,Git} headers
> in debian/control on experimental were not changed.
> Could this be a cause?
Yes, that's exactly the cause. If HEAD does not match what is uploaded
then you should be changi
Re: Colin Watson 2014-07-31 <20140730233549.gb5...@riva.ucam.org>
> Hi,
>
> I used a "v3" branch for parted for a while, but in parted 3.1-4
> (uploaded 2014-07-23) I pointed the Vcs-* fields back at master.
> However, https://qa.debian.org/cgi-bin/vcswatch?package=parted shows
> that vcswatch is
Re: Raphael Hertzog 2014-08-02 <20140802090202.ga7...@x230-buxy.home.ouaza.com>
> There's no need for this.
>
> $ git ls-remote
> https://alioth.debian.org/anonscm/git/openstack/ceilometer.git|grep HEAD
>
> This will give you the commit corresponding to the default branch. You can
> then just ch
Re: Thomas Goirand 2014-08-02 <53dca08d.8040...@debian.org>
> The problem is that between the initial "git clone" and the subsequent
> "git fetch", it is possible that the default branch of the remote bare
> repository has changed, and therefore, vcswatch may continue to use the
> wrong branch as t
Le Sun, Aug 03, 2014 at 12:02:45AM +0800, Thomas Goirand a écrit :
> FYI, in shell scripting, here's the full solution to print the default
> branch on the remote:
>
> HEADREF=`git ls-remote
> https://alioth.debian.org/anonscm/git/openstack/ceilometer.git | grep
> HEAD | awk '{print $1}'`
>
> git
* Thomas Goirand [140802 18:06]:
> Is there something quicker than 2 "git ls-remote" calls?
Hi,
I don't know a way to do this in a single call but you can eliminate a
few uses of grep:
HEADREF=`git ls-remote
https://alioth.debian.org/anonscm/git/openstack/ceilometer.git HEAD
| awk '{print $1}'`
On 08/02/2014 05:02 PM, Raphael Hertzog wrote:
> Hi,
>
> On Sat, 02 Aug 2014, Thomas Goirand wrote:
>> The obvious "solution" would be to always clone, instead of doing "git
>> fetch", though of course, this has a huge cost which maybe you don't
>> want to have. So I'm not sure how to fix it... Th
Le Sat, Aug 02, 2014 at 04:25:49PM +0800, Thomas Goirand a écrit :
>
> 1- Have somewhere on the web interface, some button to ask for a full
> re-clone of the package.
> 2- Every now and then (every week?) do a full reclone
> 3- If qa.debian.org can have ssh access to Alioth, then something like
>
Hi,
On Sat, 02 Aug 2014, Thomas Goirand wrote:
> The obvious "solution" would be to always clone, instead of doing "git
> fetch", though of course, this has a huge cost which maybe you don't
> want to have. So I'm not sure how to fix it... Though a few ideas:
>
> 1- Have somewhere on the web inte
Re: Andreas Tille 2014-06-30 <20140630100326.gc5...@an3as.eu>
> Cool. Any reason not to use UDD? If there are good reasons could you
> imagine some mirroring to UDD? I'd like to use it for Blends and all
> the information used for Blends should be in UDD.
I have no idea what the process is to c
Quoting Christoph Berg (2014-06-30 11:00:33)
> Re: Jonas Smedegaard 2014-06-24
> <20140624164126.21806.49...@bastian.jones.dk>
>> Cool addition of vcswatch to the QA page!
>>
>> I noticed what seems to be a bug - not biggie, but thought you might
>> want to know about it anyway:
>>
>> http://qa
* Christoph Berg [140630 10:49]:
[..]
> Thanks for reporting!
Thanks for fixing this so fast, it's appreciated.
--
,''`. Christian Hofstaedtler
: :' : Debian Developer
`. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03
`-
pgpe1a4Ti6AEC.pgp
Description: PGP signature
Hi Christoph,
On Mon, Jun 30, 2014 at 11:00:33AM +0200, Christoph Berg wrote:
> > > Cool addition of vcswatch to the QA page!
> >
> > YES!!!
> >
> > I really like this. May I ask where the data are drained from (sure
> > I could try to find the code, but ... sorry for my lazyness)
>
> http://a
Re: Jonas Smedegaard 2014-06-24 <20140624164126.21806.49...@bastian.jones.dk>
> Hi,
>
> Cool addition of vcswatch to the QA page!
>
> I noticed what seems to be a bug - not biggie, but thought you might
> want to know about it anyway:
>
> http://qa.debian.org/cgi-bin/vcswatch?package=pandoc&pok
Re: Christian Hofstaedtler 2014-06-29 <20140629133940.ga17...@sx.home.zeha.at>
> Hi!
>
> vcswatch for bundler [1] shows that the current version tagged in
> git would be 1.6.2-1, but this is clearly wrong -- there's a tag for
> 1.6.3-1 in git and TTBOMK has been for the last 10 days.
>
> Is there
On Tue, Jun 24, 2014 at 06:41:26PM +0200, Jonas Smedegaard wrote:
> Cool addition of vcswatch to the QA page!
YES!!!
I really like this. May I ask where the data are drained from (sure
I could try to find the code, but ... sorry for my lazyness)
Thanks for the cool extension
Andreas.
--
21 matches
Mail list logo