Re: Intent to orphan gnu-efi
On 31 Jan 2022 13:20, Robbie Harwood wrote: > Al Stone writes: > > > I may be interested in picking this up. I've been doing some UEFI > > dev work on Fedora. Let me take a look at the package and let you > > know in a day or two or three. Anything I should watch out for if > > I do decide to pick this up? > > Thanks for your interest! However, the plans have been dropped - dnf > and I weren't in agreement about how dependency querying should work. > While there aren't problems open against gnu-efi right now, PRs and > triage of bugs around the boot stack is welcome. > > Be well, > --Robbie ACK. I'll try to take a look and see what's there. Thanks. -- ciao, al --- Al Stone Principal Software Engineer Red Hat, Inc. a...@redhat.com --- signature.asc Description: PGP signature ___ 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
Re: Intent to orphan gnu-efi
On 25 Jan 2022 13:17, Robbie Harwood wrote:
> Hello, we plan to orphan gnu-efi shortly after I finish fixing the
> FTBFS. There do not appear to be any consumers:
>
> # dnf repoquery --repo=rawhide{,-source} --whatrequires gnu-efi{,-devel}
> --source
> Last metadata expiration check: 0:05:32 ago on Tue 25 Jan 2022 01:09:26 PM
> EST.
> gnu-efi-3.0.11-7.1.fc36.src.rpm
> #
>
> Be well,
> --Robbie
Howdy, Robbie.
I may be interested in picking this up. I've been doing some UEFI
dev work on Fedora. Let me take a look at the package and let you
know in a day or two or three. Anything I should watch out for if
I do decide to pick this up?
> ___
> 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
--
ciao,
al
---
Al Stone
Principal Software Engineer
Red Hat, Inc.
a...@redhat.com
---
signature.asc
Description: PGP signature
___
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
Re: RISC-V -- are we ready for more, and what do we need to do it?
On 06 Oct 2021 10:17, Justin Forbes wrote: > On Mon, Oct 4, 2021 at 12:03 PM Matthew Miller > wrote: > > > > Hi all! I just got back from Open Source Summit, several of the talks I > > found interesting were on RISC-V -- a high-level one about the > > organizational structure, and Drew Fustini's more technical talk. > > > > In that, he noted that there's a Fedora build *, but it isn't an official > > Fedora arch. As I understand it, the major infrastructure blocker is simply > > that there isn't server-class hardware (let alone hardware that will build > > fast enough that it isn't a frustrating bottleneck). > > > > So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances > > as builders, could we build fast enough under QEMU emulation to work? We > > have a nice early advantage, but if we don't keep moving, we'll lose that. > > > > But beyond that: What other things might be limits? Are there key bits of > > the distro which don't build yet? Is there a big enough risc-v team to > > respond to arch-specific build failures? And, do we have enough people to do > > QA around release time? > > Kernel is still an issue, in that the changes to support RISC-V have > not been merged yet, though I expect that is not a massive > undertaking. > > Justin Not been merged? Or just not turned on in the config? -- ciao, al --- Al Stone Principal Software Engineer Red Hat, Inc. a...@redhat.com --- ___ 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
Re: RISC-V -- are we ready for more, and what do we need to do it?
On 04 Oct 2021 21:39, Richard W.M. Jones wrote: > Personally speaking I think the real barrier is someone with a large > colourful hat putting up the money to hire a full time developer to > work on the project. > > Rich. Big ol' +1 to that. -- ciao, al ------- Al Stone Principal Software Engineer Red Hat, Inc. a...@redhat.com --- ___ 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
Re: hibernation — does it work for you: quick summary
On 10/8/18 4:42 AM, Zbigniew Jędrzejewski-Szmek wrote: > Various people replied, both here and on reddit [1]. Thank you all! > > Short summary: > works (possibly with minor glitches): 27 > works but with occasional regressions in some kernel versions: 3 > unusable: 10 If I may piggy-back on this thread a bit... Suspend and hibernate are things that come up in my daily work on a regular basis; my role so far has been to try to make sure that the kernel can find (and use) enough info in the ACPI tables on the system so that the kernel can get both suspend and hibernate to work properly. This is just part of the issue, of course; we've seen any number of reasons for failures, from bad ACPI tables, to hardware that doesn't actually know how to sleep, to systemd or GNOME misbehaving, and in one very odd case a bad mode line in xorg.conf threw things off. If I could ask each of you who has responded a favor, if you could please run the following on the machines reported: $ sudo dnf install acpica-tools $ sudo acpidump -o acpi.tables and send a copy of acpi.tables to a...@fedoraproject.org with a subject line telling me what kind of machine it is, I would *greatly* appreciate it. For the security conscious, this is the same as sending a copy of the contents of /sys/firmware/acpi/tables; if you have *any* doubts, just don't send the data. The reason I ask is to get a broader collection of ACPI tables that do and do not affect suspend/resume. This will help me work on improving the ACPI spec and on improving the kernel implementation so that we can at least remove as many of the problems as possible. As Zbigniew has said, empirical data is the best, but it can be hard to get. I can't guarantee that any given set of ACPI tables is the actual culprit, nor that I will be able to examine every one of them in excruciating detail, but it will be another avenue in understanding the problem better. Thanks. I now return you to your original thread... -- ciao, al --- Al Stone Software Engineer Red Hat, Inc. a...@redhat.com --- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity is still confusing
On 10/3/18 9:53 PM, Christopher wrote: > I'm still very confused about how to do modular packaging in Fedora. I > don't know: > > 1. How do I create a module for a new Fedora package? > 2. How do I create a module for my existing non-modular Fedora package? > 3. How do I declare BuildRequires on my build dependencies from another > module? > 4. How do I declare Requires on my runtime dependencies from another module? > 5. How do I know what modules are available? > 6. How do I figure out which packages are in a particular module? > 7. How do I find out what module a particular package is in? The documentation noted elsewhere in this thread is pretty handy; I've read through it a couple of times now and really appreciate the work that has gone into it -- thank you. I do have some suggestions: -- I'm going to be a little cranky and say the use of "ursine" is very confusing to me; it's a cute pun, but we have actual bears -- who are intensely ursine, as it were -- that live nearby so I constantly have to remind myself of context and translate since proper use of that word has been familiar to me for many years. This could just be me being an old codger, however, and I freely admit that :). -- Could we put the answers to the questions above into the FAQ? -- And the one question I have to add on to Christopher's wonderful list: I have a package where upstream releases about once a month, and each new release must by definition be backwards compatible (acpica-tools, specifically). I can think of no scenario where a module provides value to me or end-users; in fact, using anything other than the most recent causes problems. Do I have to create and maintain a module for this package anyway? Or are the defaults robust enough that a package can remain a package without touching modularity at all? The answer to this is completely unclear to me -- what I've read seems to imply that I must create a module definition regardless. Thanks again for all the documentation work so far! -- ciao, al --- Al Stone Software Engineer Red Hat, Inc. a...@redhat.com --- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Running a test from dist-git
On 10/2/18 1:40 AM, Richard W.M. Jones wrote: > On Mon, Oct 01, 2018 at 11:26:59AM +0200, Miroslav Vadkerti wrote: >> For this time I rescheduled the run: >> >> >> https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-rawhide-build-pipeline/detail/fedora-rawhide-build-pipeline/850/pipeline > > It appears to have failed, but I've got no clue why. How do I see > the output of the command? > > I think it would be easier if we could just drop a shell script into > tests/ and have it run that and display the output. The current > system seems elaborately overengineered and I don't understand why. > > Rich. > Hear, hear. + a dozen or so. I've been trying to add testing shell scripts I already have that work properly from the command line, and are even part of the RPM build, so thought it would be nice to convert them to this new automated system. So far, it just makes my brain hurt. -- ciao, al --- Al Stone Software Engineer Red Hat, Inc. a...@redhat.com --- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: You can now run Fedora 27 on 64 bit RISC-V machines (or qemu)
On 04/05/2018 03:31 PM, Richard W.M. Jones wrote: > I'm sure not many people have RISC-V machines cluttering their homes > and offices, but in case you can now run Fedora 27 on 64 bit RISC-V (RV64GC). > > We have: > > - A choice of GCC 7.3.1 or GCC 8 > - Perl, Python, Ruby, Erlang, OCaml, Lua, Tcl/Tk, ... > - vi, emacs, git, rpm-build, etc. > - PostgreSQL and MariaDB. > - TeXlive. > - Most of X11, Wayland and the basics of GNOME. > - A few games (quake2!) > > A practical solution is to run it under qemu. The disk images: > > https://fedorapeople.org/groups/risc-v/disk-images/ > > will run on qemu >= 2.12.0-0.2.rc0.fc29 or compiled from git on any(?) > host architecture. Please read the readme.txt file at the above link > first as it tells you how to run it. > > We also have limited support for the HiFive Unleashed U540 quad core > board although these have extremely limited availability and the price > will be well out of range for most people: > > https://rwmj.wordpress.com/2018/04/04/hifive-unleashed-booting/ > https://www.crowdsupply.com/sifive/hifive-unleashed > > I wrote a couple of articles for LWN about the bootstrapping process: > > https://lwn.net/Articles/749185/ > https://lwn.net/Articles/749443/ > > Rich. > Nice articles, btw. And very cool. Gives me something shiny and new to play with over the weekend :)... Thanks for all the work! -- ciao, al --- Al Stone Software Engineer Red Hat, Inc. a...@redhat.com --- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: EXTERNAL: Re: After suspension
On 01/04/2018 06:18 AM, Wells, Roger K. wrote: > On 01/02/2018 01:18 PM, Al Stone wrote: >> On 12/26/2017 12:23 PM, Wells, Roger K. wrote: >>> Small inconvenience but new and annoying: >>> Machine is Thinkpad x260 >>> uname -a: Linux rwells-x260 4.14.7-300.fc27.x86_64 #1 SMP Mon Dec 18 >>> 16:06:12 >>> UTC 2017 x86_64 x86_64 x86_64 GNU/Linux >>> Desktop: Gnome 3.26.4-1.fc27.x86_64 >>> >>> When the lid is opened on the suspended machine the screen saver appears >>> and the >>> clock proceeds to update until >>> the enter key is hit. Then the clock stops updating for 27 seconds >>> followed by >>> the login entry dialog appearing. >>> Then everything is back to normal. >>> This began right after the upgrade from F26 to F27 and has persisted >>> through one >>> or two subsequent routine updates. >>> There are inconsistencies, sometimes it only does it when there is only >>> wireless >>> connections and no wired options. >>> Sometimes it doesn't do it at all, no pattern here. >>> Sometimes the 27 second delay is much shorter but this is quite rare. >>> I have been running Fedora/Gnome for years and have never seen this. >>> >>> Any thoughts or things to try to help pin it down will be appreciated. >>> >>> thanks >> There have been a lot of recent changes in ACPI code for suspend and >> hibernate; >> it's always possible that something got tweaked in a recent kernel that could >> affect this particular model of machine. >> >> That being said, the 27 second delay sounds like the laptop hibernated (not >> suspended); if you waited a variable length of time to open the lid again, it >> might explain some of the variation -- sometimes it suspended, sometimes it >> was >> caught before hibernation was complete, sometime it was caught after it had >> fully hibernated. The other things that occur to me are that perhaps >> hibernate >> was not working before for this model of laptop and now it does; or, the >> power >> settings changed defaults, or did not retain settings when updating; or, some >> of the recent changes for lid notification aren't quite right for this laptop >> (there have been a few cases of that). Those are some of the places where I >> would start looking, at least... >> > It turns out that this delay only occurs when the suspend happened when an > external filesystem is mounted. > In this case a cifs mount, and IIRC there have been some issues related to > version changes that necessitated specifying "vers=1.0" in the fstab file. > I will do some experiments and report back if anything interesting develops. > Interesting. Could there be an ordering dependency somewhere on resume? E.g., I need to start file system but can't do that until network is ready but the info I need to start the network is on the file system ... some weirdness like that? -- ciao, al --- Al Stone Software Engineer Red Hat, Inc. a...@redhat.com --- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: After suspension
On 12/26/2017 12:23 PM, Wells, Roger K. wrote: > Small inconvenience but new and annoying: > Machine is Thinkpad x260 > uname -a: Linux rwells-x260 4.14.7-300.fc27.x86_64 #1 SMP Mon Dec 18 16:06:12 > UTC 2017 x86_64 x86_64 x86_64 GNU/Linux > Desktop: Gnome 3.26.4-1.fc27.x86_64 > > When the lid is opened on the suspended machine the screen saver appears and > the > clock proceeds to update until > the enter key is hit. Then the clock stops updating for 27 seconds followed > by > the login entry dialog appearing. > Then everything is back to normal. > This began right after the upgrade from F26 to F27 and has persisted through > one > or two subsequent routine updates. > There are inconsistencies, sometimes it only does it when there is only > wireless > connections and no wired options. > Sometimes it doesn't do it at all, no pattern here. > Sometimes the 27 second delay is much shorter but this is quite rare. > I have been running Fedora/Gnome for years and have never seen this. > > Any thoughts or things to try to help pin it down will be appreciated. > > thanks There have been a lot of recent changes in ACPI code for suspend and hibernate; it's always possible that something got tweaked in a recent kernel that could affect this particular model of machine. That being said, the 27 second delay sounds like the laptop hibernated (not suspended); if you waited a variable length of time to open the lid again, it might explain some of the variation -- sometimes it suspended, sometimes it was caught before hibernation was complete, sometime it was caught after it had fully hibernated. The other things that occur to me are that perhaps hibernate was not working before for this model of laptop and now it does; or, the power settings changed defaults, or did not retain settings when updating; or, some of the recent changes for lid notification aren't quite right for this laptop (there have been a few cases of that). Those are some of the places where I would start looking, at least... -- ciao, al --- Al Stone Software Engineer Red Hat, Inc. a...@redhat.com --- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: armv7hl builds running out of memory
On 07/27/2017 09:16 AM, Kaleb S. KEITHLEY wrote:
> On 07/26/2017 06:25 PM, Al Stone wrote:
>> I've been experimenting in a slightly different environment (RHEL vs Fedora)
>> but have been seeing oddly similar results. The use or not of the "-pipe" in
>> GCC didn't seem to help. If I forced the make in the %build step to be just
>> "make" (aka, "make -j1"), I could always get a build to work, albeit slowly.
>>
>> It turns out there is a typo in the spec file; look for the string
>> "WTIH_BABELTRACE" -- that should be "WITH_BABELTRACE". In the environment
>> I'm
>> using, "make -j32" is the default state. If I leave the typo alone and do
>> not
>> change the "make -j32", I can pretty consistently get the ceph build to fail;
>> the failure moves around a bit but generally seems to hang around with where
>> the babeltrace headers are being used (somewhere in RBD code, usually). If I
>> fix the typo -- and change nothing else -- the build succeeds.
>>
>> Would you mind trying this one change -- fixing the typo *only* -- and see if
>> you get the same results?
>
> If by same result you mean the build still fails, then yes. I get the same
> result.
>
> It's still running out of memory. Not the same way as the prior builds though.
>
> ...
> [100%] Building CXX object src/rgw/CMakeFiles/radosgw.dir/rgw_main.cc.o
> /usr/include/c++/7/bits/stl_map.h: In static member function 'static void
> pg_missing_set::generate_test_instances(std::__cxx11::list*>&)
> [with bool TrackChanges = false]':
> /usr/include/c++/7/bits/stl_map.h:493:4: note: parameter passing for argument
> of
> type 'std::_Rb_tree,
> std::_Select1st >,
> std::less, std::allocator pg_missing_item>
>> >::const_iterator {aka std::_Rb_tree_const_iterator> >hobject_t,
> pg_missing_item> >}' changed in GCC 7.1
> __i = _M_t._M_emplace_hint_unique(__i, std::piecewise_construct,
> ^~~
> virtual memory exhausted: Operation not permitted
> ...
> make: *** [Makefile:141: all] Error 2
> RPM build errors:
> error: Bad exit status from /var/tmp/rpm-tmp.RgosXb (%build)
> Bad exit status from /var/tmp/rpm-tmp.RgosXb (%build)
> Child return code was: 1
> ...
>
> See https://koji.fedoraproject.org/koji/taskinfo?taskID=20797264 for full
> logs.
>
> --
>
> Kaleb
Rats. Thought I had a clue or a pointer; thanks for trying, though. When a
colleague double checked my results, we discovered that what I was seeing was
not a change in behavior from fixing the typo, but just a fluke, pure random
chance -- we've probably got a race condition in the build somehow where if
exactly the right combination of compiles tries to occur in parallel, the OOM
killer gets invoked and compilation fails.
You may have to force the %build section to use "make -j1", as well as remove
the use of "-pipe" as you have done.
In the meantime, I'm following up on a g++ bug that may or may not be relevant;
it definitely stresses memory horribly but I need to prove that something in the
compile is actually hitting the bug. As a workaround, something like this might
help:
diff --git a/ceph.spec b/ceph.spec
index b321a1b..f15171e 100644
--- a/ceph.spec
+++ b/ceph.spec
@@ -811,8 +811,11 @@ cmake .. \
%endif
-DBOOST_J=%{_smp_ncpus}
+%ifarch aarch64
+make
+%else
make %{?_smp_mflags}
-
+%endif
%if 0%{with make_check}
%check
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: armv7hl builds running out of memory
I've been experimenting in a slightly different environment (RHEL vs Fedora) but have been seeing oddly similar results. The use or not of the "-pipe" in GCC didn't seem to help. If I forced the make in the %build step to be just "make" (aka, "make -j1"), I could always get a build to work, albeit slowly. It turns out there is a typo in the spec file; look for the string "WTIH_BABELTRACE" -- that should be "WITH_BABELTRACE". In the environment I'm using, "make -j32" is the default state. If I leave the typo alone and do not change the "make -j32", I can pretty consistently get the ceph build to fail; the failure moves around a bit but generally seems to hang around with where the babeltrace headers are being used (somewhere in RBD code, usually). If I fix the typo -- and change nothing else -- the build succeeds. Would you mind trying this one change -- fixing the typo *only* -- and see if you get the same results? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
