openSUSE Build Service January 2009

buildservice@lists.opensuse.org

67 participants
98 discussions

by Dirk Stöcker

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

11 years, 6 months

Problems with files added by remote URI

by Michael Behrisch

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

11 years, 8 months

History of _link'ed projects?

by Lars Marowsky-Bree

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

11 years, 8 months

Re: [opensuse-buildservice] debian transformer problems on xUbuntu 8.10

by Martin Mohring

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

11 years, 8 months

Colons considered harmful: escaping LD_LIBRARY_PATH in OBS projects

by Brandon Philips

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

11 years, 8 months

Re: [opensuse-buildservice] OBS: Who uses Download on Demand or Cross Build - small survey

by Martin Mohring

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

11 years, 8 months

osc and security

by Joop Boonen

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

11 years, 8 months

Status latency in build.opensuse.org

by Lars Marowsky-Bree

Hi, what's the reason for the latency in status displays on b.o.o? When I enable building for a previously disabled arch, it took several minutes to update the status from "disabled" to building/blocked. I understand that this is partly due to the scheduler re-run needed, but because that time is not known or exposed, one looks through all the expert settings to figure out what one has done wrong, or if there isn't a flag one overlooked. Sometimes the same happens between "finished" to "succeeded", or when the build has finished when the buid log seems to switch from "live" to "archived", there's a gap there the build has finished (possibly failed) but the log then still shows the outdated one - which build fine or aborted with a different error. It's a usability nightmare. Can't we at least - if the latencies can't be reduced for some reason - immediately wipe the outdated state? I'd rather see a "Please wait" message until the next scheduler run instead of wrong information. 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

11 years, 9 months

[PATCH] commit message template

by Michal Vyskocil

Hi, the attached patch changes the behavior of 'osc commit' command. I'm not very happy when I have three places where the changes should be documented: - .changes - %changelog in .spec - osc commit messages The modified commit command read a differences from 1.) .changes, or 2.) %changelog part of .spec and fill it to the commit message, so you don't need type it again. Only one problem is - you need change the commit message anyway, because osc check the difference between commit message template and a result, but this should be easily fixed (use a checksum without commit message template). What do you think about this approach? Regards Michal Vyskocil

11 years, 9 months

osc-plugins-gnome in openSUSE:Tools

by Vincent Untz

Hi, I've submitted a request to have osc-plugins-gnome in openSUSE:Tools (request #5249). This is a package containing various plugins developed by the GNOME team, but they can be useful to other people. Ideally, I'd like the package to be maintained in openSUSE:Tools instead of some home:$someone project. I'll try to find time to push the most interesting features in osc itself, but not everything makes sense there either. Good to have plugins :-) Cheers, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

11 years, 9 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openSUSE Build Service January 2009