- openSUSE Build Service

[opensuse-buildservice] Building packages
by Aaron Bockover 18 Oct '06

18 Oct '06

Hello, I'm just getting into the build system, trying to set up Banshee. I have the "Banshee" project set up, and first tried to migrate my "libipoddevice" package from autobuild. I first tried to build locally using osc: osc build SLE_10 i586 libipoddevice.spec This started pulling down (slowly) SLE packages, but failed here: Error: No more mirrors to try. Failed to retrieve libstdc++-4.1.0-28.4.i586.rpm from the following locations (in order): file:///var/tmp/osbuild-packagecache/SUSE:SLE-10/standard/i586/libstdc ++-4.1.0-28.4.i586.rpm/ http://software.opensuse.org/download/SUSE:SLE-10/standard/i586/libstdc ++-4.1.0-28.4.i586.rpm http://api.opensuse.org/rpm/SUSE:SLE-10/standard/_repository/i586/libstdc++ I then committed libipoddevice to the "Banshee" project and clicked "Trigger Rebuild" in the web interface. It has been scheduled there for almost 4 hours I think. So my questions: a) Any reason why libstdc++ can't be pulled down? (would be nice if this were fixed) b) Why is it taking 4 hours to start building libipoddevice in the build service? What if it comes back failed after it's finally started to build - do I have to wait another 4 hours for my second try? This seems like an insane amount of time - and libipoddevice is a very simple package to build. I'm worried that when I actually get to Banshee itself, the process will take hours and hours and hours. c) Maybe there's something else I should be doing altogether? I'm completely new to the build service and am mostly just poking around, although at the same time I would very seriously like to host Banshee's builds inside the build service. I'm dead set on providing easy to use and updated packages for Banshee for SUSE/SLED at the same time I release my tarballs. Thanks in advance for the insight and response. Regards, Aaron Bockover --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

4 5

[opensuse-buildservice] Re: [RFC] Release numbers and the Kernel project
by Adrian Schröter 17 Oct '06

17 Oct '06

Am Sunday 15 October 2006 21:32 schrieb Andreas Gruenbacher: > On Sunday 15 October 2006 13:53, Jan Blunck wrote: > > Therefore my proposal for fixing this issue: a buildservice package link > > should inherit the release number from its source package. All changes > > inside the linked package (additional patches, files, ...) should be > > added to this release number. I would like to see a solution, which would work also without a special hack inside of the build system. The problem is currently caused by the fact that the retrigger of a source link does not work yet within the build service. This means, kernel-default does not yet triggered, when update kernel-source. It could be that this particular problem disappears by accident when this is fixed (since all packages do always get triggered and the release number get increased when changing the source. However, there is not guarantee that this will always work). For some rational behind this, usually you have the version number to tell, if a package got significant changes and is still compatible. This is different for the kernel. However, every release number change does already make it complete incompatible. I do not want to discuss this now, but we need to keep it in mind when we speak about this situation. Since this affects also the kmp module packages, I want to repeat the current state of discussion. Please correct me, if I am wrong ;) The kmp modules build could check against which kernel version+release they are building against (means, they do not use the version+release from their own spec file). This could be done via a "rpm -q kernel-source" call during the build. Pro: * This works also outside of any specific build system. * You can update the drivers and updated versions get also a higher release number. Contra: * you can not see anymore if all kmp packages do fit for the kernel via the version+release number. (but this information could be exported in a different way). > I don't understand what you mean exactly: do you mean that when there are > changes other than plainly linking the package, then the release number > should be <linked-to-package-release-number> + 1, and if there are no > changes, the package should keep the original > <linked-to-package-release-number>? > > I'm not sure that we want to hardwire the way how release numbers are > computed for linked packages; I could imagine that we sometimes want to use > the same release numbers for the linked-from and linked-to packages, and in > other cases we want to keep the release numbers independent. actually, the concept of hardwire release numbers do break the idea of having the guarantee that they get always increased in a proper way by the build system. So, I do see more problems introduced than solved by this ... > In the kernel case in particular, we need to associate each particular > check-in (i.e., each set of package sources) with a unique identifier; this > is sufficient so that all the packages will refer to the correct paths > in /usr/src/* and /lib/modules/*. Without it, building external kernel > modules would break. right, but IMHO you can find these pathes during the build also without to use the version/release number from the kernel flavor or kmp module spec file. > This unique identifier could be the release number as we do in Autobuild, > or it could be some sort of source release number: The build service > release numbers are of the form x.y, where x gets incremented per checkin, > and y gets incremented per build. We could the x part in the kernel. > > Beyond this necessary minimum requirement, it would be nice to fully > synchronize the release numbers (source and build), so that all the kernel > packages that "belong together" can easily be identified without having to > know that the ".y" part of the release number can be ignored for this > purpose. I'm not totally convinced that this is the best idea though; > keeping a build number has other benefits. We can ignore the .y part without any problem. However, you still have a problem when you hardwire the release numbers for the case, when you only edit a kernel flavour package (kernel-default for example). Currently this problem got hidden of the fact that also in this case all packages get rebuilded. But imaging what happens when this does change. You would get a newer package with the same version and release number .... -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian(a)suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

3 4

[opensuse-buildservice] Staled RPMs and Repositories
by Dominique Leuenberger 16 Oct '06

16 Oct '06

Hi, In my home directory, there are some Directories, that should be deleted (as well as outdated RPMs). - The directory for Debian_etch is empty and not used - The directory for SuSE Linux 10.0 is empty and not used - The directory for SuSE_Factory contains packages (same package, different versions?) Even though, the repository Factory is no longer activated in my home directory (I want to avoid the build of UFO:AI Data Package multiple times... so only one REPO active for the moment. Until I get fully known to OSC to enter the MetaData... btw: will this feature come also through the webinterface? That would be GREAT Thanks for 'cleaning up' and telling me how to avoid it in the future. Dominique

1 0

[opensuse-buildservice] Re: [RFC] Release numbers and the Kernel project
by Jan Blunck 16 Oct '06

16 Oct '06

On Sun, Oct 15, Andreas Gruenbacher wrote: > On Sunday 15 October 2006 13:53, Jan Blunck wrote: > > Therefore my proposal for fixing this issue: a buildservice package link > > should inherit the release number from its source package. All changes > > inside the linked package (additional patches, files, ...) should be added > > to this release number. > > I don't understand what you mean exactly: do you mean that when there are > changes other than plainly linking the package, then the release number > should be <linked-to-package-release-number> + 1, and if there are no > changes, the package should keep the original > <linked-to-package-release-number>? Correct. From talking to mls it seems that it is somehow a requirement that the linked packages have a higher release number if they have changes in. Therefore you can make sure that the package with the changes is installed if you have both available. > I'm not sure that we want to hardwire the way how release numbers are computed > for linked packages; I could imagine that we sometimes want to use the same > release numbers for the linked-from and linked-to packages, and in other > cases we want to keep the release numbers independent. Yes, but so far nobody came up with a usecase. > In the kernel case in particular, we need to associate each particular > check-in (i.e., each set of package sources) with a unique identifier; this > is sufficient so that all the packages will refer to the correct paths > in /usr/src/* and /lib/modules/*. Without it, building external kernel > modules would break. This is assured by increasing the release number of kernel-source package with every check-in. The internal pathnames of all packages refer to the release number of the kernel-dummy package. The problem I'm talking about are the external visible release numbers of the packages in the project. They differ although the packages are related to each other. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

1 0

[opensuse-buildservice] iChain switch succeeded :)
by Adrian Schröter 13 Oct '06

13 Oct '06

Hi, the build service now runs via iChain. This means that you need to use your bugzilla/www.opensuse.org password from now on. The command line users need also to update the osc tool to version 0.9 to get access to it again. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian(a)suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

5 11

[opensuse-buildservice] openSUSE build service goes iChain
by Adrian Schröter 12 Oct '06

12 Oct '06

Hi, we will switch tomorrow at 15:00 UTC the authentification system of the build service to iChain. This means that we will have some hickups around this time, esp until the DNS records have been updated. This does NOT mean that the build service will be open for everybody, but it does mean that you can use the same account/password as for the wiki also for the build service. We will also introduce https for the api, which means that you also need a new osc tool with the URL (or you can reconfigure it manually). bye adrian -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian(a)suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

2 4

[opensuse-buildservice] Can't update x86_64 from KDE3 build service repos
by David Jopson 12 Oct '06

12 Oct '06

Hi all, I was directed here to try and get help with a problem I encountered today. If this is the wrong place to ask for help, please let me know where I mgiht be able to go for assistance. I am using SuSE 10.0 x86_64 with KDE 3.5 updated from 3.4 via the build service. In the past I have been able to get updates using YaST without issue, but today when I tried to update to KDE 3.5.5 it wouldn't work and YaST wants to downgrade me to KDE 3.4.2 because of failed dependencies. The problem is YaST is only seeing the i586 rpms from the repo. Clicking on the "Versions" tab within YaST's Software Update window confirmed this fact. I have refreshed, deleted, and re-entered the build service repos in YaST several times but it just doesn't want to find the x86_64 rpms. Someone at suseforums.net suggested it may have something to do with the fact that /opt/kde3/share/apps/krpmview/media.1/products contains: / SuSE-Linux-user-i386 0.0.0 as opposed to something x86_64 related. I don't know how valid that idea is since I have had no problems updating in the past, but I am not an expert by any means. Does anyone have any ideas on how I might fix this problem? Thanks in advance, Dave --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

2 2

[opensuse-buildservice] adding maintainer
by Pavel Nemec 12 Oct '06

12 Oct '06

Hi, could some add me as maintainer to KDE:Community games:strategy:realtime nick: pnemec Thank you -- Pavel Nemec package-maintainer http://en.opensuse.org/Czech_Packagers_Team --------------------------------------------------------------------- SuSE CR, s.r.o. e-mail: pnemec(a)suse.cz Lihovarska 1060/12 tel:+420 2 9654 2373 190 00 Praha 9 fax:+420 2 9654 2374 Ceska republika http://www.suse.cz

3 3

[opensuse-buildservice] Directory Delete please
by Peter Nixon 11 Oct '06

11 Oct '06

Can one of the admins please delete the following directories as I am no longer targeting them: http://software.opensuse.org/download/server:/telephony/Fedora_Extras_4/ http://software.opensuse.org/download/server:/telephony/SUSE_Linux_9.3/ Thanks -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc

1 0

Re: [opensuse-buildservice] Another Build possible error...
by Cameron Seader 10 Oct '06

10 Oct '06

How can i debug this? On Mon, 2006-10-02 at 12:07 -0600, Cameron Seader wrote: > How can i fix this in my Build? > > On Fri, 2006-09-29 at 18:10 +0200, Andreas Jaeger wrote: > > > "Cameron Seader" <cseader(a)novell.com> writes: > > > > > Greetings, > > > > > > What do you make of this? > > > > > > objdump: /var/tmp/monopod-0.6-build/usr/lib/monopod/Monopod.exe: File format > > > is ambiguous > > > > > > objdump: Matching formats: efi-app-ia32 pei-i386 > > > objdump: /var/tmp/monopod-0.6-build/usr/lib/monopod/entagged-sharp.dll: File format is ambiguous > > > objdump: Matching formats: efi-app-ia32 pei-i386 > > > > > > Is this something to be concerned about? I have uploaded two different sources and i get the same thing, it used to build without these messages. > > > What are these messages telling me? > > > > > > -Cameron > > > > This is factory? > > > > Could be new binutils that break our mono tests, we might need > > --target=pei-i386 to the script that calculates the mono > > dependencies (if that's the place where it fails)... > > > > Andreas > > > > > > Novell, Inc. Software for the Open Enterprise™ http://www.novell.com

3 3