Hi,
my packages home:rudi_m/dateutils and utilities/dateutils
are currently identical.
But in utilities/ it is somewhow build from other sources, see the logs.
For example it does not apply the patch
0001-fix-when-printing-zones-transitioning-at-INT_MAX-in-.patch
So because of build failure the Factory factory-repo-checker does not
accept my package, although it's fine:
https://build.opensuse.org/request/show/484859
What's going on here? IMO it's a critical issue that we don't build the
latest sources as they are committed.
cu,
Rudi
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Hello,
On my private OBS instance interconnected with build.opensuse.org, my
Ubuntu 16.04 targets are reporting the following error:
"The repository setup is broken, build or publish not possible
(repository 'openSUSE.org:Ubuntu:16.04/universe' is unavailable)
(repository 'openSUSE.org:Ubuntu:16.04/universe' is unavailable)
(repository 'openSUSE.org:Ubuntu:16.04/universe' is unavailable)
(repository 'openSUSE.org:Ubuntu:16.04/universe' is unavailable)
(repository 'openSUSE.org:Ubuntu:16.04/universe' is unavailable)
(repository 'openSUSE.org:Ubuntu:16.04/universe' is unavailable)
(repository 'openSUSE.org:Ubuntu:16.04/universe' is unavailable)
(repository 'openSUSE.org:Ubuntu:16.04/universe' is unavailable)"
Depending on the chains of subprojects, this can get quite long.
What's going on?
--
真実はいつも一つ!/ Always, there's only one truth!
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Hey OBS developers, since PR #2854 we have some changes to the
migrations. Essentially all that this
PR did was:
1. Replace migration 001 with the schema dump from OBS 2.5
2. Delete all migrations which were created before OBS 2.5
One thing that the PR does introduce is that now structure.sql contains
"USING BTREE" at the end of
indexes. This is fine because BTREE is the default of mysql indexes
anyway. It does, however, mean that
when you update your local branch from master you will need to "reset
your database" to the structure.sql
in git. You can do this with these commands:
`rake db:drop db:create db:setup`
The reason why you need to do this is because otherwise you wont be able
to generate new migrations
without schema dump deleting the "USING BTREE" references that are
currently in structure.sql in git.
To demonstrate the problem on an existing database locally you can run
these commands:
`
git pull origin master
vagrant exec rails g migration AddTestColumnToProjects test_column:string
vagrant exec rake db:migrate
git diff db/structure.sql
`
And you will see that db/structure.sql has many lines changed.. Note
that if you dont want to create
a new migration at the moment then these steps are not required but you
may as well get it over with
sooner rather than later.
I'm sorry if this causes any annoyance but there are many benefits from
having this change mainly:
1. Running `rake db:migrate` and `rake db:setup` now result in the exact
same database
(no more "check the migrations and structure.sql are the same" cards
on trello)
2. If there is any doubt as to what the correct value of structure.sql
is then its simple - the
correct value is what results from running rake db:migrate on an
empty database
3. Merging database changes between branches is easier
4. We can now squash migrations if we want to reduce the number of files
in db/migrate (i.e. as is
done in this tutorial:
http://naturaily.com/blog/post/how-to-remove-old-database-migrations-in-rub…)
https://github.com/openSUSE/open-build-service/pull/2854
Let me know if you have any questions or concerns about this change.
Thanks
--
Evan Rolfe
Full Stack Web Developer
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg
Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
Hello,
I am running private OBS instance version 2.8
I have aarch64 based arm worker which I use to build armv7 rpm packages.
Now I am trying to build kiwi images. I copied JeOS from
openSUSE:Leap:42.2:Ports and try to rebuild it.
Unfortunately, I see the following:
[ 361s] Apr-08 09:59:32 <1> : kiwi revision:
f8751719e761017db7048bd9a8ef846343c87f97
[ 361s] Apr-08 09:59:32 <1> : Setting log file to: terminal
[ 361s] Apr-08 09:59:32 <1> : EXEC [/usr/bin/uname -m]
[ 361s] Apr-08 09:59:32 <3> : Attempt to run KIWI on unsupported
architecture 'armv8l'
[ 361s] Apr-08 09:59:32 <1> : Description provides no MD5 hash, check
[ 361s] Apr-08 09:59:32 <1> : Reading image description [Prepare]...
[ 361s] Apr-08 09:59:32 <1> : EXEC [/usr/bin/uname -m]
[ 361s] Apr-08 09:59:32 <3> : Attempt to run KIWI on unsupported
architecture 'armv8l'Apr-08 09:59:32 <3> : KIWI exited with error(s)
[ 361s]
[ 361s] Apr-08 09:59:32 <1> : Closing session with ecode: 1
It is clearly personality issue. Could you please tell what kind of
additional magic I need to make it work?
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Hello,
Currently we have huge load on our OBS farm and I'm investigating ways of
decreasing number of rebuilds. My idea was to use libabigail with custom script
to trigger dependency rebuilding only when package ABI changes.
The initial assumption was that the `build-compare' package is used to detect
whether package differs or not. Now after investigation I found that the
decision is made inside the scheduler and `build-compare' is only used to make
delta-rpm packages if they are used.
As far as I understand, to reduce the number of rebuilds I'll need to introduce
kind of libabigail support into scheduler and create the `recent rpm mirror' of
repository, since I need previous and current version of rpms to compare
ABIs. And I'll also need to introduce some state into current hashmap with
project status inside the scheduler.
So the easy way to make scheduler run rebuilds depending on my custom logic
based on running script inside the buildroot does not exist, does it?
Is it possible at all to implement this feature in current OBS? And if yes,
where should I start?
Best Regards,
Pavel Kopyl
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org