rebase-helper 0.7.0 with upstream-monitoring support
by Petr Hracek
Hi fedora world,
I am glad to announce, we have released rebase-helper 0.7.0 with
upstream monitoring support.
Upstream Git Hub repo is here [1].
What is rebase-helper used for?
This tool helps you to rebase package to the latest version.
Steps are:
- It extracts old and new sources
- It applies patches to old sources,
- It adds new_sources to old_sources/ and rebase them with command git
rebase --onto new_sources
- It builds both packages with one of supported builders, like rpmbuild,
fedpkg, mock.
- It compares old and new RPMS with several checkers like rpmdiff,
abipkgdiff, pkgdiff.
At the end it reports what was changed between both versions.
How to execute rebase-helper?
Basic usage is simple: *rebase-helper <new_upstream_version>* in your
*GIT repository*.
Does have rebase-helper documentation? Yes here [2].
Pull Request to the-new-hotness is [3]. Some other work is needed based
on the discussion with Ralph Bean.
How does it look like bugzilla with rebase-helper integration? See [4].
If you have any questions, please do not hesitate to contact us on
freenode #rebase-helper channel.
[1] https://github.com/phracek/rebase-helper
[2] https://rebase-helper.readthedocs.org/en/latest/
[3] https://github.com/fedora-infra/the-new-hotness/pull/94
[4] https://partner-bugzilla.redhat.com/show_bug.cgi?id=1259391
--
Petr Hracek
Software Engineer
Developer Experience
Red Hat, Inc
Mob: +420777056169
email: phracek(a)redhat.com
8 years, 4 months
Cannot add dependency job for unit dnf-makecache.timer, ignoring:
Unit dnf-makecache.timer is masked
by Reindl Harald
WHO defines that "dependency" and WHY?
when i say "mask, i want it refreshed when it is used" than *i mean*
that and there is no business to spit my logs on all machines al day
long full with "you have masked it"
Jan 14 21:30:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:30:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:30:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:30:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:30:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:30:02 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:30:02 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:30:03 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:30:03 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:30:13 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:30:13 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:32:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:33:20 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:34:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:34:22 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:35:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:36:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:38:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:40:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:40:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:40:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:42:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:44:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:45:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:45:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:46:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:48:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:50:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:50:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:50:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:52:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:54:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:55:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:56:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 21:58:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 22:00:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 22:00:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 22:00:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 22:00:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 22:01:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 22:02:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 22:02:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 22:04:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 22:05:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 22:06:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 22:08:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 22:10:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 22:10:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 22:10:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 22:12:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 22:14:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 22:15:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
Jan 14 22:15:01 localhost systemd[1]: Cannot add dependency job for unit
dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked.
8 years, 4 months
Issue with undefined reference with assembler in rr
by Dave Johansen
I was working on packaging rr [1] and one of the tests [2] fails to build
when optimizations are turned on. I've reduced it to the following and
still been able to reproduce the issue:
static const float xmm0 = 10;
int main() {
__asm__ __volatile__(
#if __i386__
"movss xmm0, %xmm0\n\t"
#elif __x86_64__
"movss xmm0(%rip), %xmm0\n\t"
#else
#error unexpected architecture
#endif
);
return 0;
}
Here's the output on F23 x86_64:
$ gcc fxregs.c -O0
$ gcc fxregs.c -O1
/tmp/cccdze3O.o: In function `main':
fxregs.c:(.text+0x4): undefined reference to `xmm0'
collect2: error: ld returned 1 exit status
Is this a gcc bug or is there something that I need to do in the build to
get the tests to build without error?
Thanks,
Dave
[1]: https://github.com/mozilla/rr
[2]:
https://github.com/mozilla/rr/blob/9a532fd786f6378d6b8c2cd70a04731341cf06...
8 years, 4 months
Re: kmods and Fedora
by Andrew Lutomirski
On Thu, Jan 14, 2016 at 3:04 PM, Ian Malone <ibmalone(a)gmail.com> wrote:
> On 14 January 2016 at 19:29, Andrew Lutomirski <luto(a)mit.edu> wrote:
>> 2. Assuming that shipping an out-of-tree module is okay, is akmod a good
>> mechanism?
>>
>> I would argue strongly that akmod is *not* a good mechanism.
>>
>> Clearly any end-user-box-builds-modules system needs the package manager to
>> pull in the right devel stuff. This is clearly a solvable problem.
>>
>> But akmod in particular has a really nasty built-in assumption: it assumes
>> that the running kernel came from an RPM at all. For people who write
>> kernels, this utterly sucks. For example, I have no intention of rpm-ifying
>> every test kernel I build for my laptop. I install them according to the
>> standard arrangement, which "make install" can do just fine. There are
>> symlinks in standard places that a kmod build system could find. Akmod
>> can't do that. Akmod also can't figure out what to make its freshly-built
>> rpm depend on because there is no correct answer.
>>
>> I think that, if Fedora were to adopt a kmod build system: it should have a
>> QA requirement: if you "make modules_install && make install" a kernel and
>> boot into it, the kmod system should work. Akmod fails utterly in that
>> scenario.
>>
>
> I don't quite get this one, if you build any package from a non-rpm
> source it's not a given that rpm modules will work with it.
Of course there's no guarantee, but IMO it should at least try rather
than just failing utterly because the kernel doesn't come from an rpm.
> Akmod is
> really a convenience for people reliant on non-tree modules who are
> also using the distribution rpm kernel, so they have a chance of
> getting a working module whenever the kernel updates. If you're
> building your own kernel you probably know when you've done it and how
> to build the module.
>
I disagree here.
I use the nvidia binary module from rpmfusion on one machine because
its card isn't supported by nouveau yet. I also sometimes prefer to
run my own kernels (to test, to develop, to benchmark, or to enable
new hardware -- I write kernel drivers on occasion). But installing
the nvidia driver from the nvidia-provided script is a colossal mess
-- I have no reason to believe that it won't clobber something, that
it will uninstall correctly, etc. The rpmfusion version is nicely
packaged, but the actual kernel module part simply refuses to try to
install.
If there was a good, concrete benefit to its refusal to install, I'd
be more understanding, but AFAICT it's just doing complicated things
with packaging for no particularly good reason.
If, for example, it simply installed into
/lib/modules/VERSION/akmod/path/to/driver.ko, then rpm could be taught
to delete /lib/modules/VERSION when the corresponding kernel package
goes away (either using a scriptlet in the kernel package or an RPM
trigger, I imagine), and everything would work nicely without
injecting extra rpms into the system.
--Andy
8 years, 4 months
Call for Fedora 24 Test Days
by Adam Williamson
The Fedora 24 schedule [1] is winding up, and it's time we started
thinking about what we'd want to have a test day for. There are several
changes accepted already for F24, and the window for proposals is still
open so more may come. You can find the list of accepted Changes here:
http://fedoraproject.org/wiki/Releases/24/ChangeSet
Please take some time and look through the list and see if there's
anything you'd be interested in testing - or if there's something you
think should get some testing that isn't in the ChangeSet!
For those of you not familiar with them, a test day is an online event
aimed at testing a specific feature of an upcoming Fedora release. By
utilizing IRC for organization/coordination and a Wiki page for
instructions and results, test days are easy to organize. Anyone can
request to host a test day or request that the QA team help you out
with the organization of the test day. A test day can be run for any
feature or area of a distribution that focused testing would be useful
for. More information on test days can be found here:
https://fedoraproject.org/wiki/QA/Test_Days .
To propose a test day, file a ticket on the QA Trac. A full explanation
can be found here:
https://fedoraproject.org/wiki/QA/Test_Days/Create
The SOP for hosting a test day is here:
https://fedoraproject.org/wiki/QA/SOP_Test_Day_management
Traditionally test days have been held on Thursdays, but if you'd
prefer to have it on another day that's fine too. We're pretty
flexible, but having plenty of lead time helps to get the word out.
Just put in your ticket the date or time-frame you'd like, and we'll
figure it out from there.
If you have any questions about test days or the process, please don't
hesitate to contact me or any other QA Team member in #fedora-qa on
Freenode or respond on the test list.
Thanks and happy testing!
[1] https://fedoraproject.org/wiki/Releases/24/Schedule
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
8 years, 4 months
ELF arch question
by Orion Poplawski
rpm flags shared libraries of ELFCLASS64 with '(64bit)' on all architectures
except Alpha (which thankfully we don't support). My question is, are
ELFCLASS64 libraries always installed in /usr/lib64 on all Fedora platforms,
or am I going to have to read the elf class of the file to be sure?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
8 years, 4 months
Package name for EPEL7 branch
by Greg Hellings
I'm working with a package (rubygem-minitest) which already exists in
the core EL packages on the 4.x series. In order to enable a whole
slew of new packages to be created in EPEL7, it will be necessary to
package the 5.x series. However, since we don't want to mask the EL
package it has been proposed and agreed to that the EPEL package be
named rubygem-minitest5.
In order to bring this about, would I need to submit a Review Request
for a new package named rubygem-minitest5 and go through the normal
new package process? Or is there an expedited way I can just get
rubygem-minitest5 added to the tags for epel7 in koji?
--Greg
8 years, 4 months
Unreachable Developer
by Greg Hellings
I've been trying to reach jstribny(
https://admin.fedoraproject.org/accounts/user/view/jstribny) for a few
weeks regarding commit privileges on EPEL7 to several packages in
pkgdb. Most notable among those are:
rubygem-minitest
rubygem-i18n
rubygem-tzinfo
As yet, I have been unable to produce a response, either in pkgdb or
via email. Has anyone had contact with him lately? For some of my
pending requests, there are other package maintainers who have been
wonderfully helpful in responding, but I've been completely unable to
reach jstribny.
Assistance would be appreciated. Thanks!
--Greg
8 years, 4 months
