openSUSE Build Service September 2011

buildservice@lists.opensuse.org

61 participants
74 discussions

Re: [opensuse-buildservice] Re: backup of OBS

by Malcolm

On Sun, 18 Sep 2011 07:15:27 +0300 Damian Ivanov <damianatorrpm(a)gmail.com> wrote: > A shame I know, > I only use web client. > > Hi > > Don't you use osc to build etc locally? > > Hi This is an easy way to sync the files locally, even though you might prefer the web client; osc co <project_name> Will bring down all the packages. You should look at using the command line, it's quicker for checking fixes etc and if OBS goes down you can just work in offline mode and carry on. Plus it take the load of the servers... -- Cheers Malcolm °¿° (Linux Counter #276890) openSUSE 11.4 (x86_64) Kernel 2.6.37.6-0.7-desktop up 5 days 7:48, 6 users, load average: 0.21, 0.16, 0.16 GPU GeForce 8600 GTS Silent - Driver Version: 280.13 -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

9 years, 4 months

[opensuse-buildservice] help needed: building debian packages

by Mathias Homann

Hi there, I need some help with debian packages... The documentation on the wiki is not exactly complete or up-to-date... Anyone willing to help me make a deb package of home:lemmy04:snowglobe/dolphinviewer3 happen? bye, MH -- gpg key fingerprint: 5F64 4C92 9B77 DE37 D184 C5F9 B013 44E7 27BD 763C () ascii ribbon campaign against HTML e-mail /\ www.asciiribbon.org -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

9 years, 4 months

[opensuse-buildservice] Building KMP packages

by Ciro Iriarte

Hi, I'm experimenting with kmp packages, the thing is that if the version don't match exactly the version of the kernel I can't load them... Current kernel installs modules in /lib/modules/2.6.32.45-0.3-pae, but my OBS generated kmp puts them in /lib/modules/2.6.32.45-1-pae/updates. In that situation, modprobe fails with "ERROR: modinfo: could not find module <name>". I tought kmp could handle minor version changes in kernel, although in this case I've built the kmp with that exact same target kernel, OBS is the one changing the release numbers.. Any advices? -- Ciro Iriarte http://cyruspy.wordpress.com -- -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

9 years, 4 months

[opensuse-buildservice] "osc build" GPG key can't be verified.

by Troy Telford

I'm having trouble using 'osc build' on my own OBS instance: $ osc build Building htop.spec for SLE_11sp1/x86_64 Getting buildinfo from server and store to /home/ttelford/src/obs/home:ttelford/htop/.osc/_buildinfo-SLE_11sp1-x86_64.xml Getting buildconfig from server and store to /home/ttelford/src/obs/home:ttelford/htop/.osc/_buildconfig-SLE_11sp1-x86_64 Updating cache of required packages 0.0% cache miss. 88/88 dependencies cached. Verifying integrity of cached packages BuildService API error: can't verify packages due to lack of GPG keys Obviously, I'd like to be able to verify the packages; the distribution packages certainly have a GPG signature (That of SLES). I know the GPG key is on ${SLES_ISO}/pubring.gpg. So what I need to do to get 'osc build' to work (and verify the GPG signature of the packages)? Thanks. -- Troy Telford -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

9 years, 4 months

[opensuse-buildservice] Slow http performance

by Jeff_Glanz＠Dell.com

Greetings: We are using osc, version 131, to download binary files from a build repo (osc getbinaries). We are noticing 2x performance differences in download speeds on different OBS2.1 service hosts. The disk io speeds & bit transfer rates to storage are exactly the same on both hosts (verified with dd calls). The osc download requests are to local host services. On the slow performer, I see ruby trace calls referencing '_session' variables, as well as a 'Cookie' reference. We don't see this problem on an old OBS1.6 installation. We thought disabling ssl checks (sslcertck=0) would speed up the transfer - but this makes no difference. Here's the html header: send: 'GET /build/Project:700: Builder_2/rhel5/i586/......4.1.el5.i386.rpm HTTP/1.1\r\nAccept-Encoding: identity\r\nHost: obs-......com\r\nCookie: opensuse_webclient_session=0blongkey; _frontend_session=BAlongkey--65bblongkey\r\nConnection: close\r\nUser-Agent: osc/0.131\r\n\r\n' The traceroute calls all have a single hop to the local host. We are using ssl encryption. Any ideas as to how we might tune this - or what could be causing these differences in download speed? Thanks. Jeff Glanz Dell | PG Release Engineering Team office + 1 512 724 9509 -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

9 years, 4 months

[opensuse-buildservice] using custom variables with tar_scm

by Togan Muftuoglu

Hi, Is there a way to store the output of various commands ie "hg log" "hg parents" in a variable when using service files like tar_scm or set_version Thanks -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

9 years, 4 months

[opensuse-buildservice] package search for certain distros

by Ruediger Meier

Hi, I'am trying to solve BuildRequires for different distros but for some of them I can never find any packages. For example this is never succesful: $ osc search -s -B RHEL-6 ... and this never finds RHEL-6 packages: $ osc search -s ... Also I'am not sure what packages I could expect for RHEL-6. For example libedit-devel should be there, see http://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/ or http://ftp.scientificlinux.org/linux/scientific/6.0/i386/os/Packages/ but obs says: unresolvable: nothing provides libedit-devel cu, Rudi -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

9 years, 4 months

[opensuse-buildservice] How do I revert a SR I inadvertently applied

by Greg Freemyer

All, I'm a maintainer for security/sleuthkit. I need to revert SR 81940. How do I do that? Greg -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

9 years, 4 months

[opensuse-buildservice] missing fedora 15 packages.

by Paul Elliott

Why is it that obs can not find "htmldoc" for fedora 15: http://software.opensuse.org/search?q=htmldoc&baseproject=Fedora%3A15&lang=… but rpm search from pbone finds some: http://rpm.pbone.net/index.php3/stat/3/srodzaj/2/search/htmldoc-1.8.27-15.f… I was aware that RH was playing some games with source, but I thought the practice was limited to EPEL. Thank You. -- Paul Elliott 1(512)837-1096 pelliott(a)BlackPatchPanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117

9 years, 4 months

[opensuse-buildservice] Thoughts about using test driven development for my gsoc project

by Marcus Hüwe

Hi, as you might know I participated in the GSoC this year. When the coding period started my mentors and I decided to use the "test driven development" (TDD) approach to develop the python obs library. In the following I'll summarize why I think using this approach was a good idea and how it helped me to write the code. * It helps with designing a class interface With TDD you usually write the testcases _before_ the actual code. When doing so you already get a feeling if the design of the interface or method is practical because you use the interface multiple times in your testcases. Example: One of the first coding tasks was to write a class for managing (editing, saving etc.) project/package xml metadata. For instance a common use case is to add a new repository the project's metadata so I wrote a testcase for it. The first version looked something like this: prj = RemoteProject('foobar') repo = prj.add_element('repository', name='openSUSE_11.4') repo.add_element('arch', 'x86_64') repo.add_element('path', project='openSUSE:11.4', repository='standard') I think this doesn't really look pythonic (but of course this is just a matter of taste) so finally I ended up with the following: prj = RemoteProject('foobar') repo = prj.add_repository(name='openSUSE_11.4') repo.add_arch('x86_64') repo.add_path(project='openSUSE:11.4', repository='standard') (of course the add_* methods aren't statically coded in the RemoteProject's class – instead we use a "ElementFactory" which is returned by an overridden __getattr__ (for the details have a look at the code:) )) Without TDD I probably would have implemented the first version and afterwards I had realized that I didn’t like it... * It helps structuring the code Let's consider some "bigger" method which needs quite some logic like the wc.package.Package class' update method (the update method is used to update an osc package working copy). Before writing the testcases I started to think about how the update method can be structured and what parts can reside in its own (private) method (probably a natural thing which has nothing to do with TDD). I ended with the following rough layout: o calculate updateinfo: a method which calculates which files have to be updated (in particalur it returns an object which encapsulates newly added filenames, deleted filenames, modified filenames, unchanged filenames etc.) o perform merges: a method which merges the updated remote file with the local file o perform adds: simply adds the new files to the working copy o perform deletes: deletes local files which don’t exist anymore in the remote repo Then I started to write some testcases for the calculate_updateinfo method and implemented it. Next I wrote testcases for the various different update scenarios and implemented the methods and so on. It is probably much easier to write testcases for many small methods than for a few "big" methods. From time to time I realized that I forgot to test some "special cases", so I added a new testcase, fixed the code and ran the testsuite again. The cool thing is if the testsuite succeeds (that is the fix doesn’t break any of the existing testcases + the newly added testcase succeeds) one gains confidence that the fix was "correct". * It speeds up the actual coding My overall impression is that TDD “speeds” up the actual coding a bit. While writing the testcases I also thought how it could be implemented. So when all testcases were done I had rough blueprint of the method in my mind and "just" transformed it into code. For instance it didn’t take much time to write the initial version of calculate_updateinfo method. But of course this doesn’t work for all methods. Stuff like the Package class' update method took quite some time (and thinking!) even though I already wrote some testcases. The main reason was the fact that the update should be implemented as a single "transaction" (the goal was that the working copy isn't corrupted if the update was interrupted). As you can see TDD is no black magic approach which makes everything easier – thinking is still required:) * It helps to avoid useless/unused code paths I just wrote the code to comply with the existing testcases – no other (optional) features were added. Sometimes I realized that some feature was missing. In this case I added another testcase and implemented the missing feature. So the rule was whenever a new feature was required a testcase had to exist (either a testcase which directly tests the modified method or a testcase which tests a method which implicitly calls the modified method). * It helps to overcome one's weaker self From time to time I had to write some trivial class or method where I thought it isn’t worth the effort to write testcases for it. A perfectly prominent example was the wc.package.UnifiedDiff class (it's only purpose is to do a "svn diff"-like file diff). At the beginning I wanted to start coding without writing testcases because I thought it's enough to test its base class (that’s the place were the interesting things happen and the rest is just "presentation/visualization"). Luckily I abandoned this idea and wrote the testcases. It turned out that it was a good idea because this "trivial" visualization I had in mind was more complicated than I initially thought;) What I learned from this example is that it is most likely better to write testcases because the class/method might evolve and might get more complicated. Finally here's a small statistic about osc2's current code coverage (generated with python-nose's nosetest): Name Stmts Miss Cover --------------------------------------- osc 1 0 100% osc.build 79 4 95% osc.core 19 2 89% osc.httprequest 180 19 89% osc.oscargs 145 1 99% osc.remote 278 11 96% osc.source 68 2 97% osc.util 1 0 100% osc.util.io 85 8 91% osc.util.xml 23 0 100% osc.wc 1 0 100% osc.wc.base 173 20 88% osc.wc.convert 71 6 92% osc.wc.package 792 39 95% osc.wc.project 397 20 95% osc.wc.util 387 28 93% (line numbers and non osc2 modules are removed) As a conclusion I would say that using the TDD approach was a good idea and helped a lot. So you might want to give it a try too – it probably won't harm:) Last but not least I want to thank my mentors Sascha Peilicke and Marcus 'darix' Rueckert for their time and tremendous help (meetings, suggestions, interesting links etc.) during the GSoC. Thanks! Marcus -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

9 years, 4 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openSUSE Build Service September 2011