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
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
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
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
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
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
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
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
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
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