February 2009 - openSUSE Build Service

[opensuse-buildservice] rpmlint and "Packager"
by Dirk Stöcker 23 May '09

23 May '09

Hello, whether I add "Packager" in a spec file or not, rpmlint complains in both cases. One time because of hardcoding. The other time because it is missing. Could this please be fixed? What I would like to see is that the buildservice-email-address also used in the GPG key of the repository is automatically copied into the spec (like e.g. changelog or revision). Is this possible (thought that would not fix the hardcoding error message) or can the name+email be added in the build command directly? Ciao -- http://www.dstoecker.eu/ (PGP key available) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

4 7

[opensuse-buildservice] Problems with files added by remote URI
by Michael Behrisch 26 Mar '09

26 Mar '09

Hello, I tried to compile the fox1.4 package for ubuntu and wanted to add the sources directly from the debian server http://packages.debian.org/etch/libfox1.4 Unfortunately when adding the files by URL to my obs package (like http://ftp.de.debian.org/debian/pool/main/f/fox1.4/fox1.4_1.4.34.orig.tar.gz) something went wrong, because the build process fails: dpkg-source: error: file fox1.4_1.4.34.orig.tar.gz has md5sum 724e66b89b5451d5032165e03ff5228d instead of expected 3424b9d3f9b71e1f53e9c3822de3b76c I checked this by downloading the file once from the debian site and once from the obs and they have different checksums indeed. The sizes are the same thus it is probably not a matter of automatic gz extraction. The diff.gz of the same package has the same problem, that's why I think there might be something wrong with the remote upload. Has anyone else encountered this problem? Is there a known workaround besides down-/uploading? Regards, Michael -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

9 18

[opensuse-buildservice] History of _link'ed projects?
by Lars Marowsky-Bree 24 Mar '09

24 Mar '09

Hi, I wanted to generate the changes of project which links to another. But iterate through the history with osc -r fails; it generates only the diff. -e doesn't work in combination with -r. It seems the link is not generated against a specific version of the source project, and so that information is not archived, and osc doesn't know which version of the source project to retrieve. That strikes me as rather bad, because it means bi-secting for _link projects essentially doesn't work at all right now. Would it not be acceptable if osc -r -e expanded the link against the version of the source project which was current at that time? (After all, that's what it would have build against.) Of course, this would miss rebuilds/changes which were triggered because of changes in the source project, as there's no combined history. Any idea how to solve this? Regards, Lars -- Teamlead Kernel, SuSE Labs, Research and Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

4 3

[opensuse-buildservice] inject local rpm data for buildinfo calculation
by Marcus Hüwe 19 Mar '09

19 Mar '09

Hi, I wrote a small patch to inject rpm/deb/whatever data to the buildinfo calculation. This means one can collect the rpm/deb provides and requires of local packages and send them to the obs which uses them to calculate the buildinfo for local builds. Usecase: * you submitted a new package to the obs: before you can build a local package which depends on this new package you have to wait until the obs has built it (now you could simply do sth. like "osc build ... -p /path/to/local/pkgs" and it'll directly start the local build). How it works: A client like osc collects the requires and provides of some local packages, stores these information in a xml file and finally creates a cpio archive which contains the xml + a spec/dsc file and sends it to the obs. (Note: I decided to store the data in a xml because I didn't want to introduce yet another metadata format - this results in less additional code) Example xml: <localdeps> <package name="foobar" version="3.0.1" release="0" arch="i586"> <provides>foobar = 3.0.1-0</provides> <requires>glibc</requires> <requires>libfoo-devel >= 2.0</requires> </package> ... </localdeps> Any feedback, corrections etc. are welcome:) If there are no objections I'll commit it within the next few days. Marcus

5 13

Re: [opensuse-buildservice] debian transformer problems on xUbuntu 8.10
by Martin Mohring 17 Mar '09

17 Mar '09

Amilcar do Carmo Lucas wrote: >> Amilcar do Carmo Lucas wrote: >> >>> On Thursday 08 January 2009 09:41:42 Carsten Hoeger wrote: >>> >>> >>>> Did that ever work? I wasn't able to use tar.bz2 on Ubuntu 6.06 AFAIR. >>>> >>>> >>> yes, .tar.bz2 works fine for 6.06, 7.04, 8.04. >>> >>> It would be nice if you fix this regression. >>> >>> >> I got on the other hand the answer from some ubuntu packagers that >> .tar.bz2 will not be accepted by the public build instances for debia or >> ubuntu, so it has a good reason that dpkg-source is crying about not >> allowed .tar.bz2. I switced back to .tar.gz for my combi .deb and .rpm >> packages though. >> >> What I say is valid for at least: >> - Debian Lenny, Sid >> - Ubuntu: 7.10, 8.04, 8.10, 9.04 >> >> > As far as I know the build service automatically repackages the .tar.bz2 > that I give into a .tar.gz file before the build. Like I said AFAIK it > does that for all debs except 8.10. > So I'm waiting that the openSUSE people fix this bug. > I think it does not repackage the sources from .tar.bz2 into .tar.gz. What filenames would you like to use in this case, what should be stated in the .dsc then? Lets do that on an example multiplatform .deb and .spec based package. The source file is called hallo.tar.bz2. The .spec files references then hallo.tar.bz2, this is easy. On the other hand, the .dsc file references then hallo.tar.gz, a file that does not exist, only to circumvent some dpkg-source consistency checks which are there for a good reason? This is not a good solution, because not transparent. Why not fulfil the Debian/Ubuntu and the Fedora/... whatever packaging requirements? -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

3 2

[opensuse-buildservice] Colons considered harmful: escaping LD_LIBRARY_PATH in OBS projects
by Brandon Philips 09 Mar '09

09 Mar '09

Hello All- The problem can be illustrated by trying this out: osc co openSUSE:Factory attr cd openSUSE:Factory/attr quilt setup attr.spec cd attr-2.4.39/ ./configure make strace getfattr/getfattr / Here is a snip from that strace: open("/home/philips/projects/openSUSE/x86_64/libattr.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) stat("/home/philips/projects/openSUSE/x86_64", 0x7ffffec11540) = -1 ENOENT (No such file or directory) open("/home/philips/projects/openSUSE/libattr.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) stat("/home/philips/projects/openSUSE", 0x7ffffec11540) = -1 ENOENT (No such file or directory) open("Factory/attr/attr-2.4.39/libattr/.libs/tls/x86_64/libattr.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("Factory/attr/attr-2.4.39/libattr/.libs/tls/libattr.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("Factory/attr/attr-2.4.39/libattr/.libs/x86_64/libattr.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) Not ideal! The process is trying to load obviously non-existent libraries. This is because libtool creates a wrapper for getfattr so it will be executed using local libraries built in the source tree instead of the system libraries: # Add our own library path to LD_LIBRARY_PATH LD_LIBRARY_PATH="/home/philips/projects/openSUSE:Factory/attr/attr-2.4.39/libattr/.libs:$LD_LIBRARY_PATH" But it is breaking because LD_LIBRARY_PATH uses colon characters as a separator like PATH... I talked to the libtool maintainer about this and he said: On 07:37 Thu 18 Dec 2008, Ralf Wildenhues wrote: > > I have found that libtool generates temporary wrappers with improperly > > escaped LD_LIBRARY_PATH. If the current directory path contains a colon. > > For example /home/philips/test:directory/attr-2.4.43/ > > Where is it documented that LD_LIBRARY_PATH is interpreted as with > backslash escaping for colons in the names? I've never heard of that > before. > > The ld.so(1) man page on my Debian testing system documents that > LD_LIBRARY_PATH is interpreted similarly to PATH. I confirmed now that > PATH uses this kind of colon escaping, surprisingly. I cannot find it > documented anywhere though, certainly not in the Posix pages (but hey, > I overlooked things before). > > We can think about supporting it when and where this is suitably safe to > do so, but my gut reaction would be "don't do it when it hurts". Ralf's first point is correct. ld doesn't accept \: as a literal colon like PATH does. So, we will need to fix this first. _ OR _ Instead of taking on the pain of fixing ld and all of the tools and scripts to generate and understand slash escaped colon characters we could stop using colon as a separator in build service project names. Upstream maintainers are not going to be excited about fixing the colon character problem up because the build service is probably the only thing using it. So, can we please use another separator? Perhaps the dash "-". This character is well accepted and works across http/dns/sh/etc without escaping or special consideration. Doing nothing about this isn't an option. Many packages use this trick to test programs as they sit in the source tree without doing a `make install`. If we do nothing developers who are new to OBS and unaware of the issue will waste time, as I did, trying to figure out why their library fixes aren't working. Thoughts? Thanks, Brandon P.S. I first filed a bug against libtool here: https://bugzilla.novell.com/show_bug.cgi?id=460044 -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

8 17

[opensuse-buildservice] Thoughts on OBS as a git bisect build cluster
by Brandon Philips 06 Mar '09

06 Mar '09

Hello- I want to create a web based tool where users could do git bisections themselves by plugging in starting hashes (provided by a developer most likely) and get an RPM out. Then as they test they come back to the website to report their test results, good or bad, to get the next rpm to test. Now, the most intensive part would be doing all of the builds and checkouts. Something that I think OBS could handle nicely :D First, is this use of OBS is acceptable? If so the next challenge is avoiding lengthy and expensive uploads to the OBS. I have thought up a few strategies for doing such and would appreciate feedback: 1. Create an OBS project with a base version of the project tarball e.g. Kernel v2.6.28, then generate a patch with: $ git diff v2.6.28...<$BISECTHASH> Then branch this OBS project to create a project that will build the RPM for the user with this git diff patch applied. 2. Create an OBS project with a tar snapshot of the external git repo and submit it to an OBS project. Then create an OBS branch from this project for each git bisection step and submit some control file that tells the spec file what hash to build. 3. Have a spec file that does a clone from some internal mirror of the external git tree and does the bisect locally. (Can you get to the internet when building inside a VM?) For #1 and #2 I would need a way to submit a patch to a branched project _without_ doing a full checkout of the tarball again. How would I change one file in an OBS branch without downloading the whole repo? What do people think? Any other strategies to create something like this that uses OBS on the backend? Cheers, Brandon -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

4 5

Re: [opensuse-buildservice] OBS: Who uses Download on Demand or Cross Build - small survey
by Martin Mohring 05 Mar '09

05 Mar '09

adrian.crutchfield(a)gmail.com wrote: > Yes > Yes > Yes > > I'm actually working to get Base:build packages built for ARM. > What challenges as of yet did you run into? We have already discussed the performance accelerator, because OBS with QEMU is quite slow (factor 4-8 slowdown ca. in average). We have already two solutions for this in the backhand. > Late > InSearchOf > -----Original Message----- > From: Martin Mohring <martin.mohring(a)opensuse.org> > > Date: Thu, 22 Jan 2009 22:44:57 > To: <opensuse-buildservice(a)opensuse.org> > Subject: [opensuse-buildservice] OBS: Who uses Download on Demand or Cross Build - small survey > > > Hi, > > a short Discussion on the IRC channel inspired me to ask this question > to all on the mailing list: > > - Who knows what Download on Demand is inside OBS > - Who uses the Cross Development Feature for ARM architecture already > now (although OBS 1.5 is not yet officially released) > - Who of you is using Pre Release Packages for OBS from > openSUSE:Tools:Devel or openSUSE:Tools:Unstable > > Feedback is very welcome to improve usability or potential Bugs. > > Kind regards, Martin Mohring > > OBS / Maintainer Development Packages - OBS Testing > > -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

2 3

[opensuse-buildservice] osc and security
by Joop Boonen 03 Mar '09

03 Mar '09

I've checked out ~/.oscrc I saw that my password can be found in plain text. As someone who would be able to read this file would be able to change packages that I have created. I'm rather worried about it. The package could easily be piggy backed with mall ware. I'm wondering wouldn't it be possible to put an encrypted password? Or even better to work with ssh keys? An other option would be that the password wouldn't be saved. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

8 9

[opensuse-buildservice] %kde4_runtime_requires failed
by Sascha 'saigkill' Manns 01 Mar '09

01 Mar '09

Hello Mates, actually the using of %kde4_runtime_requires failed: File must begin with "/": Requires: File must begin with "/": kdebase4-runtime File must begin with "/": >= File must begin with "/": 4.2.0 File must begin with "/": kdebase4-runtime File must begin with "/": < File must begin with "/": 4.2.60 Has anyone an idea what the error is? -- Sincereley yours Sascha Manns openSUSE Marketing Team (Weekly News) openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://lizards.opensuse.org/author/saigkill -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

2 1