Re: Enable LTO build for crash utility
Add Kazu in cc list
On Wed, 18 Aug 2021 at 10:45, lijiang wrote:
>
> Hi,
>
> In Fedora crash.spec, currently the LTO is disabled as below:
>
> +# This package has an internal copy of GDB which has broken configure code
> for
> +# INTDIV0_RAISES_SIGFPE and MUST_REINSTALL_SIGHANDLERS
> +# Updating that code properly seems nontrivial and best left to the package
> +# maintainer.
> +# Disable LTO
Hi Lianbo, the above words seem to suggest disable LTO intentionally,
I know the upstream crash tool is working on gdb 10.x integration,
maybe the above is eased already with the latest gdb update?
> +%define _lto_cflags %{nil}
>
> commit: c6fc69dae3a2 ("Disable LTO")
>
> In RHEL9, that(disable LTO) was inherited from Fedora. But, currently a bug
> is reported to enable the LTO build for RHEL9:
> https://bugzilla.redhat.com/show_bug.cgi?id=1990071.
>
> I tried to remove the macro "%define _lto_cflags %{nil}" from the crash.spec,
> and then build the rpm packages, But I didn't see the lto flag such as
> "-flto" or "-ffat-lto-objects" during the whole build stage, and the build
> process passed without any error reports.
>
> I'm wondering if it could rely on the redhat-rpm-config macro or it(LTO flag)
> can take effect when the toolchain is clang(not gcc)? Any thoughts?
The question seems about how to enable LTO instead of if it is ok to
enable LTO. Maybe Jeff and others can provide some inputs
>
> Thanks.
> Lianbo
>
>
>
> But
Thanks
Dave
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
A shim bug 1651016 in Fedora
Hi, I'm not sure who is maintaining the Fedora shim pkg, if none of you, could you suggest who is the right person to ping. The bug below is not fixed yet for long time, can we get an update? https://bugzilla.redhat.com/show_bug.cgi?id=1651016 Thanks Dave ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Issue with booting on latest kernels (EFI_DISABLE_PCI_DMA related)
Hi Igor, I did not read Fedora list often, just catch this now. Maybe you have noticed the fix then just ignore my reply. On 04/15/20 at 06:50pm, Igor Gnatenko wrote: > Hello, > > I have ThinkPad T480s and after latest kernel upgrades on Rawhide I > see something like: > > ``` > exit_boot() failed! > efi_main() failed! This has been fixed by below upstream commit: 105cb9544b16 efi/x86: Move efi stub globals from .bss to .data But during the discussion about the fix, people pointed out grub in distribution should fix potential other bugs although the kernel commit above fixed the current issue: https://lore.kernel.org/linux-efi/CAMj1kXEm=E6B+kjZktG=sBPLQ=_hffuz6kflskngzrnumjn...@mail.gmail.com/#t Thanks Dave ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Minimize systemd for kdump's initramfs
On 01/03/20 at 11:45am, Dave Young wrote: > On 01/02/20 at 09:02am, Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Jan 02, 2020 at 12:21:26AM +0800, Kairui Song wrote: > > > Some component, like Systemd, have grown by a lot, here is a list of > > > the size of part of binaries along with the binaries they required in > > > F31: > > > /root/image/bin/systemctl > > > 20M . > > > /root/image/usr/bin/systemctl > > > 20M . > > > /root/image/usr/bin/systemd-cgls > > > 20M . > > > /root/image/usr/bin/systemd-escape > > > 20M . > > > /root/image/usr/bin/systemd-run > > > 20M . > > > ... > > > > > > There are overlays between the libraries they used so when installed > > > into the initramfs, the total size didn't go too big yet. But we can > > > see the size of systemd binary and libraries it used is much bigger > > > than others. > > > > All systemd binaries will mostly link to the same libraries (because > > they link to a private shared library, which links to various other > > shared libraries). So this "20M" will be repeated over and over, but > > it's the same dependencies. > > > > While we'd all prefer for this to be smaller, 20M should is actually > > not that much... > > > > > And as a compare, from version 219 to 243, systemd's library > > > dependency increased a lot: > > > (v219 is 5M in total, v243 is 20M in total) > > > > This is slightly misleading. Code was moved from individual binaries > > to libsystemd-shared-nnn.so, so if you look at the deps of just a single > > binary, you'll see many more deps (because libsystemd-shared-nnn.so has > > more deps). But the total number of deps when summed over all binaries > > grew much less. A more useful measure would be the size with deps summed > > over all systemd binaries that are installed into your image in v219 and > > v243. > > > > I vaguely remember the size increased before due to linking with libidn2 > previously, so those libraries contribute a lot. > > Does every systemd binary depend on all libraries? Or each of the > systemd binary only depends on those libs when really needed? For example if I do not need journalctl, then I can drop journalctl and those libraries specific for journalctl? > > Thanks > Dave ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Minimize systemd for kdump's initramfs
On 01/02/20 at 09:02am, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Jan 02, 2020 at 12:21:26AM +0800, Kairui Song wrote: > > Some component, like Systemd, have grown by a lot, here is a list of > > the size of part of binaries along with the binaries they required in > > F31: > > /root/image/bin/systemctl > > 20M . > > /root/image/usr/bin/systemctl > > 20M . > > /root/image/usr/bin/systemd-cgls > > 20M . > > /root/image/usr/bin/systemd-escape > > 20M . > > /root/image/usr/bin/systemd-run > > 20M . > > ... > > > > There are overlays between the libraries they used so when installed > > into the initramfs, the total size didn't go too big yet. But we can > > see the size of systemd binary and libraries it used is much bigger > > than others. > > All systemd binaries will mostly link to the same libraries (because > they link to a private shared library, which links to various other > shared libraries). So this "20M" will be repeated over and over, but > it's the same dependencies. > > While we'd all prefer for this to be smaller, 20M should is actually > not that much... > > > And as a compare, from version 219 to 243, systemd's library > > dependency increased a lot: > > (v219 is 5M in total, v243 is 20M in total) > > This is slightly misleading. Code was moved from individual binaries > to libsystemd-shared-nnn.so, so if you look at the deps of just a single > binary, you'll see many more deps (because libsystemd-shared-nnn.so has > more deps). But the total number of deps when summed over all binaries > grew much less. A more useful measure would be the size with deps summed > over all systemd binaries that are installed into your image in v219 and > v243. > I vaguely remember the size increased before due to linking with libidn2 previously, so those libraries contribute a lot. Does every systemd binary depend on all libraries? Or each of the systemd binary only depends on those libs when really needed? Thanks Dave ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaned hstr
Hi, I've orphaned hstr. I can not find time for this pkg, please take it if you want. Thanks Dave ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: koji build failure
On 02/07/18 at 06:32am, Kalev Lember wrote: > On 02/07/2018 06:17 AM, Dave Young wrote: > > - nothing provides /usr/bin//usr/bin/python3 needed by > > glib2-devel-2.55.2-1.fc28.x86_64 > > Looks like something gone wrong with new brp-mangle-shebangs script in > redhat-rpm-config. I've disabled it in glib2 2.55.2-2; can you try > submitting your build again? Thank you for quick fix! a new build seem running well now: https://koji.fedoraproject.org/koji/taskinfo?taskID=24775310 > > -- > Kalev > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org Thanks Dave ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
koji build failure
Hi all Anyone has idea bout below error in mock log? Start: build phase for kexec-tools-2.0.16-4.fc28.src.rpm Start: build setup for kexec-tools-2.0.16-4.fc28.src.rpm ERROR: Exception(/var/tmp/koji/tasks/2211/24772211/local/work/tasks/2140/24772140/kexec-tools-2.0.16-4.fc28.src.rpm) Config(f28-build-11345612-851851) 0 minutes 2 seconds INFO: Results and/or logs in: /var/lib/mock/f28-build-11345612-851851/result ERROR: Command failed: # /usr/bin/dnf builddep --installroot /var/lib/mock/f28-build-11345612-851851/root/ /var/lib/mock/f28-build-11345612-851851/root//builddir/build/SRPMS/kexec-tools-2.0.16-4.fc28.src.rpm --setopt=tsflags=nocontexts Last metadata expiration check: 0:00:00 ago on Wed 07 Feb 2018 04:31:49 AM UTC. Package pkgconf-pkg-config-1.4.1-2.fc28.x86_64 is already installed, skipping. Package zlib-1.2.11-5.fc28.x86_64 is already installed, skipping. Error: Problem: conflicting requests - nothing provides /usr/bin//usr/bin/python3 needed by glib2-devel-2.55.2-1.fc28.x86_64 build link: https://koji.fedoraproject.org/koji/taskinfo?taskID=24772211 Thanks Dave ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Can't capture vmcore?
On 01/17/18 at 09:31am, Dave Young wrote:
> Don, thanks for ccing me.
> On 01/16/18 at 07:47am, Don Zickus wrote:
> > (cc'ing Dae Young)
> >
> > On Tue, Jan 16, 2018 at 07:41:36AM -0500, Josh Boyer wrote:
> > > On Tue, Jan 9, 2018 at 1:51 PM, Maxim Burgerhout <ma...@wzzrd.com> wrote:
> > > > I'm getting kernel panics in a VM that functions as a hypervisor, the
> > > > moment
> > > > I spin up the nested guest (on AMD ThreadRipper / Fedora 27). That is
> > > > annoying, of course, so I try to be a good citizen and file a bug.
> > > >
> > > > For some reason though, I cannot get the core dumped. I get a core fine
> > > > with
> > > > sysrq, but not with this actual panic. I've followed [1] to set up
> > > > kdump and
> > > > crash, but everytime I trigger the crash and see my VM reboot, I see an
> > > > empty /var/crash afterwards.
> > > >
> > > > As was able to get the vmcore written to /var/crash on in a RHEL7
> > > > guest, I'm
> > > > starting to suspect a bug, but I'm unsure.
>
> One thing need check is if kdump service started successfully before the
> crash, ie. check /sys/kernel/kexec_crash_loaded.
>
> If use self-build kernel, you can check to use below patch for testing:
>
> ---
> It is useful to print kdump kernel loaded status in dump_stack()
> especially when panic happens so that we can differenciate
> kdump kernel early hang and a normal panic in a bug report.
>
> Signed-off-by: Dave Young <dyo...@redhat.com>
> ---
> kernel/printk/printk.c |3 +++
> 1 file changed, 3 insertions(+)
>
> --- linux-x86.orig/kernel/printk/printk.c
> +++ linux-x86/kernel/printk/printk.c
> @@ -48,6 +48,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -3127,6 +3128,8 @@ void dump_stack_print_info(const char *l
> if (dump_stack_arch_desc_str[0] != '\0')
> printk("%sHardware name: %s\n",
> log_lvl, dump_stack_arch_desc_str);
> + if (kexec_crash_loaded())
> + printk("%skdump kernel loaded\n", log_lvl);
>
> print_worker_info(log_lvl, current);
> }
>
> > > >
> > > > Any pointers on how to debug this?
> > > >
> > > > [1]
> > > > https://fedoraproject.org/wiki/How_to_use_kdump_to_debug_kernel_crashes
> > >
> > > Adding the Fedora kernel list.
> > >
> > > Kdump isn't automatically tested in Fedora and while it can work, it
> > > can often be broken as well. There might be someone on the kernel
> > > list that is more familiar with the current state of kdump support in
> > > Fedora, or alternative methods for getting the kernel backtrace.
>
> Yes, since Fedora kernel updates frequently, it is not a surprise that
> kdump does not work. But it is always good to report a bug against
> "kexec-tools" component or "kernel" -> "Kexec/kdump" Subcomponent.
Hmm, I noticed in bugzilla there is no such subcomponent for Fedora
if so the kdump bugs can be routed to "kexec-tools" so that we can
be aware about them.
>
> > >
> > > josh
> > > ___
> > > kernel mailing list -- ker...@lists.fedoraproject.org
> > > To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
>
> Thanks
> Dave
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Can't capture vmcore?
Don, thanks for ccing me.
On 01/16/18 at 07:47am, Don Zickus wrote:
> (cc'ing Dae Young)
>
> On Tue, Jan 16, 2018 at 07:41:36AM -0500, Josh Boyer wrote:
> > On Tue, Jan 9, 2018 at 1:51 PM, Maxim Burgerhout <ma...@wzzrd.com> wrote:
> > > I'm getting kernel panics in a VM that functions as a hypervisor, the
> > > moment
> > > I spin up the nested guest (on AMD ThreadRipper / Fedora 27). That is
> > > annoying, of course, so I try to be a good citizen and file a bug.
> > >
> > > For some reason though, I cannot get the core dumped. I get a core fine
> > > with
> > > sysrq, but not with this actual panic. I've followed [1] to set up kdump
> > > and
> > > crash, but everytime I trigger the crash and see my VM reboot, I see an
> > > empty /var/crash afterwards.
> > >
> > > As was able to get the vmcore written to /var/crash on in a RHEL7 guest,
> > > I'm
> > > starting to suspect a bug, but I'm unsure.
One thing need check is if kdump service started successfully before the
crash, ie. check /sys/kernel/kexec_crash_loaded.
If use self-build kernel, you can check to use below patch for testing:
---
It is useful to print kdump kernel loaded status in dump_stack()
especially when panic happens so that we can differenciate
kdump kernel early hang and a normal panic in a bug report.
Signed-off-by: Dave Young <dyo...@redhat.com>
---
kernel/printk/printk.c |3 +++
1 file changed, 3 insertions(+)
--- linux-x86.orig/kernel/printk/printk.c
+++ linux-x86/kernel/printk/printk.c
@@ -48,6 +48,7 @@
#include
#include
#include
+#include
#include
#include
@@ -3127,6 +3128,8 @@ void dump_stack_print_info(const char *l
if (dump_stack_arch_desc_str[0] != '\0')
printk("%sHardware name: %s\n",
log_lvl, dump_stack_arch_desc_str);
+ if (kexec_crash_loaded())
+ printk("%skdump kernel loaded\n", log_lvl);
print_worker_info(log_lvl, current);
}
> > >
> > > Any pointers on how to debug this?
> > >
> > > [1]
> > > https://fedoraproject.org/wiki/How_to_use_kdump_to_debug_kernel_crashes
> >
> > Adding the Fedora kernel list.
> >
> > Kdump isn't automatically tested in Fedora and while it can work, it
> > can often be broken as well. There might be someone on the kernel
> > list that is more familiar with the current state of kdump support in
> > Fedora, or alternative methods for getting the kernel backtrace.
Yes, since Fedora kernel updates frequently, it is not a surprise that
kdump does not work. But it is always good to report a bug against
"kexec-tools" component or "kernel" -> "Kexec/kdump" Subcomponent.
> >
> > josh
> > ___
> > kernel mailing list -- ker...@lists.fedoraproject.org
> > To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Thanks
Dave
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Orphaning packages
> - hstr Taking this one, thanks! Dave ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Is there something wrong with the Koji builders?
On 01/19/17 at 10:24pm, Kevin Fenzi wrote: > ok. After a bunch of debugging and digging today it sure looks like the > underlying problem was squid operating in smp mode. > > We switched the squid servers back to non smp mode around 00:00 and I've > not seen any of these failures since then. > > I sure hope everything is back to normal now. > > kevin A scratch build failed for me: https://koji.fedoraproject.org/koji/taskinfo?taskID=17388293 I noticed below error in ppc64 build log: DEBUG util.py:435: Error: package pkgconf-pkg-config-1.2.0-1.fc26.ppc64 conflicts with pkgconfig < 1:0.29.1-2 provided by pkgconfig-1:0.29.1-1.fc25.ppc64 Thanks Dave ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ping spin-kickstarts maintainer (bz1176483)
On 06/07/16 at 06:01am, Bruno Wolff III wrote: > On Tue, Jun 07, 2016 at 16:11:33 +0800, > Dave Young <dyo...@redhat.com> wrote: > > > >It is for adding kexec-tools-anaconda-addon package to kickstarts, > >exactly like Brian said in comment #5. > > I added the following questions to the bug, but since there is a discussion > here, I also mention them here. > > What does adding that package fix? (I couldn't easily find what the problem > is that this is supposed to fix.) > > If anaconda is broken without this package, why isn't it getting pulled in > by a dependency? Bruno, I agreed it is better to discuss this in bugzilla. Replied there https://bugzilla.redhat.com/show_bug.cgi?id=1176483#c8 Thanks a lot Dave -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: ping spin-kickstarts maintainer (bz1176483)
Hi, Lubomír On 06/06/16 at 11:23am, Lubomír Sedlář wrote: > Dave Young píše v Po 06. 06. 2016 v 16:56 +0800: > > Hi, > > > > We have a bug report for adding kdump anaconda addon to livecd: > > https://bugzilla.redhat.com/show_bug.cgi?id=1176483 > > > > The bug was created in 2014, seems I can not reach the maintainer. > > What else can I do? Do we have other maintainers for this component? > > Hello, > the kickstarts repo has moved to Pagure recently, so you can open a > pull request: > > https://pagure.io/fedora-kickstarts I cloned the git, but I'm not sure where to add the package. I'm lost because I know nothing the kickstarts details before. Is it sufficient to add the package name in fedora-live-base.ks? Since the package kexec-tools-anaconda-addon is an anaconda addon, are there any anaconda group I should add it to? Ccing Brian Lane also. Thanks Dave -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: ping spin-kickstarts maintainer (bz1176483)
Hi, Bruno On 06/06/16 at 04:15am, Bruno Wolff III wrote: > On Mon, Jun 06, 2016 at 16:56:50 +0800, > Dave Young <dyo...@redhat.com> wrote: > >Hi, > > > >We have a bug report for adding kdump anaconda addon to livecd: > >https://bugzilla.redhat.com/show_bug.cgi?id=1176483 > > > >The bug was created in 2014, seems I can not reach the maintainer. > >What else can I do? Do we have other maintainers for this component? > > There are a number of people that work with spin-kickstarts. (Though not all > of us work on all aspects of it.) The bug you referenced doesn't have much > in the way of details, but does seem to refer to some other comments > somewhere that isn't obvious in the bug. Note there is a freeze for Fedora > 24, so making changes in that branch aren't likely to be applied before the > release. It is for adding kexec-tools-anaconda-addon package to kickstarts, exactly like Brian said in comment #5. Thanks Dave -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
ping spin-kickstarts maintainer (bz1176483)
Hi, We have a bug report for adding kdump anaconda addon to livecd: https://bugzilla.redhat.com/show_bug.cgi?id=1176483 The bug was created in 2014, seems I can not reach the maintainer. What else can I do? Do we have other maintainers for this component? Thanks Dave -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [ANNOUNCE] kexec-tools 2.0.10
On 07/02/15 at 09:48am, Peter Robinson wrote: On Thu, Jul 2, 2015 at 4:06 AM, Dave Young dyo...@redhat.com wrote: On 07/01/15 at 09:08am, Peter Robinson wrote: On Wed, Jul 1, 2015 at 1:36 AM, Dave Young dyo...@redhat.com wrote: Pratyush, Thanks for the effort, let's cc Fedora devel list, see if we can get help from Fedora experts. Summary the problem: Latest kexec-tools koji build in rawhide results in a wrong kexec binary, kexec load fails with something like below: R_X86_64_29 Unhandled rela relocation: R_X86_64_29 This kinds of errors usually caused by gcc unnecesarrily add options like -fexception, -fPIC, -fstack-protetor-* for building kexec purgatory which runs in kernel mode. I filed a bug below: https://bugzilla.redhat.com/show_bug.cgi?id=1236456 Appreciate for any hints how to fix the problem. I commented on the BZ Peter, thank you. Resolved with your suggestion. Excellent, btw what's the status of aarch64 support landing upstream so we can enable it in Fedora? arm64 patches are still not accepted in upstream, Geoff need resend the whole series for review. Will ping them in list. Thanks Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [ANNOUNCE] kexec-tools 2.0.10
On 07/01/15 at 09:08am, Peter Robinson wrote: On Wed, Jul 1, 2015 at 1:36 AM, Dave Young dyo...@redhat.com wrote: Pratyush, Thanks for the effort, let's cc Fedora devel list, see if we can get help from Fedora experts. Summary the problem: Latest kexec-tools koji build in rawhide results in a wrong kexec binary, kexec load fails with something like below: R_X86_64_29 Unhandled rela relocation: R_X86_64_29 This kinds of errors usually caused by gcc unnecesarrily add options like -fexception, -fPIC, -fstack-protetor-* for building kexec purgatory which runs in kernel mode. I filed a bug below: https://bugzilla.redhat.com/show_bug.cgi?id=1236456 Appreciate for any hints how to fix the problem. I commented on the BZ Peter, thank you. Resolved with your suggestion. Thanks Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [ANNOUNCE] kexec-tools 2.0.10
Pratyush, Thanks for the effort, let's cc Fedora devel list, see if we can get help from Fedora experts. Summary the problem: Latest kexec-tools koji build in rawhide results in a wrong kexec binary, kexec load fails with something like below: R_X86_64_29 Unhandled rela relocation: R_X86_64_29 This kinds of errors usually caused by gcc unnecesarrily add options like -fexception, -fPIC, -fstack-protetor-* for building kexec purgatory which runs in kernel mode. I filed a bug below: https://bugzilla.redhat.com/show_bug.cgi?id=1236456 Appreciate for any hints how to fix the problem. On 06/30/15 at 04:05pm, Pratyush Anand wrote: Hi Dave, Really not able to get whats the issue..let koji people look into.. kexec-tools-2.0.7-11.fc23.x86_64.rpm build failed http://koji.fedoraproject.org/koji/taskinfo?taskID=10249484 kexec-tools-2.0.9-1.fc23.x86_64.rpm does not work http://koji.fedoraproject.org/koji/taskinfo?taskID=10249201 kexec-tools-2.0.8-12.fc23.x86_64.rpm does not work http://koji.fedoraproject.org/koji/taskinfo?taskID=10249377 - so may be its not kexec-tools version issue kexec-tools-2.0.7-26.el7.x86_64.rpm work https://brewweb.devel.redhat.com/taskinfo?taskID=9439045 The only difference which I noticed between working brew and not working koji is that koji introduces -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 into gcc command line. However, I tried -fno-enforce-eh-specs (http://koji.fedoraproject.org/koji/taskinfo?taskID=10250889), but it did not work :( Only thing remaining is to try 2.0.9/8 in brew..will try that too. ~Pratyush -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Koji build adds extra cflags [was: Re: [ANNOUNCE] kexec-tools 2.0.10]
Change the subject a bit.. On 07/01/15 at 08:36am, Dave Young wrote: Pratyush, Thanks for the effort, let's cc Fedora devel list, see if we can get help from Fedora experts. Summary the problem: Latest kexec-tools koji build in rawhide results in a wrong kexec binary, kexec load fails with something like below: R_X86_64_29 Unhandled rela relocation: R_X86_64_29 This kinds of errors usually caused by gcc unnecesarrily add options like -fexception, -fPIC, -fstack-protetor-* for building kexec purgatory which runs in kernel mode. I filed a bug below: https://bugzilla.redhat.com/show_bug.cgi?id=1236456 Appreciate for any hints how to fix the problem. On 06/30/15 at 04:05pm, Pratyush Anand wrote: Hi Dave, Really not able to get whats the issue..let koji people look into.. kexec-tools-2.0.7-11.fc23.x86_64.rpm build failed http://koji.fedoraproject.org/koji/taskinfo?taskID=10249484 kexec-tools-2.0.9-1.fc23.x86_64.rpm does not work http://koji.fedoraproject.org/koji/taskinfo?taskID=10249201 kexec-tools-2.0.8-12.fc23.x86_64.rpm does not work http://koji.fedoraproject.org/koji/taskinfo?taskID=10249377 - so may be its not kexec-tools version issue kexec-tools-2.0.7-26.el7.x86_64.rpm work https://brewweb.devel.redhat.com/taskinfo?taskID=9439045 The only difference which I noticed between working brew and not working koji is that koji introduces -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 into gcc command line. However, I tried -fno-enforce-eh-specs (http://koji.fedoraproject.org/koji/taskinfo?taskID=10250889), but it did not work :( Only thing remaining is to try 2.0.9/8 in brew..will try that too. ~Pratyush -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mass bug: packages should not auto-enable systemd units
On 04/30/14 at 09:02am, Andrew Lutomirski wrote: Due to some confusion around how alternatives worked, I screwed up the list of packages here. I've updated it below. I'll give it a few more days before filing the actual bugs. On Wed, Apr 23, 2014 at 4:59 PM, Andrew Lutomirski l...@mit.edu wrote: Hi everyone- This is a notice in accordance with the mass bug filing procedure. A number of packages install systemd units and enable them automatically. They should not. Please update these packages to use the macroized scriptlet (https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd). If your package has an exception from FESCo permitting it to enable itself, please make sure that the service in question is listed in the appropriate preset file. There is a general exception described here: https://fedoraproject.org/wiki/Starting_services_by_default If your package falls under the general exception, then it is possible that no change is required. Nevertheless, if you are relying on the exception, please make sure that your rpm scripts are sensible. The exception is: In addition, any service which does not remain persistent on the system (aka, it runs once then goes away), does not listen to incoming connections during initialization, and does not require configuration to be functional may be enabled by default (but is not required to do so). An example of runs once then goes away service is iptables. Given that this issue can affect Fedora 20 users who install your package as a dependency, these bugs should be fixed in Fedora 20 and Rawhide. The tracker bug is here: https://bugzilla.redhat.com/show_bug.cgi?id=1090684 I created it early because three of the bugs are pre-existing. Next week, I'll file bugs against the packages below. If you fix your package in the mean time, please let me know. After three weeks, provenpackagers may step in and fix these issues. abrt acpid aeolus-audrey-agent aeolus-configserver audit avahi bluez bootchart cherokee cloud-init deltacloud-core dmapd dnssec-trigger glusterfs gnome-initial-setup gpsd ipmiutil iptables kexec-tools Cc kexec-tools list. libstoragemgmt libvirt lttng-tools monit NetworkManager nfs-utils nss-pam-ldapd olpc-kbdshim olpc-powerd openct pcsc-lite qemu qpid-cpp rootfs-resize rpcbind sendmail soundmodem spacenavd subscription-manager supervisor systemd targetcli util-linux vdsm xen --Andy ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: i18n translation contact
On 08/29/2012 12:31 PM, Domingo Becker wrote: 2012/8/28 Dave Young dyo...@redhat.com: On 08/29/2012 10:54 AM, Parag N(पराग़) wrote: For translation related issues contact to l10n people on tr...@lists.fedoraproject.org list. More can be read at http://fedoraproject.org/wiki/L10N Thanks very much, will contact i10n list There is a firstboot project in Fedora's Transifex instance [1]. Would you please claim maintanership or comaintanership of that project and upload the latest pot file? Hi, we have a firstboot module to configure the kdump service. This module is maintained in kexec-tools rpm instead of firstboot. Should I create a new project in https://fedora.transifex.com/projects/? I would be more than happy to translate it to Spanish and help you with the pot upload. Thanks a lot. Problem is there's no kexec-tools project there currently [1] https://fedora.transifex.com/projects/p/firstboot/ thank you and kind regards Domingo Becker -- Thanks Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i18n translation contact
Hi, CC tr...@lists.fedoraproject.org and Neil Horman What's tell the normal process of translating po file? Neil, do you remember how to update the po files in kexec-tools before? On 08/29/2012 04:00 PM, Dave Young wrote: On 08/29/2012 12:31 PM, Domingo Becker wrote: 2012/8/28 Dave Young dyo...@redhat.com: On 08/29/2012 10:54 AM, Parag N(पराग़) wrote: For translation related issues contact to l10n people on tr...@lists.fedoraproject.org list. More can be read at http://fedoraproject.org/wiki/L10N Thanks very much, will contact i10n list There is a firstboot project in Fedora's Transifex instance [1]. Would you please claim maintanership or comaintanership of that project and upload the latest pot file? Hi, we have a firstboot module to configure the kdump service. This module is maintained in kexec-tools rpm instead of firstboot. Should I create a new project in https://fedora.transifex.com/projects/? I would be more than happy to translate it to Spanish and help you with the pot upload. Thanks a lot. Problem is there's no kexec-tools project there currently [1] https://fedora.transifex.com/projects/p/firstboot/ thank you and kind regards Domingo Becker -- Thanks Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
i18n translation contact
Hi, I'm working on the Fedora/Rhel7 firstboot module, and I have some changes to the firstboot module pot files. I wonder who I should cantact for these translating things which are visible to end user. Any help will be appreciated. Thanks a lot Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i18n translation contact
On 08/29/2012 10:54 AM, Parag N(पराग़) wrote: For translation related issues contact to l10n people on tr...@lists.fedoraproject.org list. More can be read at http://fedoraproject.org/wiki/L10N Thanks very much, will contact i10n list Thanks, Parag. -- Thanks Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /var/crash/* disappear after reboot
On 04/09/2012 04:55 PM, Nikola Pajkovsky wrote: Dave Young dyo...@redhat.com writes: On 04/09/2012 10:58 AM, Dave Young wrote: On 04/08/2012 10:54 PM, Nikola Pajkovsky wrote: Dave Young dyo...@redhat.com writes: Hi, When I testing kdump, the vmcore is successfully captured in /sysroot/var/crash which is the /var/crash in rootfs. But after reboot it disappeared. Any idea about this? do you have installed abrt? Yes, it's installed. Looks like abrt will deal with vmcore in abrt-addon-vmcore, will it cleanup /var/crash/*? yup, that's exactly the 'problem'. Take a look at /var/spool/abrt/oops-*. From kdump side of view, the vmcore should be there instead of being deleted, It's the default behaviour. Could the abrt keep them? I can not think out why it will delete them if user/customer intend to capture and save them vmcore there. -- Thanks Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Change of kexec-tool ownership in Fedora..
On 04/04/2012 06:40 AM, Michael Schwendt wrote:
On Tue, 03 Apr 2012 13:30:51 +0800, DY (Dave) wrote:
On 04/03/2012 01:22 PM, Dave Young wrote:
On 03/31/2012 02:12 AM, Linda Wang wrote:
per Fedora team members:
There is a simple process for this already, using the pkgdb tool, with
documentation on the Fedora wiki:
https://admin.fedoraproject.org/pkgdb
http://fedoraproject.org/wiki/Using_the_package_database
In a nutshell, Dave can apply for full access in the web UI. Americo
can then approve all the access. Once Dave has verified he's got all
access, Americo can release ownerhips and Dave can take it over.
thanks!
Hi,
I have tried this process before, there's some problems:
1. pkgdb commit and approveacls checkboxes reject me with poping out
below error:
yangrr must be in one of these groups: ('cvsadmin', 'packager',
'provenpackager', 'newpackager') to hold the commit acl
2. when I apply the group 'packager' in fedora account system, I found I
can not apply it as:
Please do not apply to this group. Your sponsor will add you after
you've completed
http://fedoraproject.org/wiki/Join_the_package_collection_maintainers.
Then checking the wiki page, I found it's mostly about create a new
package, seems doesn't fit for our case..
So I'm CCing fedora devel list. Can anybody help on this?
It was rejected, just subscribed the list and retry.
The Wiki covers it:
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group
Thanks for pointing out.
Amerigo, we go and return to same point which I asked Neil before.
Are you a sponsor? can you look at this?
--
Thanks
Dave
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
/var/crash/* disappear after reboot
Hi, When I testing kdump, the vmcore is successfully captured in /sysroot/var/crash which is the /var/crash in rootfs. But after reboot it disappeared. Any idea about this? -- Thanks Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
