On Thu, May 8, 2008 at 2:32 PM, Cristian Rodríguez wrote:

...

Random other question: what does a build status of "blocked" mean? (in this case, blocked by perl-ExtUtils-CBuilder)

perl-ExtUtils-CBuilder or its dependencies are being rebuilt, that 's reason why your package is blocked.

Hmm... it's been blocked for over three hours. Is that normal? Thanks, -Archie -- Archie L. Cobbs --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Thu, May 8, 2008 at 4:11 PM, Cristian Rodríguez wrote:

...

Hmm... it's been blocked for over three hours. Is that normal?

Usually Yes, it may take till monday heh ;P

I don't get it. Are you saying that the perl-ExtUtils-CBuilder build is really taking several hours to build, or are you saying the perl-ExtUtils-CBuilder build is broken and waiting for a human to fix it? In either case, I don't think my module (and lots of others) should be held up... My module has an outstanding change from me that I'm waiting on to build. The OBS should go ahead and rebuild my module using the prior version of perl-ExtUtils-CBuilder. Then when perl-ExtUtils-CBuilder finishes, it can do another rebuild if it wants to. In other words, I think the behavior should be: * Don't trigger my build until *successful completion* of a new version of perl-ExtUtils-CBuilder. * If the current version of perl-ExtUtils-CBuilder is broken, my build should use the previous (successfully built) version. Does this make sense? -Archie P.S. still wondering answer to original question about network:telephony also -- Archie L. Cobbs --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Friday 09 May 2008 01:11:23 wrote Cristian Rodríguez:

Archie Cobbs escribió: ...

...

In other words, I think the behavior should be:

* Don't trigger my build until *successful completion* of a new version of perl-ExtUtils-CBuilder.

Yes, and that is what the OBS does, AFAIK.

yes, this is was the "blocked" state means.

...

* If the current version of perl-ExtUtils-CBuilder is broken, my build should use the previous (successfully built) version.

Unless there is no previuos perl-ExtUtils-CBuilder in your repo or in the distro in which case an expansion error should thrown..

if perl-ExtUtils-CBuilder did not build in the project below, you will still get the one from the former build. It does not get removed on build failure. -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Fri, May 9, 2008 at 12:30 AM, Adrian Schröter wrote:

...

My module has an outstanding change from me that I'm waiting on to build. The OBS should go ahead and rebuild my module using the prior version of perl-ExtUtils-CBuilder. Then when perl-ExtUtils-CBuilder finishes, it can do another rebuild if it wants to.

We speak here about packages for openSUSE Factory and not building for any frozen distro like openSUSE 10.3, Fedora or alike, right ?

No, I don't think so (but I'm also still trying to figure this all out). Anyway here is what I have in my project metadata: <repository name="openSUSE_10.3"> <path repository="standard" project="openSUSE:10.3"/> <path repository="openSUSE_10.3" project="OSSP"/> <path repository="openSUSE_10.3" project="devel:languages:perl"/> <arch>i586</arch> <arch>x86_64</arch> </repository>

If you want to build anything _NOW_ it is recommended to do a local build. You can do so easily via the "osc build" command. It is anyway recommended to prepare a new package via that, because you do not have to wait to resetup the build enviroment for each try (and yes, you can build for Fedora on SUSE for example).

Yes I could do that, but I wanted to give someone the URL to the package on the OBS instead of emailing them a huge file.... and anyway, we're discussing the general behavior of OBS, not only a workaround for this particular situation.

...

In other words, I think the behavior should be:

* Don't trigger my build until *successful completion* of a new version of perl-ExtUtils-CBuilder. * If the current version of perl-ExtUtils-CBuilder is broken, my build should use the previous (successfully built) version.

this is the current situation, if I understand you right.

I don't think it is... if it was, then my package would start building as soon as I commit a change. I'll try to explain my question more precisely. Consider this sequence of events: 1. Package A requires package B from another repo 2. Package A successfully builds with package B, and everything is great 3. Package B is changed, and for whatever reason the build of package B is blocked for a long time 4. Package A is changed My question is: shouldn't package A's build proceed anyway, with the same version of B that was used in step #2? This is what I would expect as step #5: 5. Package A is built with the same version of package B used in step #2 Then many hours later after everyone has gone to sleep: 6. Package B's new build finally successfully completes 7. Package A's build is automatically triggered and it is built again with the version of package B from step #6 -Archie -- Archie L. Cobbs --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Fri, May 9, 2008 at 11:53 AM, Cristian Rodríguez wrote:

...

Then many hours later after everyone has gone to sleep:

There is no such thing "everyone has gone to sleep", this is a 24/7 community, with people worldwide.

I'm sorry if that came across wrong. I meant "everyone in my house". -Archie -- Archie L. Cobbs --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Fri, May 9, 2008 at 1:50 PM, Dirk Stoecker wrote:

...

1. Package A requires package B from another repo 2. Package A successfully builds with package B, and everything is great 3. Package B is changed, and for whatever reason the build of package B is blocked for a long time 4. Package A is changed

My question is: shouldn't package A's build proceed anyway, with the same version of B that was used in step #2? This is what I would expect as step #5:

5. Package A is built with the same version of package B used in step #2

Then many hours later after everyone has gone to sleep:

6. Package B's new build finally successfully completes 7. Package A's build is automatically triggered and it is built again with the version of package B from step #6

You are right, that it is disturbing to wait for these long blocking packages, but:

...

b) When you use osc build to do a local build test, then in most cases letting it take a day to build a package is no problem, as you checkin a working package instead of building the package on server.

Are you saying that I can build the RPM locally, and then upload it into the OBS repository? If so, that's cool, I was not aware of that option (how do you do it?)

Nevertheless I'm pretty convinced there are still situations, where blocked state is wrong, especially with aggregates.

Do you consider the situation I described as one of those? FYI, I'm asking not to be annoying but because I'm trying to understand the OBS and how it works (as someone who understands RPMs but is new to OBS, for some reason I've had a hard time understanding how things work and what all the various parts are and how they interact. I really wish there was a "reference manual" or something). E.g.: this "blocked" state seems inappropriate to me, but that's probably because I don't understand something.... if so, who can explain the logic of why it is necessary in this case (instead of just saying "don't worry about it" or suggesting a workaround). Thanks, -Archie -- Archie L. Cobbs --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Archie Cobbs napsal(a):

On Fri, May 9, 2008 at 12:30 AM, Adrian Schröter wrote: My question is: shouldn't package A's build proceed anyway, with the same version of B that was used in step #2? This is what I would expect as step #5:

5. Package A is built with the same version of package B used in step #2

Then many hours later after everyone has gone to sleep:

6. Package B's new build finally successfully completes 7. Package A's build is automatically triggered and it is built again with the version of package B from step #6

This would indeed make the buildservice experience more interactive for single package builds, BUT at the cost of wasted build power. You can imagine that people wanting to build _many_ packages (think of a new KDE release) in _reasonable_ time wouldn't be all that happy about build hosts occupied by "interactive" rebuilds, which are going to be obsoleted by a regular rebuild an hour later... If you want to test your new package, 'osc build' is the preferred method. It also allows you to debug in the build chroot, which is not possible in the build service. Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On 2008-05-10 20:48:15 -0500, Archie Cobbs wrote:

Now, if I may repeat the original question... any thoughts on this?

...

Ref: bug #383944

I've created a new RPM for voiceglue (http://www.voiceglue.org/) in my home project.

https://build.opensuse.org/package/show?package=voiceglue&project=home%3Aarchie172

What do I need to do to get this moved to network:telephony?

Also, what is the process for me updating the spec file when new versions come out? Will I (need to) be a member of the network:telephony project?

i copied the package over and you should have permissions to edit it there. but i got a few remarks: 1. in your spec: 129 rm -rf %{_var}/lib/openvxi-3.4 130 rm -rf %{_var}/lib/asterisk/sounds/voiceglue are you sure you can delete those directories in any case? 2. i removed the publish enable for 10.3 from the package meta. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Archie Cobbs napsal(a):

On Tue, May 13, 2008 at 8:54 AM, Marcus Rueckert wrote:

...

1. in your spec: 129 rm -rf %{_var}/lib/openvxi-3.4 130 rm -rf %{_var}/lib/asterisk/sounds/voiceglue

are you sure you can delete those directories in any case?

I'm OK either way. Those files are all generated at runtime and they consist mainly of cached state, audio files, etc. AFAIK. So this decision is a trade-off between RPM removal cleanliness vs. throwing away information that might be useful at a later time if the RPM were reinstalled.

What is the usual policy in this situation?

I would keep it, an uninstall should be undoable by an install IMO. Also, checking for $1 = 0 will hit you should you ever rename the package: rpm will run the %postun of the old package with 0, because after the installation, there will be zero 'voiceglue' packages and one voiceglue-ng or whatever. Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org