Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #10802 > unrolled thread

Best way to handle circular build deps to make a pypy- package

Back to article view | Back to linux.debian.maint.python

Contents

  Best way to handle circular build deps to make a pypy- package Pierre-Elliott Bécue <becue@crans.org> - 2018-08-15 13:10 +0200
    Re: Best way to handle circular build deps to make a pypy- package Ghislain Vaillant <ghisvail@gmail.com> - 2018-08-15 13:20 +0200
    Re: Best way to handle circular build deps to make a pypy- package Samuel Thibault <sthibault@debian.org> - 2018-08-15 13:20 +0200
      Re: Best way to handle circular build deps to make a pypy- package Pierre-Elliott Bécue <becue@crans.org> - 2018-08-15 15:20 +0200
        Re: Best way to handle circular build deps to make a pypy- package Pierre-Elliott Bécue <becue@crans.org> - 2018-08-15 15:50 +0200
          Re: Best way to handle circular build deps to make a pypy- package Samuel Thibault <sthibault@debian.org> - 2018-08-15 17:40 +0200
        Re: Best way to handle circular build deps to make a pypy- package Thomas Goirand <zigo@debian.org> - 2018-08-20 16:30 +0200
          Re: Best way to handle circular build deps to make a pypy- package Pierre-Elliott Bécue <becue@crans.org> - 2018-08-20 18:50 +0200

#10802 — Best way to handle circular build deps to make a pypy- package

[Multipart message — attachments visible in raw view] — view raw

Hi,

I was asked a long time ago to make a pypy package for nose2[1]. I realized
while considering this bug that I'd require to have a pypy package for mock
first. mock build-depends on unittest2 and pbr that are not pypy-packaged
either.

pbr is maintained in the OpenStack Team, but zigo is eager to help me should
I provide a sustainable MR. The thing is, pbr build-depends (indep) on
mock[3].

The way I see it, a solution is to:

 1. Build the pypy-pbr package without the testing phase (which seems to be
    the part where mock is required), and upload it.
 2. Build the pypy-mock package and upload it.
 3. Rebuild the pypy-pbr package with the testing phase and upload it.

But that doesn't satisfy me, because I guess sometimes I couldn't use this
subterfuge to build the packages.

So I have two questions :

 1. Are there other packages with the same circular build-dep thing, and if
    so, can someone provide me with examples?
 2. What's the proper way to handle such packages?

Thanks a lot!

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887933
[2] https://tracker.debian.org/media/packages/p/python-mock/control-2.0.0-3
[3] https://tracker.debian.org/media/packages/p/python-pbr/control-3.1.1-4

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.

[toc] | [next] | [standalone]

#10803

[Multipart message — attachments visible in raw view] — view raw

On Wed, 15 Aug 2018, 12:11 Samuel Thibault, <sthibault@debian.org> wrote:

> Pierre-Elliott Bécue, le mer. 15 août 2018 13:05:09 +0200, a ecrit:
> >  2. What's the proper way to handle such packages?
>
> Build profiles? You can annotate the build-dep needed for check with
> <!nocheck> so that one can easily (re)bootstrap the circle at any time
> by using DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -Pnocheck
>
> Samuel
>

I second this. Build profiles are the way to go. You can find plenty of
examples in codesearch.debian.net.

Ghis

>

[toc] | [prev] | [next] | [standalone]

#10805

Pierre-Elliott Bécue, le mer. 15 août 2018 13:05:09 +0200, a ecrit:
>  2. What's the proper way to handle such packages?

Build profiles? You can annotate the build-dep needed for check with
<!nocheck> so that one can easily (re)bootstrap the circle at any time
by using DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -Pnocheck

Samuel

[toc] | [prev] | [next] | [standalone]

#10806

[Multipart message — attachments visible in raw view] — view raw

Le mercredi 15 août 2018 à 13:10:39+0200, Samuel Thibault a écrit :
> Pierre-Elliott Bécue, le mer. 15 août 2018 13:05:09 +0200, a ecrit:
> >  2. What's the proper way to handle such packages?
> 
> Build profiles? You can annotate the build-dep needed for check with
> <!nocheck> so that one can easily (re)bootstrap the circle at any time
> by using DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -Pnocheck

Thanks, I'll dig the wiki pages and try this!

Cheers!

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.

[toc] | [prev] | [next] | [standalone]

#10807

[Multipart message — attachments visible in raw view] — view raw

Le mercredi 15 août 2018 à 15:11:25+0200, Pierre-Elliott Bécue a écrit :
> Le mercredi 15 août 2018 à 13:10:39+0200, Samuel Thibault a écrit :
> > Pierre-Elliott Bécue, le mer. 15 août 2018 13:05:09 +0200, a ecrit:
> > >  2. What's the proper way to handle such packages?
> > 
> > Build profiles? You can annotate the build-dep needed for check with
> > <!nocheck> so that one can easily (re)bootstrap the circle at any time
> > by using DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -Pnocheck
> 
> Thanks, I'll dig the wiki pages and try this!
> 
> Cheers!

Hi,

So I found a way to build locally, using your suggestions. In my case I
guess I could upload directly the output of the nocheck build as the bin
package isn't altered.

But how should I handle the upload in the archive in a general case? Let's
imagine my profile produces a different bin package, eg if foo -> bar (for
specific foo functionalities) -> foo, so with a stage1 foo, then a stage1
bar and then a stage2 foo, how should I proceed? Do all the builds locally
and upload the packages obtained from the last build?

On the other hand, let's assume one wants to do a sourceful upload, and not
upload the .deb files (I know this is not possible when one introduces a new
package in the archive), then the buildd farm couldn't succeed because the
nocheck wouldn't be taken into account. So this means profile builds
systematically require source + binary upload?

Maybe some of these questions may seem dumb, but I'd rather ask them than
upload shit to the archive. ^^

Thanks. :)

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.

[toc] | [prev] | [next] | [standalone]

#10808

Hello,

Pierre-Elliott Bécue, le mer. 15 août 2018 15:47:36 +0200, a ecrit:
> So I found a way to build locally, using your suggestions. In my case I
> guess I could upload directly the output of the nocheck build as the bin
> package isn't altered.

Yes, but better request a binnmu after the upload, to be sure.

> But how should I handle the upload in the archive in a general case? Let's
> imagine my profile produces a different bin package, eg if foo -> bar (for
> specific foo functionalities) -> foo, so with a stage1 foo, then a stage1
> bar and then a stage2 foo, how should I proceed? Do all the builds locally
> and upload the packages obtained from the last build?

AIUI it is usually preferred to upload as few manually-built packages as
possible, and thus you'd upload stage1 foo, let bar be built, and
request a binmu for stage2 foo.

> On the other hand, let's assume one wants to do a sourceful upload, and not
> upload the .deb files (I know this is not possible when one introduces a new
> package in the archive), then the buildd farm couldn't succeed because the
> nocheck wouldn't be taken into account. So this means profile builds
> systematically require source + binary upload?

If the profile-specific build really is needed, yes. In practice, once
the loop is broken it's not needed since you already have a stage1 bar
to build with and so you can just let builds happen. It's then only for
new archs that a bootstrap is needed (and keeping the profile available
for doing it is really useful for porters to just do it themselves).

Samuel

[toc] | [prev] | [next] | [standalone]

#10823

On 08/15/2018 03:11 PM, Pierre-Elliott Bécue wrote:
> Le mercredi 15 août 2018 à 13:10:39+0200, Samuel Thibault a écrit :
>> Pierre-Elliott Bécue, le mer. 15 août 2018 13:05:09 +0200, a ecrit:
>>>  2. What's the proper way to handle such packages?
>>
>> Build profiles? You can annotate the build-dep needed for check with
>> <!nocheck> so that one can easily (re)bootstrap the circle at any time
>> by using DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -Pnocheck
> 
> Thanks, I'll dig the wiki pages and try this!
> 
> Cheers!

Hi!

I have uploaded PBR 4.2.0-2 with lots of <!nocheck> in debian/control,
which includes removing mock if such build profile is activated.

I hope this helps,
Cheers,

Thomas Goirand (zigo)

[toc] | [prev] | [next] | [standalone]

#10825

[Multipart message — attachments visible in raw view] — view raw

Le lundi 20 août 2018 à 16:20:54+0200, Thomas Goirand a écrit :
> On 08/15/2018 03:11 PM, Pierre-Elliott Bécue wrote:
> > Le mercredi 15 août 2018 à 13:10:39+0200, Samuel Thibault a écrit :
> >> Pierre-Elliott Bécue, le mer. 15 août 2018 13:05:09 +0200, a ecrit:
> >>>  2. What's the proper way to handle such packages?
> >>
> >> Build profiles? You can annotate the build-dep needed for check with
> >> <!nocheck> so that one can easily (re)bootstrap the circle at any time
> >> by using DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -Pnocheck
> > 
> > Thanks, I'll dig the wiki pages and try this!
> > 
> > Cheers!
> 
> Hi!
> 
> I have uploaded PBR 4.2.0-2 with lots of <!nocheck> in debian/control,
> which includes removing mock if such build profile is activated.
> 
> I hope this helps,
> Cheers,

Hi,

Thanks!

Unfortunately I'll have to look into some deps of pbr that are not yet
pypy-packaged. But I'll find my way.

I'll start to work on this between mid and late September.

Thanks again and cheers!

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web