On Mon, Dec 19, 2016 at 11:13:48PM +0100, Andreas Beckmann wrote:
> > which I understood as both having the same tests…
>
> That's the same *tarballs*
>
> [sid]
> precedence = 1
> description = + Fails if there are leftover files after purge.
> piuparts-flags =
> %(flags-leftovers)s
>
>
@debian-release: please
piuparts-ignore gitlab/8.13.6+dfsg2-2
and let's see if we can improve the situation on piuparts' side for the
next upload.
On 2016-12-19 17:33, Holger Levsen wrote:
> [tarball/sid]
> piuparts-flags =
> %(flags-default)s
>
> [tarball/stretch]
> piuparts-flags =
>
On Mon, Dec 19, 2016 at 05:24:38PM +0100, Andreas Beckmann wrote:
> On 2016-12-19 17:13, Niels Thykier wrote:
> > Though for some reason it appears that your testing version is passing
> > the piuparts, which leads me to thinking that unstable and testing have
> > different requirements.
> >
> >
On Mon, Dec 19, 2016 at 04:13:00PM +, Niels Thykier wrote:
> Though for some reason it appears that your testing version is passing
> the piuparts, which leads me to thinking that unstable and testing have
> different requirements.
>
> * @h01ger: can you confirm the above?
actually, no. (I a
On 2016-12-19 17:13, Niels Thykier wrote:
> Though for some reason it appears that your testing version is passing
> the piuparts, which leads me to thinking that unstable and testing have
> different requirements.
>
> * @h01ger: can you confirm the above?
Yes, the sid configuration is more stri
Pirate Praveen:
> On വെള്ളി 09 ഡിസംബര് 2016 01:45 വൈകു, Emilio Pozuelo Monfort wrote:
>> The hint was there, it's just that since this is a new kind of hint, it
>> hadn't
>> been enabled in the configuration and so britney was ignoring it.
>>
>> I have fixed that now and urgented gitlab so it doe
On വെള്ളി 09 ഡിസംബര് 2016 01:45 വൈകു, Emilio Pozuelo Monfort wrote:
> The hint was there, it's just that since this is a new kind of hint, it hadn't
> been enabled in the configuration and so britney was ignoring it.
>
> I have fixed that now and urgented gitlab so it doesn't have to wait until i
On 09/12/16 05:29, Pirate Praveen wrote:
>
>
> On 2016, ഡിസംബർ 7 12:32:00 PM IST, Niels Thykier wrote:
>> I have added a hint to ignore the piuparts issues.
>
> That hint is not active, 8 days and it still says not considered. It
> completed 5 days before the 10 day mandatory migration started
On 2016, ഡിസംബർ 7 12:32:00 PM IST, Niels Thykier wrote:
>I have added a hint to ignore the piuparts issues.
That hint is not active, 8 days and it still says not considered. It completed
5 days before the 10 day mandatory migration started. This is frustrating. I'm
blocked from uploading a se
On ബുധന് 07 ഡിസംബര് 2016 12:32 വൈകു, Niels Thykier wrote:
> I have added a hint to ignore the piuparts issues.
But gitlab is still not migrated after 7 days.
signature.asc
Description: OpenPGP digital signature
Julien Cristau:
> On 12/04/2016 11:18 PM, Holger Levsen wrote:
>> looking at
>> https://piuparts.debian.org/sid/fail/gitlab_8.13.6+dfsg2-1.log I see:
>>
>> 12m12.4s ERROR: WARN: Processes are running inside chroot:
>> 12m20.4s ERROR: WARN: Broken symlinks:
>> 12m55.1s ERROR: FAIL: Package purging l
Pirate Praveen:
> On ബുധന് 07 ഡിസംബര് 2016 02:02 രാവിലെ, Andreas Beckmann wrote:
[...]
>>
>> And the actual problem for the piuparts test failing currently
>> is a ton of cruft lying around after the package was purged:
>>
>> https://piuparts.debian.org/sid/fail/gitlab_8.13.6+dfsg2-1.log
>>
On 12/04/2016 11:18 PM, Holger Levsen wrote:
> looking at
> https://piuparts.debian.org/sid/fail/gitlab_8.13.6+dfsg2-1.log I see:
>
> 12m12.4s ERROR: WARN: Processes are running inside chroot:
> 12m20.4s ERROR: WARN: Broken symlinks:
> 12m55.1s ERROR: FAIL: Package purging left files on system:
>
On 12/04/2016 11:18 PM, Holger Levsen wrote:
> and, btw, #814393 filed against piuparts.d.o "Run redis service for packages
> depending on redis-server like gitlab" is *no* reason for gitlab failing
> to install. gitlab's postinst MUST exit cleanly even if there is no
> redis service available.
>
On ബുധന് 07 ഡിസംബര് 2016 02:02 രാവിലെ, Andreas Beckmann wrote:
>>> 12m12.4s ERROR: WARN: Processes are running inside chroot:
>>> 12m20.4s ERROR: WARN: Broken symlinks:
>>> 12m55.1s ERROR: FAIL: Package purging left files on system:
>>>
>>> of which I'd consider the processes left running in the
>> 12m12.4s ERROR: WARN: Processes are running inside chroot:
>> 12m20.4s ERROR: WARN: Broken symlinks:
>> 12m55.1s ERROR: FAIL: Package purging left files on system:
>>
>> of which I'd consider the processes left running in the chroot to be
>> seriously broken.
>
>It is a WARN and not FAIL. You c
On ചൊവ്വ 06 ഡിസംബര് 2016 07:01 വൈകു, Holger Levsen wrote:
> And we want packages to be installable in eg chroots or such.
>
> Debian packages share a common standard. This is part of it.
If that standard is limiting us to provide better installation
experience for users, we should change it.
On Tue, Dec 06, 2016 at 06:54:21PM +0530, Pirate Praveen wrote:
> That is pointless, I want it to fail if redis-server is no available.
And we want packages to be installable in eg chroots or such.
Debian packages share a common standard. This is part of it.
As I've explained this before and we
On ചൊവ്വ 06 ഡിസംബര് 2016 06:44 വൈകു, Holger Levsen wrote:
> that's fine, just don't fail with error when redis aint there.
That is pointless, I want it to fail if redis-server is no available. It
is not optional, gitlab is useless without a working redis-server. If
there is something wrong with r
On Tue, Dec 06, 2016 at 06:24:08PM +0530, Pirate Praveen wrote:
> I want to be able to ensure a working gitlab instance is present
> without any need of extra manual configurations and I need redi-service
> running for this.
that's fine, just don't fail with error when redis aint there.
--
che
On ചൊവ്വ 06 ഡിസംബര് 2016 02:45 വൈകു, Holger Levsen wrote:
> installations of a package must not fail in chroots with no services
> running.
>
> that's nothing new *at all* and >53k packages manage this nicely.
That is not an excuse to degrade the installation experience of gitlab.
It is like say
On Tue, Dec 06, 2016 at 02:04:19PM +0530, Pirate Praveen wrote:
> Its ironic that a software designed to test packages forces maintainers
> to not ensure the package is working correctly. A running redis-server
> is required to test gitlab is installed correctly and can use the redis
> server.
>
>
On തിങ്കള് 05 ഡിസംബര് 2016 02:48 വൈകു, Holger Levsen wrote:
> On Mon, Dec 05, 2016 at 01:52:44PM +0530, Pirate Praveen wrote:
>>> I do not buy that argument. piuparts failures are generally filed as RC
>>> bugs.
>
> there's a notable exception to this: "leaving files behind after
> purge"-bugs
On Mon, Dec 05, 2016 at 01:52:44PM +0530, Pirate Praveen wrote:
> > I do not buy that argument. piuparts failures are generally filed as RC
> > bugs.
there's a notable exception to this: "leaving files behind after
purge"-bugs and also "fails to purge"-bugs are only considered
important, even th
On തിങ്കള് 05 ഡിസംബര് 2016 01:16 വൈകു, Niels Thykier wrote:
> Pirate Praveen:
>> package: release.debian.org
>>
>> This version fixes many bugs in testing and the piuparts regression is
>> not introduced by this version (current version in testing has the exact
>> same problem with piuparts).
>
Pirate Praveen:
> package: release.debian.org
>
> This version fixes many bugs in testing and the piuparts regression is
> not introduced by this version (current version in testing has the exact
> same problem with piuparts).
According to piuparts.d.o, gitlab succeeds the test in testing.
> I w
package: release.debian.org
This version fixes many bugs in testing and the piuparts regression is
not introduced by this version (current version in testing has the exact
same problem with piuparts). I will fix the piuparts regression in a
future upload, but delaying the migration for this reason
27 matches
Mail list logo
