December 2011 - openSUSE Build Service

[opensuse-buildservice] Expired OBS Keys?
by King Thorin 02 Jul '13

02 Jul '13

It seems the OBS Security key (keyid 79EAFD54) on keys.gnupg.net has expired (2011-Apr-2). Would it be possible for someone to update it? I know an updated key has been generated (which expires 2013) as it can be found here: http://download.opensuse.org/repositories/security:/OpenVAS:/STABLE:/v4/xUb… Further details can be found via: http://lists.wald.intevation.org/pipermail/openvas-distro/2011-April/thread… Basically the issue came to light when following instructions: http://www.openvas.org/install-packages.html#openvas4_ubuntu_obs -- 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] Use solid state disks [ssd] to improve obs build times.
by doiggl＠velocitynet.com.au 30 Jul '12

30 Jul '12

Hello With the opensuse build service [obs] getting more usage every day I wonder if this would make a diffence :- 1. Use solid state disks [ssd] to improve build times of package rpms on, perhaps point the BuildRoot or _tmppath to the ssd's Reason for asking. Improve the packaging times during busy times on obs. Cheers Glenn. -- 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] MonoOSC?
by Roger Luedecke 03 Jun '12

03 Jun '12

ANy plans to get this working again? I'm at a loss as to how to get it going though I had branched the project etc. Frankly, I'm figuring out the build service, and think monoosc would go a long way to fostering a quicker understanding. -- Roger Luedecke openSUSE Ambassador Ind. Repairs and Consulting **Looking for a C++ etc. mentor*** -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

5 25

[opensuse-buildservice] OBS 2.3 corrections
by Joop Boonen 14 Apr '12

14 Apr '12

Hi all, I found some errors in de configurations of the OBS 2.3 server. I've attached the corrected files and the patches. It's related to: Documentation: /usr/share/doc/packages/obs-api/README.SETUP Apache vhosts configuration: /etc/apache2/vhosts.d/obs.conf I've added the api port 81 connection as a quick fix and as the internal doesn't really need to be encrypted. Should I create a bug report for this? Regards, Joop.

3 3

[opensuse-buildservice] Add Mageia to OBS
by Stephan Kleine 21 Mar '12

21 Mar '12

Hi, could Mageia please get added to OBS? thanks a lot in advance, Stephan -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

5 6

[opensuse-buildservice] openSUSE 10.3 runs out of maintenance
by Adrian Schröter 21 Feb '12

21 Feb '12

Hello, is usual, openeSUSE 10.3 runs out of maintenance and I will remove all repos building against it in OBS. openSUSE:10.3 project has been moved to DISCONTINUED: namespace as announced a while ago. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian(a)suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

2 2

[opensuse-buildservice] version-release numbering for DEB packages
by Steve Rae 08 Feb '12

08 Feb '12

I understand the release tag numbering in spec files (for ‘rpm’ packages): Release: <CI_CNT>.<B_CNT> However, I am unable to determine how to perform the same “release” numbering in ‘deb’ packages. A simple test in home:srae:tools (build.opensuse.org) shows: - the ‘rpm’ <CI_CNT> incrementing, but - the ‘deb’ stays the same -- actually, it seems to use the <version>-<release> as specified on the first line of the ‘debian/changelog’ file (in debian.tar.gz) Thanks in advance! -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

2 3

[opensuse-buildservice] distro independant rpms and debs for distro independant data?
by Paul Elliott 31 Jan '12

31 Jan '12

This question concerns both the OBS and packaging so I am sending to both lists. I am currently working on packaging the Swiss Ephemeris http://www.astro.com/swisseph/ I am currently at the planning scheming and experimentation stage. First I will do the library. But then there is the data. The data is about 60 files not all of which will be wanted by all people. There may be ways of grouping but I am not sure. Perhaps one rpm per file. The Web page says: > For this extended timespan the ephemeris requires 32 Mbytes of ephemeris > files. It would be a shame if this had to repeat for each distro. There may be other projects with even more data. This data is distro and architecture independent. I understand that there should be different rpm per distro because different distros link libraries differently and do other details differently. There could be rpm version dependencies. Perhaps one distro can not understand rpms from another distro as raw data. My question is this is there a lowest common denominator rpm format that can represent pure data (and a few text licensing files) and be understood by all distros? How would you get the build service to produce such rpms? After you produced them how would you get the build service to serve them for all rpm based distros? Same question for debs and the debian based distros? Unrelated question: a while back OBS debian binary repositories were debian compatible but the source repositories were not. Is this still true? -- 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

7 8

[opensuse-buildservice] historic errors showing up again in linkedbuild projects
by Robert Schiele 20 Jan '12

20 Jan '12

Hi, It's me again. It seems I am running into all bugs related to linkedbuild projects in combination with source services. Probably I am the only user of this feature set combination. ;) Now, here it is: With current versions, including up to this version: commit ad4cc3d11b9b6daed710f7d7bad80d7b9440c2e6 Author: Michael Schroeder <mls(a)suse.de> Date: Fri Dec 16 16:02:38 2011 +0100 [backend] use url as fallback for title in patchinfo references I can see the following behavior: 1. I have a project (referring to as the main project in the following) including some packages using source services that pull their sources from an external server. 2. I have other projects that have a subset of packages from the previous projects and pull in the rest of the packages with the linkedbuild feature. 3. One day the external source server referred to in the source services was temporarily down, thus leading to source service errors in the main project and thus some broken packages. 4. After the external source server came back up again I retriggered all source service runs that previously failed and got successful results, such that all packages in the project were fine again. 5. Some packages (but interestingly not all of them) in the linkedbuild projects kept the error. It is not possible to retrigger the runs there since those packages are only linked ones and no real ones. 6. Making an explicit copy of an affected package into the linkedbuild project fixes the problem, since the package is now a materialized copy and thus causes a separate source service run. As soon as this copy is removed again though and the project falls back to the linked project the error reappears. 7. Creating a new linkedbuild project has the same broken packages, even though the packages had been fixed in the main project already long time before the new linkedbuild project was created. So, to sum this up: What I observed in 5-7 seems to be a bug that the source service results are not always copied correctly, picking an outdated result for copying instead of the most recent one. Especially the fact that the problem even persists for newly created projects makes me a bit nervous about the reliability here. Anyone with an idea, what could be causing that, which places in the sources I should focus on for searching for the cause? Alternatively does someone have a good idea for a suitable workaround that is smarter than my current approach to just explicitly copy in all packages that suffer from this behavior? Robert -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

2 1

[opensuse-buildservice] "dead lock" between autoyast2 and yast2-schema
by Joop Boonen 09 Jan '12

09 Jan '12

All, Currently there is a "dead lock" between package autoyast2 and yast2-schema (for the openSUSE:Factory:ARM build). The thing is that autoyast2 Requires yast2-schema. Because of this yast2-schema is blocked. I got around this by removing the autoyast2 requirement. Until yast2-schema has been build. When this package was build I added the Requirement again. I wonder if there is a better "mechanism" in OBS that solves such "lock issue" automatically? Otherwise someone has to handle this by hand. Regards, Joop. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

2 1