November 2014 - openSUSE Build Service

[opensuse-buildservice] obs-service-$whatever tooling, packaging
by Roman Neuhauser 20 Nov '14

20 Nov '14

hello, TL;DR: i'd like all obs-service-* tools to have a Makefile, and i'd prefer if we could colocate all of them in a single git repository. i want to package obs-service-* for ArchLinux. most of these tools have no Makefile, and the build/install procedures are spelled out in their specfiles in b.o.o. i set out to move the build scripts into Makefiles since a) i don't fancy reproducing them in the prospective PKGBUILD files and b) it would do zilch for the future Debian packager. the various obs-service-* have quite simple and similar needs. if i went with a simple Makefile per service we'd end up with the common bits interspersed with the tool-specific ones, which i sense as fertile ground for divergence. instead, i went for a common obs-service.mk file which is identical among the different tools, and a GNUmakefile file to provide that with tool-specific bits. this arrangement makes it a bit easier to keep the common bits identical in the various tools, even though it obviously does nothing to remove the duplication itself; i'm not sure what/if i can do with that. simple: https://github.com/roman-neuhauser/obs-service-python_sdist/compare/wip-mak… local extras: https://github.com/roman-neuhauser/obs-service-download_files/compare/wip-m… https://github.com/roman-neuhauser/obs-service-format_spec_file/compare/wip… https://github.com/roman-neuhauser/obs-service-source_validator/compare/wip… obs-service-download_files inspired the $(cachedirs)/install-cache code which, on a closer look, should be local to that tool, AFAICT there's no other consumer of that feature. --- while the above solves the issues of packaging the various services for different packaging formats and removes *some* of the pain of keeping the machinery in sync, it does not solve the latter completely. even with the syncing procedure as simple as copying a file around, i fully expect the various copies of obs-service.mk to diverge over time. my suggestion here would be to mvoe all the obs-service-* tools into a single repository to bring the number of obs-service.mk copies down to one. is there another way? -- roman -- 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] Fwd: MonoDevelop crashes because of a library version mismatch
by Jacek Rużyczka 18 Nov '14

18 Nov '14

Hi folks, I have already posted this matter in the gtk-sharp mailing list, but the guys there suspect my issue to be related to the MonoDevelop RPM I am using: I am using gtk-sharp2 incl. glib-sharp2-2.12.10-85.13.x86_64 for my Mono project and for MonoDevelop (5.0.1-110.14) itself. The issue is that after the recent update, MD crashes a few seconds after opening whatever project. I get the following error message: monodevelop: symbol lookup error: /usr/lib64/libglibsharpglue-2.so: undefined symbol: g_type_check_instance_is_fundamentally_a The version of glib-sharp2 is the most recent I can get for my openSuSE 12.3 machine. For MD and the Mono files incl. gtk-sharp2 I am using Mono/Factory as a repo. One of the gtk-sharp guys told me the instance checking routine in libglibsharpglue had been added in May 2014: https://mail.gnome.org/archives/commits-list/2014-May/msg08836.html What shall I do? Thank you for any useful hints. Kind regards Jacek Rużyczka -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

1 1

[opensuse-buildservice] build-compare forces republish for new commit and new rpm
by Olaf Hering 18 Nov '14

18 Nov '14

I wonder why its important to republish a package which just had a new commit. If the resulting binary package is identical there is no need to republish, just because the rpm %RELEASE string happens to differ. Similar for a new rpm version in the build tree. Why would that require a republish of the entire tree? I mean the install stack has to cope with old rpm packages anyway, no matter which version of rpm was used to create these packages. Thats the (untested) change I propose to handle both cases and leave the previous package on the mirror: Index: functions.sh =================================================================== --- functions.sh (revision 222a61b1a991885b87a3e16ef27c22bb) +++ functions.sh (working copy) @@ -59,7 +59,7 @@ QF="$QF %{VENDOR} %{DISTRIBUTION} %{DISTURL}" QF="$QF %{LICENSE} %{LICENSE}\\n" QF="$QF %{GROUP} %{URL} %{EXCLUDEARCH} %{EXCLUDEOS} %{EXCLUSIVEARCH}\\n" - QF="$QF %{EXCLUSIVEOS} %{RPMVERSION} %{PLATFORM}\\n" + QF="$QF %{EXCLUSIVEOS} %{PLATFORM}\\n" QF="$QF %{PAYLOADFORMAT} %{PAYLOADCOMPRESSOR} %{PAYLOADFLAGS}\\n" @@ -91,13 +91,6 @@ # Remember to quote the . which is in release release1=`$RPM --qf "%{RELEASE}" "$oldrpm"|sed -e 's/\./\\\./g'` release2=`$RPM --qf "%{RELEASE}" "$newrpm"|sed -e 's/\./\\\./g'` - # This might happen with a forced rebuild of factory - if [ "${release1%.*}" != "${release2%.*}" ] ; then - echo "release prefix mismatch" - if test -z "$check_all"; then - return 1 - fi - fi check_provides $oldrpm $release1 > $file1 check_provides $newrpm $release2 > $file2 Olaf -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

5 15

[opensuse-buildservice] build fails with "missing packages: build-compare@<chksum>"
by Olaf Hering 18 Nov '14

18 Nov '14

I have tweaked build-compare enough to handle kernel-binary packages. For some reason the part of the build which does "rpmbuild kernel-binary.spec" fails at the very end with: missing packages: build-compare@4fb40b45ede614509b721c69adb46441 This does not happen with other packages like xen or whatever. Looking through my changes its not obvious why the kernel packages behave different. Any idea what is going on, and how to debug the remote build? Olaf -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

3 6

[opensuse-buildservice] OBS 2.5 appliance behind company proxy - problems
by Miroslav Sabljic 17 Nov '14

17 Nov '14

Hello guys! I need some help with setting up my local OBS installation to work behind our company proxy (squid). I was searching trough documentation and tried whatever I found about proxy but so far nothing was successful. So here is the story. OBS is installed and proxy is configured on the system with yast. Zypper, curl, and other work without a problem. Proxy uses port 8080 and authentication. I've defined http_proxy and no_proxy variables to options.yml because without this it couldn't download list of available platform repositories from remote OBS instance. After all this I still cannot build a package, it is always staying in scheduled state and nothing happens. Can you please point me to some documentation about proxy or tell me is there maybe some older version of OBS that officially supports proxy? Thanks! -- Best regards, Miroslav -- 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] OBS 2.5.x + clockwork = ActiveRecord::ConnectionTimeoutError
by Srinidhi B 17 Nov '14

17 Nov '14

Hi, A couple of months back, we updated our local OBS server to OBS 2.5.4. Ever since this update, we've had a lot of issues with clockwork and delayed_job. As soon as we updated OBS, /srv/www/obs/api/tmp/clockworkd.clock.output said: I, [2014-09-12T20:30:55.163170 #29041] INFO -- : Triggering 'fetch notifications' E, [2014-09-12T20:31:00.163931 #29041] ERROR -- : could not obtain a database connection within 5.000 seconds (waited 5.000 seconds) (ActiveRecord::ConnectionTimeoutError) /usr/lib64/ruby/gems/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:190:in `block in wait_poll' /usr/lib64/ruby/gems/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:181:in `loop' /usr/lib64/ruby/gems/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:181:in `wait_poll' /usr/lib64/ruby/gems/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:136:in `block in poll' /usr/lib64/ruby/2.0.0/monitor.rb:211:in `mon_synchronize' /usr/lib64/ruby/gems/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:146:in `synchronize' /usr/lib64/ruby/gems/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:134:in `poll' /usr/lib64/ruby/gems/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:423:in `acquire_connection' /usr/lib64/ruby/gems/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:356:in `block in checkout' /usr/lib64/ruby/2.0.0/monitor.rb:211:in `mon_synchronize' /usr/lib64/ruby/gems/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:355:in `checkout' /usr/lib64/ruby/gems/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:265:in `block in connection' /usr/lib64/ruby/2.0.0/monitor.rb:211:in `mon_synchronize' /usr/lib64/ruby/gems/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:264:in `connection' /usr/lib64/ruby/gems/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:294:in `with_connection' /srv/www/obs/api/config/clock.rb:39:in `block in <module:Clockwork>' /usr/lib64/ruby/gems/2.0.0/gems/clockwork-0.7.0/lib/clockwork/event.rb:51:in `call' /usr/lib64/ruby/gems/2.0.0/gems/clockwork-0.7.0/lib/clockwork/event.rb:51:in `execute' /usr/lib64/ruby/gems/2.0.0/gems/clockwork-0.7.0/lib/clockwork/event.rb:41:in `block in run' This continued for a few days until I realized we weren't receiving any build failure notifications. Since I couldn't debug the issue - and I wasn't aware of the fact that clockwork log file was in "tmp" directory instead of "log" - I simply restarted /etc/init.d/obsapidelayed service. Immediately, our users were bombarded with a build failure mails! Running "mysqladmin processlist", showed that there were more than 34-36 database connections open - almost each and every one of them had "Sleep" mentioned in the "Command" column. The same story repeated a couple of weeks back which triggered me to make the following changes in database.yml: production: .. - pool: 30 + pool: 50 + checkout_timeout: 15 After this change, I managed to keep delayed_job happy for almost 2 weeks. Last week, things once again went to bad state: I, [2014-11-12T16:09:31.940219 #6089] INFO -- : Triggering 'status.refresh' E, [2014-11-12T16:09:36.938688 #6089] ERROR -- : could not obtain a database connection within 15.000 seconds (waited 15.000 seconds) (ActiveRecord::ConnectionTimeoutError) /usr/lib64/ruby/gems/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:190:in `block in wait_poll' /usr/lib64/ruby/gems/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:181:in `loop' /usr/lib64/ruby/gems/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:181:in `wait_poll' /usr/lib64/ruby/gems/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:136:in `block in poll' /usr/lib64/ruby/2.0.0/monitor.rb:211:in `mon_synchronize' /usr/lib64/ruby/gems/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:146:in `synchronize' /usr/lib64/ruby/gems/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:134:in `poll' /usr/lib64/ruby/gems/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:423:in `acquire_connection' /usr/lib64/ruby/gems/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:356:in `block in checkout' /usr/lib64/ruby/2.0.0/monitor.rb:211:in `mon_synchronize' /usr/lib64/ruby/gems/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:355:in `checkout' /usr/lib64/ruby/gems/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:265:in `block in connection' /usr/lib64/ruby/2.0.0/monitor.rb:211:in `mon_synchronize' /usr/lib64/ruby/gems/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:264:in `connection' /usr/lib64/ruby/gems/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:294:in `with_connection' /srv/www/obs/api/config/clock.rb:39:in `block in <module:Clockwork>' /usr/lib64/ruby/gems/2.0.0/gems/clockwork-0.7.0/lib/clockwork/event.rb:51:in `call' /usr/lib64/ruby/gems/2.0.0/gems/clockwork-0.7.0/lib/clockwork/event.rb:51:in `execute' /usr/lib64/ruby/gems/2.0.0/gems/clockwork-0.7.0/lib/clockwork/event.rb:41:in `block in run' As of now, I've 57 connections to the database: # mysqladmin processlist | grep frontend | wc -l 57 (Ignore the "grep", I'm just being lazy for skipping the table borders and the table header. There is just one database served by the MySQL server) Regarding mysql's max connections: # mysqladmin -p variables | grep max_conn Enter password: | max_connect_errors | 10 | | max_connections | 151 | Apparently, we keep filling up ActiveRecord's connection pool without freeing any of the connections. Not sure if the issue occurs because we have set "fetch_notifications" job to be run in a different thread: every(27.seconds, 'fetch notifications', thread: true) do ActiveRecord::Base.connection_pool.with_connection do |sql| # this will return if there is already a thread running UpdateNotificationEvents.new.perform end end (Yes, I changed the duration from 17 to 27 seconds after I increased the timeout in database.yml from 5 to 15) Has someone else found this issue? I can't find any solution other than setting a daily cron job to restart obsapidelayed :-/ Regards, Srinidhi. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

1 0

[opensuse-buildservice] Factory vs Tumbleweed repos (again)
by Greg Freemyer 17 Nov '14

17 Nov '14

In my home project I just removed the Factory repo and added the Tumbleweed repo. I understood that to be the recommendation. Now when I run "osc build" the default repo is RedHat. Not exactly my preference. I'm re-adding factory until that is resolved. Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

2 2

[opensuse-buildservice] Freeing buildserver resources: remove driver:
by Johannes Weberhofer 17 Nov '14

17 Nov '14

Dear all! In September there was a discussion about maintainers of the driver: section here: http://lists.opensuse.org/opensuse-factory/2014-09/msg00163.html I think it's time to delete the complete "driver:" project. Any objections against? Can someone do that? Best regards, Johannes -- Johannes Weberhofer Weberhofer GmbH, Austria, Vienna -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

1 0

[opensuse-buildservice] "Link has errors: conflict in file debian.control"
by Florian Höch 15 Nov '14

15 Nov '14

Hi, if you look at the following URL: https://build.opensuse.org/package/show/multimedia:color_management/dispcal… You'll see the error "Link has errors: conflict in file debian.control". I have no clue what that is supposed to mean, pointers welcome. -- Florian Höch -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

1 1

[opensuse-buildservice] solving conflicts
by Olaf Hering 14 Nov '14

14 Nov '14

How do I solve this conflict? Just copying the prjconf part from openSUSE:Factory does not work. The package has a PreReq: udev. [ 11s] now installing cumulated packages [ 14s] Preparing... ######################################## [ 14s] file /usr/lib64/libudev.so.1.4.0 conflicts between attempted installs of libudev-mini1-210-25.5.4.x86_64 and libudev1-210-25.5.4.x86_64 [ 14s] file /usr/bin/udevadm conflicts between attempted installs of udev-mini-210-25.5.4.x86_64 and udev-210-25.5.4.x86_64 [ 14s] file /usr/lib/systemd/systemd-udevd conflicts between attempted installs of udev-mini-210-25.5.4.x86_64 and udev-210-25.5.4.x86_64 [ 14s] file /usr/lib/udev/accelerometer conflicts between attempted installs of udev-mini-210-25.5.4.x86_64 and udev-210-25.5.4.x86_64 [ 14s] file /usr/lib/udev/ata_id conflicts between attempted installs of udev-mini-210-25.5.4.x86_64 and udev-210-25.5.4.x86_64 [ 14s] file /usr/lib/udev/cdrom_id conflicts between attempted installs of udev-mini-210-25.5.4.x86_64 and udev-210-25.5.4.x86_64 [ 14s] file /usr/lib/udev/collect conflicts between attempted installs of udev-mini-210-25.5.4.x86_64 and udev-210-25.5.4.x86_64 [ 14s] file /usr/lib/udev/scsi_id conflicts between attempted installs of udev-mini-210-25.5.4.x86_64 and udev-210-25.5.4.x86_64 [ 14s] exit ... %if 0%{?suse_version} >= 1310 # prefer the small systemd for building Conflict: libudev1:udev-mini Prefer: libudev-mini-devel libudev-mini1 udev-debuginfo libudev1-debuginfo Prefer: systemd-mini systemd-mini-devel Prefer: systemd-mini-devel:systemd-mini Prefer: udev-mini libcom_err2-mini libext2fs2-mini Prefer: libudev1:udev %endif Olaf -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

3 6