openSUSE Build Service March 2012

buildservice@lists.opensuse.org

72 participants
73 discussions

[opensuse-buildservice] mozilla:yasm - Broken signatures

by Claudio Freire

I was trying to update firefox on an old 11.1 installation. I found that the mozilla project in OBS contains 11.1, so I set it up and started updating. The "yasm" in that project is failing to install (only yasm), complaining about bad signatures. I did a full refresh to make sure I had the latest GPG keys (I had some expired ones), and it's still broken. Can someone trigger a rebuild please? (it might get fixed with a rebuild). -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

8 years, 10 months

[opensuse-buildservice] using build directly vs. post-build-checks

by Frank Lichtenheld

Hi. When building with OBS, not only the BuildRequires seem to get installed in the build chroot, but also the hardcoded Requires from the spec file. This is necessary for at least the post-build-checks to work correctly. When building with "build" directly (i.e. using build's internal expanddeps script to resolve BuildRequires), the Requires do not seem to get installed and so the post-build-checks fail. Would you consider that a bug? I.e. should the default behavior be changed to install Requires, too? Or should a new command line option be introduced to control the behavior? I'm happy to provide a patch for either solution. Or am I missing something completely and this should work already? Gruesse, Frank -- Frank Lichtenheld frank.lichtenheld(a)sophos.com | Lead Engineer Astaro GmbH & Co. KG - a Sophos company | www.astaro.com | www.sophos.com Phone +49-721-255-16-362 | Fax -200 | Mobile +49-174-1748211 Amalienbadstr. 41/ Bau 52 | 76227 Karlsruhe | Germany Astaro GmbH & Co. KG - a Sophos company, Commercial Register: Mannheim HRA 702710, Headquarter Location: Karlsruhe, Represented by the General Partner Astaro Verwaltungs GmbH Commercial Register: Mannheim HRB 708248 Amalienbadstr. 41/ Bau 52 | 76227 Karlsruhe | Germany Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

8 years, 10 months

[opensuse-buildservice] different packages installed in local build chroot than in OBS build

by Uwe Geuder

Hi! As already initially discussed on IRC I have observed that my local chroot build environments get different packages installed than the build environment on the OBS workers. I think the discussion there confirmed my assumption that the local chroot should have exactly the same contents as the build environment on the host[1]. Both OBS and my local environment are just chroot, no virtualization[2]. I have a hierarchy (<path> in buildinfo) of 4 projects, the "lowest" one has a project configuration. I'm using the highest one and there I see the difference in the build roots. The main properties are: - worker architecture is x86_64, same for my local machine - target architecture is arm, all execection uses binfmt_misc and qemu-arm-static The differences are related to some preinstalls. The preinstalls are defined in the project configuration of the "lowest" project, e. g. like this %if %speedbash Preinstall: bash-x86-arm ncurses-libs-x86-arm Runscripts: bash-x86-arm %endif (This is just one example, there are several similar cases in the whole project config) This configuration is copied correctly into .osc/_buildconfig... when I run osc build. However, it appears that on the OBS the %speedbash macro is true (resulting in some x86 preinstalls), in my local builds it must be false (these preinstalls are missing). So I end up with different preinstalls locally than remote. The %speedbash macro depends on other %if macros, but in the beginning of the chain some macro must just be initialized differently on the worker host than locally. How can I find out where these macros are actually intialized and where the difference comes from? When looking at http://en.opensuse.org/openSUSE:Build_Service_prjconf, I read: > The prjconf denotes the (build) configuration of a project. The main > part of this file (/usr/lib/build/configs/$distro.conf) is the > definition of the build environment So do these conf files actually play a role in the initialization of the macros? If yes, is it the one on the host or the one in the chroot? I don't really understand how that should work: We are talking about the initialization of the chroot, so I can't see how the conf files from inside the chroot could be used, because they are not there yet when we need to decide our preinstalls. But on the other side if the ones of the host are used, the host could influence the contents of the chroot, contradicting the purpose of the chroot being a well-defined isolated build envoironment. Any explanations to solve this knot are welcome. Or are these conf files for the "second" kind of macros only, which are used by rpmbuild, not those used in the prjconf? Any hints to trace down were the difference is created? I have already tried to debug osc a bit, but at least so far I have not found any place where these macros are handled. When I execute "osc build", is the difference likely to be caused already on the OBS (I don't have any access to the installation than a normal user account) and included e.g. in the buildinfo sent from the OBS to my local build or does the relevant processing happen first locally in my own machine (where I could debug it)? Regards, Uwe Geuder Nomovok Ltd. Tampere, Finland uwe.gxuder@xxxxxxxxxxx (bot check: humans correct 1 obvious spelling error) [1] As far as installed packages are concerned. Of course there will be other differences like the kernel, the amount of memory and a million other parameters that could cause nasty problems if things go really wrong. [2] chroot in OBS is a security risk. This is a private OBS instance in a closed intranet with only "trusted" users. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

8 years, 10 months

[opensuse-buildservice] Debootstrap as a replacement of debian chroot creation in obs

by Helio Chissini de Castro

Hi Since we're starting to experiment full OBS build of a debian derivative distro, we detected some faults in the chroot creation related sometimes to scripting and post script runs as order of package install too. So, for our personal test, we decided to replace the internal parts related to dpkg in init_buildsystem ( obs-build ), for a single one common solution to debian and ubuntu, which is debootstrap. First difficulty i found was the lack of debian tools in RPM distros, rendering workers unnefective, so i made a proper rpm for debootstrap, debhelper, autotools-dev and apt ( which i called apt-debian ) to both Fedora and openSUSE. openSUSE need less tools than Fedora, since have package deb which contains dpkg + debhelper. Having this, i was able to replace many parts of init_buildsystem script for two steps: - Generate a proper debian repos locally using apt-ftparchive - Execute debootstrap First step uses an script, that now is limited to test i386 and armhf for our purposes Second uses the buildd option of debootsrap, looking in local already downloaded packages. We already are using it as default in our internal OBS and so far so good, the process shown some progress. It's working in both deb and rpm workers I'm open to opinions, ideas of how far we can go, improve the script and if maybe we can adapt this to upstream in future. You can see the branch of obs-build here: https://github.com/heliocastro/obs-build And all packages in my home:heliochissini on build.opensuse.org https://build.opensuse.org/project/show?project=home%3Aheliochissini []'s -- Helio Chissini de Castro Collabora -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

8 years, 10 months

[opensuse-buildservice] How do I unmark packages as a devel project?

by Dave Plater

After continually getting multimedia packages that I was working on in home:plater, messed up by other submissions I had the bright idea to make the package the devel project of the multimedia:libs package. Unfortunately I can't delete or "undevel" the package and with my current situation I'm not on line enough to manage this either. The problem I attempted to address is a real problem though, there should be a way for a maintainer to lock the package that he's working on, especially before release when there's a lot of activity. Dave -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

8 years, 10 months

[opensuse-buildservice] add GIT as possible value for URL in spec file

by Tomas Cech

Hi, I'm using GIT protocol in URL in spec files and I have always warning like this one: evas.x86_64: W: invalid-url URL git://git.enlightenment.org/git/e.git I'd be glad if GIT would be one of correct protocols. What is your opinion here? I'm aware that Enlightenment has it's web page in this case. Thanks Tomas Cech Sleep_Walker

8 years, 10 months

[opensuse-buildservice] RedHat:RHEL-4 => DISCONTINUED:

by Adrian Schröter

JFYI, RHEL 4 is out of maintenance. So I copied to the DISCONTINUED: area and will remove the RedHat:RHEL-4 plus all repositories still building against it in the next days. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian(a)suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

8 years, 10 months

[opensuse-buildservice] where to submit packages for the bug fix update

by Togan Muftuoglu

hi I'm trying to maintain a package which I have branched using osc mbranch once I fix the issue which project do I send the submitrequest ie in my case the package to be fixed is for openSUSE 12.1 according to <http://en.opensuse.org/openSUSE:Package_maintenance#Submit_your_changes> I should osc sr openSUSE:12.1:Update:Test not being sure I did via webui and it submitted to openSUSE:Maintenance which for some reason doesn't feel right Thanks Togan -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

8 years, 10 months

[opensuse-buildservice] Cross compilation dependency handling

by Carsten Munk

Hi, One of the discussion points about my SB2-OBS patch is that we ought to work towards a common strategy for denoting these special kind of dependencies in prjconf instead of using "SB2install" "CBinstall" etc. Daniel Gollub suggested that we work with N amount of 'sysroots' and N rpm databases and I tend to agree. Right now in SB2 I distinguish between host (/) and target /target, but it might be more flexible to do with N targets instead. The question is of course, can we effectively work with multiple dependency trees (maybe even across schedulers?) within the current code and how do we do it best? Adrian suggested something like Preinstall($hostarch) to indicate that this needs to be preinstalled on host architecture. My suggestion would be perhaps to indicate through configuration where to put things, for example, Roots: host=/ armv7l=/opt/cross/armv7l, etc, so we can do dynamic labeling and telling what location on the build filesystem things should go in. What are your thoughts? BR Carsten Munk -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

8 years, 10 months

[opensuse-buildservice] Reworking the software search page

by Thomas Schmidt

As part of the current boosters sprint[1] which aims at integrating the appstream[2] project into our distribution we would like to enhance the web view on our packages at software.o.o/search. With the final target of an web-based appstore we began thinking of how to display a package (app) to the user. The challenge is to make available the matrix of different OS versions, repositories and package versions in a clear way while making it easy for the standard user to get the latest stable version for his OS without getting confused. We already have a mockup available: http://dl.dropbox.com/u/294274/software.o.o/package-view.png Feedback appreciated :-) Greetings [1] https://trello.com/board/appstream/4f156e1c9ce0824a2e1b8831 [2] http://distributions.freedesktop.org/wiki/AppStream -- Thomas Schmidt (tom [at] opensuse.org) openSUSE Boosters Team "Don't Panic", Douglas Adams (11.03.1952 - 11.05.2001) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

8 years, 10 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openSUSE Build Service March 2012